How to use GitLab and Ansible to create infrastructure as code

GitLab CI is a powerful tool that can be used for a number of things, including infrastructure as code and GitOps. GitLab is tool agnostic, but we use Ansible in this demonstration because it's a language commonly used by developers for infrastructure as code. This is a two-router demo from the Ansible networking class.

What’s particularly cool about GitLab CI is that the code from the Ansible playbook can be edited and shipped without ever having to install any dependencies locally. The demo project, which calls for an update to the SNMP strings on all devices monthly per our security policy, can be done entirely on GitLab.com , our hosted service.

The first step is to open up the Ansible playbook, where we see four tasks:

• Gather router facts
• Display version
• Display serial number
• Configure SNMP

Configuring the SNMP strings is the focus of this demo, which can be achieved in a simple series of steps.

Start with the issue board

Every plan at GitLab starts in the same place: with an issue. So the first step in the GitLab workflow is to check out the issue board within the ansible-demo project. On the ansible-demo issue board, we see that there is already an issue to change SNMP strings on all routers. There is a link to the GitLab security policy wiki within the issue stating that SNMP strings must be rotated monthly and that there must be different strings for read-only and read-write.

GitLab security policy calls for updating SNMP strings monthly.

We then check that the commands to configure the SNMP strings in the two-router demo follow the GitLab security policy outlined in the issue.

The commands to configure the SNMP strings are available in the Ansible playbook.

Next, return to the issue and assign to yourself and switch the label from to-do to doing in the right sidebar of the issue, or by dragging between columns in the issue board.

Create a merge request

The next step is to create a merge request (MR) from the issue. Double-check that the “Work in Progress” (WIP) flag is attached to your MR so it isn’t merged with master prematurely. Rather than connect locally, we use GitLab’s Web IDE because the changes to the SNMP strings are small.

• We open the CI/CD demo section.
• Go to the Ansible playbook.
• Edit the SNMP section so it reads:

-snmp-server community New-SNMP-DEMO1 RO

-snmp-server community Fun-SNMP-RW-STR RW

• Note that the RO and RW are set to different strings, per the GitLab security policy outlined in the issue.

Commit changes

Now that the SNMP string has been updated based on the guidelines, commit the changes. Open the side-by-side comparison of the changes to see the MR has been updated with your latest commit.

The side-by-side comparison tool is an easy way to visualize your changes.

Results

Committing the changes will automatically kick off a GitLab CI pipeline. This will perform tasks such as:

• Syntax checking
• Dry-runs
• Testing of changes in lab/simulated environment

We can view the progress and output of each job in the GitLab CI pipeline to execute the SNMP updates.

See the output from your job showing that the SNMP updates in the simulated environment were successful.

All of these tasks will be run and documented in the MR.

The checkmarks indicate that each task in the GitLab CI pipeline passed.

Next, you can log into your lab routers and see the changes.

The changes to the RO and RW SNMP strings are reflected in the routers.

MR review

An optional step is to implement MR approvals. Implementing approvals gives more users the ability to review the changes before they are sent to production.

The MR can be set up so another user has to review your work before it can be merged into master.

Merging into master

The changes can be merged into master once the testing is complete. This is the branch that holds our production environment code.

When you're ready, click on the Resolve Work In Progress button. Then click Merge.

Resolving the WIP status will allow the MR to be merged and close out the issue.

Now a new pipeline will run all of the tests that were performed with the additional step of running the playbook in the production environment.

You can view the progress and logs from the pipelines screen. Once this process is complete, you can log into your production routers and see that the SNMP security strings have been updated.

The magic of GitLab CI

The magic that made all of this possible is GitLab CI. GitLab CI pipelines are a string of sequential tasks that execute everything you need to test and implement your Ansible code.

GitLab CI is configured with a single simple YAML file that lives in the repository, named .gitlab-ci.yml.

In this demonstration you will see our .gitlab-ci.yml file contains three stages.

1. Deploy: This creates the two-router simulation network, in AWS, using Ansible.
2. Demo: This executes the playbook that will change the SNMP strings.
3. Destroy: This destroys the two-router simulation network.

GitLab CI starts with a base image, in this case we are using a Docker image that contains all the required Ansible binaries and dependencies. We specify the commands to be run at each stage and the dependencies as necessary.

A simple YAML file contains the three stages of the GitLab CI.

A look inside the demo stage of the GitLab CI, which executes the Ansible playbook.

Peering under the hood of our pipelines shows how GitLab CI can be used to build infrastructure as code without ever having to install any Ansible dependencies onto your computer. This is just one example of how GitLab CI can be used to execute infrastructure as code. Watch the video below to see the full tutorial: