Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となります: 2022-09-28. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてください。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してください。

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

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

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

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

High Availability を実現するには、アクティブノードを備えたネットワークとパッシブノードを備えたネットワーク間の遅延が 70 ミリ秒未満である必要があります。 2 つのネットワーク間にファイアウォールを設定することはお勧めしません。

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

アプリケーションのポートは、エンドユーザーに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サポートを有効化することを強くおすすめします。

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ポートマッピング

送信元ポート宛先ポートサービスの説明
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を示します。

To enable the X-Forwarded-For header, use this command:

$ 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の有効化"を参照してください。