Chapter 6. Configuring automation hub on Red Hat OpenShift Container Platform web console
You can use these instructions to configure the automation hub operator on Red Hat OpenShift Container Platform, specify custom resources, and deploy Ansible Automation Platform with an external database.
Automation hub configuration can be done through the automation hub pulp_settings or directly in the user interface after deployment. However, it is important to note that configurations made in pulp_settings take precedence over settings made in the user interface. Hub settings should always be set as lowercase on the Hub custom resource specification.
When an instance of automation hub is removed, the PVCs are not automatically deleted. This can cause issues during migration if the new deployment has the same name as the previous one. Therefore, it is recommended that you manually remove old PVCs before deploying a new automation hub instance in the same namespace. See Finding and deleting PVCs for more information.
6.1. Prerequisites
- You have installed the Ansible Automation Platform Operator in Operator Hub.
6.1.1. Storage options for Ansible Automation Platform Operator installation on Red Hat OpenShift Container Platform
Automation hub requires ReadWriteMany
file-based storage, Azure Blob storage, or Amazon S3-compliant storage for operation so that multiple pods can access shared content, such as collections.
The process for configuring object storage on the AutomationHub
CR is similar for Amazon S3 and Azure Blob Storage.
If you are using file-based storage and your installation scenario includes automation hub, ensure that the storage option for Ansible Automation Platform Operator is set to ReadWriteMany
. ReadWriteMany
is the default storage option.
In addition, OpenShift Data Foundation provides a ReadWriteMany
or S3-compliant implementation. Also, you can set up NFS storage configuration to support ReadWriteMany
. This, however, introduces the NFS server as a potential, single point of failure.
Additional resources
- Persistent storage using NFS in the OpenShift Container Platform Storage guide
- IBM’s How do I create a storage class for NFS dynamic storage provisioning in an OpenShift environment?
6.1.1.1. Provisioning OCP storage with ReadWriteMany
access mode
To ensure successful installation of Ansible Automation Platform Operator, you must provision your storage type for automation hub initially to ReadWriteMany
access mode.
Procedure
-
Go to
. - Click btn: Create PersistentVolume.
In the first step, update the
accessModes
from the defaultReadWriteOnce
toReadWriteMany
.- See Provisioning to update the access mode. for a detailed overview.
- Complete the additional steps in this section to create the persistent volume claim (PVC).
6.1.1.2. Configuring object storage on Amazon S3
Red Hat supports Amazon Simple Storage Service (S3) for automation hub. You can configure it when deploying the AutomationHub
custom resource (CR), or you can configure it for an existing instance.
Prerequisites
- Create an Amazon S3 bucket to store the objects.
- Note the name of the S3 bucket.
Procedure
Create a Kubernetes secret containing the AWS credentials and connection details, and the name of your Amazon S3 bucket. The following example creates a secret called
test-s3
:$ oc -n $HUB_NAMESPACE apply -f- <<EOF apiVersion: v1 kind: Secret metadata: name: 'test-s3' stringData: s3-access-key-id: $S3_ACCESS_KEY_ID s3-secret-access-key: $S3_SECRET_ACCESS_KEY s3-bucket-name: $S3_BUCKET_NAME s3-region: $S3_REGION EOF
Add the secret to the automation hub custom resource (CR)
spec
:spec: object_storage_s3_secret: test-s3
-
If you are applying this secret to an existing instance, restart the API pods for the change to take effect.
<hub-name>
is the name of your hub instance.
$ oc -n $HUB_NAMESPACE delete pod -l app.kubernetes.io/name=<hub-name>-api
6.1.1.3. Configuring object storage on Azure Blob
Red Hat supports Azure Blob Storage for automation hub. You can configure it when deploying the AutomationHub
custom resource (CR), or you can configure it for an existing instance.
Prerequisites
- Create an Azure Storage blob container to store the objects.
- Note the name of the blob container.
Procedure
Create a Kubernetes secret containing the credentials and connection details for your Azure account, and the name of your Azure Storage blob container. The following example creates a secret called
test-azure
:$ oc -n $HUB_NAMESPACE apply -f- <<EOF apiVersion: v1 kind: Secret metadata: name: 'test-azure' stringData: azure-account-name: $AZURE_ACCOUNT_NAME azure-account-key: $AZURE_ACCOUNT_KEY azure-container: $AZURE_CONTAINER azure-container-path: $AZURE_CONTAINER_PATH azure-connection-string: $AZURE_CONNECTION_STRING EOF
Add the secret to the automation hub custom resource (CR)
spec
:spec: object_storage_azure_secret: test-azure
-
If you are applying this secret to an existing instance, restart the API pods for the change to take effect.
<hub-name>
is the name of your hub instance.
$ oc -n $HUB_NAMESPACE delete pod -l app.kubernetes.io/name=<hub-name>-api
6.1.2. Configure your automation hub operator route options
The Red Hat Ansible Automation Platform operator installation form allows you to further configure your automation hub operator route options under Advanced configuration.
Procedure
- Log in to Red Hat OpenShift Container Platform.
-
Navigate to
. - Select your Ansible Automation Platform Operator deployment.
- Select the Automation Hub tab.
For new instances, click
.- For existing instances, you can edit the YAML view by clicking the ⋮ icon and then .
- Click .
- Under Ingress type, click the drop-down menu and select Route.
- Under Route DNS host, enter a common host name that the route answers to.
- Under Route TLS termination mechanism, click the drop-down menu and select Edge or Passthrough.
- Under Route TLS credential secret, click the drop-down menu and select a secret from the list.
6.1.3. Configuring the ingress type for your automation hub operator
The Ansible Automation Platform Operator installation form allows you to further configure your automation hub operator ingress under Advanced configuration.
Procedure
- Log in to Red Hat OpenShift Container Platform.
-
Navigate to
. - Select your Ansible Automation Platform Operator deployment.
- Select the Automation Hub tab.
For new instances, click
.- For existing instances, you can edit the YAML view by clicking the ⋮ icon and then .
- Click .
- Under Ingress type, click the drop-down menu and select Ingress.
- Under Ingress annotations, enter any annotations to add to the ingress.
- Under Ingress TLS secret, click the drop-down menu and select a secret from the list.
After you have configured your automation hub operator, click
at the bottom of the form view. Red Hat OpenShift Container Platform will now create the pods. This may take a few minutes.
You can view the progress by navigating to
Verification
Verify that the following operator pods provided by the Ansible Automation Platform Operator installation from automation hub are running:
Operator manager controllers | automation controller | automation hub |
---|---|---|
The operator manager controllers for each of the 3 operators, include the following:
| After deploying automation controller, you will see the addition of these pods:
| After deploying automation hub, you will see the addition of these pods:
|
A missing pod can indicate the need for a pull secret. Pull secrets are required for protected or private image registries. See Using image pull secrets for more information. You can diagnose this issue further by running oc describe pod <pod-name>
to see if there is an ImagePullBackOff error on that pod.
6.2. Configuring LDAP authentication for Ansible automation hub on OpenShift Container Platform
Configure LDAP authentication settings for Ansible Automation Platform on OpenShift Container Platform in the spec section of your Hub instance configuration file.
Procedure
Use the following example to configure LDAP in your automation hub instance. For any blank fields, enter
``
.spec: pulp_settings: auth_ldap_user_attr_map: email: "mail" first_name: "givenName" last_name: "sn" auth_ldap_group_search_base_dn: 'cn=groups,cn=accounts,dc=example,dc=com' auth_ldap_bind_dn: ' ' auth_ldap_bind_password: ' ' auth_ldap_group_search_filter: (objectClass=posixGroup) auth_ldap_user_search_scope: SUBTREE auth_ldap_server_uri: 'ldap://ldapserver:389' authentication_backend_preset: ldap auth_ldap_mirror_groups: 'True' auth_ldap_user_search_base_dn: 'cn=users,cn=accounts,dc=example,dc=com' auth_ldap_bind_password: 'ldappassword' auth_ldap_user_search_filter: (uid=%(user)s) auth_ldap_group_search_scope: SUBTREE auth_ldap_user_flags_by_group: '@json {"is_superuser": "cn=tower-admin,cn=groups,cn=accounts,dc=example,dc=com"}'
Do not leave any fields empty. For fields with no variable, enter ``
to indicate a default value.
6.3. Finding the automation hub route
You can access the automation hub through the platform gateway or through the following procedure.
Procedure
- Log into Red Hat OpenShift Container Platform.
-
Navigate to
. - Under Location, click on the URL for your automation hub instance.
The automation hub user interface launches where you can sign in with the administrator credentials specified during the operator configuration process.
If you did not specify an administrator password during configuration, one was automatically created for you. To locate this password, go to your project, select
6.4. Configuring an external database for automation hub on Red Hat Ansible Automation Platform Operator
For users who prefer to deploy Ansible Automation Platform with an external database, they can do so by configuring a secret with instance credentials and connection information, then applying it to their cluster using the oc create
command.
By default, the Ansible Automation Platform Operator automatically creates and configures a managed PostgreSQL pod in the same namespace as your Ansible Automation Platform deployment.
You can choose to use an external database instead if you prefer to use a dedicated node to ensure dedicated resources or to manually manage backups, upgrades, or performance tweaks.
The same external database (PostgreSQL instance) can be used for both automation hub and automation controller as long as the database names are different. In other words, you can have multiple databases with different names inside a single PostgreSQL instance.
The following section outlines the steps to configure an external database for your automation hub on a Ansible Automation Platform Operator.
Prerequisite
The external database must be a PostgreSQL database that is the version supported by the current release of Ansible Automation Platform.
Ansible Automation Platform 2.5 supports PostgreSQL 15.
Procedure
The external postgres instance credentials and connection information will need to be stored in a secret, which will then be set on the automation hub spec.
Create a
postgres_configuration_secret
YAML file, following the template below:apiVersion: v1 kind: Secret metadata: name: external-postgres-configuration namespace: <target_namespace> 1 stringData: host: "<external_ip_or_url_resolvable_by_the_cluster>" 2 port: "<external_port>" 3 database: "<desired_database_name>" username: "<username_to_connect_as>" password: "<password_to_connect_with>" 4 sslmode: "prefer" 5 type: "unmanaged" type: Opaque
- 1
- Namespace to create the secret in. This should be the same namespace you want to deploy to.
- 2
- The resolvable hostname for your database node.
- 3
- External port defaults to
5432
. - 4
- Value for variable
password
should not contain single or double quotes (', ") or backslashes (\) to avoid any issues during deployment, backup or restoration. - 5
- The variable
sslmode
is valid forexternal
databases only. The allowed values are:prefer
,disable
,allow
,require
,verify-ca
, andverify-full
.
Apply
external-postgres-configuration-secret.yml
to your cluster using theoc create
command.$ oc create -f external-postgres-configuration-secret.yml
When creating your
AutomationHub
custom resource object, specify the secret on your spec, following the example below:apiVersion: automationhub.ansible.com/v1beta1 kind: AutomationHub metadata: name: hub-dev spec: postgres_configuration_secret: external-postgres-configuration
6.4.1. Enabling the hstore extension for the automation hub PostgreSQL database
Added in Ansible Automation Platform 2.5, the database migration script uses hstore
fields to store information, therefore the hstore
extension to the automation hub PostgreSQL database must be enabled.
This process is automatic when using the Ansible Automation Platform installer and a managed PostgreSQL server.
If the PostgreSQL database is external, you must enable the hstore
extension to the automation hub PostreSQL database manually before automation hub installation.
If the hstore
extension is not enabled before automation hub installation, a failure is raised during database migration.
Procedure
Check if the extension is available on the PostgreSQL server (automation hub database).
$ psql -d <automation hub database> -c "SELECT * FROM pg_available_extensions WHERE name='hstore'"
Where the default value for
<automation hub database>
isautomationhub
.Example output with
hstore
available:name | default_version | installed_version |comment ------+-----------------+-------------------+--------------------------------------------------- hstore | 1.7 | | data type for storing sets of (key, value) pairs (1 row)
Example output with
hstore
not available:name | default_version | installed_version | comment ------+-----------------+-------------------+--------- (0 rows)
On a RHEL based server, the
hstore
extension is included in thepostgresql-contrib
RPM package, which is not installed automatically when installing the PostgreSQL server RPM package.To install the RPM package, use the following command:
dnf install postgresql-contrib
Create the
hstore
PostgreSQL extension on the automation hub database with the following command:$ psql -d <automation hub database> -c "CREATE EXTENSION hstore;"
The output of which is:
CREATE EXTENSION
In the following output, the
installed_version
field contains thehstore
extension used, indicating thathstore
is enabled.name | default_version | installed_version | comment -----+-----------------+-------------------+------------------------------------------------------ hstore | 1.7 | 1.7 | data type for storing sets of (key, value) pairs (1 row)
6.5. Finding and deleting PVCs
A persistent volume claim (PVC) is a storage volume used to store data that automation hub and automation controller applications use. These PVCs are independent from the applications and remain even when the application is deleted. If you are confident that you no longer need a PVC, or have backed it up elsewhere, you can manually delete them.
Procedure
List the existing PVCs in your deployment namespace:
oc get pvc -n <namespace>
- Identify the PVC associated with your previous deployment by comparing the old deployment name and the PVC name.
Delete the old PVC:
oc delete pvc -n <namespace> <pvc-name>
6.6. Additional configurations
A collection download count can help you understand collection usage. To add a collection download count to automation hub, set the following configuration:
spec: pulp_settings: ansible_collect_download_count: true
When ansible_collect_download_count
is enabled, automation hub will display a download count by the collection.
6.7. Additional resources
- For more information on running operators on OpenShift Container Platform, navigate to the OpenShift Container Platform product documentation and click the Operators - Working with Operators in OpenShift Container Platform guide.