* fix: correct port number for internal receptor address
* feat: add support for ingress for awxmeshingress cr
* feat: add support for ingressroutetcp (for traefik) for awxmeshingress cr
When pod loses connection with k8s api server,
a statefulset can take a while (5 minutes) before
it is rescheduled. Deployments quicker turnaround
in this situation, which should help mesh
stability.
Signed-off-by: Seth Foster <fosterbseth@gmail.com>
The mesh role now calls
1. awx-manage provision instance to register the hop
node to the database
2. awx-manage add_receptor_address to register the
internal address
3. awx-manage add_receptor_address to register the
external address (to be used by remote nodes)
CRD expanded to include external_ipaddress and
external_hostname
external_ipaddress is added as ipaddress in the
hop node certificate
external_hostname is added as dnsname in the
hop node certificate
the mesh role now checks for is_openshift and
only creates a Route if true. Otherwise it
will use external_hostname set in the spec
file in place of Route name.
Signed-off-by: Seth Foster <fosterbseth@gmail.com>
sample are used in CI for validation test
in current implementation we only support openshift route this will not work on kind clusters correctly and having the sample is causing CI failure
* Add multi-arch image builds to makefile
* A default set of platforms is specified and will build those if var `PLATFORMS` is not specified on the CLI
* Builds containers and stores @ghcr with tag that is git commit.
* Pushes the image to quay.io/ansible with tag devel.
* Update Promote to use single build point and the multi-arch manifest
- Pulls the complete manifest containing all architectures that matches the version from ghcr
- Tag manifest with the specified version and publish to quay.io
- Tag manifest as 'latest' and publish to quay.io
Author: jon-nfc
Co-authored-by: Christian M. Adams <chadams@redhat.com>
Co-authored-by: TheRealHaoLiu
* Replace api version for deployment kind to apps/v1
* Add new multiple ingress spec and deprecate hostname and ingress_tls_secret
* Manage new ingress_hosts.tls_secret backup separately
* Fix ci molecule lint warnings and error
* Fix documentation
* Fix ingress_hosts tls_secret key being optional
* Remove fieldDependency:ingress_type:Ingress for Ingress Hosts
* Fix scenario when neither hostname or ingress_hosts is defined
---------
Co-authored-by: Guillaume Lefevre <guillaume.lefevre@agoda.com>
Co-authored-by: Seth Foster <fosterseth@users.noreply.github.com>
Co-authored-by: Christian Adams <chadams@redhat.com>
- Previously, if the flag was set to true, the bash conditional failed
because the boolean was not correctly interpreted.
- Use pg_restore return code to determine if the task should be marked as failed
Signed-off-by: Christian M. Adams <chadams@redhat.com>
- Describe checking out the tag to deploy in basic install instructions
- Also, the repo already contains a awx-demo.yml file but the doc reference awx-demo.yaml with en extra a. I remove this road block for newcomers by using same 'yml' extension everywhere.
We discovered some weird behavior observed on later Kubernetes version (OCP 4.12+)
For some reason why we apply the templates postgres resource with
```
postgres_storage_requirements:
limit: {}
requests:
storage: <x>Gi
```
the `Create Database if no database is specified` task that does the k8s apply will always think the resource is "changed" and proceed to cycle the task and web pod
This resulted in AWX pods being continuously restarted
Update postgres.yaml.j2
Rename TAG_NAME to VERSION so it's no longer ambiguous when running hack/publish-to-operator-hub.sh
Checkout awx-operator at VERSION with fetch-depth=0 so that `make print-PREV_VERSION` will be able to actually find previous tag
* Automate awx-operator publishing on operatorhub
* Use scripts from workflow branch
Previously it will use scripts from the release tag to do the release
If we have to fix up the scripts for any reason we would have to retag
This will allow us to modify the publishing script without having to retag the release.
NOTE: the commit in this PR was accidentally pushed to `devel` directly... merging this PR just for the record.
Previously it will use scripts from the release tag to do the release
If we have to fix up the scripts for any reason we would have to retag
This will allow us to modify the publishing script without having to retag the release.
- Fix indentation on one of the newer molecule files.
- Update to actions/checkout@v3 and actions/setup-python@v4 and helm/kind-action@v1.8.0.
Signed-off-by: Rick Elrod <rick@elrod.me>
* Update awx.ansible.com_awxs.yaml with rsyslog resource containers
* Update awx-operator.clusterserviceversion.yaml with x-descriptors
* Add default values in main.yml
* Template resource_requirements in web.yaml.j2 and task.yaml.j2
* feat: add HostAliases to web/task containers (fixes#646)
* feat: add HostAliases to web/task containers
* Make host_aliases display in the Operator UI
* Add default value for host_aliases and add to web deployment template
Co-authored-by: zhangpeng.zong <zhangpeng.zong@funplus.com>
Co-authored-by: Dimitri Savineau <savineau.dimitri@gmail.com>
- In some use cases, limits must be set for every container in a
cluster. To address this, we will use the task and web resource
requirements for the initContainers where applicable.
This was fixed in 6cae8df but the task/web split rebase didn't apply this
to the web deployment.
This prevents to deploy the operator when FIPS is enabled.
{"msg": "An unhandled exception occurred while running the lookup plugin
'template'. Error was a <class 'ValueError'>, original message:
[digital envelope routines: EVP_DigestInit_ex] disabled for FIPS"}
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
- rename awx_pod to awx_web_pod to better reflect intention
- update `awx_version` block to also validate awx_task_pod
- add get awx_task_pod in additional label check block (fix CI in awx repo which does not run the validate awx_version block)
- add assertion for awx_task_pod extra label
move chmod chgrp for projects_persistence to different init
default init container is the awx-ee because and unable to run command chgrp
moving it into a different init container
note this is not needed for openshift so this is conditional on is_k8s
SUPERVISOR_WEB_CONFIG_PATH is used in the old deployment for task container to reach into the web container and restart services
this is no longer possible/needed after splitting the deployment
renaming SUPERVISOR_WEB_CONFIG_PATH to SUPERVISOR_CONFIG_PATH
and setting it to the supervisor file for the container
this can still be useful to help run `supervisorctl -c $SUPERVISOR_CONFIG_PATH`
- rename scale_down vars to the new deployments since the old one no longer exists
- rename postgres.yml scale down vars as it references the old ones as well
Added the following volume mounts to the web container:
- receptor-work-signing
- receptor-ca
- work-public-key.pem
Also added these corresponding volumes to the web deployments:
- receptor-ca
- receptor-work-signing
update logic for determining if install.yml task should be run
to respect the auto_upgrade field in awx resource
conditions and expected behavior
```
auto_upgrade awx awx-web awx-task run install.yml
-------------- ----- --------- ---------- -----------------
T - - - T
F T - - F
F - T T F
F - T F T
F - F T T
F - F F T
```
* first pass, still WIP, need tolerations etc
* add tolerations that don't work bc idk
* bug hunting
* local push, still a WIP
* affinity still needs testfor to_nice_yaml, tolerations logic is working
* fixed task deployment and affinity for both
The choice for backup_source are:
- Backup CR
- PVC
This current prevents to create an AWXRestore CR with the Backup CR value
from the OLM UI.
Error "Unsupported value: "Backup CR": supported values: "CR", "PVC"" for
field "spec.backup_source".
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
The deployment_name from the AWXRestore CR doesn't requires to set a
value for this parameter.
That parameter is already required for the AWXBackup CR so it should be
the same for AWXRestore.
Creating an AWXRestore CR without deployment_name set results in a failure
during the Secrets restoration.
"reason":"FieldValueInvalid","message":"Invalid value: \\"-receptor-ca\\":
a lowercase RFC 1123 subdomain must consist of lower case alphanumeric
characters, \'-\' or \'.\', and must start and end with an alphanumeric
character (e.g. \'example.com\', regex used for validation is
\'[a-z0-9]([-a-z0-9]*[a-z0-9])?(\\\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\')"
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
We could let the web container terminate as usual, as there are no
reasons to keep it running as it doesn't participate in
job control. Additionally, it stops receiving traffic with the beginning
of termination
> At the same time as the kubelet is starting graceful shutdown, the
> control plane removes that shutting-down Pod from EndpointSlice (and
> Endpoints) objects where these represent a Service with a configured
> selector
@ https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination
- previously, there was no way to auto-assign a port by default
which led to conflicts with other deployments at times
- nodeport_port param can still be used to specify a port if desired
With the previous approach, not all associated (mounted) CM/Secrets
changes caused the Deployment to be rolled out, but also the Deployment
could have been rolled out unnecessary during e.g. Ingress or Service
changes (which do not require Pod restarts).
Previously existing Pod removal (state: absent) was not complete as
other pods continued to exist, but also is not needed with this commit
change due to added Pods annotations.
The added Deployment Pod annotations now cause the new ReplicaSet
version to be rolled out, effectively causing replacement of the
previously existing Pods in accordance with the deployment `strategy`
(https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#deploymentstrategy-v1-apps,
`RollingUpdate`) whenever there is a change in the associated CMs or
Secrets referenced in annotations. This implementation is quite standard
and widely used for Helm workflows -
https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments
Do not consider Pods marked for deletion when calculating tower_pod to
address replicas scale down case - where normally Pods spawned recently
are being taken for removal. As well as the case when operator kicked
off but some old replicas are still terminating.
Respect `creationTimestamp` so to make sure that the newest Pod is taken
after Deployment application, in which case multiple RS Pods (from old
RS and new RS) could be running simultaneously while the rollout is
happening.
Proper waiting is already performed earlier during Deplyment{apply: yes, wait: yes} -
e6ac874098/plugins/module_utils/k8s/waiter.py (L27).
And also not every Deployment change produces new RS/Pods. For example,
changing Deployment labels won't cause new rollout, but will cause
`until` loop to be invoked unnecessarily (when replicas=1).
There are cases when having a new Deployment may be taking above the
default timeout of 120s.
For instance, when a Deployment has multiple replicas, and each replica
starts on a separate node, and the Deployment specifies new images, then
just pulling these new images for each replica may be taking above the
default timeout of 120s.
Having the default time multiplied by the number of replicas should
provide generally enough time for all replicas to start
* Move label templates into `common` role
So that there is single source of labels management, and labels are
unified across the other roles
* Introduce `additional_labels`
* Fix paths for labels templates
* Return `additional_labels_items` as list
* Add molecule tests
- Reconfigure index file generation
- checkout gh-pages branch in promote.yaml
- fix helm-index make target
- add gh-pages folder in .gitignore
Signed-off-by: Miles Wilson <wilson.mil@icloud.com>
Co-authored-by: Hao Liu <haoli@redhat.com>
Co-authored-by: Christian Adams <rooftopcellist@gmail.com>
In order to get information during CI debugging then turning off the
no_log statement will help with non hidden output.
FAILED! => {"censored": "the output has been hidden due to the fact that
'no_log: true' was specified for this result"}
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
I had hard times to identify how to declare to include statement for a custom certifcate bundle within the Kustomize file.
The tricky part for me was to spot the option "disableNameSuffixHash: true" in order to avoid renaming the secret name with an has suffix
* Add an option to specify affinity rules for the awx pod
In some cases, you may want to use affinity rules instead of a
node selector so you can have more flexbility. For example if you want
to have "soft" rules i.e. run my pod on this node if possible otherwise
run it anywhere
* Rename `node_affinity` to `affinity`
* Maintain defaults and CSV
* Add fields validation
Co-authored-by: Olivier <oliverf1ca@yahoo.com>
`base64 --decode` prints no new line after its output, resulting in the next shell prompt starting immediately after the password. This makes copying the password difficult. Adding an `echo` at the end of the command fixes this.
Since e966e92 we're using the `no_log` variable to control the no_log
statement value.
This job will check if the no_log statements are correctly set.
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
Set the no_log default value in the CRDs and switch from hidden to
boolean in the CSV file so this can be display properly in the UI.
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
e966e92 adds the configurable no_log parameter to all CRDs (install, backup
and restore) but only once in the CSV file (for installer).
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
Support external execution nodes
- Allow receptor.conf to be editable at runtime
- Create CA cert and key as a k8s secret
- Create work signing RSA keypair as a k8s secret
- Setup volume mounts for containers to have access to the needed
Receptor keys / certs to facilitate generating the install bundle
for a new execution node
- added firewall rule, work signing and tls cert configuration to default receptor.conf
The volume mount changes in this PR fulfill the following:
- `receptor.conf` need to be shared between task container and ee container
- **task** container writes the `receptor.conf`
- **ee** consume the `receptor.conf`
- receptor ca cert/key need to be mounted by both ee container and web container
- **ee** container need the ca cert
- **web** container will need the ca key to sign client cert for remote execution node
- **web** container will need the ca cert to generate install bundle for remote execution node
- receptor work private/public key need to be mounted by both ee container and web container
- **ee** container need to private key to sign the work
- **web** container need the public key to generate install bundle for remote execution node
- **task** container need the private key to sign the work
Signed-off-by: Hao Liu <haoli@redhat.com>
Co-Authored-By: Seth Foster <fosterbseth@gmail.com>
Co-Authored-By: Shane McDonald <me@shanemcd.com>
Signed-off-by: Hao Liu <haoli@redhat.com>
Co-authored-by: Shane McDonald <me@shanemcd.com>
Co-authored-by: Seth Foster <fosterbseth@gmail.com>
* Bump Postgresql, Nginx and Redis versions
* pg12 --> pg13 upgrade path
* Set supported pg version as a variable to remain DRY
* Make deleting the old db data pvc after upgrade configurable
* Use labels to find the postgres pod
* backup/restore: fix postgres label selector value
We need to use the deployment_name variable for the postgres instance
name.
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
* backup/restore: add missing default supported_pg_version variable
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
* restore: update database_host fact with pg suffix
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
Co-authored-by: Dimitri Savineau <dsavinea@redhat.com>
- Removes backup_pvc_namespace field from OLM forms
- This field has created confusion for users and there is no strong
case for needing this functionality
- Users will still be able to add it to the yaml for the CR if they
want to use it with the cluster-scoped AWX operator
- Remove unneeded advanced descriptors to avoid empty Advanced
configuration expander
fixes AAP-1176
GNU make resolves the $(wildcard ) macro when starting a block, and
caches it for the duration of the run. In order to correctly remove
namespace references from the generated helm charts, we have to split
the generation and editing into two makefile targets.
Helm should be able to set the namespace for the operator at deploy time
via the --namespace option. Use yq to remove all references to
namespaces in the helm chart prior to publishing.
Update CI process to create namespace during install.
Resolves#907
Changing bug_report from markdown to yaml
Adding config.yml for new issues
Adding Code of Conduct and support to the README (along with tags at the
top of the readme)
Adding SECURITY.md
Adding CODE_OF_CONDUCT.md
When the task_resource_requirements variable has no "limits" key (which
is the default value) then the config template generation fails
----------------------------------
looking for "config.yaml.j2" at "/opt/ansible/roles/installer/templates/config.yaml.j2"
File lookup using /opt/ansible/roles/installer/templates/config.yaml.j2 as file
fatal: [localhost]: FAILED! => {
"msg": "The task includes an option with an undefined variable. The error was: the inline if-expression on line 36 evaluated to false and no else section was defined.
The error appears to be in /opt/ansible/roles/installer/tasks/resources_configuration.yml: line 30, column 3, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
- name: Apply Resources
^ here
----------------------------------
The current condition doesn't have a else statement so the template fails
when the "limits" key isn't present.
This rewrite the current if/else statement in jinja template.
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
* defaults in Deploying a specific version of AWX added
* Update README.md
updated the README clarified the defaults of Deploying a specific version of AWX
* added capability to set the redis container resources
* Reduce resource requests so that it can be scheduled on GitHub workflows
Co-authored-by: Cedric Morin <cedric.morin_ext@michelin.com>
Without this I was seeing:
$ make yq
tar: yq_linux_amd64: Not found in archive
tar: Exiting with failure status due to previous errors
make: *** [Makefile:240: yq] Error 2
* Load LDAP password from secret and update guideline
* Add pod_labels for custom pod labels
Signed-off-by: Loc Mai <lmai@axon.com>
* Omit tls secret if using wildcard cert
* Resolve conflicts
* Remove the ingress changes
* Remove the config changes
* Load LDAP password from secret and update guideline
* Omit tls secret if using wildcard cert
* Resolve conflicts
* Remove the ingress changes
* Remove the config changes
Co-authored-by: hungts <hungts@axon.com>
Co-authored-by: Loc Mai <lmai@axon.com>
Co-authored-by: Max Bidlingmaier <Max-Florian.Bidlingmaier@sap.com>
Co-authored-by: Max Bidlingmaier <maks@konsolan.de>
When there are e.g. multiple authenticated container registries used
we need to be able to add multiple imagePullSecrets to the k8s resource
Co-authored-by: Maximilian Meister <maximilian.meister@pm.me>
It's recommended to install the standalone version of kustomize rather
than using the version that ships with kubectl because that version is
typically very old and doesn't match the docs.
- This avoids issues with multple initContainers trying to mount the
postgres pvc at once, as is the case when there are multiple
replicas.
Signed-off-by: Christian M. Adams <chadams@redhat.com>
Otherwise, we get the too-low setting of the request, which
will be a rough experience for folks who have been using the operator
and are used to the experience of having entire underlying node capacity
Users can still set the setting via extra_settings to get the experience
of having each pod with a individualized capacity, or set a limit.
This warning originated [two years
ago](6e6cd37ce6 (diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R18)).
The API is now at `v1beta1`, so it's probably not accurate to call it
"alpha" anymore.
Since AWX and awx-operator are both OSS upstream projects, there is
implicitly no vendor support from Red Hat. The warning about support can
lead to confusion, and potentially imply that some other part of AWX is
supported, as demonstrated in a recent [twitter
thread](https://twitter.com/vwbusguy/status/1470902780311212035). When
this warning was written, the operator was self-described as an
"installation method for Ansible Tower or AWX". Since then, it appears
that the operator is focused only on upstream AWX, so that presumably
removes any need to clarify vendor support status.
I ran into a bug with this when releasing the latest version of AWX. RELATED_IMAGE_AWX always clobbers the version and does not respect `DEFAULT_AWX_VERSION`
This allows for doing stuff like this on the custom resource:
```
security_context_settings:
runAsUser: 1000
runAsGroup: 0
```
I added `snakeCaseParameters: False` because without it, variables like `runAsUser` become `run_as_user`... and that doesnt work.
* Only use them if user did not set an image, or RELATED_IMAGES_ var
is not set
Signed-off-by: Christian M. Adams <chadams@redhat.com>
(cherry picked from commit bb957be9e6)
If you `git checkout <some-released-tag>` this should just work. If you run this from the HEAD of devel, you will need to run `make docker-build docker-push` and override the appropriate image versions.
With some kubernetes clusters and settings, you might need to specify
some capabilities so the container can start. For example, the CHOWN,
SETUID and SETGID capabilties.
Setting the redis_capabilities option will add the capabilities in
the deployment.
* This increases security, the awx-operator SA has less cluster-wide
access
* This means one operator can only deploy to a single namespace
* If AWX deployments are needed in multiple namespaces, multiple
awx-operators can be deployed to accomplish this.
Signed-off-by: Christian M. Adams <chadams@redhat.com>
We hit that issue ourselves and it took us weeks until someone pointed out our error.
As it feels like this could hit other users inexperienced with kubernetes too, I propose this note.
- This prevents us from overwriting vars unintentionally at restore time
- This will make it easier to add secrets to be backed up in the future
- Add generated secret names to awx spec backup
- Fail early if secret status doesn't exist
- Skip if secret is not in spec for non-generated secrets
- Secret values must be b64 decoded before secret is created
- Cleanup temp files
* This is so that users can intentially set it to an empty string if they want to use the default storage class
* conversely, now users can manually create a pvc that does not utilize the default storage class
- renamed some more variables to be consistent with the pulp-operator
- removed unneeded vars from backup & restore crds
- added a way to parse spec at restore time by including vars to
get around the issue of triply nested quotes when using to_json
- set migrate data status even if custom name for old postgres config is not used
- Allow users to change pg name, pw & db name for a managed postgres
- set default value for postgres-configuration type as unmanaged if secret is created
- Make pg port configurable for managed deployments
For more advanced usage, a user can do the
extra_volumes/extra_volume_mounts dance. But for simple need adding this
parameter make it easy to just specify an extra parameter.
Currently the file is inacurrate and yaml parsing would fail on line 166
with
> syntax error: expected <block end>, but found '<block mapping start>'
(syntax)
This chart installs the AWX Operator resources configured in [this](https://github.com/ansible/awx-operator) repository.
## Getting Started
To configure your AWX resource using this chart, create your own `yaml` values file. The name is up to personal preference since it will explicitly be passed into the helm chart. Helm will merge whatever values you specify in your file with the default `values.yaml`, overriding any settings you've changed while allowing you to fall back on defaults. Because of this functionality, `values.yaml` should not be edited directly.
In your values config, enable `AWX.enabled` and add `AWX.spec` values based on the awx operator's [documentation](https://github.com/ansible/awx-operator/blob/devel/README.md). Consult the docs below for additional functionality.
### Installing
The operator's [helm install](https://ansible.readthedocs.io/projects/awx-operator/en/latest/installation/helm-install-on-existing-cluster.html) guide provides key installation instructions.
* This value is accessed by `{{ $.Release.Namespace }}` in the templates
* Acts as the default namespace for all unspecified resources
*`--create-namespace` specifies that helm should create the namespace before installing
To update an existing installation, use `helm upgrade` instead of `install`. The rest of the syntax remains the same.
### Caveats on upgrading existing installation
There is no support at this time for upgrading or deleting CRDs using Helm. See [helm documentation](https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#some-caveats-and-explanations) for additional detail.
When upgrading to releases with CRD changes use the following command to update the CRDs
The goal of adding helm configurations is to abstract out and simplify the creation of multi-resource configs. The `AWX.spec` field maps directly to the spec configs of the `AWX` resource that the operator provides, which are detailed in the [main README](https://github.com/ansible/awx-operator/blob/devel/README.md). Other sub-config can be added with the goal of simplifying more involved setups that require additional resources to be specified.
These sub-headers aim to be a more intuitive entrypoint into customizing your deployment, and are easier to manage in the long-term. By design, the helm templates will defer to the manually defined specs to avoid configuration conflicts. For example, if `AWX.spec.postgres_configuration_secret` is being used, the `AWX.postgres` settings will not be applied, even if enabled.
### External Postgres
The `AWX.postgres` section simplifies the creation of the external postgres secret. If enabled, the configs provided will automatically be placed in a `postgres-config` secret and linked to the `AWX` resource. For proper secret management, the `AWX.postgres.password` value, and any other sensitive values, can be passed in at the command line rather than specified in code. Use the `--set` argument with `helm install`. Supplying the password this way is not recommended for production use, but may be helpful for initial PoC.
### Additional Kubernetes Resources
The `AWX.extraDeploy` section allows the creation of additional Kubernetes resources. This simplifies setups requiring additional objects that are used by AWX, e.g. using `ExternalSecrets` to create Kubernetes secrets.
Resources are passed as an array, either as YAML or strings (literal "|"). The resources are passed through `tpl`, so templating is possible. Example:
The `customSecrets` section simplifies the creation of our custom secrets used during AWX deployment. Supplying the passwords this way is not recommended for production use, but may be helpful for initial PoC.
If enabled, the configs provided will automatically used to create the respective secrets and linked at the CR spec level. For proper secret management, the sensitive values can be passed in at the command line rather than specified in code. Use the `--set` argument with `helm install`.
Example:
```yaml
AWX:
# enable use of awx-deploy template
...
# configurations for external postgres instance
postgres:
enabled:false
...
customSecrets:
enabled:true
admin:
enabled:true
password:mysuperlongpassword
secretName:my-admin-password
secretKey:
enabled:true
key:supersecuresecretkey
secretName:my-awx-secret-key
ingressTls:
enabled:true
selfSignedCert:true
key:unset
certificate:unset
routeTls:
enabled:false
key:<contentoftheprivatekey>
certificate:<contentofthepublickey>
ldapCacert:
enabled:false
crt:<contentofmybundlecacrt>
ldap:
enabled:true
password:yourldapdnpassword
bundleCacert:
enabled:false
crt:<contentofmybundlecacrt>
eePullCredentials:
enabled:false
url:unset
username:unset
password:unset
sslVerify:true
secretName:my-ee-pull-credentials
cpPullCredentials:
enabled:false
dockerconfig:
- registry:https://index.docker.io/v1/
username:unset
password:unset
secretName:my-cp-pull-credentials
```
### Custom volumes
The `customVolumes` section simplifies the creation of Persistent Volumes used when you want to store your databases and projects files on the cluster's Node. Since their backends are `hostPath`, the size specified are just like a label and there is no actual capacity limitation.
You have to prepare directories for these volumes. For example:
| `customVolumes.postgres.storageClassName` | PersistentVolume storage class name | `<resourcename>-projects-volume` |
# Contributing
## Adding abstracted sections
Where possible, defer to `AWX.spec` configs before applying the abstracted configs to avoid collision. This can be facilitated by the `(hasKey .spec what_i_will_abstract)` check.
## Building and Testing
This chart is built using the Makefile in the [awx-operator repo](https://github.com/ansible/awx-operator). Clone the repo and run `make helm-chart`. This will create the awx-operator chart in the `charts/awx-operator` directory. In this process, the contents of the `.helm/starter` directory will be added to the chart.
## Future Goals
All values under the `AWX` header are focused on configurations that use the operator. Configurations that relate to the Operator itself could be placed under an `Operator` heading, but that may add a layer of complication over current development.
# Chart Publishing
The chart is currently hosted on the gh-pages branch of the repo. During the release pipeline, the `index.yaml` stored in that branch is generated with helm chart entries from all valid tags. We are currently unable to use the `chart-releaser` pipeline due to the fact that the complete helm chart is not committed to the repo and is instead built during the release process. Therefore, the cr action is unable to compare against previous versions.
Instead of CR, we use `helm repo index` to generate an index from all locally pulled chart versions. Since we build from scratch every time, the timestamps of all entries will be updated. This could be improved by using yq or something similar to detect which tags are already in the index.yaml file, and only merge in tags that are not present.
Not using CR could be addressed in the future by keeping the chart built as a part of releases, as long as CR compares the chart to previous release packages rather than previous commits. If the latter is the case, then we would not have the necessary history for comparison.
This is a list of high-level changes for each release of `awx-operator`. A full list of commits can be found at `https://github.com/ansible/awx-operator/releases/tag/<version>`.
# 0.19.0 (Mar 23, 2022)
- Fix corrupted spec for the service with nodeport type (kurokobo) - dbaf64e
- Add ability to deploy with OLM & added logo (Christian Adams) - 86c31a4
- Fix backup & restore issues with special characters in the postgres password (kurokobo) - 589a375
- Use centos:stream8 container where applicable (Shane McDonald)- 12a58d7
# 0.14.0 (Oct 03, 2021)
- Starting with awx-operator 0.14.0, the project is now based on operator-sdk 1.x.
- To avoid a headache, you probably want to delete your existing operator Deployment and follow the README.
- Starting with awx-operator 0.14.0, AWX can only be deployed in the namespace that the operator exists in. See [upgrade docs](./README.md#upgrading) for necessary cleanup actions. (Christian Adams) - 58c3ebf (breaking change)
# 0.10.0 (Jun 1, 2021)
- Make tower_ingress_type to respect ClusterIP definition (Marcelo Moreira de Mello) - e37c091 (breaking_change)
- Add ability to get/create/delete secrets for the awx service account (Christian M. Adams) - 61b3cb4
- Added ability to specify annotations to ServiceAccount (Marcelo Moreira de Mello) - 446ac0b
- Do not shadow other variables (Yanis Guenane) - 223fe98
- Do not prepend variables name with tower_ (Yanis Guenane) - 75458d0 (breaking_change)
- Fully remove finalizer (Christian M. Adams) - fd92050
- Use custom pg_dump format for faster restores (Christian M. Adams) - f16d9ac
- Allow user to specify empty string for storage class on PVC (Christian M. Adams) - 818b837
- Unset ownerRefs in the installer instead of the finalizer (Christian M. Adams) - c12a1f0
- Make awx-operator compatible with Ansible 2.12 (Alan Rominger) - 5216489
- Restore: set proper kind var after deploying AWX CR (Julen Landa Alustiza) - fc4687f
- Add support for custom service labels (Jeremy Kimber) - fd42802
- Rename product specific variable names (Christian M. Adams) - 5ae3636 (breaking_change)
- Add watcher for backup CR (Christian M. Adams) - fdcc745
# 0.9.0 (May 1, 2021)
- Update playbook to allow for deploying custom image version/tag (Shane McDonald) - 77e7039
- Mounts /var/lib/awx/projects on awx-web container (Marcelo Moreira de Mello) - f21ec4d
- Extra Settings: Allow one to pass extra API configuration settings. (Yanis Guenane) - 1d14ebc
- PostgreSQL: Properly handle variable name difference when using Red Hat containers (Yanis Guenane) - 2965a90
- Deployment type: Make more fields dynamic based on that field (Yanis Guenane) - 4706aa9
- Add templated EE volume mount var to operator config (Christian M. Adams) - e55d83f
- Add NodePort to tower_ingress_type enum (TheStally) - 96b878f
- Split container image and version in 2 variables (Marcelo Moreira de Mello) - bc34758 (breaking_change)
- Handles deleting and recreating statefulset and deployment when needed (Marcelo Moreira de Mello) - 597356f
Hi there! We're excited to have you as a contributor.
Have questions about this document or anything not covered here? Please file a new at [https://github.com/ansible/awx-operator/issues](https://github.com/ansible/awx-operator/issues).
## Table of contents
* [Things to know prior to submitting code](#things-to-know-prior-to-submitting-code)
* [Submmiting your Work](#submitting-your-work)
* [Testing](#testing)
* [Testing in Docker](#testing-in-docker)
* [Testing in Minikube](#testing-in-minikube)
* [Generating a bundle](#generating-a-bundle)
* [Reporting Issues](#reporting-issues)
## Things to know prior to submitting code
- All code submissions are done through pull requests against the `devel` branch.
- All PRs must have a single commit. Make sure to `squash` any changes into a single commit.
- Take care to make sure no merge commits are in the submission, and use `git rebase` vs `git merge` for this reason.
- If collaborating with someone else on the same branch, consider using `--force-with-lease` instead of `--force`. This will prevent you from accidentally overwriting commits pushed by someone else. For more information, see https://git-scm.com/docs/git-push#git-push---force-with-leaseltrefnamegt
- We ask all of our community members and contributors to adhere to the [Ansible code of conduct](http://docs.ansible.com/ansible/latest/community/code_of_conduct.html). If you have questions, or need assistance, please reach out to our community team at [codeofconduct@ansible.com](mailto:codeofconduct@ansible.com)
## Submmiting your work
1. From your fork `devel` branch, create a new branch to stage your changes.
```sh
#> git checkout -b <branch-name>
```
2. Make your changes.
3. Test your changes according described on the Testing section.
4. If everything looks correct, commit your changes.
```sh
#> git add <FILES>
#> git commit -m "My message here"
```
5. Create your [pull request](https://github.com/ansible/awx-operator/pulls)
**Note**: If you have multiple commits, make sure to `squash` your commits into a single commit which will facilitate our release process.
## Testing
This Operator includes a [Molecule](https://molecule.readthedocs.io/en/stable/)-based test environment, which can be executed standalone in Docker (e.g. in CI or in a single Docker container anywhere), or inside any kind of Kubernetes cluster (e.g. Minikube).
You need to make sure you have Molecule installed before running the following commands. You can install Molecule with:
```sh
#> pip install 'molecule[docker]'
```
Running `molecule test` sets up a clean environment, builds the operator, runs all configured tests on an example operator instance, then tears down the environment (at least in the case of Docker).
If you want to actively develop the operator, use `molecule converge`, which does everything but tear down the environment at the end.
#### Testing in Kind
Testing with a kind cluster is the recommended way to test the awx-operator locally. First, you need to install kind if you haven't already. Please see these docs for setting that up:
* https://kind.sigs.k8s.io/docs/user/quick-start/
To run the tests, from the root of your checkout, run the following command:
```sh
#> molecule test -s kind
```
#### Testing in Minikube
```sh
#> minikube start --memory 8g --cpus 4
#> minikube addons enable ingress
#> molecule test -s test-minikube
```
[Minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/) is a more full-featured test environment running inside a full VM on your computer, with an assigned IP address. This makes it easier to test things like NodePort services and Ingress from outside the Kubernetes cluster (e.g. in a browser on your computer).
Once the operator is deployed, you can visit the AWX UI in your browser by following these steps:
1. Make sure you have an entry like `IP_ADDRESS example-awx.test` in your `/etc/hosts` file. (Get the IP address with `minikube ip`.)
2. Visit `http://example-awx.test/` in your browser. (Default admin login is `test`/`changeme`.)
Alternatively, you can also update the service `awx-service` in your namespace to use the type `NodePort` and use following command to get the URL to access your AWX instance:
```sh
#> minikube service <serviceName> -n <namespaceName> --url
```
## Generating a bundle
> :warning: operator-sdk version 0.19.4 is needed to run the following commands
If one has the Operator Lifecycle Manager (OLM) installed, the following steps is the process to generate the bundle that would nicely display in the OLM interface.
Applying this template will do it. Once the CatalogSource is in a READY state, the bundle should be available on the OperatorHub tab (as part of the custom CatalogSource that just got added)
5. Enjoy
## Reporting Issues
We welcome your feedback, and encourage you to file an issue when you run into a problem.
[](https://docs.ansible.com/ansible/latest/community/code_of_conduct.html)
An [Ansible AWX](https://github.com/ansible/awx) operator for Kubernetes built with [Operator SDK](https://github.com/operator-framework/operator-sdk) and Ansible.
# Table of Contents
<!-- Regenerate this table of contents using https://github.com/ekalinin/github-markdown-toc -->
<!-- gh-md-toc --insert README.md -->
<!--ts-->
* [AWX Operator](#awx-operator)
* [Table of Contents](#table-of-contents)
* [Purpose](#purpose)
* [Usage](#usage)
* [Basic Install](#basic-install)
* [Admin user account configuration](#admin-user-account-configuration)
* [Network and TLS Configuration](#network-and-tls-configuration)
Then create a file named `my-awx.yml` with the following contents:
```yaml
---
apiVersion:awx.ansible.com/v1beta1
kind:AWX
metadata:
name:awx
```
Finally, use `kubectl` to create the awx instance in your cluster:
```bash
#> kubectl apply -f my-awx.yml
```
After a few minutes, the new AWX instance will be deployed. One can look at the operator pod logs in order to know where the installation process is at. This can be done by running the following command: `kubectl logs -f deployments/awx-operator`.
Once deployed, the AWX instance will be accessible at `http://awx.mycompany.com/` (assuming your cluster has an Ingress controller configured).
By default, the admin user is `admin` and the password is available in the `<resourcename>-admin-password` secret. To retrieve the admin password, run `kubectl get secret <resourcename>-admin-password -o jsonpath="{.data.password}" | base64 --decode`
You just completed the most basic install of an AWX instance via this operator. Congratulations !
### Admin user account configuration
There are three variables that are customizable for the admin user account creation.
| tower_admin_user | Name of the admin user | admin |
| tower_admin_email | Email of the admin user | test@example.com |
| tower_admin_password_secret | Secret that contains the admin user password | Empty string |
If `tower_admin_password_secret` is not provided, the operator will look for a secret named `<resourcename>-admin-password` for the admin password. If it is not present, the operator will generate a password and create a Secret from it named `<resourcename>-admin-password`.
To retrieve the admin password, run `kubectl get secret <resourcename>-admin-password -o jsonpath="{.data.password}" | base64 --decode`
The secret that is expected to be passed should be formatted as follow:
```yaml
---
apiVersion:v1
kind:Secret
metadata:
name:<resourcename>-admin-password
namespace:<target namespace>
stringData:
password:mysuperlongpassword
```
### Network and TLS Configuration
#### Ingress Type
By default, the AWX operator is not opinionated and won't force a specific ingress type on you. So, if `tower_ingress_type` is not specified as part of the Custom Resource specification, it will default to `none` and nothing ingress-wise will be created.
The AWX operator provides support for three kinds of `Ingress` to access AWX: `Ingress`, `Route` and `LoadBalancer`, To toggle between these options, you can add the following to your AWX CR:
* Route
```yaml
---
spec:
...
tower_ingress_type:Route
```
* Ingress
```yaml
---
spec:
...
tower_ingress_type:Ingress
tower_hostname:awx.mycompany.com
```
* LoadBalancer
```yaml
---
spec:
...
tower_ingress_type:LoadBalancer
tower_ingress_protocol:http
```
#### TLS Termination
* Route
The following variables are customizable to specify the TLS termination procedure when `Route` is picked as an Ingress
| tower_loadbalancer_protocol | Protocol to use for Loadbalancer ingress | http |
| tower_loadbalancer_port | Port used for Loadbalancer ingress | 80 |
### Database Configuration
#### External PostgreSQL Service
In order for the AWX instance to rely on an external database, the Custom Resource needs to know about the connection details. Those connection details should be stored as a secret and either specified as `tower_postgres_configuration_secret` at the CR spec level, or simply be present on the namespace under the name `<resourcename>-postgres-configuration`.
The secret should be formatted as follows:
```yaml
---
apiVersion:v1
kind:Secret
metadata:
name:<resourcename>-postgres-configuration
namespace:<target namespace>
stringData:
host:<external ip or url resolvable by the cluster>
port:<external port, this usually defaults to 5432>
database:<desired database name>
username:<username to connect as>
password:<password to connect with>
type:Opaque
```
#### Migrating data from an old AWX instance
For instructions on how to migrate from an older version of AWX, see [migration.md](./docs/migration.md).
#### Managed PostgreSQL Service
If you don't have access to an external PostgreSQL service, the AWX operator can deploy one for you along side the AWX instance itself.
The following variables are customizable for the managed PostgreSQL service
| tower_postgres_data_path | PostgreSQL data path | `/var/lib/postgresql/data/pgdata` |
Example of customization could be:
```yaml
---
spec:
...
tower_postgres_resource_requirements:
requests:
memory:2Gi
storage:8Gi
limits:
memory:4Gi
storage:50Gi
tower_postgres_storage_class:fast-ssd
```
**Note**: If `tower_postgres_storage_class` is not defined, Postgres will store it's data on a volume using the default storage class for your cluster.
### Advanced Configuration
#### Deploying a specific version of AWX
There are a few variables that are customizable for awx the image management.
| tower_image | Path of the image to pull | ansible/awx:15.0.0 |
| tower_image_pull_policy | The pull policy to adopt | IfNotPresent |
| tower_image_pull_secret | The pull secret to use | '' |
Example of customization could be:
```yaml
---
spec:
...
tower_image:myorg/my-custom-awx
tower_image_pull_policy:Always
tower_image_pull_secret:pull_secret_name
```
#### Privileged Tasks
Depending on the type of tasks that you'll be running, you may find that you need the task pod to run as `privileged`. This can open yourself up to a variety of security concerns, so you should be aware (and verify that you have the privileges) to do this if necessary. In order to toggle this feature, you can add the following to your custom resource:
```yaml
---
spec:
...
tower_task_privileged:true
```
If you are attempting to do this on an OpenShift cluster, you will need to grant the `awx` ServiceAccount the `privileged` SCC, which can be done with:
Again, this is the most relaxed SCC that is provided by OpenShift, so be sure to familiarize yourself with the security concerns that accompany this action.
#### Containers Resource Requirements
The resource requirements for both, the task and the web containers are configurable - both the lower end (requests) and the upper end (limits).
This Operator includes a [Molecule](https://molecule.readthedocs.io/en/stable/)-based test environment, which can be executed standalone in Docker (e.g. in CI or in a single Docker container anywhere), or inside any kind of Kubernetes cluster (e.g. Minikube).
You need to make sure you have Molecule installed before running the following commands. You can install Molecule with:
```sh
#> pip install 'molecule[docker]'
```
Running `molecule test` sets up a clean environment, builds the operator, runs all configured tests on an example operator instance, then tears down the environment (at least in the case of Docker).
If you want to actively develop the operator, use `molecule converge`, which does everything but tear down the environment at the end.
#### Testing in Docker
```sh
#> molecule test -s test-local
```
This environment is meant for headless testing (e.g. in a CI environment, or when making smaller changes which don't need to be verified through a web interface). It is difficult to test things like AWX's web UI or to connect other applications on your local machine to the services running inside the cluster, since it is inside a Docker container with no static IP address.
#### Testing in Minikube
```sh
#> minikube start --memory 8g --cpus 4
#> minikube addons enable ingress
#> molecule test -s test-minikube
```
[Minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/) is a more full-featured test environment running inside a full VM on your computer, with an assigned IP address. This makes it easier to test things like NodePort services and Ingress from outside the Kubernetes cluster (e.g. in a browser on your computer).
Once the operator is deployed, you can visit the AWX UI in your browser by following these steps:
1. Make sure you have an entry like `IP_ADDRESS example-awx.test` in your `/etc/hosts` file. (Get the IP address with `minikube ip`.)
2. Visit `http://example-awx.test/` in your browser. (Default admin login is `test`/`changeme`.)
Alternatively, you can also update the service `awx-service` in your namespace to use the type `NodePort` and use following command to get the URL to access your AWX instance:
```sh
#> minikube service <serviceName> -n <namespaceName> --url
The first step is to create a draft release. Typically this will happen in the [Stage Release](https://github.com/ansible/awx/blob/devel/.github/workflows/stage.yml) workflow for AWX and you don't need to do it as a separate step.
1. The Docker image which powers AWX Operator.
2. The `awx-operator.yaml` Kubernetes manifest file which initially deploys the Operator into a cluster.
If you need to do an independent release of the operator, you can run the [Stage Release](https://github.com/ansible/awx-operator/blob/devel/.github/workflows/stage.yml) in the awx-operator repo. Both of these workflows will run smoke tests, so there is no need to do this manually.
Each of these must be appropriately built in preparation for a new tag:
After the draft release is created, publish it and the [Promote AWX Operator image](https://github.com/ansible/awx-operator/blob/devel/.github/workflows/promote.yaml) will run, which will:
If everything works, commit the updated version, then tag a new repository release with the same tag as the Docker image pushed earlier.
- Publish image to Quay
- Release Helm chart
## Author
This operator was originally built in 2019 by [Jeff Geerling](https://www.jeffgeerling.com) and is now maintained by the Ansible Team
## Code of Conduct
We ask all of our community members and contributors to adhere to the [Ansible code of conduct](http://docs.ansible.com/ansible/latest/community/code_of_conduct.html). If you have questions or need assistance, please reach out to our community team at [codeofconduct@ansible.com](mailto:codeofconduct@ansible.com)
## Get Involved
We welcome your feedback and ideas. The AWX operator uses the same mailing list and IRC channel as AWX itself. Here's how to reach us with feedback and questions:
- Join the [Ansible AWX channel on Matrix](https://matrix.to/#/#awx:ansible.com)
- Join the [Ansible Community Forum](https://forum.ansible.com)
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.