Wednesday, August 3, 2022
HomeHealthUtilizing CI/CD Pipelines for Infrastructure Configuration and Administration

Utilizing CI/CD Pipelines for Infrastructure Configuration and Administration

Welcome again everybody to the second a part of the “Utilizing CI/CD pipelines for infrastructure configuration and administration” weblog sequence. As you would possibly bear in mind from the earlier weblog, the pipeline we’re constructing is utilizing GitLab CE, pyATS, Ansible, and Cisco CML. On this weblog, we are going to set up GitLab CE and get it prepared for the subsequent steps.

Putting in GitLab CE

For my atmosphere I’ve used the GitLab CE and GitLab runner Docker photographs on CentOS 8.4. Examine right here for a full checklist of supported working methods for GitLab. Since I’m utilizing this atmosphere for demo functions, I’ll set up each GitLab CE and the GitLab runner on the identical digital machine. In a manufacturing atmosphere you would possibly need to set up GitLab CE and the runner on separate machines for safety, efficiency, and scalability functions.

GitLab CE (Group Version) is an entire DevOps platform that has all of the crucial options wanted within the software program improvement lifecycle: model management and hosted git repositories, venture administration options and a built-in CI/CD. GitLab runner is a separate utility that works with GitLab CI/CD to run the roles in a pipeline and return the outcomes again to GitLab. Each GitLab and the runner help a number of totally different set up fashions: from Linux packages, on Kubernetes by Helm charts, compiling from supply or as Docker containers. I’ve chosen the Docker set up for simplicity.

The Docker file definition for operating GitLab and the runner as containers ought to seem like the one under. Save this data in a file named docker-compose.yml.

model: '3.4'

  restart: at all times
  picture: gitlab/gitlab-ce
  hostname: gitlab
   - gitlab-config:/and so on/gitlab
   - gitlab-data:/var/choose/gitlab
   - "80:80"
   - GITLAB_HOST=http://devbox
   - VIRTUAL_HOST=devbox
  restart: at all times
  picture: gitlab/gitlab-runner
    - REGISTRATION_TOKEN=gitlabrunners
    - RUNNER_NAME=runner1
    - RUNNER_EXECUTOR=docker
    - CI_SERVER_URL=http://devbox
    - CLONE_URL=http://devbox
    - DOCKER_IMAGE=alpine
    - DOCKER_EXTRA_HOSTS=devbox:
    - DOCKER_PULL_POLICY=if-not-present
    - /var/run/docker.sock:/var/run/docker.sock
    - "devbox:"
   driver: native 
   driver: native

From this docker-compose file definition we are able to see that two companies are being instantiated: gitlab and runner1. Each of them needs to be operating always (restart:at all times) and can use the official gitlab photographs gitlab-ce and gitlab-runner respectively. Volumes are mounted from the host working system to the container and port 80 is uncovered for HTTP entry to the gitlab internet interface. A number of atmosphere variables are outlined and handed to the containers, together with the gitlab root account password, the runner registration token in addition to the runner executor which on this case is Docker. As soon as gitlab and the runner containers are instantiated and began, the runner should register with the gitlab occasion utilizing the token specified on this file. The GitLab runner implements a number of executors that can be utilized to run the builds and the pipeline in several eventualities akin to: shell, SSH, Kubernetes, Parallels, VirtualBox, Docker, and so on.

Since after instantiating the 2 containers there are further steps wanted to carry the GitLab occasion on-line and register the runner, let’s mix all these steps in a shell script. The shell script will run the “docker-compose up” command first and as soon as GitLab CE turns into out there, it reconfigures the external_url in /and so on/gitlab/gitlab.rb to level to the right IP handle. Your atmosphere will most actually have a unique IP handle so be sure you edit the gitlab_host entry to mirror the IP handle from your personal setup. As soon as GitLab is reconfigured with the right external_url, the runner will register with GitLab. The shell script under incorporates all of the steps described to date.

#!/usr/bin/env bash

# prints coloured textual content
success () {
    COLOR="92m"; # inexperienced
    printf "$STARTCOLOR%b$ENDCOLOR" "donen";

echo ""
printf "Launching Gitlab CE..."
docker-compose up -d 2> gitlab_setup.log

printf "Waiting for Gitlab CE to become available..."

until $(curl --output /dev/null --silent --head --fail ${gitlab_host}); do
    printf '.'
    sleep 10

printf "Configuring external URL for GitLab..."
docker-compose exec gitlab /bin/bash -c "echo external_url '${gitlab_host}' >> /etc/gitlab/gitlab.rb"
docker-compose exec gitlab gitlab-ctl reconfigure 2>&1 >> gitlab_setup.log

printf "Registering GitLab Runner, waiting ${gitlab_wait_time} second(s) for gitlab to become available..."
sleep ${gitlab_wait_time}
docker-compose exec runner1 gitlab-runner register 2>&1 >> gitlab_setup.log

Make sure the shell script is executable: chmod u+x ./ and then execute it with ./ The gitlab_setup.log file that is generated contains all the logs and should be reviewed at the end of the script run. The two containers should be up and running:

Adrian CI-CD 1

The GitLab web interface is available at in my case. Make sure you login with the root account and password C1sco12345 and create a new “developer” user account that will be used in the next steps.

Adrian CI-CD 2

Stay tuned for the next part

In part three of this blog series we will configure the GitLab CI/CD pipeline component. In the meantime, if you have any questions or comments, please leave me a comment in the section below.

Related resources

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 | YouTube Channel




Please enter your comment!
Please enter your name here

Most Popular

Recent Comments