Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となります: 2023-01-18. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

Cluster network configuration

GitHub Enterprise Server clustering relies on proper DNS name resolution, load balancing, and communication between nodes to operate properly.

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.

PortDescriptionEncrypted
22/TCPGit over SSHYes
25/TCPSMTPRequires STARTTLS
80/TCPHTTPNo
(When SSL is enabled this port redirects to HTTPS)
443/TCPHTTPSYes
9418/TCPSimple Git protocol port
(Disabled in private mode)
No

Administrative ports

Administrative ports are not required for basic application use by end users.

PortDescriptionEncrypted
ICMPICMP PingNo
122/TCPAdministrative SSHYes
161/UDPSNMPNo
8080/TCPManagement Console HTTPNo
(When SSL is enabled this port redirects to HTTPS)
8443/TCPManagement Console HTTPSYes

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.

PortDescription
1336/TCPInternal API
3033/TCPInternal SVN access
3037/TCPInternal SVN access
3306/TCPMySQL
4486/TCPGovernor access
5115/TCPStorage backend
5208/TCPInternal SVN access
6379/TCPRedis
8001/TCPGrafana
8090/TCPInternal GPG access
8149/TCPGitRPC file server access
8300/TCPConsul
8301/TCPConsul
8302/TCPConsul
9000/TCPGit Daemon
9102/TCPPages file server
9105/TCPLFS server
9200/TCPElasticsearch
9203/TCPSemantic code service
9300/TCPElasticsearch
11211/TCPMemcache
161/UDPSNMP
8125/UDPStatsd
8301/UDPConsul
8302/UDPConsul
25827/UDPCollectd

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-server service. 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ポートマッピング

送信元ポート宛先ポートサービスの説明
2223Git over SSH
8081HTTP
443444HTTPS
80808081Management Console HTTP
84438444Management Console HTTPS
94189419Git

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ポートマッピング

送信元ポート宛先ポートサービスの説明
2222Git over SSH
2525SMTP
8080HTTP
443443HTTPS
80808080Management Console HTTP
84438443Management 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のいずれかをチェックするようにロードバランサを設定してください。

  • https://HOSTNAME/status HTTPS が有効な場合 (既定)
  • http://HOSTNAME/status HTTPS が無効な場合

ノードが正常でエンドユーザーからの要求に応えられる場合、このチェックによって状態コード 200 (OK) が返されます。

注: アプライアンスがメンテナンス モードの場合、https://HOSTNAME/status URL は状態コード 503 (サービス利用不可) を返します。 詳細については、「メンテナンスモードの有効化とスケジューリング」を参照してください。

DNS Requirements

GitHub Enterprise Serverのホスト名に対するDNSルックアップは、ロードバランサに解決されなければなりません。 Subdomain Isolationを有効化することをおすすめします。 サブドメイン分離が有効化されている場合、追加のワイルドカード レコード (*.HOSTNAME) もロード バランサーに解決されなければなりません。 詳細については、「サブドメイン分離の有効化」を参照してください。