Skip to main content

クラスタのネットワーク設定

A GitHub Enterprise Server cluster requires proper DNS name resolution, load balancing, and communication between nodes.

この機能を使用できるユーザーについて

GitHub はクラスタリングの適格性を決定し、インスタンスのライセンスの構成を有効にする必要があります。 クラスタリングには、慎重な計画と追加の管理オーバーヘッドが必要です。 詳しくは、「クラスタリングについて」を参照してください。

GitHub Enterprise Server クラスターのネットワークについて

GitHub Enterprise Server クラスター内の各ノードは、ネットワーク経由でクラスター内の他のすべてのノードと通信可能である必要があります。 エンド ユーザー、管理、およびノード間の通信に必要なポートとプロトコルを確認できます。 フロントエンド ノード間でトラフィックを分散するために、GitHub では、外部ロード バランサーを構成することをお勧めします。

ネットワークに関する考慮事項

クラスタリングのための最もシンプルなネットワーク設計は、ノード群を単一のLANに置くことです。 クラスタがサブネットワークにまたがる必要がある場合は、ネットワーク間にファイアウォールルールを設定することはお勧めしません。 ノード間の遅延は 1 ミリ秒未満である必要があります。

高可用性を実現するには、アクティブ ノードを持つネットワークとパッシブ ノードを持つネットワーク間の待機時間が 70 ミリ秒未満である必要があります。 2 つのネットワーク間にファイアウォールを設定することはお勧めしません。

エンドユーザーのためのアプリケーションポート

アプリケーションのポートは、エンドユーザーにWebアプリケーションとGitへのアクセスを提供します。

Port説明Encrypted
22/TCPGit over SSH
25/TCPSMTPSTARTTLSが必要
80/TCPHTTP

SSL が有効になっている場合、このポートは HTTPS にリダイレクトされます
443/TCPHTTPS
9418/TCP単純な Git プロトコル ポート
(プライベート モードでは無効)

管理ポート

管理ポートは、エンドユーザが基本的なアプリケーションを利用するためには必要ありません。

Port説明Encrypted
ICMPICMP Ping
122/TCP管理SSH
161/UDPSNMP
8080/TCPManagement Console HTTP

SSL が有効になっている場合、このポートは HTTPS にリダイレクトされます
8443/TCPManagement Console HTTPS

クラスタ通信ポート

ネットワークレベルのファイアウォールがノード間にある場合は、これらのポートがアクセス可能である必要があります。 ノード間の通信は暗号化されていません。 これらのポートは外部からアクセスできません。

Port説明
1336/TCP内部 API
3033/TCP内部 SVN アクセス
3037/TCP内部 SVN アクセス
3306/TCPMySQL
4486/TCPGovernor アクセス
5115/TCPストレージ バックエンド
5208/TCP内部 SVN アクセス
6379/TCPRedis
8001/TCPGrafana
8090/TCP内部 GPG アクセス
8149/TCPGitRPC ファイルサーバーアクセス
8300/TCPConsul
8301/TCPConsul
8302/TCPConsul
9000/TCPGit デーモン
9102/TCPPages ファイルサーバー
9105/TCPLFS サーバー
9200/TCPElasticsearch
9203/TCPセマンティックコードサービス
9300/TCPElasticsearch
11211/TCPMemcache
161/UDPSNMP
8125/UDPStatsd
8301/UDPConsul
8302/UDPConsul
25827/UDPCollectd

ロードバランサの設定

ノード間のトラフィックの分配には、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ポートマッピング

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

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-apply

PROXYサポートなしで使うプロトコルのTCPポートマッピング

送信元ポート宛先ポートサービスの説明
2222Git over SSH
2525SMTP
8080HTTP
443443HTTPS
80808080Management Console HTTP
84438443Management Console HTTPS

健全性チェックの設定

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

次の URL をチェックするようにロード バランサーを構成します。

http(s)://HOSTNAME/status

ノードが正常でエンドユーザーからの要求に応えられる場合、このエンドポイントによって状態コード 200 (OK) が返されます。 詳しくは、「High Availability 設定の監視」を参照してください。

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

DNS の要件

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