Building GitLab Pipelines on OpenShift

This blog will guide you through the creation of a functional GitLab CI/CD pipeline for applications that will be deployed to OpenShift. 

GitLab is a tool that developers can use to not only host a repository for the code that they write but also use it to create CI/CD pipelines. The ability to create these pipelines is a function that is built into GitLab itself; to get started you simply need to have a configuration file, .gitlab-ci.yml, present in the root directory of your repository. 

The major steps in the pipeline are defined by stages. In each of the stages you have the ability to create multiple jobs that will run a shell script to execute commands. One thing to keep in mind is that a stage defined in the configuration file does not necessarily have to run for each execution of the pipeline; the steps that are chosen will depend on the rules for triggering that stage. 

Further information on GitLab CI/CD can be found here.

Requirements

Helm is a major component of this pipeline. It is used to apply a general template to all deployments and builds which you can then use to create the corresponding OpenShift resources. You can download and find more info on helm here.

CI/CD Pipeline Configuration

Follow the steps in the README within the repo to configure the pipeline to work with your project.

Notes on Branching

Feature Branch Mechanics

Feature branches operate on a different set of rules than non-feature branches (ex. master). Whenever a feature branch is created, the first execution of that pipeline for that branch will create a namespace in OpenShift. This will allow the developers to test their new functionality without any contention for a single “dev” environment. Once the feature is complete and the branch in the git repo is deleted, a cleanup job in the pipeline will be triggered, deleting the feature branch namespaces and reclaiming the resources. 

Non-Feature Branch Mechanics

The non-feature branches, such as master, are a known entity, and can be created ahead of time and configured to grant fewer privileges to the service account, to ensure an accidental unwanted change or project deletion is not possible through the pipeline.

GitLab Runners on OpenShift

The GitLab Runner is the application that processes the GitLab pipeline. For each job to be processed, the Runner will spawn a pod to execute the commands in that job.  Runners can be deployed on many different operating systems and there are several ways to deploy a Runner on OpenShift.  In addition to the Kubernetes installation provided by GitLab, the Red Hat Community of Practice (CoP) provides a Runner container image which does not require a privileged SCC to run.  The deployment of the CoP container image uses the standard Helm chart provided for Kubernetes installation.  There are also other sources for the Runner but in this post, we will focus on the Runner provided by the GitLab Operator. 

Deploying the Runner Operator and Runner

The deployment of a GitLab Runner using the OpenShift GitLab Operator has been documented in detail here: Installing the GitLab Runner the OpenShift Way

Configuring the Runner

Scripts for managing the Runner are created as ConfigMaps in your runner project.  These scripts have some parameters for configuring the Runner within the scripts themselves.  For example, `register-runner` has MAX_REGISTER_ATTEMPTS=30 hard coded into it.  Most configuration parameters, however, are set as environment variables in the Runner Deployment resource. 

To see the current settings, one can look at either the Deployment or the running Pod.  For example:

To set KUBERNETES_HELPER_MEMORY_REQUEST to 3G, you can run oc patch with json code similar to the following.

On success, you should see a message like this:

Another oc rsh command into the pod will confirm that your new setting is part of the running environment of the Runner pod: