保管ガイド
概要
GitLabチャート内の以下のアプリケーションは、状態をメンテナーするために永続ストレージを必要とします。
- Gitaly(Gitリポジトリの永続化)
- PostgreSQL(GitLabデータベースのデータを永続化)
- Redis(GitLabジョブデータの永続化)
- MinIO(オブジェクト・ストレージ・データの永続化)
管理者は、動的または静的ボリューム・プロビジョニングを使用してこのストレージをプロビジョニングすることを選択できます。
重要:事前計画により、インストール後の余分なストレージ移行タスクを最小限に抑えます。 最初のデプロイ後の変更には、
helm upgrade
を実行する前に、既存の Kubernetes オブジェクトを手動で編集する必要があります。
典型的な設置動作
インストーラは、デフォルトのストレージクラスとダイナミック・ボリューム・プロビジョニングを使用してストレージを作成します。 アプリケーションは、パーシスタント・ボリューム・クレームを通じてこのストレージに接続します。 管理者は、利用可能な場合は、スタティック・ボリューム・プロビジョニングの代わりにダイナミック・ボリューム・プロビジョニングを使用することをお勧めします。
管理者は、
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
を、対象のインストール環境に適した値に置き換えてください。
一部のレポーターによると、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
さらに詳しい情報や、その他の永続オプションについては、以下のリンクを参照してください:
注意: 高度な永続化オプションの中には、PostgreSQLとそれ以外とで異なるものがありますので、変更する前にそれぞれのドキュメントを確認することが重要です。
静的ボリュームプロビジョニングの使用
動的ボリューム・プロビジョニングを推奨しますが、クラスターや環境によってはサポートされていない場合があります。 管理者は、永続ボリュームを手動で作成する必要があります。
Google GKEの使用
gcloud compute disks create --size=50GB --zone=*GKE_ZONE* *DISK_VOLUME_NAME*
-
例
YAML
構成を変更した後、永続ボリュームを作成します。
kubectl create -f *PV_YAML_FILE*
Amazon EKSの使用
aws ec2 create-volume --availability-zone=*AWS_ZONE* --size=10 --volume-type=gp2
-
例
YAML
構成を変更した後、永続ボリュームを作成します。
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
です。
サンプルYAMLコンフィギュレーションをあなたの環境用に修正し、helm
を呼び出すときに参照します。
StatefulSetを使用しないその他のサービスでは、管理者が
volumeName
。このChartは、ボリューム請求の作成を引き続き担当し、手動で作成したボリュームへのバインドを試みます。含まれる各アプリケーションのChartドキュメントを確認してください。ほとんどの場合、手動で作成したディスクボリュームを使用するサービスだけを残して、例のYAML設定を変更するだけです。
インストール後のストレージの変更
最初のインストール後、新しいボリュームへの移行やディスクサイズの変更などのストレージの変更には、Helmのアップグレードコマンド以外でKubernetesオブジェクトを編集する必要があります。
永続ボリュームの管理に関するドキュメントを参照してください。
オプション
大規模なインストールでは、バックアップ/リストアを動作させるためにタスク・ランナー・ポッドに永続ストレージを追加する必要があるかもしれません。 この方法については、トラブルシューティング・ドキュメントを参照してください。