This commit is contained in:
Marcelo Moreira de Mello
2021-04-21 15:02:33 -04:00
4 changed files with 36 additions and 2 deletions

View File

@@ -29,6 +29,7 @@ An [Ansible AWX](https://github.com/ansible/awx) operator for Kubernetes built w
* [Custom Volume and Volume Mount Options](#custom-volume-and-volume-mount-options)
* [Upgrade Notes](#upgrade-notes)
* [From Older Versions](#from-older-versions)
* [Exporting Environment Variables to Containers](#exporting-environment-variables-to-containers)
* [Development](#development)
* [Testing](#testing)
* [Testing in Docker](#testing-in-docker)
@@ -52,10 +53,12 @@ Note that the operator is not supported by Red Hat, and is in **alpha** status.
This Kubernetes Operator is meant to be deployed in your Kubernetes cluster(s) and can manage one or more AWX instances in any namespace.
First you need to deploy AWX Operator into your cluster:
First, you need to deploy AWX Operator into your cluster. Start by going to https://github.com/ansible/awx-operator/releases and making note of the latest release.
Replace `<tag>` in the URL below with the version you are deploying:
```bash
#> kubectl apply -f https://raw.githubusercontent.com/ansible/awx-operator/devel/deploy/awx-operator.yaml
#> kubectl apply -f https://raw.githubusercontent.com/ansible/awx-operator/<tag>/deploy/awx-operator.yaml
```
Then create a file named `my-awx.yml` with the following contents:
@@ -486,6 +489,27 @@ Example spec file for volumes and volume mounts
For `AWX` instances created by the `awx-operator<0.0.8`, it is required both PostgreSQL `statefulset` and AWX `deployment` resources to be deleted and recreated. This is required due to new labels added on both resources and the requirement of the Kubernetes API which enforces `selector.matchLabels` attributes to be `ready-only`.
The `awx-operator` will handle the upgrading both resources. Note that just the `statefulset` and `deployment` will be recreated. Therefore, any `persistent volume` used on any of these 2 resources, **shall not be deleted**.
#### Exporting Environment Variables to Containers
If you need to export custom environment variables to your containers.
| Name | Description | Default |
| ----------------------------- | -------------------------------------------------------- | ------- |
| tower_task_extra_env | Environment variables to be added to Task container | '' |
| tower_web_extra_env | Environment variables to be added to Web container | '' |
Example configuration of environment variables
```yaml
spec:
tower_task_extra_env: |
- name: MYCUSTOMVAR
value: foo
tower_web_extra_env: |
- name: MYCUSTOMVAR
value: foo
```
## Development

View File

@@ -295,6 +295,7 @@ spec:
- urn:alm:descriptor:com.tectonic.ui:advanced
- urn:alm:descriptor:com.tectonic.ui:hidden
- displayName: Tower Task Extra Env
description: Environment variables to be added to Task container
path: tower_task_extra_env
x-descriptors:
- urn:alm:descriptor:com.tectonic.ui:advanced
@@ -322,6 +323,7 @@ spec:
- urn:alm:descriptor:com.tectonic.ui:advanced
- urn:alm:descriptor:com.tectonic.ui:hidden
- displayName: Tower Web Extra Env
description: Environment variables to be added to Web container
path: tower_web_extra_env
x-descriptors:
- urn:alm:descriptor:com.tectonic.ui:advanced

View File

@@ -225,6 +225,7 @@ spec:
type: string
type: array
tower_task_extra_env:
description: Environment variables to be added to Task container
type: string
tower_ee_extra_volume_mounts:
description: Specify volume mounts to be added to Execution container
@@ -270,6 +271,7 @@ spec:
type: string
type: array
tower_web_extra_env:
description: Environment variables to be added to Web container
type: string
tower_web_extra_volume_mounts:
description: Specify volume mounts to be added to web container

View File

@@ -43,6 +43,12 @@ type: Opaque
> For `host`, a URL resolvable by the cluster could look something like `postgresql.<namespace>.svc.cluster.local`, where `<namespace>` is filled in with the namespace of the AWX deployment you are migrating data from.
If your AWX deployment is already using an external database server or its database is otherwise not managed
by the AWX deployment, you can instead create the same secret as above but omit the `-old-` from the `name`.
In the next section pass it in through `tower_postgres_configuration_secret` instead, omitting the `_old_`
from the key and ensuring the value matches the name of the secret. This will make AWX pick up on the existing
database and apply any pending migrations. It is strongly recommended to backup your database beforehand.
## Deploy AWX
When you apply your AWX object, you must specify the name to the database secret you created above: