Red Hat Ansible for Network Automation

After completing this section, you should be able to write playbooks that include multiple plays.

Playbooks can run multiple plays. That means you can apply a different succession of tasks to different hosts.

This playbook contains two plays: one that configures foo hosts with the domain name foo.com and another that configures bar hosts with bar.com.

---
- name: a play that sets the domain name to foo.com
  hosts: foo
  vars:
    domain_name: foo
  tasks:
    - name: "set domain name to {{ domain_name }}"
      ios_config:
        lines:
          - "ip domain-name {{ domain_name }}"

- name: a play that sets the domain name to bar.com
  hosts: bar
  vars:
    domain_name: bar
  tasks:
    - name: "set domain name to {{ domain_name }}"
      ios_config:
        lines:
          - "ip domain-name {{ domain_name }}"

As a general rule, use command-line options available with the ansible-playbook command:

Checking the syntax of playbooks you edit, before running them, is recommended. If a different setting involves something you do on a regular basis, consider editing ansible.cfg to modify the default value, or use a group or host variable to associate the value with a group or host. If it only applies to a particular play or task, use a variable at the play or task level to explicitly set it there.

Options available with the ansible-playbook command modify the connection settings used when that command is executed:

The ansible-playbook command provides options that modify privilege escalation.

The ansible-playbook command has other options for modifying many aspects of playbook behavior, some of which are described below. Use ansible-playbook --help to see all available options.

Host patterns tell Ansible which inventory hosts to target for a play or ad hoc command.

It is easier and more flexible to adapt patterns to control the hosts that a play targets than to embed conditional logic in playbooks. Note that the --list-hosts option displays which hosts are effectively targeted with a pattern.

Using a host identifier as the selection pattern:

[user@host ~]$ ansible ftp -i myinventory --list-hosts
  hosts (1):
    ftp

Using a group identifier as the selection pattern:

[user@host ~]$ ansible spines -i myinventory --list-hosts
  hosts (2):
    spine01
    spine02

Using a wildcard in the selection pattern:

[user@host ~]$ ansible 'server0*' -i myinventory --list-hosts
  hosts (2):
    server01
    server02

Using logical negation in the selection pattern:

[user@host ~]$ ansible 'datacenter,!servers' -i myinventory --list-hosts
  hosts (4):
    leaf01
    leaf02
    ...

Using a logical conjunction (intersection) as the selection pattern:

[user@host ~]$ ansible 'servers,&web' -i myinventory --list-hosts
  hosts (1):
    web

Exercise care when using patterns to target hosts. If the pattern matches one or more host identifiers and also matches one or more group identifiers, the result might not be what you intended.

Consider the following inventory snippet:

[servers]
server01
server02
accounting01
www01

The pattern serv* matches the group name servers, and therefore includes the accounting01 and www01 hosts, which might not be what you intended:

[user@host ~]$ ansible 'serv*' -i inventory --list-hosts
  hosts (4):
    server01
    server02
    accounting01
    www01