Ansible Pull and Push Patterns

Ansible is an automation tool that configures servers, installs software, and runs commands across multiple machines. In a standard setup, you have one control node — a laptop or server — that stores your playbooks. A playbook is a YAML file containing a list of tasks. The control node connects to managed nodes over SSH and pushes the playbook to them. This is the push pattern.

The push pattern works well when all managed nodes are reachable over the network and the control node can initiate connections to every machine at once. But real environments often have nodes that are not always online, such as laptops that employees take home, servers in a factory that lose internet at night, or devices behind strict firewalls that block inbound SSH. In those cases, the control node cannot push because it cannot start the connection.

Ansible pull mode solves this by reversing the direction. Instead of the control node pushing the playbook to each managed node, each managed node runs a command called ansible-pull. That command connects to a version control repository — usually Git — and downloads the latest playbook. Then it runs that playbook locally on the node itself. The node effectively pulls its own configuration.

Here is how it works step by step. First, you store your playbook in a Git repository. Git is a version control system that tracks changes to files over time. Every time you update the playbook, you commit and push the changes to the repository. Second, on each managed node, you install Ansible. Third, you set up a cron job, which is a scheduled task, that runs ansible-pull at a regular interval, for example every hour. Fourth, when the cron job runs, ansible-pull clones the Git repository to a local directory. Cloning means downloading the entire repository so the node has a local copy. Fifth, ansible-pull runs the playbook from that local copy, applying the desired state to the node.

The ansible-pull command accepts several important options. The -U or --url flag specifies the Git repository URL. The -d or --directory flag sets where to clone the repository locally. The -i or --inventory flag points to an inventory file if you need to target specific nodes. The --accept-host-key flag automatically accepts the Git server's host key, which avoids interactive prompts. The -C or --checkout flag selects a specific branch or tag. The -o or --only-if-changed flag tells ansible-pull to only run the playbook if the repository has changed since the last pull.

Why does pull mode matter for the EX294 exam? Red Hat wants you to know that pull mode is not a replacement for push mode. It is a specialised tool for specific scenarios. You must understand the ansible-pull command syntax, the required options, and how to test a pull setup. The exam may ask you to write a cron job that runs ansible-pull every 30 minutes, or to debug why a pull did not apply the latest playbook changes. You must also know that pull mode requires Git to be installed on the managed nodes, and that the managed node must have network access to the Git repository.

Key terms to remember:

- ansible-pull: the command each managed node runs to fetch and apply a playbook from a Git repository. - Git repository: a remote storage location for your playbook files, typically hosted on GitHub, GitLab, or a private server. - cron: a Linux utility that runs commands at scheduled times. You use it to schedule ansible-pull to run periodically. - control node: the machine where you normally run ansible commands in push mode. In pull mode, the control node role shifts to the Git repository. - managed node: the machine that Ansible configures. In pull mode, the managed node initiates the connection to the Git repository.

Maria works as a systems administrator for a retail company with 500 point-of-sale terminals in shops across the country. Each terminal is a Linux server running inventory management software. The terminals are behind highly restrictive firewalls that block inbound SSH connections. Maria cannot use push mode because her control node cannot initiate connections to the terminals. She must use pull mode.

First, Maria sets up a private Git repository on a central server that the terminals can reach over HTTPS. She creates a playbook named pos-config.yml that installs security updates, updates the inventory application, and configures the network settings. She commits and pushes the playbook to the repository.

Next, Maria writes a script that runs ansible-pull on each terminal. The script uses these options:

- -U https://git.company.internal/ansible/pos-playbook.git - -d /opt/ansible/pull - -o (only run if changed) - --accept-host-key - -C main (use the main branch)

She then sets up a cron job on each terminal to run this script every hour. She uses the root user's crontab to ensure the playbook has permission to make system changes. The cron line looks like this: 0 * * * * ansible-pull -U https://git.company.internal/ansible/pos-playbook.git -d /opt/ansible/pull -o --accept-host-key -C main.

Three weeks later, a critical security patch is released for the inventory software. Maria updates the playbook in the Git repository and pushes the change. Over the next hour, all 500 terminals pull the updated playbook and apply the patch automatically. Maria does not need to log into each terminal or wait for a maintenance window. The pull pattern handles the scale.

A common real-world requirement is to set up a pull interval that balances timeliness with network load. Maria chose hourly because the terminals have limited bandwidth. If a node misses its pull because the terminal is powered off, it will pull the next time it boots and the cron job runs. Maria also added logging to the cron job so she can audit which terminals pulled which version of the playbook.

The key lesson: pull mode frees the administrator from being the single point of failure. If Maria's control node crashes, the terminals continue to pull the latest playbook from Git. They do not depend on Maria's machine being online.