Playbook

Playbook

• A playbook is saved using the standard file extension .yml.

• Indentation with space character indicates the structure of the data in the file.

• YAML does not place strict requirements on how many spaces are used for the indentation, but there are two basic rules.

  • Data elements at the same level in the hierarchy (such as items in the same list) must have the same indentation.

  • Items that are children of another item must be indented more than their parents.

• Only the space character can be used for indentation. Tab characters are not allowed.

Limiting Playbook Execution

• A play has hosts: webservers in its definition

• datacenter2 and webservers are both groups in the inventory

• The play will only run on hosts that are in both webservers and datacenter2:

  • ansible-playbook site.yml --limit datacenter2

• If retry file is enabled, to re-run failed hosts:

  • ansible-playbook site.yml --limit @site.retry

Validating a Playbook

• Verify that playbook can be ingested by ansible

• ansible-playbook --syntax-check webserver.yml

Dry Run

• Report what changes would have occurred if the playbook were executed, but does not make any actual changes to managed hosts.

  • ansible-playbook -C webserver.yml

Variable

• Global

  • The value is set for all hosts.

  • Example: extra variables you set in the job template

• Host

  • The value is set for a particular host (or group).

  • Examples: variables set for a host in the inventory or a host_vars directory, gathered facts

• Play

  • The value is set for all hosts in the context of the current play.

  • Examples: vars directives in a play, include_vars tasks, and so on

Variable Preference

• If a variable is defined at more than one level, the level with the highest precedence wins.

• A narrow scope generally takes precedence over a wider scope.

• Variables that you define in an inventory are overridden by variables that you define in the playbook.

• Variables defined in a playbook are overridden by “extra variables” defined on the command line with the -e option.

• https://docs.ansible.com/ansible/latest/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable

Examples

# Directly in vars block
- hosts: all
  vars:
    user_name: user
    user_state: present

# In External files
- hosts: all
  vars_files:
    - vars/users.yml

  tasks:
    # This line will read: Creates the user joe
    - name: Creates the user {{ user_name }}
      user:
        # This line will create the user named joe
        name: "{{ user_name }}"
        state: present

• When referencing one variable as another variable’s value, and the curly braces start the value, quotes must be used around the value.

• This prevents Ansible for interpreting the variable reference as starting a YAML dictionary.

• The following message appears if the quotes are missing:

The offending line appears to be:
- systemd:
  name: {{ service }}
         ^ here
         We could be wrong, but this one looks like it might be an issue with
         missing quotes. Always quote template expression brackets when they
         start a value. For instance:
  with_items:
    - {{ foo }}
  Should be written as:
  with_items:
    - "{{ foo }}"

Host and Group Variables

• Host variables apply to a specific host.

• Group variables apply to all hosts in a host group or in a group of host groups.

• Host variables take precedence over group variables, but variables defined inside a play take precedence over both.

• Host variables and group variables can be defined

  • In the inventory itself. In host_vars and group_vars directories in the same directory as the inventory.

  • In host_vars and group_vars directories in the same directory as the playbook. These are host and group based but have higher precedence than the inventory variables.

    • In the same directory as your playbook, create two directories, group_vars and host_vars.

      • To define group variables for the servers group, you would create a file named group_vars/servers.

      • In that file, set variables to values, using YAML syntax. (The example at right sets ansible_user to a string and newfiles to a list of values.)

      • To define host variables for a particular host, create a file with a name matching the host in the host_vars directory

        ansible_user: devops
        newfiles:
          - /tmp/a.conf
          - /tmp/b.conf

Using password in Environment Variable

export ANSIBLE_PASSWORD="not revealed"
ansible-playbook \
  -i inventory.yaml \
  play.yaml \
  -e ansible_password='{{ lookup("env", "ANSIBLE_PASSWORD") }}'

• or store the same string in the inventory, group vars, host vars or even play vars.

---
foo:
  hosts:
    foo1:
      ansible_user: ansible
      ansible_password: '{{ lookup("env", "ANSIBLE_PASSWORD") }}'

Suppressing Output from a Task

• Use: no_log: true

# Without no_log
- name: Print variable
  debug:
    msg: "{{ secret }}"
# Result:
#TASK [Print variable] *****************
#ok: [localhost] => {
#"msg": "youknowit"
#}

# With no_log
- name: Print variable
  debug:
    msg: "{{ secret }}"
  no_log: true
# Result:
#TASK [Print variable] *****************
#ok: [localhost] 

Task Iteration with Loops

- name: Create users
  hosts: servera.lab.example.com
  vars:
    myusers:
      - aditya
      - boris
      - carlotta
  tasks:
    - name: Create users
      user:
        name: "{{ item }}"
        state: present
      loop: "{{ myusers }}"

When Loop is Inefficient

Inefficient

• This will launch the yum module three times, once for each item in the loop which is inefficient

- name: Install a list of
  packages
    yum:
      name: "{{ item }}"
      state: present
    loop:
      - nginx
      - postgresql
      - postgresql-server

Efficient

• The yum module can take a list of packages and install them all in one operation which will be faster

- name: Install a list of
  packages
    yum:
      name:
        - nginx
        - postgresql
        - postgresql-server
      state: present

Run Tasks Conditionally

When Statements

• Used to run task conditionally

  • When condition is met, the task runs

  • When condition is not met, the task is skipped

## if my_service is not defined, the task is skipped without an error
- name: Test variable is defined
  hosts: all
  vars:
    my_service: httpd
  
  tasks:
    - name: "{{ my_service }} package is installed
      yum:
        name: "{{ my_service }}"
      when: my_service is defined

Some conditions

Operation	Example
Equal (value is a string)	ansible_machine=="x86_64"
Equal (value is numeric)	max_memory == 512
Less than	min_memory < 128
Greater than	min_memory > 256
Less than or equal to	min_memory <= 256
Greater than or equal to	min_memory >= 512
Not equal to	min_memory != 512
Variable exists	min_memory is defined
Variable does not exist	min_memory is not defined
Boolean variable is true. The values of 1, True, or yes evaluate to true.	memory_available
Boolean variable is false. The values of 0, False, or no evaluate to false.	not memory_available
First variable's value is present as a value in second variable's list	ansible_distribution in supported_distros

Constructing Conditions with Ansible Facts

- name: Demonstrate "in" in a condition
  hosts: all
  gather_facts: yes
  become: yes
  vars:
    my_service: httpd
    supported_os:
      - RedHat
      - Fedora
  tasks:
    - name: Install "{{ my_service }}"
      yum:
        name: "{{ my_service }}"
        state: present
      when: ansible_facts['distribution'] in supported_os

Multiple Conditions

Or Condition

• when: ansible_ditribution == "Redhat" or ansible_distribution == "Fedora"

And Condition

• when: ansible_distribution_version == "7.5" and ansible_kernel == "3.10.0-327.el7.x86_64"

when: 
  - ansible_distribution_version == "7.5"
  - =ansible_kernel == "3.10.0-327.el7.x86_64"

Complex Condition

when: >
  (ansible_distribution == "RedHat" and 
   ansible_distribution_major_version == "7")
  or
  (ansible_distribution == "Fedora" and
    ansible_distribution_major_version == "28")

Combining Loop and Conditional Tasks

- name: install mariadb-server if enough space 300M on root
  yum:
    name: mariadb-server
    state: latest
  loop: "{{ ansible_mounts }}"
  when: item.mount == "/" and item.size_available > 300000000

- name: Restart HTTPD if Postfix is running
  hosts: all
  tasks:
    - name: Get Postfix Server Status
      command: /usr/bin/systemctl is-active postfix
      ignore_errors: yes
      register: result
    - name: Restart HTTPD based on postfix status
      service: 
        name: httpd
        state: restarted
      when: result.rc == 0

Block

• In playbooks, blocks are clauses that logically group tasks as a unit.

• They can be used to control how tasks are executed.

• For example, a block can have a when conditional applied to the entire block.

• This means that all the tasks in the block will only run if the conditional is met.

• In below example, the block groups two tasks that run only when ansible_distribution is RedHat

- name: block example
  hosts: all
  tasks:
    - name: installing and configuring Yum versionlock plugin
      block:
      - name: package needed by yum
        yum:
          name: yum-plugin-versionlock
          state: present
      - name: lock version of tzdata
        lineinfile:
          dest: /etc/yum/pluginconf.d/versionlock.list
          line: tzdata-2016j-1
          state: present
      when: ansible_distribution == "RedHat"

Block and Rescue: Recovering from Failure

• Blocks can also be used to back out of a change if tasks in the block fail.

• A block can have a set of tasks grouped in a rescue statement.

• The tasks in the rescue statement only run if a task in the block fails.

• Normally, the tasks in the rescue statement will recover the managed host from the failure. This is useful if the block exists because multiple tasks are needed to accomplish something.

Block, Rescue and Always

• block also supports a third section, always

• After the block runs, and the rescue if there was a failure in block, the tasks in always run

• These tasks always run if the block runs at all, but they are subject to the conditional on the block

• To summarize:

  • block: Defines the main tasks to run.

  • rescue: Defines the tasks to run if the tasks defined in the block clause fail.

  • always: Defines the tasks that will always run independently of the success or failure of tasks defined in the block and rescue clauses.

# If a task defined in the block clause fails, tasks defined in the rescue and always clauses are executed.
# If all tasks defined in the block clause succeed, then tasks in the always clause are executed
# If there were a when condition on the block clause, it would also apply to its rescue and always clauses.
tasks:
  - name: Upgrade DB
    block:
      - name: upgrade the database
        shell:
          cmd: /usr/local/lib/upgrade-database
    rescue:
      - name: revert the database upgrade
        shell: 
          cmd: /usr/local/lib/revert-database
    always:
      - name: always restart the database
        service:
          name: mariadb
          state: restarted

Reference

• How to pass password to Ansible from environment variable