A list of best practises and style choices that I think are good for writing clean and consistent Ansible.
This makes it easy to differentiate between a "global" variable and a playbook/role variable.
Do:
In inventory/group_vars/production.yml:
---| #!/usr/bin/env python3 | |
| # Keeps LibreNMS groups in sync. | |
| # If service templates are in use it's expected that they target groups | |
| # whose names start with "z-service" and automatically re-discovers hosts | |
| # that are part of these groups, if they're added / modified by the script. | |
| # | |
| # Config file is expected to have this format: | |
| # { |
| from ansible.cli import CLI | |
| from ansible.template import Templar | |
| from ansible.vars.manager import VariableManager | |
| from ansible.parsing.dataloader import DataLoader | |
| from ansible.inventory.manager import InventoryManager | |
| import ansible.constants as C | |
| def main(): | |
| # The DataLoader is responsible for loading yaml/json content |
A list of best practises and style choices that I think are good for writing clean and consistent Ansible.
This makes it easy to differentiate between a "global" variable and a playbook/role variable.
Do:
In inventory/group_vars/production.yml:
---A collection of code snippets for solving different problems in Ansible.
This works by first getting the inventory hostnames of all members in the database group and then extracting the variable ansible_host for each one of them.
database_servers_ips: "{{ groups.database | map('extract', hostvars, 'ansible_host') }}"
-> ["10.0.0.1", "10.0.0.2"]iptables contains 5 tables which in turn contain a number of built-in chains and may also contain user defined chains. Each chain is a list of rules that can match a set of packets. Each rule specifies what to do with a packet that matches. The action to take on matched packets are known as a 'target' and are specified via the --jump flag. The target can either be a chain, a target from an iptables-extension or one of the special built-in targets:
Most Ansible users have come across the args keyword when using the ansible.builtin.command module. In this case the args keyword is used to pass a named parameter such as chdir or creates to the module that accepts a "free form" parameter.
Example:
- ansible.builtin.command: touch filename #Run this command
args:
chdir: /some/path # Change to this path before running command
creates: /some/path/filename # The command creates this file
What you might not know is that the args keyword can be used on any module for a number of different use cases . Here are some examples:
I frequent the r/ansible sub and try to help out and answer as many questions as I can. One area that I see most people struggling with is using some of the more advanced jinja filters such as select, selectattr and map.
In this post I will try to give some easy to understand examples of how to use these filters in order to filter lists and dictionaries in your Ansible playbooks.
In jinja a test is a template expression that evaluates to either True or False.
Test are used to compare objects.
Jinja has a number of built-in tests but Ansible also provies some filters of their own:
https://jinja.palletsprojects.