In this post, we will outline how to use Ansible and Git in order to perform a simple workflow for device configuration backup for network nodes.

Using Git as a distributed Version control and saving the device configuration into a Git Repo is one of the first steps into the adoption of an Infrastructure as a Code discipline and transitioning the model we operate and interact with the network to a more DevOps style. Saving the network configuration into a Git repo also provides several advantages with some is outlined as below

  • Version Control and simple change tracking.
  • Simple Rollback mechanism using built-in Git procedures.
  • Simple Auditing and history tracking.
  • Simple integration with Change Management frameworks

 

The high-level components for the setup are using Ansible + Git on the Ansible Control machine and using any Git hosted solution like GitHub, GitLab or BitBucket. The Git Repo that will be hosted should be a private Repo and the access to this private Repo should be governed by SSH Access Keys. Another approach is to use a private instance of GitLab or BitBucket within your network instead of the hosted solution available online this in case a more tight control is required.

 

Pre-Requisites

The following infrastructure components need to be in place (installed) on the Ansible Control machine

  • Ansible
  • Git

The following steps need to be carried out to create a new local Git Repo on the Ansible control machine and link it to the remote Git Repo (on GitHub).

  • A new directory should be created in order to host the Ansible playbook as well as the directory where the device configuration will be saved to, In this new directory a new Git Repo should be initialized and should be linked to the Private Repo on the Git Cloud provider (In the below snippet I am using GitHub)
vagrant@automation:/vagrant$ mkdir config_backup_git
vagrant@automation:/vagrant$ cd config_backup_git/

vagrant@automation:/vagrant/config_backup_git$ git init
Initialized empty Git repository in /vagrant/config_backup_git/.git/
  • Create a Git Repo on GitHub or GitLab
  • Link the local Git Repo on the Ansible control machine with the remote Repo on GitHub
vagrant@automation:/vagrant/config_backup_git$ git remote add origin git@github.com:kokasha/config_backup_git.git
  • The final setup is to add the local ssh public keys of the machine to the allowed ssh keys for this Repo on GitHub.
vagrant@automation:/vagrant/config_backup_git$ cat ~/.ssh/id_rsa.pub

with this, we have the local directory linked with the remote GitHub Repo and

 

Playbook Workflow

The following Steps outline the main tasks carried out in the playbook to retrieve the running configuration from the devices and saving them to Git Repo.

  • Create New Git Branch and Switch to it

On the Ansible control machine, we create a new branch to store the new configuration that we will pull from the live network

  • Synchronize with the Remote Repo

Retrieve the latest current network configuration from the Git Repo from the master branch, the Master branch is now our source of truth and it holds the latest known state of the network configuration

  • Retrieve the Running configuration of the devices.

In this step, we retrieve the running configuration from the network devices and save it locally on the Ansible Machine

  • Remove Any unneeded info (Optional)

In case there is unneeded information that we don’t need to track on the configuration (for example in JunOS the last changed output is present in the show running-config, and it is not needed) we can remove any information we might think shouldn’t be relevant to the configuration or sensitive info like clear password or SNMP communities (if required).

  • Push the changes (if any) to the Remote Repo

We check if there was any device configuration file has been added or changes (using git status) and if this command report any change to the current folder, this means that either a new device was added or a change in an existing configuration file was made, this will trigger a Git add and then Git push to the remote Repo in order to add this new change.

 

The overall Workflow is outlined in the below diagram with the overall building blocks

 

 

On the Git Repo on GitHub (or any other provider) a git pull request is initiated with the new changes and a complete process can be triggered in terms of assigning this change to a team member to review this change and then approve it and this can be linked to another ticketing system and can be integrated into the current change management process.

 

Conclusion

Using a Git Repo as a source of truth for the device configuration is the first building block in terms of adopting an Infrastructure as a Code approach in dealing with Device configuration and is the cornerstone for achieving next steps like building a CI/CD pipelines.

The same approach that was outlined in this post can be extended to extract network state (like BGP peer status, Interface Status,…) and using a slightly different mechanism to detect network state changes and documenting them.

The complete playbook can be found in this Git Repo, and it has two playbooks one is using ios_command, junos_command to retrieve the device configuration and the other playbook is using the new cli_command (Ansible 2.7+) to simplify the playbook.

 

In the next post, we will outline how to use another approach to deal will pushing configuration changes into network devices using Ansible+NAPALM and how to integrate it with Git in order to build a history for all the changes that were pushed into the network as well as implementing a peer review workflow to validate and review network changes before being pushed into network devices.