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’ll set up GitLab CE and get it prepared for the following steps.

Putting in GitLab CE

For my setting I’ve used the GitLab CE and GitLab runner Docker photographs on CentOS 8.4. Test right here for a full record of supported working methods for GitLab. Since I’m utilizing this setting for demo functions, I’ll set up each GitLab CE and the GitLab runner on the identical digital machine. In a manufacturing setting you would possibly wish 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 essential options wanted within the software program improvement lifecycle: model management and hosted git repositories, challenge 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 completely 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 working GitLab and the runner as containers ought to seem like the one beneath. Save this info in a file named docker-compose.yml.

model: '3.4'

  restart: at all times
  picture: gitlab/gitlab-ce
  hostname: gitlab
   - gitlab-config:/and so forth/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 will see that two providers are being instantiated: gitlab and runner1. Each of them must be working 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 setting 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 numerous eventualities reminiscent of: shell, SSH, Kubernetes, Parallels, VirtualBox, Docker, and so forth.

Since after instantiating the 2 containers there are further steps wanted to convey the GitLab occasion on-line and register the runner, let’s mix all these steps in a setup.sh shell script. The shell script will run the “docker-compose up” command first and as soon as GitLab CE turns into accessible, it reconfigures the external_url in /and so forth/gitlab/gitlab.rb to level to the proper IP deal with. Your setting will most actually have a special IP deal with so be sure you edit the gitlab_host entry to mirror the IP deal with from your personal setup. As soon as GitLab is reconfigured with the proper external_url, the runner will register with GitLab. The shell script beneath comprises 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 ./setup.sh and then execute it with ./setup.sh. 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