Gitlab

Gitlab is one of the most widely used GIT implementations in the world. There are
many others, but for the sake of clarity, we will focus on gitlab in this book. All the
pipeline code used here is relatively easy to translate to another git implementation.
That doesn't have to apply to the playbooks and the methodologies we're going to
use later, but the principle should be clear and that's what it's all about in the end.

If the principle is clear, you can also follow the idea and make an implementation of it
for your own environment. Even then, the goal of this book has been achieved.

Gitlab is a git implementation that is fairly easy to program with ansible. And when
you talk about programming, you're talking about automating and implementing
standards. Also in this case:

Earlier, we have already identified a number of items that we are going to record in
gitlab and use (pipeline) code somewhere with each update (GitOps). Those items so
far are:
- Collections
- Execution environments
- Config as code

In this book we assume a "clean" installation of gitlab, but if that is not the case and
cannot be done, make sure that a similar layout is obtained. The names don't really
matter, but they should be clear to everyone. You also need to have full control over
those groups.

Gitlab groups

In the "clean" gitlab installation used for the book, we were of course able to do our
own thing, so we created the following groups from the "root":
- Collections
- Images
- Cac

Of course, there are many more groups, but for this documentation we will stick to it
here, it will be complex enough. The collections group contains all repositories in
which your own (so-called custom) collections are stored.

The images group includes all repositories in which their own execution
environments are defined.

CaC stores all repositories that have to do with configuration as code, whether it is
for the automation hub, the automation controller or the EDA.
Group runner in GitLab project.

To be able to use pipelines, a runner must be available for the gitlab project: This can
be found under: Settings/"CI/CD"/runners. If it says "available runners: >1" under
shared runners, there is a runner available to run the pipelines. If this is not the case,
have the administrator link a runner.

GitLab runner

A Gitlab runner is a machine/container that will execute the code according to the
steps in the ".gitlab-ci.yaml" file. The container runs a service that checks in gitlab
whether there is a task (job) ready that needs to be executed. These tasks are
recognized by so-called "Tags", if a tag corresponds to a runner, he will perform the
task.

As mentioned, a runner needs to be configured and linked outside of Gitlab. In the
online version of GitLab.com, these are available by default to use.

In our on-premise environment, we have to arrange this ourselves, this can be done
on openshift or on another container platform, such as docker.

How this can be done is well documented on gitlab.com. For a gitlab runner on
openshift, there are a number of points of attention, which are specific to an openshift
implementation. Most importantly, you need to make sure that the runner is using a
service account to spin the runner containers in openshift and that that container is
running in the correct namespace (not docker in docker!). You can do this by filling
the config.toml file within the runner with the following contents:

  config.toml: |
    [[runners]]
      name = "<runner-name>"
      url = "<gitlab-url>"
      clone_url = "<alternate-gitlab-url>"
      executor = "kubernetes"
      [runners.kubernetes]
        service_account = "gitlab-service-account"
        image_pull_secrets = ['gitlab-pull-secret']
        pull_policy = "if-not-present"
      [runners.kubernetes.pod_labels]
        "openshift.io/build.name" = ""

The above configuration ensures that the runner knows that it is running on openshift
and that it should behave as such. So the openshift API will be used to spin up
containers. The images for those containers may be retrieved from the registry to
which rights have been given, and the pull secret has been used to grant the pull
rights. By registering the runner with the correct registration token with gitlab, the
runner will pick up tasks that are prepared by gitlab when a repository is updated,
containing a gitlab-ci.yaml file.

Back

Back to Site