Deploying By Ansible

Deploying By Ansible
Ansible Inventory
 An inventory defines a collection of hosts that Ansible will manage.
 Host inventories can be defined in two different ways
o Static Host Inventory
 A static host inventory can be defined by a text file
o Dynamic Host Inventory
 A dynamic host inventory can be generated by a script
or other program as needed, using external information
providers.
 Ansible Managed hosts can be managed with following ways
o Individual
o It can assign to groups, which can be managed collectively.
o Groups can contain child groups.
o Hosts can be members of multiple groups.

Note – Ansible has default 2 group “all and ungrouped”, where all group
will show list of all managed host and ungrouped will show the managed
host which is not a part of any group

 “/etc/ansible/hosts” is a global inventory file but we can create local

inventory file also that can call by --inventory (-i) option.

 Create Inventory
# cat /etc/ansible/hosts | tail -20

 List all ansible managed host

# ansible all --list-host
Deploying By Ansible

 List ungrouped host, which is not a part of any group

# ansible ungrouped --list-host

 List one managed host

# ansible webserver1-prod.example.com --list-host

 List webprod group of managed host

# ansible webprod --list-host

 List mumbairegion group of managed host

# ansible mumbairegion --list-host

Overriding the Location of the Inventory

# ansible all –i inventory.ini --list-host

Host Patterning
 mumbairegion:canadaregion:- It will show all the host which are
member of these two groups, but remember it will not show the
repeated host name either one host will be member of multiple host
group.
 “mumbairegion:&canadaregion” - Here & is for intersection means
it will only shows those host which is only repeated in both host
group
Deploying By Ansible

 “mumbairegion: canadaregion:!servera.example.com”- Here ! is

exception It will shows all the host name associated with these
host group except servera.example.com
 “192.16*”- Here * means every host whose initial numbers are
192.16

Ansible Infrastructure
 While communicating managed host, we can connect by using
password or without password.

 And we can use root or local user both to connect with managed
host

 If we use local user then we should also take care of SUDO

prevelige of local user

Authentication with root

 Password based Authentication

# ansible 192.168.0.105 -u root -k -m ping

# ansible 192.168.0.105 -u root -k -m setup

 For Password less Authentication we need to generate key on both

node using “ssh-keygen” then copy it to other node by “ssh-copy-id
root@hostname”.

# ansible 192.168.0.105 -u root -m setup

Authentication by Local User

 As we know that Ansible can execute task with root but for security
concern ssh is denied for root. So we need to execute task with
local account

# ansible 192.168.0.105 -u devops -k -m ping

# ansible 192.168.0.105 -u devops -k -m setup

 For Password less Authentication in Ansible we need to generate

key on both node using “ssh-keygen” then copy it to other node by
“ssh-copy-id user@hostname”.

# ansible 192.168.0.105 -u devops -m setup

Deploying By Ansible

# ansible 192.168.0.105 -u devops -m ping

SUDO Configuration for Ansible

 Local user has limited access, so in Linux prevelige is assign to
local user using SUDO
 On every managed Host
# visudo

devops ALL=(ALL) NOPASSWD: ALL

 Control Node
# ansible 192.168.0.105 -u devops --become -m setup

 If we do not set NOPASSWD parameter for user in SUDO in that case

we need to force the ansible to ask sudo password by using - -ask-
sudo-pass.

# ansible 192.168.0.105 -u devops --become --ask-sudo-pass -m setup

Ansible Configuration
 Ansible has global configuration file as /etc/ansible/ansible.conf.

 Ansible.cfg file has classified in different sections

o [defaults]
 Most of the settings in the configuration file are grouped
under the [defaults] section.
o [privilege_escalation]
 This section contains settings for defining how
operations which require escalated privileges will be
executed on managed hosts.
o [paramiko_connection], [ssh_connection] and [accelerate]
 These sections contain settings for optimizing
connections to managed hosts.
o [selinux]
 This section contains settings for defining how SELinux
interactions will be configured. While not included in the
default global Ansible configuration file provided by the
ansible package.
o [galaxy]
Deploying By Ansible

This section is also available for defining parameters

related to Ansible Galaxy, which is discussed in a later
chapter.
[root@servera ~]# grep "^\[" /etc/ansible/ansible.cfg

[defaults]

[privilege_escalation]

[paramiko_connection]

[ssh_connection]

[accelerate]

[selinux]

[colors]

Customizing location of ansible.cfg

 Most parameters of ansible.cfg can be overridden in ansible-
playbook or with command line flags
 But to shortend the execution we can update in ansible.cfg.
However local users do not have access to modify global
configuration file, so ansible has many way to create ansible.cfg.
o Using variable ANSIBLE_CONFIG
o ansible.cfg in the current working directory
o .ansible.cfg in the home directory
o /etc/ansible/ansible.cfg
Configuration file’s preferences
 Using Default Location
$ ansible --version

 Using Ansible variable

$ export ANSIBLE_CONFIG=/opt/myansible.cfg
$ echo $ANSIBLE_CONFIG
$ ansible --version

 Using present working directory

$ mkdir ansible
$ touch /home/linux2cloud/ansible/ansible.cfg
$ cd ansible/
Deploying By Ansible

$ ansible --version

 Using Home Directory

$ touch ~/.ansible.cfg
$ ansible --version

Customizing option in ansible.cfg

 This controls whether an Ansible playbook should prompt for a
password by default. The default behaviour is no:

ask_pass = True
Note: if using SSH keys for authentication, it’s probably not needed to
change this setting

 Similar to ask_pass, this controls whether an Ansible playbook

should prompt for a sudo password by default when sudoing. The
default behaviour is also no:

ask_sudo_pass = True

 As described in Getting Started, host key checking is on by default

in Ansible 1.3 and later. If you understand the implications and wish
to disable it, you may do so here by setting the value to False:

host_key_checking = True

 To change location of inventory file

inventory= /home/linux2cloud/ansible/inventory

 It will use this user name if no user name specified


remote_user=root

 Coma-separated list of file extension patterns to ignore when

Ansible inventory is a directory with multiple sources (static and
dynamic):

inventory_ignore_extensions = ~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo

Deploying By Ansible

Note: for more detail http://docs.ansible.com/ansible/latest/intro_configuration.html

Ansible Module
 Modules are programs that Ansible uses to perform operations on
managed hosts. They are ready-to-use tools designed to perform
specific operations. Modules can be executed from the ansible
command line or used in playbooks to execute tasks.
 Ansible comes packaged with over 200 modules available for use.
These prepackaged modules can be used to perform a wide range of
tasks, such as cloud, user, package, and service management.
 There are three types of Ansible modules
o Core
o Extras
o Custom modules

Core Module
 Core modules are included with Ansible and are written and
maintained by the Ansible development team. Core modules are the
most important modules and are used for common administration
tasks.

Extra Module/Community Module

 Extras modules are currently included with Ansible but may be
promoted to core or shipped separately in the future.
 They are generally not maintained by the Ansible team but by the
community. Typically, these modules implement features for
managing newer technologies such as OpenStack.

Custom Module
 Custom modules are modules developed by end users and not
shipped by Ansible. If a module does not already exist for a task, an
administrator can write a new module to implement it.
Module categories
 For better organization and management, Ansible modules are
grouped into the following.
 Functional categories. On Linux systems, modules are installed in
the /usr/lib/python<version>/site-packages/ansible/modules/.
o Cloud
o Clustering
o Commands
o Database
o Files
Deploying By Ansible

o Inventory
o Messaging
o Monitoring
o Network
o Notification
o Packaging
o Source Control
o System
o Utilities
o Web Infrastructure
o Windows

Ansible-doc
 The ansible-doc command also offers a -s (or --snippet) option,
which produces example output that can serve as a model for how
to use a particular module in a playbook. This output can serve as a
starter template which can be included in a playbook to implement
the module for task execution.

 To see a list of the modules available on a control node, run the

ansible-doc -l command

# ansible-doc –l

# ansible-doc –s yum

# ansible-doc yum

METADATA Section
 The ansible-doc documentation for the module is expected to
specify who maintains that module in the upstream Ansible
community, and what its development status is. This is indicated in
the METADATA section at the end of the output of ansible-doc for
that module.

 The status field records the development status of the module:

Means who maintains that module in the upstream Ansible
Deploying By Ansible

o stableinterface: The module's keywords are stable, and every

effort will be made not to remove keywords or change their
meaning.

o preview: The module is in technology preview, and might be

unstable, its keywords might change, or it might require
libraries or web services that are themselves subject to
incompatible changes.

o deprecated: The module is deprecated, and will no longer be

available in some future release.

o removed: The module has been removed from the release, but
a stub exists for documentation purposes to help former users
migrate to new modules.

 The supported_by field records who maintains the module in the

upstream Ansible community. Possible values are:
o core:
 Maintained by the "core" Ansible developers upstream,
and always included with Ansible.
# ansible-doc yum

o curated
 Modules submitted and maintained by partners or
companies in the community. Maintainers of these
modules must watch for any issues reported or pull
requests raised against the module.
 Upstream "core" developers review proposed changes
to curated modules after the community maintainers
have approved the changes.
 Core committers also ensure that any issues with these
modules due to changes in the Ansible engine are
remediated.
Deploying By Ansible

 These modules are currently included with Ansible, but

might be packaged separately at some point in the
future.

o Community
 Modules not supported by the core upstream developers,
partners, or companies, but maintained entirely by the
general open source community. Modules in this
category are still fully usable, but the response rate to
issues is purely up to the community. These modules are

# ansible-doc kubernetes

# ansible-doc k8s_raw

Custom Modules
 Custom Modules are available on
https://github.com/ansible/ansible/issues

 On local system if we have custom modules we can stores at

library = /usr/share/my_modules

 Ansible searches for custom modules in the location specified by

the ANSIBLE_LIBRARY environment variable
Or
 Ansible also searches for custom modules in the ./library directory
relative to the playbook currently being run

Idempotentency with Module

 Ansible modules are idempotent in nature (except command, shell
and raw module).
Deploying By Ansible

 It means ansible module do not make unnecessary changes if the

managed hosts are already in the correct state.
 When possible, try to avoid the command, shell, and raw modules,
because everytime these module will make change either server is
in drift or desired state

Lab
1. Create a local user “student” on control node.

2. Create devops user with no sudo password on managed host.

3. Set password less authentication between student and devops user

of all managed host.
4. Login with student, create inventory file in home directory that
should have grouped and ungrouped hosts
5. Host group should be oracle, mysql.
6. Create one more host group database, that should have host which
is associated with oracle and mysql host group.
7. Create configuration file in home directory and set inventory
file and remote user as devops
8. Setup privilege_escalation in configuration file created in home
directory and capture ansible facts of server

Summary
- Ansible Static Inventory

- Configure Ansible Infra, using SUDO

- Ansible Configuration file and it’s priority

- Ansible Module and it’s type

- Ansible Doc and it’s sections