An overview of the LPI-OT DevOps Tools Engineer certification's Ansible objectives. The slides cover the concepts and components of Ansible and demonstrate the basic principles of any infrastructure as code management tool such as idempotence and repeatability.

1. Ansible DevOps Training

2. 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

3. 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)

4. 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

5. How Ansible Works

6. 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

7. 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

8. 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

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

10. 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

11. 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

12. 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

13. 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,

14. 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’

15. 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”

16. 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!)

17. Ansible Playbooks

18. 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

19. 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}

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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”