on 01-10-2023 11:22 PM
Introduction
This blog will walk through how to build a Continuous Integration/Continuous Delivery (CI/CD) pipeline for network automation using on-prem GitLab and Terraform to provision Application Centric Infrastructure (ACI) in development and production environments.
CI/CD overview
CI/CD Pipelines have evolved over many years depending on what components have been used in the pipeline by developers.
Continuous Integration has been a practice of integrating code that different developers were producing into one central location. Code is developed in separate branches by multiple developers and has multiple features. When code is merged into a branch at the central location you need to perform testing that validates the changes. If you find any bugs you need to flush out those potential bugs and ensure that there is no integration issues and quality is maintained.
Continuous Delivery is the stage where you run the code. You need to check that the changes have met integration requirements. All tasks are automated, and releases can be created and delivered at any time. Taking delivery, a step further you can consider Continuous Deployment were many different deployment strategies available.
Infrastructure Automation
You can save the configuration files as text files and push them to a central location like Network as Code. Then you can have a continuous delivery approach to network changes along with continuous health and improvement approach to watching the network. Configuration changes can be done through automation tools like Ansible and Terraform. You can have historical insight into changes made to the network and validate changes prior to configuring the network. If an issue is introduced into the network, those changes can be rolled back to a known good state. You can also implement integration with change and ticketing systems for true Continuous Deployment.
GitLab
GitLab is a Complete DevOps platform where you can do project management. GitLab hosts Git repositories along with Built-in CI/CD components.
A project on GitLab includes Code, issues, and you can integrate with wikis, etc. Everything in GitLab is organized into projects. Projects can be created from scratch or you can use template, or import an existing project. You may configure visibility levels for your project as private, internal or public.
Regarding the files in the repository, you can view, edit or create on your project repo.
You have the Commits. You may View and manage commits within your project. Each commit will be creating a version and you can move from one commit to another easily.
There are also Branches, such as test branch and main branch. Branches are a version of a project’s working tree. You can create merge requests and perform inline code reviews.
If any issue happens you can track the issues. It’s used for collaborating on ideas and planning the work. You can also enable sharing and discussion of ideas/proposals along with tracking the status of work and tasks.
When you want deploy the code in the test branch on production branch you can call for Merge Requests were you request to merge one branch into another.
There are several Pipelines that are running at the same time. Pipelines are the fundamental building blocks for CI/CD. These Pipelines get triggered automatically. On Git Push GitLab will deploy the changes made on files that are monitored by triggering the Pipeline.
Pipelines are composed of Jobs which is basically what to do and Stages which mentions when to run the job. A typical pipeline would contain four stages:
Whenever you have a change in the configuration file, and you push it to GitLab. At that time a pipeline is triggered, and a Runner will clone the repo and then execute the instructions inside .gitlab-ci.yml. Runners are used to run the jobs and send results back to GitLab. It’s on the gitlab-ci.yml file is where you design the stages of the pipeline and in each stage what is to be done.
An example of gitlab-ci.yml is as shown below.
Runners can implement a variety of executors like SSH, Shell, Parallels, VirtualBox, Docker, Kubernetes etc. In short you can run Jobs in different scenarios.
Pipelines are normally run when conditions are met for example when a branch is pushed to a repository. But you can Schedule the Pipelines to run at a specific interval like once in every day or every Friday Or at any schedule as needed.
In GitLab using the export keyword you can setup the environment variables which will be useful for customizing your jobs.
ACI Terraform GitLab CI/CD Pipeline
This pipeline is for configuration management on an APIC instance. APIC is an ACI controller. When the network engineer submits for a change for example you want to create new Tenant within ACI fabric. Gitlab will push the changes and first get deployed on a test environment that is the development environment. If everything went fine, you will be able to validate the result on APIC. Now you want to deploy the same on the Production environment.
Demo
For building the Test environment the Tools (products) Used are the following:
Lets first create a new project with the name ACI-Terraform-GitLab-Pipeline
Navigate to settings and select CICD
Click on Add Variable button on the window opened as below.
Add 2 variables namely DEV for development and PROD for production by entering the values on the pop window as shown below.
Now you may see the details of the added variables as shown below
Next navigate to the master folder where you have already pushed the terraform scripts which runs the show.
Once you click on the pipeline button on GitLab it will open a window as shown below.
By clicking on init button you can find the status of the job running as shown below.
In the following pictures shown below you will be navigating through various stages
1)Prepare
2)Validate
3)Build
4)Deploy
Now you may verify on ACI that the changes got applied or not…
By clicking on the Tenant you can find the details as shown below.
As you have verified that the changes got applied on the development environment all you need is to deploy the same on the Production environment . For that you are going to create a new branch on GitLab and name it as Production.
All the files will be cloned from the master into the production branch.
As seen before you will be repeating the same jobs ..
1)Prepare
2)Validate
3)Build
4)Deploy
Once done you may Verify on the ACI environment that the new Tenant with the details as mentioned in terraform script got created or not…
To check the status of the Jobs from the GitLab environment you may verify by navigating to Jobs-Terraform.
You can find the status as Passed.
Credit
Cisco live presentation - Using CI/CD pipelines for network automation – DEVNET-3069
Reference
Great blog @Geevarghese Cheria
Very nice! This is very helpful!
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
New to DevOps? These resources can help: