Configure resources with Ansible (mandatory)

This is an advanced lab, so we don’t really want you to use the web UI for everything. To fully embrace automation and adopt the infrastructure as code (IaC) and Configuration as Code (CaC) methodology, we want to use Ansible to configure our automation platform.

Since the automation platform is exposing all of its functionality via REST API, we can automate everything. Instead of using the API directly, it is highly recommended to use the Ansible Collections to setup, configure and maintain your Red Hat Ansible Automation Platform using Ansible.

Before we jump into the details, let’s have a quick overview of the currently available collections and how they rely on each other.

  • ansible.controller — Ansible collection for interacting with Red Hat Ansible Automation Platform via playbooks.

  • ansible.eda — Event source plugins, event filters, and example rulebooks for ansible-rulebook.

  • ansible.hub — Ansible collection for interacting with Ansible Automation Hub via playbooks.

  • ansible.platform — Modules to automate creating resources on Ansible Automation Platform.

The Scenario

For the next chapters we need a number of resources configured in AAP:

  • Static Inventory with two hosts

  • Credentials

  • Some Projects

  • A number of Job Templates

This would involve a lot of error prone clicking in the web UI, so you’ll use the pro way: a playbook was prepared upfront to save time, but you will still learn how to use Ansible to configure the Automation Execution part of AAP.

Authentication

The Ansible modules we use in the playbook need to talk to AAP and require authentication, of course. There are a number of ways to accomplish this, you could e.g. set the URL/user name/password as environment variables.

In this lab we use a little trick to save time and make it less error prone. We set the credentials and other values directly in the .ansible-navigator.yml file in your home directory, so ansible-navigator will pick them up with every run. Have a look for yourself in your terminal (how to access a terminal is described here) on the bastion host:

cat ~/.ansible-navigator.yml

The result should look like this:

.ansible-navigator.yml
---
ansible-navigator:
  execution-environment:
    image: "MYHUB.apps.ocpvdev01.rhdp.net/ee-supported-rhel9:latest"
    enabled: true
    container-engine: podman
    pull:
      policy: missing
    volume-mounts:
       - {dest: /etc/ansible/, src: /etc/ansible/}
    environment-variables:
      pass:
        - GUID
      set:
        CONTROLLER_HOST: "https://MYCTLHOST.apps.ocpvdev01.rhdp.net"
        CONTROLLER_PASSWORD: "MYCTLPASSWORD"
        CONTROLLER_USERNAME: "MYCTLUSER"
        CONTROLLER_VERIFY_SSL: "False"

The environment variables prefixed with CONTROLLER_ are the connection and credential parameters.

For your convenience we added the authentication credentials for automation controller to the configuration, so you don’t have to manually log in. In real world you don’t want to do this and will not store your password in a clear text configuration file.
For performance and security reasons, it is recommended "in real life" to generate and use a token for your automation and store the token in a secure place. Check the ansible-navigator documentation for details on how to do this.

Create the Playbook

Now, let’s get the Playbook. In your terminal run:

git clone https://MYGITEAHOST.apps.ocpvdev01.rhdp.net/MYGITEAUSER/playbooks-adv-controller.git
cd playbooks-adv-controller
cat configure-controller.yml

Use cat or the VS Code Server editor to have a good look at what the configure-controller.yml Playbook is supposed to do.

Since we are calling the REST API of automation controller, the Ansible playbook is running against localhost, but the modules will connect to the URL provided by the CONTROLLER_HOST environment variable set for you in ~/.ansible-navigator.yml.

Tasks:

  • Create an inventory: An inventory is created.

  • Add hosts to inventory: Hosts are added to the inventory.

  • Machine Credentials: Machine credentials are created.

    SSH keys have already been created and distributed in your lab environment and sudo has been setup on the managed hosts to allow password-less login. When you SSH into a host as a regular user from the bastion node you will become user lab-user on the host you logged in.

  • Create Projects: different projects are created based on public git repos which we have synced to your environment (check how we define the scm variable if you’re interested in the details).

  • Create XYZ Template: and finally three job templates are created based on the previously added elements (the trinity inventory, credential and project).

Run the Playbook

After you have inspected the Playbook finally run it:

ansible-navigator run configure-controller.yml

While in ansible-navigator press a line number e.g. to get more information about a play or a task. This works only for less then 10 lines, if you want to inspect a line number with 2 digits or more, you need to prefix it with :. To leave, press Esc multiple times to get up again in the views and eventually out of Ansible Navigator.

Do not leave the Ansible Navigator TUI (Text User Interface) before the job is finished! Check the colored text box in the bottom-right corner, it must go from Running to Successful.

After the successful run, log in to Ansible Automation Platform as MYCTLUSER with password MYCTLPASSWORD. Open Automation Execution and make sure that you see the configured objects and that three jobs "Source Control Update" have successfully been executed which cloned the git repositories.

If you run this Ansible Playbook multiple times, you will notice the ansible.controller.credential module is not idempotent! Since automation controller stores the SSH key encrypted, the Ansible Module is unable to verify it has already been set and didn’t change. This is what we want and expect from a secure system, but it also means Ansible has no means to verify it and hence overrides the SSH key or password every time the Ansible Playbook is executed. This can be overridden with the update_secrets parameter. Also note that the credential_type value is simply the type’s name.

Conclusion

The Red Hat Ansible Automation Platform is developed following the "API first" model allowing all aspects of the system to be automatically configured and managed by using the API. This also allows us to "automate the automation" and use Ansible to fully configure it.