Automation Tools: Ansible
Let's learn how to use Ansible in the network automation process and try out some simple commands.
We'll cover the following
Ansible is the automation engine where playbooks are run, either in
check mode or full execution mode. Running playbooks is as simple as
creating a YAML file and running the ansible-playbook
command in the
Linux host.
The syntax for ansible-playbook
is as follows:
ansible-playbook <playbook file name.yml> <options>
Some common options:
-
–ask-vault-pass
: Ask for the vault password. -
-C
,--check
: Do not make changes; instead, try to predict some of the changes that occur. -
-D
,--diff
: When changing (small) files and templates, show the differences in those files; works great with--check
. -
-l SUBSET
,--limit=SUBSET
: Further limit selected hosts to an additional pattern. -
–start-at-task=START_AT_TASK
: Start the playbook at the task matching this name. -
–step one-step-at-a-time:
: Confirm each task before running. -
–syntax-check
: Perform a syntax check on the playbook but do not execute. -
-t TAGS
,--tags=TAGS
: Only run plays and tasks tagged with these values. -
-v
,--verbose
: Verbose mode (-vvv
for more).
Scope of playbook
The scope of what devices to run a playbook against is included in the
playbook itself, but can be overridden using the --limit
option.
This is useful if the playbook is configured, for example, to run
against the entire campus. However, there are only changes for a single device
or subset of devices. Use the --limit
option and provide a group or
hostname from the hosts
file to specify which devices to run the
playbook against at run time.
ansible-playbook <playbook.yml> --limit <host/group>
Check mode
Check mode can be used to dry run Ansible playbooks and as part of the change management process. It is a validation step before pull requests are approved. The output from check mode can be made a mandatory artifact. The results from check mode show exactly what devices will be changed and the exact configuration commands that will be executed and in what order.
Check mode is often combined with a level of verbosity to display more details about what the Ansible playbook would have changed, as opposed to simply indicating a change. This data is a gold mine of information that can be used to help the NetDevOps team collaborate and fully understand a change before it is deployed.
ansible-playbook <playbook.yml> --check -v
Idempotency
Much like check mode, the state of playbook idempotency is another source of non-technical information NetDevOps can leverage. An understanding of how far ahead or behind either the source of truth or the production environment is from each other is provided using check mode capabilities. Once idempotency is achieved, ensure that no out of band changes are made. The only changes that should be made are automated changes using the automation engine and NDLC process. Also, make sure that the branching strategy is followed to maintain the idempotent state.
Get hands-on with 1200+ tech skills courses.