Developing Advanced Automation with Red Hat Ansible Automation Platform

One key DevOps concept is the idea of infrastructure as code (IaC). Instead of managing your infrastructure manually, you define and build your systems by running your automation code. Red Hat Ansible Automation Platform is a key tool that can help you implement this approach.

If Ansible projects are the code used to define the infrastructure, then a version control system (VCS) such as Git should be used to track and control changes to the code.

Version control also enables you to implement a lifecycle for the different stages of your infrastructure code, such as development, QA, and production. You can commit your changes to a branch and test those changes in noncritical development and QA environments. When you are confident with the changes, you can merge them to the main production code and apply the changes to your production infrastructure.

Git is a distributed version control system (DVCS) that enables you to manage changes to files in a project collaboratively. Using Git provides many benefits:

Using Git, you can start by cloning an existing shared project from a remote repository. Cloning a project creates a complete copy of the original remote repository as a local repository. This local copy has the entire history of the files in Git, and not just the latest snapshot of the project files.

You make edits in a working tree, which is a checkout of a single snapshot of the project. Next, you place the modified files in a staging area, ready to commit the differences to the local repository. At this point, no changes have been made to the shared remote repository.

When you are ready to share the completed work, you push the changes to the remote repository. Likewise, when you are ready to update the local repository with the latest changes to the remote repository, you pull the changes, which fetches them from the remote repository and merges them into the local repository.

To use Git effectively, you must be aware of the three possible states of a file in the working tree: modified, staged, or committed.

When you commit the file to the local repository, that file can be pushed to or pulled by a remote repository.

Figure 1.8: The four areas where Git manages files

Because Git users frequently modify projects with multiple contributors, Git records the user's name and email address on each of their commits. These values can be defined at a project level, but you can also set global defaults for a user. The git config command controls these settings.

Using git config with the --global option manages the default settings for all Git projects to which you contribute by saving the settings in your ~/.gitconfig file.

[user@host ~]$ git config --global user.name 'Peter Shadowman'
[user@host ~]$ git config --global user.email peter@host.example.com

If Bash is your shell, then another useful, optional setting, is to configure your prompt to automatically update to indicate the status of your working tree. The easiest way to do it is to use the git-prompt.sh script that ships with the git package.

To modify your shell prompt in this way, add the following lines to your ~/.bashrc file.

source /usr/share/git-core/contrib/completion/git-prompt.sh
export GIT_PS1_SHOWDIRTYSTATE=true
export GIT_PS1_SHOWUNTRACKEDFILES=true
export PS1='[\u@\h \W$(declare -F __git_ps1 &>/dev/null && __git_ps1 " (%s)")]\$ '

If your current directory is in a Git working tree, then the name of the current Git branch for the working tree is displayed in parentheses. If you have untracked, modified, or staged files in your working tree, then the prompt could indicate one of the following meanings:

When working on shared projects, you clone an existing upstream repository with the git clone command. The provided path name or URL determines which repository is cloned into the current directory. This process creates a working tree of files ready for revisions. Because the working tree is unmodified, it is initially in a clean state. A clean state means the working tree does not contain any modified, staged, or new files.

For example, the following command clones the project.git repository at git.lab.example.com by connecting using the SSH protocol and authenticating as the git user:

[user@host ~]$ git clone git@git.lab.example.com:project.git

Figure 1.9: Git subcommands used to create a repository

Use git init --bare to create a bare repository on a server. Bare repositories do not have a local working tree. Therefore, you cannot use the bare repository to apply file changes.

Git servers usually contain bare repositories, because the working tree is not needed on the server. When you create a local copy of the repository, you usually need a working tree to make local changes, so you create a non-bare clone. The server must also be set up to allow users to clone, pull from, and push to the repository using either the HTTPS or SSH protocol.

As you work, you create new files and modify existing files in the working tree. This changes the working tree to a dirty state. The git status command displays detailed information about which files in the working tree are modified but unstaged, untracked (new), or staged for the next commit.

Figure 1.10: Git subcommands used to add and update local repository content

The git add command stages files, preparing them to be committed. Only files that are staged to the staging area are saved to the repository on the next commit.

The git rm command removes a file from the working directory and also stages its removal from the repository on the next commit.

The git reset command removes a file from the staging area that has been added for the next commit. This command has no effect on the file's contents in the working tree.

The git commit command commits the staged files to the local Git repository. You must provide a log message that explains why you are saving the current set of staged files. Failure to provide a message aborts the commit. Log messages do not have to be long, but they should be meaningful so that they are useful.

The git push command uploads changes made to the local repository to the remote repository. One common way to coordinate work with Git is for all developers to push their work to the same, shared, remote repository.

Before Git pushes can work, you must define the default push method to use. The following command sets the default push method to the simple method. This is the safest option for beginners.

[user@host ~]$ git config --global push.default simple

Use the git pull command to perform the following tasks:

Run the git pull command frequently to stay current with the changes that others are making to the project in the remote repository.

Figure 1.11: Git subcommands that interact with a remote repository

Branches enable you to make changes to your project, working on new development, without altering your main branch. Then, when you are satisfied with your changes, you can merge the changes in your branch to the main branch of development, integrating them.

A branch is essentially a pointer to a particular commit in your commit tree. Each commit contains the changes it made and information about how to reference it and what its relationship is to other commits in the commit tree. The information in a commit includes:

The git commit command generates a new commit with all changes added to the stage with the git add command. You can display a Git repository as a commit graph, and branches as references to commits.

Figure 1.12: Sample Git repository

The preceding figure shows a sample Git repository containing 11 commits. The most recent commits are to the right; the arrows point to earlier commits. It has three branches (main, feature/1, and feature/2) and a single tag (tag/1.0).

The HEAD reference is the current commit in the local working tree. If you make a change in your working tree, stage it with the git add command, and commit it with the git commit command. A new commit is then created with the most recent commit as its parent, and HEAD moves to point to the new commit.

[user@host ~]$ git checkout -b feature/3
Switched to a new branch 'feature/3'

[user@host ~]$ git checkout feature/3
Switched to branch 'feature/3'
[user@host ~]$ git push --set-upstream origin feature/3

Each Ansible project should have its own Git repository. The structure of the files in that repository should follow the directory layout recommended at https://docs.ansible.com/ansible/6/user_guide/sample_setup.html#sample-directory-layout. For example, the directory structure might appear as follows:

site.yml                  # main playbook
webservers.yml            # playbook for webserver tier
dbservers.yml             # playbook for dbserver tier

collections/              # holds Ansible Content Collections in directories
    requirements.yml      # specifies collections needed by this project

roles/
    common/               # this hierarchy represents a "role"
        tasks/            #
            main.yml      #  <-- tasks file can include smaller files if warranted
        handlers/         #
            main.yml      #  <-- handlers file
        templates/        #  <-- files for use with the template resource
            ntp.conf.j2   #  <------- templates end in .j2
        files/            #
            bar.txt       #  <-- files for use with the copy resource
            myscript.sh   #  <-- script files for use with the script resource
        vars/             #
            main.yml      #  <-- variables associated with this role
        defaults/         #
            main.yml      #  <-- default lower priority variables for this role
        meta/             #
            main.yml      #  <-- role dependencies
  ...additional roles...

roles/**
!roles/requirements.yml
collections/ansible_collections
ansible-navigator.log
*-artifact-*
.ssh