Chapter 10 Configuration Management

Chapter 10 Configuration Management “The development of full artificial intelligence could spell the end of the human race….It would take off on its own, and re-design itself at an ever-increasing rate. Humans, who are limited by slow biological evolution, couldn't compete, and would be superseded.”

- Stephen Hawking 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 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 (if a playbook fails, which task is it failing on), and documentation can all be used to understand the changes or include artifacts in 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 another Ansible module, assemble, 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 our case our Jinja2 templates (which is another reason we prepend our templates with a numeric order for sequence at assembly time), in a folder and creates a new, single, Jinja2 file that 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.