Since Red Hat Ansible Automation Platform 2.5 this project is focussing on the containerized installation method and utilizing the infra.aap_configuration to apply the Configuration as Code principal. This approach also allowed to retire some old code and reduce complexity.
The high level flow can be seen as three loosely coupled phases.
The Playbook caap-install.yml in the playbook-caap acts as a wrapper and starts the necessary Playbooks in the correct order.
caap-instance: creates a virtual machine or cloud instance on which AAP will be installed. Can be skipped if existing VMs or instances are used.
caap-setup: performs the installation of the containerized version of the Red Hat Ansible Automation Platform.
caap-postinstall: this will apply the basic configuration and create job templates for all use cases.
NOTE: Make sure to set the environment variables to access the cloud provider or virtual infrastructure AND the credentials to connect and authenticate with the Ansible Automation Platform, before running any of these playbooks.
The caap-postinstall Playbook will clone the git repository configuration-platform which contains the basic configuration.
global settings, for example session time outs
minimum organizations, teams and users
basic RBAC settings
Job Templates for each use case - follow the naming convention “Use Case - XYZ”
NOTE: If global configuration changes are modified in the configuration-platform repository, rerunning the caap-postinstall playbook will apply all these changes. However, make sure to not forget applying the environment variables before running caap-postinstall.
Each use case has a corresponding repository following the naming convention use-case-XYZ. Use cases are free to apply any additional configuration, but should not override or change settings from the configuration-platform.
In some cases, use cases can depend on each other. For example, the use-case-multicloud will automatically apply use-case-cloud-aws, use-case-cloud-azure and use-case-cloud-gcp. This is done by cloning the respective repsitories before applying all configurations at once.
NOTE: If during development a use case is changed, you should be able to just rerun the corresponding Job Template to apply the latest changes. For example, in the above example, if you rerun Use Case - Multicloud all changes in the repositories will be applied.
This is defined by the content of the use case. For example the cloud use cases creates job templates and workflows allowing the use to demonstrate Ansible’s multi cloud capabilities. This is completely up to the use case developer and can vary widely.
Check the use cases section for more details.