チャートを使用したPraefect

Praefectチャートは、HelmチャートでデプロイされたGitLabインスタンス内のGitaly Cluster (Praefect)を管理するために使用されます。

既知の問題

1. データベースは手動で作成する必要があります。
2. クラスターサイズは固定されています: Gitaly Cluster (Praefect)はオートスケールをサポートしていません。
3. クラスター内のPraefectインスタンスを使用してクラスター外のGitalyインスタンスを管理することはサポートされていません。

要件

このチャートは、Gitalyチャートを使用します。global.gitalyの設定は、このチャートによって作成されたインスタンスを設定するために使用されます。これらの設定のドキュメントは、Gitalyチャートドキュメントにあります。

重要: global.gitaly.tlsはglobal.praefect.tlsから独立しています。これらは個別に設定されます。

デフォルトでは、このチャートは3つのGitalyレプリカを作成します。

設定

このチャートはデフォルトで無効になっています。チャートデプロイの一部として有効にするには、global.praefect.enabled=trueを設定します。

レプリカ:

デプロイするレプリカのデフォルトの数は3です。これは、目的のレプリカ数でglobal.praefect.virtualStorages[].gitalyReplicasを設定することで変更できます。例:

global:
  praefect:
    enabled: true
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1

複数の仮想ストレージ

複数の仮想ストレージを設定できます（Gitaly Cluster (Praefect)ドキュメントを参照）。例:

global:
  praefect:
    enabled: true
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1
    - name: vs2
      gitalyReplicas: 5
      maxUnavailable: 2

これにより、Gitalyのリソースが2セット作成されます。これには、2つのGitaly StatefulSet（仮想ストレージごとに1つ）が含まれます。

管理者は、新しいリポジトリの保存場所を設定できます。

永続性

仮想ストレージごとに永続性設定を提供できます。

global:
  praefect:
    enabled: true
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1
      persistence:
        enabled: true
        size: 50Gi
        accessMode: ReadWriteOnce
        storageClass: storageclass1
    - name: vs2
      gitalyReplicas: 5
      maxUnavailable: 2
      persistence:
        enabled: true
        size: 100Gi
        accessMode: ReadWriteOnce
        storageClass: storageclass2

defaultReplicationFactor

defaultReplicationFactorは、各仮想ストレージで設定できます（レプリケーション係数を設定するドキュメントを参照）。

global:
  praefect:
    enabled: true
    virtualStorages:
    - name: default
      gitalyReplicas: 5
      maxUnavailable: 2
      defaultReplicationFactor: 3
    - name: secondary
      gitalyReplicas: 4
      maxUnavailable: 1
      defaultReplicationFactor: 2

Praefectへの移行

スタンドアロンのGitalyインスタンスからPraefectセットアップに移行する場合、global.praefect.replaceInternalGitalyをfalseに設定できます。これにより、新しいPraefectで管理されるGitalyインスタンスが作成されている間、既存のGitalyインスタンスが確実に保持されます。

global:
  praefect:
    enabled: true
    replaceInternalGitaly: false
    virtualStorages:
    - name: virtualStorage2
      gitalyReplicas: 5
      maxUnavailable: 2

Gitaly Cluster (Praefect)への移行の手順に従って、defaultストレージからvirtualStorage2にデータを移動できます。global.gitaly.internal.namesで追加のストレージが定義されている場合は、それらのストレージからリポジトリを移行してください。

リポジトリがvirtualStorage2に移行された後、Praefect設定でdefaultという名前のストレージが追加されている場合は、replaceInternalGitalyをtrueに戻すことができます。

global:
  praefect:
    enabled: true
    replaceInternalGitaly: true
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1
    - name: virtualStorage2
      gitalyReplicas: 5
      maxUnavailable: 2

Gitaly Cluster (Praefect)への移行の手順に再度従うと、必要に応じてvirtualStorage2から新しく追加されたdefaultストレージにデータを移動できます。

最後に、新しいリポジトリの保存場所を設定するには、リポジトリストレージパスのドキュメントを参照してください。

データベースの作成

Praefectは、独自のデータベースを使用して状態を追跡します。Praefectが機能するためには、これを手動で作成する必要があります。

1. データベースインスタンスにログインします:

   kubectl exec -it $(kubectl get pods -l app.kubernetes.io/name=postgresql -o custom-columns=NAME:.metadata.name --no-headers) -- bash

   PGPASSWORD=$(echo $POSTGRES_POSTGRES_PASSWORD) psql -U postgres -d template1

2. データベースユーザーを作成します:

   CREATE ROLE praefect WITH LOGIN;

3. データベースユーザーのパスワードを設定します。

   デフォルトでは、shared-secretsジョブはシークレットを生成します。

   1. パスワードをフェッチします:

      kubectl get secret RELEASE_NAME-praefect-dbsecret -o jsonpath="{.data.secret}" | base64 --decode

   2. psqlプロンプトでパスワードを設定します:

      \password praefect

4. データベースを作成します:

   CREATE DATABASE praefect WITH OWNER praefect;

TLS経由でのPraefectの実行

Praefectは、TLS経由でクライアントおよびGitalyノードとの通信をサポートします。これは、global.praefect.tls.enabledとglobal.praefect.tls.secretNameの設定によって制御されます。TLS経由でPraefectを実行するには、次の手順に従います:

1. Helmチャートは、TLS経由でPraefectと通信するために証明書が提供されることを想定しています。この証明書は、存在するすべてのPraefectノードに適用される必要があります。したがって、これらのノードの各ホスト名はすべて、証明書のサブジェクト代替名（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. 作成した証明書を使用してTLSシークレットを作成します。

   kubectl create secret tls <secret name> --cert=praefect.crt --key=praefect.key

2. --set global.praefect.tls.enabled=trueを渡してHelmチャートを再度デプロイします。

TLS経由でGitalyを実行する場合は、仮想ストレージごとにシークレット名を指定する必要があります。

global:
  gitaly:
    tls:
      enabled: true
  praefect:
    enabled: true
    tls:
      enabled: true
      secretName: praefect-tls
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1
      tlsSecretName: default-tls
    - name: vs2
      gitalyReplicas: 5
      maxUnavailable: 2
      tlsSecretName: vs2-tls

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

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

serviceAccount

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

affinity

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