ドキュメントに関する現在のご利用体験についてお聞かせください。アンケートにご協力ください。

ディザスターリカバリー（Geo）

プラン: Premium、Ultimate
提供形態: GitLab Self-Managed

Geoは、データベース、Gitリポジトリ、その他のアセットをレプリケートします。いくつかの既知のイシューがあります。

複数セカンダリの設定では、プロモートされていないすべてのセカンダリの完全な再同期と再設定が必要であり、ダウンタイムが発生します。
セカンダリGeoサイトがプロモートされた後、プライマリGeoサイトは完全に切り離されます。プライマリGeoサイトを復元する場合は、新しいセカンダリGeoサイトとして追加する必要があります。

選択的同期が有効なセカンダリGeoサイト

選択的同期が有効なセカンダリGeoサイトをプロモートすると、そのセカンダリGeoサイトにレプリケートされなかったすべてのデータがpermanent data loss。詳細については、選択的同期が有効なセカンダリGeoサイトのプロモートを参照してください。

`gitlab-cluster.json`ファイル

gitlab-ctl geo promoteを使用してセカンダリGeoサイトをプライマリGeoサイトにプロモートすると、コマンドは実行する各ノードに/etc/gitlab/gitlab-cluster.jsonファイルが自動的に作成されます。ほとんどの場合、このファイルを手動で編集する必要はありません。

gitlab-cluster.jsonファイルを使用すると、/etc/gitlab/gitlab.rbを直接変更することなく、プロモートコマンドで設定の変更を自動化できます。gitlab.rbをプログラムで編集するとエラーが発生しやすいため、gitlab-cluster.jsonは機械で管理される上書きレイヤーとして機能します。

両方のファイルが存在する場合、gitlab-ctl reconfigureが実行されると、gitlab-cluster.jsonの値がgitlab.rbの対応する値より優先されます。このコマンドを実行すると、次のような警告が表示されます:

The 'geo_primary_role' is defined in /etc/gitlab/gitlab-cluster.json as 'true' and overrides the setting in the /etc/gitlab/gitlab.rb
The 'geo_secondary_role' is defined in /etc/gitlab/gitlab-cluster.json as 'false' and overrides the setting in the /etc/gitlab/gitlab.rb

この警告は、プロモート後に予期されるものです。

ファイル構造

典型的なgitlab-cluster.jsonファイルは次のようになります:

json
{
  "primary": true,
  "secondary": false,
  "geo_secondary": {
    "enable": false
  }
}

キー	説明
`primary`	`true`の場合、`geo_primary_role`が有効になり、ノードがGeoプライマリとして設定されます。
`secondary`	`true`の場合、`geo_secondary_role`が有効になり、ノードがGeoセカンダリとして設定されます。
`geo_secondary`	Geoセカンダリ設定に関連する設定（追跡データベースなど）を含みます。`"enable": false`はセカンダリ固有のサービスを無効にします。

primaryとsecondaryキーは、それぞれgeo_primary_roleとgeo_secondary_roleに対応します。これらのロールは単一ノードの設定に便利なものであり、個々のサービスロールがgitlab.rbで明示的に設定されているマルチノードの設定では使用しないでください。

ファイルを削除

プロモートが成功した後も、gitlab-cluster.jsonを残しておくことができます。ただし、次のような場合は削除する必要があります:

降格されたプライマリを新しいセカンダリGeoサイトとして戻す場合は、すべてのSidekiq、PostgreSQL、Gitaly、およびRailsノードからgitlab-cluster.jsonを削除する必要があります。
gitlab.rbを更新してGeoロール（roles(['geo_primary_role'])など）を設定し、gitlab.rbを唯一の設定ソースにしたい場合。
部分的なフェイルオーバーからリカバリーした後。
ファイルがリカバリー中に手動で作成される時期の詳細については、部分的なフェイルオーバーからのリカバリーを参照してください。

ファイルを削除するには:

次のコマンドを実行します:
shell
```
sudo rm /etc/gitlab/gitlab-cluster.json
sudo gitlab-ctl reconfigure
```
マルチノードの設定では、サイトのすべてのノードでこれらのコマンドを繰り返します。

gitlab-cluster.jsonが再設定プロセスとどのように連携するかの技術的な詳細については、Omnibus再設定ドキュメントを参照してください。

単一ノードの設定におけるセカンダリGeoサイトのプロモート

Geoレプリカを自動的にプロモートしてフェイルオーバーを行うことはできませんが、マシンへのrootアクセスがある場合は手動でプロモートできます。

このプロセスは、セカンダリGeoサイトをプライマリGeoサイトにプロモートします。地理的な冗長性をできるだけ早く回復するために、これらの手順に従った直後に新しいセカンダリGeoサイトを追加する必要があります。

可能であればレプリケーションの完了を許可する

セカンダリGeoサイトがまだプライマリGeoサイトからデータをレプリケートしている場合は、不要なデータ損失を避けるために計画されたフェイルオーバードキュメントに可能な限り厳密に従ってください。

ステップ1.プライマリGeoサイトを永続的に無効にする

プライマリGeoサイトがオフラインになった場合、プライマリGeoサイトに保存されているデータがセカンダリGeoサイトにレプリケートされていない可能性があります。続行すると、このデータは失われたものとして扱われます。

プライマリGeoサイトで停止が発生した場合、2つの異なるGitLabインスタンスで書き込みが発生するスプリットブレイン状態を回避するために可能な限りのことを行う必要があります。これはリカバリー作業を複雑にします。したがって、フェイルオーバーの準備として、プライマリGeoサイトを無効にする必要があります。

SSHアクセスがある場合:
1. プライマリGeoサイトにSSHで接続し、GitLabを停止および無効にします:
  shell
```
sudo gitlab-ctl stop
```
2. サーバーが予期せず再起動した場合にGitLabが再度起動するのを防ぎます:
  shell
```
sudo systemctl disable gitlab-runsvdir
```
プライマリGeoサイトへのSSHアクセスがない場合は、利用可能なあらゆる手段でマシンをオフラインにし、再起動しないようにします。次のような作業が必要になる場合があります:
- ロードバランサーを再設定します。
- DNSレコードを変更します（例: プライマリDNSレコードをセカンダリGeoサイトにポイントして、プライマリGeoサイトの使用を停止します）。
- 仮想サーバーを停止します。
- ファイアウォールを介してトラフィックをブロックします。
- プライマリGeoサイトからオブジェクトストレージの権限を失効します。
- マシンを物理的に切断します。
プライマリドメインDNSレコードを更新する場合は、DNS変更の高速な伝播を確実にするために、低いTTLを維持することをお勧めします。
プライマリGeoサイトの/etc/gitlab/gitlab.rbファイルは、このプロセス中にセカンダリGeoサイトに自動的にコピーされません。プライマリの/etc/gitlab/gitlab.rbファイルをバックアップして、後でセカンダリGeoサイトで必要な値を復元できるようにしてください。

ステップ2.セカンダリGeoサイトのプロモート

セカンダリをプロモートする際に、次の点に注意してください:

セカンダリGeoサイトが一時停止されている場合、プロモートは最後に既知の状態へのポイントインタイムリカバリーを実行します。セカンダリが一時停止中にプライマリで作成されたデータは失われます。
セカンダリGeoサイトが一時停止されている状態で、このプロセス中にActiveRecord::StatementInvalid: PG::ReadOnlySqlTransaction: ERROR: cannot execute DELETE in a read-only transactionエラーメッセージが発生した場合は、このナレッジベースドキュメントを参照してください: 予期しないプライマリ停止後のGeoプロモートの失敗（読み取り専用トランザクションエラーまたはタイムアウト）。
現時点では、新しいセカンダリを追加しないでください。新しいセカンダリを追加したい場合は、セカンダリをプライマリにプロモートするプロセス全体を完了した後に行います。
このプロセス中にActiveRecord::RecordInvalid: Validation failed: Name has already been takenエラーメッセージが発生した場合は、詳細についてこのトラブルシューティングアドバイスを参照してください。
個別のURLを使用している場合は、プライマリドメインDNSを新しくプロモートされたサイトにポイントする必要があります。そうしないと、Runnerを新しくプロモートされたサイトに再登録する必要があり、すべてのGitリモート、ブックマーク、および外部インテグレーションを更新する必要があります。
ロケーション認識DNSを使用している場合、古いプライマリがDNSエントリから削除されると、Runnerは自動的に新しいプライマリに接続します。
プライマリGeoサイトがダウンした後、セカンダリでgitlab-ctl promotion-preflight-checksを実行してGeo同期ステータスを確認し、最終検証チェックを実行します。
以前のプライマリに接続されていたRunnerが戻ってこないと予想される場合は、それらを削除する必要があります:
- UIを使用する場合は、以下のとおりです:
  1. 右上隅で、管理者を選択します。
  2. CI/CD > Runnersを選択して削除します。
- Runner APIを使用します。

単一ノードで実行されているセカンダリGeoサイトのプロモート

セカンダリGeoサイトにSSHで接続し、実行します:
- セカンダリGeoサイトをプライマリにプロモートするには:
  shell
```
sudo gitlab-ctl geo promote
```
- セカンダリGeoサイトをプライマリにwithout any further confirmationプロモートするには:
  shell
```
sudo gitlab-ctl geo promote --force
```
以前セカンダリGeoサイトに使用されていたURLを使用して、新しくプロモートされたプライマリGeoサイトに接続できることを確認します。
成功した場合、セカンダリGeoサイトはプライマリGeoサイトにプロモートされました。

gitlab-ctl geo promoteを実行すると、gitlab-cluster.jsonファイルがノードに作成されます。このファイルは、再設定時にgitlab.rb内のGeoロール設定を上書きします。

ステップ3.以前のセカンダリの追跡データベースを削除する

/etc/gitlab/gitlab.rbファイルでgeo_secondary[]設定オプションが有効になっている場合は、それらをコメントアウトまたは削除し、変更を有効にするためにGitLabを再設定します。

この時点で、プロモートされたサイトが新しいプライマリGitLabGeoサイトです。オプションで、新しいセカンダリGeoサイトとしてGeoを再度設定したい場合は、古いサイトをセカンダリとして戻すことができます。

マルチノードと単一ノードセカンダリGeoサイトを持つセカンダリGeoサイトのプロモート

セカンダリGeoサイトのすべてのSidekiq、PostgreSQL、およびGitalyノードにSSHで接続し、次のいずれかのコマンドを実行します:
- セカンダリGeoサイトのノードをプライマリにプロモートするには:
  shell
```
sudo gitlab-ctl geo promote
```
- セカンダリGeoサイトをプライマリにwithout any further confirmationプロモートするには:
  shell
```
sudo gitlab-ctl geo promote --force
```
セカンダリGeoサイトの各RailsノードにSSHで接続し、次のいずれかのコマンドを実行します:
- セカンダリGeoサイトをプライマリにプロモートするには:
  shell
```
sudo gitlab-ctl geo promote
```
- セカンダリGeoサイトをプライマリにwithout any further confirmationプロモートするには:
  shell
```
sudo gitlab-ctl geo promote --force
```
以前セカンダリGeoサイトに使用されていたURLを使用して、新しくプロモートされたプライマリGeoサイトに接続できることを確認します。
成功した場合、セカンダリGeoサイトはプライマリGeoサイトにプロモートされました。

Patroniスタンバイクラスターを持つセカンダリGeoサイトのプロモート

セカンダリGeoサイトのすべてのSidekiq、PostgreSQL、およびGitalyノードにSSHで接続し、次のいずれかのコマンドを実行します:
- セカンダリGeoサイトをプライマリにプロモートするには:
  shell
```
sudo gitlab-ctl geo promote
```
- セカンダリGeoサイトをプライマリにwithout any further confirmationプロモートするには:
  shell
```
sudo gitlab-ctl geo promote --force
```
セカンダリGeoサイトの各RailsノードにSSHで接続し、次のいずれかのコマンドを実行します:
- セカンダリGeoサイトをプライマリにプロモートするには:
  shell
```
sudo gitlab-ctl geo promote
```
- セカンダリGeoサイトをプライマリにwithout any further confirmationプロモートするには:
  shell
```
sudo gitlab-ctl geo promote --force
```
以前セカンダリGeoサイトに使用されていたURLを使用して、新しくプロモートされたプライマリGeoサイトに接続できることを確認します。
成功した場合、セカンダリGeoサイトはプライマリGeoサイトにプロモートされました。

外部PostgreSQLデータベースを持つセカンダリGeoサイトのプロモート

gitlab-ctl geo promoteコマンドは、外部PostgreSQLデータベースと組み合わせて使用できます。この場合、まずセカンダリGeoサイトに関連付けられたレプリカデータベースを手動でプロモートする必要があります:

セカンダリGeoサイトに関連付けられたレプリカデータベースをプロモートします。これにより、データベースが読み書き可能に設定されます。手順は、データベースがホストされている場所によって異なります:
- Amazon RDS
- Azure PostgreSQL
- Google Cloud SQL
- 他の外部PostgreSQLデータベースの場合は、セカンダリGeoサイトに次のスクリプトを保存します（例: /tmp/geo_promote.sh）。そして、環境に合わせて接続パラメータを修正します。次に、それを実行してレプリカをプロモートします:
  shell
```
#!/bin/bash

PG_SUPERUSER=postgres

# The path to your pg_ctl binary. You may need to adjust this path to match
# your PostgreSQL installation
PG_CTL_BINARY=/usr/lib/postgresql/16/bin/pg_ctl

# The path to your PostgreSQL data directory. You may need to adjust this
# path to match your PostgreSQL installation. You can also run
# `SHOW data_directory;` from PostgreSQL to find your data directory
PG_DATA_DIRECTORY=/etc/postgresql/16/main

# Promote the PostgreSQL database and allow read/write operations
sudo -u $PG_SUPERUSER $PG_CTL_BINARY -D $PG_DATA_DIRECTORY promote
```
セカンダリGeoサイトのすべてのSidekiq、PostgreSQL、およびGitalyノードにSSHで接続し、次のいずれかのコマンドを実行します:
- セカンダリGeoサイトをプライマリにプロモートするには:
  shell
```
sudo gitlab-ctl geo promote
```
- セカンダリGeoサイトをプライマリにwithout any further confirmationプロモートするには:
  shell
```
sudo gitlab-ctl geo promote --force
```
セカンダリGeoサイトの各RailsノードにSSHで接続し、次のいずれかのコマンドを実行します:
- セカンダリGeoサイトをプライマリにプロモートするには:
  shell
```
sudo gitlab-ctl geo promote
```
- セカンダリGeoサイトをプライマリにwithout any further confirmationプロモートするには:
  shell
```
sudo gitlab-ctl geo promote --force
```
以前セカンダリGeoサイトに使用されていたURLを使用して、新しくプロモートされたプライマリGeoサイトに接続できることを確認します。
成功した場合、セカンダリGeoサイトはプライマリGeoサイトにプロモートされました。

（オプション）プライマリドメインDNSレコードの更新

プライマリドメインのDNSレコードを更新して、セカンダリGeoサイトをポイントするようにします。これにより、GitリモートやAPI URLの変更など、プライマリドメインへのすべての参照を更新する必要がなくなります。

セカンダリGeoサイトにSSHで接続し、rootでログインします:
shell
```
sudo -i
```
プライマリドメインのDNSレコードを更新します。プライマリドメインのDNSレコードを更新してセカンダリGeoサイトをポイントするようにした後、セカンダリGeoサイトの/etc/gitlab/gitlab.rbを編集して新しいURLを反映させます:
ruby
```
# Change the existing external_url configuration
external_url 'https://<new_external_url>'
```
external_urlを変更しても、セカンダリDNSレコードがそのまま残っている限り、古いセカンダリURLからのアクセスは妨げられません。
セカンダリのSSL証明書を更新します:
- Let’s Encryptインテグレーションを使用している場合、証明書は自動的に更新されます。
- 手動で設定した場合は、セカンダリの証明書をプライマリからセカンダリにコピーします。プライマリにアクセスできない場合は、新しい証明書を発行し、主体の別名にプライマリとセカンダリの両方のURLが含まれていることを確認してください。次で確認できます:
  shell
```
/opt/gitlab/embedded/bin/openssl x509 -noout -dates -subject -issuer \
    -nameopt multiline -ext subjectAltName -in /etc/gitlab/ssl/new-gitlab.new-example.com.crt
```
セカンダリGeoサイトを再設定して、変更を有効にします:
shell
```
gitlab-ctl reconfigure
```
新しくプロモートされたプライマリGeoサイトURLを更新するために、以下のコマンドを実行します:
shell
```
gitlab-rake gitlab:geo:update_primary_node_url
```
このコマンドは、/etc/gitlab/gitlab.rbで定義されているexternal_urlの変更された設定を使用します。
新しくプロモートされたプライマリに、そのURLを使用して接続できることを確認します。プライマリドメインのDNSレコードを更新した場合、以前のDNSレコードのTTLによっては、これらの変更がまだ伝播されていない可能性があります。

（オプション）プロモートされたプライマリGeoサイトにセカンダリGeoサイトを追加する

新しいセカンダリGeoサイトをオンラインにするには、Geo設定手順に従ってください。

マルチノード設定におけるセカンダリGeoレプリカのプロモート

セカンダリGeoサイトが複数あり、そのうちの1つをプロモートする必要がある場合は、単一ノード設定におけるセカンダリGeoサイトのプロモートに従うことをお勧めします。その後、さらに2つのステップが必要です。

ステップ1.1つ以上のセカンダリGeoサイトにサービスを提供するように新しいプライマリGeoサイトを準備する

新しいプライマリGeoサイトにSSHで接続し、rootでログインします:
shell
```
sudo -i
```

/etc/gitlab/gitlab.rbを編集します:

ruby
## Enable a Geo Primary role (if you haven't yet)
roles ['geo_primary_role']

##
# Allow PostgreSQL client authentication from the primary and secondary IPs. These IPs may be
# public or VPC addresses in CIDR format, for example ['198.51.100.1/32', '198.51.100.2/32']
##
postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']

# Every secondary site needs to have its own slot so specify the number of secondary sites you're going to have
# postgresql['max_replication_slots'] = 1 # Set this to be the number of Geo secondary nodes if you have more than one

##
## Disable automatic database migrations temporarily
## (until PostgreSQL is restarted and listening on the private address).
##
gitlab_rails['auto_migrate'] = false

（これらの設定の詳細については、プライマリサーバーの設定を参照してください）

ファイルを保存し、データベースのリッスン変更とレプリケーションスロットの変更を適用するためにGitLabを再構成します:
shell
```
gitlab-ctl reconfigure
```
変更を有効にするため、PostgreSQLを再起動します:
shell
```
gitlab-ctl restart postgresql
```
PostgreSQLが再起動され、プライベートアドレスでリッスンしているため、移行を再度有効にします。
/etc/gitlab/gitlab.rbを編集し、構成をtrueに変更します:
ruby
```
gitlab_rails['auto_migrate'] = true
```
ファイルを保存し、GitLabを再設定します:
shell
```
gitlab-ctl reconfigure
```

ステップ2.レプリケーションプロセスを開始する

次に、各セカンダリGeoサイトに新しいプライマリGeoサイトの変更をリッスンさせる必要があります。そのためには、レプリケーションプロセスを再度開始する必要がありますが、今回は別のプライマリGeoサイトに対してです。古いレプリケーション設定はすべて上書きされます。

既存のセカンダリGeoサイトにはすべて入力されたデータベースがあるため、次のようなメッセージが表示される場合があります:

shell

Found data inside the gitlabhq_production database! If you are sure you are in the secondary server, override with --force

適切なセカンダリGeoサイトであることを確認したら、--forceでレプリケーションを開始します。

--forceを使用すると、all existing data in the database on that secondary server to be deleted。

GitLab HelmチャートにおけるセカンダリGeoクラスターのプロモート

クラウドネイティブGeoデプロイを更新する場合、セカンダリKubernetesクラスターの外部にあるノードを更新するプロセスは、非クラウドネイティブのアプローチと変わりありません。そのため、詳細についてはいつでも単一ノード設定におけるセカンダリGeoサイトのプロモートを参照してください。

以下のセクションでは、gitlabネームスペースを使用していることを前提としています。クラスターの設定時に別のネームスペースを使用した場合は、--namespace gitlabを独自のネームスペースに置き換える必要があります。

ステップ1.プライマリクラスターを永続的に無効にする

プライマリKubernetesクラスターにアクセスできる場合は、それに接続し、GitLab webserviceおよびSidekiqポッドを無効にします:

shell
kubectl --namespace gitlab scale deploy gitlab-geo-webservice-default --replicas=0
kubectl --namespace gitlab scale deploy gitlab-geo-sidekiq-all-in-1-v1 --replicas=0

プライマリKubernetesクラスターにアクセスできない場合は、クラスターをオフラインにし、利用可能なあらゆる手段で再起動しないようにします。次のような作業が必要になる場合があります:
- ロードバランサーを再設定します。
- DNSレコードを変更します（例: プライマリDNSレコードをセカンダリGeoサイトにポイントして、プライマリGeoサイトの使用を停止します）。
- 仮想サーバーを停止します。
- ファイアウォールを介してトラフィックをブロックします。
- プライマリGeoサイトからオブジェクトストレージの権限を失効します。
- マシンを物理的に切断します。

ステップ2.クラスターの外部にあるすべてのセカンダリGeoサイトノードをプロモート

セカンダリGeoサイトが一時停止されている場合、これは最後に既知の状態へのポイントインタイムリカバリーを実行します。セカンダリが一時停止中にプライマリで作成されたデータは失われます。

Linuxパッケージを使用しているセカンダリKubernetesクラスターの外部にある各ノード（PostgreSQLまたはGitalyなど）にSSHで接続し、次のいずれかのコマンドを実行します:
- セカンダリKubernetesクラスターの外部にあるセカンダリGeoサイトノードをプライマリにプロモートするには:
  shell
```
sudo gitlab-ctl geo promote
```
- セカンダリKubernetesクラスターの外部にあるセカンダリGeoサイトノードをプライマリにwithout any further confirmationプロモートするには:
  shell
```
sudo gitlab-ctl geo promote --force
```

toolboxポッドを見つけます:

shell

kubectl --namespace gitlab get pods -lapp=toolbox

セカンダリをプロモートします:
shell
```
kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake gitlab:geo:set_secondary_as_primary
```
タスクの動作を変更するために環境変数を指定できます。利用可能な変数は次のとおりです:
名前デフォルト値説明
ENABLE_SILENT_MODE false trueの場合、プロモート前にサイレントモードを有効にします

名前	デフォルト値	説明
`ENABLE_SILENT_MODE`	`false`	`true`の場合、プロモート前にサイレントモードを有効にします

ステップ3.セカンダリクラスターをプロモート

既存のクラスター設定を更新します。
Helmで既存の設定を取得できます:
shell
```
helm --namespace gitlab get values gitlab-geo > gitlab.yaml
```
既存の設定には、次のようなGeoセクションが含まれています:
yaml
```
geo:
   enabled: true
   role: secondary
   nodeName: secondary.example.com
   psql:
      host: geo-2.db.example.com
      port: 5431
      password:
         secret: geo
         key: geo-postgresql-password
```
セカンダリクラスターをプライマリクラスターにプロモートするには、role: secondaryをrole: primaryに更新します。
クラスターがプライマリGeoサイトとして残る場合、geoの下のpsqlセクション全体を削除する必要があります。これは追跡データベースを参照します。そのままにしておくと、アプリケーションは起動時にノードをセカンダリとして識別し、統合URLで新しいセカンダリが追加されたときに認証を妨げるルート登録の問題を引き起こします。
新しい設定でクラスターを更新します:
shell
```
helm upgrade --install --version <current Chart version> gitlab-geo gitlab/gitlab --namespace gitlab -f gitlab.yaml
```
以前セカンダリに使用されていたURLを使用して、新しくプロモートされたプライマリに接続できることを確認します。
成功しました！セカンダリがプライマリにプロモートされました。

ステップ4.（オプション）OpenBao HAクラスターをプロモート

GitLab Secrets Managerが有効になっている場合、Kubernetesクラスターをプロモートした後、OpenBao高可用性（HA）クラスターをプロモートするには、以下の手順を実行します。

OpenBaoポッドを再起動する

PostgreSQLレプリカがプライマリにプロモートされた後、OpenBaoポッドを再起動して、書き込み可能になったデータベースに再接続させます:

shell
kubectl --namespace gitlab rollout restart deployment -l app=openbao

JWT認証を設定する

プライマリドメインがプロモートされたセカンダリGeoサイトをポイントするようにDNSレコードを更新します。OpenBaoは、異なるドメインを使用するセカンダリGeoサイトへのフェイルオーバーをサポートしていません。詳細については、Geoデプロイを参照してください。

必要に応じて開封シークレットを復元する

セカンダリクラスターの開封キーは、プライマリキーと同じである必要があります。そうでない場合、OpenBaoはセカンダリのVaultを開封できません。

不一致がある場合は、gitlab-openbao-unsealシークレットをセカンダリクラスターにバックアップから復元し、OpenBaoポッドを再起動します:

shell
kubectl --namespace gitlab rollout restart deployment -l app=openbao

OpenBaoが機能することを確認する

すべてのOpenBaoポッドが実行されていることを確認します:
shell
```
kubectl --namespace gitlab get pods -l app=openbao
```
シークレットマネージャー変数を使用するCIパイプラインを実行して、OpenBaoインテグレーションをテストします。

トラブルシューティング

このセクションは別の場所に移動されました。

Was this page helpful?