Ansible 407

This exam is based on Red Hat® Enterprise Linux® 7.3 and Ansible 2.3.

Ansible tips

If you decide to use Ansible, make sure you set the proper configurations in the
/etc/ansible/ansible.cfg file. The bare minimum if you're using ssh keys (which I
highly recommend) instead of using root is set the following settings:

host_key_checking = False

Ansible has two components: Ansible Core and Ansible Tower. Core provides the Ansible
runtime that executes

 playbooks (yaml files defining tasks and roles) against

 inventories (group of hosts).
 Ansible Tower provides management, visibility, job scheduling, credentials,
RBAC, auditing / compliance and more.

Ansible Tower uses an Ansible playbook to deploy itself. As such configuration

parameters or groupvars are stored in inventory file.

Configuring Ansible Hosts

Ansible keeps track of all of the servers that it knows about through a "hosts" file.
We need to set up this file first before we can begin to communicate with our other
computers.

sudo vi /etc/ansible/hosts

ssh-keygen -b 2048 -t rsa

ssh-copy-id -i user01@server2.example.com

On the server2, edit the /etc/ssh/sshd_config file and set the following options:

PasswordAuthentication no
PubkeyAuthentication yes

Ansible basic commands

 ansible -m ping all

 ansible --list-hosts all

Ansible uses playbook to describe automation jobs and uses YAML – It is in human
readable form

Ansible Galaxy is Ansible’s official community hub for sharing Ansible roles. A role is
the Ansible way of bundling automation content and making it reusable.

Ansible Galaxy can help you: https://galaxy.ansible.com/

1. learn by example looking at the code other people have written and;
 2. develop great playbooks by orchestrating roles that have been created by the
community.

The thought process workflow - https://www.redhat.com/en/blog/developers-shortcut-

getting-started-ansible#

Ansible Basics

 Ansible Engine – The Ansible runtime and CLI which executes playbooks. The
engine runs on a management node, from where you want to drive automation.
 Playbook – A series or group of tasks that automate a process. Playbooks are
written in YAML.
 Inventory – Determines what hosts you want to run playbook against. Inventories
can be dynamic or static.
 Configuration – The configuration for Ansible is stored in ansible.cfg by
default under /etc/ansible/ansible.cfg. It determines default settings for
Ansible, where the inventory is located and much more. You can have many
ansible.cfg files.
 Role – Ansible way to build re-usable automation components. A role groups
together playbooks, templates, variables and everything needed to automate a
given process in a pre-packaged unit of work.
 Ansible Galaxy – Ansible roles provided by the Ansible community. Not only can
you get access to 1000s of roles, but you can share as well.
 Ansible Modules – Used in Ansible to perform tasks, install software, enable
services, etc. Modules are provided with Ansible (core modules) and provided by
the community. They are mostly written in python which is used by Ansible
itself.
 Ansible Tower – API and UI for Ansible to handle scheduling, reporting,
visualization and support teamwork for organizations running many playbooks
across many teams.
Ansible Complete Beginners Tutorial:

DONT MISS THIS IF YOU ARE SERIOUSLY INTERESTED TO LEARN "ANSIBLE" FROM BEGINNING. LINKS
ARE ARRANGED TO MAKE YOU UNDERSTAND EASILY.

Spend few minutes and start working on Ansible. Make use of it, Share to your friends
and groups.

 https://keithtenzer.com/2017/11/09/ansible-getting-started-guide/ - read this

guide
 https://www.jeffgeerling.com/blog/automating-your-automation-ansible-tower
 https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-
ansible-on-centos-7
 https://www.linuxtechi.com/install-and-use-ansible-in-centos-7/
 https://serversforhackers.com/c/an-ansible-tutorial
 http://devopstechie.com/install-and-configure-ansible-tower-centos7/


1. What is Ansible, Why do we use Ansible, Ansible Terminologies

Document: http://www.learnitguide.net/…/what-is-ansible-how-ansible-w…

Youtube: https://www.youtube.com/watch?v=kyS_AP0XHyU

2. Ansible Inventory Management for Beginners

Document: http://www.learnitguide.net/…/ansible-inventory-introductio…

Youtube Video: https://www.youtube.com/watch?v=1awOyxjLvZQ

3. Ansible Configuration Management
Document: http://www.learnitguide.net/…/managing-ansible-configuratio…

Youtube: https://www.youtube.com/watch?v=KuTPh4GUGdc

4. Ansible Ad-Hoc Commands with Examples Explained

Document: http://www.learnitguide.net/…/ansible-ad-hoc-commands-ansib…

Youtube Video: https://www.youtube.com/watch?v=nuN2WrRIEP8

5. Ansible Playbook Beginners Tutorial

Document: http://www.learnitguide.net/…/ansible-playbook-tutorial-wit…

Youtube Video: https://www.youtube.com/watch?v=4sNdq6fjZFQ

6. Ansible Roles Explained in Detail - Create Your First Ansible Roles

Document: http://www.learnitguide.net/…/ansible-roles-explained-with-…

Youtube Video: https://www.youtube.com/watch?v=KgoDnSGvJJg

7. Ansible Vault to Protect Ansible Playbooks with Encryption

Document: http://www.learnitguide.net/…/how-to-use-ansible-vault-to-p…

YouTube Video: https://www.youtube.com/watch?v=VKbvhuRjNeE

Also there are more other videos on Puppet, Openstack cloud, VCS Cluster....
For more free documents and tutorial videos,
Like us on Facebook : https://www.facebook.com/learnitguide
Subscribe on Youtube : https://www.youtube.com/learnitguide
Follow us on Twitter : https://www.twitter.com/learnitguide
Visit our Website : https://www.learnitguide.net

#ansible #devops #devopstool #devopsadmin #devopsgroup #ansibleplaybook #automation

####################################################################################

You should be able to:

 Understand core components of Ansible

o Inventories
o Modules
o Variables
o Facts
o Plays
o Playbooks
o Configuration files
 Install and configure an Ansible control node
o Install required packages
o Create a static host inventory file
o Create a configuration file
 Configure Ansible managed nodes
o Create and distribute SSH keys to managed nodes
o Configure privilege escalation on managed nodes
o Validate a working configuration using ad-hoc Ansible commands
 Create simple shell scripts that run ad hoc Ansible commands
 Use both static and dynamic inventories to define groups of hosts
  Utilize an existing dynamic inventory script
 Create Ansible plays and playbooks
o Know how to work with commonly used Ansible modules
o Use variables to retrieve the results of running commands
o Use conditionals to control play execution
o Configure error handling
o Create playbooks to configure systems to a specified state
 Use Ansible modules for system administration tasks that work with:
o Software packages and repositories
o Services
o Firewall rules
o File systems
o Storage devices
o File content
o Archiving
o Scheduled tasks
o Security
o Users and groups
 Create and use templates to create customized configuration files
 Work with Ansible variables and facts
 Create and work with roles
 Download roles from an Ansible Galaxy and use them
 Manage parallelism
 Use Ansible Vault in playbooks to protect sensitive data
 Use provided documentation to look up specific information about Ansible modules
and commands

####################################################################################

The Ansible exam focused on

 Writing Ansible playbooks,

 working with Ansible inventories including dynamic inventories,
 running ad-hoc Ansible commands,
 leveraging Ansible facts,
 creating Jinja2 templates,
 error handling,
 playbook tags,
 downloading a role from Ansible Galaxy and
 using Ansible vault to secure passwords.

Exam Tips

1. Use the ansible-playbook --limit parameter, to try out your playbook against a
single host first before applying it to all your hosts.
2. Make sure you can run Ansible modules as ad-hoc commands. They can come handy when
you want to undo the effects of running an erroneous playbook.
3. Use ansible-doc --list to look up a module that can achieve your goal and ansible-
doc <module> to learn about the module parameters and example usage.
4.

Managed hosts are listed in an inventory, which also organizes those systems into
groups for easier collective management. The inventory can be defined in a static text
file, or dynamically determined by scripts that get information from external sources.
A play performs a series of tasks on the host or hosts, in the order specified by the
play. These plays are expressed in YAML format in a text file. A file that contains one
or more plays is called a playbook.

NB: Tasks, plays, and playbooks should be idempotent.

In the following example, the host inventory defines two host groups, webservers and
db-servers.

[webservers]

web1.example.com

web2.example.com

192.0.2.42

[db-servers]

db1.example.com

db2.example.com

Two host groups always exist:

• The all host group contains every host explicitly listed in the inventory.

• The ungrouped host group contains every host explicitly listed in the inventory that

isn't a member of any other group.

Overriding the Location of the Inventory

The /etc/ansible/hosts file is considered the system's default static inventory file.

The /etc/ansible/ansible.cfg configuration file is the default config file.

Because of the multitude of locations in which Ansible configuration files can be

placed, it can be confusing which configuration file is being used by Ansible,
especially when multiple files exist on the control node. You can run the

# ansible --version command or use ansible servers --list-hosts -v

to clearly identify which version of Ansible is installed, and which configuration file
is being used.

# ansible all -m ping

# ansible ltzservers -m ping – ltzservers is a hostgroup

# ansible all -i /home/mildred/install/inventory --list-hosts -v

Common ansible modules

  File modules, such as copy (copy a local file to the managed host),
 get_url (download a file to the managed host),
 synchronize (to synchronize content like rsync),
 file (set permissions and other properties of a file), and
 lineinfile (make sure a certain line is or isn't in a file)
 Software package management modules, such as yum, dnf, apt, pip, gem, and so on
 System administration tools, such as service, to control daemons, and user, to
o add,
o remove and
o configure users
 uri, which interacts with a web server and can test functionality or issue API
requests

# Ad hoc commands pass arguments to modules using the -a option.

#Its always recommended to create an ansible user to be used on all hosts

 #useradd -m mildred
 #usermod -aG wheel mildred

# ssh-keygen -b 2048 -t rsa

# Source of key(s) to be installed: "/home/mildred/.ssh/id_rsa.pub"

NB: Always create a projects directory to distinguish between different tasks and add an
inventory file for every project.

Roles

A role is a collection of tasks and templates (among other things, but those are the most
common) focused on one very specific goal. For instance, you can have a role that installs
nginx, another that deploys ssh keys for admins, etc…

Nginx role will install and configure nginx. Nothing else. It won’t create DNS entries, trim
logs, add a ftp server or anything. It just installs nginx. Period.

Another one: Roles are a way to make code in playbooks reusable by putting the functionality
into generalized "libraries" that can be then used in any playbook as needed.

Roles are a way to group tasks together into one container. You could have a role for setting up
MySQL, another one for setting up Postfix etc.

A playbook defines what is happening where. This is the place where you define the hosts
(hostgroups, see below) and the roles which will be applied to those hosts.

Inventories

An inventory is a list of hosts, eventually assembled into groups, on which you will run
ansible playbooks. Ansible automatically puts all defined hosts in the aptly named group all.
For instance, you could have hosts www1 and www2, assembled in group webservers, and later
reference the group or individual hosts, depending on your needs.

Inventories can also come with variables applied to hosts or groups (including all).

Inventories can be dynamic. If the inventory file is executable, Ansible will run it and use
its output as the inventory (note that, in this case, the format is not the same as static
inventory).

You can of course have multiple inventories, segregated from each other. We will take
advantage from this later on.

Playbooks

The last piece of the puzzle is the playbook. The playbook is the pivot between and inventory
and roles. This is where you basically tell Ansible: please install roles foo, bar and baz on
machines alice, bob and charlie.

# Playbooks consist of tasks which are executed in the order which they are listed in If a
tasks fails Ansible will stop executing further tasks on that specific system.

Playbooks are written in YAML syntax which is a data serialization format like XML and JSON but much
better human readable. A convention of YAML is to start every file with three dashes (—).

A simple Playbook which makes sure the user mikhail exists might look like this.

users.yml:

---
- hosts: all
sudo: yes
tasks:
- name: Configure Users
user: name=mikhail comment='Martin and Mildred’s son' group=admins
groups=wheel

When run this playbook will make sure that the user mikhail is present, that his primary group will be
admins and that he will be member of the group wheel. If this is not the case the system will ‘make it so’
and if it’s already the case it will do nothing, this is called ‘idempotent’ in configuration management
lingo, it doesn’t matter how many times you run the command, the endstate will always be the same.

You can specify the inventory by pointing to either a file, a script, or a directory:

 in command-line:
 ansible-playbook playbook.yml -i /path/to/inventory

The playbook directory is simply the one in which the playbook is stored.

in ansible.cfg:

inventory = /path/to/inventory
NB: In order for that line in ansible.cfg to work it MUST be in the [defaults] section or ansible will
refuse to use it

A play is a set of tasks or roles (or both) inside a playbook. In most cases (and examples) a
playbook will contain only one single play. But you can have as many as you like. That means
you could have a playbook which will run the role postfix on the hostgroup mail_servers and
the role mysql on the hostgroup databases:

- hosts: mail_servers
roles:
- postfix

- hosts: databases
roles:
- mysql

AFAIK you have to provide the path to the playbook when invoking ansible-playbook. So ansible-
playbook someplaybook.yaml would expect someplaybook.yaml to be in you current directory.
But you can provide the full path: ansible-playbook /path/to/someplaybook.yaml

Note that the hosts file is known as the inventory file.