GitLab インストールの復元

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

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

バックアップを作成したのと同じバージョンのGitLabにリストアすることをお勧めします。

GitLab バックアップリストアは、Chart で指定されたtask-runner ポッドでbackup-utility コマンドを実行することで行われます。

リストアを初めて実行する前に、タスクランナーが オブジェクトストレージにアクセスできるように適切に設定されていることを確認してください。

GitLab Helm chartが提供するバックアップユーティリティは、以下のいずれかの場所からtarballをリストアすることをサポートしています。

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

秘密の復元

Railsの秘密の復元

GitLab Chartでは、RailsのsecretはKubernetes Secretとして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>
  ci_jwt_signing_key: <your ci jwt signing key>

この値は、バックアップインスタンスのrails secretsから一致する値に置き換える必要があります。オムニバスインストールの場合は、/etc/gitlab/gitlab-secrets.json 。その他のインストールの場合は、secrets.yml

シークレットをローカルのYAMLファイルとして作成したら

  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=<local-yaml-filepath>
    

ポッドの再起動

新しいシークレットを使用するには、webservicesidekiqtask-runner ポッドを再起動する必要があります。これらのポッドを再起動する最も安全な方法は、実行することです:

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

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

GitLabインストールを復元する手順は以下の通りです。

  1. Chartをデプロイすることで、GitLabインスタンスが起動していることを確認します。 以下のコマンドを実行することで、task-runner ポッドが有効になっており、起動していることを確認します。

    kubectl get pods -lrelease=RELEASE_NAME,app=task-runner
    
  2. 上記のいずれかの場所にtarballを用意してください。<timestamp>_<version>_gitlab_backup.tar 形式で名前が付けられていることを確認してください。
  3. バックアップ・ユーティリティを実行し、tarballを復元してください。

    kubectl exec <task-runner pod name> -it -- backup-utility --restore -t <timestamp>_<version>
    

    ここで、<timestamp>_<version> は、gitlab-backups バケットに保存されている tarball の名前からです。公開 URL を指定したい場合は、以下のコマンドを使用します。

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

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

  4. この処理には、tarボールのサイズに応じて時間がかかります。
  5. リストアプロセスでは、データベースの既存のコンテンツが消去され、既存のリポジトリが一時的な場所に移動され、tarボールのコンテンツが抽出されます。 リポジトリはディスク上の対応する場所に移動され、アーティファクト、アップロード、LFSなどのその他のデータは、Object Storageの対応するバケットにアップロードされます。

リストアの際には、バックアップtarballをディスクに展開する必要があります。 つまり、task-runner ポッドに必要なサイズのディスクが用意されている必要があります。

ランナー登録トークンの復元

復元後、正しい登録トークンがないため、含まれるランナーはインスタンスに登録できません。 以下のトラブルシューティング手順に従って、更新してください。

リストアしたバックアップが既存のChartのインストールからではない場合、リストア後にKubernetes固有の機能を有効にする必要もあります。CIジョブのインクリメンタルログなどです。

  1. 次のコマンドを実行して、task-runner ポッドを探します。

    kubectl get pods -lrelease=RELEASE_NAME,app=task-runner
    
  2. インスタンス・セットアップ・スクリプトを実行して、必要な機能を有効にします。

kubectl exec <task-runner pod name> -it -- /scripts/custom-instance-setup

ポッドの再起動

新しい変更を使用するには、webservicesidekiq ポッドを再起動する必要があります。これらのポッドを再起動する最も安全な方法は、以下を実行することです:

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

(オプション)ルートユーザーのパスワードをリセットします。

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

  1. コマンドを実行してウェブサービスポッドにアタッチします。

    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!"
    

追加情報