Ansible DevOps Training

LPI-OT DevOps Ansible Objectives
● Description: Candidates should be able to use
Ansible to ensure a target server is in a specific
state regarding its configuration and installed
software. This objective covers the feature set of
Ansible version 2.2 or later.
● Key Knowledge Areas:
– Understand the principles of automated system
configuration and software installation
– Create and maintain inventory files
– Understand how Ansible interacts with remote systems
– Manage SSH login credentials for Ansible, including
using unprivileged login accounts
– Create, maintain and run Ansible playbooks, including
tasks, handlers, conditionals, loops and registers
– Set and use variables
– Maintain secrets using Ansible vaults
– Write Jinja2 templates, including using common filters,
loops and conditionals
– Understand and use Ansible roles and install Ansible roles
from Ansible Galaxy
– Understand and use important Ansible tasks, including file,
copy, template, ini_file, lineinfile, patch, replace, user,
group, command, shell, service, systemd, cron, apt,
debconf, yum, git, and debug
– Awareness of dynamic inventory
– Awareness of Ansibles features for non-Linux systems
– Awareness of Ansible containers
● The following is a partial list of the used files,
terms and utilities:
– ansible.cfg
– ansible-playbook
– ansible-vault
– ansible-galaxy
– ansible-doc

Ansible
● Agentless
– Uses ssh,
● Secure
– Uses os level security and
privilege escalation
mechanisms
● Provisioning and deployment
● Easy to start
● Configuration mostly in yaml
● Data driven
● Idempotent
– Rerunning the playbook will not
result in duplication of successful
actions
● Describe the intended system
state
● Written i and extended with
Python,
● Tries to leave nothing behind
(agentless)

Modules
● Ansible functionality provided by
modules
● 250+ modules
– Cloud services (Amazon,
Rackspace, Google Compute
Platform)
– Packaging (apt, yum, pip, gem)
– Source control (git, svn)
– OS plugins (service, command, file,
template)
– Module index
● Generic modules used when a
specific module does not
exist,
– commands,
– shell
– Raw
● Best to use a specific module
when available – ensures
proper handling of
idempotence

How Ansible Works

Provisioning/Set Up
● Ansible target host requirements
– Ssh must be enabled
– User with admin privileges
● root (not recommended),
● User with sudo/su rights – ansible recommends passwordless sudo/su for the ansible user
– Authentication via
● Password
● Ssh key (preferred)
● Prerequisites for labs:
– Install a virtual machine
● Ensure ssh is enabled
● Ensure python is installed

Ansible Concepts
● Hosts are defined in the ansible
“inventory”
● Ansible operates on a set of host
by
– Hostname,
● one.example.com
● one.example.com:two.example.com
– group name
● Web-servers
● Webserver:!dbserver - in
webservers but not dbservers group
–
– a selection pattern.
● 192.0.2.50
● 192.0.2.*
● Ansible can operate in
– ad-hoc mode, used to run once off
commands
– playbook mode where multi-step
commands are run to configure the
target host
● Ansible uses modules for its
functionality
– Modules are written in python

Static Inventory
● Defines how ansible will
interact with remote hosts
via inventory parameters
● Define logical groups of
managed nodes
● Default location :
/etc/ansible/hosts
● INI format

Static Inventory
● Can have parent
groups
– “[southeast:children”
● Can use patterns to
match hosts

Ansible Ad-hoc Commands
● Ansible can run ad-hoc commands,
● Ad-hoc commands can be used to
– learn ansible or
– run once off commands,
● Primarily playbooks are used to run ansible configurations tasks
● Before running anbsile commands the target node’s hostkey
– must be in known_hosts or
– host key checking must be disabled in ansible.cfg
● Initially we will use password based authentication to run ansible

Ansible Ad-hoc Commands
● Ansible can run ad-hoc commands,
● Ad-hoc commands can be used to
– learn ansible or
– run once off commands,
● Primarily playbooks are used to run ansible configurations tasks
● Before running anbsile commands the target node’s hostkey
– must be in known_hosts or
– host key checking must be disabled in ansible.cfg
● Initially we will use password based authentication to run ansible

Ansible Ad hoc Commands
● “ansible {pattern} -m {module} -a “{options}” {flags}”
– pattern : which hosts
– module : which ansible module (command by default)
– options : which module options
● flags : command flags
– “-u {username}”: to run the command as a different user (useraccount by default)
– “--ask-pass”, “-k”: prompt for user password. Used if ssh keys are not sued for authentication
– “-f {n}”: to run the command in n parallel forks (5 by default)
– “--become”, “-b”: to run the command through sudo
– “--ask-become-pass”,”-K”: to interactively prompt you for the sudo password to use
– “-i {file}”: inventory file to use
– “--ask-vault-pass”: to specify the vault-password interactively

Ad-hoc Command & Modules
● As stated previously functionality is provided by
modules,
● Ansible ad-hoc command can take a module option,
– “command” is the default module if none is specified
● The “-a” option takes the module parameters as
arguments. These are the same parameters used in
playbooks,

Ansible Ad hoc Commands
Examples
● Examples: ansible <pattern_goes_here> -m <module_name> -a <arguments>
– Ansible Ping Hosts
● “ansible webhosts -m ping”
– Manage a service
● ‘ansible webservers -m service -a "name=httpd state=restarted"’
– File transfer
● ‘ansible all -m copy -a "src=/etc/hosts dest=/tmp/hosts"’
– Deploying from source control
● ‘ansible webservers -m git -a "repo=git://foo.example.org/repo.git dest=/srv/myapp
version=HEAD"’
– Gathering facts
● ‘ansible all -m setup’

Configure node targets for key
based access
● Copy over key of Ansible admin to authorised key file on target
– “ssh-copy-id ansible@example.co.za”
● Edit /etc/sudoers file on target. Either
– ad an user entry for the remote ansible user or
● “ansible ALL=(ALL:ALL) NOPASSWD: ALL”
– make ansible user member of wheel group and enable passwordless
sudo
● ”usermod -a -G sudo ansible”
● “%sudo ALL=(ALL:ALL) NOPASSWD: ALL”

PlayBooks
● Ansible's configuration and orchestration language
● Describe policy of desired state of node
● Can be used form mange configurations or roll-outs of complex software
solutions
● Expressed in YAML language
● Composed of one or more “plays” in a list
– A play can consist of multiple tasks
● Allowing multi-machine deployments orchestration
● Support templating—both in playbooks and in file templates—by way of Jinja2
● Can be one file, or split up into many roles (more later!)

Ansible Playbooks

Playbook Syntax
● hosts:
– one or more group or host patterns
● vars:
– Playbook variables
● tasks:
– List of tasks to run for the play
● handlers:
– List of handlers – handler are called by notify parameter to a task
● remote_user : (not shown in example)
– the name of the remote user account (per play or task)
● become/sudo: (not shown in example)
– run tasks using sudo (per play or task)
● become_user/sudo_user: (not shown in example)
– sudo to a different user than root

Playbook Syntax - Tasks
● Are executed in order against all
machines matched by the host
pattern
● May be Included from other files
● Hosts with failed tasks are taken
out for the entire playbook
● Each task executes a module with
specific options
● Modules are idempotent in order to
bring the system to the desired
state
tasks:
- include: tasks/foo.yml
Task Syntax
tasks:
- name: {task name}
{module}: {options}

Playbooks Tasks - Handlers
● Notifications may be triggered at the end of each task
whenever a change has been made on the remote system
● Handlers are referenced by name
tasks:
- name: template configuration file
template: src=template.j2 dest=/etc/foo.conf
notify:
- restart apache
...
handlers:
- name: restart apache
service: name=apache state=restarted

Ansible Inventory Parameters
● Used in
– inventory file,
– hosts_vars files,
– group_vars files
● ansible_connection: local, ssh or paramiko
● ansible_ssh_host: the name of the host to connect to
● ansible_ssh_port: the ssh port number if not 22
● ansible_ssh_user: the ssh user name to use
● ansible_ssh_pass: the ssh password to use(insecure)
● ansible_ssh_private_key_file: private key file used by ssh
● ansible_python_interpreter: path to python interpreter tou es

Ansible Variables
● Variables are defined
– in yaml as
● “name: value”
– In ini files as
● “name=value”
● Variables can be defined on a per
– host,
● Inventory file
● host_vars folder
– playbook,
– group,
● Inventory file
● group_vars folder
– Roles
● host_vars,
● group_vars
● defaults

Roles
● A way to organise tasks in a DRY way,
● Based on known folder structure and file name
– Each folder should contain a file named
● “main.yml”
– The playbooks contain set up and configuration
parameters. Roles contains tasks, handler and
variables
Referenced in playbook via
the “roles” key
Referenced in playbook via
the “roles” key

Roles main.yml
● Tasks defined in the
tasks/main.yml are just a list of
tasks as per an ordinary
playbook,
● For var/main.yml,
handlers/main.yml etc the yaml
files simply contain a list of
variables, handlers etc as per
playbooks not using roles,
● Roles are primarily a way to
manage and organise task

Docker Vault
● Allows keeping encrypted data in source control
● Used to encrypt enitre playbook or can be used to encrypt passwords in plain text files
● Created encrypted files
– “ansible-vault create foo.yml”
● Editing encrypted files
– “ansible-vault edit foo.yml”
● Encrypting unencrypted files
– “ansible-vault encrypt foo.yml”
● Decrypting encrypted files
– “ansible-vault decrypt foo.yml”
● Running ad-hoc or playbook with vault
– “ansible-playbook site.yml –vault-password-file ~/.vault_pass.txt”