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

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

GitHub Enterprise Server クラスタリングが適切に動作するためには、DNS の名前解決、ロードバランシング、ノード間の通信が適切に行われなければなりません。

ここには以下の内容があります:

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

クラスタリングのための最もシンプルなネットワーク設計は、ノード群を単一のLANに置くことです。 冗長性を持つクラスタが複数のサブネットにまたがってしまう場合は、サブネット間に適切な経路があり、レイテンシが1ms以下でなければなりません。

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

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

ポート説明暗号化
22/TCPGit over SSHあり
25/TCPSMTPSTARTTLSが必要
80/TCPHTTPなし
(SSLが有効化されている場合、このポートはHTTPSにリダイレクトされる)
443/TCPHTTPSあり
9418/TCPシンプルなGitプロトコルのポート
(プライベートモードでは無効化される)
なし

管理ポート

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

ポート説明暗号化
ICMPICMP Pingなし
122/TCP管理SSHあり
161/UDPSNMPなし
8080/TCPManagement Console HTTPなし
(SSLが有効化されている場合、このポートはHTTPSにリダイレクトされる)
8443/TCPManagement Console HTTPSあり

クラスタ通信ポート

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

ポート説明
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サポートを有効化することを強くおすすめします。

  • インスタンスにはこのコマンドを使用してください:

    $ 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 サポートの有効化

PROXYプロトコルが利用できないときにかぎりX-Forwarded-Forプロトコルを利用してください。 X-Forwarded-Forは、HTTP及びHTTPSでのみ動作します。 SSH経由のGit接続で示されるIPアドレスは、ロードバランサのIPを示します。

X-Fowarded-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のいずれかをチェックするようにロードバランサを設定してください。

  • https://HOSTNAME/status HTTPSが有効な場合(デフォルト)
  • http://HOSTNAME/status HTTPSが無効な場合

ノードが健全でエンドユーザーからのリクエストに応えられる場合、このチェックにはステータスコード200(OK)が返されます。

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

DNSの要求事項

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

担当者にお尋ねください

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

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