GitLabインスタンスの復元

LinuxパッケージやGitLab Helmチャートなどの他のインストール方法を使用した既存のGitLabインスタンスのバックアップtarballを取得するには、ドキュメントに記載されている手順に従ってください。

別のインスタンスから取得したバックアップを復元する場合は、バックアップを作成する前に、既存のインスタンスをオブジェクトストレージを使用するように移行する必要があります。issue 646を参照してください。

復元は、作成元のGitLabのバージョンと同じバージョンに復元することをお勧めします。

GitLabのバックアップ復元は、チャートで提供されるToolboxポッドでbackup-utilityコマンドを実行することで行われます。

初めて復元を実行する前に、Toolboxが適切に設定されていることを、オブジェクトストレージにアクセスするために確認する必要があります。

GitLab Helmチャートによって提供されるバックアップユーティリティは、次のいずれかの場所からtarballを復元することをサポートしています。

1. インスタンスに関連付けられたオブジェクトストレージサービスのgitlab-backupsバケット。これはデフォルトのシナリオです。
2. ポッドからアクセスできるパブリックURL。
3. kubectl cpを使用してToolboxポッドにコピーできるローカルファイル

シークレットの復元

Railsシークレットの復元

GitLabチャートは、RailsシークレットがYAMLのコンテンツを含むKubernetesシークレットとして提供されることを想定しています。LinuxパッケージインスタンスからRailsシークレットを復元している場合、シークレットは/etc/gitlab/gitlab-secrets.jsonファイルにJSON形式で保存されます。ファイルを変換し、シークレットをYAML形式で作成するには、次の手順に従います:

1. /etc/gitlab/gitlab-secrets.jsonファイルを、kubectlコマンドを実行するワークステーションにコピーします。

2. ワークステーションにyqツール（バージョン4.21.1以降）をインストールします。

3. 次のコマンドを実行して、gitlab-secrets.jsonをYAML形式に変換します:

   yq -P '{"production": .gitlab_rails}' gitlab-secrets.json -o yaml >> gitlab-secrets.yaml

4. 新しいgitlab-secrets.yamlファイルに次のコンテンツが含まれていることを確認します:

   production:
     db_key_base: <your key base value>
     secret_key_base: <your secret key base value>
     otp_key_base: <your otp key base value>
     openid_connect_signing_key: <your openid signing key>
     active_record_encryption_primary_key:
     - 'your active record encryption primary key'
     active_record_encryption_deterministic_key:
     - 'your active record encryption deterministic key'
     active_record_encryption_key_derivation_salt: 'your active record key derivation salt'

5. openid_connect_signing_keyのような複数行のシークレットに改行文字（\n）が含まれていないことを確認してください。アプリケーションで使用される際にデコードの問題を回避するために、複数行のシークレットを複数の行に分割します。

YAMLファイルからRailsシークレットを復元するには、次の手順に従います:

1. Railsシークレットのオブジェクト名を見つけます:

   kubectl get secrets | grep rails-secret

2. 既存のシークレットを削除します:

   kubectl delete secret <rails-secret-name>

3. 古いシークレットと同じ名前を使用して新しいシークレットを作成し、ローカルYAMLファイルを渡します。

   kubectl create secret generic <rails-secret-name> --from-file=secrets.yml=gitlab-secrets.yaml

ポッドをリセットする

新しいシークレットを使用するには、Webservice、Sidekiq、およびToolboxポッドをリセットする必要があります。これらのポッドをリセットする最も安全な方法は、次を実行することです:

kubectl delete pods -lapp=sidekiq,release=<helm release name>
kubectl delete pods -lapp=webservice,release=<helm release name>
kubectl delete pods -lapp=toolbox,release=<helm release name>

バックアップファイルの復元

GitLabインスタンスを復元する手順は次のとおりです

1. チャートをデプロイして、実行中のGitLabインスタンスがあることを確認します。次のコマンドを実行して、Toolboxポッドが有効になっていることを確認します。

   kubectl get pods -lrelease=RELEASE_NAME,app=toolbox

2. 上記のいずれかの場所でtarballを準備します。<backup_ID>_gitlab_backup.tar形式で名前が付けられていることを確認してください。バックアップIDの詳細をお読みください。

3. 後続のリセットのために、データベースクライアントの現在のレプリカ数に注意してください:

   kubectl get deploy -n <namespace> -lapp=sidekiq,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
   kubectl get deploy -n <namespace> -lapp=webservice,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
   kubectl get deploy -n <namespace> -lapp=prometheus,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'

4. 復元プロセスを妨げるロックを防ぐために、データベースのクライアントを停止します:

   kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=0
   kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=0
   kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=0

5. バックアップユーティリティを実行してtarballを復元します

   kubectl exec <Toolbox pod name> -it -- backup-utility --restore -t <backup_ID>

   ここで、<backup_ID>は、gitlab-backupsバケットに格納されているtarballの名前から取得されます。パブリックURLを提供する場合は、次のコマンドを使用します:

   kubectl exec <Toolbox pod name> -it -- backup-utility --restore -f <URL>

   形式がfile:///<path>である限り、ローカルパスをURLとして指定できます。

6. このプロセスは、tarballのサイズに応じて時間がかかります。

7. 復元プロセスは、データベースの既存のコンテンツを消去し、既存のリポジトリを一時的な場所に移動し、tarballのコンテンツを抽出します。リポジトリは、ディスク上の対応する場所に移動され、アーティファクト、アップロード、LFSなどのその他のデータは、オブジェクトストレージ内の対応するバケットにアップロードされます。

8. アプリケーションをリセットします:

   kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=<value>
   kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=<value>
   kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=<value>

Runnerの登録トークンを復元する

復元後、含まれているRunnerは、正しい登録トークンを持たなくなったため、インスタンスに登録できなくなります。リセットされたトラブルシューティングの手順に従って、更新してください。

Kubernetes関連の設定を有効にする

復元されたバックアップがチャートの既存のインストールからのものではない場合は、復元後にいくつかのKubernetes固有の機能を有効にする必要もあります。増分CIジョブログなど。

1. 次のコマンドを実行して、Toolboxポッドを見つけます

   kubectl get pods -lrelease=RELEASE_NAME,app=toolbox

2. インスタンスのセットアップスクリプトを実行して、必要な機能を有効にします

   kubectl exec <Toolbox pod name> -it -- gitlab-rails runner -e production /scripts/custom-instance-setup

ポッドをリセットする

新しい変更を使用するには、WebserviceとSidekiqポッドをリセットする必要があります。これらのポッドをリセットする最も安全な方法は、次を実行することです:

kubectl delete pods -lapp=sidekiq,release=<helm release name>
kubectl delete pods -lapp=webservice,release=<helm release name>

（オプション）ルートユーザーのパスワードをリセットする

復元プロセスでは、バックアップの値でgitlab-initial-root-passwordシークレットが更新されません。rootとしてログインするには、バックアップに含まれている元のパスワードを使用します。パスワードにアクセスできなくなった場合は、次の手順に従ってリセットしてください。

1. コマンドを実行して、Webserviceポッドにアタッチします

   kubectl exec <Webservice pod name> -it -- bash

2. 次のコマンドを実行して、rootユーザーのパスワードをリセットします。#{password}をご希望のパスワードに置き換えてください

   /srv/gitlab/bin/rails runner "user = User.first; user.password='#{password}'; user.password_confirmation='#{password}'; user.save!"

追加情報

• GitLabチャートバックアップ/復元の概要
• GitLabインスタンスのバックアップ