Before we proceed any further, we must point out that the title of this section is an oxymoron as Ansible itself does not integrate with Git. Specifically, Ansible playbooks and roles are stored in Git, to be checked out locally on the host that will execute them. It does have modules such as git and git_config, which allow you to write playbooks that deploy code from a Git repository, but the ansible-playbook command does not support running a playbook from anything other than the local filesystem.
We will make use of the publicly available ansible-examples repository on github.com for these next few examples as they are publicly available to you for testing. Hypothetically speaking, suppose that you wanted to run the playbook for installing WordPress on RHEL 7 in your enterprise from this repository. Your process to perform this would (assuming you have already defined your Ansible inventory) look something like the following example:
$ git clone https://github.com/ansible/ansible-examples.git
$ cd ansible-examples/wordpress-nginx_rhel7/
$ ansible-playbook site.yml
The preceding three commands ensure that you clone the very latest playbook from this Git repository, and the output will look a little something like the following screenshot (the deprecation warning shows that this playbook needs updating for more recent versions of Ansible):
Once checked out, the playbooks can always be updated to the latest version from the Git server (assuming there are no local changes that need to be committed):
$ git pull
Following a successful update of the local working copy of your playbooks, the latest version of the playbook can be run. This is a fairly painless process, and requiring engineers or admins to run the git pull command before running a playbook is not too arduous a task.
Sadly, though, this process does not really help to enforce good practices in the enterprise. It would be very easy for someone to forget to run the git pull command before running a playbook. Equally, there is nothing to stop administrators and engineers amassing their own playbooks and failing to share them. This is definitely a step forward, but it is by no means the full solution.
A far more robust option is to enforce the use of a tool such as AWX or Ansible Tower. These, as we saw in Chapter 3, Streamlining Infrastructure Management with AWX, enable the enforcement of good processes by ensuring that playbook runs can only be executed against playbooks pulled down from a version control system. If administrators are not given access to the filesystem of the AWX server, then it will not be possible to run arbitrary playbooks that they have knocked up themselves and they must instead pull them in from a version control source.
In Creating a project in AWX section of Chapter 3, Streamlining Infrastructure Management with AWX, we looked at creating a project that would actually make use of the ansible-examples repository we looked at earlier. This, of course, begs the question, how do you organize your playbooks within a version control system effectively? We will look at precisely this in the next section.