複数のノード用のGeo

このドキュメントでは、マルチノード構成でGeoを実行するための最小限のリファレンスアーキテクチャについて説明します。お使いのマルチノード構成が、ここで説明されているものと異なる場合は、これらの手順を必要に応じて調整できます。

このガイドは、複数のアプリケーションノード（SidekiqまたはGitLab Rails）がインストールされている場合に適用されます。外部PostgreSQLを使用した単一ノードインストールの場合、2つの単一ノードサイト（外部PostgreSQLサービスを使用）のGeoのセットアップに従い、他の外部サービスを使用する場合は、設定を調整してください。

アーキテクチャの概要

diagram source - GitLab team members only（図の出典 - GitLabチームメンバーのみ）

トポロジ図は、プライマリとセカンダリのGeoサイトが、専用の仮想ネットワーキングとプライベートIPアドレスを使用して、2つの異なる場所に配置されていることを前提としています。ネットワークは、1つの地理的な場所にあるすべてのマシンが、プライベートIPアドレスを使用して相互に通信できるように構成されています。指定されたIPアドレスは例であり、デプロイのネットワークトポロジによっては異なる場合があります。

2つのGeoサイトにアクセスする唯一の外部方法は、前の例ではgitlab.us.example.comとgitlab.eu.example.comのHTTPS経由です。

マルチノード用のRedisとPostgreSQL

PostgreSQLとRedisのこの設定のセットアップにはさらに複雑さが伴うため、このGeoのマルチノードドキュメントでは説明されていません。

Linuxパッケージを使用してマルチノードのPostgreSQLクラスターおよびRedisクラスターをセットアップする方法の詳細については、以下を参照してください:

• Geoマルチノードデータベースレプリケーション
• Redisマルチノードドキュメント

前提要件: 独立して動作する2つのGitLabマルチノードサイト

1つのGitLabサイトがGeoのプライマリサイトとして機能します。これをセットアップするには、GitLabリファレンスアーキテクチャドキュメントを使用してください。Geoサイトごとに異なるリファレンスアーキテクチャのサイズを使用できます。既に使用中の動作中のGitLabインスタンスがある場合は、プライマリサイトとして使用できます。

2番目のGitLabサイトは、Geoのセカンダリサイトとして機能します。繰り返しますが、これをセットアップするには、GitLabリファレンスアーキテクチャドキュメントを使用してください。サインインしてテストすることをお勧めします。ただし、データはプライマリサイトからレプリケーションするプロセスの一部として消去されることに注意してください。

GitLabサイトをGeoのプライマリサイトとして設定する

次の手順では、GitLabサイトがGeoのプライマリサイトとして機能するようにします。

ステップ1: プライマリフロントエンドノードを設定する

1. /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>'
   
   ##
   ## Disable automatic migrations
   ##
   gitlab_rails['auto_migrate'] = false

これらの変更を加えた後、変更を有効にするためにGitLabを再構成します。

ステップ2: サイトをプライマリサイトとして定義する

1. フロントエンドノードのいずれかで、次のコマンドを実行します:

   sudo gitlab-ctl set-geo-primary-node

他のGitLabサイトをGeo セカンダリサイトとして設定する

セカンダリサイトは、他のGitLabマルチノードサイトと同様ですが、3つの大きな違いがあります:

• メインのPostgreSQLデータベースは、GeoのプライマリサイトのPostgreSQLデータベースの読み取り専用のレプリカです。
• 各Geo セカンダリサイトには、追加のPostgreSQLデータベース（「Geoトラッキングデータベース」と呼ばれる）があり、さまざまなリソースのレプリケーションと検証の状態を追跡します。
• 追加のGitLabサービスgeo-logcursorがあります

したがって、マルチノードコンポーネントを1つずつセットアップし、一般的なマルチノードセットアップからの逸脱を含めます。ただし、Geoセットアップの一部ではないかのように、最初に真新しいGitLabサイトを設定することを強くお勧めします。これにより、動作中のGitLabサイトであることを確認できます。その後でのみ、Geo セカンダリサイトとして使用するために変更する必要があります。これにより、Geoのセットアップの問題を、関係のないマルチノード設定の問題から分離できます。

ステップ1: Geo セカンダリサイトでRedisおよびGitalyサービスを設定する

次のサービスを、Geo以外のマルチノードドキュメントを使用して再度設定します:

• GitLabのRedisの設定（マルチノードの場合）。
• Geoのプライマリサイトから同期されたデータを保存するGitaly。

ステップ2: Geo セカンダリサイトでGeoトラッキングデータベースを設定する

GeoトラッキングデータベースはマルチノードのPostgreSQLクラスターでは実行できません。トラッキングデータベース用のPatroniクラスターの設定を参照してください。

次のように、単一ノードでGeoトラッキングデータベースを実行できます:

1. GitLabアプリケーションがトラッキングデータベースへのアクセスに使用するデータベースユーザー名の目的のパスワードのMD5ハッシュを生成します:

   ユーザー名（gitlab_geo（デフォルト）はハッシュに組み込まれています。

   gitlab-ctl pg-password-md5 gitlab_geo
   # Enter password: <your_tracking_db_password_here>
   # Confirm password: <your_tracking_db_password_here>
   # fca0b89a972d69f00eb3ec98a5838484

   次の手順で、このハッシュを使用して<tracking_database_password_md5_hash>に入力します。

2. Geoトラッキングデータベースの実行を目的とするマシンで、/etc/gitlab/gitlab.rbに以下を追加します:

   ##
   ## Enable the Geo secondary tracking database
   ##
   geo_postgresql['enable'] = true
   geo_postgresql['listen_address'] = '<ip_address_of_this_host>'
   geo_postgresql['sql_user_password'] = '<tracking_database_password_md5_hash>'
   
   ##
   ## Configure PostgreSQL connection to the replica database
   ##
   geo_postgresql['md5_auth_cidr_addresses'] = ['<replica_database_ip>/32']
   gitlab_rails['db_host'] = '<replica_database_ip>'
   
   # Prevent reconfigure from attempting to run migrations on the replica database
   gitlab_rails['auto_migrate'] = false

3. GitLabのアップグレード時に意図しないダウンタイムが発生しないように、PostgreSQLの自動アップグレードをオプトアウトします。GeoでPostgreSQLをアップグレードする際の既知の注意点に注意してください。特に大規模な環境では、PostgreSQLのアップグレードは慎重に計画し、実行する必要があります。その結果、今後、PostgreSQLのアップグレードが定期的なメンテナンスアクティビティーの一部であることを確認してください。

これらの変更を加えた後、変更を有効にするためにGitLabを再構成します。

外部PostgreSQLインスタンスを使用している場合は、外部PostgreSQLインスタンスを使用したGeoも参照してください。

ステップ3: PostgreSQLストリーミングレプリケーションを設定する

Geoデータベースレプリケーションの手順に従います。

外部PostgreSQLインスタンスを使用している場合は、外部PostgreSQLインスタンスを使用したGeoも参照してください。

ストリーミングレプリケーションを有効にすると、gitlab-rake db:migrate:status:geoセカンダリサイトの設定が完了するまで失敗します。具体的には、Geoの設定 - ステップ3。セカンダリサイトを追加します。

ステップ4: Geo セカンダリサイトでフロントエンドアプリケーションノードを設定する

最小限のアーキテクチャの概要では、GitLabアプリケーションサービスを実行している2台のマシンがあります。これらのサービスは、設定で選択的に有効になります。

リファレンスアーキテクチャに概説されている関連する手順に従ってGitLab Railsアプリケーションノードを設定し、次の変更を加えます:

1. Geo セカンダリサイトの各アプリケーションノードで/etc/gitlab/gitlab.rbを編集し、以下を追加します:

   ##
   ## Enable GitLab application services. The application_role enables many services.
   ## Alternatively, you can choose to enable or disable specific services on
   ## different nodes to aid in horizontal scaling and separation of concerns.
   ##
   roles ['application_role']
   
   ## `application_role` already enables this. You only need this line if
   ## you selectively enable individual services that depend on Rails, like
   ## `puma`, `sidekiq`, `geo-logcursor`, and so on.
   gitlab_rails['enable'] = true
   
   ##
   ## Enable Geo Log Cursor service
   ##
   geo_logcursor['enable'] = true
   
   ##
   ## 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>'
   
   ##
   ## Disable automatic migrations
   ##
   gitlab_rails['auto_migrate'] = false
   
   ##
   ## Configure the connection to the tracking database
   ##
   geo_secondary['enable'] = true
   geo_secondary['db_host'] = '<geo_tracking_db_host>'
   geo_secondary['db_password'] = '<geo_tracking_db_password>'
   
   ##
   ## Configure connection to the streaming replica database, if you haven't
   ## already
   ##
   gitlab_rails['db_host'] = '<replica_database_host>'
   gitlab_rails['db_password'] = '<replica_database_password>'
   
   ##
   ## Configure connection to Redis, if you haven't already
   ##
   gitlab_rails['redis_host'] = '<redis_host>'
   gitlab_rails['redis_password'] = '<redis_password>'
   
   ##
   ## If you are using custom users not managed by Omnibus, you need to specify
   ## UIDs and GIDs like below, and ensure they match between nodes in a
   ## cluster to avoid permissions issues
   ##
   user['uid'] = 9000
   user['gid'] = 9000
   web_server['uid'] = 9001
   web_server['gid'] = 9001
   registry['uid'] = 9002
   registry['gid'] = 9002

これらの変更を加えた後、変更を有効にするためにGitLabを再構成します。

アーキテクチャの概要トポロジでは、次のGitLabサービスが「フロントエンド」ノードで有効になっています:

• geo-logcursor
• gitlab-pages
• gitlab-workhorse
• logrotate
• nginx
• registry
• remote-syslog
• sidekiq
• puma

sudo gitlab-ctl statusをフロントエンドアプリケーションノードで実行して、これらのサービスが存在することを確認します。

ステップ5: Geo セカンダリサイト用のロードバランサーをセットアップする

最小限のアーキテクチャの概要は、アプリケーションノードへのトラフィックをルーティングするために、地理的な場所ごとにロードバランサーを示しています。

詳細については、複数のノードを持つGitLabのロードバランサーを参照してください。

ステップ6: Geo セカンダリサイトでバックエンドアプリケーションノードを設定する

最小限のアーキテクチャの概要は、すべてのアプリケーションサービスが同じマシン上で一緒に実行されていることを示しています。ただし、複数のノードの場合、すべてのサービスを個別に実行することを強くお勧めします。

たとえば、Sidekiqノードは、以前にドキュメント化されたフロントエンドアプリケーションノードと同様に設定できますが、sidekiqサービスのみを実行するように変更されています:

1. Geo セカンダリサイトの各Sidekiqノードで/etc/gitlab/gitlab.rbを編集し、以下を追加します:

   ##
   ## Enable the Sidekiq service
   ##
   sidekiq['enable'] = true
   gitlab_rails['enable'] = true
   
   ##
   ## 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>'
   
   ##
   ## Disable automatic migrations
   ##
   gitlab_rails['auto_migrate'] = false
   
   ##
   ## Configure the connection to the tracking database
   ##
   geo_secondary['enable'] = true
   geo_secondary['db_host'] = '<geo_tracking_db_host>'
   geo_secondary['db_password'] = '<geo_tracking_db_password>'
   
   ##
   ## Configure connection to the streaming replica database, if you haven't
   ## already
   ##
   gitlab_rails['db_host'] = '<replica_database_host>'
   gitlab_rails['db_password'] = '<replica_database_password>'
   
   ##
   ## Configure connection to Redis, if you haven't already
   ##
   gitlab_rails['redis_host'] = '<redis_host>'
   gitlab_rails['redis_password'] = '<redis_password>'
   
   ##
   ## If you are using custom users not managed by Omnibus, you need to specify
   ## UIDs and GIDs like below, and ensure they match between nodes in a
   ## cluster to avoid permissions issues
   ##
   user['uid'] = 9000
   user['gid'] = 9000
   web_server['uid'] = 9001
   web_server['gid'] = 9001
   registry['uid'] = 9002
   registry['gid'] = 9002

   geo_logcursor['enable'] = trueでgeo-logcursorサービスのみを実行するようにノードを同様に設定し、sidekiq['enable'] = falseでSidekiqを無効にすることができます。

   これらのノードは、ロードバランサーにアタッチする必要はありません。

ステップ7: シークレットをコピーし、アプリケーションにセカンダリサイトを追加する

1. GitLabを設定する プライマリサイトとセカンダリサイトを設定します。