Building an infrastructure as code with GitLab and Ansible

All the power of GitLab CI in demonstrating Ansible playbooks with the infrastructure as code approach.

GitLab CI is an effective tool for a wide variety of scenarios, including infrastructure as code. GitLab can be used with different tools, but in this demo we will take Ansible, because it is the developers who use it most often with the framework as an infrastructure approach. Here is a demo with two routers from the course on Ansible networks .

The beauty of GitLab CI is that the code from the Ansible playbook can be changed and delivered without installing any dependencies locally. A demo project that causes SNMP strings to be updated on all devices every month in accordance with our security policy can be fully completed on GitLab.com , our code hosting service.

To get started, open the Ansible playbook, where there are 4 tasks:

• Gather router facts - collecting facts about routers.
• Display version - display version
• Display serial number
• Configure SNMP - Configure SNMP.

In this demo, we will focus on configuring SNMP strings, for which you need to follow a few simple steps.

Starting from the task board

Any plan on GitLab starts the same way: with a task . So, the first step of the GitLab workflow is to check the task board in the ansible-demo project . On the ansible-demo task board, we already see the task: change SNMP lines on all routers . The task has a link to the GitLab security policy wiki page, where it says that SNMP lines need to be updated every month, and for read-only and read and write operations, there should be different lines.

GitLab's security policy prescribes updating SNMP strings every month.

Then you need to verify that the commands for configuring SNMP strings in the demo with two routers do not violate the GitLab security policy described in the task.

Commands for configuring SNMP strings are available on Ansible playbook.

Then return to the task, assign it to yourself and change the shortcut from to-doto doingon the right panel or simply drag the task on the board from one column to another.

Creating a merge request

Now you need to create a merge request from the task. Make sure the merge request has a Work in Progress (WIP) flag so that it does not get into the wizard prematurely. Instead of connecting locally, we use the GitLab Web IDE because the changes to the SNMP lines are minor.

• Open the CI / CD demo section.
• Go to Ansible playbook.
• Change the SNMP section as follows:
• Please note that different lines are configured for RO and RW in accordance with the GitLab security policy described in the task .

Commit commit

You updated the SNMP line according to the instructions, and now you need to commit the changes. Open a parallel change comparison to make sure the merge request contains the latest commit.

The parallel comparison tool visually shows the changes.

results

Committing changes will automatically launch the GitLab CI pipeline. He will perform the following tasks:

• Syntax check
• Test runs.
• Testing changes in a laboratory / artificial environment.

We see the progress and output of each job in the GitLab CI pipeline that updates SNMP.

The output from your task shows that SNMP updates in the artificial environment were successful.

All these tasks will be launched and documented in the merge request.

Checkmarks indicate that the task in the GitLab CI pipeline has been completed.

Then log in to the routers for a demo and see the changes.

Changes in SNMP RO and RW strings are reflected in routers.

Merge Request Review

You can perform an additional step - approval of the merge request . If you set up approval, several users will be able to verify the changes before they go into production.

The merge request can be configured so that another user checks your works before they appear in the wizard.

Transfer to the master

Changes can be submitted to the wizard immediately after testing. A wizard is the main branch that contains workspace code.

When ready, press the button Resolve Work In Progress. Then click Merge.

When you enable WIP status, the merge request can be sent to the wizard, and the task can be closed.

The new pipeline will run all the tests that you performed on the additional step of launching the playbook in production.

Keep track of progress and logs on the pipeline screen. When the process completes, log into the working routers and verify that the SNMP lines have changed.

Magic GitLab CI

All this is possible thanks to the magic of GitLab CI. GitLab CI pipelines are a series of sequential tasks that perform everything necessary for testing and implementing Ansible code.

The entire configuration of GitLab CI fits in a simple YAML file, which is stored in the repository .gitlab-ci.yml.

In this demo, the file .gitlab-ci.ymlcontains 3 steps.

1. Deploy (Deployment): Creates a simulated network with two routers in AWS using Ansible.
2. Demo: Performs a playbook that will change SNMP lines.
3. Destroy: Destroys a simulated network with two routers.

GitLab CI starts with a basic image. In this case, we use the Docker image, which contains all the necessary code and Ansible dependencies. Indicate the commands that will be executed at each stage, and dependencies.

A simple YAML file contains three stages of GitLab CI.

The demonstration phase of GitLab CI, which runs the Ansible playbook.

We looked inside the pipeline and saw how you can use GitLab CI to create an infrastructure as code without even installing Ansible dependencies on your computer. This is just one example of how GitLab CI can be used to implement infrastructure as code. See the video for a complete guide: