GitHub Enterprise Server クラスターのネットワークについて
GitHub Enterprise Server クラスター内の各ノードは、ネットワーク経由でクラスター内の他のすべてのノードと通信可能である必要があります。 エンド ユーザー、管理、およびノード間の通信に必要なポートとプロトコルを確認できます。 フロントエンド ノード間でトラフィックを分散するために、GitHub では、外部ロード バランサーを構成することをお勧めします。
ネットワークに関する考慮事項
クラスタリングのための最もシンプルなネットワーク設計は、ノード群を単一のLANに置くことです。 クラスタがサブネットワークにまたがる必要がある場合は、ネットワーク間にファイアウォールルールを設定することはお勧めしません。 ノード間の遅延は 1 ミリ秒未満である必要があります。
プライマリ ノードとレプリカ ノード間の待機時間は 70 ミリ秒未満である必要があります。 ノードのネットワーク間にファイアウォールを設定することはお勧めしません。
エンドユーザーのためのアプリケーションポート
アプリケーションのポートは、エンドユーザーにWebアプリケーションとGitへのアクセスを提供します。
| Port | 説明 | Encrypted |
|---|---|---|
| 22/TCP | Git over SSH | |
| 25/TCP | SMTP | STARTTLSが必要 |
| 80/TCP | HTTP | SSL が有効になっている場合、このポートは HTTPS にリダイレクトされます |
| 443/TCP | HTTPS | |
| 9418/TCP | 単純な Git プロトコル ポート (プライベート モードでは無効) |
管理ポート
管理ポートは、エンドユーザが基本的なアプリケーションを利用するためには必要ありません。
| Port | 説明 | Encrypted |
|---|---|---|
| ICMP | ICMP Ping | |
| 122/TCP | 管理SSH | |
| 161/UDP | SNMP | |
| 8080/TCP | Management Console HTTP | SSL が有効になっている場合、このポートは HTTPS にリダイレクトされます |
| 8443/TCP | Management Console HTTPS |
クラスタ通信ポート
ネットワークレベルのファイアウォールがノード間にある場合は、これらのポートがアクセス可能である必要があります。 ノード間の通信は暗号化されていません。 これらのポートは外部からアクセスできません。
| Port | 説明 |
|---|---|
| 1336/TCP | 内部 API |
| 3033/TCP | 内部 SVN アクセス |
| 3037/TCP | 内部 SVN アクセス |
| 3306/TCP | MySQL |
| 4486/TCP | Governor アクセス |
| 5115/TCP | ストレージ バックエンド |
| 5208/TCP | 内部 SVN アクセス |
| 6379/TCP | Redis |
| 8001/TCP | Grafana |
| 8090/TCP | 内部 GPG アクセス |
| 8149/TCP | GitRPC ファイルサーバーアクセス |
| 8300/TCP | Consul |
| 8301/TCP | Consul |
| 8302/TCP | Consul |
| 9000/TCP | Git デーモン |
| 9102/TCP | Pages ファイルサーバー |
| 9105/TCP | LFS サーバー |
| 9200/TCP | Elasticsearch |
| 9203/TCP | セマンティックコードサービス |
| 9300/TCP | Elasticsearch |
| 11211/TCP | Memcache |
| 161/UDP | SNMP |
| 8125/UDP | Statsd |
| 8301/UDP | Consul |
| 8302/UDP | Consul |
| 25827/UDP | Collectd |
ロードバランサの設定
ノード間のトラフィックの分配には、PROXY プロトコルをサポートする TCP ベースの外部ロードバランサをおすすめします。 以下のロードバランサ設定を検討してください:
- TCP ポート (以下に示す) は、
web-serverサービスを実行しているノードに転送する必要があります。 これらは、外部クライアント要求を処理する唯一のノードです。 - スティッキーセッションは有効化してはなりません。
Warning
ロード バランサーの HTTPS 接続を終了する場合、ロード バランサーから GitHub Enterprise Server への要求も HTTPS を使用する必要があります。 接続の HTTP へのダウングレードはサポートされません。
クライアントの接続情報の処理
クラスタへのクライアント接続はロードバランサから行われるため、クライアントの IP アドレスが失われる可能性があります。 クライアント接続情報を正しく取り込むには、追加の検討が必要です。
使用しているロードバランサがサポートできるなら、PROXYプロトコルの利用を強くおすすめします。 PROXY サポートが利用できない場合でも、X-Forwarded-For ヘッダーを使って HTTP および HTTPS ポートを負荷分散できます。
Caution
PROXY サポートまたは HTTP 転送を有効にしている場合、外部のトラフィックが直接 GitHub Enterprise Server アプライアンスに到達できないことが重要です。 外部トラフィックが適切にブロックされていない場合、ソース IP アドレスが偽造されるかもしれません。
GitHub Enterprise Serverでの PROXY サポートの有効化
インスタンスとロードバランサの双方でPROXYサポートを有効化することを強くおすすめします。
Note
GitHub Enterprise Server は、AWS ネットワーク ロード バランサーと互換性のない PROXY プロトコル V1 をサポートしています。 GitHub Enterprise Server で AWS ネットワーク ロード バランサーを使用する場合は、PROXY サポートを有効にしないでください。
-
インスタンスにはこのコマンドを使用してください:
ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply -
ロードバランサでは、ベンダーから提供された手順書に従ってください。
PROXYプロトコルのTCPポートマッピング
| 送信元ポート | 宛先ポート | サービスの説明 |
|---|---|---|
| 22 | 23 | Git over SSH |
| 80 | 81 | HTTP |
| 443 | 444 | HTTPS |
| 8080 | 8081 | Management Console HTTP |
| 8443 | 8444 | Management Console HTTPS |
| 9418 | 9419 | Git |
GitHub Enterprise Serverでの X-Forwarded-For サポートの有効化
X-Forwarded-For プロトコルは、PROXY プロトコルが使用できない場合にのみ使用します。 X-Forwarded-For ヘッダーは HTTP と HTTPS とのみ互換性があります。 SSH経由の Git 接続では、示される IP アドレスは、ロード バランサーの IP を示します。 一部の環境では、インスタンスの監査ログのクライアント IP アドレスが 127.0.0.1 として正しく表示されない場合があります。
X-Forwarded-For ヘッダーを有効にするには、次のコマンドを使用します。
ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-apply
PROXYサポートなしで使うプロトコルのTCPポートマッピング
| 送信元ポート | 宛先ポート | サービスの説明 |
|---|---|---|
| 22 | 22 | Git over SSH |
| 25 | 25 | SMTP |
| 80 | 80 | HTTP |
| 443 | 443 | HTTPS |
| 8080 | 8080 | Management Console HTTP |
| 8443 | 8443 | Management Console HTTPS |
健全性チェックの設定
ロードバランサは健全性チェックによって、事前に設定されたチェックが失敗するようになったノードがあれば、反応しなくなったノードへのトラフィックの送信を止めます。 クラスタのノードに障害が起きた場合、冗長なノードと組み合わさったヘルスチェックが高可用性を提供してくれます。
次の URL をチェックするようにロード バランサーを構成します。
http(s)://HOSTNAME/status
ノードが正常でエンドユーザーからの要求に応えられる場合、このエンドポイントによって状態コード 200 (OK) が返されます。 詳しくは、「High Availability 設定の監視」を参照してください。
Note
アプライアンスがメンテナンス モードの場合、https://HOSTNAME/status の URL からは状態コード 503 (サービス利用不可) が返されます。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。
DNS の要件
GitHub Enterprise Serverのホスト名に対するDNSルックアップは、ロードバランサに解決されなければなりません。 Subdomain Isolationを有効化することをおすすめします。 サブドメイン分離が有効化されている場合、追加のワイルドカード レコード (*.HOSTNAME) もロード バランサーに解決されなければなりません。 詳しくは、「Subdomain Isolationの有効化」を参照してください。