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 Syntaxtasks:- 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 filetemplate: src=template.j2 dest=/etc/foo.confnotify:- restart apache...handlers:- name: restart apacheservice: 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”