Ansible Cheatsheet

Photo by Phillip Glickman on Unsplash

Ansible is a tool to automate system administration tasks. The Ansible Control Node is the machine used to control other machines; the Managed Node is the machine being controlled.

Both machines have to run Linux (e.g. two VMs, one WLS and one VM, a local Linux machine and a remote VM, two remote Linux machines…)

Since Ansible runs commands by SSH, so no need to have an agent on managed nodes.

How does it work

Ansible selects machine to run the commands on using an inventory (in /etc/ansible/hosts); it connects to machines using ssh, copy modules and then executes them.

Installation (Ubuntu)

Please refer here to install on other OS.

Python should be installed on both the machines (control node and managed node).

Install Ansible on the Control Node:

Finding the IP of the destination machine

Installing openssh on the managed nodes

Note: all the managed nodes have to be accessible with the same username

Generating SSH keys

Keys are needed to authenticate the session without using user/password.

Testing Ansible

Playbooks

Playbooks execute many operations on managed nodes (e.g. creating multiple users). They are essentially .yml files.

state: present -> makes sure the user has been added, if not, it will be added

state: absent -> makes sure the user has been removed, if not, it will be removed

Be careful with loops, as they are not always efficient. (e.g: looping over three yum vs using a single yum with three packages)

Ansible-galaxy is a playbook repository (there you can find a playbook to install mysql defining databases and users, along with their access rights).

Executing a Playbook

Dry run of a playbook

Escalating privileges in a Playbook (sudo)

Adding the user to sudoers removes the need of -K.

Secrets management with ansible-vault

ansible-vault allows the user to encrypt/decrypt files of secrets (e.g. API keys, passwords)

Executing a Playbook with a vault password

no-log doesn’t show the secrets while executing playbooks.

Conditional tasks

Conditional tasks are defined using “when”.

Testing for conditions (it is possible to use booleans)

Ansible Facts

Data regarding the remote system (e.g: IP, OS…) gathered in a dictionary with a standard nomenclature.

Handlers

Task responding to notifications sent by other tasks (e.g. rebooting the system after relaunching services). Handler are defined at playbook level.

Block

Blocks are clauses gathering tasks in logic units.

A block can provide a “when” so that the tasks in a block are launched if and only if a condition is met.

rescue: only executed if the block fails

always: is always executed

Templating (Jinja2)

Templating allows deploying customized files. Ansible searches for template files in the playbook directory or in a “templates” directory in the playbook directory.

File “template.j2”:

Looping in the template

Filters in the template

Useful to process variables without changing their values

Lookup plugins

Lookup plugins are extensions to the Jinja2 language allowing to get data from external sources (e.g. file content, API calls…).

Example: “dig” to gather informations about a DNS record.

--

--

Full-time Human-computer interpreter. Opinions are my own.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store