GitLab-Gitalyチャートの使用

gitalyサブチャートは、Gitalyサーバーの構成可能なデプロイを提供します。

要件

このチャートは、完全なGitLabチャートの一部として、またはこのチャートがデプロイされるKubernetesクラスタから到達可能な外部サービスとして提供されるWorkhorseサービスへのアクセスに依存します。

設計上の選択

このチャートで使用されているGitalyコンテナには、まだGitalyに移植されていないGitリポジトリに対するアクションを実行するために、GitLab Shellコードベースも含まれています。Gitalyコンテナには、その中にGitLab Shellコンテナのコピーが含まれており、その結果、このチャート内でGitLab Shellも構成する必要があります。

設定

gitalyチャートは、外部サービスとチャート設定の2つの部分で構成されています。

Gitalyは、GitLabチャートをデプロイする際に、デフォルトでコンポーネントとしてデプロイされます。Gitalyを個別にデプロイする場合は、global.gitaly.enabledをfalseに設定する必要があり、追加の設定は、外部Gitalyドキュメントに記載されているように実行する必要があります。

インストールコマンドラインオプション

以下の表に、helm installコマンドに--setフラグを使用して指定できる、可能なすべてのチャートの設定を示します。

チャート設定の例

extraEnv

extraEnvを使用すると、ポッド内のすべてのコンテナで追加の環境変数を公開できます。

extraEnvの使用例を以下に示します:

extraEnv:
  SOME_KEY: some_value
  SOME_OTHER_KEY: some_other_value

コンテナの起動時に、環境変数が公開されていることを確認できます:

env | grep SOME
SOME_KEY=some_value
SOME_OTHER_KEY=some_other_value

extraEnvFrom

extraEnvFromを使用すると、ポッド内のすべてのコンテナで、他のデータソースからの追加の環境変数を公開できます。

extraEnvFromの使用例を以下に示します:

extraEnvFrom:
  MY_NODE_NAME:
    fieldRef:
      fieldPath: spec.nodeName
  MY_CPU_REQUEST:
    resourceFieldRef:
      containerName: test-container
      resource: requests.cpu
  SECRET_THING:
    secretKeyRef:
      name: special-secret
      key: special_token
      # optional: boolean
  CONFIG_STRING:
    configMapKeyRef:
      name: useful-config
      key: some-string
      # optional: boolean

image.pullSecrets

pullSecretsを使用すると、プライベートレジストリに認証して、ポッドのイメージをプルできます。

プライベートレジストリとその認証方法に関する追加の詳細は、Kubernetesドキュメントにあります。

pullSecretsの使用例を以下に示します

image:
  repository: my.gitaly.repository
  tag: latest
  pullPolicy: Always
  pullSecrets:
  - name: my-secret-name
  - name: my-secondary-secret-name

serviceAccount

このセクションでは、ServiceAccountを作成するかどうか、またデフォルトのアクセストークンをポッドにマウントするかどうかを制御します。

tolerations

tolerationsを使用すると、taintされたワーカーノードでポッドをスケジュールできます

tolerationsの使用例を以下に示します:

tolerations:
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoExecute"

アフィニティ

詳細については、affinityを参照してください。

注釈

annotationsを使用すると、注釈をGitalyポッドに追加できます。

annotationsの使用例を以下に示します:

annotations:
  kubernetes.io/example-annotation: annotation-value

priorityClassName

priorityClassNameを使用すると、PriorityClassをGitalyポッドに割り当てることができます。

priorityClassNameの使用例を以下に示します:

priorityClassName: persistence-enabled

git.config

git.configを使用すると、Gitalyによって起動されたすべてのGitコマンドに設定を追加できます。以下に示すように、git-config(1)のドキュメントに記載されている設定をkey / valueのペアで受け入れます。

git:
  config:
    - key: "pack.threads"
      value: 4
    - key: "fsck.missingSpaceBeforeDate"
      value: ignore

cgroups

リソースの枯渇を防ぐため、Gitalyはcgroupsを使用して、操作対象のリポジトリに基づいてGitプロセスをcgroupに割り当てます。各cgroupにはメモリとCPUの制限があり、システムの安定性を確保し、リソースの飽和を防ぎます。

Gitalyの起動前に実行されるinitContainerは、rootとして実行される必要があります。このコンテナは、Gitalyがcgroupを管理できるように、権限を設定します。したがって、/sys/fs/cgroupへの書き込みアクセス権を持つように、ファイルシステムにボリュームをマウントします。

オーバーサブスクリプションの例

cgroups:
  enabled: true
  # Total limit across all repository cgroups
  memoryBytes: 64424509440 # 60GiB
  cpuShares: 1024
  cpuQuotaUs: 1200000 # 12 cores
  # Per repository limits, 1000 repository cgroups
  repositories:
    count: 1000
    memoryBytes: 32212254720 # 30GiB
    cpuShares: 512
    cpuQuotaUs: 400000 # 4 cores

外部サービス

このチャートは、Workhorseサービスに接続する必要があります。

Workhorse

workhorse:
  host: workhorse.example.com
  serviceName: webservice
  port: 8181

チャートの設定

次の値は、Gitalyポッドを設定するために使用されます。

Gitリポジトリの永続性

このチャートは、PersistentVolumeClaimをプロビジョニングし、Gitリポジトリデータに対応する永続ボリュームをマウントします。これが機能するには、Kubernetesクラスタリングで使用可能な物理ストレージが必要です。emptyDirを使用する場合は、persistence.enabled: falseでPersistentVolumeClaimを無効にします。

persistence:
  enabled: true
  storageClass: standard
  accessMode: ReadWriteOnce
  size: 50Gi
  matchLabels: {}
  matchExpressions: []
  subPath: "data"
  annotations: {}

TLS経由でのGitalyの実行

Gitalyは、TLS経由で他のコンポーネントとの通信をサポートしています。これは、global.gitaly.tls.enabledおよびglobal.gitaly.tls.secretNameの設定によって制御されます。TLS経由でGitalyを実行する手順に従ってください:

1. Helm Chartは、TLS経由でGitalyと通信するために証明書が提供されることを想定しています。この証明書は、存在するすべてのGitalyノードに適用される必要があります。したがって、これらの各Gitalyノードのすべてのホスト名を、件名代替名（SAN）として証明書に追加する必要があります。

   使用するホスト名を知るには、Toolboxポッドの/srv/gitlab/config/gitlab.ymlファイルを確認し、その中のrepositories.storagesキーの下に指定されているさまざまなgitaly_addressフィールドを確認します。

   kubectl exec -it <Toolbox pod> -- grep gitaly_address /srv/gitlab/config/gitlab.yml

1. 作成された証明書を使用して、k8s TLSシークレットを作成します。

   kubectl create secret tls gitaly-server-tls --cert=gitaly.crt --key=gitaly.key

2. --set global.gitaly.tls.enabled=trueを渡して、Helm Chartを再デプロイします。

グローバルサーバーフック

Gitaly StatefulSetは、グローバルサーバーフックをサポートしています。フックスクリプトはGitalyポッドで実行されるため、Gitalyコンテナで使用可能なツールに限定されます。

フックはConfigMapを使用して入力された状態になり、必要に応じて次の値を設定することで使用できます:

1. global.gitaly.hooks.preReceive.configmap
2. global.gitaly.hooks.postReceive.configmap
3. global.gitaly.hooks.update.configmap

ConfigMapに入力するには、スクリプトのディレクトリにkubectlマップを割り当てることができます:

kubectl create configmap MAP_NAME --from-file /PATH/TO/SCRIPT/DIR

GitLabによって作成されたコミットへのGPG署名

Gitalyには、GitLab UI（WebIDEなど）を介して作成されたすべてのGPG署名コミットだけでなく、マージコミットやスカッシュなど、GitLabによって作成されたコミットに署名する機能があります。

1. GPGプライベートキーを使用して、k8sシークレットを作成します。

   kubectl create secret generic gitaly-gpg-signing-key --from-file=signing_key=/path/to/gpg_signing_key.gpg

2. values.yaml設定でGPG署名を有効にします。

   gitlab:
     gitaly:
       gpgSigning:
         enabled: true
         secret: gitaly-gpg-signing-key
         key: signing_key

サーバー側のバックアップ

このチャートは、Gitalyサーバー側のバックアップをサポートしています。それらを使用するには:

1. バックアップを保存するためのバケットを作成します。

2. オブジェクトストレージの認証情報とストレージURLを設定します。

   gitlab:
     gitaly:
       extraEnvFrom:
          # Mount the exisitign object store secret to the expected environment variables.
          AWS_ACCESS_KEY_ID:
            secretKeyRef:
              name: <Rails object store secret>
              key: aws_access_key_id
          AWS_SECRET_ACCESS_KEY:
            secretKeyRef:
              name: <Rails object store secret>
              key: aws_secret_access_key
       backup:
         # This is the connection string for Gitaly server side backups.
         goCloudUrl: <object store connection URL>

   オブジェクトストレージバックエンドに必要な環境変数とストレージURL形式については、Gitalyドキュメントを参照してください。

3. backup-utilityでサーバー側のバックアップを有効にする。