GitLab インストールの復元

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

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

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

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

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

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

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

シークレットの復元

シークレットの復元

GitLabチャートは、railsシークレットがYAMLのコンテンツを持つKubernetesシークレットとして提供されることを期待しています。Linux パッケージインスタンスから rails シークレットをリストアする場合、シークレットは/etc/gitlab/gitlab-secrets.json ファイルに JSON 形式で保存されます。このファイルを変換してYAML形式でシークレットを作成します：

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

  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>
  ci_jwt_signing_key: <your ci jwt signing key>

YAMLファイルからRailsシークレットをリストアするには：

  1. rails secretsのオブジェクト名を探します：

    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. ChartをデプロイしてGitLabインスタンスが起動していることを確認します。以下のコマンドを実行することで、Toolboxポッドが有効化され、実行されていることを確認します。

    kubectl get pods -lrelease=RELEASE_NAME,app=toolbox

  2. 上記のいずれかの場所に tarball を用意してください。<timestamp>_gitlab_backup.tar 形式で名前が付けられていることを確認してください。バックアップのタイムスタンプの内容を読んでください。

  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 <timestamp>

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

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

    URLとしてローカルパスを指定することもできます：file:///<path>

  6. この処理には、tarボールのサイズに応じて時間がかかります。

  7. 復元プロセスでは、データベースの既存のコンテンツが消去され、既存のリポジトリが一時的な場所に移動され、tarボールのコンテンツが抽出されます。リポジトリはディスク上の対応する場所に移動され、アーティファクト、アップロード、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>
note
リストア中に、バックアップ tarball をディスクに展開する必要があります。つまり、Toolboxポッドに必要なサイズのディスクが用意されている必要があります。詳細と設定については、Toolboxのドキュメントを参照してください。

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

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

リストアされたバックアップが既存のChartのインストールからでない場合、リストア後に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>

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

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

  1. 以下のコマンドを実行して、Web サービス・ポッドにアタッチします。

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

追加情報