In the previous post, we looked at running Ad-Hoc commands on remote systems. In this post, we will see how can a playbook (a set of instructions and data in yaml format) be written to execute a set of tasks. We will continue to use the inventory file that we defined in the previous post.

admin_server1
admin_server2

[application_servers]
server_java_app1
server_php_app1
server_php_app2

[DB_servers]
server_oracle_1 primary_dns='172.16.1.1' secondary_dns='172.16.1.2'
server_mysql_1

[application_servers:children]
thirdparty_applications
secondparty_applications

[thirdparty_applications]
ftp_server_app1
monitoring_server_app

[secondparty_applications]
marketing_server_app

[application_servers:vars]
primary_dns=10.65.1.4

[DB_servers:vars]
primary_dns=11.65.1.4

[all:vars]
secondary_dns=172.65.1.3

Let’s look at the below example to understand the working of Ansible playbook. The playbook begins with three dashes, signaling the beginning of the document. This is followed by some yaml formatted data which are ‘hosts specification’, followed by a ‘set of tasks’ that should run on these hosts. We also see a ‘vars’ section where in, some variables are defined.

We already know from the previous post that, variables can be defined in the inventory file specific to hosts and groups. Variables can also be defined in a playbook. Variables defined in a playbook takes precedence over the inventory variables. The below example define a different primary and secondary DNS than the ones defined in the inventory. A typical task block includes a name section to describe the task, followed by the name of the ansible module with options. In the below example, we use the shell module to update the DNS and the service module to disable the NetworkManager service. These tasks are run on the group “application_servers” only and the user ID used to ssh to these machines is defined as “admin”.

---
- hosts: application_servers
  vars:
    primary_dns: 11.69.1.1
    secondary_dns: 172.68.1.7
  remote_user: admin
  
  tasks:
  - name: Update DNS records on remote systems
    shell: |
      echo "{{ primary_dns }}" > /etc/resolv.conf	  
      echo "{{ secondary_dns }}" >> /etc/resolv.conf	  
	  echo "search unixutils.com" >> /etc/resolv.conf

  - name: stop and disable network manager service
    service:
      name: NetworkManager
	  state: stopped 
      disabled: yes

Running an Ansible playbook

Command: ‘ansible-playbook path/to/playbooks/myplaybook.yml -u username -k -K’

(we already know that -k and -K makes Ansible prompt for password and sudo password respectively)

Playbooks can contain multiple plays. You may have a playbook that targets first the application_servers, and then the DB_servers servers. For example:

---
- hosts: application_servers
  remote_user: root

  tasks:
  - name: ensure wget package is at the latest version
    yum:
      name: wget
      state: latest

- hosts: DB_servers
  remote_user: admin

  tasks:
  - name: ensure openjdk-devel is at the latest version
    yum:
      name: java-1.8.0-openjdk-devel
      state: latest
      become: yes
  - name: ensure that firewalld is started
    service:
      name: firewalld
      state: started
      become: yes

NOTE: ‘become’ parameter when set to yes, makes the task run with sudo root privileges. we can also make the task run as a specific user by specifying the username. example ‘become: admin’. When the ‘become’ keyword is not specified, the task by default runs with the username that was used to ssh to the remote system.

Now let’s save this file as ‘test.yaml’ and run it on our inventory file ‘myinventory.ini’

Output:

[admin@unixutils ~]# ansible-playbook -i myinventory.ini test.yaml -k -K
SSH password:
SUDO password[defaults to SSH password]:

PLAY [application_servers] **************************************************************************************************************

TASK [Gathering Facts] ******************************************************************************************************************
ok: [server_java_app1]
ok: [server_php_app1]
ok: [server_php_app2]
ok: [marketing_server_app]
ok: [monitoring_server_app]
ok: [ftp_server_app1]

TASK [ensure wget package is at the latest version] *************************************************************************************
changed: [marketing_server_app]
ok: [ftp_server_app1]
ok: [monitoring_server_app]

PLAY [DB_servers] ***********************************************************************************************************************

TASK [Gathering Facts] ******************************************************************************************************************
ok: [server_oracle_1]
ok: [server_mysql_1]


PLAY RECAP ******************************************************************************************************************************
ftp_server_app1            : ok=2    changed=0    unreachable=0    failed=0
marketing_server_app       : ok=2    changed=1    unreachable=0    failed=0
monitoring_server_app      : ok=2    changed=0    unreachable=0    failed=0
server_java_app1           : ok=2    changed=0    unreachable=0    failed=0
server_mysql_1             : ok=1    changed=1    unreachable=0    failed=0
server_oracle_1            : ok=1    changed=1    unreachable=0    failed=0
server_php_app1            : ok=2    changed=0    unreachable=0    failed=0
server_php_app2            : ok=2    changed=0    unreachable=0    failed=0

[admin@unixutils ~]#

Ansible reports the status of the tasks for each host. ‘ok’ indicates that a task was not run since the expected result of a task is already satisfied and in place and hence successful. Whereas, a ‘Changed’ status indicates that the task was run and it was successful.

In this post we looked at how to write a set of tasks in a single playbook. Ansible allows us to create ‘roles’ which are a set of tasks that can be re-used in multiple playbooks. This not only makes the code reusable but also helps in organizing the tasks. For instance, you can write an “add user” role to create user IDs, which can be imported into different playbooks to create a different set of users defined separately for the playbook. The idea of the role is to have the functionality of the code independent of the data that it uses to run the task. In future posts, we will look at how to define a role with examples.

This site uses Akismet to reduce spam. Learn how your comment data is processed.