• 典型的なインストールの動作
• クラスター・ストレージの設定
  • 推奨
  • 最小ストレージ・クラス設定
  • カスタム・ストレージ・クラスの使用
• 静的ボリューム・プロビジョニングの使用
  • Google GKEの使用
  • Amazon EKSの使用
  • PersistentVolumeClaims の手動作成
• インストール後のストレージの変更
• オプションのボリューム

GitLabチャートのストレージ設定

GitLabチャート内の以下のアプリケーションは、状態をメンテナーするために永続ストレージを必要とします。

• Gitaly(Gitリポジトリを永続化)
• PostgreSQL(GitLabデータベースのデータを永続化)
• Redis(GitLabのジョブデータを永続化)
• MinIO(オブジェクトストレージデータの永続化)

管理者は、ダイナミックまたはスタティックボリュームプロビジョニングを使用して、このストレージをプロビジョニングすることを選択できます。

インポート:事前計画により、インストール後の余分なストレージマイグレーションタスクを最小限に抑えます。最初のデプロイ後の変更では、helm upgrade を実行する前に、既存のKubernetesオブジェクトを手動で編集する必要があります。

典型的なインストールの動作

インストーラは、デフォルトのストレージクラスとダイナミックボリュームプロビジョニングを使用してストレージを作成します。アプリケーションは、Persistent Volume Claim を使用してこのストレージに接続します。管理者は、動的ボリューム・プロビジョニングが使用可能な場合は、静的ボリューム・プロビジョニングの代わりに動的ボリューム・プロビジョニングを使用することをお勧めします。

管理者は、kubectl get storageclass を使用して本番環境のデフォルト・ストレージ・クラスを決定し、kubectl describe storageclass *STORAGE_CLASS_NAME* を使用してそれを調べる必要があります。Amazon EKSなど、一部のプロバイダはデフォルトのストレージクラスを提供していません。

クラスター・ストレージの設定

推奨

デフォルトのストレージクラスは

• 利用可能な場合は、高速SSDストレージを使用します。
• reclaimPolicy 。Retain

reclaimPolicy をRetain に設定せずに GitLab をアンインストールすると、自動ジョブはボリューム、ディスク、データを完全に削除することができます。一部のプラットフォームでは、デフォルトのreclaimPolicy をDeleteに設定しています。gitaly 永続ボリュームのクレームは、StatefulSetに属しているため、このルールには従いません。

最小ストレージ・クラス設定

以下のYAML 設定は、GitLab 用のカスタムストレージクラスを作成するために必要な最低限のものです。CUSTOM_STORAGE_CLASS_NAME は、対象のインストール環境に適した値に置き換えてください。

• Google Cloud上のGKE用ストレージクラスの例
• Amazon Web Services上のEKS用ストレージクラスの例

一部のユーザーは、Amazon EKS がノードの作成がポッドと同じゾーンにあるとは限らない動作を示すと報告しています。ノードの作成時に ゾーンパラメータを設定することでリスクを軽減できます。

カスタム・ストレージ・クラスの使用

カスタム・ストレージ・クラスをクラスターのデフォルトに設定すると、すべての動的プロビジョニングに使用されます。

kubectl patch storageclass CUSTOM_STORAGE_CLASS_NAME -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

あるいは、インストール時にカスタムストレージクラスとその他のオプションをサービスごとにHelmに提供することもできます。提供されている設定ファイルの例を見て、環境に合わせて変更してください。

helm install -upgrade gitlab gitlab/gitlab -f HELM_OPTIONS_YAML_FILE

さらに詳しい情報やその他の永続化オプションについては、以下のリンクを参照してください：

• Gitaly永続化設定
• MinIO永続性の設定
• Redis永続化設定
• アップストリームPostgreSQLチャートの設定

注意: 高度な永続化オプションのいくつかは、PostgreSQLとそれ以外で異なります。

静的ボリューム・プロビジョニングの使用

動的ボリューム・プロビジョニングを推奨しますが、クラスターや環境によってはサポートされていない場合があります。管理者は手動で永続ボリュームを作成する必要があります。

Google GKEの使用

1. クラスターに永続ディスクを作成します。

gcloud compute disks create --size=50GB --zone=*GKE_ZONE* *DISK_VOLUME_NAME*

1. の例YAML の設定を変更した後、永続ボリュームを作成します。

kubectl create -f *PV_YAML_FILE*

Amazon EKSの使用

1. クラスターに永続ディスクを作成します。

aws ec2 create-volume --availability-zone=*AWS_ZONE* --size=10 --volume-type=gp2

1. 例YAML 設定を修正した後、永続ボリュームを作成します。

kubectl create -f *PV_YAML_FILE*

PersistentVolumeClaims の手動作成

GitalyサービスはStatefulSetを使ってデプロイします。以下の命名規則を使用してPersistentVolumeClaimを作成すると、正しく認識され、使用されます。

<mount-name>-<statefulset-pod-name>

Gitaly のmount-name はrepo-data です。StatefulSetのポッド名は、以下を使用して作成します：

<statefulset-name>-<pod-index>

GitLabチャートはstatefulset-name ：

<chart-release-name>-<service-name>

Gitaly PersistentVolumeClaim の正しい名前はrepo-data-gitlab-gitaly-0 です。

注：複数の Virtual Storage で Praefect を使用する場合、定義された Virtual Storage ごとに、Gitaly レプリカごとに 1 つの PersistentVolumeClaim が必要です。たとえば、default およびvs2 の Virtual Storage が定義され、それぞれに 2 つのレプリカがある場合、次の PersistentVolumeClaim が必要です：

• repo-data-gitlab-gitaly-default-0
• repo-data-gitlab-gitaly-default-1
• repo-data-gitlab-gitaly-vs2-0
• repo-data-gitlab-gitaly-vs2-1

YAML 設定例を環境に合わせて変更し、helm を起動する際に参照します。

StatefulSetを使用しない他のサービスでは、管理者が設定にvolumeName 。このChartは、ボリューム請求の作成と手動で作成したボリュームへのバインドを引き続き行います。含まれる各アプリケーションの Chart ドキュメントを確認してください。

ほとんどの場合、手動で作成したディスクボリュームを使用するサービスだけを残して、例のYAML設定を変更するだけです。

インストール後のストレージの変更

初期インストール後、新しいボリュームへのマイグレーションやディスクサイズの変更などストレージの変更を行うには、Helm upgradeコマンド以外でKubernetesオブジェクトを編集する必要があります。

永続ボリュームの管理のドキュメントを参照してください。

オプションのボリューム

大規模なインストールでは、Toolbox に永続ストレージを追加してバックアップ/リストアを実行する必要があります。この方法については、トラブルシューティング ドキュメントを参照してください。