Ansible

Architecture:

One Ansible control server. If using CentOS, run:

yum install epel-release
yum install ansible

Once installed, the target devices can be defined in /etc/ansible/hosts, while general Ansible configuration is in /etc/ansible/ansible.cfg

The hosts file is also known as an inventory file and simply lists the devices that will be controlled, be it VMs, computers, routers, switches, etc.

SSH Keymanagement

When using Ansible it is recommended to create an ansible key for automated commands.

Inventory file

In the inventory file we can define a group by using [] notation. For example, a group of Linux servers would be defined as follows:

# Define a group and the hosts in the group
[linux]

192.168.0.90
192.168.0.91

# Define variables and attributes for that group
[linux:vars]

# Consider adding a user for ansible
ansible_user=root 
ansible_password=

Note that the IP addresses can be substituted with DNS records, if configured in a DNS server properly.

Configuration file

Using ansible comands

To ping servers, run ansible linux -m ping

Note: more specifically, run ansible all --key-file ~/.ssh/ansible -i inventory -m ping to specify the ssh-key file as well as a specific inventory file. To set up a shorter version include the parameters in an ansible.cfg file. When running ansible, a local .cfg file will override the global settings at /etc/ansible.

[defaults]
inventory = inventory
private_key_file = ~/.ssh/ansible

This command calls ansible, uses the linux group defined in hosts and uses the ping module (remember that it is Python based!)

To run general linux commands, use the following: ansible linux -a "cat /etc/os-release". Note that the -a can be thought of as “ad-hoc” commands that we want to run.

elevated commands

If we want to update the apt repository on a Debian machine, we run ansible all -m apt -a update_cache=true. Note that the -a refers to the argument that is being passed to the apt module. THe command,. however, will fail because it requires sudo privileges.

To elevate, we can add a few parameters at the end:

`ansible all -m apt -a update_cache=true --become --ask-become-pass

Installing packages

To install a package we can use the same command as above, but as an argument instead of update_cache we can use name to refer to a specific package. For the -a parameters we add quotation marks in order to pass more than one argument to it.

ansible all -m apt -a "name=neovim state=latest" --become --ask-become-pass

Playbooks

Playbooks are an organised way to establish “plays” which themselves have “tasks”. The Playbook is a YAML file with “tasks”, that are really just ansible commands but pre-planned (much like say, an installer bash script).

Example

---    
│ - name: installnvim    
│ │ hosts: centos    
│ │ tasks:     
│ │ │ - name: ensure nvim is there    
│ │ │ │ yum:    
│ │ │ │ name: nvim         
│ │ │ │ state: latest                        

Note: YML does not support tabs; use spaces instead

This is a simple Ansible playbook. The first “play” is called “installnvim” and its only task is to ensure that nvim is installed. Note that yum is used here because the target devices are CentOS - this can be replaced with apt for Debian-based systems.

Specifically, yum in this playbook is known as a module. The modules are small programs that help us define the state of the machine. For example, by using state: latest we are telling Ansible to install the latest version of a package. We can also use state: absent to ensure the package is uninstalled, if found.

Note that all of these commands are idempotent. Changes will only be made if they are necessary.

To run this, use the command ansible-playbook {filename}.yml

Modules

Modules are built-in tools that carries a specific job in the target system. They are specified with the -m flag in ad hoc mode; they cinlude stuff like apt, copy, file, start, etc.