Automation Tools: Ansible

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.