2つのシングルノードサイトのGeoのセットアップ
以下のガイドでは、外部サービスをセットアップしていない 2 つの Linux パッケージインスタンスを使って、2 つのシングルノードサイトインストール用に GitLab Geo をデプロイする方法を簡潔に説明します。
前提条件:
- 独立して動作するGitLabサイトが2つ以上あること。サイトを作成するには、GitLabリファレンスアーキテクチャのドキュメントを参照してください。
- 1つのGitLabサイトがGeoプライマリサイトとして機能します。Geoサイトごとに異なるリファレンスアーキテクチャサイズを使用することができます。すでに動作している GitLab インスタンスがある場合は、それをプライマリサイトとして使うことができます。
- 2つ目のGitLabサイトはGeoセカンダリサイトとして機能します。Geoは複数のセカンダリサイトをサポートしています。
- Geoプライマリサイトは少なくともGitLab Premiumライセンスを持っています。全てのサイトに必要なライセンスは1つだけです。
- すべてのサイトがGeo を実行するための要件を満たしていることを確認してください。
Geo for Linux パッケージのセットアップ (Omnibus)
前提条件:
- PostgreSQL 12以降を使用しており、
pg_basebackup
ツール が含まれていること。
プライマリサイトの設定
-
GitLabのプライマリサイトにSSHで入り、rootでサインインします:
sudo -i
-
/etc/gitlab/gitlab.rb
にユニークな Geo サイト名を追加します:## ## The unique identifier for the Geo site. See ## https://docs.gitlab.com/ee/user/admin_area/geo_nodes.html#common-settings ## gitlab_rails['geo_node_name'] = '<site_name_here>'
-
変更を適用するには、プライマリ サイトを再設定します:
gitlab-ctl reconfigure
-
サイトをプライマリ Geo サイトとして定義します:
gitlab-ctl set-geo-primary-node
このコマンドは
/etc/gitlab/gitlab.rb
で定義したexternal_url
を使用します。 -
gitlab
データベース・ユーザーのパスワードを作成します。-
必要なパスワードの MD5 ハッシュを生成します:
gitlab-ctl pg-password-md5 gitlab # Enter password: <your_password_here> # Confirm password: <your_password_here> # fca0b89a972d69f00eb3ec98a5838484
-
/etc/gitlab/gitlab.rb
を編集します:# Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab` postgresql['sql_user_password'] = '<md5_hash_of_your_password>' # Every node that runs Puma or Sidekiq needs to have the database # password specified as below. If you have a high-availability setup, this # must be present in all application nodes. gitlab_rails['db_password'] = '<your_password_here>'
-
-
データベース・レプリケーション・ユーザーのパスワードを定義します。
postgresql['sql_replication_user']
設定の下、/etc/gitlab/gitlab.rb
で定義したユーザー名を使用します。デフォルト値はgitlab_replicator
です。-
必要なパスワードの MD5 ハッシュを生成します:
gitlab-ctl pg-password-md5 gitlab_replicator # Enter password: <your_password_here> # Confirm password: <your_password_here> # 950233c0dfc2f39c64cf30457c3b7f1e
-
/etc/gitlab/gitlab.rb
を編集します:# Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab_replicator` postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'
-
オプション。Linux パッケージで管理されていない外部データベースを使用する場合は、
gitlab_replicator
ユーザーを作成し、そのユーザーのパスワードを手動で定義する必要があります:--- Create a new user 'replicator' CREATE USER gitlab_replicator; --- Set/change a password and grants replication privilege ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<replication_password>';
-
-
/etc/gitlab/gitlab.rb
で、ロールをgeo_primary_role
に設定します:## Geo Primary role roles(['geo_primary_role'])
-
PostgreSQLがネットワークインタフェースをリッスンするように設定します:
-
Geo サイトのアドレスを調べるには、Geo サイトに SSH 接続し、次のコマンドを実行します:
## ## Private address ## ip route get 255.255.255.255 | awk '{print "Private address:", $NF; exit}' ## ## Public address ## echo "External address: $(curl --silent "ipinfo.io/ip")"
多くの場合、Geoサイトの設定には以下のアドレスが使われます:
設定 アドレス postgresql['listen_address']
プライマリサイトの公開アドレスまたはVPCの非公開アドレス。 postgresql['md5_auth_cidr_addresses']
プライマリおよびセカンダリサイトの公開アドレスまたはVPC非公開アドレス。 Google Cloud Platform、SoftLayer、または仮想プライベートクラウド
postgresql['md5_auth_cidr_addresses']
を提供するその他のベンダーを使用している場合、プライマリおよびセカンダリサイトの非公開アドレス(Google Cloud Platform の「内部アドレス」に相当)をpostgresql['md5_auth_cidr_addresses']
およびpostgresql['listen_address']
に使用できます。0.0.0.0
または*
をlisten_address
として使用する必要がある場合は、postgresql['md5_auth_cidr_addresses']
の設定に127.0.0.1/32
を追加して、Rails が127.0.0.1
を介して接続できるようにする必要があります。詳しくはイシュー5258をご覧ください。ネットワーク設定によっては、推奨されるアドレスが正しくない場合があります。プライマリ サイトとセカンダリ サイトがローカル エリア ネットワーク、またはAmazon の VPCやGoogle の VPC のようなアベイラビリティ ゾーンを接続する仮想ネットワークで接続されている場合は、セカンダリ サイトの非公開アドレスを
postgresql['md5_auth_cidr_addresses']
に使用する必要があります。 -
/etc/gitlab/gitlab.rb
に以下の行を追加します。 IPアドレスは、必ずネットワーク設定に適したアドレスに置き換えてください:## ## Primary address ## - replace '<primary_node_ip>' with the public or VPC address of your Geo primary node ## postgresql['listen_address'] = '<primary_site_ip>' ## # Allow PostgreSQL client authentication from the primary and secondary IPs. These IPs may be # public or VPC addresses in CIDR format, for example ['198.51.100.1/32', '198.51.100.2/32'] ## postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']
-
-
PostgreSQLが再起動され、非公開アドレスでリッスンされるまで、データベースの自動マイグレーションを一時的に無効にしてください。
/etc/gitlab/gitlab.rb
で、gitlab_rails['auto_migrate']
を false に設定します:## Disable automatic database migrations gitlab_rails['auto_migrate'] = false
-
これらの変更を適用するには、GitLabを再設定してPostgreSQLを再起動します:
gitlab-ctl reconfigure gitlab-ctl restart postgresql
-
マイグレーションを再び有効にするには、
/etc/gitlab/gitlab.rb
を編集し、gitlab_rails['auto_migrate']
をtrue
に変更します:gitlab_rails['auto_migrate'] = true
ファイルを保存して GitLab を再設定してください:
gitlab-ctl reconfigure
PostgreSQL サーバーがリモート接続を受け入れるように設定されています。
-
netstat -plnt | grep 5432
を実行して、PostgreSQL がプライマリサイトの非公開アドレスのポート5432
をリスンしていることを確認してください。 -
GitLabの再設定時に証明書が自動的に生成されました。この証明書は、PostgreSQLのトラフィックを盗聴者から保護するために自動的に使用されます。アクティブな(”man-in-the-middle”)攻撃者から守るには、証明書をセカンダリサイトにコピーしてください:
-
プライマリサイトで
server.crt
:cat ~gitlab-psql/data/server.crt
-
セカンダリ・サイトを設定するときのために、出力を保存してください。証明書は機密データではありません。
証明書は、一般的な
PostgreSQL
コモンネームで作成されます。ホ ス ト 名の不一致エ ラ ーを防ぐ には、 デー タ ベース を複製す る 際にverify-ca
モー ド を使用す る 必要があ り ます。 -
セカンダリ・サーバの設定
-
GitLab セカンダリサイトに SSH して root でサインインします:
sudo -i
-
サイトが設定される前にコマンドが実行されるのを防ぐために、アプリケーションサーバーとSidekiqを停止します:
gitlab-ctl stop puma gitlab-ctl stop sidekiq
-
プライマリ・サイトのPostgreSQLサーバへのTCP接続を確認します:
gitlab-rake gitlab:tcp_check[<primary_site_ip>,5432]
この手順が失敗する場合、間違ったIPアドレスを使用しているか、ファイアウォールがサイトへのアクセスを妨げている可能性があります。公開アドレスと非公開アドレスの違いに注意してIPアドレスを確認してください。ファイアウォールが存在する場合は、セカンダリサイトがポート5432でプライマリサイトへの接続を許可されていることを確認してください。
-
セカンダリ・サイトで、
server.crt
というファイルを作成し、プライマリ・サイトを設定したときに作成した証明書のコピーを追加します。editor server.crt
-
セカンダリサイトでPostgreSQLのTLS検証を設定するには、
server.crt
をインストールしてください:install \ -D \ -o gitlab-psql \ -g gitlab-psql \ -m 0400 \ -T server.crt ~gitlab-psql/.postgresql/root.crt
PostgreSQLはTLS接続を検証する際に、この証明書のみを認識します。この証明書は、プライマリサイトのみに存在する秘密鍵にアクセスできる人であれば複製することができます。
-
gitlab-psql
ユーザがプライマリサイトのデータベースに接続できることをテストしてください。デフォルトの 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_site_ip>
プロンプトが表示されたら、
gitlab_replicator
ユーザーに設定した平文のパスワードを入力します。すべてが正しく動作していれば、プライマリ・サイト・データベースのリストが表示されるはずです。 -
/etc/gitlab/gitlab.rb
を編集し、ロールをgeo_secondary_role
に設定します:## ## Geo Secondary role ## - configure dependent flags automatically to enable Geo ## roles(['geo_secondary_role'])
詳細については、Geoロールを参照してください。
-
PostgreSQLを設定するには、
/etc/gitlab/gitlab.rb
:## ## Secondary address ## - replace '<secondary_site_ip>' with the public or VPC address of your Geo secondary site ## postgresql['listen_address'] = '<secondary_site_ip>' postgresql['md5_auth_cidr_addresses'] = ['<secondary_site_ip>/32'] ## ## Database credentials password (defined previously in primary site) ## - replicate same values here as defined in primary site ## postgresql['sql_replication_password'] = '<md5_hash_of_your_password>' postgresql['sql_user_password'] = '<md5_hash_of_your_password>' gitlab_rails['db_password'] = '<your_password_here>'
IPアドレスはあなたのネットワーク設定に適したアドレスに置き換えてください。
-
変更を適用するには、GitLabを再設定してください:
gitlab-ctl reconfigure
-
IPアドレスの変更を適用するには、PostgreSQLを再起動してください:
gitlab-ctl restart postgresql
データベースの複製
セカンダリサイトのデータベースをプライマリサイトのデータベースに接続します。以下のスクリプトを使用してデータベースをレプリケートし、ストリーミング・レプリケーションに必要なファイルを作成することができます。
スクリプトはデフォルトのLinuxパッケージ・ディレクトリを使用します。デフォルトを変更した場合は、以下のスクリプトのディレクトリ名とパス名を独自の名前に置き換えてください。
pg_basebackup
を実行する前にすべての PostgreSQL データを削除するため、データが失われる可能性があります。データベースを複製するには
-
GitLab セカンダリサイトに SSH して root でサインインします:
sudo -i
-
レプリケーションスロット名として使用する、セカンダリサイトのデータベースフレンドリーな名前を選択します。例えば、ドメインが
secondary.geo.example.com
の場合、secondary_example
をスロット名として使います。レプリケーション・スロット名には、小文字、数字、アンダースコアのみを含める必要があります。 -
以下のコマンドを実行してデータベースをバックアップおよびリストアし、レプリケーションを開始します。
各Geoセカンダリサイトには、それぞれ固有のレプリケーションスロット名が必要です。2つのセカンダリ間で同じスロット名を使用すると、PostgreSQLレプリケーションが壊れます。gitlab-ctl replicate-geo-database \ --slot-name=<secondary_site_name> \ --host=<primary_site_ip> \ --sslmode=verify-ca
プロンプトが表示されたら、
gitlab_replicator
に設定した平文のパスワードを入力します。
レプリケーション処理が完了します。
新しいセカンダリサイトの設定
レプリケーションプロセスが完了したら、SSHキーの高速検索を設定する必要があります。
GitLab の秘密の値を手動で複製します。
GitLabはいくつかのシークレットバリューを/etc/gitlab/gitlab-secrets.json
。このJSONファイルは各サイトノードで同じでなければなりません。手動でセカンダリサイト全体にシークレットファイルを複製する必要がありますが、イシュー3789ではこの動作を変更することを提案しています。
-
プライマリサイトのRailsノードにSSH接続して、以下のコマンドを実行します:
sudo cat /etc/gitlab/gitlab-secrets.json
複製するシークレットがJSON形式で表示されます。
-
セカンダリノードの各ノードに SSH でログインし、root としてサインインします:
sudo -i
-
既存のシークレットのバックアップを作成します:
mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
-
/etc/gitlab/gitlab-secrets.json
をプライマリ サイトの Rails ノードから各セカンダリ サイト ノードにコピーします。ノード間でファイルの内容をコピー&ペーストすることもできます:sudo editor /etc/gitlab/gitlab-secrets.json # paste the output of the `cat` command you ran on the primary # save and exit
-
ファイルの権限が正しいことを確認してください:
chown root:root /etc/gitlab/gitlab-secrets.json chmod 0600 /etc/gitlab/gitlab-secrets.json
-
変更を適用するには、すべてのRails、Sidekiq、Gitalyセカンダリサイトノードを再設定します:
gitlab-ctl reconfigure gitlab-ctl restart
プライマリサイトのSSHホストキーを手動で複製します。
-
セカンダリサイトの各ノードにSSHでログインし、rootとしてサインインします:
sudo -i
-
既存のSSHホスト・キーをバックアップします:
find /etc/ssh -iname 'ssh_host_*' -exec cp {} {}.backup.`date +%F` \;
-
プライマリサイトからOpenSSHホストキーをコピーします。
-
SSHトラフィックを提供するプライマリサイトノードの1つ(通常はGitLab Railsアプリケーションのメインノード)にrootでアクセスできる場合:
# Run this from the secondary site, change `<primary_site_fqdn>` for the IP or FQDN of the server scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh
-
sudo
権限を持つユーザーからのみアクセスできる場合:# Run this from the node on your primary site: sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key* # Run this on each node on your secondary site: scp <user_with_sudo>@<primary_site_fqdn>:geo-host-key.tar.gz . tar zxvf ~/geo-host-key.tar.gz -C /etc/ssh
-
-
各セカンダリ サイト ノードについて、ファイルの権限が正しいことを確認します:
chown root:root /etc/ssh/ssh_host_*_key* chmod 0600 /etc/ssh/ssh_host_*_key
-
キー・フィンガープリントの一致を確認するには、各サイトのプライマリ・ノードとセカンダリ・ノードの両方で以下のコマンドを実行します:
for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
以下のような出力が得られるはずです:
1024 SHA256:FEZX2jQa2bcsd/fn/uxBzxhKdx4Imc4raXrHwsbtP0M root@serverhostname (DSA) 256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY root@serverhostname (ECDSA) 256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM root@serverhostname (ED25519) 2048 SHA256:qwa+rgir2Oy86QI+PZi/QVR+MSmrdrpsuH7YyKknC+s root@serverhostname (RSA)
出力は両方のノードで同じでなければなりません。
-
既存の秘密鍵に対して正しい公開鍵があることを確認します:
# This will print the fingerprint for private keys: for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done # This will print the fingerprint for public keys: for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done
公開鍵と秘密鍵コマンドの出力は同じフィンガープリントを生成するはずです。
-
各セカンダリ・サイト・ノードについて、
sshd
を再起動します:# Debian or Ubuntu installations sudo service ssh reload # CentOS installations sudo service sshd reload
-
SSHが機能していることを確認するために、新しいターミナルからGitLabセカンダリサーバにSSH接続してください。接続できない場合は、正しい権限を持っていることを確認してください。
セカンダリサイトの追加
-
セカンダリサイトの各RailsおよびSidekiqノードにSSHでログインし、rootとしてサインインします:
sudo -i
-
/etc/gitlab/gitlab.rb
を編集し、サイトの固有名を追加します。## ## The unique identifier for the Geo site. See ## https://docs.gitlab.com/ee/user/admin_area/geo_nodes.html#common-settings ## gitlab_rails['geo_node_name'] = '<site_name_here>'
次のステップのために一意の名前を保存します。
-
変更を適用するには、セカンダリサイトの各RailsおよびSidekiqノードを再設定します。
gitlab-ctl reconfigure
- プライマリノードのGitLabインスタンスに移動します:
- 左のサイドバーで、Search を選択するか、次のページに進んでください。
- Admin Areaを選択します。
- Geo > Sitesを選択します。
-
サイトを追加]を選択します。
-
Name に、
gitlab_rails['geo_node_name']
の値を/etc/gitlab/gitlab.rb
に入力します。値は正確に一致する必要があります。 -
外部 URL」には、「
external_url
」の値を「/etc/gitlab/gitlab.rb
」に入力します。一方の値が「/
」で終わり、もう一方が「 」で終わらなくても問題ありません。それ以外の場合は、値が正確に一致する必要があります。 - オプション。内部URL(オプション)には、プライマリ・サイトの内部URLを入力します。
- オプション。セカンダリサイトでレプリケートするグループまたはストレージシャードを選択します。すべてをレプリケートするには、フィールドを空白のままにします。選択的同期を参照してください。
- 変更を保存を選択します。
-
セカンダリサイトの各RailsおよびSidekiqノードにSSH接続して、サービスを再起動します:
gitlab-ctl restart
-
Geoのセットアップに共通のイシューがないか、実行して確認してください:
gitlab-rake gitlab:geo:check
チェックに失敗した場合は、トラブルシューティングを参照してください。
-
セカンダリサイトに到達可能であることを確認するには、プライマリサイトのRailsまたはSidekiqサーバにSSHでログインし、rootとしてサインインします:
gitlab-rake gitlab:geo:check
いずれかのチェックに失敗した場合は、トラブルシューティング ドキュメントを確認してください。
セカンダリ サイトが Geo 管理ページに追加され、再起動されると、サイトは自動的にバックフィルと呼ばれるプロセスで、プライマリ サイトの欠落データの複製を開始します。
一方、プライマリ サイトは各セカンダリ サイトに変更の通知を開始し、セカンダリ サイトはその通知に即座に対応できるようになります。
セカンダリサイトが実行中であり、アクセス可能であることを確認してください。セカンダリサイトには、プライマリサイトで使用したのと同じ認証情報でサインインできます。
HTTP/HTTPS と SSH での Git アクセスを有効にします。
Geo は HTTP/HTTPS 経由でリポジトリを同期するため、このクローン方法を有効にする必要があります。これはデフォルトで有効になっています。既存のサイトを Geo に変換する場合は、clone メソッドが有効になっていることを確認する必要があります。
プライマリ サイトで
- 左のサイドバーで、Search を選択するか、次のページに進んでください。
- Admin Areaを選択します。
- 設定] > [全般]を選択します。
- 表示とアクセス制御] を展開します。
- GitをSSHで使う場合:
- Enabled Git access protocolsがBoth SSH and HTTP(S)に設定されていることを確認してください。
- プライマリサイトとセカンダリサイトの両方で、データベース内の作成者SSHキーを高速に検索します。
- SSH 経由で Git を使用しない場合は、「Enabled Git access protocols」を「Only HTTP(S)」に設定してください。
セカンダリサイトが正しく機能していることを確認します。
セカンダリサイトには、プライマリサイトで使用したのと同じ認証情報でサインインできます。
サインイン後
- 左のサイドバーで、Search を選択するか、次のページに進んでください。
- Admin Areaを選択します。
- Geo > Sitesを選択します。
- サイトがセカンダリ Geo サイトとして正しく識別され、Geo が有効になっていることを確認します。
最初のレプリケーションには時間がかかる場合があります。各 Geo サイトの同期プロセスは、ブラウザのプライマリサイトGeo サイトダッシュボードから監視できます。