Skip to content

Add documentation on how to configure an air-gapped (offline) install of the GitLab Runner Operator

Overview

We recently released a new version of the runner operator that enables users to install the runner in air-gapped environments.

Problem

For now, we don't have a way to install GitLab Runner Operator on a Kubernetes/Openshift cluster on an isolated network.

For example, we have a customer that has a Kubernetes instance on an isolated network. They follow the steps listed here to install the GitLab Runner operator on their Kubernetes cluster.

They were able to override the image for cert manager and OLM, but when it came to installing the Operator via the command kubectl create -f https://operatorhub.io/install/gitlab-runner-operator.yaml, the job that OLM generated to install the operator failed as it won't be able to pull the image required for the job.

On my test, installing the GitLab Runner Operator will trigger a job in the olm namespace that requires the following images:

          image: quay.io/operator-framework/upstream-opm-builder:latest
          image: quay.io/operator-framework/olm@sha256:2b4fee73c05069d9d2c537c7d3072241097914748abfb938b5b08c969b2f544b
          image: quay.io/operatorhubio/gitlab-runner-operator@sha256:c55775df9fbea15324e14c43669ceebb01498fd28c1abaa132ea5bb4c4c5b9e8

There is no clear way on how to override these images. In the customer's case, the job is failing as they only have a trusted registry to pull the image from.

Also related to #120

Proposal

The scope of this issue is to add a section to the install GitLab runner operator docs that covers the configuration steps required to install the Runner Operator on a Kubernetes cluster in an air-gapped environment.

Edited by Darren Eastman