Open in app

Sign in

Write

Sign in

Building GitLab Runner Operator on Power

Sneha Gaonkar
6 min readAug 16, 2021

--

The GitLab Runner operator aims to manage the lifecycle of GitLab Runner instances in your Kubernetes or Openshift container platforms. The GitLab Runner operator uses native Kubernetes resources to deploy and manage GitLab Runner instances in your cluster.

GitLab Runner Operator for Power

GitLab has gained a lot of popularity in past few years. Providing a way to deploy GitLab and Red Hat together supports developers in application development. Recently, GitLab Runner was officially released for ppc64le architecture in v14.3.0. However, the GitLab Runner operator is currently available only for the amd64 architecture and does not have Power support.

This blog will take you through the steps to set up GitLab runner operator on Power. We will use the officially available Power images from GitLab runner ubi images repository. However, if you want to build the images yourself, you can check this blog.

Pre-requisites

  • A standalone VM to build the required image/binaries.

This example uses a ppc64le Ubuntu 20.04.2 LTS VM. You can use PowerVS service at IBM Cloud or Minicloud to get your ppc64le virtual machine.

  • A ppc64le OCP cluster for deploying the GitLab Runner Operator

You can deploy a Red Hat OpenShift cluster on IBM Power Systems Virtual Servers using steps in this article: https://developer.ibm.com/components/ibm-power/tutorials/install-ocp-on-power-vs/

  • A Gitlab project where you will be creating the Gitlab runners to run the pipelines

Installing Dependencies

You need to install the following dependencies on the VM you will use to build the operator and related images:

  • Golang, Make and other dependencies
apt-get update && apt-get install -y qemu binfmt-support qemu-user-static qemu-system-ppc64 python3-pip golang
  • Docker

The steps for docker installation can be found here.

  • Operator SDK
wget https://github.com/operator-framework/operator-sdk/releases/download/v1.5.0/operator-sdk_linux_ppc64lechmod +x operator-sdk_linux_ppc64le && mv operator-sdk_linux_ppc64le /usr/local/bin/operator-sdk
  • Kustomize
go get sigs.k8s.io/kustomize/kustomize/v3
  • OPM
wget https://mirror.openshift.com/pub/openshift-v4/ppc64le/clients/ocp/4.6.22/opm-linux-4.6.22.tar.gztar -C /usr/bin/ -zxvf opm-linux-4.6.22.tar.gz && rm opm-linux-4.6.22.tar.gzopm version
  • Export the environment variables below:
export OS=linux
export ARCH=ppc64le
export DOCKER_REGISTRY=”<Path to your registry. We used quay.io>”
export VERSION=main
export DOCKER_CLI_EXPERIMENTAL=enabled

Gitlab Runner and Helper UBI images

GitLab Runner and Helper UBI images are officially available for Power. Below images will be used internally in the release.yaml, generated for building operator image in the next section:

1)GitLab Runner
registry.gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images/gitlab-runner-ocp:ppc64le-main2)GitLab Runner Helper
registry.gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images/gitlab-runner-helper-ocp:ppc64le-main

Building Gitlab-Runner-Operator image and bundle

The source code for building this image can be found here. Switch to the multiarch-support branch which has code changes for building required images for specified OS/Architecture. See issue.

  • Generate release.yaml file
CERTIFIED=false \
ARCH=”${ARCH}” \
UPSTREAM_UBI_IMAGES_REPOSITORY=”${DOCKER_REGISTRY}” \
./scripts/create_release_config.sh v1.0.0 “${VERSION}”cat hack/assets/release.yaml
  • Build gitlab-runner-operator image
docker buildx build — platform “${OS}/${ARCH}” \
— build-arg VERSION=”${VERSION}” \
— build-arg ARCH=”${ARCH}” \
-f Dockerfile \
-t “${DOCKER_REGISTRY}/gitlab-runner-operator:v1.0.0” .docker push ${DOCKER_REGISTRY}/gitlab-runner-operator:v1.0.0
  • Generate related_images.yaml and create certification bundle
CERTIFIED=false \
ARCH=”${ARCH}” \
UPSTREAM_UBI_IMAGES_REPOSITORY=”${DOCKER_REGISTRY}” \
GITLAB_RUNNER_OPERATOR_REGISTRY=”${DOCKER_REGISTRY}” \
KUBE_RBAC_PROXY_IMAGE=”registry.redhat.io/openshift4/ose-kube-rbac-proxy:latest” \
./scripts/create_related_images_config.sh v1.0.0 “${VERSION}”make bundle certification-bundle IMG=${DOCKER_REGISTRY}/gitlab-runner-operator:v1.0.0 BUNDLE_IMG=${DOCKER_REGISTRY}/gitlab-runner-operator-bundle:v1.0.0 VERSION=v1.0.0 CERTIFIED=false
  • Build operator bundle
docker buildx build — platform “${OS}/${ARCH}” \
— build-arg VERSION=”${VERSION}” \
-f certification.Dockerfile \
-t “${DOCKER_REGISTRY}/gitlab-runner-operator-bundle:v1.0.0” .docker push ${DOCKER_REGISTRY}/gitlab-runner-operator-bundle:v1.0.0
  • Generate index image
opm index add \
— bundles “${DOCKER_REGISTRY}/gitlab-runner-operator-bundle:v1.0.0” \
— tag “${DOCKER_REGISTRY}/gitlab-runner-operator-catalog-source:v1.0.0” \
— build-tool docker \
— binary-image registry.redhat.io/openshift4/ose-operator-registry@sha256:80e12437142a91b14c01f6c385c98387daa628669bbfd70bf78fb4602a398bc5docker push “${DOCKER_REGISTRY}/gitlab-runner-operator-catalog-source:v1.0.0”
  • Create manifest
docker manifest create “${DOCKER_REGISTRY}/operator-catalog-manifest:v1.0.0” “${DOCKER_REGISTRY}/gitlab-runner-operator-catalog-source:v1.0.0”docker manifest push “${DOCKER_REGISTRY}/operator-catalog-manifest:v1.0.0”

Installing GitLab Runner Operator using CatalogSource

  • Create CatalogSource
  1. On the cluster bastion node, create a CatalogSource in the ‘openshift-marketplace’ namespace.
export DOCKER_REGISTRY=”quay.io/gitlab-power-images”cat > catalogsource.yaml << EOF
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: gitlab-runner-catalog
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: ${DOCKER_REGISTRY}/operator-catalog-manifest:v1.0.0
  displayName: GitLab Runner Operators
  publisher: GitLab Community 
EOFoc apply -f catalogsource.yaml

2. Verify the CatalogSource has been created

oc -n openshift-marketplace get catalogsource

Once you have confirmed the catalogsource exists, run the following command to verify it’s associated pod is successfully running. This verifies that the index image has been successfully pulled down from the repository.

oc -n openshift-marketplace get pods

You should see output like this:

The CatalogSource can also be viewed from Cluster Settings> Global Configuration > OperatorHub > Sources :

  • Create OperatorGroup

1. Create a namespace for your project.

export NEW_PROJECT=gitlab-runner-systemoc new-project $NEW_PROJECT

2. Create OperatorGroup.

cat > test-operatorgroup.yaml << EOF
apiVersion: operators.coreos.com/v1alpha2
kind: OperatorGroup
metadata:
  name: my-group
  namespace: ${NEW_PROJECT}
spec:
  targetNamespaces:
      - ${NEW_PROJECT}
EOFoc apply -f test-operatorgroup.yaml

Verify you have a working operatorgroup within the namespace you created:

oc get ogNAME        AGE
my-group     8s
  • Create Subscription

1. Create a subscription

cat > test-subscription.yaml << EOF
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: test-subscription
spec:
  channel: stable
  installPlanApproval: Automatic
  name: gitlab-runner-operator
  source: gitlab-runner-catalog
  sourceNamespace: openshift-marketplace
EOFoc create -f test-subscription.yaml

Verify the subscription is created within your namespace:

oc get sub -n ${NEW_PROJECT}

The creation of the subscription should trigger the creation of the InstallPlan.

oc get installplan -n ${NEW_PROJECT}NAME           CSV                            APPROVAL    APPROVED
install-lhfp4 gitlab-runner-operator.v1.0.0   Automatic    true

The install plan will create the gitlab runner manager pod in your namespace:

  • Create Runner

1. Create the secret file with your GitLab project’s runner token:

Go to your Gitlab project’s Settings > CI/CD > Expand Runners > Copy your ‘Registration token”

cat > gitlab-runner-secret.yml << EOF
apiVersion: v1
kind: Secret
metadata:
  name: gitlab-runner-secret
type: Opaque
stringData:
  runner-registration-token: REPLACE_ME # your project runner secret
EOFoc apply -f gitlab-runner-secret.yml

2. Create the Runner from CRD

Create Custom Resource Definition (CRD) file with the following information. The tags value must be openshift for the job to run.

cat > gitlab-runner.yml << EOF
apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
  name: gitlab-runner
spec:
  gitlabUrl: <YOUR GITLAB INSTANCE URL>
  buildImage: alpine
  token: gitlab-runner-secret
  tags: openshift
EOFoc apply -f gitlab-runner.yml

Confirm that GitLab Runner is installed by running:

oc get runnersNAME               AGE
gitlab-runner      5m

The runner pod should also be visible in NEW_PROJECT namespace:

Verify that runner is listed in “Specific runners” list for the Gitlab project. In your Gitlab project, go to Settings > CI/CD > Expand Runners :

3. Configuring code to use the new Runner

Modify the tag field in .gitlab-ci.yaml file to use the newly available runner. Link to sample repository used in this tutorial- https://gitlab.com/skanekar1/myfirstproject/

A new build will now use the ‘openshift’ runner. It will create a new pod to run the build:

Done! You have now configured your Gitlab project to use Gitlab runner for Power. The Gitlab runner operator will manage the lifecycle of your runners.

Hope this tutorial was helpful. Thanks for reading :)

Gitlab
Openshift
Ibm Power Systems
Operators
Gitlab Runner

--

--

Sneha Gaonkar

Written by Sneha Gaonkar

20 Followers

Cloud engineer at Dataroots

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams