GitLab GeoでGitLabチャートを設定する

GitLab Geoは、地理的に分散したアプリケーションデプロイを可能にします。

外部データベースサービスも使用できますが、これらのドキュメントでは、PostgreSQL用のLinuxパッケージを使用して、最もプラットフォームに依存しないガイドを提供し、gitlab-ctlに含まれる自動化を利用することに重点を置いています。

このガイドでは、両方のクラスタリングで同じ外部URLを使用します。この機能は、バージョン7.3以降のチャートでサポートされています。Geoサイトの統一されたURLを設定するを参照してください。オプションで、セカンダリサイトに個別のURLを設定することができます。

既知の問題については、Geoのドキュメントを参照してください。

要件

GitLab GeoをGitLab Helmチャートで使用するには、次の要件を満たす必要があります:

• 外部PostgreSQLサービスの使用。チャートに含まれるPostgresSQLは外部ネットワークに公開されておらず、レプリケーションに必要なWALサポートがないため。
• 提供されるデータベースは、以下をサポートする必要があります:
  • レプリケーションをサポートします。
  • プライマリデータベースは、プライマリサイト、およびすべてのセカンダリデータベースノード（レプリケーション用）から到達可能である必要があります。
  • セカンダリデータベースは、セカンダリサイトからのみ到達可能である必要があります。
  • プライマリおよびセカンダリデータベースノード間のSSLをサポートします。
• プライマリサイトは、すべてのセカンダリサイトからHTTP(S)経由で到達可能である必要があります。セカンダリサイトは、プライマリサイトからHTTP(S)経由でアクセス可能である必要があります。
• 要件の完全なリストについては、Geoの実行に関する要件を参照してください。

概要

このガイドでは、Linuxパッケージを使用して作成された2つのデータベースノードを使用し、必要なPostgreSQLサービスのみを設定し、GitLab Helmチャートの2つのデプロイを使用します。これは、必要な_最小限_の設定であることを目的としています。このドキュメントには、アプリケーションからデータベースへのSSL、他のデータベースプロバイダーのサポート、またはセカンダリサイトをプライマリにプロモートすることは含まれていません。

以下の概要は、順番に従う必要があります:

1. Linuxパッケージデータベースノードを設定する
2. Kubernetesクラスタリングを設定する
3. 情報を収集する
4. プライマリデータベースを設定する
5. Geoプライマリサイトとしてチャートをデプロイする
6. Geoプライマリサイトを設定する
7. セカンダリデータベースを設定する
8. プライマリサイトからセカンダリサイトにシークレットをコピーする
9. Geoセカンダリサイトとしてチャートをデプロイする
10. プライマリ経由でセカンダリGeoサイトを追加する
11. 運用ステータスを確認する
12. セカンダリサイトに個別のURLを設定する（オプション）
13. レジストリ
14. Cert-managerと統合URL

Linuxパッケージデータベースノードを設定する

このプロセスでは、2つのノードが必要です。1つはプライマリデータベースノード、もう1つはセカンダリデータベースノードです。オンプレミスまたはクラウドプロバイダーから、マシンインフラストラクチャの任意のプロバイダーを使用できます。

通信が必要になることに注意してください:

• レプリケーションのための2つのデータベースノード間。
• 各データベースノードとそのそれぞれのKubernetesデプロイ間:
  • プライマリは、TCPポート5432を公開する必要があります。
  • セカンダリは、TCPポート5432と5431を公開する必要があります。

Linuxパッケージでサポートされているオペレーティングシステムをインストールし、Linuxパッケージをインストールします。インストール時にEXTERNAL_URL環境変数を指定しないでください。パッケージを再設定する前に、最小限の設定ファイルを提供します。

オペレーティングシステムとGitLabパッケージをインストールしたら、使用するサービスの設定を作成できます。その前に、情報を収集する必要があります。

Kubernetesクラスタリングを設定する

このプロセスでは、2つのKubernetesクラスタリングを使用する必要があります。これらは、オンプレミスまたはクラウドプロバイダーから、任意のプロバイダーからのものでかまいません。

通信が必要になることに注意してください:

• それぞれのデータベースノードへ:
  • プライマリはTCP 5432へ送信。
  • セカンダリはTCP 5432と5431へ送信。
• HTTPS経由の両方のKubernetes Ingress間。

プロビジョニングされる各クラスタリングには、以下が必要です:

• これらのチャートのベースラインインストールをサポートするのに十分なリソース。
• 永続ストレージへのアクセス:
  • 外部オブジェクトストレージを使用している場合は、MinIOは不要です。
  • 外部Gitalyを使用している場合は、Gitalyは不要です。
  • 外部Redisを使用している場合は、Redisは不要です。

情報を収集する

設定を続行するには、さまざまなソースから次の情報を収集する必要があります。これらを収集し、このドキュメントの残りの部分で使用するためのメモを作成します。

• プライマリデータベース:
  • IPアドレス
  • ホスト名（オプション）
• セカンダリデータベース:
  • IPアドレス
  • ホスト名（オプション）
• プライマリクラスタリング:
  • 外部URL
  • 内部URL
  • ノードのIPアドレス
• セカンダリクラスタリング:
  • 内部URL
  • ノードのIPアドレス
• データベースパスワード（事前にパスワードを決定する必要があります）:
  • gitlab（postgresql['sql_user_password']、global.psql.passwordで使用）
  • gitlab_geo（geo_postgresql['sql_user_password']、global.geo.psql.passwordで使用）
  • gitlab_replicator（レプリケーションに必要）
• GitLabライセンスファイル

各クラスタリングの内部URLは、すべてのクラスタリングが他のすべてのクラスタリングにリクエストできるように、クラスタリングに一意である必要があります。例:

• すべてのクラスタリングの外部URL: https://gitlab.example.com
• プライマリクラスタリングの内部URL: https://london.gitlab.example.com
• セカンダリクラスタリングの内部URL: https://shanghai.gitlab.example.com

このガイドでは、DNSのセットアップについては説明しません。

gitlabデータベースとgitlab_geoデータベースのユーザーパスワードは、ベアパスワードとPostgreSQLハッシュパスワードの2つの形式で存在する必要があります。ハッシュ形式を取得するには、Linuxパッケージインストールインスタンスの1つで次のコマンドを実行します。これにより、パスワードを入力して確認するように求められた後、メモするための適切なハッシュ値が出力されます。

1. gitlab-ctl pg-password-md5 gitlab
2. gitlab-ctl pg-password-md5 gitlab_geo

プライマリデータベースを設定する

このセクションは、プライマリLinuxパッケージインストールデータベースノードで実行されます。

プライマリデータベースノードのLinuxパッケージインストールの設定を構成するには、この設定例から作業を開始します:

### Geo Primary
external_url 'http://gitlab.example.com'
roles ['geo_primary_role']
# The unique identifier for the Geo node.
gitlab_rails['geo_node_name'] = 'London Office'
gitlab_rails['auto_migrate'] = false
## turn off everything but the DB
sidekiq['enable']=false
puma['enable']=false
gitlab_workhorse['enable']=false
nginx['enable']=false
geo_logcursor['enable']=false
gitaly['enable']=false
redis['enable']=false
gitlab_kas['enable']=false
prometheus_monitoring['enable'] = false
## Configure the DB for network
postgresql['enable'] = true
postgresql['listen_address'] = '0.0.0.0'
postgresql['sql_user_password'] = 'gitlab_user_password_hash'
# !! CAUTION !!
# This list of CIDR addresses should be customized
# - primary application deployment
# - secondary database node(s)
postgresql['md5_auth_cidr_addresses'] = ['0.0.0.0/0']

いくつかのアイテムを置き換える必要があります:

• external_urlは、プライマリサイトのホスト名を反映するように更新する必要があります。
• gitlab_rails['geo_node_name']は、サイトの一意の名前に置き換える必要があります。共通設定の名前フィールドを参照してください。
• gitlab_user_password_hashは、gitlabパスワードのハッシュ形式に置き換える必要があります。
• postgresql['md5_auth_cidr_addresses']は、明示的なIPアドレスのリスト、またはクラスレスドメイン間ルーティング表記のアドレスブロックに更新できます。

md5_auth_cidr_addressesは、[ '127.0.0.1/24', '10.41.0.0/16']の形式である必要があります。Linuxパッケージの自動化はこれを使用して接続するため、このリストに127.0.0.1を含めることが重要です。このリストのアドレスには、セカンダリデータベースのIPアドレス（ホスト名ではない）と、プライマリKubernetesクラスタリングのすべてのノードが含まれている必要があります。これは['0.0.0.0/0']として残す_こと_もできますが、ベストプラクティスではありません。

上記の設定を準備した後:

1. コンテンツを/etc/gitlab/gitlab.rbに配置します

2. gitlab-ctl reconfigureを実行します。TCPでリッスンしていないサービスに関して問題が発生した場合は、gitlab-ctl restart postgresqlで直接再起動してみてください。

3. gitlab-ctl set-replication-passwordを実行して、gitlab_replicatorユーザーのパスワードを設定します。

4. プライマリデータベースノードの公開証明書を取得します。これは、セカンダリデータベースがレプリケーションできるようにするために必要です（この出力を保存します）:

   cat ~gitlab-psql/data/server.crt

Geoプライマリサイトとしてチャートをデプロイする

このセクションは、プライマリサイトのKubernetesクラスタリングで実行されます。

このチャートをGeoプライマリとしてデプロイするには、この設定例から開始します:

1. チャートが消費するデータベースパスワードを含むシークレットを作成します。以下のPASSWORDを、gitlabデータベースユーザーのパスワードに置き換えます:

   kubectl --namespace gitlab create secret generic geo --from-literal=postgresql-password=PASSWORD

2. 設定例に基づいてprimary.yamlファイルを作成し、正しい値を反映するように設定を更新します:

   ### Geo Primary
   global:
     # See docs.gitlab.com/charts/charts/globals
     # Configure host & domain
     hosts:
       domain: example.com
       # optionally configure a static IP for the default LoadBalancer
       # externalIP:
       # optionally configure a static IP for the Geo LoadBalancer
       # externalGeoIP:
     # configure DB connection
     psql:
       host: geo-1.db.example.com
       port: 5432
       password:
         secret: geo
         key: postgresql-password
     # configure geo (primary)
     geo:
       nodeName: London Office
       enabled: true
       role: primary
   # configure Geo Nginx Controller for internal Geo site traffic
   nginx-ingress-geo:
     enabled: true
   gitlab:
     webservice:
       # Use the Geo NGINX controller.
       ingress:
         useGeoClass: true
       # Configure an Ingress for internal Geo traffic
       extraIngress:
         enabled: true
         hostname: gitlab.london.example.com
         useGeoClass: true
   # External DB, disable
   postgresql:
     install: false

   • global.hosts.domain
   • global.psql.host
   • global.geo.nodeNameは、管理者エリアのGeoサイトの名前フィールドと一致する必要があります
   • Geoトラフィックがセカンダリから転送されるようにIngressコントローラーを有効にするには、nginx-ingress-geo.enabledを設定します。
   • GeoトラフィックのプライマリGeoサイトのgitlab.webserviceIngressを設定します。
   • 次のような追加の設定も行います:
     • SSL/TLSの設定
     • 外部Redisの使用
     • 外部オブジェクトストレージを使用

3. この設定を使用してチャートをデプロイします:

   helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f primary.yaml

   これは、gitlabネームスペースを使用していることを前提としています。別のネームスペースを使用する場合は、このドキュメントの残りの部分全体で--namespace gitlabでも置き換える必要があります。

4. デプロイが完了し、アプリケーションがオンラインになるまで待ちます。アプリケーションに到達できるようになったら、ログインします。

5. GitLabにサインインし、GitLabサブスクリプションをアクティブ化します。

   この手順は、Geoが機能するために必要です。

Geoプライマリサイトを設定する

これで、チャートがデプロイされ、ライセンスがアップロードされたので、これをプライマリサイトとして設定できます。これは、Toolboxポッドを介して行います。

1. Toolboxポッドを探す

   kubectl --namespace gitlab get pods -lapp=toolbox

2. kubectl execでgitlab-rake geo:set_primary_nodeを実行します:

   kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake geo:set_primary_node

3. Railsランナーコマンドを使用して、プライマリサイトの内部URLを設定します。https://primary.gitlab.example.comを実際の内部URLに置き換えます:

   kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rails runner "GeoNode.primary_node.update!(internal_url: 'https://primary.gitlab.example.com')"

4. Geo設定のステータスを確認します:

   kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake gitlab:geo:check

   以下のような出力が表示されます:

   WARNING: This version of GitLab depends on gitlab-shell 10.2.0, but you're running Unknown. Please update gitlab-shell.
   Checking Geo ...
   
   GitLab Geo is available ... yes
   GitLab Geo is enabled ... yes
   GitLab Geo secondary database is correctly configured ... not a secondary node
   Database replication enabled? ... not a secondary node
   Database replication working? ... not a secondary node
   GitLab Geo HTTP(S) connectivity ... not a secondary node
   HTTP/HTTPS repository cloning is enabled ... yes
   Machine clock is synchronized ... Exception: getaddrinfo: Servname not supported for ai_socktype
   Git user has default SSH configuration? ... yes
   OpenSSH configured to use AuthorizedKeysCommand ... no
     Reason:
     Cannot find OpenSSH configuration file at: /assets/sshd_config
     Try fixing it:
     If you are not using our official docker containers,
     make sure you have OpenSSH server installed and configured correctly on this system
     For more information see:
     doc/administration/operations/fast_ssh_key_lookup.md
   GitLab configured to disable writing to authorized_keys file ... yes
   GitLab configured to store new projects in hashed storage? ... yes
   All projects are in hashed storage? ... yes
   
   Checking Geo ... Finished

   • Kubernetesコンテナはホストクロックにアクセスできないため、Exception: getaddrinfo: Servname not supported for ai_socktypeを心配しないでください。これは問題ありません。
   • OpenSSH configured to use AuthorizedKeysCommand ... no が予想されます。このRakeタスクはローカルのSSHサーバーをチェックしていますが、実際にはgitlab-shellチャート内に存在し、別の場所にデプロイされており、すでに適切に設定されています。

セカンダリデータベースを設定する

このセクションは、セカンダリLinuxパッケージインストールデータベースノードで実行されます。

セカンダリデータベースノードのLinuxパッケージインストールの設定を構成するには、この設定例から作業を開始します:

### Geo Secondary
# external_url must match the Primary cluster's external_url
external_url 'http://gitlab.example.com'
roles ['geo_secondary_role']
gitlab_rails['enable'] = true
# The unique identifier for the Geo node.
gitlab_rails['geo_node_name'] = 'Shanghai Office'
gitlab_rails['auto_migrate'] = false
geo_secondary['auto_migrate'] = false
## turn off everything but the DB
sidekiq['enable']=false
puma['enable']=false
gitlab_workhorse['enable']=false
nginx['enable']=false
geo_logcursor['enable']=false
gitaly['enable']=false
redis['enable']=false
prometheus_monitoring['enable'] = false
gitlab_kas['enable']=false
## Configure the DBs for network
postgresql['enable'] = true
postgresql['listen_address'] = '0.0.0.0'
postgresql['sql_user_password'] = 'gitlab_user_password_hash'
# !! CAUTION !!
# This list of CIDR addresses should be customized
# - secondary application deployment
# - secondary database node(s)
postgresql['md5_auth_cidr_addresses'] = ['0.0.0.0/0']
geo_postgresql['listen_address'] = '0.0.0.0'
geo_postgresql['sql_user_password'] = 'gitlab_geo_user_password_hash'
# !! CAUTION !!
# This list of CIDR addresses should be customized
# - secondary application deployment
# - secondary database node(s)
geo_postgresql['md5_auth_cidr_addresses'] = ['0.0.0.0/0']
gitlab_rails['db_password']='gitlab_user_password'

いくつかのアイテムを置き換える必要があります:

• gitlab_rails['geo_node_name']は、サイトの一意の名前に置き換える必要があります。共通設定の名前フィールドを参照してください。
• gitlab_user_password_hashは、gitlabパスワードのハッシュ形式に置き換える必要があります。
• postgresql['md5_auth_cidr_addresses']は、明示的なIPアドレスのリスト、またはクラスレスドメイン間ルーティング表記のアドレスブロックに更新する必要があります。
• gitlab_geo_user_password_hashは、gitlab_geoパスワードのハッシュ形式に置き換える必要があります。
• geo_postgresql['md5_auth_cidr_addresses']は、明示的なIPアドレスのリスト、またはクラスレスドメイン間ルーティング表記のアドレスブロックに更新する必要があります。
• gitlab_user_passwordを更新する必要があり、LinuxパッケージがPostgreSQL設定を自動化できるようにするためにここで使用されます。

md5_auth_cidr_addressesは、[ '127.0.0.1/24', '10.41.0.0/16']の形式である必要があります。Linuxパッケージの自動化はこれを使用して接続するため、このリストに127.0.0.1を含めることが重要です。このリストのアドレスには、セカンダリKubernetesクラスタリングのすべてのノードのIPアドレスが含まれている必要があります。これは['0.0.0.0/0']として残す_こと_もできますが、ベストプラクティスではありません。

上記の設定を準備した後:

1. プライマリサイトのPostgreSQLノードへのTCP接続を確認します:

   openssl s_client -connect <primary_node_ip>:5432 </dev/null

   出力は次のようになります:

   CONNECTED(00000003)
   write:errno=0

   この手順が失敗した場合は、間違ったIPアドレスを使用しているか、ファイアウォールがサーバーへのアクセスを妨げている可能性があります。IPアドレスを確認し、パブリックアドレスとプライベートアドレスの違いに注意し、ファイアウォールが存在する場合は、セカンダリ PostgreSQLノードがTCPポート5432でプライマリ PostgreSQLノードへの接続を許可されていることを確認します。

2. コンテンツを/etc/gitlab/gitlab.rbに配置します

3. gitlab-ctl reconfigureを実行します。TCPでリッスンしていないサービスに関して問題が発生した場合は、gitlab-ctl restart postgresqlで直接再起動してみてください。

4. プライマリPostgreSQLノードの証明書コンテンツを上記のprimary.crtに配置します

5. セカンダリ PostgreSQLノードで、PostgreSQL TLSの検証を設定します:

   primary.crtファイルをインストールします:

   install \
      -D \
      -o gitlab-psql \
      -g gitlab-psql \
      -m 0400 \
      -T primary.crt ~gitlab-psql/.postgresql/root.crt

   PostgreSQLは、TLS接続を検証する際に、その正確な証明書のみを認識するようになります。証明書をレプリケーションできるのは、秘密キーへのアクセス権を持つユーザーのみです。秘密キーは、プライマリPostgreSQLノードにのみ存在します。

6. gitlab-psqlユーザーがプライマリサイトのPostgreSQL（デフォルトのLinuxパッケージデータベース名はgitlabhq_production）に接続できることをテストします:

   sudo \
      -u gitlab-psql /opt/gitlab/embedded/bin/psql \
      --list \
      -U gitlab_replicator \
      -d "dbname=gitlabhq_production sslmode=verify-ca" \
      -W \
      -h <primary_database_node_ip>

   gitlab_replicatorユーザーに対して以前に収集したパスワードのプロンプトが表示されたら、入力します。すべてが正しく動作していれば、プライマリ PostgreSQLノードのデータベースのリストが表示されるはずです。

   ここで接続に失敗した場合は、TLSの設定が間違っていることを示しています。プライマリ PostgreSQLノードの~gitlab-psql/data/server.crtの内容が、セカンダリ PostgreSQLノードの~gitlab-psql/.postgresql/root.crtの内容と一致していることを確認してください。

7. データベースをレプリケーションします。PRIMARY_DATABASE_HOSTをプライマリPostgreSQLノードのIPアドレスまたはホスト名に置き換えます:

   gitlab-ctl replicate-geo-database --slot-name=geo_2 --host=PRIMARY_DATABASE_HOST --sslmode=verify-ca

8. レプリケーションが完了したら、pg_hba.confがセカンダリPostgreSQLノードに対して正しいことを確認するために、Linuxパッケージをもう一度設定する必要があります:

   gitlab-ctl reconfigure

プライマリサイトからセカンダリサイトにシークレットをコピーします

次に、プライマリサイトのKubernetesデプロイメントからセカンダリサイトのKubernetesデプロイメントに、いくつかのシークレットをコピーします:

• gitlab-geo-gitlab-shell-host-keys
• gitlab-geo-rails-secret
• レジストリのレプリケーションが有効になっている場合は、gitlab-geo-registry-secret。

1. kubectlコンテキストをプライマリのコンテキストに変更します。

2. プライマリデプロイメントからこれらのシークレットを収集します:

   kubectl get --namespace gitlab -o yaml secret gitlab-geo-gitlab-shell-host-keys > ssh-host-keys.yaml
   kubectl get --namespace gitlab -o yaml secret gitlab-geo-rails-secret > rails-secrets.yaml
   kubectl get --namespace gitlab -o yaml secret gitlab-geo-registry-secret > registry-secrets.yaml

3. kubectlコンテキストをセカンダリのコンテキストに変更します。

4. これらのシークレットを適用します:

   kubectl --namespace gitlab apply -f ssh-host-keys.yaml
   kubectl --namespace gitlab apply -f rails-secrets.yaml
   kubectl --namespace gitlab apply -f registry-secrets.yaml

次に、データベースのパスワードを含むシークレットを作成します。以下のパスワードを適切な値に置き換えます:

kubectl --namespace gitlab create secret generic geo \
   --from-literal=postgresql-password=gitlab_user_password \
   --from-literal=geo-postgresql-password=gitlab_geo_user_password

Geoセカンダリサイトとしてチャートをデプロイします

このセクションは、セカンダリサイトのKubernetesクラスターで実行されます。

このチャートをGeoセカンダリサイトとしてデプロイするには、この設定例から開始します。

1. 設定例に基づいてsecondary.yamlファイルを作成し、正しい値を反映するように設定を更新します:

   ## Geo Secondary
   global:
     # See docs.gitlab.com/charts/charts/globals
     # Configure host & domain
     hosts:
       domain: shanghai.example.com
       # use a unified URL (same external URL as the primary site)
       gitlab:
         name: gitlab.example.com
     # configure DB connection
     psql:
       host: geo-2.db.example.com
       port: 5432
       password:
         secret: geo
         key: postgresql-password
     # configure geo (secondary)
     geo:
       enabled: true
       role: secondary
       nodeName: Shanghai Office
       psql:
         host: geo-2.db.example.com
         port: 5431
         password:
           secret: geo
           key: geo-postgresql-password
   # Optional for secondary sites: Configure Geo Nginx Controller for internal Geo site traffic.
   # nginx-ingress-geo:
   #   enabled: true
   gitlab:
     webservice:
       # Configure a Ingress for internal Geo traffic
       extraIngress:
         enabled: true
         hostname: shanghai.gitlab.example.com
   # External DB, disable
   postgresql:
     install: false

   • global.hosts.domain
   • global.psql.host
   • global.geo.psql.host
   • global.geo.nodeNameは、管理者エリアのGeoサイトの名前フィールドと一致する必要があります
   • nginx-ingress-geo.enabledを設定すると、内部Geoトラフィック用に事前設定されたIngressコントローラーを有効にできます。これにより、サイトをプライマリにプロモートすることが容易になります。。
   • セカンダリサイトの内部URLに送信されるトラフィックを処理するために、gitlab.webserviceの追加のIngressを設定します。
   • 次のような追加の設定も行います:
     • SSL/TLSの設定
     • 外部Redisの使用
     • 外部オブジェクトストレージを使用
   • 外部データベースの場合、global.psql.hostはセカンダリの読み取り専用レプリカデータベースであり、global.geo.psql.hostはGeoトラッキングデータベースです

2. この設定を使用してチャートをデプロイします:

   helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f secondary.yaml

3. デプロイが完了し、アプリケーションがオンラインになるまで待ちます。

プライマリを介してGeoセカンダリサイトを追加

両方のデータベースが設定され、アプリケーションがデプロイされたので、プライマリサイトにセカンダリサイトが存在することを通知する必要があります:

1. プライマリサイトにアクセスします。
2. 左側のサイドバーの下部で、管理者エリアを選択します。
3. Geo > サイトを追加を選択します。
4. セカンダリサイトを追加します。URLには、完全なGitLab URLを使用します。
5. セカンダリサイトのglobal.geo.nodeNameを使用して名前を入力します。これらの値は常に文字どおり完全に一致する必要があります。
6. 内部URL（例: https://shanghai.gitlab.example.com）を入力します。
7. オプションで、どのグループまたはストレージシャードをセカンダリサイトでレプリケーションするかを選択します。すべてをレプリケーションするには、空白のままにします。
8. ノードを追加を選択します。

セカンダリサイトが管理パネルに追加されると、プライマリサイトから不足しているデータのレプリケーションが自動的に開始されます。このプロセスは「バックフィル」と呼ばれます。一方、プライマリサイトは各セカンダリサイトに変更を通知し始め、セカンダリサイトはそれらの変更を迅速にレプリケーションできます。

オペレーションステータスを確認

最終的な手順は、Toolboxポッドを介して、完全に設定されたらセカンダリサイトのGeo設定を再確認することです。

1. Toolboxポッドを探します:

   kubectl --namespace gitlab get pods -lapp=toolbox

2. kubectl execを使用してポッドにアタッチします:

   kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- bash -l

3. Geo設定のステータスを確認します:

   gitlab-rake gitlab:geo:check

   以下のような出力が表示されます:

   WARNING: This version of GitLab depends on gitlab-shell 10.2.0, but you're running Unknown. Please update gitlab-shell.
   Checking Geo ...
   
   GitLab Geo is available ... yes
   GitLab Geo is enabled ... yes
   GitLab Geo secondary database is correctly configured ... yes
   Database replication enabled? ... yes
   Database replication working? ... yes
   GitLab Geo HTTP(S) connectivity ...
   * Can connect to the primary node ... yes
   HTTP/HTTPS repository cloning is enabled ... yes
   Machine clock is synchronized ... Exception: getaddrinfo: Servname not supported for ai_socktype
   Git user has default SSH configuration? ... yes
   OpenSSH configured to use AuthorizedKeysCommand ... no
     Reason:
     Cannot find OpenSSH configuration file at: /assets/sshd_config
     Try fixing it:
     If you are not using our official docker containers,
     make sure you have OpenSSH server installed and configured correctly on this system
     For more information see:
     doc/administration/operations/fast_ssh_key_lookup.md
   GitLab configured to disable writing to authorized_keys file ... yes
   GitLab configured to store new projects in hashed storage? ... yes
   All projects are in hashed storage? ... yes
   
   Checking Geo ... Finished

   • Exception: getaddrinfo: Servname not supported for ai_socktypeについては、Kubernetesコンテナーはホストクロックにアクセスできないため、心配しないでください。これは問題ありません。
   • OpenSSH configured to use AuthorizedKeysCommand ... no が予想されます。このRakeタスクはローカルのSSHサーバーをチェックしていますが、実際にはgitlab-shellチャート内に存在し、別の場所にデプロイされており、すでに適切に設定されています。

セカンダリサイトの個別のURLを設定します（オプション）

プライマリサイトとセカンダリサイトの単一の統合URLは、通常、ユーザーにとってより便利です。たとえば、次のことができます:

• 両方のサイトをロードバランサーの背後に配置します。
• クラウドプロバイダーのDNS機能を使用して、ユーザーを最寄りのサイトにルーティングします。

場合によっては、ユーザーがどのサイトにアクセスするかを制御できるようにすることがあります。この目的のために、セカンダリGeoサイトを設定して、一意の外部URLを使用できます。例:

• プライマリクラスタの外部URL: https://gitlab.example.com
• セカンダリクラスタの外部URL: https://shanghai.gitlab.example.com

1. secondary.yamlを編集し、セカンダリクラスタの外部URLを更新して、webserviceチャートがそれらのリクエストを処理できるようにします:

   global:
     # See docs.gitlab.com/charts/charts/globals
     # Configure host & domain
     hosts:
       domain: example.com
       # use a unique external URL for the secondary site
       gitlab:
         name: shanghai.gitlab.example.com

2. GitLabでセカンダリサイトの外部URLを更新して、必要な場所でURLを使用できるようにします:

   • 管理者UIの使用:
     1. プライマリサイトにアクセスします。
     2. 左側のサイドバーの下部で、管理者エリアを選択します。
     3. Geo > サイトを選択します。
     4. 鉛筆アイコンを選択して、セカンダリサイトを編集します。
     5. 外部URL（例: https://shanghai.gitlab.example.com）を編集します。
     6. 変更を保存を選択します。

3. セカンダリサイトのチャートを再デプロイします:

   helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f secondary.yaml

4. デプロイが完了し、アプリケーションがオンラインになるまで待ちます。

レジストリ

セカンダリレジストリをプライマリレジストリと同期するには、レジストリレプリケーションを、通知シークレットを使用して設定できます。

Cert-managerと統合URL

Geoの統合URLは、地理位置情報対応ルーティング（たとえば、Amazon Route 53またはGoogleクラウドプロバイダーDNSを使用）でよく使用されます。これにより、ドメイン名が管理下にあることを検証するために、HTTP01 Challengeを使用すると問題が発生する可能性があります。

1つのGeoサイトの証明書をリクエストすると、Let’s Encryptは、DNS名をリクエストしているGeoサイトに解決する必要があります。DNSが別のGeoサイトに解決される場合、統合URLの証明書は発行または更新されません。

cert-managerで確実に証明書を作成して更新するには、統合ホスト名をGeoサイトのIPアドレスに解決することがわかっているサーバーにChallengeネームサーバーを設定するか、DNS01 Issuerを設定します。