ACI Terraform GitLab CI/CD Pipeline

1679

Views

Helpful

Comments

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:

Build (compile)
Test (unit-tests)
Staging (deploy-to-stage, integration-tests)
Production (deploy-to-prod)

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:

ACI v2h
ACI Simulator
Terraform v0.14.2
GitLab Cloud / On-premise: Latest Release

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.