Playbook Parsing

• We will look into
  • Order of Operations
  • Relative path assumptions
  • Play behavior keys
  • Host selection for plays & tasks
  • play & task names

Order of Operations

• A playbook has only two main operations

  • Run a play
  • include other playbook from somewhere.

• The order in which these are executed is simply the order in which they appear in a playbook

• Inside playbooks we have plays. The list of possible operations & order in which play get s executed

  1. Variable Loading
  2. Fact Gathering
  3. The pre_tasks execution
  4. Handlers notified from pre_tasks execution
  5. Roles execution
  6. Tasks execution
  7. Handlers notified from roles or tasks execution
  8. The post_tasks execution
  9. Handlers notified from post_tasks execution

• Lets create a sample playbook as shown below with inventory file just having localhost

---
- hosts: all
  gather_facts: false
  vars:
    - my_var: "from playbook"
  pre_tasks:
    - name: pretask
      debug:
        msg: "this is pre-task"
      notify: say hi
  tasks:
    - name: task
      debug:
        msg: "This is task"
      notify: say hi
  post_tasks:
    - name: posttask
      debug:
        msg: "This is post-task"
      notify: say hi

• Now execute the playbook
• Now lets slightly change the playbook

---
- hosts: all
  gather_facts: true
  vars:
    - my_var: "from playbook"
  pre_tasks:
    - name: pretask
      debug:
        msg: "this is pre-task"
      notify: say hi
  tasks:
    - name: task
      debug:
        msg: "This is task"
      notify: say hi
    - name:
      debug:
        var: my_var
  post_tasks:
    - name: posttask
      debug:
        msg: "This is post-task"
      notify: say hi

• now execute playbook
• Refer Here for official playbook docs
• Now lets add notify section by forcing change to tasks with changed_when: true, The playbook will be as shown below

---
- hosts: all
  gather_facts: true
  vars:
    - my_var: "from playbook"
  pre_tasks:
    - name: pretask
      debug:
        msg: "this is pre-task"
      changed_when: true
      notify: 
        - sayhi
  tasks:
    - name: task
      debug:
        msg: "This is task"
      changed_when: true
      notify: 
        - sayhi
  post_tasks:
    - name: posttask
      debug:
        msg: "This is post-task"
      changed_when: true
      notify: 
        - sayhi
  handlers:
    - name: sayhi
      debug:
        msg: "hi"

• Execute this playbook

Path Assumptions in Ansible

• Ansible when parses the playbooks, assumes certain relative paths. Ansible will expect the relative path to be in the same directory where the playbook is present.
• So for experimenting this lets create a folder called as relative and in relative the files to be created are shown below
• The playbook file relativeplaybook.yaml will have the following content

---
- name: understanding relative paths
  hosts: all
  vars_files:
    - my_var.yaml
  tasks:
    - name: "print variable"
      debug:
        var: somevar
    - include: tasks/onlytasks.yaml

• The variable file my_var.yaml will have following content

---
somevar: "This value is from variable file in same directory as playbook"

• The tasks/onlytasks.yaml will have following content

---
- name: im from only tasks
  debug:
    msg: "Iam from onlytasks"
- include: specialtasks.yaml

• The task/specialtaks.yaml will have the following content

---
- name: special task
  debug:
    msg: "I'm special task"

• Now execute relativeplaybook.yaml

Play behavior directives

• These are the directives which we write at the same level as hosts.
• Some of the play behavior directives are
  • any_errors_fatal: This Boolean directive instructs ansible to treat any failure as fatal and prevent any further tasks from execution
  • gather_facts: This boolean directive instructs ansible whether to collect facts or not.
  • max_fail_percentage: This allows to define just what percentage of failures hosts can fail before the whole operation is halted
  • no_log: This is boolean directive to control whether ansible will log or not
  • port: What port to connect to SSH
  • remote_user: which user to login into host
  • become: To execute with privilege escalation
  • become_method:
  • become_flags
  • strategy
• For the whole list of play directives refer here

Execution Strategies

• A strategy defines how Ansible coordinates tasks across the hosts.
• More strategies can be added as ansible-plugins or you can develop your own
• Ansible comes with two strategies
  • linear: default ansible strategy
  • free
• To be continued in next series