• GitLab Runner オペレータへのプロパティの渡し方
• オペレータ プロパティ
• キャッシュプロパティ
  • S3キャッシュ
  • GCS キャッシュ
  • Azure キャッシュ
• プロキシ環境の設定
• 設定テンプレートでconfig.toml をカスタマイズします。
• カスタムTLS証明書の設定
• RunnerポッドのCPUとメモリサイズの設定
• クラスターのリソースに基づくランナーごとのジョブの同時実行の設定
• トラブルシューティング
  • ルートと非ルート
    • HOME 環境変数のオーバーライド
    • SCC に注意してください。
    • anyuid として実行 SCC
    • SETFCAPの設定
  • FIPS 準拠の GitLab Runner の使用法
    • 自己署名証明書を使用して GitLab Runner を登録します。
    • IP アドレスを指す外部 URL で GitLab Runner を登録します。

OpenShift での GitLab Runner の設定

OpenShift 上での GitLab Runner の設定方法を説明します。

GitLab Runner オペレータへのプロパティの渡し方

Runner を作成する際には、そのspec にプロパティを設定することで設定を行うことができます。例えば、登録する GitLab URL や、登録トークンを含むシークレットの名前を指定することができます：

apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
 name: dev
spec:
 gitlabUrl: https://gitlab.example.com
 token: gitlab-runner-secret # Name of the secret containing the Runner token

利用可能なプロパティについては、Operator propertiesをご覧ください。

オペレータ プロパティ

Operator に渡すことができるサポートされているプロパティのリストです。

一部のプロパティは、最近のバージョンの Operator でのみ使用できます。

キャッシュプロパティ

S3キャッシュ

GCS キャッシュ

Azure キャッシュ

プロキシ環境の設定

プロキシ環境を構築します：

1. custom-env.yaml ファイルを編集します。例えば

   apiVersion: v1
   data:
     HTTP_PROXY: example.com
   kind: ConfigMap
   metadata:
     name: custom-env
   

2. OpenShift を更新して変更を適用します。

   oc apply -f custom-env.yaml
   

3. gitlab-runner.yml ファイルを更新します。

   apiVersion: apps.gitlab.com/v1beta2
   kind: Runner
   metadata:
     name: dev
   spec:
     gitlabUrl: https://gitlab.example.com
     token: gitlab-runner-secret # Name of the secret containing the Runner token
     env: custom-env
   

プロキシがKubernetes APIに到達できない場合、CI/CDジョブでエラーが表示される可能性があります：

ERROR: Job failed (system failure): prepare environment: setting up credentials: Post https://172.21.0.1:443/api/v1/namespaces/<KUBERNETES_NAMESPACE>/secrets: net/http: TLS handshake timeout. Check https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading for more information

このエラーを解決するには、custom-env.yaml ファイルのNO_PROXY 設定に Kubernetes API の IP アドレスを追加します：

   apiVersion: v1
   data:
     NO_PROXY: 172.21.0.1
     HTTP_PROXY: example.com
   kind: ConfigMap
   metadata:
     name: custom-env

を実行することで、Kubernetes APIのIPアドレスを確認できます：

oc get services --namespace default --field-selector='metadata.name=kubernetes' | grep -v NAME | awk '{print $3}'

設定テンプレートでconfig.toml をカスタマイズします。

設定テンプレートを使用することで、Runnerのconfig.toml 。

1. カスタム設定テンプレートファイルを作成します。例えば、EmptyDir ボリュームをマウントするように Runner に指示してみましょう。custom-config.toml ファイルを作成します：

   [[runners]]
     [runners.kubernetes]
       [runners.kubernetes.volumes]
         [[runners.kubernetes.volumes.empty_dir]]
           name = "empty-dir"
           mount_path = "/path/to/empty_dir"
           medium = "Memory"
   

2. custom-config.toml ファイルからcustom-config-toml という名前のConfigMap を作成します：

    oc create configmap custom-config-toml --from-file config.toml=custom-config.toml
   

3. Runner のconfig プロパティを設定します：

   apiVersion: apps.gitlab.com/v1beta2
   kind: Runner
   metadata:
     name: dev
   spec:
     gitlabUrl: https://gitlab.example.com
     token: gitlab-runner-secret
     config: custom-config-toml
   

カスタムTLS証明書の設定

1. カスタムTLS証明書を設定するには、キーtls.crt でシークレットを作成します。この例では、ファイル名はcustom-tls-ca-secret.yaml です：

   apiVersion: v1
   kind: Secret
   metadata:
       name: custom-tls-ca
   type: Opaque
   stringData:
       tls.crt: |
           -----BEGIN CERTIFICATE-----
           MIIEczCCA1ugAwIBAgIBADANBgkqhkiG9w0BAQQFAD..AkGA1UEBhMCR0Ix
           .....
           7vQMfXdGsRrXNGRGnX+vWDZ3/zWI0joDtCkNnqEpVn..HoX
           -----END CERTIFICATE-----
   

2. シークレットを作成します：

   oc apply -f custom-tls-ca-secret.yaml
   

3. runner.yaml のca キーをシークレットの名前と同じ名前に設定します：

   apiVersion: apps.gitlab.com/v1beta2
   kind: Runner
   metadata:
     name: dev
   spec:
     gitlabUrl: https://gitlab.example.com
     token: gitlab-runner-secret
     ca: custom-tls-ca
   

RunnerポッドのCPUとメモリサイズの設定

カスタムconfig.toml ファイルでCPU 制限と メモリ制限を設定するには、このトピックの説明に従ってください。

クラスターのリソースに基づくランナーごとのジョブの同時実行の設定

Runner リソースのconcurrent プロパティを設定します：

apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
  name: dev
spec:
  gitlabUrl: https://gitlab.example.com
  token: gitlab-runner-secret
  concurrent: 2

ジョブの同時実行はプロジェクトの要件によって決まります。

1. CIジョブを実行するために必要な計算リソースとメモリリソースを決定することから始めましょう。
2. クラスターのリソースがあれば、そのジョブが何回実行できるかを計算します。

concurrencyの値を大きく設定しすぎると、Kubernetes Executorは可能な限り早くジョブを処理します。しかし、Kubernetesクラスタのスケジューラ容量によって、ジョブがいつスケジュールされるかが決まります。

トラブルシューティング

ルートと非ルート

GitLab Runner OperatorとGitLab Runnerポッドは非rootユーザーとして実行されます。そのため、ジョブで使用するビルドイメージは非 root ユーザーで実行しないと正常に完了しません。これは、ジョブが最小限の権限で正常に実行できるようにするためです。ただし、これが機能するためには、CIジョブに使用するビルドイメージも非rootで実行するようにビルドする必要があり、制限されたファイルシステムに書き込んではいけません。OpenShiftクラスター上のほとんどのコンテナファイルシステムは、マウントされたボリューム、/var/tmp 、/tmp およびtmpfs としてルートファイルシステムにマウントされた他のボリュームを除いて、読み取り専用になることに留意してください。

HOME 環境変数のオーバーライド

カスタムビルドイメージを作成したり、環境変数を上書きしたりする場合は、HOME環境変数が読み取り専用になる/ に設定されていないことを確認してください。特に、ジョブがホームディレクトリにファイルを書き込む必要がある場合は注意が必要です。例えば/home の下に/home/ci のようなディレクトリを作成し、DockerfileにENV HOME=/home/ci を設定することができます。

HOME /home/gitlab-runnerこの変数が変更された場合、新しい場所には適切な権限が必要です。これらのガイドラインは、Red Hat Container Platform Docs > Creating Images > Support arbitrary user idsにも記載されています。

SCC に注意してください。

デフォルトでは、新しい OpenShift プロジェクトにインストールすると、GitLab Runner オペレータは非 root として実行されます。例外として、default プロジェクトのように、プロジェクト内のすべてのサービスアカウントにanyuid アクセス権が付与されている場合があります。その場合、イメージのユーザーはroot となります。これは、ジョブなどのコンテナシェル内部でwhoami を実行することで簡単に確認できます。SCC については、Red Hat Container Platform Docs > Managing security contextconstraints を参照してください。

anyuid として実行 SCC

推奨されませんが、CIジョブがrootユーザーとして実行されたり、rootファイルシステムに書き込まれたりすることがどうしても必要なイベントの場合、GitLab Runnerコンテナで使用されるGitLab Runnerサービスアカウントgitlab-runner-sa 、anyuid SCCを設定する必要があります。

OpenShift 4.3.8以前のバージョンでは：

oc adm policy add-scc-to-user anyuid -z gitlab-runner-sa -n <runner_namespace>

# Check that the anyiud SCC is set:
oc get scc anyuid -o yaml

OpenShift 4.3.8 以降の場合：

oc create -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: scc-anyuid
  namespace: <runner_namespace>
rules:
- apiGroups:
  - security.openshift.io
  resourceNames:
  - anyuid
  resources:
  - securitycontextconstraints
  verbs:
  - use
EOF

oc create -f - <<EOF
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sa-to-scc-anyuid
  namespace: <runner_namespace>
subjects:
  - kind: ServiceAccount
    name: gitlab-runner-sa
roleRef:
  kind: Role
  name: scc-anyuid
  apiGroup: rbac.authorization.k8s.io
EOF

SETFCAPの設定

Red Hat OpenShift Container Platform(RHOCP) 4.11 以降を使用している場合、以下のエラーメッセージが表示されることがあります：

error reading allowed ID mappings:error reading subuid mappings for user

一部のジョブ (例えば、buildah) を正しく実行するには、SETFCAP 機能の付与が必要です。このイシューを修正するには、以下の手順に従ってください：

1. GitLab Runner が使用している SCC に SETFCAP ケーパビリティを追加します（gitlab-scc を GitLab Runner のポッドに割り当てられている SCC に置き換えてください）：

   oc patch scc gitlab-scc --type merge -p '{"allowedCapabilities":["SETFCAP"]}'  
   

2. config.toml を更新し、kubernetes セクションの下にSETFCAP ケーパビリティを追加します：

   [[runners]]
     [runners.kubernetes]
     [runners.kubernetes.pod_security_context]
       [runners.kubernetes.build_container_security_context]
       [runners.kubernetes.build_container_security_context.capabilities]
         add = ["SETFCAP"]
   

3. GitLab Runnerがデプロイされているネームスペースに、このconfig.toml を使用してconfigmapを作成します：

   oc create configmap custom-config-toml --from-file config.toml=config.toml 
   

4. 修正したいランナーを修正し、config: パラメーターを追加して、最近作成したコンフィグマップを指すようにします（my-runner を正しいランナーのポッド名に置き換えてください）。

   oc patch runner my-runner --type merge -p '{"spec": {"config": "custom-config-toml"}}'
   

詳細については、Red Hat のドキュメントを参照してください。

FIPS 準拠の GitLab Runner の使用法

FIPSに準拠したGitLab Runner Helperを使用するには、以下のようにヘルパーイメージを変更してください：

apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
 name: dev
spec:
 gitlabUrl: https://gitlab.example.com
 token: gitlab-runner-secret
 helperImage: gitlab/gitlab-runner-helper:ubi-fips
 concurrent: 2

自己署名証明書を使用して GitLab Runner を登録します。

GitLab の自己管理インストールで自己署名証明書を使用する場合は、非公開証明書に署名するために使用する CA 証明書を含むシークレットを作成する必要があります。

そのシークレットの名前を Runner spec セクションの CA として指定します：

KIND:     Runner
VERSION:  apps.gitlab.com/v1beta2

FIELD:    ca <string>

DESCRIPTION:
     Name of tls secret containing the custom certificate authority (CA)
     certificates

シークレットは次のコマンドで作成できます：

oc create secret generic mySecret --from-file=tls.crt=myCert.pem -o yaml

IP アドレスを指す外部 URL で GitLab Runner を登録します。

Runnerが自己署名証明書とホスト名を照合できない場合、エラーメッセージが表示されることがあります。これは、GitLabセルフマネージドインスタンスがホスト名ではなくIPアドレスからアクセスするように設定されている場合に起こる可能性があります（###.##.##.##はGitLabサーバーのIPアドレスです）：

[31;1mERROR: Registering runner... failed               [0;m  [31;1mrunner[0;m=A5abcdEF [31;1mstatus[0;m=couldn't execute POST against https://###.##.##.##/api/v4/runners:
Post https://###.##.##.##/api/v4/runners: x509: cannot validate certificate for ###.##.##.## because it doesn't contain any IP SANs
[31;1mPANIC: Failed to register the runner. You may be having network problems.[0;m

このイシューを修正するには

1. GitLabセルフマネージドサーバーで、openssl を修正し、subjectAltName パラメーターに IP アドレスを追加します：

   # vim /etc/pki/tls/openssl.cnf
      
   [ v3_ca ]
   subjectAltName=IP:169.57.64.36 <---- Add this line. 169.57.64.36 is your GitLab server IP.
   

2. 次に、以下のコマンドで自己署名 CA を生成し直します：

   # cd /etc/gitlab/ssl
   # openssl req -x509 -nodes -days 3650 -newkey rsa:4096 -keyout /etc/gitlab/ssl/169.57.64.36.key -out /etc/gitlab/ssl/169.57.64.36.crt
   # openssl dhparam -out /etc/gitlab/ssl/dhparam.pem 4096
   # gitlab-ctl restart
   

3. この新しい証明書を使って新しいシークレットを生成します。