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 keep 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 subsequent steps.
Putting in GitLab CE
For my atmosphere I’ve used the GitLab CE and GitLab runner Docker photos on CentOS 8.4. Test right here for a full checklist of supported working programs 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 (Neighborhood Version) is a whole DevOps platform that has all of the vital 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 assist a number of totally different set up fashions: from Linux packages, on Kubernetes by means of 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 appear like the one under. Save this info in a file named docker-compose.yml.
model: '3.4'
companies:
gitlab:
restart: all the time
picture: gitlab/gitlab-ce
hostname: gitlab
volumes:
- gitlab-config:/and many others/gitlab
- gitlab-data:/var/choose/gitlab
ports:
- "80:80"
atmosphere:
- GITLAB_ROOT_PASSWORD=C1sco12345
- GITLAB_SHARED_RUNNERS_REGISTRATION_TOKEN=gitlabrunners
- GITLAB_HOST=http://devbox
- VIRTUAL_HOST=devbox
runner1:
restart: all the time
picture: gitlab/gitlab-runner
atmosphere:
- REGISTRATION_TOKEN=gitlabrunners
- RUNNER_NAME=runner1
- RUNNER_EXECUTOR=docker
- CI_SERVER_URL=http://devbox
- CLONE_URL=http://devbox
- REGISTER_NON_INTERACTIVE=true
- DOCKER_IMAGE=alpine
- DOCKER_EXTRA_HOSTS=devbox:192.168.0.148
- DOCKER_PULL_POLICY=if-not-present
volumes:
- /var/run/docker.sock:/var/run/docker.sock
extra_hosts:
- "devbox:192.168.0.148"
volumes:
gitlab-config:
driver: native
gitlab-data:
driver: native
From this docker-compose file definition we will see that two companies are being instantiated: gitlab and runner1. Each of them ought to be operating always (restart:all the time) and can use the official gitlab photos 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 net 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 must 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 reminiscent of: shell, SSH, Kubernetes, Parallels, VirtualBox, Docker, and many others.
Since after instantiating the 2 containers there are further steps wanted to deliver 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 out there, it reconfigures the external_url in /and many others/gitlab/gitlab.rb to level to the proper IP tackle. Your atmosphere will most actually have a distinct IP tackle so be sure you edit the gitlab_host entry to replicate the IP tackle from your individual setup. As soon as GitLab is reconfigured with the proper external_url, the runner will register with GitLab. The shell script under comprises all of the steps described up to now.
#!/usr/bin/env bash
gitlab_host="http://192.168.0.148"
gitlab_wait_time=25
# prints coloured textual content
success () {
COLOR="92m"; # inexperienced
STARTCOLOR="e[$COLOR";
ENDCOLOR="e[0m";
printf "$STARTCOLOR%b$ENDCOLOR" "donen";
}
echo ""
printf "Launching Gitlab CE..."
docker-compose up -d 2> gitlab_setup.log
success
printf "Waiting for Gitlab CE to become available..."
until $(curl --output /dev/null --silent --head --fail ${gitlab_host}); do
printf '.'
sleep 10
done
success
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
success
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
success
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:
The GitLab web interface is available at http://192.168.0.148 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.
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
Share: