保管ガイド

概要

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の使用

  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*

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オブジェクトを編集する必要があります。

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

オプション

大規模なインストールでは、バックアップ/リストアを動作させるためにタスク・ランナー・ポッドに永続ストレージを追加する必要があるかもしれません。 この方法については、トラブルシューティング・ドキュメントを参照してください。