Using CI/CD Pipelines for Infrastructure Configuration and Management
Continuous Integration/Continuous Delivery, or Continuous Deployment, pipelines have been used in the software development industry for years. For most teams, the days of manually taking source code and manifest files and compiling them to create binaries or executable files and then manually distributing and installing those applications are long gone. In an effort to automate the build process and distribution of software as well as perform automated testing, the industry has continuously evolved towards more comprehensive pipelines. Depending on how much of the software development process is automated, pipelines can be categorized into different groups and stages:
- Continuous Integration is the practice of integrating code that is being produced by developers. On medium to large software projects is common to have several developers or even several teams of developers work on different features or components at the same time. Taking all this code and bringing it to a central location or repository is regularly done using a git based version control system. When the code is merged into a branch on an hourly, daily, weekly or whatever the cadence of the development team is, simple to complex tests can be setup to validate the changes and flush out potential bugs at a very early stage. When performed in an automated fashion, all these steps consist in a continuous integration pipeline.
- Continuous Delivery takes the pipeline to the next level by adding software building and release creation and delivery. After the software has been integrated and tested in the continuous integration part of the pipeline, continuous delivery adds additional testing and has the option to deploy the newly built software packages in a sandbox or stage environment for close monitoring and additional user testing. Similar to continuous integration, all steps performed in the continuous delivery part of the pipeline are automated.
- Continuous Deployment takes the pipeline to its next and last level. By this stage, the application has been integrated, tested, built, tested some more, deployed in a stage environment and tested even more. The continuous deployment stage takes care of deploying the application in the production environment. Several different deployment strategies are available with different risk factors, cost considerations and complexity. For example, in the basic deployment model, all application nodes are updated at the same time to the new version. While this deployment model is simple it is also the riskiest, it is not outage-proof and does not provide easy rollbacks. The rolling deployment model as the name suggests takes an incremental approach to updating the application nodes. A certain number of nodes are updated in batches. This model provides easier rollback, it is less risky than the basic deployment but at the same time requires that the application runs with both new and old code at the same time. In applications that use the micro-services architecture, this last requirement must be given extra attention. Several other deployment models are available, including canary, blue/green, A/B, etc.
The CI/CD pipeline component of GitLab CE
Why use CI/CD pipelines for infrastructure management
Based on the requirements of the development team, software development pipelines can take different forms and use different components. Version control systems are usually git based these days (github, gitlab, bitbucket, etc.). Build and automation servers such as Jenkins, drone.io, Travis CI, to name just a few, are also popular components of the pipeline. The variety of options and components make the pipelines very customizable and scalable
CI/CD pipelines have been developed and used for years and I think it is finally time to consider them for infrastructure configuration and management. The same advantages that made CI/CD pipelines indispensable from any software development enterprise apply also to infrastructure management. Those advantages include:
- automation at the forefront of all steps of the pipeline
- version control and historical insight into all the changes
- extensive testing of all configuration changes
- validation of changes in a sandbox or test environment prior to deployment to production
- easy roll-back to a known good state in case an issue or bug is introduced
- possibility of integration with change and ticketing systems for true infrastructure Continuous Deployment
In this series of blogs, I will demonstrate how to use Gitlab CE as a foundational component for a CI/CD pipeline that manages and configures a simple CML simulated network. Several other components are involved as part of the pipeline:
- pyATS for creating and taking snapshots of the state of the network both prior and after the changes have been applied
- Ansible for performing the configuration changes
- Cisco CML to simulate a 4 node network that will act as the test infrastructure
Simple network simulation in Cisco CML
Stay tuned for a deeper dive
Next up in this blog series we’ll dive deeper into Gitlab CE, and the CI/CD pipeline component. If you have any questions or comments, please leave me a comment in the section below.
In the meantime, if you would like to learn and practice some of the latest techniques, please visit our Cisco Modeling Labs and the CML Sandbox. A world of network simulation awaits!
Meet me at Cisco Live in Las Vegas, June 13 to 16
I’ll be in the DevNet zone and at the following sessions:
- BRKDEV-2883 – Prism of Possibilities with Cisco DevNet’s Network Programmability & Automation
- DEVNET-1530 – NetAcad Session
- DEVNET-2653 – Cisco ACI management with Smartsheet
- DEVNET-2806 – Build custom security advisory notification systems using Cisco PSIRT APIs
- DEVWKS-2367 – DevNet Workshop – Custom OpenAPI implementation for Cisco SD-WAN
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
LinkedIn | Twitter @CiscoDevNet | Facebook | Developer Video Channel
Share:
