ネットワークの設定
GitHub Enterprise Server クラスタリングが適切に動作するためには、DNS の名前解決、ロードバランシング、ノード間の通信が適切に行われなければなりません。
ネットワークに関する考慮
クラスタリングのための最もシンプルなネットワーク設計は、ノード群を単一のLANに置くことです。 冗長性を持つクラスタが複数のサブネットにまたがってしまう場合は、サブネット間に適切な経路があり、レイテンシが1ms以下でなければなりません。
エンドユーザーのためのアプリケーションポート
アプリケーションのポートは、エンドユーザーにWebアプリケーションとGitへのアクセスを提供します。
| ポート | 説明 | 暗号化 |
|---|---|---|
| 22/TCP | Git over SSH | あり |
| 25/TCP | SMTP | STARTTLSが必要 |
| 80/TCP | HTTP | なし |
| （SSLが有効化されている場合、このポートはHTTPSにリダイレクトされる） | ||
| 443/TCP | HTTPS | あり |
| 9418/TCP | シンプルなGitプロトコルのポート | |
| （プライベートモードでは無効化される） | なし |
管理ポート
管理ポートは、エンドユーザが基本的なアプリケーションを利用するためには必要ありません。
| ポート | 説明 | 暗号化 |
|---|---|---|
| ICMP | ICMP Ping | なし |
| 122/TCP | 管理SSH | あり |
| 161/UDP | SNMP | なし |
| 8080/TCP | Management Console HTTP | なし |
| （SSLが有効化されている場合、このポートはHTTPSにリダイレクトされる） | ||
| 8443/TCP | Management Console HTTPS | あり |
クラスタ通信ポート
ネットワークレベルのファイアウォールがノード間にある場合は、これらのポートがアクセス可能である必要があります。 ノード間の通信は暗号化されていません。 これらのポートは外部からアクセスできません。
| ポート | 説明 |
|---|---|
| 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 ファイルサーバーアクセス |
| 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 |
| 25827/UDP | Collectd |
ロードバランサの設定
ノード間のトラフィックの分配には、PROXY プロトコルをサポートする TCP ベースの外部ロードバランサをおすすめします。 以下のロードバランサ設定を検討してください:
- TCP ポート (下記参照) は
web-serverサービスを実行しているノードに転送される必要があります。 これらは、外部クライアント要求を処理する唯一のノードです。 - スティッキーセッションは有効化してはなりません。
警告: HTTPS 接続をロードバランサでターミネートしている場合、ロードバランサからの GitHub Enterprise Server へのリクエストも HTTPS を使わなければなりません。接続の HTTP へのダウングレードはサポートされません。
クライアントの接続情報の処理
クラスタへのクライアント接続はロードバランサから行われるため、クライアントの IP アドレスが失われる可能性があります。 クライアント接続情報を正しく取り込むには、追加の検討が必要です。
ロードバランサがサポートできるなら、PROXY プロトコルの実装を強くおすすめします。PROXY プロトコルのサポートがない場合でも、X-Forwarded-For ヘッダを使って HTTP および HTTPS ポートをロードバランスすることができます。
セキュリティの警告: PROXY サポートあるいは HTTP フォワーディングが有効化されている場合、外部のトラフィックが直接 GitHub Enterprise Server アプライアンスに到達できないことが重要です。外部トラフィックが適切にブロックされていない場合、ソース IP アドレスが偽造されるかもしれません。
GitHub Enterprise Serverでの PROXY サポートの有効化
インスタンスとロードバランサの双方で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 になります。
X-Fowarded-For ヘッダを有効化するには、次のコマンドを使用します:
$ ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-applyPROXY サポートなしで利用するプロトコルの 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 のいずれかをチェックするようにロードバランサを設定します:
- HTTPSが有効な場合 (デフォルト) は
https://HOSTNAME/status - HTTPS が無効な場合は
http://HOSTNAME/status
ノードが健全でエンドユーザのリクエストに応えることができるのであれば、このチェックにはステータスコード 200 (OK) が返されます。
メモ: アプライアンスがメンテナンスモードになっている場合、URL の https://HOSTNAME/status はステータスコード 503 (Service Unavailable) を返します。詳しい情報については「メンテナンスモードの有効化とスケジューリング」を参照してください。
DNSの要求事項
GitHub Enterprise Server のホスト名への DNS ルックアップは、ロードバランサに解決されなければなりません。Subdomain Isolation を有効化することをおすすめします。Subdomain Isolation が有効化されている場合、追加のワイルドカードレコード (*.HOSTNAME) もロードバランサに解決されなければなりません。詳細は「Subdomain Isolation を有効化する」を参照してください。