Red Hat Ansible for Network Automation
After completing this section, you should be able to build more complex plays that include multiple tasks.
Use connection: to set the connection method in a playbook.
Privilege escalation can be customized using methodbecome, become_user, and become_method.
---
- name: a simple playbook with one play and one task
hosts: spine1
connection: network_cli
remote_user: admin
become: yes
become_method: enable
vars:
destination: 10.10.10.4
tasks:
- name: "test reachability to {{ destination }}"
ios_ping:
dest: "{{ destination }}"The connection methods for connecting to networking devices execute Ansible python code locally on the control node.
For consistent formatting and improved readability, the recommended practice is to use the key: value syntax for mappings rather than the key=value shorthand.
The key: value form also facilitates fine-grained, line-oriented syntax error alerting.
The following is valid, but not recommended:
- name: print a message debug: msg="Welcome to the example.com network"
The preferred format is as follows:
- name: print a message
debug:
msg: "This is the example.com network"
For similar reasons, using the longer - item block style rather than the shorter [ item,... ] flow style is recommended practice for representing sequences.
The following is valid, but not recommended:
vars: interfaces: [ GigabitEthernet1, GigabitEthernet2, GigabitEthernet3 ]
The preferred format is as follows:
vars:
interfaces:
- GigabitEthernet1
- GigabitEthernet2
- GigabitEthernet3Notice that there are no commas after list elements in the preferred style.
In certain contexts, flow style may be preferred.
Flow style can be an effective way of promoting clarity, by conveying how elements in a collection are grouped together as a unit. This is frequently the case with sequences of mappings; with roles, for instance, or when loops or aggregation are used.
roles:
- { role: git_server, git_project: project }
- { role: git_server, git_project: ipa-client-register }---
- hosts: routers
gather_facts: no
vars:
interface_data:
cs01:
- { name: Loopback1, ipv4: 172.16.0.1/32 }
- { name: GigabitEthernet2, ipv4: 172.16.2.2/30 }
- { name: GigabitEthernet3, ipv4: 172.16.5.2/30 }
- { name: GigabitEthernet4, ipv4: 172.16.10.1/30 }
tasks:
- name: set IP address on IOS device
ios_l3_interface:
aggregate: "{{ interface_data[inventory_hostname] }}"
when: ansible_network_os == 'ios'Look for opportunities to break long strings into multiline ones. For example:
vars: line: this is a very long line that seems to go on and on and on and on
The preferred format is shown below:
vars:
line: >
this is a very long line
that seems to go on and on
and on and on and onBoth of those are identical strings as far as YAML is concerned.
The ansible-playbook command displays color-coded information about what is happening as plays are running and executing tasks on hosts.
Table 2.1. Color Key
| Color | Text | Meaning |
|---|---|---|
| green | ok | Normal, successful operation |
| yellow | changed | Host was changed by task |
| red | error | Error or failure |
You can register the output of commands associated with a task, and conditionally perform later tasks based on the status of earlier ones (changed, ok, or error).
The ansible-playbook command displays output in JSON form.
- Play
Information about which hosts were targeted by the play
- Task
Success or failure of task for host, plus any output from task
- Gathering Facts
(unless suppressed): Success or failure of fact gathering for host
- Play Recap
For each host, the number of tasks resulting in ok, changed, unreachable, and failed
The ansible-playbook program runs the plays found in playbooks and much more.
This is why it is good to name plays and tasks to clearly communicate their purpose.
List the hosts to which a playbook would be applied:
[user@host ~]$ansible-playbook --list-hostsplaybook-file
List the tasks contained in a playbook:
[user@host ~]$ansible-playbook --list-tasksplaybook-file
Verify the syntax of a playbook:
[user@host ~]$ansible-playbook --syntax-checkplaybook-file
Return information about changes that would be made, but do not make them ("dry run"):
[user@host ~]$ansible-playbook --checkplaybook-file
The first playbook example illustrated how to take an ad hoc command and convert it to a simple playbook. Plays do not begin to show their potential, however, until they do multiple tasks.
---
- name: play that sets interface descriptions
hosts: cloud-services
connection: network_cli
tasks:
- name: backup running config
ios_config:
backup: yes
- name: label outside interface
ios_interface:
name: GigabitEthernet2
description: outside
- name: label inside interface
ios_interface:
name: GigabitEthernet4
description: inside
