Starting Configuration

Now that the intent has been documented and validated, two playbooks will be created with the ambitious intent of configuring the whole enterprise campus network based on the data models and using the dynamic templates. The playbooks generate the exact same configuration. However, one executes all the tasks serially, offering more control and insight into the playbook. Mean while, the other playbook assembles all the tasks and templates into a single change, offering more speed at execution time.

Full network configuration management builds on one-time tasks and the utilization of the ios_command module.

configure-campus.yml

Organized by logical task executions, these tasks generate the configurations based on the compiled output of the dynamic Jinja2 templates and the group, and host variable data dictionaries.

This playbook executes each task serially across each device in the campus enterprise network. Using check mode with verbosity, it is possible to see what tasks are making changes on what device without executing the changes. Change validation, code troubleshooting, and documentation can all be used to understand the changes or include artifacts in the approval requests to execute the playbook.

The drawback of this approach is the time the playbook takes to execute. Waiting for thirty-five tasks to run serially and individually, multiplied by the number of the devices in the campus network, might not be the most optimal way to manage network configurations. This approach is great for a deep understanding and validation of a playbook, for troubleshooting and identifying failures in playbooks, or for documenting a playbook in detail. It is not great for pushing out configurations to many devices. For that reason, use the assemble module.

assembled-configure-campus.yml

Using the assemble Ansible module, we get the best of both worlds by having many small modular tasks and the ability to run fast, efficient playbooks against the network. Assemble does exactly that. It assembles all the files in a folder and creates a new, single, Jinja2 file. In this case, the files are our Jinja2 templates, which is another reason to prepend our templates with a numeric order for the sequence at assembly time. This file is the result of the assembly of all the other .j2 files.

This approach allows us to push a single, large configuration as a single task in our playbook instead of thirty-five individual tasks. It should be noted that the output and the results from either the configure-campus.yml or assembled-configure-campus.yml are the same. Having both simply provides operational flexibility.