GitLabチャートのストレージを設定する

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed

以下のアプリケーションは、ステートを維持するために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などの一部のプロバイダーは、デフォルトのストレージクラスを提供していません。

クラスタリングストレージの設定

推奨事項

デフォルトのストレージクラスは、次のとおりである必要があります:

可能な場合は、高速ソリッドステートドライブストレージを使用する
reclaimPolicyをRetainに設定する

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

最小ストレージクラス構成

以下のYAML構成は、GitLab用のカスタムストレージクラスを作成するために必要な最小限の構成を提供します。CUSTOM_STORAGE_CLASS_NAMEを、ターゲットインストール環境に適した値に置き換えます。

一部のユーザーは、Amazon EKSが、ポッドと同じゾーンにノードの作成が常に存在するとは限らないという動作を示すとレポートしています。上記の*zone（ゾーン）*パラメータを設定すると、リスクが軽減されます。

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

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

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

詳細と追加の永続オプションについては、以下のリンクを参照してください:

メモ: 高度な永続オプションの一部はPostgreSQLと他のオプションで異なるため、変更を行う前に、それぞれの特定のドキュメントを確認することが重要です。

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

動的ボリュームプロビジョニングが推奨されますが、一部のクラスタリングまたは環境ではサポートされていない場合があります。管理者は、Persistent Volumeを手動で作成する必要があります。

Google GKEの使用

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

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

YAML構成例を変更した後、Persistent Volumeを作成します。

kubectl create -f *PV_YAML_FILE*

Amazon EKSの使用

複数のゾーンにデプロイする必要がある場合は、ストレージソリューションを定義するときに、ストレージクラスに関するAmazon独自のドキュメントを確認する必要があります。

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

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

YAML構成例を変更した後、Persistent Volumeを作成します。

kubectl create -f *PV_YAML_FILE*

PersistentVolumeClaimの手動作成

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です。

メモ: 複数の仮想ストレージでPraefectを使用している場合は、定義された仮想ストレージごとにGitalyレプリカごとに1つのPersistentVolumeClaimが必要になります。たとえば、defaultおよびvs2仮想ストレージが定義されていて、それぞれに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

環境に合わせて設定ファイル例を変更し、helmを実行するときに参照します。

StatefulSetを使用しない他のサービスでは、管理者が設定にvolumeNameを提供できます。このチャートは、ボリュームクレームの作成を処理し、手動で作成されたボリュームへのバインドを試みます。含まれている各アプリケーションのチャートドキュメントを確認してください。
ほとんどの場合、手動で作成したディスクボリュームを使用するサービスのみを保持して、設定ファイル例を変更するだけです。

インストール後にストレージを変更する

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

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

オプションのボリューム

大規模なインストールの場合は、バックアップと復元するを機能させるために、Toolboxに永続ストレージを追加する必要がある場合があります。これを行う方法については、トラブルシューティングドキュメントを参照してください。