Default structure
The default directory structure is the same as (if you read my 2.4 solution) the 2.4 structure, just the contents is different.
.
├── ansibe.cfg
├── collections
│ └── requirements.yml
├── group_vars
│ ├── all
│ │ └── yml-files
│ ├── dev
│ │ └── yml-files
│ └── prod
│ └── yml-files
├── host_vars
│ └── aap_dev
│ ├── aap_auth.yaml
│ └── aap_dev.yaml
├── inventory.yaml
├── main.yml
├── README.md
└── workarounds.yml
Shown above is the global structure of a repository in git that will hold my configuration.
It holds some files and directories that contain certain data structures and will be explained later.
You'll see 3 directories under group_vars that resemble an inventory, and this is a correct assumption. It looks like an inventory, but not as we know it.
The group_vars now consists of 2 environments 'dev' and 'prod'. In the host_vars the prod is missing, this is intentional during development, so I can't target production even by accident.
This will be added once development has ended.
This is one repository with configurationas code for rhaap2.5, eventually there will be 3 repositories with base code and a extra repository for each team/organization that is enabled in rhaap2.5.
As this is a gitlab repository using a pipeline, something you don't see here, is the .gitlab-ci.yml, the pipeline is configured elsewhere as a security feature. This will be explaned also at a later time.
Default files
The files that will be present in all repositories are:
ansible.cfg
This is the part of the ansible.cfg where you have defined the repositories to download your collections from while executing the pipeline to apply the configuration. Be advised that this must also be availlable in a recovery situation!
collections/requirements.yml
This file specifies the collections you need to execute this canfiguration, keep the number of collection as low as possible here, as downloading costs time in recovery.
When your pipeline is on docker/kubernetes or openshift, you can create an image to run this pipeline, that includes all collections you need, inthat case these files can be deleted.
inventory.yml
Is exactly what you think it is, an inventory for the pipeline.
main.yml
This is where the magic happens a ansible playbook that harnesses the configurationas code and applies all tricks to make it functional.
README.md
As all repositories, this one needs a readme of what is in here and what it does and how.
workarounds.yml
In this file the default dispatcher configuration of the infra.aap_configuration collection is overruled (the order was alphabeticly ) and not in the correct execution order.
for each of the configuration types, the content will be somewhat different. At least until all bugs are fixed in the community collections.
Until now nothing shocking, easy to follow.
This will change