GitLab Operatorを使ってOpenShiftにGitLabを構築する

この記事はOpenShift Advent Calendar 2022の19日目の記事です。

OpenShiftのOperatorHubでは、Red Hatや3rd Party、Communityが提供しているOperatorなど様々なソフトウェアが提供されていますが、最近Community OperatorとしてGitLabが利用できるようになりました。
今回はこのOperatorを使ってOpenShift環境にGitLabを構築していきたいと思います。
環境はROSA(Red Hat OpenShift on AWS)でOpenShiftのバージョンは4.11.17です。

Operatorのインストール

まずはOperatorをインストールしていきましょう。
OpenShiftコンソールからOperatorHubを選択し、検索ボックスにGitLabと入れます。
そうするとCommunity版のGitLab Operatorが見つかるため、クリックしてインストールします。

この時、インストール先として任意のProjectを選択できます。
今回はデフォルトのgitlab-systemを使用していきます。

ここから早速カスタムリソースを作成してGitLabを構築していきたいところですが、もう一つOperatorをインストールする必要があります。
それがCert-manager Operatorです。先ほどと同じく検索ボックスにcert-managerと入力し、Operatorをインストールしていきます。

Cert-managerはRed Hatが提供するOperatorがあるためそちらを選択し使用していきましょう。（2022年12月現在Tech Preview）
これで準備が整いました。

GitLabカスタムリソースの作成

それではgitlab-systemProjectに移動し、カスタムリソースを作成していきます。
インストール済みのOperatorからGitLabを選択し、GitLabタブを選択します。

GitLabカスタムリソースを作成する際に、構築するGitLabの証明書をどのように設定するか決めることができます。
今回は以下の3つのパターンを全て試してみます。

• 自己証明書を利用するパターン
• ROSAのワイルドカード証明書を利用するパターン
• Cert-managerを使ってGitLab用の証明書を発行するパターン

自己証明書を利用するパターン

まずは自己証明書を利用するパターンです。
GitLabカスタムリソースは以下の通りとなります。

kind: GitLab
apiVersion: apps.gitlab.com/v1beta1
metadata:
  name: gitlab
  namespace: gitlab-system
spec:
  chart:
    values:
      certmanager:
        install: false
      nginx-ingress:
        enabled: false
      global:
        hosts:
          domain: apps.${CLUSTER_NAME}.${YOUR_DOMAIN} #自クラスタのドメインに置き換えて下さい
          hostSuffix: null
        ingress:
          configureCertmanager: false
          tls:
            secretName: null
          class: none
          annotations:
            route.openshift.io/termination: "edge"
    version: '6.6.0'

.spec.chart.values以下でHelmでGitLabをインストールするのと同様のパラメータを設定することができます。（ただし、Helmで有効な設定項目でもOperatorで全て有効になっているわけではなさそうです。）
このパターンではCert-managerを利用した証明書発行は行わないため、Cert-managerのインストールや設定に関する項目はfalseと設定しています。
またGitLabのデフォルトIngressであるNginx-ingressは使用せず、OpenShiftのRouteを使用するためannotationの付与などがされています。

.spec.versionはHelm Chartのバージョンです。利用可能なバージョンはこちらで確認しましょう。
Helmの最新は6.6.2ですが、Operatorでは6.6.0が最新の利用可能バージョンとなっているなど若干の違いがあるようです。

あとはこのyamlファイルを適用するとGitLabの構築がスタートします。
利用可能になるまでしばし待ちましょう。

GitLabのStatusがRunningになったらRouteからGitLabのURLにアクセスします。

無事ログイン画面を開くことができました。

Usernameはroot、Passwordは以下のコマンドで取得できます。

oc get secret gitlab-gitlab-initial-root-password -o "jsonpath={.data.password}" | base64 -d -

ということで、無事ログインすることができました。
しかし、自己証明書を使用しているため次は別の方法でのデプロイを試してみたいと思います。

ROSAのワイルドカード証明書を利用するパターン

ROSAではクラスタ構築時にLet's Encryptによる有効な証明書を取得し設定しているため、これをGitLabにも適用していきます。

まず、必要な証明書チェーンと暗号鍵をローカルに保存します。

oc extract secret/${YOUR_CLUSTER}-primary-cert-bundle-secret --keys=tls.crt -n openshift-ingress
oc extract secret/${YOUR_CLUSTER}-primary-cert-bundle-secret --keys=tls.key -n openshift-ingress

これらを一つのSecretにまとめ、gitlab-systemProjectに作成します。

oc create secret tls gitlab-tls --cert=tls.crt --key=tls.key -n gitlab-system

あとは作成したこのSecretを利用するよう、GitLabのCRを修正します。

kind: GitLab
apiVersion: apps.gitlab.com/v1beta1
metadata:
  name: gitlab
  namespace: gitlab-system
spec:
  chart:
    values:
      certmanager:
        install: false
      nginx-ingress:
        enabled: false
      global:
        hosts:
          domain: apps.${CLUSTER_NAME}.${YOUR_DOMAIN} #自クラスタのドメインに置き換えて下さい
          hostSuffix: null
        ingress:
          configureCertmanager: false
          tls:
            secretName: gitlab-tls # 作成したSecretを指定
          class: none
          annotations:
            route.openshift.io/termination: "edge"
    version: '6.6.0'

.spec.chart.values.global.ingress.tls.secretNameに先ほど作成したSecretを指定します。

カスタムリソースを更新し、しばらく待つとGitLabのURLにアクセスすると有効な証明書が設定されていることが分かります。

これで有効な証明書の設定ができましたが、手動でSecretの作成を行なっているため証明書のローテーションを考えるとやや面倒ですね。
この点をケアすべく、最後にCert-managerを利用するパターンを試してみましょう。

Cert-managerを使ってGitLab用の証明書を発行するパターン

apiVersion: apps.gitlab.com/v1beta1
kind: GitLab
metadata:
  name: gitlab
  namespace: gitlab-system
spec:
  chart:
    values:
      certmanager:
        install: false
      certmanager-issuer:
        email: ${YOUR_EMAIL} # 証明書取得用のメールアドレス
      global:
        hosts:
          domain: apps.${CLUSTER_NAME}.${YOUR_DOMAIN} #自クラスタのドメインに置き換えて下さい
          hostSuffix: null
        ingress:
          annotations:
            route.openshift.io/termination: edge
            kubernetes.io/tls-acme: true
          class: none
      nginx-ingress:
        enabled: false
    version: 6.6.0

.spec.chart.values.certmanager-issuer.emailに証明書発行時に利用するメールアドレスを設定します。
また先ほどまでのパターンではingressのconfigureCertmanager: falseという設定がありましたがこちらを削ったり、annotationを追加したりしています。
こちらを適用するとCert-managerにより発行された証明書を使ってGitLabを構築できます。

証明書の発行先が、このGitLab用のURLに変わっていることが確認できました。
本格的に運用していくことを考えるとこの方法が良さそうかなと思います。

GitLabのメトリクスの取得

さて無事構築できたGitLabですが、実はインストールした時点でPrometheusでメトリクスを取得するためのExporterやServiceMonitorが自動的に作成されます。

oc get pod | grep exporter
---
gitlab-gitlab-exporter-65c8bb6888-hc6qj      1/1     Running     0          29m

oc get servicemonitor
---
NAME                     AGE
gitlab-gitaly            93m
gitlab-gitlab-exporter   93m
gitlab-postgresql        93m
gitlab-redis             93m
gitlab-webservice        93m

そのため、OpenShiftではユーザー定義プロジェクトのモニタリングを有効化するだけでGitLabのメトリクスを取得することができます。ROSAの場合こちらはデフォルトで有効化されています。（クラスタ作成時の設定に依ります）

Self-managedでクラスタを構築している場合は、以下のyamlファイルを適用してあげましょう。

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    enableUserWorkload: true

OpenShiftコンソールのメトリクスからGitLabのメトリクス名を指定することで情報を得ることができます。
取得できるPrometheusのメトリクスについてはこちらを参照しましょう。

GitLab Runnerのインストール

せっかくなのでGitLabでCI/CDを実行する際に必要となるGitLab RunnerについてもOperatorでインストールしたいと思います。

再びOperatorHubに移り、GitLab Runnerを探します。
この時、Community版とCertified版という二つのバージョンがありますが、Community版の方がバージョンが新しそうなのでそちらをインストールします。

インストールするProjectを選択することができますが、今回はGitLab Operatorと同じgitlab-systemにインストールします。

ここからまずGitLab Runnerを登録するためのTokenを払い出しSecretとして登録するのですが、GitLab Operatorを使ってGitLabを構築している場合は、gitlab-gitlab-runner-secretという名前で必要なSecretが既に作成されています。便利ですね。

一応外部のGitLabを使用する場合を踏まえ、手動でTokenを登録する方法も書いておきましょう。
まずGitLabのAdmin画面からRunnersを選択し、登録用のTokenをコピーします。

コピーしたTokenを元にGitLab Runnerの登録用Secretを作成します。

apiVersion: v1
kind: Secret
metadata:
  name: gitlab-runner-secret
type: Opaque
stringData:
  runner-registration-token: NdX... # ここにコピーしたTokenを貼る

あとはGitLab Runnerを登録するため、TokenのSecretを使用するようRunnerカスタムリソースを作成すれば完了です。

apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
 generateName: gitlab-runner-
spec:
 gitlabUrl: https://gitlab.apps.xxx.yyy.com # GitLabのURL
 buildImage: registry.access.redhat.com/ubi8/ubi
 token: gitlab-runner-secret # TokenのSecret
 tags: openshift

GitLabのAdmin画面から無事Runnerが登録できたことが確認できます。

Runnerを増やしたい場合はDeploymentのPod数を変更するのではなく、Runnerカスタムリソースを新たに追加すればOKです。(RunnerカスタムリソースでgenerateNameを使っていたのはこの理由からです。)

まとめ

今回はOpenShiftにGitLabをインストールしてみました。Operatorで気軽にGitリポジトリを立てれるのは有難いですね。みなさんも是非試してみて下さい。