ネットワークに関する考慮事� �
クラスタリングのための最もシンプルなネットワーク設計は、ノード群を単一のLANに置くことです。 クラスタがサブネットワークにまたがる必要がある� �合は、ネットワーク間にファイアウォールルールを設定することはお勧めしません。 ノード間の遅延は 1 ミリ秒未満である必要があります。
高可用性を実現するには、アクティブ ノードを備えたネットワークとパッシブ ノードを備えたネットワーク間の待ち時間が 70 ミリ秒未満である必要があります。 2 つのネットワーク間にファイアウォールを設定することはお勧めしません。
エンドユーザーのためのアプリケーションポート
アプリケーションのポートは、エンドユーザーにWebアプリケーションとGitへのアクセスを提供します。
| Port | 説明 | Encrypted |
|---|---|---|
| 22/TCP | Git over SSH | Yes |
| 25/TCP | SMTP | STARTTLSが必要 |
| 80/TCP | HTTP | No (SSL が有効になっている� �合、このポートは HTTPS にリダイレクトされます) |
| 443/TCP | HTTPS | Yes |
| 9418/TCP | 単純な Git プロトコル ポート (プライベート モードでは無効) | No |
管理ポート
管理ポートは、エンドユーザが基本的なアプリケーションを利用するためには必要ありません。
| Port | 説明 | Encrypted |
|---|---|---|
| ICMP | ICMP Ping | No |
| 122/TCP | 管理SSH | Yes |
| 161/UDP | SNMP | No |
| 8080/TCP | Management Console HTTP | No (SSL が有効になっている� �合、このポートは HTTPS にリダイレクトされます) |
| 8443/TCP | Management Console HTTPS | Yes |
クラスタ通信ポート
ネットワークレベルのファイアウォールがノード間にある� �合は、これらのポートがアクセス可能である必要があります。 ノード間の通信は暗号化されていません。 これらのポートは外部からアクセスできません。
| Port | 説明 |
|---|---|
| 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サポートを有効化することを強くおすすめします。
注: GitHub Enterprise Server は、AWS ネットワーク ロード バランサーと互換性のない PROXY プロトコル V1 をサポートしています。 GitHub Enterprise Server で AWS ネットワーク ロード バランサーを使用する� �合は、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-Forwarded-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://HOSTNAME/statusHTTPS が有効な� �合 (既定)http://HOSTNAME/statusHTTPS が無効な� �合
ノードが正常でエンドユーザーからの要求に応えられる� �合、このチェックによって状態コード 200 (OK) が返されます。
注: アプライアンスがメンテナンス モードの� �合、https://HOSTNAME/status URL は状態コード 503 (サービス利用不可) を返します。 詳細については、「メンテナンスモードの有効化とスケジューリング」を参照してく� さい。
DNS の要件
GitHub Enterprise Serverのホスト名に対するDNSルックアップは、ロードバランサに解決されなければなりません。 Subdomain Isolationを有効化することをおすすめします。 サブドメイン分離が有効化されている� �合、追� のワイルドカード レコード (*.HOSTNAME) もロード バランサーに解決されなければなりません。 詳細については、「サブドメイン分離の有効化」を参照してく� さい。