The run_once statement in Ansible
Harnessing the Hidden Power of Ansible’s “run_once” Directive
Ansible is a powerful automation tool that makes managing IT infrastructure easier. One of its lesser-known but highly useful directives is “run_once.” While using it at the play level might seem unremarkable, its true potentials reveals itself when employed within a task. Let’s explore the wonders of run_once and how it can simplify complex automation scenarios.
At the play level, using
run_once is equivalent to changing the host selection. Instead of specifying hosts as “
foo” you’d use “
foo”. This makes it convenient for directing tasks to a specific host but doesn’t necessarily elicit much excitement.
- name: Play level hosts: host1,host2,host3,host4,host5,host6,host7 run_once: true tasks: - name: Print message ansible.builtin.debug: msg: Hello World
However, the real enchantment occurs when you use run_once within a task. When you do this, tasks with run_once are executed on a single host, typically the first host in the runlist. This simple feature allows for intricate choreography. For instance, you can send a command to a cluster only once, even if there are multiple equally available hosts in the cluster group. Furthermore, with the ability to continue executing playbooks even when some hosts are unavailable, you can ensure your command reaches the first available node in the cluster. It’s very useful in its utility.
What happens when you combine run_once with the “
register” directive? You might wonder if the variable for hosts where the command wasn’t run remains undefined or contains some “
message, as can occur with other combinations of directives like “when” and “register`.”
In this case, Ansible behaves in the best way imaginable. The registered variable is created for all hosts in the runlist, even if the task was executed on a single host. When you combine it with delegation, it becomes even more elegant.
One of the best applications of this feature is in gathering “pseudo-facts.” For example:
- name: Get data ansible.builtin.command: data get run_once: true register: data
Previously, you might have added this to the play without concerns. While it’s slightly inefficient, it’s concise and straightforward. Now, it becomes a real trick that dramatically reduces the number of calls to the delegated host.
The Best Resources For Ansible
- CYBER DEALS at The Linux Foundation! Up to 65% off, and a FREE GIFT with EVERY PURCHASE! Limited Time, Don't Delay!
- Udemy: Learn Ansible Automation in 250+examples & practical lessons: Learn Ansible with some real-life examples of how to use the most common modules and Ansible Playbook
- Ansible by Examples: 200+ Automation Examples For Linux and Windows System Administrator and DevOps
- Ansible Cookbook: A Comprehensive Guide to Unleashing the Power of Ansible via Best Practices, Troubleshooting, and Linting Rules with Luca Berton
- Ansible For Windows By Examples: 50+ Automation Examples For Windows System Administrator And DevOps
- Ansible For Linux by Examples: 100+ Automation Examples For Linux System Administrator and DevOps
- Ansible Linux Filesystem By Examples: 40+ Automation Examples on Linux File and Directory Operation for Modern IT Infrastructure
- Ansible For Security by Examples: 100+ Automation Examples to Automate Security and Verify Compliance for IT Modern Infrastructure
- Ansible Tips and Tricks: 10+ Ansible Examples to Save Time and Automate More Tasks
- Ansible Linux Users & Groups By Examples: 20+ Automation Examples on Linux Users and Groups Operation for Modern IT Infrastructure
- Ansible For PostgreSQL by Examples: 10+ Examples To Automate Your PostgreSQL database
- Ansible For Amazon Web Services AWS By Examples: 10+ Examples To Automate Your AWS Modern Infrastructure
- Ansible Automation Platform By Example: A step-by-step guide for the most common user scenarios
Imagine a playbook with multiple hosts, and you want to set a fact using
- name: Pseudo-facts playbook hosts: host1,host2,host3,host4,host5,host6,host7 tasks: - name: Set fact run_once: true ansible.builtin.set_fact: foo: 42 - name: Print the fast ansible.builtin.debug: var: foo
What do you think will happen to “foo” for all hosts in the play? It’s not just magic; it’s sheer brilliance. All hosts will have “
foo: 42”. The primary difference from a version lacking
run_once is the reduction in output. This feature is especially valuable when working with loops and other complex automation constructs, making it a fantastic way to streamline your Ansible playbooks.
In conclusion, the “
run_once” directive in Ansible might seem simple at first, but it holds incredible power. Whether you want to send a command to a single host in a group, efficiently gather “pseudo-facts,” or streamline your playbook output,
run_once is a wonderful tool that every Ansible user should be aware of. It demonstrates how the simplest features can bring about the most powerful automation results.
Learn the Ansible automation technology with some real-life examples in my
My book Ansible By Examples: 200+ Automation Examples For Linux and Windows System Administrator and DevOps
Want to keep this project going? Please donate