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

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: Albert 
    number: +1000000000 
    country: USA 
  - name: David 
    number: +44000000000 
    country: UK 

Those are the basics of YAML. YAML can do much more, but for now this will be enough.

As we have seen in the previous chapter, it is possible to use Ansible to automate simple tasks that you probably already perform daily.

Let's start by checking if a remote machine is reachable; in other words, let's start by pinging a machine. The simplest way to do this, is to run the following:

$ ansible all -i HOST, -m ping

Here, HOST is an IP address, the Fully Qualified Domain Name (FQDN), or an alias of a machine where you have SSH access (you can use a Kernel-based Virtual Machine (KVM), as we have seen in the previous chapter).

In this case, we have performed it against a virtual machine on our system:

$ ansible all -i test01.fale.io, -m ping

You should receive something like this as a result:

test01.fale.io | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Now, let's see what we did and why. Let's start from the Ansible help. To query it, we can...

Playbooks are one of the core features of Ansible and tell Ansible what to execute. They are like a to-do list for Ansible that contains a list of tasks; each task internally links to a piece of code called a module. Playbooks are simple, human-readable YAML files, whereas modules are a piece of code that can be written in any language with the condition that its output be in the JSON format. You can have multiple tasks listed in a playbook and these tasks would be executed serially by Ansible. You can think of playbooks as an equivalent of manifests in Puppet, states in Salt, or cookbooks in Chef; they allow you to enter a list of tasks or commands you want to execute on your remote system.

One of the first options anyone picks up is the debug option. To understand what is happening when you run the playbook, you can run it with the verbose (-v) option. Every extra v will provide the end user with more debug output.

Let's see an example of using the playbook debug for a single task using the following debug options:

    Using /etc/ansible/ansible.cfg as config file 
 
    PLAYBOOK: setup_apache.yaml ******************************* 
    1 plays in setup_apache.yaml 
 
    PLAY [all] ************************************************ 
 
    TASK [setup] ********************************************** 
    ok: [test01.fale.io] 
 
    TASK [Ensure the HTTPd package is installed] ************** 
    task path: /home/fale/setup_apache.yaml:5 
    ok:...

Sometimes it is important to set and get variables in a playbook.

Very often, you'll need to automate multiple similar operations. In those cases, you'll want to create a single playbook that can be called with different variables to ensure code reusability.

Another case where variables are very important is when you have more than one datacenter and some values will be datacenter-specific. A common example are the DNS servers. Let's analyze the following simple code that will introduce us to the Ansible way to set and get variables:

--- 
- hosts: all 
  remote_user: fale 
  tasks: 
  - name: Set variable 'name' 
    set_fact: 
      name: Test machine 
  - name: Print variable 'name' 
    debug: 
      msg: '{{ name }}' 

Let's run it in the usual way:

$ ansible-playbook -i test01.fale.io, variables.yaml

You should see the following result:

PLAY [all] **********************************************************
TASK [setup...

When you create a machine (or rent one from any hosting company) it arrives only with the root user. Let's start creating a playbook that ensures that an Ansible user is created, it's accessible with an SSH key, and is able to perform actions on behalf of other users (sudo) with no password asked. I often call this playbook, firstrun.yaml since I execute it as soon as a new machine is created, but after that, I don't use it since it uses the root user that I disable for security reasons. Our script will look something like the following:

--- 
- hosts: all 
  user: root 
  tasks: 
  - name: Ensure ansible user exists 
    user: 
      name: ansible 
      state: present 
      comment: Ansible 
  - name: Ensure ansible user accepts the SSH key 
    authorized_key: 
      user: ansible 
      key: https://github.com/fale.keys 
   state: present 
  - name: Ensure the ansible user is sudoer with no...

After we have created the user for Ansible with the necessary privileges, we can go on to make some other small changes to the OS. To make it more clear, we will see how each action is performed and then we'll look at the whole playbook.

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