Geo設定

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

note
これは、セカンダリGeo サイトのセットアップの最終ステップです。セットアッププロセスのステージは、文書化された順序で完了する必要があります。そうでない場合は、先に進む前にすべてのステージを完了してください。

データベースのレプリケーションを設定し、プライマリおよびセカンダリサイトの両方で作成者の SSH キーを高速ルックアップするよう設定したことを確認してください。

セカンダリサイトの設定の基本的な手順は以下のとおりです：

  • プライマリ・サイトと セカンダリ・サイト間で必要な設定を複製します。
  • 各セカンダリサイトにトラッキングデータベースを設定します。
  • 各セカンダリサイトでGitLab を起動します。

テスト/本番環境で実行する前に、まずすべてのステップに目を通すことをお勧めします。

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

ステップ1.GitLab の秘密の値を手動で複製します。

GitLabは/etc/gitlab/gitlab-secrets.json ファイルにいくつかのシークレット値を保存しています。これはサイトのすべてのノードで同じでなければなりません。サイト間でこれらを自動的に複製する手段ができるまでは（イシュー#3789を参照）、セカンダリサイトのすべてのノードに手動で複製しなければなりません。

  1. プライマリサイトのRailsノードにSSH接続して、以下のコマンドを実行してください：

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

    複製が必要なシークレットがJSON形式で表示されます。

  2. セカンダリノードの各ノードにSSH でログインし、root ユーザーとしてログインします：

    sudo -i

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

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

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

    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トラフィックを提供しているプライマリサイトのノード（通常はメインの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
    note
    秘密鍵と公開鍵コマンドの出力は同じフィンガープリントを生成するはずです。

  7. セカンダリサイトの各 Rails ノードで sshd for OpenSSH または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 を編集し、サイトの固有名を追加します。これは次のステップで必要になります：

    ##
## 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. 左のサイドバーで、Search を選択するか、次のページに進んでください。
    2. Admin Areaを選択します。
    3. 左サイドバーでGeo > Sites を選択します。
    4. サイトを追加]を選択します。Add secondary site
    5. Name に、gitlab_rails['geo_node_name'] の値を/etc/gitlab/gitlab.rbに入力します。これらの値は、常に文字と文字が正確に一致する必要があります。
    6. 外部URLには、/etc/gitlab/gitlab.rbにexternal_url の値を入力します。これらの値は常に一致しなければなりませんが、一方が/ で終わっていても、もう一方がそうでなくてもかまいません。
    7. オプション。内部URL（オプション）には、プライマリ・サイトの内部URLを入力します。
    8. オプション。セカンダリサイトでレプリケートするグループまたはストレージシャードを選択します。すべてをレプリケートする場合は空白のままにします。詳細については、選択的同期を参照してください。
    9. 変更を保存］を選択して、セカンダリサイトを追加します。

  5. セカンダリサイトの各Rails、SidekiqノードにSSHでログインし、サービスを再起動します：

    gitlab-ctl restart

    Geoのセットアップに共通のイシューがないか、実行して確認してください：

    gitlab-rake gitlab:geo:check

    いずれかのチェックに失敗した場合は、トラブルシューティング ドキュメントを確認してください。

  6. プライマリサイトの Rails または Sidekiq サーバーにSSH でログインし、root としてログインして、セカンダリサイトに到達可能か、Geo セットアップに共通の問題がないかを確認します：

    gitlab-rake gitlab:geo:check

    いずれかのチェックに失敗した場合は、トラブルシューティング ドキュメントを確認してください。

セカンダリサイトが Geo 管理ページに追加され、再起動されると、サイトは自動的に、バックフィルと呼ばれるプロセスで、プライマリサイトから欠落したデータの複製を開始します。一方、プライマリサイトは各セカンダリサイトに変更の通知を開始し、セカンダリサイトはその通知に即座に対応できるようになります。

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

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

以下の場合は、このステップを省略できます：

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

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

GitLab Geoプライマリサイトがカスタム証明書または自己署名証明書をインバウンドHTTPS接続のセキュリティに使用する場合、これはシングルドメイン証明書またはマルチドメイン証明書のいずれかになります。

証明書の種類に応じて正しい証明書をインストールしてください：

  • プライマリ サイトとセカンダリ サイトの両方のドメインを含むマルチドメイン証明書：セカンダリサイトのすべてのRails、Sidekiq、Gitalyノードに/etc/gitlab/ssl 、証明書をインストールします。
  • 証明書が各 Geo サイト ドメインに固有のシングル ドメイン証明書：セカンダリサイトのドメインに対して有効な証明書を生成し、セカンダリサイト内のすべてのRails、Sidekiq、および Gitalyノードに、以下の手順に従って/etc/gitlab/ssl にインストールします。

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

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

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

プライマリ・サイトが インバウンドの HTTPS 接続にカスタム証明書または自己署名証明書を使用している場合は、プライマリ・サイトの証明書をセカンダリ・サイトのトラスト・ストアに追加する必要があります：

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

    sudo -i

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

    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、Gitalyノードをそれぞれ再設定します：

    sudo gitlab-ctl reconfigure

ステップ5.HTTP/HTTPSとSSHでGitにアクセスできるようにします。

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

プライマリサイトで

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで、設定 > 一般を選択します。
  4. 表示とアクセス制御] を展開します。
  5. GitをSSHで使う場合：
    1. Enabled Git access protocols” が “Both SSH and HTTP(S)” になっていることを確認してください。
    2. プライマリとセカンダリの全サイトで、データベース内の作成者SSHキーを高速に検索します。
  6. SSHでGitを使わない場合は、”Enabled Git access protocols” を “Only HTTP(S)” に設定してください。

ステップ6.セカンダリー・サイトが正しく機能していることを確認します。

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

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーでGeo > Sites を選択します。
  4. セカンダリGeo サイトとして正しく認識され、Geo が有効になっていることを確認します。

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

Geo dashboard

インストールが正常に機能していない場合は、トラブルシューティングのドキュメントをご確認ください。

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

  1. データベースのレプリケーションがうまく機能していない
  2. インスタンス間の通知が機能していないこの場合、以下のようなことが考えられます：

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

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

ユーザーにGeo サイトの使用ガイドを参照してください。

現在、同期されているのはこれです：

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

選択的同期

Geo は選択的同期をサポートしており、管理者はセカンダリサイトで同期するプロジェクトを選択できます。プロジェクトのサブセットは、グループまたはストレージシャードごとに選択できます。前者はユーザーのサブセットに属するデータをレプリケートするのに適しており、後者はGeoを大規模なGitLabインスタンスに段階的に展開するのに適しています。

note
Geoの同期ロジックはドキュメントにまとめられています。ソリューションとドキュメントはどちらも随時変更される可能性があります。プライバシーやサイバーセキュリティに関する法律、適用される貿易管理法に関する法的義務は、継続的に独自に判断する必要があります。

選択的同期：

  1. セカンダリサイトからの権限を制限しません。
  2. セカンダリサイトからプロジェクトのメタデータを非表示にしません。
    • Geoは現在PostgreSQLレプリケーションに依存しているため、すべてのプロジェクトメタデータはセカンダリサイトにレプリケートされますが、選択されていないリポジトリは空になります。
  3. Geo イベントログに生成されるイベントの数は減りません。
    • プライマリ・サイトは、セカンダリ・サイトが存在する限りイベントを生成します。選択的同期制限は、プライマリ・サイトではなく、セカンダリ・サイトに実装されます。

複製されていないリポジトリに対する Git オペレーション

GitLab 12.10 で HTTP(S) 用に、GitLab 13.0 で SSH 用に導入されました。

HTTP(S) と SSH 経由での Git clone, pull, push オペレーションは、プライマリサイトに存在しセカンダリサイトに存在しないリポジトリに対してサポートされます。この状況は以下の場合に発生する可能性があります：

  • 選択的同期にリポジトリにアタッチされているプロジェクトが含まれていない場合。
  • リポジトリはアクティブにレプリケートされていますが、まだ完了していません。

Geo のアップグレード

Geo サイトのアップグレードに関する文書を参照してください。

トラブルシューティング

トラブルシューティングをご覧ください。