As we discussed earlier in this chapter, it is vital that you version control and test not only your code but also your Ansible automation code. This should include inventories (or dynamic inventory scripts), any custom modules, plugins, roles, and playbook code. The reason for this is simple—the ultimate goal of Ansible automation is likely to be to deploy an entire environment using a playbook (or set of playbooks). This might even involve deploying infrastructure as code, especially if you are deploying to a cloud environment.
Any changes to your Ansible code could mean big changes to your environment, and possibly even whether an important production service works or not. As a result, it is vital that you maintain a version history of your Ansible code and that everyone works from the same version. You are free to choose the version control system that suits you best; most corporate environments will already have some kind of version control system in place. However, if you haven't worked with version control systems before, we recommend that you sign up for a free account on somewhere such as GitHub or GitLab, which both offer version control repositories for free, along with more advanced paid-for plans.
A complete discussion of version control with Git is beyond the scope of this book; there are, indeed, entire books devoted to the subject. However, we will take you through the simplest possible use case. It is assumed, in the following examples, that you are using a free account on GitHub, but if you are using a different provider, simply change the URLs to match those given to you by your version control repository host.
In addition to this, you will need to install the command-line Git tools on your Linux host. On CentOS, you would install these as follows:
$ sudo yum install git
On Ubuntu, the process is similarly straightforward:
$ sudo apt-get update
$ sudo apt-get install git
Once the tools are installed and your account is set up, your next task is to clone a Git repository to your machine. If you want to start working with your own repository, you will need to set this up with your provider—excellent documentation is provided by both GitHub and GitLab and you should follow this to set up your first repository.
Once it is set up and initialized, you can clone a copy to your local machine to make changes to your code. This local copy is called a working copy, and you can work through the process of cloning it and making changes as follows (note that these are purely hypothetical examples to give you an idea of the commands you will need to run; you should adapt them for your own use case):
- Clone your git repository to your local machine to create a working copy using a command such as the following:
$ git clone https://github.com/<YOUR_GIT_ACCOUNT>/<GIT_REPO>.git
Cloning into '<GIT_REPO>'...
remote: Enumerating objects: 7, done.
remote: Total 7 (delta 0), reused 0 (delta 0), pack-reused 7
Unpacking objects: 100% (7/7), done.
- Change to the directory of the code you cloned (the working copy) and make any code changes you need to make:
$ cd <GIT_REPO>
$ vim myplaybook.yml
- Be sure to test your code and, when you are happy with it, add the changed files that are ready for committing a new version using a command such as the following:
$ git add myplaybook.yml
- The next step is to commit the changes you have made. A commit is basically a new version of code within the repository, so it should be accompanied by a meaningful commit message (specified in quotes after the -m switch), as follows:
$ git commit -m 'Added new spongle-widget deployment to myplaybook.yml'
[master ed14138] Added new spongle-widget deployment to myplaybook.yml
Committer: Daniel Oh <[email protected]>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly. Run the
following command and follow the instructions in your editor to edit
your configuration file:
git config --global --edit
After doing this, you may fix the identity used for this commit with:
git commit --amend --reset-author
1 file changed, 1 insertion(+), 1 deletion(-)
- Right now, all of these changes live solely in the working copy on your local machine. This is good by itself, but it would be better if the code was available to everyone who needs to view it on the version control system. To push your updated commits back to (for example) GitHub, run the following command:
$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 297 bytes | 297.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To https://github.com/<YOUR_GIT_ACCOUNT>/<GIT_REPO>.git
0d00263..ed14138 master -> master
That's all there is to it!
- Now, other collaborators can clone your code just as we did in step 1. Alternatively, if they already have a working copy of your repository, they can update their working copy using the following command (you can also do this if you want to update your working copy to see changes made by someone else):
$ git pull
There are some incredibly advanced topics and use cases for Git that are beyond the scope of this book. However, you will find that roughly 80% of the time, the preceding commands are all the Git command-line knowledge you need. There are also a number of graphical frontends to Git, as well as code editors and Integrated Development Environments (IDEs), that integrate with Git repositories and can assist you further in taking advantage of them. With that complete, let's take a look at how to ensure you can use the same playbook (or role) across multiple hosts, even though they might have different OSes and versions.