Base configuration for Automation Platform
Before we can use the just installed automation platform 2.6, we need some configuration to be present.
We could just login as the admin user and start clicking, but do you want to do this in the middle of the night, in case of a crash?
I think not.
To load the initial configuration in Automation Platform, we need the following files:
gateway_applications.yml
gateway_authenticator_maps.yml
gateway_authenticators.yml
gateway_http_ports.yml
gateway_organizations.yml
gateway_role_team_assignments.yml
gateway_role_user_assignments.yml
gateway_routes.yml
gateway_service_clusters.yml
gateway_service_keys.yml
gateway_service_nodes.yml
gateway_services.yml
gateway_settings.yml
gateway_teams.yml
gateway_users.yml
hub_collection_remotes.yml
hub_collection_repositories.yml
hub_collections.yml
hub_ee_images.yml
hub_ee_registries.yml
hub_ee_repositories.yml
hub_namespaces.yml
controller_credentials_input_sources.yml
controller_credential_types.yml
controller_credentials.yml
controller_execution_environments.yml
controller_hosts.yml
controller_instance_groups.yml
controller_inventory.yml
controller_inventory_sources.yml
controller_labels.yml
controller_notification_templates.yml
controller_organization.yml
controller_projects.yml
controller_roles.yml
controller_schedules.yml
controller_settings.yml
controller_templates.yml
controller_workflows.yml
You'll see that the files are named gateway..., hub... or controller... this is ofcourse a dead giveaway of whats in there.
For the contents of each of these files, you can refer to the documentation on github for the infra.aap_configuration project. The documentation of the parameters can be found in the roles documentation of each role.
I will explain each file as we progress on our configuration journey.
First we wil look back on the directory structure we have shown you before, but only the part we need at the moment:
.
├── group_vars
│ ├── all
│ │ └── yml-files
│ ├── dev
│ │ └── yml-files
│ └── prod
│ └── yml-files
The files we see above are placed in each of the group_vars directories, so each directory will hold the same filenames (content is different!).
All files need to be present, or else the code will not work.
As you see, the group_vars looks like an inventory, and it basically is, but the thing with inventories is, they tend to overwrite variables.
This is not what we want, so the content of the files is slightly different, so the vaiables aren't overidden. I hear you asking why and I will tell you.
We don't want to define things twice, ever.
So if we define things in "ALL" we want to be present in all of our environments, but if this where an inventory, as soon as we define somenthing in the same file in dev, we must copy all contents from the "ALL" file to dev AND prod. So that doubles our maintenance for that file.
If we slightly differ the variable names in the files and let the code merge the variables, then the all is still all and merges with the correct environment.
Less copying, less maintenance and easy management.
This is the essence of the configurationas code as I built it.
All code is tested on the homelab, described here Lab_on_Proxmox.
Not all services of the Automation Platform will be configured, only those we need to make it functional.
Once you have mastered this, you can figure the rest out.
Adding the first file
We start by adding the first file to the shown structure and configure the values in them, if needed. The first file on the file_list is "gateway_applications.yml'. The structure is now as seen below:
.
├── group_vars
│ ├── all
│ │ └── gateway_applications.yml
│ ├── dev
│ │ └── gateway_applications.yml
│ └── prod
│ └── gateway_applications.yml
Now we will show you the content of each file:
group_vars/all/gateway_applications.yml
As we do not configure extra application in rhaap, this file is an empty set.
---
aap_applications_all: []
# - name: "gateway Config Default Application"
# description: "Generic application, which can be used for oauth tokens"
# organization: "Default"
# state: "present"
# client_type: "confidential"
# authorization_grant_type: "password"
...
But you can already see that the variable name used here has the "_all" extension, so the variable will not be overridden as this is not quite a inventory.
Why we do this, will become clear in a moment.
group_vars/dev/gateway_applications.yml
As we do not configure extra application in rhaap, this file is an empty set.
---
aap_applications_dev: []
# - name: "gateway Config Default Application"
# description: "Generic application, which can be used for oauth tokens"
# organization: "Default"
# state: "present"
# client_type: "confidential"
# authorization_grant_type: "password"
...
Here the variable has the "_dev" extension, so the variable will not be overridden.
group_vars/prod/gateway_applications.yml
As we do not configure extra application in rhaap, this file is an empty set.
---
aap_applications_prod: []
# - name: "gateway Config Default Application"
# description: "Generic application, which can be used for oauth tokens"
# organization: "Default"
# state: "present"
# client_type: "confidential"
# authorization_grant_type: "password"
...
Here the variable has the "_dev" extension, so the variable will not be overridden.
Variable handling
When we run our playbook to start the configuration for the "dev" environment, the play wil have the following variables availllable form the above "inventory":
- gateway_applications_all
- gateway_applications_dev
The collection infra.aap_configuration does not know of these variables and will not even try to confgure the rhaap2.5 environment.
So how do we get the correct variable to feed to the collection? What we don't want is to write everything twice or more. So wel will everything that must exist in all environments into the "..._all" variable and only the specific items for dev in the "..._dev" variable.
Then if we merge the 2 variables into the gateway_applications variable, before we call the infra collection, all will beconfigured correctly.
How we do this exactly, we will axplain later, first we will add and confugre more files.
More files
gateway_authenticator_maps.yml
gateway_authenticators.yml
gateway_http_ports.yml
gateway_organizations.yml
gateway_role_team_assignments.yml
gateway_role_user_assignments.yml
gateway_routes.yml
gateway_service_clusters.yml
gateway_service_keys.yml
gateway_service_nodes.yml
gateway_services.yml
gateway_settings.yml
gateway_teams.yml
gateway_users.yml
hub_collection_remotes.yml
hub_collection_repositories.yml
hub_collections.yml
hub_ee_images.yml
hub_ee_registries.yml
hub_ee_repositories.yml
hub_namespaces.yml
controller_credentials_input_sources.yml
controller_credential_types.yml
controller_credentials.yml
controller_execution_environments.yml
controller_hosts.yml
controller_instance_groups.yml
controller_inventory.yml
controller_inventory_sources.yml
controller_labels.yml
controller_license.yml
controller_notification_templates.yml
controller_organization.yml
controller_projects.yml
controller_roles.yml
controller_schedules.yml
controller_settings.yml
controller_templates.yml
controller_workflows.yml
All files must be configured, before you can run any pipeline code or it wil break.
If you did all the above, follow me to the code..
The code in the repository
As we created the directory structure to hold the configuration files we dicussed above this, we need to add the host_vars directories.
It may be obvious what goed in there, but anyway..
We expand the structure above with the following structure and start filling in the files to make things functional.
── host_vars
│ ├── aap_dev
│ │ ├── aap_auth.yml
│ │ └── aap_dev.yml
│ └── aap_prod
│ ├── aap_auth.yml
│ └── aap_prod.yml
├── inventory.yaml
└── main.yml
host_vars/aap_dev/aap_auth.yml
In this file we place the authentication variables to be able to login to the freshly installed rhaap (so it will be the admin account).
---
ah_hostname: 'https://rhaap26.homelab'
ah_validate_certs: false
ah_username: admin
ah_password: !vault |
$ANSIBLE_VAULT;1.1;AES256
62376235356630323466653639303235366562393632613031303630643564656535306264633634
3133616538333963663961656631326164343534366538630a623665663764373838383838333335
64386531356335303439643132663561383166656166613232323537336565323562633765363435
3063343531383132650a613834653466623166656264393731366262616661353562336330373437
3963
aap_hostname: 'https://rhaap26.homelab'
aap_validate_certs: false
aap_username: admin
aap_password: !vault |
$ANSIBLE_VAULT;1.1;AES256
62376235356630323466653639303235366562393632613031303630643564656535306264633634
3133616538333963663961656631326164343534366538630a623665663764373838383838333335
64386531356335303439643132663561383166656166613232323537336565323562633765363435
3063343531383132650a613834653466623166656264393731366262616661353562336330373437
3963
cloud_token: '<your_cloud_token_here>' # noqa: yaml[line-length]
cfg_hostname: rhaap26.homelab
cfg_password: !vault |
$ANSIBLE_VAULT;1.1;AES256
562376235356630323466653639303235366562393632613031303630643564656535306264633634
31583016538333963663961656631326164343534366538630a623665663764373838383838333335
643865361356335303439643132663561383166656166613232323537336565323562633765363435
30633435531383132650a613834653466623166656264393731366262616661353562336330373437
3963
You may have read that the cloud_token is defined elsewhere... here it is.. just once per environment The cfg_hostname is for the main.yml playbook, to define the host to write the ansible.cfg to. The cfg_password is the password of the user defined to write the ansible.cfg (in my case 'ansible')
host_vars/aap_dev/aap_dev.yml
Some vars for the collections to make things run smooth.
Added the url to the manifest here, this is the manifest that the playbook will download and install.
---
hostname: localhost
aap_configuration_async_retries: 50
aap_configuration_async_delay: 5
aap_request_timeout: 60
manifest_url: "http://<webserver_url>/manifest_rhaap.zip"
...
The production branch of the host_vars holds the same files, with other values, siutable for the production environment.
inventory.yml
This file is important, but so simple.. just copy this:
---
dev:
hosts: aap_dev
prod:
hosts: aap_prod
workaround.yml
As we are near to configuring the first part of rhaap 2.5, we need to explain what we did to the collections to be able to map the user roles on organization name, istead of the object_id.
Read on here:
Hacking infra.aap_configuration.dispatch
the real code main.yml
The file main.yml is almost the same in every repository for configuration as code. Just the variables vary.
The only exeption is the one here, it must adapt for the workaround.