正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

新しいセカンダリサイトの設定

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

これは、セカンダリ Geoサイトをセットアップする際の最終ステップです。設定プロセスのステージは、ドキュメントに記載されている順序で完了する必要があります。そうでない場合は、続行する前にcomplete all prior stages。

セカンダリサイトを設定する基本的な手順は次のとおりです:

  1. プライマリサイトとセカンダリサイト間で必要な設定をレプリケートします。
  2. 各セカンダリサイトでトラッキングデータベースを設定します。
  3. 各セカンダリサイトでGitLabを起動します。

このドキュメントでは、最初の項目に焦点を当てます。テスト/本番環境で実行する前に、すべての手順を読んで理解しておくことをお勧めします。

both primary and secondary sitesの前提条件:

セカンダリサイトでは、カスタム認証を設定しないでください。これはプライマリサイトによって処理されます。管理者エリアへのアクセスを必要とする変更は、プライマリサイトで行う必要があります。これは、セカンダリサイトが読み取り専用レプリカであるためです。

ステップ1: 秘密のGitLabの値を手動でレプリケートします

GitLabは、/etc/gitlab/gitlab-secrets.jsonファイルに多数の秘密値を格納します。これは、サイトのすべてのノードで同じである必要があります。サイト間でこれらを自動的にレプリケートする手段がない限り（イシュー3789を参照）、これらはセカンダリサイトのすべてのノードに手動でレプリケートする必要があります。

  1. プライマリサイトのRailsノードにSSH接続し、次のコマンドを実行します:

    sudo cat /etc/gitlab/gitlab-secrets.json

    これにより、レプリケートする必要があるシークレットがJSON形式で表示されます。

  2. into each node on your secondary Geo siteにSSH接続し、rootユーザーとしてログインします:

    sudo -i

  3. 既存のシークレットのバックアップを作成します:

    mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`

  4. /etc/gitlab/gitlab-secrets.jsonをプライマリサイトのRailsノードサイトからセカンダリサイトの各ノードにコピーするか、ノード間でファイルの内容をコピーアンドペーストします:

    sudo editor /etc/gitlab/gitlab-secrets.json

# paste the output of the `cat` command you ran on the primary
# save and exit

  5. ファイル権限が正しいことを確認してください:

    chown root:root /etc/gitlab/gitlab-secrets.json
chmod 0600 /etc/gitlab/gitlab-secrets.json

  6. 変更を有効にするには、セカンダリサイトの各Rails、Sidekiq、Gitalyノードを再設定します:

    gitlab-ctl reconfigure
gitlab-ctl restart

ステップ2: プライマリサイトのSSHホストキーを手動でレプリケートします

GitLabはシステムにインストールされたSSHデーモンと統合し、すべてのアクセス要求が処理されるユーザー（通常はgitという名前）を指定します。

ディザスターリカバリーの状況では、GitLabシステム管理者がセカンダリサイトをプライマリサイトにプロモートします。プライマリドメインのDNSレコードも、新しいプライマリサイト（以前はセカンダリサイト）を指すように更新する必要があります。これにより、GitリモートおよびAPI URLを更新する必要がなくなります。

これにより、新たにプロモートされたプライマリサイトへのすべてのSSHリクエストは、SSHホストキーの不一致により失敗します。これを防ぐために、プライマリのSSHホストキーを手動でセカンダリサイトにレプリケートする必要があります。

SSHホストキーのパスは、使用するソフトウェアによって異なります:

  • OpenSSHを使用している場合、パスは/etc/sshです。
  • gitlab-sshdを使用している場合、パスは/var/opt/gitlab/gitlab-sshdです。

次の手順では、使用している<ssh_host_key_path>に置き換えます:

  1. セカンダリサイトの各RailsノードにSSH接続し、rootユーザーとしてサインインします:

    sudo -i

  2. 既存のSSHホストキーのバックアップを作成します:

    find <ssh_host_key_path> -iname 'ssh_host_*' -exec cp {} {}.backup.`date +%F` \;

  3. プライマリサイトからSSHホストキーをコピーします:

    SSHトラフィックを処理するnodes on your primary（primary）サイトのノード（通常は、メインのGitLab Railsアプリケーションノード）の1つに、rootユーザーを使用してアクセスできる場合:

    # Run this from the secondary site, change `<primary_site_fqdn>` for the IP or FQDN of the server
scp root@<primary_node_fqdn>:<ssh_host_key_path>/ssh_host_*_key* <ssh_host_key_path>

    sudo権限を持つユーザーを介してのみアクセスできる場合:

    # Run this from the node on your primary site:
sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz <ssh_host_key_path>/ssh_host_*_key*

# Run this on each node on your secondary site:
scp <user_with_sudo>@<primary_site_fqdn>:geo-host-key.tar.gz .
tar zxvf ~/geo-host-key.tar.gz -C <ssh_host_key_path>

  4. セカンダリサイトの各Railsノードで、ファイルの権限が正しいことを確認します:

    chown root:root <ssh_host_key_path>/ssh_host_*_key*
chmod 0600 <ssh_host_key_path>/ssh_host_*_key

  5. キーのフィンガープリントの一致を検証するには、各サイトのプライマリとセカンダリのノードの両方で次のコマンドを実行します:

    for file in <ssh_host_key_path>/ssh_host_*_key; do ssh-keygen -lf $file; done

    これと同様の出力が表示され、両方のノードで同一である必要があります:

    1024 SHA256:FEZX2jQa2bcsd/fn/uxBzxhKdx4Imc4raXrHwsbtP0M root@serverhostname (DSA)
256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY root@serverhostname (ECDSA)
256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM root@serverhostname (ED25519)
2048 SHA256:qwa+rgir2Oy86QI+PZi/QVR+MSmrdrpsuH7YyKknC+s root@serverhostname (RSA)

  6. 既存の秘密キーに正しい公開キーがあることを確認します:

    # This will print the fingerprint for private keys:
for file in <ssh_host_key_path>/ssh_host_*_key; do ssh-keygen -lf $file; done

# This will print the fingerprint for public keys:
for file in <ssh_host_key_path>/ssh_host_*_key.pub; do ssh-keygen -lf $file; done

    秘密キーと公開キーコマンドの出力は、同じフィンガープリントを生成する必要があります。

  7. セカンダリサイトの各Railsノードで、OpenSSHの場合はsshd、またはgitlab-sshdサービスを再起動します:

    • OpenSSHの場合:

      # Debian or Ubuntu installations
sudo service ssh reload

# CentOS installations
sudo service sshd reload

    • gitlab-sshdの場合:

      sudo gitlab-ctl restart gitlab-sshd

  8. SSHがまだ機能していることを確認します。

    新しいターミナルでGitLab セカンダリサーバーにSSH接続します。接続できない場合は、前の手順に従って権限が正しいことを確認してください。

ステップ3: セカンダリサイトを追加

  1. セカンダリサイトの各RailsおよびSidekiqノードにSSH接続し、rootとしてログインします:

    sudo -i

  2. /etc/gitlab/gitlab.rbを編集し、サイトにuniqueな名前を追加します。これは、次の手順で必要になります:

    ##
## The unique identifier for the Geo site. See
## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings
##
gitlab_rails['geo_node_name'] = '<site_name_here>'

  3. 変更を有効にするには、セカンダリサイトの各RailsおよびSidekiqノードを再設定します:

    gitlab-ctl reconfigure

  4. プライマリノードのGitLabインスタンスに移動します:

    1. 左側のサイドバーの下部で、管理者を選択します。
    2. 左側のサイドバーの下部にあるGeo > サイトを選択します。
    3. サイトを追加を選択します。 Geo設定インターフェースでのセカンダリサイトの追加
    4. 名前に、/etc/gitlab/gitlab.rbのgitlab_rails['geo_node_name']の値を入力します。これらの値は常に、文字どおりexactly一致する必要があります。
    5. 外部URLに、/etc/gitlab/gitlab.rbのexternal_urlの値を入力します。これらの値は常に一致する必要がありますが、一方が/で終わり、もう一方が終わらない場合は問題ありません。
    6. オプション。**内部URL (オプション)**に、セカンダリサイトの内部URLを入力します。
    7. オプション。セカンダリサイトによってレプリケートされるグループまたはストレージシャードを選択します。すべてをレプリケートするには、空白のままにします。詳細については、selective synchronizationを参照してください。
    8. 変更を保存を選択して、セカンダリサイトを追加します。

  5. セカンダリサイトの各RailsおよびSidekiqノードにSSH接続し、サービスを再起動します:

    gitlab-ctl restart

    実行して、Geoの設定に関する一般的なイシューがあるかどうかを確認します:

    gitlab-rake gitlab:geo:check

    チェックのいずれかが失敗した場合は、troubleshooting documentationを確認してください。

  6. Rails or Sidekiq server on your primaryサイトにSSH接続し、rootとしてログインして、セカンダリサイトが到達可能であるか、Geoの設定に共通のイシューがないかを確認します:

    gitlab-rake gitlab:geo:check

    チェックのいずれかが失敗した場合は、troubleshooting documentationを確認してください。

セカンダリサイトがGeoの管理者ページに追加され、再起動されると、サイトは自動的にプライマリサイトから不足データのレプリケートをbackfillというプロセスで開始します。一方、プライマリサイトは各セカンダリサイトに変更を通知し始め、セカンダリサイトはこれらの通知にすぐに対応できます。

セカンダリサイトが実行中でアクセス可能であることを確認してください。プライマリサイトで使用したものと同じ認証情報を使用してセカンダリサイトにサインインできます。

ステップ4: （オプション）カスタム証明書の使用

次の場合は、この手順を安全にスキップできます:

  • プライマリサイトが、公開CA発行のHTTPS証明書を使用している。
  • プライマリサイトは、CA発行（自己署名ではない）のHTTPS証明書を使用して、外部サービスにのみ接続する。

インバウンド接続用のカスタムまたは自己署名証明書

GitLab Geoのプライマリサイトが、カスタムまたはself-signed certificate to secure inbound HTTPS connectionsを使用している場合、これはシングルドメイン証明書またはマルチドメイン証明書のいずれかになります。

証明書のタイプに基づいて、正しい証明書をインストールします:

  • Multi-domain certificate: プライマリサイトとセカンダリサイトドメインの両方を含む: /etc/gitlab/sslの証明書をRails, Sidekiq, and Gitaly（Rails、Sidekiq、およびGitaly） ノード (セカンダリサイト内) すべてにインストールします。
  • Single-domain certificate: 証明書が各Geoサイトドメインに固有である: セカンダリサイトのドメインの有効な証明書を生成し、/etc/gitlab/sslですべてのRails, Sidekiq, and Gitaly（Rails、Sidekiq、およびGitaly）ノード (セカンダリサイト内) にthese instructionsに従ってインストールします。

カスタム証明書を使用する外部サービスへの接続

外部サービス用の自己署名証明書のコピーは、サービスへのアクセスを必要とするすべてのプライマリサイトのノード上の信頼ストアに追加する必要があります。

セカンダリサイトが同じ外部サービスにアクセスできるようにするには、これらの証明書をセカンダリサイトのトラストストアに追加する必要があります。

プライマリサイトがcustom or self-signed certificate for inbound HTTPS connectionsを使用している場合、プライマリサイトの証明書をセカンダリサイトのトラストストアに追加する必要があります:

  1. セカンダリサイトのRails、Sidekiq、GitalyノードにSSH接続し、rootとしてログインします:

    sudo -i

  2. プライマリサイトから信頼できる証明書をコピーします:

    rootユーザーを使用してSSHトラフィックを処理するプライマリサイトのノードの1つにアクセスできる場合:

    scp root@<primary_site_node_fqdn>:/etc/gitlab/trusted-certs/* /etc/gitlab/trusted-certs

    sudo権限を持つユーザーを介してのみアクセスできる場合:

    # Run this from the node on your primary site:
sudo tar --transform 's/.*\///g' -zcvf ~/geo-trusted-certs.tar.gz /etc/gitlab/trusted-certs/*

# Run this on each node on your secondary site:
scp <user_with_sudo>@<primary_site_node_fqdn>:geo-trusted-certs.tar.gz .
tar zxvf ~/geo-trusted-certs.tar.gz -C /etc/gitlab/trusted-certs

  3. 更新された各Rails, Sidekiq, and Gitaly node in your secondary（Rails、Sidekiq、およびGitalyノード（セカンダリ））サイトを再設定します:

    sudo gitlab-ctl reconfigure

ステップ5: HTTP/HTTPSおよびSSHを介したGitアクセスを有効にする

GeoはHTTP/HTTPSを介してリポジトリを同期するため、このクローン方式を有効にする必要があります。これはデフォルトで有効になっていますが、既存のサイトをGeoに変換する場合は、確認する必要があります:

プライマリサイトで:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 設定 > 一般を選択します。
  3. 表示レベルとアクセス制御を展開します。
  4. SSH経由でGitを使用している場合は、次のようにします:
    1. 「有効なGitアクセスプロトコル」が「SSHとHTTP(S)の両方」に設定されていることを確認します。
    2. all primary and secondaryサイトでfast lookup of authorized SSH keys in the databaseを設定する手順に従ってください。
  5. SSH経由でGitを使用していない場合は、「有効なGitアクセスプロトコル」を「HTTP(S)のみ」に設定します。

ステップ6: セカンダリサイトの適切な機能を検証します

セカンダリサイトには、プライマリサイトで使用したものと同じ認証情報でサインインできます。サインインした後:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. Geo > サイトを選択します。
  3. それがセカンダリ Geoサイトとして正しく識別され、Geoが有効になっていることを確認します。

最初のレプリケーションには時間がかかる場合があります。サイトのステータスまたは「バックフィル」は、まだ進行中である可能性があります。ブラウザで、プライマリサイトのGeoサイトダッシュボードから、各Geoサイトの同期プロセスをモニタリングできます。

Geo dashboard of secondary site

インストールが正しく機能しない場合は、troubleshooting documentを確認してください。

ダッシュボードで明らかになる可能性のある2つの最も明白なイシューは次のとおりです:

  1. データベースのレプリケーションがうまく機能していません。
  2. インスタンスからインスタンスへの通知が機能していません。その場合、次のいずれかになります:
    • カスタム証明書またはカスタムCAを使用しています（troubleshooting documentを参照）。
    • インスタンスがファイアウォールで保護されています（ファイアウォールルールを確認してください）。

セカンダリサイトを無効にすると、同期プロセスが停止します。

リポジトリストレージが複数のリポジトリシャードのプライマリサイトでカスタマイズされている場合は、同じ設定を各セカンダリサイトで複製する必要があります。

Using a Geo Site guideにユーザーを誘導します。

現在、同期されているのは次のとおりです:

  • Gitリポジトリ
  • Wiki。
  • LFSオブジェクト。
  • イシュー、マージリクエスト、スニペット、コメントの添付ファイル。
  • ユーザー、グループ、プロジェクトアバター。

トラブルシューティング

troubleshooting documentを参照してください。