ネットワークに関する考慮
クラスタリングのための最もシンプルなネットワーク設計は、ノード群を単一のLANに置くことです。 クラスタがサブネットワークにまたがる必要がある� �合は、ネットワーク間にファイアウォールルールを設定することはお勧めしません。 ノード間の遅延は 1 ミリ秒未満である必要があります。
High Availability を実現するには、アクティブノードを備えたネットワークとパッシブノードを備えたネットワーク間の遅延が 70 ミリ秒未満である必要があります。 2 つのネットワーク間にファイアウォールを設定することはお勧めしません。
エンドユーザーのためのアプリケーションポート
アプリケーションのポートは、エンドユーザーに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 ファイルサーバーアクセス |
| 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サービスを実行しているノードに転送される必要があります。 これらは、外部クライアント要求を処理する唯一のノードです。 - スティッキーセッションは有効化してはなりません。
警告: 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サポートを有効化することを強くおすすめします。
Note: GitHub Enterprise Server supports PROXY Protocol V1, which is incompatible with AWS Network Load Balancers. If you use AWS Network Load Balancers with GitHub Enterprise Server, do not enable PROXY support.
-
インスタンスにはこのコマンドを使用してく� さい:
$ 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 サポートの有効化
PROXYプロトコルが利用できないときにかぎりX-Forwarded-Forプロトコルを利用してく� さい。 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-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://HOSTNAME/statusHTTPSが有効な� �合（デフォルト）http://HOSTNAME/statusHTTPSが無効な� �合
ノードが健全でエンドユーザーからのリクエストに応えられる� �合、このチェックにはステータスコード200（OK）が返されます。
ノート： アプライアンスがメンテナンスモードの� �合、https://HOSTNAME/statusのURLはステータスコード503（Service Unavailable）を返します。 詳しい情� �については"メンテナンスモードの有効化とスケジューリング"を参照してく� さい。
DNSの要求事� �
GitHub Enterprise Serverのホスト名に対するDNSルックアップは、ロードバランサに解決されなければなりません。 Subdomain Isolationを有効化することをおすすめします。 Subdomain Isolationが有効化されている� �合、追� のワイルドカードレコード(*.HOSTNAME)もロードバランサに解決されなければなりません。 詳しい情� �については"Subdomain Isolationの有効化"を参照してく� さい。