Container Compute Service:ACS クラスターでの GitLab Runner を使用した CI/CD 環境の構築

ステップ 1: GitLab Runner チャートの取得

helm repo add gitlab https://charts.gitlab.io
helm repo update gitlab
helm pull gitlab/gitlab-runner --version 0.68.1 && tar zvxf gitlab-runner-0.68.1.tgz

ステップ 2: values.yaml の作成

GitLab Runner を実行するには、3 つのパラメーターが必要です。

以下の values.yaml は、推奨設定を含む動作する構成を示しています。

## GitLab Runner イメージ
##
## デフォルトでは registry.gitlab.com/gitlab-org/gitlab-runner:alpine-v{VERSION} を使用します
## ここで、{VERSION} は Chart.yaml の appVersion フィールドから取得されます
##
## 参照: https://gitlab.com/gitlab-org/gitlab-runner/container_registry/29383?orderBy=NAME&sort=asc&search[]=alpine-v&search[]=
##
## 注: イメージを Ubuntu リリースに変更する場合は、
##       securityContext の変更を忘れないでください。
##       これらのイメージは異なるユーザー ID で実行されます。
##
...

## runner を登録する GitLab サーバーの URL (プロトコルを含む)
## 参照: https://docs.gitlab.com/runner/commands/index.html#gitlab-runner-register
##
gitlabUrl: https://jihulab.com/

## 非推奨: 新しい Runner を GitLab サーバーに追加するための登録トークン。
##
## 参照: https://docs.gitlab.com/ee/ci/runners/new_creation_workflow.html
##
# runnerRegistrationToken: ""

## 新しい Runner を GitLab サーバーに追加するための Runner トークン。これは
## GitLab インスタンスから取得する必要があります。すでに登録されている runner のトークンです。
## 参照: (これに関するドキュメントはまだありませんが、既存のトークンを使用します)
##
runnerToken: "glrt-t3_sz6xxxxxxxxxDsWF77"
#

## 終了前にすべての runner の登録を解除する
##
## runner の chart バージョンまたは構成を更新すると、runner コンテナが
## 終了されて再作成されます。これにより、Gitlab インスタンスが
## 存在しない runner を参照する可能性があります。終了前に runner の登録を解除すると、この問題が軽減されます。
## 参照: https://docs.gitlab.com/runner/commands/index.html#gitlab-runner-unregister
##
unregisterRunners: true

## runner を停止するときは、ジョブが終了するのを待つ時間を与えます。
##
## runner の chart バージョンまたは構成を更新すると、runner コンテナは
## 正常な停止リクエストで終了します。terminationGracePeriodSeconds は
## runner の Pod が正常に終了するのに十分な時間待機するように Kubernetes に指示します。
## 参照: https://docs.gitlab.com/runner/commands/#signals
terminationGracePeriodSeconds: 3600

## GitLab Runner が使用するカスタム証明書を渡すために certsSecretName を設定します。
## 同じ名前空間にある Kubernetes Secret オブジェクトのリソース名を指定します。
## これは /home/gitlab-runner/.gitlab-runner/certs/ ディレクトリにデータを格納するために使用されます
## 参照: https://docs.gitlab.com/runner/configuration/tls-self-signed.html#supported-options-for-self-signed-certificates-targeting-the-gitlab-server
##
# certsSecretName:

## 同時ジョブの最大数を構成します
## 参照: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
##
concurrent: 10

...

## RBAC サポートの場合:
rbac:
  ## Role と RoleBinding を作成するかどうかを指定します
  ## この値を `true` に設定した場合、`serviceAccount.create` も `true` または `false` のいずれかに設定する必要があります
  ##
  create: true
  ## create が true に設定されている場合に生成される serviceAccountName を定義します
  ## 指定しない場合、デフォルトは "gitlab-runner.fullname" になります
  ## 非推奨: 代わりに `serviceAccount.name` を使用してください
  generatedServiceAccountName: ""
...

## runner が新しいジョブごとに起動する Pod の構成
##
runners:
  # runner の構成。複数行の文字列は
  # テンプレートとして評価されるため、その中に Helm の値を指定できます。
  #
  # tpl: https://helm.sh/docs/howto/charts_tips_and_tricks/#using-the-tpl-function
  # runner の構成: https://docs.gitlab.com/runner/configuration/advanced-configuration.html
  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "alpine"

  ## 既存の runner 構成ファイルの絶対パス
  ## "volumes" および "volumeMounts" とともに使用して、外部構成ファイルを使用できます
  ## runners.config が空または null の場合にアクティブになります
  configPath: ""
...

以下の表は、主要なパラメーターについて説明しています。

ステップ 3: GitLab Runner のインストール

helm install --namespace default gitlab-runner -f values.yaml --version 0.68.1 gitlab/gitlab-runner

インストールの検証

kubectl get pod | grep gitlab

期待される出力:

gitlab-runner-7c5b4xxxxx-xxxxx   1/1     Running     0          5m17s

方法 1: クラスター内のすべての Pod に BestEffort QoS を構成

クラスター内のすべての Pod に BestEffort QoS クラスを構成することを推奨します。ビジネス要件に基づいて、他の QoS クラスを選択することもできます。

Runner が作成するすべてのジョブ Pod に BestEffort QoS を適用するには、values.yaml に Pod ラベルを追加します。

...
runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        ...
        pod_labels_overwrite_allowed = ".*" # Allow the system to overwrite the labels of project pods based on variables.
      [[runners.kubernetes.pod_labels]]
      "app" = "acs-gitlab-runner"
      "alibabacloud.com/compute-class" = "general-purpose"
      "alibabacloud.com/compute-qos" = "best-effort" # Configure the BestEffort QoS class for pods.
...

プロジェクトごとに異なる QoS クラスを適用するには、代わりにプロジェクトの .gitlab-ci.yml に対応する KUBERNETES_POD_LABELS_* 変数を追加します。上記の「kaniko の例」をご参照ください。

方法 2: 自動フェイルオーバーのための ResourcePolicy の構成

ResourcePolicy を使用すると、カスタムスケジューリング優先度を定義できます。ジョブ Pod は最初に BestEffort 容量にスケジュールされます。リージョンで BestEffort Pod が枯渇すると、システムは自動的にデフォルト Pod を作成し、CI ジョブの継続性と可用性を確保します。

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: rp-demo
  namespace: default
spec:
  selector: # Specify the label selector used to select pods. In this example, the ResourcePolicy is applied to pods that have the app=stress label.
    app: acs-gitlab-runner
  units: # Specify the priorities of different types of nodes for pod scheduling.
  - resource: acs # Prioritize BestEffort resources.
    podLabels:
      alibabacloud.com/compute-class: general-purpose
      alibabacloud.com/compute-qos: best-effort
  - resource: acs # Apply for Default resources when the preceding resources are out of stock.
    podLabels:
      alibabacloud.com/compute-class: general-purpose
      alibabacloud.com/compute-qos: default

Runner マネージャー Pod の再起動後に残留 Pod が存在する理由

マネージャー Pod が異なる Runner トークンで再作成されると、以前のトークンで作成されたジョブ Pod を管理する能力を失います。それらの Pod は残留しますが、追跡されなくなります。

これを回避するには:

• GitLab で Runner を再作成し、構成ファイルで Runner トークンを更新してください。

• 登録トークンを使用する場合は、初期登録からのトークンを含む Secret をマネージャー Pod にマウントしてください。これにより、再起動全体で同じトークンが再利用されることが保証されます。

• FF_USE_POD_ACTIVE_DEADLINE_SECONDS を有効にしてください。これにより、各ジョブ Pod の TTL がジョブタイムアウトに設定され、孤立した Pod が自動的にクリーンアップされます。