Day-0: Deploy the SUPERADMIN organization

Once all the objects are already configured at the GitLab repository, they can be deployed for the first time into the target Automation Controller.

1. Create the objects in the Controller

One important thing to remember is to add the public key part of the private key configured at orgs_vars/${SUPERADMIN_ORG}/env/dev/controller_credentials.d/controller_credentials_scm.yml to the GitLab repositories used by the configured projects. See the (dev) Source Control Manager and GitLab API Token Credentials will let the Job Templates to connect to the GitLab repository/group 021-initial-dir-and-files.adoc#_source_control_manager_and_gitlab_api_token_credentials_will_let_the_job_templates_to_connect_to_the_gitlab_repositorygroup

Make sure that the required environment variables are properly set. See the Export all the variables to be used in the next steps

Run the configuration playbook to create the defined objects in the target AAP Controllers, for both DEV and PRO environments, running the following commands:

ansible-navigator run casc_ctrl_config.yml -i inventory -l dev -e "{orgs: ${SUPERADMIN_ORG}, dir_orgs_vars: orgs_vars, env: dev}" -m stdout --eei quay.io/automationiberia/aap/ee-casc:latest --vault-password-file .vault_password --pull-arguments=--tls-verify=false
ansible-navigator run casc_ctrl_config.yml -i inventory -l pro -e "{orgs: ${SUPERADMIN_ORG}, dir_orgs_vars: orgs_vars, env: pro}" -m stdout --eei quay.io/automationiberia/aap/ee-casc:latest --vault-password-file .vault_password --pull-arguments=--tls-verify=false

The following requirements must be taken in consideration:

  • ansible-navigator command must be available to run the playbook

  • An Execution Environment with all the required collections must exist and be available to be pulled and used:

    See the requirements.yaml contents
    ---
    collections:
      - name: infra.controller_configuration
      - name: automationiberia.casc_setup
    ...
  • The target AAP Controller must be available when running the previous command

  • The file .vault_password used in the previous command, must exist and contain the vault password needed to access the vaulted variables

The file inventory must be filled accordingly to the corresponding group_vars configuration file to reach the correct Automation Controller instance

2. Configure the GitLab Webhooks

Once the objects has been created at the Ansible Automation Controller, there are two options to configure the GitLab Webhook to run the Continuous Integration for the CasC:

2.1. Dev environment

  • Automatically

  • Manually

A Job Template and a Project have been created to automatically configure the GitLab Webhook making use of the GitLab API Token credential defined and vaulted in the configuration files (take a look at orgs_vars/${SUPERADMIN_ORG}/env/dev/controller_credentials.d/controller_credentials_gitlab_api_token.yml):

Launch the Job Template called {{ orgs }} dev Gitlab Webhook Creation:

configure webhook launch dev
Figure 1. Configure Webhook Launch

Configure the following webhook trigger parameters for the dev environment:

configure webhook launch params dev.1
Figure 2. Configure Webhook Trigger Parameters
configure webhook launch params dev.2
Figure 3. Configure Webhook Params

The parameter (Workflow) Job Template Name is something similar to:

<ORGNAME> dev CasC Ctrl CD Webhook Trigger

After running the Job, the webhook will already be configured at the git repository for the specified organization, which will point to the selected Job Template in the selected Automation Controller.

configure webhook result dev
Figure 4. Configure Webhook Result

Following steps must be performed to configure the GitLab Webhook to run the Continuous Integration for the CasC in the specified organization:

  1. Get the id number of the Job Template which will receive the webhook calls:

    configure webhook get config dev
    Figure 5. Configure Webhook Get Config

    The Url displayed in the (Workflow) Job Template configuration is using the ID to identify the (Workflow) Job Template, but it’s not recommended to use this identifier, as it can change if the configuration is applied to different AAP instances. Instead, the named_url from the API may be used.

    configure webhook named url dev
    Figure 6. Configure Webhook Named URL
  2. Set the webhook information at the GitLab repository:

    configure webhook set info dev
    Figure 7. Configure webhook Set Info

2.2. Pro environment

  • Automatically

  • Manually

A Job Template and a Project have been created to automatically configure the GitLab Webhook making use of the GitLab API Token credential defined and vaulted in the configuration files (take a look at [orgs_vars/${SUPERADMIN_ORG}/env/pro/controller_credentials.d/controller_credentials_gitlab_api_token.yml](orgs_vars/superadmin/env/pro/controller_credentials.d/controller_credentials_gitlab_api_token.yml)):

Launch the Job Template called {{ orgs }} pro Gitlab Webhook Creation:

configure webhook launch pro
Figure 8. Configure Webhook Launch

Configure the following webhook trigger parameters for the dev environment:

configure webhook launch params pro.1
Figure 9. Configure Webhook Trigger Parameters
configure webhook launch params pro.2
Figure 10. Configure Webhook Params

The parameter (Workflow) Job Template Name is something similar to:

<ORGNAME> pro CasC Ctrl CD Webhook Trigger

After running the Job, the webhook will already be configured at the git repository for the specified organization, which will point to the selected Job Template in the selected Automation Controller.

configure webhook result pro
Figure 11. Configure Webhook Result

Following steps must be performed to configure the GitLab Webhook to run the Continuous Integration for the CasC in the specified organization:

  1. Get the id number of the Job Template which will receive the webhook calls:

    configure webhook get config pro
    Figure 12. Configure Webhook Get Config

    The Url displayed in the (Workflow) Job Template configuration is using the ID to identify the (Workflow) Job Template, but it’s not recommended to use this identifier, as it can change if the configuration is applied to different AAP instances. Instead, the named_url from the API may be used.

    configure webhook named url pro
    Figure 13. Configure Webhook Named URL
  2. Set the webhook information at the GitLab repository:

    configure webhook set info pro
    Figure 14. Configure webhook Set Info

3. All done

Now, all the initial configuration is done and from that moment, only pushing new commits to the dev branch will create or update all the objects at the Automation Controller.

Follow with the Day-2: Create a new Organization steps to create normal organizations.