Developing Advanced Automation with Red Hat Ansible Automation Platform
Validate that a custom automation execution environment works as expected by testing it with the
ansible-navigatorcommand, and then distribute the automation execution environment for reuse.
After the ansible-builder command successfully creates a new automation execution environment, it is important to validate that it works correctly.
To ensure that the automation execution environment uses its internal collections, you can remove locally installed collections from your system.
Use the ansible-galaxy command to list installed collections.
[user@host ~]$ ansible-galaxy collection list
# /home/user/.ansible/collections/ansible_collections
Collection Version
----------------- -------
ansible.controller 4.2.0
community.crypto 2.7.0
community.general 5.6.0In addition to showing the installed collections, the output displays where the collections are installed.
Recursively removing the ansible_collections directory removes the locally installed collections.
[user@host ~]$ rm -rf /home/user/.ansible/collections/ansible_collectionsIf your new automation execution environment uses custom collections, then create a playbook that tests one or more of those collections. The test might use a simple playbook to test a role or a module included in the collection.
---
- name: Testing a custom Ansible Content Collection
hosts: all
roles:
- role: mynamespace.mycollection.my_role
tasks:
- name: Ensure my custom module works
mynamespace.mycollection.my_module:Important
When using automation execution environments, localhost is the container itself rather than the machine from which you run the ansible-navigator command.
Playbooks originally written for the ansible-playbook command that target localhost might not work as intended.
If you want plays or tasks to target your local machine, then define your local machine in the inventory file and modify the plays and tasks to point to that machine name.
For playbooks that you intend to run locally as well as on automation controller, you can use hosts: all to target all inventory hosts.
Then you can create an inventory that only contains the desired hosts.
Use the ansible-navigator command to run your test playbook using the new automation execution environment.
Use the
--inventory(or-i) option to specify an inventory file or directory.Use the
--execution-environment-image(or--eei) option to specify the automation execution environment container image.If the container image exists locally, then use the
--pull-policy never(or--pp never) option. Without that option, and if the image tag islatest, then theansible-navigatorcommand attempts to pull the container image from a container registry, such as the Red Hat Ecosystem Catalog or Docker Hub.If the playbook requires privilege escalation and does not use
become: true, then add the--become(or-b) option to enable privilege escalation.Optionally add the
--mode stdout(or-m stdout) option to redirect the playbook output to your terminal window. Alternatively, run the playbook in the default interactive mode.
[user@host ~]$ansible-navigator run test_playbook.yml -i inventory \>--eei localhost/ee-demo:v2.0 --pp never -b -m stdout
If the playbook succeeds, then you can share the automation execution environment. If the playbook does not succeed, then investigate any reported issues.
When Ansible runs a play on a managed host, it generally must provide authentication credentials to that host to log in and make changes.
For Linux-based managed hosts, one common solution is to install the user account specified by the Ansible remote_user directive with the public SSH key that matches a private SSH key available to the automation execution environment.
The ansible-playbook command (or ansible-navigator with the --ee false option) uses the same machine as the control node and automation execution environment.
In this mode, Ansible can read the private SSH key directly from your ~/.ssh directory.
If you use automation execution environment containers, however, then you need to provide the private SSH key to the container.
Automation controller can store your private SSH key in a machine credential, a special resource that can be updated but not read from the web UI. If you use password-based SSH authentication, it can instead store an SSH username and password. You can provide the machine credential in the playbook's job template so that the credential is automatically passed to the automation execution environment when automation controller runs the playbook. The machine credential can also store a password used for privilege escalation.
Automation content navigator can get your private SSH key from ssh-agent.
If you use the default graphical GNOME desktop environment, then ssh-agent starts automatically when you log in.
If you log in through a text-based terminal or SSH, you can start ssh-agent with the eval $(ssh-agent) command.
When ssh-agent is running, you can run the ssh-add command to add your private SSH keys to ssh-agent.
Automation content navigator provides keys stored by ssh-agent to the automation execution environment.
Warning
It is possible to put a private SSH key inside the Ansible project and to use the private_key_file directive to point Ansible at that private SSH key.
This is not a recommended practice. If you do this, it is too easy to accidentally commit the private SSH key to your version control system. This can be particularly bad if your SSH key is not passphrase protected and the contents of your Git repository or other version control system are publicly visible.
By default, ansible-navigator does not prompt you for passwords or other interactive input.
This means that normally you cannot use options that prompt you for such things as a connection password (--ask-pass), a privilege escalation password (--ask-become-pass), or vault passwords (--ask-vault-pass).
(This design decision is intentional, because automation controller does not support interactive prompting in this manner either.)
To enable the ansible-navigator command to support interactive prompts for passwords, you can either use the --pae false option, or you can edit your ansible-navigator.yml configuration file and add the following section:
--- ansible-navigator:playbook-artifact:enable: false
In addition, you need to use the --mode stdout (or -m stdout) option with the ansible-navigator run command.
The ansible-builder command creates automation execution environment container images on your local system.
For automation controller and your users to access these images, push them to a container registry, such as Quay.io or private automation hub.
Important
You are not allowed to publicly distribute container images that you build on top of the automation execution environment images that Red Hat provides.
Push a container image to private automation hub by using a procedure such as the following.
In this example, private automation hub is accessible at hub.example.com.
List your local container images.
[user@host ~]$ podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/ee-demo v2.0 ba77b0d0a59d 2 minutes ago 308 MB
...output omitted...Use the
podman tagcommand to tag the local container image for your private automation hub. The image name on private automation hub does not have to be the same as the local image. Also, private automation hub organizes the images in namespaces. You can use those namespaces to group your images per team, for example. Thepodman pushcommand that you use in a following step creates the namespace if it does not exist.
[user@host ~]$podman tag localhost/ee-demo:v2.0 \>hub.example.com/mynamespace/ee-demo:v2.0
Note
If you do not specify a tag, then the latest tag is used.
A tag is arbitrary text and can specify a version, a date, an environment, and so on.
Examples include v1.0, 20220923, and devel.
A container image can have multiple tags, such as latest, v1.0, and best.
Add each tag individually.
An individual tag, such as latest, can only apply to one container image at a time.
Adding a tag name to an image removes that tag name from any other container image with the same name.
Using a tag other than latest makes it easier for automation controller to use a specific version of the automation execution environment.
Use the
podman logincommand to log in to private automation hub.
[user@host ~]$ podman login hub.example.comUse the
podman pushcommand to push the container image to private automation hub.
[user@host ~]$ podman push hub.example.com/mynamespace/ee-demo:v2.0References
podman-login(1), podman-tag(1), and podman-push(1) man pages
