The integration of GitLab CI/CD with OpenShift represents a strategic convergence of high-level orchestration and automated software delivery pipelines. OpenShift, as a Kubernetes-based platform, provides a robust environment for developing, deploying, and managing container-based applications. It offers a self-service platform that allows users to create, modify, and deploy applications on demand, which significantly accelerates development and release lifecycles. While OpenShift includes native CI/CD solutions rooted in Jenkins or Tekton, the ability to integrate external tools like GitLab allows organizations to leverage specific ecosystem preferences while maintaining the security and scalability of the OpenShift environment. This integration is not merely about connecting two tools but about establishing a secure, scalable, and automated pathway from code commit to production deployment.
The central component of this architecture is the GitLab Runner. These are the applications responsible for processing CI/CD jobs originating from either GitLab.com or self-hosted GitLab instances. While GitLab.com provides shared hosted runners, enterprises often require dedicated private runners to maintain control over their pipeline infrastructure. In the context of OpenShift, the GitLab Runner Operator serves as the primary vehicle for this implementation. As a Red Hat Certified Operator, it enables a cloud-native installation that minimizes manual setup and maintenance. This allows engineers to shift their focus from infrastructure management to the actual content and configuration of their builds.
The architectural relationship between GitLab and OpenShift is multifaceted. It spans from running the GitLab application itself on an OpenShift cluster via the GitLab Operator to managing a fleet of runners via the GitLab Runner Operator. Furthermore, for those deploying custom or Commercial Off-the-Shelf (COTS) applications, the GitLab agent for Kubernetes provides the necessary integration for deployment. This comprehensive ecosystem ensures that every stage of the software development lifecycle—from the initial build to the final deployment—is managed within a secure, containerized framework.
OpenShift and GitLab Compatibility Framework
The compatibility between OpenShift and GitLab is categorized into three distinct functional aspects, each serving a specific role in the deployment architecture.
- Use OpenShift to run GitLab Self-Managed: This involves utilizing the GitLab Operator to deploy the entire GitLab application within an OpenShift cluster. This approach is ideal for organizations that require total control over their source code management and CI/CD orchestration.
- Use OpenShift to run a GitLab Runner Fleet: The GitLab Operator does not include the GitLab Runner. To deploy and manage a fleet of runners, the GitLab Runner Operator must be used. This allows for the scaling of job execution capacities within the OpenShift cluster.
- Deploy to and integrate with OpenShift from GitLab: This is achieved through the GitLab agent for Kubernetes, allowing users to push applications from a GitLab repository directly into an OpenShift environment.
The following table outlines the specific tools used for each compatibility aspect:
| Compatibility Aspect | Primary Tool/Operator | Function |
|---|---|---|
| GitLab Self-Managed | GitLab Operator | Full Application Deployment |
| Runner Management | GitLab Runner Operator | Job Execution Fleet |
| Deployment Integration | GitLab agent for Kubernetes | Application Orchestration |
The GitLab Runner Operator Deployment Process
The GitLab Runner Operator is recognized as the only secure way to integrate GitLab CI/CD with Kubernetes, as it leverages the native operator pattern to manage the lifecycle of runner instances. The deployment process involves several critical configuration steps to ensure secure communication between the OpenShift cluster and the GitLab instance.
The initial phase begins with the creation of a dedicated project or namespace within OpenShift. This isolation ensures that the CI/CD tooling does not interfere with other application namespaces.
- Create the project: The command
oc new-project gitlabis used to initialize the namespace. This provides a clean environment for the operator and subsequent runners.
Once the namespace is established, the operator must be installed. This can be achieved through the OpenShift UI by navigating to Administrator > Operators > OperatorHub and searching for "Gitlab". For those preferring a command-line approach, the operator can be deployed by applying a specific configuration file.
- Install the Operator: The command
oc apply -f kubefiles/gitlab-operator.yamlis utilized to deploy the operator via YAML.
After the operator is installed, a GitLab runner instance must be deployed. This requires a mapping mechanism to connect the runner to the GitLab project, which is achieved through a GitLab token.
- Retrieve GitLab Token: The user must log in to their GitLab repository and navigate to settings > CI / CD > Runners to expand the section and retrieve the necessary token.
CI/CD Pipeline Configuration and Execution
Once the infrastructure is in place, the pipeline configuration is defined using a .gitlab-ci.yml file. This file dictates the sequence of jobs, the environment in the which they run, and the specific commands executed. A typical project structure for this integration includes a Flask application, a Dockerfile for building images, and a kubefiles folder containing the necessary Kubernetes YAML configurations.
The runner's container image must be equipped with specific utilities to interact with the OpenShift environment and the container registry. These tools include:
- Skopeo: Used for inspecting and copying images between registries.
- oc: The OpenShift command-line tool.
- kubectl: The standard Kubernetes command-line tool.
- kn: Tools for interacting with Knative.
To execute the pipeline, the user navigates to the Pipelines section in GitLab and clicks "Run Pipeline". If the pipeline remains in a "stuck" status, it is imperative to ensure that the "run untagged jobs" option is enabled for the runner.
Advanced Integration with Quay and Container Scanning
A critical aspect of modern CI/CD is the integration of container scanning to prevent vulnerable images from reaching production. By leveraging the Quay container registry, organizations can implement a security gate within the pipeline.
The workflow integrates Quay to store and scan the container image. If vulnerabilities are discovered during the scanning process, the deployment can be interrupted, ensuring that only secure images are deployed to the OpenShift cluster. This creates a security loop where the build is validated against known vulnerabilities before the OpenShift Serverless capability is triggered.
OpenShift Serverless and Knative Integration
OpenShift Serverless is a "bonus" capability that can be deployed as an operator to handle application serving. This allows for a more efficient deployment model where the application is served via Knative.
The deployment of OpenShift Serverless follows these steps:
- Install the Operator: Navigate to the OperatorHub in the OpenShift instance and install the "Openshift Serverless" operator.
- Create Project: Create a new
knative-servingproject. - Initialize Serving: Navigate to Installed Operators > Openshift Serverless Operator > Knative Serving > Create Knative Serving.
Once configured, the GitLab CI/CD pipeline can deploy the application using OpenShift's Serverless Serving capability, provided that the base image and code are free of vulnerabilities.
Specialized Build Use Cases: Fedora Silverblue and Immutable Images
The GitLab Runner Operator can be used to create customized base images for Fedora Silverblue, an immutable distribution of Fedora Linux. Fedora Silverblue utilizes a hybrid image and package management system known as rpm-ostree, which allows the system to boot directly from OCI containers.
In this specific use case, the GitLab CI/CD pipeline is used to build customized Silverblue images that include the most recent releases of OpenShift and Operator tooling.
The build process for these images involves several technical configurations within the .gitlab-ci.yml and the Containerfile:
- Filesystem Management: Since most container filesystems in OpenShift are read-only, the
$HOMEvariable is changed to/tmpto ensure write capabilities. - VFS Usage: The use of
vfsis currently the simplest solution for these builds. - Build Script: The script utilizes predefined GitLab CI variables to sign into the GitLab container registry, build the image, tag it, and push it to the registry.
The outcome of this setup is a self-hosted CI/CD pipeline that generates custom Silverblue images at scheduled intervals or upon commits to the main branch. Users can then update their local Silverblue installation using the command rpm-ostree update.
Security Model and Unsupported Features
While the integration is powerful, OpenShift's stringent security model introduces certain limitations. Specifically, features that require Docker-in-Docker (DinD) may not function as expected when running a GitLab Runner fleet on OpenShift.
- Docker-in-Docker: This is unsupported due to the security constraints of the OpenShift environment.
- Auto DevOps: Certain features of Auto DevOps are not yet supported in this configuration.
Summary of Technical Specifications and Tools
The following table summarizes the technical components involved in the GitLab-OpenShift integration:
| Component | Tool/Technology | Role in Pipeline |
|---|---|---|
| Orchestrator | OpenShift | Platform for Deployment and Management |
| CI/CD Engine | GitLab CI/CD | Pipeline Logic and Job Triggering |
| Runner Manager | GitLab Runner Operator | Lifecycle Management of Runners |
| Registry | Quay | Image Storage and Vulnerability Scanning |
| Serverless Layer | Knative / OpenShift Serverless | Application Serving |
| Immutable OS | Fedora Silverblue | Target for Custom Base Images |
| Package Manager | rpm-ostree | Image-based System Updates |
Analysis of Infrastructure Outcomes
The implementation of a GitLab Runner Operator on OpenShift transforms the CI/CD process from a manual, error-prone sequence into a streamlined, cloud-native operation. By utilizing a Red Hat Certified Operator, the manual overhead associated with the installation and maintenance of runners is virtually eliminated. This architectural choice ensures that the runner fleet is scalable and can handle concurrent jobs without requiring manual intervention, unless there is a need to reconfigure job tags.
The integration of Quay introduces a critical security layer. The ability to interrupt a deployment based on vulnerability scanning results prevents the proliferation of insecure images in the production environment. This shifts security "left" in the development lifecycle, ensuring that vulnerabilities are caught during the build phase rather than after deployment.
Furthermore, the use of OpenShift Serverless via Knative provides a modern approach to application delivery, reducing the complexity of scaling and resource management. When combined with the ability to build immutable images for Fedora Silverblue, the system demonstrates a high level of sophistication, allowing for the creation of specialized, immutable environments that are updated via OCI container streams. This approach not only improves stability but also simplifies the rollback process via rpm-ostree rollback, providing a fail-safe mechanism for system administration.