Storing source code, running CI/CD jobs, and DevOps pipelines are core developer workflows. OpenShift and GitLab customers depend on these workflows on top of their OpenShift clusters to get work done.
We have previously covered our closer collaboration with GitLab. Our engineering teams have engaged on a joint roadmap for two main capabilities, the GitLab Runner Operator and a new Operator for running all of GitLab.
GitLab Runner Operator
Certified for OpenShift, the Operator allows GitLab to communicate with OpenShift clusters to push and manage jobs and monitor activities. This makes it easy for excess cluster capacity to meet demand for CI/CD jobs and tests applications in the same environment in which they will run. The Operator has been available since June 2020.
GitLab Operator
This Operator is ambitious in scope – managing a complete GitLab footprint – while allowing re-use of GitLab’s investment in Helm. It is currently in Beta and you can try it out today.
The goals of the Operator are to:
- ease installation and configuration of GitLab instances
- offer seamless upgrades from version to version
- ease backup and restore of GitLab and its components
- aggregate and visualize metrics using Prometheus and Grafana
- enhance auto-scaling with application level knowledge
As you can see in the example below, the Operator is currently re-using most of the existing Chart, but will quickly move beyond that to climb up the Operator Maturity Model.
apiVersion: apps.gitlab.com/v1beta1
kind: GitLab
metadata:
name: example
spec:
chart:
version: "X.Y.Z"
values:
global:
hosts:
domain: example.com
11 lines of YAML to get a complete distributed system and access to all of the power of GitLab – the simplicity and power of using an Operator is incredible. Of course, under the hood there is a lot of heavy lifting to install the components of GitLab that provide the UI, source code management, asset storage, monitoring, logging, and much more.
Driving Consistency With an Operator
Customers in certain verticals like finance, government, and health care will frequently require isolated installations of their DevOps tools, and GitLab is no different. The Operator drives consistency between installations so you can be assured that each is configured correctly.
When it comes time to upgrade, the GitLab Operator can enforce consistency during this process and prevent human errors. Between install and upgrade, the Operator is constantly ensuring that autoscaling, monitoring, and other housekeeping tasks are executed on time, fully autonomously.
Works Out of the Box With OpenShift’s Higher Security
GitLab’s existing Helm chart does not work out of the box against OpenShift’s default security posture, which goes above and beyond standard Kubernetes. This was a frequent friction point for OpenShift customers using GitLab. The new Operator will address the issue through improved UID handling via a SecurityContextConstraint (SCC).
The Operator will be namespace-scoped in terms of access control and blast radius, and multiple GitLab installations can be managed within that scope.
Integration With Other Certified Operators
The beta version of the GitLab Operator can integrate with the certified nginx-ingress Operator from Nginx for handling traffic into the application and the certified cert-manager from JetStack to secure that traffic.
Try It on OpenShift
You can try out the beta version of the GitLab Operator by following the install instructions. Stay tuned for more updates, and look for a certified version of the Operator as it becomes feature complete.
You can also find the GitLab Runner Operator ready to go inside of OperatorHub in your OpenShift cluster.
Red Hat is excited to build a world-class DevOps platform together with GitLab for the entire OpenShift community.
Categories
