• 前提条件
• バックアップとリストアの手順
• オブジェクトストレージ
  • S3へのバックアップ
  • Googleクラウドストレージへのバックアップ(GCS)
  • Azure blobストレージへのバックアップ
• トラブルシューティング
  • ポッドの立ち退きに関する問題
  • 「バケットが見つかりません」エラー
  • “AccessDeniedException：403 “エラー
  • “ERROR:/home/git/.s3cfg ：でbackup-utility を実行すると “None” エラー。--backend s3
  • “PermissionError：File not writable” S3を使用したエラー

GitLabインスタンスのバックアップとリストア

GitLab Helmチャートでは、Toolboxサブチャートから、GitLabインスタンスのバックアップとリストアを行うためのインターフェイスとして機能するユーティリティポッドを提供しています。このタスクに必要な他のポッドと相互作用するbackup-utility 実行ファイルを備えています。ユーティリティの動作に関する技術的な詳細は、アーキテクチャのドキュメントを参照してください。

前提条件

• ここで説明するバックアップとリストアの手順は、S3互換のAPIでのみテストされています。Google Cloud Storageのような他のオブジェクトストレージサービスのサポートは、将来のリビジョンでテストされる予定です。

• リストアの際には、バックアップtarボールをディスクに展開する必要があります。これは、Toolboxポッドに必要なサイズのディスクが用意されている必要があることを意味します。

• このChartでは、artifacts 、uploads 、packages 、registry 、lfs オブジェクトのオブジェクト ストレージの使用に依存しており、リストア時にこれらのオブジェクトをマイグレーションすることはできません。別のインスタンスから取得したバックアップをリストアする場合は、バックアップを取得する前に、既存のインスタンスをオブジェクト・ストレージを使用するようにマイグレーションする必要があります。イシュー646を参照してください。

バックアップとリストアの手順

• GitLabインストールのバックアップ
• GitLabインストールのリストア

オブジェクトストレージ

外部のオブジェクトストレージが指定されない限り、このChartを使用する際にMinIOインスタンスを提供します。Toolboxは、特定の設定がない限り、デフォルトで付属のMinIOに接続します。Toolbox は、Amazon S3 または Google Cloud Storage(GCS)にバックアップする設定も可能です。

S3へのバックアップ

Toolboxはオブジェクトストレージへの接続にs3cmd 。外部オブジェクトストレージへの接続を設定するには、.s3cfg ファイルを含む Kubernetes シークレットを指すgitlab.toolbox.backups.objectStorage.config.secret を指定する必要があります。デフォルトのconfig と異なる場合は、gitlab.toolbox.backups.objectStorage.config.key を指定する必要があります。これは、.s3cfg ファイルのコンテンツを含むキーを指します。

以下のようになります：

helm install gitlab gitlab/gitlab \
  --set gitlab.toolbox.backups.objectStorage.config.secret=my-s3cfg \
  --set gitlab.toolbox.backups.objectStorage.config.key=config .

s3cmd.s3cfg ファイルのドキュメントはこちらです。

さらに、2つのバケットロケーションを設定する必要があります。1つはバックアップを保存するためのバケット、もう1つはバックアップをリストアするときに使用する一時的なバケットです。

--set global.appConfig.backups.bucket=gitlab-backup-storage
--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage

Googleクラウドストレージへのバックアップ(GCS)

GCS にバックアップするには、gitlab.toolbox.backups.objectStorage.backend をgcs に設定する必要があります。これにより、Toolbox がオブジェクトを保存および取得する際にgsutil CLI を使用するようになります。さらに、gitlab.toolbox.backups.objectStorage.config.gcpProject に、ストレージバケットを含むGCPプロジェクトのプロジェクトIDを設定する必要があります。アクティブなサービスアカウントのJSONキーの内容でKubernetesシークレットを作成する必要があり、サービスアカウントはバックアップに使用するバケットのstorage.admin ロールを持ちます。以下は、gcloud とkubectl を使用してシークレットを作成する例です。

export PROJECT_ID=$(gcloud config get-value project)
gcloud iam service-accounts create gitlab-gcs --display-name "Gitlab Cloud Storage"
gcloud projects add-iam-policy-binding --role roles/storage.admin ${PROJECT_ID} --member=serviceAccount:gitlab-gcs@${PROJECT_ID}.iam.gserviceaccount.com
gcloud iam service-accounts keys create --iam-account gitlab-gcs@${PROJECT_ID}.iam.gserviceaccount.com storage.config
kubectl create secret generic storage-config --from-file=config=storage.config

バックアップのためにGCSへの認証にサービスアカウントのキーを使用するために、以下のようにHelm Chartを設定します：

helm install gitlab gitlab/gitlab \
  --set gitlab.toolbox.backups.objectStorage.config.secret=storage-config \
  --set gitlab.toolbox.backups.objectStorage.config.key=config \
  --set gitlab.toolbox.backups.objectStorage.config.gcpProject=my-gcp-project-id \
  --set gitlab.toolbox.backups.objectStorage.backend=gcs

さらに、2つのバケットロケーションを設定する必要があります。1つはバックアップを保存するためのバケット、もう1つはバックアップをリストアするときに使用する一時的なバケットです。

--set global.appConfig.backups.bucket=gitlab-backup-storage
--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage

Azure blobストレージへのバックアップ

Azure blob ストレージは、gitlab.toolbox.backups.objectStorage.backend をazure に設定することで、バックアップの保存に使用できます。これにより、Toolbox はazcopy の内部コピーを使用して Azure blob ストレージにバックアップ ファイルを送信および取得できるようになります。

Azure blobストレージを使用するには、既存のリソースグループにストレージアカウントを作成する必要があります。ストレージ アカウントの名前、アクセス キー、およびブロブ ホストで構成シークレットを作成します。

パラメータを含む設定ファイルを作成します：

# azure-backup-conf.yaml
azure_storage_account_name: <storage account>
azure_storage_access_key: <access key value>
azure_storage_domain: blob.core.windows.net # optional

Kubernetes Secretを作成するには、次のkubectl コマンドを使用します：

kubectl create secret generic backup-azure-creds \
  --from-file=config=azure-backup-conf.yaml

シークレットが作成されたら、デプロイした値にバックアップ設定を追加するか、Helmコマンドラインで設定を与えることで、GitLab Helmチャートを設定することができます。例えば

helm install gitlab gitlab/gitlab \
  --set gitlab.toolbox.backups.objectStorage.config.secret=backup-azure-creds \
  --set gitlab.toolbox.backups.objectStorage.config.key=config \
  --set gitlab.toolbox.backups.objectStorage.backend=azure

シークレットのアクセスキーは、ストレージアカウントにアクセスするための短命の共有アクセスシグネチャ(SAS) トークンの生成とリフレッシュに使われます。

さらに、バックアップを保存するためのバケットと、バックアップをリストアするときに使用する一時的なバケットの2つのバケット/コンテナを事前に作成する必要があります。バケット名を値や設定に追加します。例えば

--set global.appConfig.backups.bucket=gitlab-backup-storage
--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage

トラブルシューティング

ポッドの立ち退きに関する問題

バックアップはオブジェクトストレージターゲットの外側でローカルに組み立てられるため、一時的なディスク領域が必要になります。必要な容量は実際のバックアップ アーカイブのサイズを超える場合があります。デフォルト設定では、Toolboxポッドのファイルシステムを使用して一時データを保存します。リソースが少ないためにポッドが退避している場合は、ポッドに永続ボリュームをアタッチして一時データを保存する必要があります。GKEでは、Helmコマンドに次の設定を追加します：

--set gitlab.toolbox.persistence.enabled=true

バックアップが付属のバックアップcronジョブの一部として実行されている場合は、cronジョブの永続化も有効にします：

--set gitlab.toolbox.backups.cron.persistence.enabled=true

他のプロバイダの場合は、永続ボリュームを作成する必要があるかもしれません。他のプロバイダの場合、永続ボリュームを作成する必要があるかもしれません。

「バケットが見つかりません」エラー

バックアップ中にBucket not found エラーが発生した場合は、バケットに認証情報が設定されているか確認してください。

コマンドはクラウドサービスプロバイダに依存します：

• AWS S3の場合、認証情報は~/.s3cfg のtoolboxポッドに保存されます。実行します：

   s3cmd ls
  

• GCP GCSの場合は、実行します：

   gsutil ls
  

利用可能なバケットの一覧が表示されるはずです。

“AccessDeniedException：403 “エラー

[Error] AccessDeniedException: 403 <GCP Account> does not have storage.objects.list access to the Google Cloud Storage bucket. のようなエラーは通常、GitLabインスタンスのバックアップやリストア中に発生します。権限が不足しているためです。

バックアップやリストアのオペレーションは環境内のすべてのバケットを使用するので、環境内のすべてのバケットが作成され、GCPアカウントがすべてのバケットにアクセス（リスト、読み込み、書き込み）できることを確認してください：

1. ツールボックスのポッドを探します：

   kubectl get pods -lrelease=RELEASE_NAME,app=toolbox
   

2. ポッドの環境にあるすべてのバケットを取得します。<toolbox-pod-name> を実際の toolbox ポッド名に置き換えますが、"BUCKET_NAME" はそのままにしておきます：

   kubectl describe pod <toolbox-pod-name> | grep "BUCKET_NAME"
   

3. 環境内のすべてのバケットにアクセスできることを確認します：

   # List
   gsutil ls gs://<bucket-to-validate>/
      
   # Read
   gsutil cp gs://<bucket-to-validate>/<object-to-get> <save-to-location>
      
   # Write
   gsutil cp -n <local-file> gs://<bucket-to-validate>/
   

“ERROR:/home/git/.s3cfg ：でbackup-utility を実行すると “None” エラー。--backend s3

このエラーは、.s3cfg ファイルを含む Kubernetes シークレットが、gitlab.toolbox.backups.objectStorage.config.secret 値を通して指定されていない場合に発生します。

これを修正するには、S3へのバックアップの指示に従ってください。

“PermissionError：File not writable” S3を使用したエラー

[Error] WARNING: <file> not writable: Operation not permitted のようなエラーは、toolbox ユーザーがバケツアイテムの保存されたパーミッションと一致するファイルの書き込み権限を持っていない場合に発生します。

これを防ぐには、gitlab.toolbox.backups.objectStorage.config.secretを経由して参照される.s3cfg ファイルに以下のフラグを追加して、s3cmd でファイルのオーナー、モード、タイムスタンプを保持しないように設定してください。

preserve_attrs = False