レプリケーション(Geo)

Geo を使用したレプリケーションは、広範囲に分散した開発チーム向けのソリューションです。

概要

一つのGitLabインスタンスから離れた場所にいるチームにとって、大きなリポジトリのフェッチには長い時間がかかることがあります。

Geoは、GitLabインスタンスの読み込み専用のローカルインスタンスを提供します。 これにより、大規模なリポジトリのクローンやフェッチにかかる時間を短縮し、開発者をスピードアップさせることができます。

注:Geo をセットアップする前に、必要条件をよく確認してください。

Geoの紹介ビデオについては、Introduction to GitLab Geo - GitLab Featuresをご覧ください。

注意:Geo はリリースごとに大きな変更が加えられています。 アップグレードはサポートされ、文書化されていますが、あなたのインストールに正しいバージョンの文書を使用していることを確認する必要があります。

ドキュメントの正しいバージョンを使っていることを確認するには、GitLab.comのこのページのソースバージョンに移動し、スイッチブランチ/タグのドロップダウンから適切なリリースを選択します。 たとえば、v11.2.3-ee.

ユースケース

Geoを導入すると、次のようなメリットがあります:

  • ディストリビューション開発者が大規模なリポジトリやプロジェクトのクローン作成と取得にかかる時間を数分から数秒に短縮します。
  • 開発者全員が、どこにいてもアイデアに貢献し、並行して作業できるようにします。
  • プライマリ・ノードと セカンダリ・ノード間の読み取り専用負荷のバランスをとります。

さらに

  • GitLabウェブインターフェイスで利用可能なあらゆるデータの読み込みに加えて、プロジェクトのクローンやフェッチに使用できます(現在の制限を参照)。
  • 離れたオフィス間の低速接続を克服し、ディストリビューションチームの速度を向上させることで時間を節約します。
  • 自動タスク、カスタムインテグレーション、内部ワークフローのロード時間の短縮に役立ちます。
  • 災害復旧シナリオにおいて、セカンダリノードへの迅速なフェイルオーバーが可能。
  • セカンダリノードへの 計画的なフェイルオーバーを可能にします。

Geoが提供します:

  • 読み取り専用のセカンダリノード:1つのGitLabプライマリノードをメンテナーしつつ、ディストリビューションチームごとに読み取り専用のセカンダリノードを有効にします。
  • 認証システムフック:セカンダリノードはプライマリインスタンスからすべての認証データ(ユーザーアカウントやログインなど)を受け取ります。
  • 直感的なUI:セカンダリノードは、チームが慣れ親しんだWebインターフェイスを使用します。 さらに、書き込みオペレーションをブロックし、ユーザーがセカンダリノードにいることを明確にするビジュアル通知があります。

どのように動作するか

Geo インスタンスは、あらゆるデータの読み取りに加えて、プロジェクトのクローン作成とフェッチにも使用できます。 これにより、長距離の大規模リポジトリでの作業がより高速になります。

Geo overview

Geoが有効な場合:

  • オリジナルのインスタンスはプライマリ・ノードと呼ばれます。
  • 複製された読み取り専用ノードはセカンダリ・ノードと呼ばれます。

覚えておいてください:

  • セカンダリノードは プライマリノードと通信します:
    • ログイン用ユーザーデータの取得(API).
    • リポジトリ、LFSオブジェクト、添付ファイル(HTTPS + JWT)を複製します。
  • GitLab Premium 10.0以降、プライマリノードから セカンダリノードへの変更の通知は行われなくなりました(API)。
  • セカンダリノードへの直接プッシュ(HTTPとSSHの両方、Git LFSを含む)はGitLab Premium11.3で導入されました。
  • 現在の実装には限界があります。

アーキテクチャ

以下の図は、Geo の基本的なアーキテクチャを示しています。

Geo architecture

この図では

  • プライマリ・ノードと1つのセカンダリ・ノードの詳細があります。
  • データベースへの書き込みはプライマリノードでのみ実行できます。セカンダリノードはPostgreSQLストリーミングレプリケーションによってデータベースの更新を受け取ります。
  • LDAPサーバーが存在する場合は、災害復旧シナリオ用にレプリケートするように構成する必要があります。
  • セカンダリノードは、JWTで保護された特別な作成者を使用して、プライマリノードに対して異なるタイプの同期を実行します:
    • リポジトリはGit over HTTPSでクローン/更新されます。
    • 添付ファイル、LFS オブジェクト、その他のファイルは、非公開 API エンドポイントを使用して HTTPS 経由でダウンロードされます。

Gitオペレーションを行うユーザーの視点から:

  • プライマリノードは完全に読み書き可能なGitLabインスタンスとして振る舞います。
  • セカンダリー・ノードは読み取り専用ですが、Gitのプッシュ・オペレーションをプライマリー・ノードにプロキシします。 これにより、セカンダリー・ノード自身がプッシュ・オペレーションをサポートしているように見えます。

図を簡略化するため、必要なコンポーネントの一部を省略しています。 以下の点に注意してください:

セカンダリノードには2つの異なるPostgreSQLデータベースが必要であることに注意してください:

  • メインのGitLabデータベースからデータをストリームする読み取り専用のデータベースインスタンス。
  • セカンダリノードが内部で使用する別のデータベースインスタンスで、レプリケートされたデータを記録します。

セカンダリノードには、GeoLog Cursorというデーモンが追加されています。

Geoの実行要件

Geoの実行には以下が必要です:

さらに、GitLabの最小要件を確認してください:

  • Geoの基本的な機能のために少なくともGitLab Enterprise Edition 10.0。
  • 最新バージョンでより快適に。

ファイアウォールルール

次の表は、プライマリノードと セカンダリノード間で Geo が開いていなければならない基本的なポートの一覧です。

一次ノード 二次ノード プロトコル
80 80 HTTP
443 443 TCPまたはHTTPS
22 22 伝送制御プロトコル
5432   PostgreSQL

GitLabが使用するポートの一覧はPackage defaultsをご覧ください。

注意:Web 端末のサポートには、ロードバランサが WebSocket 接続を正しく処理する必要があります。 HTTP または HTTPS プロキシを使用する場合、ロードバランサはConnectionUpgrade ホップバイホップヘッダを通過するように設定する必要があります。 詳細はWeb 端末インテグレーションガイドを参照してください。
注:ポート443にHTTPSプロトコルを使用する場合、ロードバランサーにSSL証明書を追加する必要があります。 代わりにGitLabアプリケーションサーバーでSSLを終了したい場合は、TCPプロトコルを使用してください。

ライトウェイトディレクトリアクセスプロトコル

プライマリ・ノードでLDAPを使う場合は、セカンダリ・ノードにもLDAPサーバーをセットアップすることをお勧めします。 そうしないと、セカンダリ・ノードでHTTPベーシック認証を使ったGitオペレーションができなくなります。 しかし、SSHや個人アクセストークンを使ったGitオペレーションは可能です。

注:すべてのセカンダリノードでLDAPサーバを共有することは可能ですが、追加の待ち時間がイシューになる可能性があります。 また、セカンダリノードが プライマリノードに昇格した場合、ディザスタリカバリシナリオでどのLDAPサーバが利用できるかを考慮してください。

LDAP サービスでレプリケーションを設定する方法については、使用するソフトウ ェアやサービスによって異なります。 例えば、OpenLDAP では次のような説明があります。

Geoトラッキングデータベース

トラッキング・データベース・インスタンスは、ローカル・インスタンスのディスク上で更新が必要なものを制御するためのメタデータとして使用されます。 例えば、以下のようなものです:

  • 新しいアセットをダウンロードしてください。
  • 新しい LFS オブジェクトを取得します。
  • 最近更新されたリポジトリから変更を取得します。

レプリケートされたデータベースインスタンスは読み取り専用であるため、各セカンダリノードにこの追加のデータベースインスタンスが必要です。トラッキングデータベースにはpostgres_fdw 拡張が必要です。

Geo ログカーソル

このデーモンは

  • プライマリ・ノードから セカンダリ・データベース・インスタンスにレプリケートされたイベントのログを読み取ります。
  • 実行が必要な変更で Geo Tracking Database インスタンスを更新します。

トラッキングデータベースインスタンスに更新マークが付けられると、セカンダリノードで実行されている非同期ジョブが必要なオペレーションを実行し、状態を更新します。

この新しいアーキテクチャにより、GitLabはノード間の接続性の問題に強くなりました。セカンダリノードが プライマリノードからどれだけ長い間切断されていても、すべてのイベントを正しい順序で再生し、再びプライマリノードと同期することができるからです。

セットアップ方法

これらの手順は、GitLab のインスタンスが動作していることを前提としたものです。 この手順では、以下のことを説明します:

  1. 既存のインスタンスをプライマリ・ノードにします。
  2. セカンダリノードの追加
注意:以下の手順は表示された順番に従ってください。 GitLabのバージョンがすべてのノードで同じであることを確認してください。

Omnibus GitLab の使用法

Omnibus パッケージを使って GitLab をインストールした場合(強くお勧めします):

  1. セカンダリノードとなるサーバーに GitLab Enterprise Edition をインストールします。 新しいセカンダリノードにアカウントを作成したりログインしたりしないでください。
  2. Geoのロックを解除するために、プライマリノードにGitLab Licenseをアップロードします。 ライセンスはGitLab Premium以上のものでなければなりません。
  3. データベースのレプリケーションprimary (read-write) <-> secondary (read-only) トポロジー)を設定します。
  4. データベース内の作成者SSHキーの高速検索を設定します。 このステップは必須で、プライマリノードと セカンダリノードの 両方で実行する必要があります。
  5. GitLabにプライマリノードと セカンダリノードを設定します。
  6. オプション:セカンダリ・ノード用にセカンダリLDAPサーバを設定します。LDAPに関する注記を参照してください。
  7. Geoサーバーの使用」ガイドに従ってください。

インストール後のドキュメント

セカンダリノードにGitLabをインストールして初期設定を行った後、インストール後の情報については以下のドキュメントを参照してください。

Geoの設定

Geo の設定については、Geo の設定を参照してください。

Geoの更新

Geoノードを最新のGitLabバージョンにアップデートする方法については、Geoノードのアップデートをご覧ください。

レプリケーションの一時停止と再開

GitLab Premium13.2で導入されました

アップグレード時や計画的なフェイルオーバー時など、状況によってはプライマリとセカンダリ間のレプリケーションを一時停止することが望ましい場合があります。

レプリケーションの一時停止と再開は、セカンダリノードからコマンドラインツールを使って行います。

一時停止するには:(セカンダリーから)

gitlab-ctl geo-replication-pause

レジュメへ:(セカンダリーから)

gitlab-ctl geo-replication-resume

複数ノードに対する Geo の設定

複数ノード用の Geo の設定については、複数サーバー用のGeo を参照してください。

オブジェクトストレージを使用した Geo の設定

オブジェクトストレージを使用した Geo の設定については、オブジェクトストレージを使用したGeo を参照してください。

災害復旧

Geo を災害復旧時に使用してデータ損失を軽減し、サービスを復元する方法については、「災害復旧」を参照してください。

コンテナレジストリの複製

コンテナレジストリを複製する方法の詳細については、セカンダリノードのDockerレジストリを参照してください。

セキュリティ・レビュー

Geoセキュリティの詳細については、Geoセキュリティレビューをご覧ください。

Geoのチューニング

Geo のチューニングの詳細については、Geo のチューニングを参照してください。

場所を意識したGit URLの設定

AWS Route53 で場所を認識した Git リモート URL を設定する例については、AWS Route53 による場所を認識した Git リモート URLを参照してください。

Geoノードの削除

Geo ノードの削除の詳細については、セカンダリGeo ノードの削除を参照してください。

現在の制限

注意:この制限のリストはGitLabの最新バージョンのみを反映しています。 古いバージョンを使用している場合、余分な制限がある可能性があります。
  • セカンダリノードへの直接のプッシュは、リクエストを直接処理する代わりに(HTTPの場合は)リダイレクトするか(SSHの場合は)プライマリノードへプロキシします。ただし、URIにクレデンシャルを埋め込んでGit over HTTPを使う場合を除きます。例えば、https://user:password@secondary.tld.
  • プライマリ・ノードに存在し、セカンダリ・ノードには存在しないリポジトリのクローン作成、プル、プッシュ(選択的同期にプロジェクトが含まれない場合)は、SSH 経由ではサポートされていませんが、サポートが予定されています。HTTP(S) 。
  • OAuthログインを行うには、プライマリ・ノードがオンラインである必要があります。 既存のセッションやgitは影響を受けません。セカンダリ・ノードがプライマリとは独立したOAuthプロバイダーを使用するためのサポートは計画中です。
  • インストールには複数の手動ステップが必要で、状況によっては合わせて一時間ほどかかることもあります。 私たちはこの経験の改善に取り組んでいます。 詳しくはOmnibusGitLabissue #2978をご覧ください。
  • セカンダリ・ノードでは、(ロング・ポーリングなどによる)イシュー/マージ・リクエストのリアルタイム更新は機能しません。
  • 選択的同期はファイルとリポジトリにのみ適用され、その他のデータセットはセカンダリ・ノードに完全にレプリケートされるため、アクセス制御メカニズムとしては不適切です。
  • フォークされたプロジェクト重複排除のためのオブジェクトプールは、プライマリノードでのみ動作し、セカンダリノードでは複製されます。
  • 外部マージ・リクエストの差分がディスク上にある場合はレプリケートされず、マージ・リクエストの表示は失敗します。 ただし、オブジェクト・ストレージ内の外部 MR差分はサポートされます。 デフォルトの構成 (データベース内) は機能します。
  • GitLab Runnerはセカンダリノードに登録することができません。 このサポートは将来的に予定されています。

複製・検証の制限

これらのエピック/イシューに欠けている項目を実装するための進捗状況を把握することができます:

GitLabの全データ型の完全なリストと、レプリケーションと検証の既存のサポートがあります。

よくある質問

よくある質問については、GeoFAQをご覧ください。

ログファイル

GitLab 9.5以降、Geoは構造化されたログメッセージをgeo.log ファイルに保存します。Omnibusのインストールでは、このファイルは/var/log/gitlab/gitlab-rails/geo.logにあります。

このファイルには、Geo がリポジトリとファイルの同期を試みたときの情報が含まれています。 ファイルの各行には、取り込むことができる個別の JSON エントリが含まれています。 たとえば、Elasticsearch や Splunk などです。

使用例:

{"severity":"INFO","time":"2017-08-06T05:40:16.104Z","message":"Repository update","project_id":1,"source":"repository","resync_repository":true,"resync_wiki":true,"class":"Gitlab::Geo::LogCursor::Daemon","cursor_delay_s":0.038}

このメッセージは、Geo がプロジェクト1でリポジトリの更新が必要であることを検知したことを示しています。

トラブルシューティング

トラブルシューティングの手順については、「Geoトラブルシューティング」を参照してください。