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:
$ oc rsh example-runner-787df7bf58-jpgjn env | grep MEM KUBERNETES_SERVICE_MEMORY_REQUEST= KUBERNETES_HELPER_MEMORY_LIMIT= KUBERNETES_MEMORY_REQUEST= KUBERNETES_MEMORY_LIMIT= KUBERNETES_HELPER_MEMORY_REQUEST= KUBERNETES_SERVICE_MEMORY_LIMIT= |
To set KUBERNETES_HELPER_MEMORY_REQUEST to 3G, you can run oc patch with json code similar to the following.
$ oc patch deployment example-runner -p '{"spec":{"template":{"spec":{"containers":[{"image":"registry.connect.redhat.com/gitlab/gitlab-runner:12.9","name":"runner","env":[{"name":"KUBERNETES_HELPER_MEMORY_REQUEST","value":"3G"}]}]}}}}' |
On success, you should see a message like this:
deployment.apps/example-runner patched |
Another oc rsh command into the pod will confirm that your new setting is part of the running environment of the Runner pod:
$ oc rsh example-runner-f5b546b76-dvkjk env | grep MEM KUBERNETES_MEMORY_LIMIT= KUBERNETES_HELPER_MEMORY_REQUEST=3G KUBERNETES_SERVICE_MEMORY_REQUEST= KUBERNETES_HELPER_MEMORY_LIMIT= KUBERNETES_MEMORY_REQUEST= KUBERNETES_SERVICE_MEMORY_LIMIT= |
About the authors
More like this
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit