Skip to content

Play with Ansible Playbooks

Avatar photo

https://www.linkedin.com/in/gineesh/ https://twitter.com/GiniGangadharan

Plays are ordered set of tasks to execute against host selections from your inventory. A playbook is a file containing one or more plays.

See all parts of  Automation with Ansible Guides here

Tasks → Plays → Playbook

It is important to learn about the ansible playbook syntax where spacing and indentation is very critical. If you are using visual editors, you can get plugins for ansible as it will help on syntax and options. But if you are using a CLI editor like vim or nano, please make sure you are following correct indentation.

Learn more about customization of vim editor for ansible playbook.

YAML format

  • Start with — (3 consecutive hyphens)  end with … (optional)
  • A list– begin with dash followed by space
  • attribute definition
    attribute1: value1
    attribute2: value2
  • Comments are preceded by #
  • Warning: DO NOT use TAB! (unless you configured tab expand)
  • Multiple Lines:
    address: |
                 1, Jalan 2,
                 Main Block,
                 89892 Abc, My.
    my_note: >
                 This is a single
                 line of text.

Refer this guide for some yaml rules.

Your First Playbook

Let’s start writing our playbook; in this case we will add tasks for installing a webserver and enable firewall rules for the same.

Start your playbook

As you can see below, we have started our playbook by “—” and then named it as “Enable Intranet Services“. We have also mentioned hosts as node1.techbeatly.com. (It can be a single node, a group like database server or all nodes.) Since we need privileged permissions we have enabled become: yes. We will add tasks under tasks: section.

---
- name: Enable Intranet Services
  hosts: node1.techbeatly.com
  become: yes
  tasks:

Add our first task to the Play – install packages

Let’s add tasks to install webserver and firewall services.

    - name: Install httpd and firewalld
      yum:
        name: 
          - httpd
          - firewalld
        state: latest

You can see, we have a name for the task (not mandatory but keeping a name is a good practice) and task must be started with a “-“. Here we called the yum module inside the task, added required parameters as list – httpd and firewalld. state means the required state to be achived, in this case we are asking to install the latest package. (It can be present for installing or absent for uninstalling the package)

Add task for enable firewall and http

Next we will add a task for enable and running the firewall service which we have installed in previous play.

    - name: Enable and Run Firewalld
      service: 
        name: firewalld
        enabled: true
        state: started

Above is self explanatory; it is calling the service module, asking to enable firewalld service (make it running every time the system boot), and also start the firewalld service – state : started. (It can be stopped or restarted as you need)

Next we need to enable http traffic over firewall and we will use the firewall module for that. Below task will enable the http traffic over firewall, make the rule permanent and this will effect immediate.

    - name: firewalld permitt httpd service
      firewalld:
        service: http
        permanent: true
        state: enabled
        immediate: yes

Let’s add another task to start and enable httpd service.

    - name: httpd enabled and running
      service:
        name: httpd
        enabled: true
        state: started

Finally we need to add a task to install the very basic index.html file for our web server; we will use the copy module as below.

    - name: Test html page is installed
      copy:
        content: "Welcome to the example.com intranet!\n"
        dest: /var/www/html/index.html

That’s all; we have our first playbook to install a web server, install the firewall service, enable both services and opening firewall port http with  very basic index page. Hold on, how we gonna test this webserver ? Come on, we are automating everything, you should add a task to test this, instead of checking this on browser or CLI.

Another play in same playbook for testing our webserver

So, we are just adding another pay (not a task) to differentiate the actual implementing tasks and test tasks. In this case, we know we have run this from localhost and not from the node. So our hosts: localhost as shown below. Since we don’t need privilege to test this, lets add become: no. We will use the uri module to test page by checking the status_code: 200.

- name: Test intranet web server
  hosts: localhost
  become: no
  tasks:
    - name: connect to intranet webserver
      uri: 
        url: http://lab.techbeatly.com
        status_code: 200       

Full playbook

So we have the final playbook with two plays and multiple tasks as below.


- name: Enable Intranet Services
  hosts: node1.techbeatly.com
  become: yes
  tasks:
    - name: Install httpd and firewalld
      yum:
        name: 
          - httpd
          - firewalld
        state: latest
    - name: Enable and Run Firewalld
      service: 
        name: firewalld
        enabled: true
        state: started
    - name: firewalld permitt httpd service
      firewalld:
        service: http
        permanent: true
        state: enabled
        immediate: yes
    - name: httpd enabled and running
      service:
        name: httpd
        enabled: true
        state: started
    - name: Test html page is installed
      copy:
        content: "Welcome to the example.com intranet!\n"
        dest: /var/www/html/index.html
- name: Test intranet web server
  hosts: localhost
  become: no
  tasks:
    - name: connect to intranet webserver
      uri: 
        url: http://lab.techbeatly.com
        status_code: 200

Running the playbook

You have to use the ansible-playbook command to run the playbook.

$ ansible-playbook myintranet.yml

There are few options available for ansible-playbook command, like enable or disable privileged mode, add additional variables etc. We will cover that in upcoming sessions.

See all parts of  Automation with Ansible Guides here

Disclaimer:

The views expressed and the content shared in all published articles on this website are solely those of the respective authors, and they do not necessarily reflect the views of the author’s employer or the techbeatly platform. We strive to ensure the accuracy and validity of the content published on our website. However, we cannot guarantee the absolute correctness or completeness of the information provided. It is the responsibility of the readers and users of this website to verify the accuracy and appropriateness of any information or opinions expressed within the articles. If you come across any content that you believe to be incorrect or invalid, please contact us immediately so that we can address the issue promptly.

Avatar photo


https://www.linkedin.com/in/gineesh/ https://twitter.com/GiniGangadharan
Gineesh Madapparambath is the founder of techbeatly and he is the co-author of The Kubernetes Bible, Second Edition. and the author of 𝗔𝗻𝘀𝗶𝗯𝗹𝗲 𝗳𝗼𝗿 𝗥𝗲𝗮𝗹-𝗟𝗶𝗳𝗲 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻. He has worked as a Systems Engineer, Automation Specialist, and content author. His primary focus is on Ansible Automation, Containerisation (OpenShift & Kubernetes), and Infrastructure as Code (Terraform). (aka Gini Gangadharan - iamgini.com)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

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