About networking for a GitHub Enterprise Server cluster
Each node in your GitHub Enterprise Server cluster must be able to communicate with all of the other nodes in the cluster over the network. You can review the required ports and protocols for end users, administration, and communication between nodes. To distribute traffic among front-end nodes, GitHub recommends that you configure an external load balancer.
Network considerations
The simplest network design for clustering is to place the nodes on a single LAN. If a cluster must span subnetworks, we do not recommend configuring any firewall rules between the networks. The latency between nodes should be less than 1 millisecond.
高可用性を実現するには、アクティブ ノードを持つネットワークとパッシブ ノードを持つネットワーク間の待機時間が 70 ミリ秒未満である必要があります。 2 つのネットワーク間にファイアウォールを設定することはお勧めしません。
Application ports for end users
Application ports provide web application and Git access for end users.
| Port | Description | Encrypted |
|---|---|---|
| 22/TCP | Git over SSH | |
| 25/TCP | SMTP | Requires STARTTLS |
| 80/TCP | HTTP | When SSL is enabled this port redirects to HTTPS |
| 443/TCP | HTTPS | |
| 9418/TCP | Simple Git protocol port (Disabled in private mode) |
Administrative ports
Administrative ports are not required for basic application use by end users.
| Port | Description | Encrypted |
|---|---|---|
| ICMP | ICMP Ping | |
| 122/TCP | Administrative SSH | |
| 161/UDP | SNMP | |
| 8080/TCP | Management Console HTTP | When SSL is enabled this port redirects to HTTPS |
| 8443/TCP | Management Console HTTPS |
Cluster communication ports
If a network level firewall is in place between nodes, these ports will need to be accessible. The communication between nodes is not encrypted. These ports should not be accessible externally.
| Port | Description |
|---|---|
| 1336/TCP | Internal API |
| 3033/TCP | Internal SVN access |
| 3037/TCP | Internal SVN access |
| 3306/TCP | MySQL |
| 4486/TCP | Governor access |
| 5115/TCP | Storage backend |
| 5208/TCP | Internal SVN access |
| 6379/TCP | Redis |
| 8001/TCP | Grafana |
| 8090/TCP | Internal GPG access |
| 8149/TCP | GitRPC file server access |
| 8300/TCP | Consul |
| 8301/TCP | Consul |
| 8302/TCP | Consul |
| 9000/TCP | Git Daemon |
| 9102/TCP | Pages file server |
| 9105/TCP | LFS server |
| 9200/TCP | Elasticsearch |
| 9203/TCP | Semantic code service |
| 9300/TCP | Elasticsearch |
| 11211/TCP | Memcache |
| 161/UDP | SNMP |
| 8125/UDP | Statsd |
| 8301/UDP | Consul |
| 8302/UDP | Consul |
| 25827/UDP | Collectd |
Configuring a load balancer
We recommend an external TCP-based load balancer that supports the PROXY protocol to distribute traffic across nodes. Consider these load balancer configurations:
- TCP ports (shown below) should be forwarded to nodes running the
web-serverservice. These are the only nodes that serve external client requests. - Sticky sessions shouldn't be enabled.
警告: ロード バランサーの HTTPS 接続を終了する場合、ロード バランサーから GitHub Enterprise Server への要求も HTTPS を使用する必要があります。 接続の HTTP へのダウングレードはサポートされません。
Handling client connection information
Because client connections to the cluster come from the load balancer, the client IP address can be lost. To properly capture the client connection information, additional consideration is required.
使用しているロードバランサがサポートできるなら、PROXYプロトコルの利用を強くおすすめします。 PROXY サポートが利用できない場合でも、X-Forwarded-For ヘッダーを使って HTTP および HTTPS ポートを負荷分散できます。
セキュリティの警告: PROXY サポートあるいは HTTP フォワーディングが有効化されている場合、外部のトラフィックが直接 GitHub Enterprise Server アプライアンスに到達できないことが重要です。 外部トラフィックが適切にブロックされていない場合、ソース IP アドレスが偽造されるかもしれません。
Enabling PROXY support on GitHub Enterprise Server
We strongly recommend enabling PROXY support for both your instance and the load balancer.
注: GitHub Enterprise Server は、AWS ネットワーク ロード バランサーと互換性のない PROXY プロトコル V1 をサポートしています。 GitHub Enterprise Server で AWS ネットワーク ロード バランサーを使用する場合は、PROXY サポートを有効にしないでください。
-
For your instance, use this command:
ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply -
For the load balancer, use the instructions provided by your vendor.
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 |
Enabling X-Forwarded-For support on GitHub Enterprise Server
X-Forwarded-For プロトコルは、PROXY プロトコルが使用できない場合にのみ使用します。 X-Forwarded-For ヘッダーは HTTP と HTTPS でのみ機能します。 SSH経由のGit接続で示されるIPアドレスは、ロードバランサのIPを示します。
To enable the X-Forwarded-For header, use this command:
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 |
Configuring health checks
Health checks allow a load balancer to stop sending traffic to a node that is not responding if a pre-configured check fails on that node. If a cluster node fails, health checks paired with redundant nodes provides high availability.
次の URL をチェックするようにロード バランサーを構成します。
http(s)://HOSTNAME/status
ノードが正常でエンドユーザーからの要求に応えられる場合、このエンドポイントによって状態コード 200 (OK) が返されます。 詳しくは、「Monitoring a high-availability configuration」を参照してください。
注: アプライアンスがメンテナンス モードの場合、https://HOSTNAME/status URL は状態コード 503 (サービス利用不可) を返します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。
DNS requirements
GitHub Enterprise Serverのホスト名に対するDNSルックアップは、ロードバランサに解決されなければなりません。 Subdomain Isolationを有効化することをおすすめします。 サブドメイン分離が有効化されている場合、追加のワイルドカード レコード (*.HOSTNAME) もロード バランサーに解決されなければなりません。 詳しくは、「Subdomain Isolationの有効化」を参照してください。