複数のノード用のGeoをセットアップする

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

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

アーキテクチャの概要

図のソース - GitLabチームメンバーのみ

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

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

マルチノードのRedisおよびPostgreSQL

PostgreSQLとRedisのこの設定をセットアップする際の追加の複雑さのため、このGeoマルチノードドキュメントでは取り上げていません。

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

• 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/administration/geo_sites/#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 セカンダリサイトには、「Geoトラッキングデータベース」と呼ばれる追加のPostgreSQLデータベースがあり、さまざまなリソースのレプリケーションおよび検証ステータスを追跡するします。
• 追加のGitLabサービスgeo-logcursorがあります。

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

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

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

• 複数のノード用のGitLab用Redisの設定。
• Geo プライマリサイトから同期されたデータを保存するGitaly。

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

GeoトラッキングデータベースはマルチノードPostgreSQLクラスターでは実行できません。トラッキング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 セカンダリサイトでフロントエンドアプリケーションノードを設定する

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

リファレンスアーキテクチャに示されている関連する手順に従って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/administration/geo_sites/#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

このノード上のRailsがPostgreSQLに接続できるように、現在のノードのIPがリードレプリカのデータベースのpostgresql['md5_auth_cidr_addresses']設定にリストされていることを確認してください。

これらの変更を行った後、変更を有効にするために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/administration/geo_sites/#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を設定して、プライマリサイトとセカンダリサイトを設定します。