複数ノードのGeo

この文書では、マルチノード構成で Geo を実行するための最小限のリファレンスアーキテクチャについて説明します。 マルチノードのセットアップが説明されているものと異なる場合は、これらの手順をニーズに合わせて変更することが可能です。

建築概要

Geo multi-node diagram

ダイアグラムソース - GitLab従業員のみ

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

つの Geo デプロイに外部からアクセスする唯一の方法は、上記の例ではgitlab.us.example.comgitlab.eu.example.com の HTTPS です。

注:プライマリと セカンダリのGeo デプロイは、HTTPS で相互に通信できる必要があります。

複数ノード用のRedisとPostgreSQL

Geoがサポートします:

  • プライマリノードのRedisとPostgreSQLを複数ノードに設定。
  • 複数ノード用に設定されたセカンダリノード上のRedis。
注意:複数ノード構成におけるセカンダリノード上のPostgreSQLのサポートが計画されています。

PostgreSQLとRedisに対してこの設定を行うにはさらに複雑さが伴うため、このGeoマルチノード・ドキュメントでは扱っていません。

omnibusパッケージを使用した複数ノードのPostgreSQLクラスタとRedisクラスタのセットアップの詳細については、それぞれPostgreSQLとRedisの複数ノードのドキュメントを参照してください。

注意:PostgreSQLとRedisにクラウドホスティングサービスを使用することは可能ですが、このドキュメントの範囲外です。

前提条件:GitLabマルチノードクラスターが2つ稼働していること

一つのクラスターをプライマリノードとして使用します。GitLabのマルチノードに関するドキュメントを参考に設定してください。 すでに使用中のGitLabインスタンスがある場合は、それをプライマリとして使用することができます。

二番目のクラスターがセカンダリノードとなります。 ここでも、GitLabマルチノードのドキュメントを参考に設定してください。 ログインしてテストするのがよいでしょう。ただし、プライマリからレプリケーションする過程でデータが消去されることに注意しましょう。

GitLabクラスターをプライマリノードに設定します。

以下の手順で、GitLabクラスターをプライマリノードとして使えるようにします。

ステップ1:プライマリフロントエンドサーバの設定

  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 を再設定します。

注意:PostgreSQL と Redis は、通常の GitLab マルチノードのセットアップの際に、アプリケーションサーバーではすでに無効にして、アプリケーションサーバーからバックエンドサーバーのこれらのサービスへの接続を設定しておく必要があります。PostgreSQLRedisについては、マルチノード設定のドキュメントを参照ください。

ステップ2:プライマリ・データベースの設定

  1. /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 以外のマルチノードのドキュメントを使用して、以下のサービスを構成します:

  • GitLab 用Redis を複数ノード用に設定します。
  • Gitalyはプライマリノードから同期されたデータを保存します。
注:NFSはGitalyの代わりに使用できますが、推奨されていません。

ステップ2:セカンダリノード上のメインの読み取り専用レプリカPostgreSQLデータベースの設定

注意:以下の文書では、データベースを単一ノードのみで実行することを想定しています。セカンダリノードでのマルチノードPostgreSQLは現在サポートされていません。

セカンダリ・データベースを プライマリ・データベースの読み取り専用レプリカとして構成します。 ガイドとして以下を使用してください。

  1. 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>

  2. レプリカデータベースマシンで/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:セカンダリノード上のトラッキングデータベースの設定

注意:このドキュメントでは、追跡データベースを PostgreSQL クラスタとしてではなく、単一のマシンのみで実行することを想定しています。

トラッキングデータベースを設定します。

  1. 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>

  2. トラッキング・データベース・マシンの/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に従ってアプリケーションサーバーを設定し、次のように修正します:

  1. セカンダリクラスタ内の各アプリケーションサーバで/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
    
注意:omnibusパッケージを使用してPostgreSQLクラスタをセットアップしていて、postgresql['sql_user_password'] = 'md5 digest of secret' の設定を行っている場合、上記のgitlab_rails['db_password']geo_secondary['db_password']に平文のパスワードが含まれていることに注意してください。 これはRailsサーバがデータベースに接続するために使用されます。
注:現在のノード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:セカンダリノードのロードバランサーのセットアップ

このトポロジーでは、アプリケーションサーバーにトラフィックをルーティングするために、各地域にロードバランサーが必要です。

詳しくは複数ノードのGitLab用ロードバランサーをご覧ください。

ステップ6:セカンダリ・ノード上のバックエンド・アプリケーション・サーバーの設定

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

例えば、Sidekiqサーバーは、上記のフロントエンドアプリケーションサーバーと同様に構成することができますが、sidekiq サービスのみを実行するように変更する必要があります:

  1. セカンダリクラスタ内の各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'] = truegeo-logcursor サービスのみを実行し、sidekiq['enable'] = falseで Sidekiq を無効にするようにサーバーを設定できます。

    これらのサーバーはロードバランサーに接続する必要はありません。