The ansible-pull command is a special feature of Ansible that allows you to, all in one go, pull a playbook from a Git repository (for example, GitHub) and then execute it, hence saving the usual steps such as cloning (or updating the working copy of) the repository, then executing the playbook. The great thing about ansible-pull is that it allows you to centrally store and version control your playbooks and then execute them with a single command, hence enabling them to be executed using the cron scheduler without the need to even install the Ansible playbooks on a given box.

An important thing to note, however, is that, while the ansible and ansible-playbook commands can both operate over an entire inventory and run the playbooks against one or more remote hosts, the ansible-pull command is only intended to run the playbooks it obtains from your source control system on the localhost. Hence, if you want to use ansible-pull throughout your infrastructure, you must install it onto every host that needs it.

Nonetheless, let's see how this might work. We'll simply run the command by hand to explore its application, but in reality, you would almost certainly install it into your crontab so that it runs on a regular basis, picking up any changes you make to your playbook in the version control system. 

As ansible-pull is only intended to run the playbook on the local system, an inventory file is somewhat redundant—instead, we'll use a little-used inventory specification whereby you can simply specify inventory hosts directory as a comma-separated list on the command line. If you only have one host, you simply specify its name followed by a comma.

Let's use a simple playbook from GitHub that sets the message of the day based on variable content. To do this, we will run the following command (which we'll break down in a minute):

$ ansible-pull -d /var/ansible-set-motd -i ${HOSTNAME}, -U https://github.com/jamesfreeman959/ansible-set-motd.git site.yml -e "ag_motd_content='MOTD generated by ansible-pull'" >> /tmp/ansible-pull.log 2>&1

This command breaks down as follows:

• -d /var/ansible-set-motd: This sets the working directory that will contain the checkout of the code from GitHub.
• -i ${HOSTNAME},: This runs only on the current host, specified by its hostname from the appropriate shell variable.
• -U https://github.com/jamesfreeman959/ansible-set-motd.git: We use this URL to obtain the playbooks.
• site.yml: This is the name of the playbook to run.
• -e "ag_motd_content='MOTD generated by ansible-pull'": This sets the appropriate Ansible variable to generate the MOTD content.
• >> /tmp/ansible-pull.log 2>&1: This redirects the output of the command to a log file in case we need to analyze it later—especially useful if running the command in a cron job where the output would never be printed to the user's terminal.

When you run this command, you should see some output similar to the following (note that log redirection has been removed to make it easier to see the output):

$ ansible-pull -d /var/ansible-set-motd -i ${HOSTNAME}, -U https://github.com/jamesfreeman959/ansible-set-motd.git site.yml -e "ag_motd_content='MOTD generated by ansible-pull'"
Starting Ansible Pull at 2020-04-14 17:26:21
/usr/bin/ansible-pull -d /var/ansible-set-motd -i cookbook, -U https://github.com/jamesfreeman959/ansible-set-motd.git site.yml -e ag_motd_content='MOTD generated by ansible-pull'
cookbook |[WARNING]: SUCCESS = Your git > {
    "aversion isfter": "7d too old t3a191ecb2do fully suebe7f84f4fpport the a5817b0f1bdepth argu49c4cd54",ment.
Fall
    "ansing back tible_factso full che": {
     ckouts.
   "discovered_interpreter_python": "/usr/bin/python"
    },
    "before": "7d3a191ecb2debe7f84f4fa5817b0f1b49c4cd54",
    "changed": false,
    "remote_url_changed": false
}

PLAY [Update the MOTD on hosts] ************************************************

TASK [Gathering Facts] *********************************************************
ok: [cookbook]

TASK [ansible.motd : Add 99-footer file] ***************************************
skipping: [cookbook]

TASK [ansible.motd : Delete 99-footer file] ************************************
ok: [cookbook]

TASK [ansible.motd : Delete /etc/motd file] ************************************
skipping: [cookbook]

TASK [ansible.motd : Check motd tail supported] ********************************
fatal: [cookbook]: FAILED! => {"changed": true, "cmd": "test -f /etc/update-motd.d/99-footer", "delta": "0:00:00.004444", "end": "2020-04-14 17:26:25.489793", "msg": "non-zero return code", "rc": 1, "start": "2020-04-14 17:26:25.485349", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}
...ignoring

TASK [ansible.motd : Add motd tail] ********************************************
skipping: [cookbook]

TASK [ansible.motd : Add motd] *************************************************
changed: [cookbook]

PLAY RECAP *********************************************************************
cookbook : ok=4 changed=2 unreachable=0 failed=0 skipped=3 rescued=0 ignored=1

This command can be a very powerful part of your overall Ansible solution, especially as it means you don't have to worry too greatly about running all of your playbooks centrally, or ensuring that they are all up to date every time you run them. The ability to schedule this in cron is especially powerful in a large infrastructure where, ideally, automation means things should take care of themselves.

This concludes our practical look at playbooks and how to author your own code—with a little research into Ansible modules, you should now have enough to write your own robust playbooks with ease.