Ansible

Global configuration is in /etc/ansible

By default, Ansible will try to use native OpenSSH for remote communication when possible. This enables ControlPersist[controlPersistNote], Kerberos, and options in ~/.ssh/config such as Jump Host setup.

Variables

Variable names should be letters, numbers, and underscores. Variables should always start with a letter. YAML also supports dictionaries which map keys to values.

Variables can be defined in:

inventories
playbooks

and later be used in playbooks using the Jinja2 templating system.

Ansible Facts: system variables

As well as with the ansible_facts variable, facts are variables discovered from systems.

$ ansible localhost -m setup
127.0.0.1 | SUCCESS => {
    "ansible_facts": {
        "ansible_all_ipv4_addresses": [
            ...
    "changed": false
}

$ ansible localhost -m setup -a "filter=*arch*"
127.0.0.1 | SUCCESS => {
    "ansible_facts": {
        "ansible_architecture": "x86_64",
        "ansible_userspace_architecture": "x86_64"
    },
    "changed": false
}

Playbooks

Basic elements

Play

The goal of a play is to map a group of hosts to some well defined roles, represented by things ansible calls tasks.

Task

A task is in its simple form triggers the executing of a module, with specific arguments. Tasks can be condionally executed, looped. Logical grouping of tasks can be organised in blocks. Variables can be used in arguments to modules. Modules should be idempotent and changes trigger handlers.

Handlers

Modules can relay when they have made a change on the remote system: notify.

loops

Looping

loop is prefered over with_* (not deprecated)

Best practices

Run a playbook and load password stored in vault

ansible-playbook --ask-vault-pass --extra-vars '@/etc/ansible/vault.yml' oh-my-zsh.yml

Specifying an inventory file

ansible-playbook -i inventories/hosts --ask-vault-pass --extra-vars '@/etc/ansible/vault.yml' oh-my-zsh.yml

Inventory

Variables can be assigned to hosts

[atlanta]
host1 http_port=80 maxRequestsPerChild=808
host2 http_port=303 maxRequestsPerChild=909

Roles

Roles are ways of automatically loading certain vars_files, tasks, and handlers based on a known file structure. Grouping content by roles also allows easy sharing of roles with other users.

A role is distributed as directory structure and contains at least one of the following directory, containing itself a main.yml that will be added to the playbook.

tasks - contains the main list of tasks to be executed by the role.
handlers - contains handlers, which may be used by this role or even anywhere - outside this role.
defaults - default variables for the role (see Using Variables for more - information).
vars - other variables for the role (see Using Variables for more information).
files - contains files which can be deployed via this role.
templates - contains templates which can be deployed via this role.
meta - defines some meta data for this role. See below for more details.

Role dependencies

https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-dependencies

List roles

The command ansible-galaxy list -p roles outputs list of roles in the roles directory and warnings about missing directories

Import and include role in playbooks

The module import_role and include_role. On import, keywords, loops and conditionals will only be applied to the imported tasks, not to this statement itself.

Install multiples roles

ansible-galaxy install -r requirements.yml

requirements.yml specification can be found in the official documentation.

Debug

Print variables

Print all variables in debug mode (flag -vvvv)

- name: "Ansible | List all known variables and facts"
  debug:
    var: hostvars[inventory_hostname]

Ansible-galaxy

Get the number of distribution (platforms key in metadata)

$ curl  https://galaxy.ansible.com/api/v1/platforms/ | jq '.results | group_by(.name)[] | {key: .[0].name, length: length}'

Molecule

Note: default configurations are defined in molecule.config

Scenarios

Scenarios can be though as multiple test suites. Each scenario is configured through a YAML file molecule.yml with top level key:

dependency: sets and configure the dependency manager [galaxy, gilt, shell]
driver: sets the driver for spinning-up the environment to test on [delegated, docker, podman]
lint: to configure any external lint commands.
platforms: defines the instances to be tested, and the groups to which the instances belong.
provisioner: handles provisioning and converging the role (ansible).
scenario: scenarios are first-class citizens with a top-level configuration syntax. A scenario is a self-contained directory containing everything necessary for testing the role in a particular way. The default scenario is named default, and every role should contain a default scenario.
state: is an internal bookkeeping mechanism
verifier: sets the test suite

Action

dependency
check
converge
cleanup
create
destroy
prepare
idempotence
verify

Default scenarios sequences are:

"check_sequence": [ "dependency", "cleanup", "destroy", "create", "prepare", "converge", "check", "cleanup", "destroy", ],
"cleanup_sequence": ["cleanup"],
"converge_sequence": ["dependency", "create", "prepare", "converge"],
"create_sequence": ["dependency", "create", "prepare"],
"destroy_sequence": ["dependency", "cleanup", "destroy"],
"test_sequence": [ "dependency", "lint", "cleanup", "destroy", "syntax", "create", "prepare", "converge", "idempotence", "side_effect", "verify", "cleanup", "destroy",

The corresponding playbooks are stored in the files whose default names are:

"cleanup": "cleanup.yml",
"create": "create.yml",
"converge": "converge.yml",
"destroy": "destroy.yml",
"prepare": "prepare.yml",
"side_effect": "side_effect.yml",
"verify": "verify.yml",

Creating a new role

molecule init role my-new-role

or add to an existing role:

molecule scenario role my-new-role

Notes

FAQ

ERROR! no action detected in task

e-roux/ansible.md