LINUX AND VMWARE STUFF

YAML

YAML, like many other data serialization languages (such as JSON), has very few, basic concepts:

Declarations
Lists
Associative arrays

A declaration is very similar to a variable in any other language, that is:
name: 'This is the name' 

To create a list, we will have to use '-':
- 'item1' 
- 'item2' 
- 'item3' 
YAML uses indentation to logically divide parents from children. So if we want to create associative arrays (also known as objects), we would just need to add an indentation:

item: 
  name: TheName 
  location: TheLocation 
Obviously, we can mix those together, that is:

people: 
  - name: Jhon
    number: +91123456
    country: India
  - name: Cena
    number: +44763520 
    country: UK 
Those are the basics of YAML. YAML can do much more, but for now this will be enough.

Studying the anatomy of a Ansible Playbook

Playbooks can have a list of remote hosts, user variables, tasks, handlers, and so on. You can also override most of the configuration settings through a playbook. Let's start looking at the anatomy of a playbook.

The purpose of the playbook we are going to consider now, is to ensure that the httpd package is installed and the service is enabled and started. This is the content of the setup_apache.yaml file:

--- 
- hosts: all 
  remote_user: testuser
  tasks: 
  - name: Ensure the HTTPd package is installed 
    yum: 
      name: httpd 
      state: present 
      become: True 
  - name: Ensure the HTTPd service is enabled and running 
    service: 
      name: httpd 
      state: started 
      enabled: True 
    become: True 
The setup_apache.yaml file is an example of a playbook. The file is comprised of three main parts, as follows:

hosts: This lists the host or host group against which we want to run the task. The hosts field is mandatory and every playbook should have it. It tells Ansible on which hosts to run the listed tasks. When provided with a host group, Ansible will take the host group from the playbook and try look for it in an inventory file . If there is no match, Ansible will skip all the tasks for that host group. The --list-hosts option along with the playbook (ansible-playbook <playbook> --list-hosts) will tell you exactly which hosts the playbook will run against.
remote_user: This is one of the configuration parameters of Ansible (consider, for example, testuser -remote_user) that tells Ansible to use a particular user (in this case, testuser) while logging into the system.
tasks: Finally, we come to tasks. All playbooks should contain tasks. Tasks are a list of actions you want to perform. A tasks field contains the name of the task, a module that should be executed, and arguments that are required for the module. Let's look at the single task that is listed in the playbook, as shown in the preceding snippet of code:
Note
All examples in the book would be executed on CentOS, but the same set of examples with a few changes would work on other distributions as well.

In the preceding case, there are two tasks. The name parameter represents what the task is doing and is present mainly to improve readability, as we'll see during the playbook run. The name parameter is optional. The modules, yum and service, have their own set of parameters. Almost all modules have the name parameter (there are exceptions such as the debug module), which indicates what component the actions are performed on. Let's look at the other parameters:

In the yum module's case, the state parameter has the latest value and it indicates that the httpd latest package should be installed. The command to execute more or less translates to yum install httpd.
In the service module's scenario, the state parameter with the started value indicates that the httpd service should be started, and it roughly translates to /etc/init.d/httpd start. In this module we also have the "enabled" parameter that defines whether the service should start at boot or not.

True parameter represents the fact that the tasks should be executed with sudo access. If the sudo user's file does not allow the user to run the particular command, then the playbook will fail when it is run.

Note
Why there is no package module that figures out the architecture internally and runs the yum, apt, or any other package options depending on the architecture of the system. Ansible populates the package manager value into a variable named ansible_pkg_manager.

In general, we need to remember that the number of packages that have a common name across different operating systems is a small subset of the number of packages that are actually present. For example, the httpd package is called httpd in Red Hat systems and apache2 in Debian-based systems. We also need to remember that every package manager has its own set of options that make it powerful; as a result, it makes more sense to use explicit package manager names so that the full set of options are available to the end user writing the playbook.

Enabling EPEL repository by using ansible playbook

EPEL is the most important repository for Enterprise Linux and it contains a lot of additional packages. It's also a safe repository since no package in EPEL will conflict with packages in the base repository. To enable EPEL in RHEL/CentOS 7, it is enough to just install the epel-release package. To do so in Ansible, we will use:

$vi setup_epel.yaml

- name: Ensure EPEL is enabled 
  yum: 
    name: epel-release 
    state: present 
    become: True 

As you can see, we have used the yum module, specifying the name of the package and that we want it to be present.

Running this playbook
To instruct Ansible to execute a playbook instead of a module, we will have to use a command ansible-playbooks.

Syntax :  ansible-playbook -i HOST setup_epel.yaml

Command

$ ansible-playbook -i test01.fale.io setup_epel.yaml

here,

i   - group of server or server name (Inventory)

Installing Ansible from source in RHEL7

By default git package is installed in RHEL 7.

You can install Ansible directly from the source. Installing from source does not require any root permissions. Let's clone a repository and activate virtualenv, which is an isolated environment in Python where you can install packages without interfering with the system's Python packages. The command and the resulting output for the repository is as follows:

[root@nsk nsk]# git clone git://github.com/ansible/ansible.git
Cloning into 'ansible'...
remote: Counting objects: 282962, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 282962 (delta 2), reused 2 (delta 0), pack-reused 282953
Receiving objects: 100% (282962/282962), 91.03 MiB | 113.00 KiB/s, done.
Resolving deltas: 100% (183996/183996), done.
[root@nsk nsk]#
.
[root@nsk nsk]# cd ansible/
[root@nsk ansible]# source ./hacking/env-setup
Ansible now needs setuptools in order to build. Install it using your package manager (usually python-setuptools) or via pip (pip install setuptools).

Setting up Ansible to run out of checkout...

PATH=/home/nsk/ansible/bin:/home/nsk/ansible/test/runner:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
PYTHONPATH=/home/nsk/ansible/lib:
MANPATH=/home/nsk/ansible/docs/man:
Remember, you may wish to specify your host file with -i
Done!
[root@nsk ansible]#

Ansible needs a couple of Python packages, which you can install using pip. If you don't have pip installed on your system, install it using the following command. If you don't have easy_install installed, you can install it using Python's setuptools package on Red Hat systems, or by using Brew on the Mac:

[root@nsk ansible]# yum -y update
[root@nsk ansible]# cd ..
[root@nsk nsk]# curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1558k  100 1558k    0     0   104k      0  0:00:14  0:00:14 --:--:--  118k
[root@nsk nsk]# python get-pip.py
Collecting pip
  Downloading pip-9.0.1-py2.py3-none-any.whl (1.3MB)
    100% |████████████████████████████████| 1.3MB 113kB/s
Collecting setuptools
  Downloading setuptools-38.2.5-py2.py3-none-any.whl (489kB)
    100% |████████████████████████████████| 491kB 115kB/s
Collecting wheel
  Downloading wheel-0.30.0-py2.py3-none-any.whl (49kB)
    100% |████████████████████████████████| 51kB 125kB/s
Installing collected packages: pip, setuptools, wheel
Successfully installed pip-9.0.1 setuptools-38.2.5 wheel-0.30.0

Once you have installed pip, install the paramiko, PyYAML, jinja2, and httplib2 packages using the following command lines:

[root@nsk nsk]# pip install paramiko PyYAML jinja2 httplib2
Collecting paramiko
  Downloading paramiko-2.4.0-py2.py3-none-any.whl (192kB)
    100% |████████████████████████████████| 194kB 127kB/s
Collecting PyYAML
  Downloading PyYAML-3.12.tar.gz (253kB)
    100% |████████████████████████████████| 256kB 125kB/s
Collecting jinja2
  Downloading Jinja2-2.10-py2.py3-none-any.whl (126kB)
    100% |████████████████████████████████| 133kB 126kB/s
Collecting httplib2
  Downloading httplib2-0.10.3.tar.gz (204kB)
    100% |████████████████████████████████| 204kB 131kB/s
Collecting pyasn1>=0.1.7 (from paramiko)
  Downloading pyasn1-0.4.2-py2.py3-none-any.whl (71kB)
    100% |████████████████████████████████| 71kB 117kB/s
Collecting bcrypt>=3.1.3 (from paramiko)
  Downloading bcrypt-3.1.4-cp27-cp27mu-manylinux1_x86_64.whl (57kB)
    100% |████████████████████████████████| 61kB 174kB/s
Collecting cryptography>=1.5 (from paramiko)
  Downloading cryptography-2.1.4-cp27-cp27mu-manylinux1_x86_64.whl (2.2MB)
    100% |████████████████████████████████| 2.2MB 75kB/s
Collecting pynacl>=1.0.1 (from paramiko)
  Downloading PyNaCl-1.2.1-cp27-cp27mu-manylinux1_x86_64.whl (696kB)
    100% |████████████████████████████████| 706kB 106kB/s
Collecting MarkupSafe>=0.23 (from jinja2)
  Downloading MarkupSafe-1.0.tar.gz
Collecting six>=1.4.1 (from bcrypt>=3.1.3->paramiko)
  Downloading six-1.11.0-py2.py3-none-any.whl
Collecting cffi>=1.1 (from bcrypt>=3.1.3->paramiko)
  Downloading cffi-1.11.2-cp27-cp27mu-manylinux1_x86_64.whl (405kB)
    100% |████████████████████████████████| 409kB 124kB/s
Collecting enum34; python_version < "3" (from cryptography>=1.5->paramiko)
  Downloading enum34-1.1.6-py2-none-any.whl
Collecting asn1crypto>=0.21.0 (from cryptography>=1.5->paramiko)
  Downloading asn1crypto-0.24.0-py2.py3-none-any.whl (101kB)
    100% |████████████████████████████████| 102kB 123kB/s
Collecting idna>=2.1 (from cryptography>=1.5->paramiko)
  Downloading idna-2.6-py2.py3-none-any.whl (56kB)
    100% |████████████████████████████████| 61kB 134kB/s
Collecting ipaddress; python_version < "3" (from cryptography>=1.5->paramiko)
  Downloading ipaddress-1.0.19.tar.gz
Collecting pycparser (from cffi>=1.1->bcrypt>=3.1.3->paramiko)
  Downloading pycparser-2.18.tar.gz (245kB)
    100% |████████████████████████████████| 256kB 138kB/s
Building wheels for collected packages: PyYAML, httplib2, MarkupSafe, ipaddress, pycparser
  Running setup.py bdist_wheel for PyYAML ... done
  Stored in directory: /root/.cache/pip/wheels/2c/f7/79/13f3a12cd723892437c0cfbde1230ab4d82947ff7b3839a4fc
  Running setup.py bdist_wheel for httplib2 ... done
  Stored in directory: /root/.cache/pip/wheels/ca/ac/5f/749651f7925b231103f5316cacca82a487810c22d30f011c0c
  Running setup.py bdist_wheel for MarkupSafe ... done
  Stored in directory: /root/.cache/pip/wheels/88/a7/30/e39a54a87bcbe25308fa3ca64e8ddc75d9b3e5afa21ee32d57
  Running setup.py bdist_wheel for ipaddress ... done
  Stored in directory: /root/.cache/pip/wheels/d7/6b/69/666188e8101897abb2e115d408d139a372bdf6bfa7abb5aef5
  Running setup.py bdist_wheel for pycparser ... done
  Stored in directory: /root/.cache/pip/wheels/95/14/9a/5e7b9024459d2a6600aaa64e0ba485325aff7a9ac7489db1b6
Successfully built PyYAML httplib2 MarkupSafe ipaddress pycparser
Installing collected packages: pyasn1, six, pycparser, cffi, bcrypt, enum34, asn1crypto, idna, ipaddress, cryptography, pynacl, paramiko, PyYAML, MarkupSafe, jinja2, httplib2
Successfully installed MarkupSafe-1.0 PyYAML-3.12 asn1crypto-0.24.0 bcrypt-3.1.4 cffi-1.11.2 cryptography-2.1.4 enum34-1.1.6 httplib2-0.10.3 idna-2.6 ipaddress-1.0.19 jinja2-2.10 paramiko-2.4.0 pyasn1-0.4.2 pycparser-2.18 pynacl-1.2.1 six-1.11.0
[root@nsk nsk]#

Note
By default, Ansible will be running against the development branch. You might want to check out the latest stable branch. Check what the latest stable version is using the following command line:

[root@nsk ansible]# git branch -a
* devel
  remotes/origin/HEAD -> origin/devel
  remotes/origin/devel
  remotes/origin/release1.5.0
  remotes/origin/release1.5.1
..
  remotes/origin/stable-2.0-network
  remotes/origin/stable-2.0.0.1
  remotes/origin/stable-2.1
  remotes/origin/stable-2.2
  remotes/origin/stable-2.3
  remotes/origin/stable-2.4
  remotes/origin/temp-staging-post-2.3.3
  remotes/origin/threading_instead_of_forking
  remotes/origin/threading_plus_forking
[root@nsk ansible]#

Copy the latest version you want to use. Version 2.4 was the latest version available at the time of writing. Check the latest version using the following command lines:

[root@nsk ansible]# git checkout stable-2.4
Branch stable-2.4 set up to track remote branch stable-2.4 from origin.
Switched to a new branch 'stable-2.4'

[root@nsk nsk]# ansible --version
ansible 2.4.3.0 (stable-2.3 8708105616) last updated 2017/12/28 08:55:50 (GMT +550)
  config file = None
  configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /home/nsk/ansible/lib/ansible
  executable location = /home/nsk/ansible/bin/ansible
  python version = 2.7.5 (default, Aug  4 2017, 00:39:18) [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)]

You now have a working setup of Ansible ready.

Note : One of the benefits of running Ansible from source is that you can enjoy the new features immediately, without waiting for your package manager to make them available for you.