- 建築概要
- 複数ノード用のRedisとPostgreSQL
- 前提条件：GitLabマルチノードクラスターが2つ稼働していること
- GitLabクラスターをプライマリノードに設定します。
- セカンダリノードの設定
複数ノードのGeo
この文書では、マルチノード構成で Geo を実行するための最小限のリファレンスアーキテクチャについて説明します。 マルチノードのセットアップが説明されているものと異なる場合は、これらの手順をニーズに合わせて変更することが可能です。
建築概要
上記のトポロジーは、プライマリと セカンダリのGeo クラスターが、プライベート IP アドレスを持つ独自の仮想ネットワーク上の 2 つの別々の場所にあることを想定しています。 ネットワークは、1 つの地理的な場所にあるすべてのマシンが、プライベート IP アドレスを使用して相互に通信できるように構成されています。 指定された IP アドレスは例であり、デプロイのネットワークトポロジーによって異なる場合があります。
つの Geo デプロイに外部からアクセスする唯一の方法は、上記の例ではgitlab.us.example.com とgitlab.eu.example.com の HTTPS です。
複数ノード用のRedisとPostgreSQL
Geoがサポートします：
- プライマリノードのRedisとPostgreSQLを複数ノードに設定。
- 複数ノード用に設定されたセカンダリノード上のRedis。
PostgreSQLとRedisに対してこの設定を行うにはさらに複雑さが伴うため、このGeoマルチノード・ドキュメントでは扱っていません。
omnibusパッケージを使用した複数ノードのPostgreSQLクラスタとRedisクラスタのセットアップの詳細については、それぞれPostgreSQLとRedisの複数ノードのドキュメントを参照してください。
前提条件：GitLabマルチノードクラスターが2つ稼働していること
一つのクラスターをプライマリノードとして使用します。GitLabのマルチノードに関するドキュメントを参考に設定してください。 すでに使用中のGitLabインスタンスがある場合は、それをプライマリとして使用することができます。
二番目のクラスターがセカンダリノードとなります。 ここでも、GitLabマルチノードのドキュメントを参考に設定してください。 ログインしてテストするのがよいでしょう。ただし、プライマリからレプリケーションする過程でデータが消去されることに注意しましょう。
GitLabクラスターをプライマリノードに設定します。
以下の手順で、GitLabクラスターをプライマリノードとして使えるようにします。
ステップ1:プライマリフロントエンドサーバの設定
-
/etc/gitlab/gitlab.rbを編集し、以下を追加してください：## ## Enable the Geo primary role ## roles ['geo_primary_role'] ## ## The unique identifier for the Geo node. ## gitlab_rails['geo_node_name'] = '<node_name_here>' ## ## Disable automatic migrations ## gitlab_rails['auto_migrate'] = false
これらの変更を行った後、変更が有効になるように GitLab を再設定します。
ステップ2：プライマリ・データベースの設定
-
/etc/gitlab/gitlab.rbを編集し、以下を追加してください：## ## Configure the Geo primary role and the PostgreSQL role ## roles ['geo_primary_role', 'postgres_role']
セカンダリノードの設定
セカンダリクラスターは他のGitLabマルチノードクラスターと似ていますが、大きな違いが2つあります：
- メインのPostgreSQLデータベースは、プライマリノードのPostgreSQLデータベースの読み取り専用のレプリカです。
- また、セカンダリクラスタには「トラッキングデータベース」と呼ばれるPostgreSQLデータベースが1つあり、さまざまなリソースの同期状態を追跡します。
そのため、マルチノードコンポーネントを1つ1つセットアップし、通常のマルチノードセットアップからの逸脱も含めて説明します。 しかし、まず新しいクラスターをGeoセットアップの一部でないかのように設定し、動作するクラスターとしてテストおよび検証できるようにすることを強くお勧めします。 その後で初めて、Geoセカンダリとして使用するために変更する必要があります。 これにより、Geoセットアップに関連する問題と関連しない問題を分けることができます。
ステップ1:セカンダリノードのRedisとGitalyサービスの設定
Geo 以外のマルチノードのドキュメントを使用して、以下のサービスを構成します：
ステップ2：セカンダリノード上のメインの読み取り専用レプリカPostgreSQLデータベースの設定
セカンダリ・データベースを プライマリ・データベースの読み取り専用レプリカとして構成します。 ガイドとして以下を使用してください。
-
GitLabアプリケーションがread-replicaデータベースにアクセスするために使用するデータベースユーザーのパスワードのMD5ハッシュを生成します：
ユーザー名（デフォルトでは
gitlab）がハッシュに組み込まれることに注意してください。gitlab-ctl pg-password-md5 gitlab # Enter password: <your_password_here> # Confirm password: <your_password_here> # fca0b89a972d69f00eb3ec98a5838484このハッシュを使って、次のステップで
<md5_hash_of_your_password>。 -
レプリカデータベースマシンで
/etc/gitlab/gitlab.rbを編集し、以下を追加します：## ## Configure the Geo secondary role and the PostgreSQL role ## roles ['geo_secondary_role', 'postgres_role'] ## ## Secondary address ## - replace '<secondary_node_ip>' with the public or VPC address of your Geo secondary node ## - replace '<tracking_database_ip>' with the public or VPC address of your Geo tracking database node ## postgresql['listen_address'] = '<secondary_node_ip>' postgresql['md5_auth_cidr_addresses'] = ['<secondary_node_ip>/32', '<tracking_database_ip>/32'] ## ## Database credentials password (defined previously in primary node) ## - replicate same values here as defined in primary node ## postgresql['sql_user_password'] = '<md5_hash_of_your_password>' gitlab_rails['db_password'] = '<your_password_here>' ## ## When running the Geo tracking database on a separate machine, disable it ## here and allow connections from the tracking database host. And ensure ## the tracking database IP is in postgresql['md5_auth_cidr_addresses'] above. ## geo_postgresql['enable'] = false ## ## Disable `geo_logcursor` service so Rails doesn't get configured here ## geo_logcursor['enable'] = false
これらの変更を行った後、変更が有効になるように GitLab を再設定します。
外部のPostgreSQLインスタンスを使用する場合は、外部のPostgreSQLインスタンスとのGeoも参照してください。
ステップ3：セカンダリノード上のトラッキングデータベースの設定
トラッキングデータベースを設定します。
-
GitLabアプリケーションがトラッキングデータベースにアクセスするために使用するデータベースユーザーのパスワードのMD5ハッシュを生成します：
ユーザー名（デフォルトでは
gitlab_geo）がハッシュに組み込まれることに注意してください。gitlab-ctl pg-password-md5 gitlab_geo # Enter password: <your_password_here> # Confirm password: <your_password_here> # fca0b89a972d69f00eb3ec98a5838484このハッシュを使って、次のステップで
<tracking_database_password_md5_hash>。 -
トラッキング・データベース・マシンの
/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 FDW connection to the replica database ## geo_secondary['db_fdw'] = true geo_postgresql['fdw_external_password'] = '<replica_database_password_plaintext>' 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 DB gitlab_rails['auto_migrate'] = false ## ## Disable all other services that aren't needed, since we don't have a role ## that does this. ## alertmanager['enable'] = false consul['enable'] = false gitaly['enable'] = false gitlab_exporter['enable'] = false gitlab_workhorse['enable'] = false nginx['enable'] = false node_exporter['enable'] = false pgbouncer_exporter['enable'] = false postgresql['enable'] = false prometheus['enable'] = false redis['enable'] = false redis_exporter['enable'] = false repmgr['enable'] = false sidekiq['enable'] = false puma['enable'] = false
これらの変更を行った後、変更が有効になるように GitLab を再設定します。
外部のPostgreSQLインスタンスを使用する場合は、外部のPostgreSQLインスタンスとのGeoも参照してください。
ステップ4：セカンダリノード上のフロントエンドアプリケーションサーバの設定
アーキテクチャの概要では、GitLabアプリケーションサービスを実行しているマシンが2台あります。 これらのサービスは、コンフィギュレーションで選択的に有効になっています。
Configuring GitLab for multiple nodesに従ってアプリケーションサーバーを設定し、次のように修正します：
-
セカンダリクラスタ内の各アプリケーションサーバで
/etc/gitlab/gitlab.rbを編集し、以下を追加します：## ## Enable the Geo secondary role ## roles ['geo_secondary_role', 'application_role'] ## ## The unique identifier for the Geo node. ## gitlab_rails['geo_node_name'] = '<node_name_here>' ## ## Disable automatic migrations ## gitlab_rails['auto_migrate'] = false ## ## Configure the connection to the tracking DB. And disable application ## servers from running tracking databases. ## geo_secondary['db_host'] = '<geo_tracking_db_host>' geo_secondary['db_password'] = '<geo_tracking_db_password>' geo_postgresql['enable'] = false ## ## 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 servers 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
postgresql['sql_user_password'] = 'md5 digest of secret' の設定を行っている場合、上記のgitlab_rails['db_password'] とgeo_secondary['db_password']に平文のパスワードが含まれていることに注意してください。 これはRailsサーバがデータベースに接続するために使用されます。postgresql['md5_auth_cidr_addresses'] 設定にリストされていることを確認してください。変更後 GitLab を再設定し、変更を有効にします。
セカンダリでは、以下のGitLabフロントエンドサービスが有効になります：
geo-logcursorgitlab-pagesgitlab-workhorselogrotatenginxregistryremote-syslogsidekiqpuma
フロントエンドのアプリケーションサーバでsudo gitlab-ctl status を実行して、これらのサービスを検証してください。
ステップ5：セカンダリノードのロードバランサーのセットアップ
このトポロジーでは、アプリケーションサーバーにトラフィックをルーティングするために、各地域にロードバランサーが必要です。
詳しくは複数ノードのGitLab用ロードバランサーをご覧ください。
ステップ6：セカンダリ・ノード上のバックエンド・アプリケーション・サーバーの設定
上記の最小リファレンス・アーキテクチャ図では、すべてのアプリケーション・サービスが同じマシン上で一緒に実行されています。 しかし、複数ノードの場合は、すべてのサービスを個別に実行することを強くお勧めします。
例えば、Sidekiqサーバーは、上記のフロントエンドアプリケーションサーバーと同様に構成することができますが、sidekiq サービスのみを実行するように変更する必要があります：
-
セカンダリクラスタ内の各Sidekiqサーバで
/etc/gitlab/gitlab.rbを編集し、以下を追加します：## ## Enable the Geo secondary role ## roles ['geo_secondary_role'] ## ## Enable the Sidekiq service ## sidekiq['enable'] = true ## ## Ensure unnecessary services are disabled ## alertmanager['enable'] = false consul['enable'] = false geo_logcursor['enable'] = false gitaly['enable'] = false gitlab_exporter['enable'] = false gitlab_workhorse['enable'] = false nginx['enable'] = false node_exporter['enable'] = false pgbouncer_exporter['enable'] = false postgresql['enable'] = false prometheus['enable'] = false redis['enable'] = false redis_exporter['enable'] = false repmgr['enable'] = false puma['enable'] = false ## ## The unique identifier for the Geo node. ## gitlab_rails['geo_node_name'] = '<node_name_here>' ## ## Disable automatic migrations ## gitlab_rails['auto_migrate'] = false ## ## Configure the connection to the tracking DB. And disable application ## servers from running tracking databases. ## geo_secondary['db_host'] = '<geo_tracking_db_host>' geo_secondary['db_password'] = '<geo_tracking_db_password>' geo_postgresql['enable'] = false ## ## 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 servers 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 を無効にするようにサーバーを設定できます。これらのサーバーはロードバランサーに接続する必要はありません。
