How We Use Ansіble for Configuration of Our Environments

After testing several SMCs (Software configuration management), we have decided to choose Ansible as it is the most lightweight option and does not require a client-server implementation.

So, let’s get started and see how it works.

We set up ansible on the local machine. Personally, I am using Fedora release 22.

DNF is a new package manager, designed to replace yum.

The simplest thing Ansible can do, is running commands on servers. To do this, let’s write in the command line:

all  a command running for servers in the inventory file

-i   a path to the inventory file

-u   a user, under which we will access the servers

-m  module

You can also run any arbitrary command:

Displaying:

62.244.31.234 | success | rc=0 >> 

Wed Jun 29 06:20:19 EDT 2015 

62.244.31.235 | success | rc=0 >>

Wed Jun 29 06:20:19 EDT 2015

-a arbitrary command

The inventory file is a list of servers and groups

ip, domaine     List of Servers

test1, test2     Groups

If you run:

You see:

62.244.31.234 | success | rc=0 >>

Wed Jun 29 06:31:10 EDT 2015

The command applies only to the servers of a certain group.

A playbook is one of the main concepts in Ansible. This is a YAML file where we specify what actions must be done on the servers

In the example above we will install the docker package for docker hosts group and remove sendmail packages

name      An arbitrary designation of the task

yum        yum module

become    Switching user to superuser

If the playbook becomes large, and we need to run an action located somewhere in the end of the file,then we’d have to wait for quite a while.

To shorten the waiting time, ansible offers tags

Write in the command line:

PLAY [docker] *****************************************************************

GATHERING FACTS ***************************************************************

ok: [docker_ci]

TASK: [Copying docker-storage config] *****************************************

ok: [docker_ci]

PLAY RECAP ********************************************************************

docker_ci : ok=2 changed=0 unreachable=0 failed=0

-check       Check, but do not apply changes

-t            Tag

-skip-tags    Will perform all tasks except those that are specified

Tags can be also specified as follows:

Sometimes, having performed some changes, you need to restart the service. For this, ansible has handlers. Handlers are performed at the very end of the playbook, because playbook can have a lot of tasks that will restart the service

notify Specifies the name of the handler

Ansible has the variables. To omit the same values, let’s ​​define the variables:

{{}} Variables are defined in such brackets

Ansible has such a concept as facts, a set of information about the servers. To see the facts about a certain machine, let’s write:

62.244.31.234 | success >> {

«ansible_facts»: {

«ansible_all_ipv4_addresses»: [

«62.244.31.234»

],

«ansible_all_ipv6_addresses»: [],

«ansible_architecture»: «x86_64»,

«ansible_bios_date»: «NA»,

«ansible_bios_version»: «NA»,

«ansible_cmdline»: {

«quiet»: true

},

«ansible_date_time»: {

«date»: «2015-08-25»,

«day»: «25»,

«epoch»: «1440503957»,

«hour»: «07»,

«iso8601»: «2015-08-25T11:59:17Z»,

«iso8601_micro»: «2015-08-25T11:59:17.235193Z»,

«minute»: «59»,

«month»: «08»,

«second»: «17»,

«time»: «07:59:17»,

«tz»: «EDT»,

«tz_offset»: «-0400»,

«weekday»: «Вторник»,

«year»: «2015»

}

……………..

Facts are collected every time Ansible runs. If you put gather_facts:no in playbook, the facts will not be collected:

Let’s consider the cycles, as quite often you need to install lots of packages, which overwhelms playbook with similar tasks. For this, there is the key with_items:

There is another option of usage, by applying several parameters: