Jenkins is an open-source tool used for Continuous Integration and Continuous Delivery (CI/CD). Jenkins can be used to create a NetDevOps pipeline for a Data Center environment that has Cisco Nexus Switches. The pipeline in Jenkins is configured to trigger steps for automated build and testing of code. Cisco Nexus Switches within the Data Center provide connectivity to bare-metal, virtualized servers and to the corporate intranet. Ansible, Terraform or commercial products such as Cisco NSO are typically used for automation of deployment and configuration management. In this use case, Ansible is used for configuration management.
It is assumed that the Data Center is already fully operational. Connectivity of new bare-metal and virtualized servers to Cisco Nexus switches must be configured in the Data Center. Thus, new VLANs and physical interfaces on those switches must be configured to allow connectivity to those servers. Ansible code will be written to achieve this configuration. Ansible code, to automate these steps and tasks, is saved in files that are called playbooks in ansible terminology. This code, i.e., playbook files, define the desired state by using YAML syntax. And the playbooks are saved with extension of .yml (YAML).
Refer to below Figure for the NetDevOps pipeline steps.
This pipeline executes a series of automated steps on a testing environment to validate the Ansible code. Such validation prior to making those configuration changes on staging, pre-production and/or production environments reduces risks for any misconfiguration and potential network downtime.
The following provides a high-level overview of the steps in the pipeline. Detailed procedures about the configurations of Jenkins and git are covered in this book.
- A new playbook named "vlan.yml" is authored by a NetDevOps engineer. It's a simple playbook that creates new VLAN and add interfaces on multiple switches.
- NetDevOps engineer pushes the playbook to the centralized git repository on GitHub. In git terminology this is done by performing a git commit and then git push to the existing centralized GitHub repository.
- Jenkins is configured to automatically trigger a series of steps in a pipeline upon the merge of code in the git centralized repository.
- Firstly, the Jenkins pipeline automates the launch of a docker container, from the pre-existing docker image, in the test environment. The steps to create this Docker image with git and Ansible, along with required packages, are also documented in this book.
- Next automated step in the pipeline copies the code in the form of playbooks, from the centralized git repository on GitHub, within the docker container. In git terminology this step of copying a repository to a local machine is performed using git clone.
- Further, the automated pipeline performs a syntax check of the Ansible playbook. This is performed by automatically executing the following ansible command, as per pipeline, within the docker container:
$ ansible-playbook vlan.yml --syntax-check
- Next step in the pipeline performs a dry run of the ansible playbook on the test environment by automatically executing the following command within the docker container:
$ ansible-playbook vlan.yml –check
- It's always a good practice to clean up at the end of the pipeline and remove resources that have been created for testing purposes, otherwise stale or unwanted resources stay in the environment and consume undesired computing resources. Hence, the last step in the pipeline removes the docker container on test environment.
This cleanup step can be configured to run unconditionally in Jenkins, regardless of failure of one or more steps in the pipeline.