ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。
記事のバージョン: Enterprise Server 2.15

このバージョンの GitHub Enterprise はこの日付をもって終了となります: このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2019-10-16. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 For better performance, improved security, and new features, upgrade to the latest version of GitHub Enterprise. For help with the upgrade, contact GitHub Enterprise support.

ネットワークの設定

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 ベースの外部ロードバランサをおすすめします。 以下のロードバランサ設定を検討してください:

Warning: When terminating HTTPS connections on a load balancer, the requests from the load balancer to GitHub Enterprise Server also need to use HTTPS. Downgrading the connection to HTTP is not supported.

クライアントの接続情報の処理

クラスタへのクライアント接続はロードバランサから行われるため、クライアントの IP アドレスが失われる可能性があります。 クライアント接続情報を正しく取り込むには、追加の検討が必要です。

If your load balancer can support it, we strongly recommend implementing the PROXY protocol. When no PROXY support is available, it is also possible to load balance the HTTP and HTTPS ports using the X-Forwarded-For header.

Security Warning: When either PROXY support or HTTP forwarding is enabled, it is critical that no external traffic can directly reach the GitHub Enterprise Server appliances. If external traffic is not properly blocked, the source IP addresses can be forged.

GitHub Enterprise Serverでの PROXY サポートの有効化

インスタンスとロードバランサの双方でPROXYサポートを有効化することを強くおすすめします。

PROXY protocol TCP port mappings
Source port Destination port Service description
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 サポートの有効化

Use the X-Forwarded-For protocol only when the PROXY protocol is unavailable. The X-Forwarded-For header only works with HTTP and HTTPS. The IP address reported for Git connections over SSH will show the load balancer IP.

X-Fowarded-For ヘッダを有効化するには、次のコマンドを使用します:

$ ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-apply
Protocol TCP port mappings for use without PROXY support
Source port Destination port Service description
22 22 Git over SSH
25 25 SMTP
80 80 HTTP
443 443 HTTPS
8080 8080 Management Console HTTP
8443 8443 Management Console HTTPS

ヘルスチェックの設定

ロードバランサは健全性チェックによって、事前に設定されたチェックが失敗するようになったノードがあれば、反応しなくなったノードへのトラフィックの送信を止めます。 クラスタのノードに障害が起きた場合、冗長なノードと組み合わさったヘルスチェックが高可用性を提供してくれます。

Configure the load balancer to check one of these URLs:

The check will return status code 200 (OK) if the node is healthy and available to service end-user requests.

メモ: アプライアンスがメンテナンスモードになっている場合、URL の https://HOSTNAME/status はステータスコード 503 (Service Unavailable) を返します。詳しい情報については「メンテナンスモードの有効化とスケジューリング」を参照してください。

DNSの要求事項

DNS lookups for the GitHub Enterprise Server hostname should resolve to the load balancer. We recommend that you enable subdomain isolation. If subdomain isolation is enabled, an additional wildcard record (*.HOSTNAME) should also resolve to the load balancer. 詳しい情報については"Subdomain Isolationの有効化"を参照してください。

担当者にお尋ねください

探しているものが見つからなかったでしょうか?

弊社にお問い合わせください