Gitlab-ci

Hello.
We do not have many tasks that require a full CI. For some time, we used Jenkins as a CI service. Everything is pretty obvious there, it is simple and flexible to configure, has a bunch of plug-ins, but a couple of times we ran into OOM killer agents on weak machines and decided to consider Gitlab CI as a CI service, because we like experiments and especially in the comments to our last article asked such a question.

Installing GitLab-CE

')
It's all pretty trivial, because there is an Omnibus package .

Install and run the necessary packages:

sudo yum install curl openssh-server openssh-clients postfix cronie sudo service postfix start sudo chkconfig postfix on 

Install Gitlab-CE:

 curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash sudo yum install gitlab-ce 

Configure and run Gitlab-CE:

 sudo gitlab-ctl reconfigure 

Runner installation

GitLab Runner is an agent that actually executes instructions from a special .gitlab-ci.yml file.
Unlike the Jenkins gitlab runners are written in Go, so they are very small and fast. And they can run tasks in completely different ways: locally, in docker-containers, in different clouds or via ssh-connection to any server. Details, as always, in the documentation.

Someone in the comments to the last article asked to consider Gitlab for testing ansible-playbooks, and take it.
To ensure the identity of the testing and production environments, we will use Docker.

For the runner to work in Docker - first you need to install docker:

 curl -sSL https://get.docker.com/ | sh 

Runner installation

 #  Debian/Ubuntu curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash #  RHEL/CentOS curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash 

 #  Debian/Ubuntu sudo apt-get install gitlab-ci-multi-runner #  RHEL/CentOS sudo yum install gitlab-ci-multi-runner 

Setting up and connecting runner to CI-service:

 sudo gitlab-ci-multi-runner register Please enter the gitlab-ci coordinator URL (eg https://gitlab.com/ci ) http://domain.example.com/ci Please enter the gitlab-ci token for this runner bQ0nvkVJACDUrvQ9ttqx Please enter the gitlab-ci description for this runner my-runner INFO[0034] fcf5c619 Registering runner... succeeded Please enter the executor: shell, docker, docker-ssh, ssh? docker Please enter the Docker image (eg. ruby:2.1): centos:7 INFO[0037] Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded! 

We specify the URL of our Gitlab, and prescribe a token for authorization.
You also need to set the runner name, the way to start the job, in the case of docker - we specify the image that will run the runner.
The configuration for the runner is specified by url example.com/groupname/projectname/runners
Here you can edit the name of the runner and the tags with which the project will be collected on this runner. For example, we need to test the project at different stages first in the shell, then pack it into a docker container and roll it out somewhere via ssh. About this a little later.

From there, you need to take the URL of the master and the token to authorize the runner on the "master".



Launch

 sudo gitlab-ci-multi-runner start 

After that, it should appear in the list of project runners:

Install Container Registry

Not so long ago, the Container Registry was integrated into Gitlab.
GitLab Container Registry is a secure, private repository for storing Docker images.
We are looking in /etc/gitlab/gitlab.rb section of the Container registry settings

 registry_external_url 'https://domain.example.com' # Settings used by GitLab application gitlab_rails['registry_enabled'] = true gitlab_rails['registry_host'] = "domain.example.com" gitlab_rails['registry_port'] = "5000" gitlab_rails['registry_api_url'] = "http://localhost:5000" gitlab_rails['registry_key_path'] = "/var/opt/gitlab/gitlab-rails/certificate.key" gitlab_rails['registry_path'] = "/var/opt/gitlab/gitlab-rails/shared/registry" # gitlab_rails['registry_issuer'] = "omnibus-gitlab-issuer" # Settings used by Registry application registry['enable'] = true registry['username'] = "registry" registry['group'] = "registry" # registry['uid'] = nil # registry['gid'] = nil registry['dir'] = "/var/opt/gitlab/registry" registry['log_directory'] = "/var/log/gitlab/registry" registry['log_level'] = "info" registry['rootcertbundle'] = "/var/opt/gitlab/registry/gitlab-registry.crt" registry['storage_delete_enabled'] = true 

From the necessary:
you need to set gitlab_rails ['registry_enabled'] = true and registry ['enable'] = true
In the registry_external_url specify the domain name of the server on which the repository will be located.

You also need to find the following settings:

 registry_nginx['ssl_certificate'] = "/path/to/certificate.pem" registry_nginx['ssl_certificate_key'] = "/path/to/certificate.key" 

And specify the correct path to the certificates.

If self-signed certificates are used, then on the docker-daemon side, from which all work with images will take place, you need to set the --insecure-registry option, otherwise, if you try to log in, we will get an error (runner also applies).

In Debian: /etc/systemd/system/multi-user.target.wants/docker.service

 [Unit] Description=Docker Application Container Engine Documentation=https://docs.docker.com After=network.target docker.socket Requires=docker.socket [Service] Type=notify ExecStart=/usr/bin/docker daemon -H fd:// --insecure-registry domain.example.com MountFlags=slave LimitNOFILE=1048576 LimitNPROC=1048576 LimitCORE=infinity TimeoutStartSec=0 [Install] WantedBy=multi-user.target 

(Yes, there is no need to specify the port. There is an API for the registry - it hangs on localhost: 5000 and the front, through which authorization and further work with images takes place. I’ve been looking for a way to outweigh the API from the local host :))

apply changes

 systemctl daemon-reload 

 systemctl restart docker 

And we try to log in with our gitlab account.

 docker login domain.example.com Username: root Password: Email: admin@example.com WARNING: login credentials saved in /root/.docker/config.json Login Succeeded 

Well, now is the time to do something with it, build the first pipeline and see how the project will be built.

CI Setup

We start testing ansible playbooks:

I will not go into the depths and talk about serverspec and test-kitchen, they have already been written about in my last post.
First of all - we collect a simple image with an environment for tests. We will manage Dry run and ansible-lint .

vim Dockerfile

 FROM centos:7 RUN yum -y update && yum -y install epel-release \ && yum -y install ansible python-pip RUN pip install ansible-lint # Default command CMD ["/bin/bash"] 

Okay, let's get an image

 docker build -t centos:7 . 

and push in Registry

 docker tag centos:7 domain.example.com/<groupname>/<projectname> docker push domain.example.com/<groupname>/<projectname> 

Now is the time to describe pipeline

At the root of our project, we create a .gitlab-ci.yml file (again, YAML, yeah) and describe the steps involved in building the project.

 image: domain.example.com/root/my-repo stages: - test - deploy test_job: stage: test script: - ansible-lint playbook.yml - ansible-playbook --check playbook.yml tags: - ansible deploy_job: stage: deploy script: - ansible-playbook playbook.yml tags: - ansible 

Here we indicate the assembly stages of the project. At the testing stage, we go through lint for syntax errors and run Ansible in Dry mode, that is, without applying changes on the host, but simply showing them. If suddenly something breaks during the playback of the playbook - we will know about it before the configuration on the host changes.
Correspondingly, if we now try to add spaces to the playbook, the configuration will not apply, lint will report an error and drop during the testing phase, which can be found after the commit directly in the gitlab web interface.





.Gitlab-ci.yml has a lot of different options for all cases of the project's life stage. Unfortunately, it was not possible to get acquainted with everything in one evening.

As you can see, Gitlab is no worse than other CI services, it has a positive and user-friendly interface, but there are features in terms of writing a test script and deployment.

Thanks for attention. Successful automation!