Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2023-01-18. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせく� さい

GitHub Enterprise Server でロードバランサを使用する

ロード バランサーを、単一の GitHub Enterprise Server インスタンス、あるいは高可用性構成のインスタンスのペアの前で使ってく� さい。

ロード バランサーについて

ロードバランサの設計では、ネットワークデバイスを使ってGit及びHTTPのトラフィックを個々のGitHub Enterprise Serverアプライアンスに向かわせます。 ロードバランサを使って、セキュリティのためにアプライアンスへの直接のトラフィックを制限したり、必要に応じてDNSのレコードを変更することなくトラフィックをリダイレクトしたりできます。 PROXYプロトコルをサポートするTCPベースのロードバランサを使うことを強くおすすめします。

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

クライアントの接続情� �の処理

GitHub Enterprise Server へのクライアント接続はロードバランサから来ることになるため、クライアントの IP アドレスは失われることがあります。

使用しているロードバランサがサポートできるなら、PROXYプロトコルの利用を強くおすすめします。 PROXY サポートが利用できない� �合でも、X-Forwarded-For ヘッダーを使って HTTP および HTTPS ポートを� 荷分散できます。

セキュリティの警告: PROXY サポートあるいは HTTP フォワーディングが有効化されている� �合、外部のトラフィックが直接 GitHub Enterprise Server アプライアンスに到達できないことが重要です。 外部トラフィックが適切にブロックされていない� �合、ソース IP アドレスが偽� されるかもしれません。

警告: ロード バランサーの HTTPS 接続を終了する� �合、ロード バランサーから GitHub Enterprise Server への要求も HTTPS を使用する必要があります。 接続の HTTP へのダウングレードはサポートされません。

での PROXY プロトコル サポートの有効化

インスタンスとロード バランサーの両方で PROXY プロトコル サポートを有効にすることを強くおすすめします。 ロードバランサでPROXYプロトコルを有効化する方法については、ベンダーが提供する指示に従ってく� さい。 詳細については、PROXY プロトコルのドキュメントを参照してく� さい。

注: GitHub Enterprise Server は、AWS ネットワーク ロード バランサーと互換性のない PROXY プロトコル V1 をサポートしています。 GitHub Enterprise Server で AWS ネットワーク ロード バランサーを使用する� �合は、PROXY サポートを有効にしないでく� さい。

  1. GitHub Enterprise Server の管理アカウントから、任意のページの右上隅の をクリックします。

    サイト管理者設定にアクセスするための宇宙船アイコンのスクリーンショット

  2. [サイト管理者] ページにま� 表示されていない� �合は、左上隅の [サイト管理者] をクリックします。

    [サイト管理者] リンクのスクリーンショット 1. 左側のサイドバーで、 [Management Console] をクリックします。 左側のサイドバーの [[Management Console]] タブ 1. 左側のサイドバーで、 [プライバシー] をクリックします。 設定サイドバーの [プライバシー] タブ

  3. [外部ロード バランサー] で、 [PROXY プロトコルのサポートを有効にする] を選択します。 PROXY プロトコルのサポートを有効にするチェックボックス 1. 左側のサイドバーで、 [設定の保存] をクリックします。

    [Management Console] の [設定の保存] ボタンのスクリーンショット

    注: [Management Console] に設定を保存すると、システ�  サービスが再起動され、ユーザーに表示されるダウンタイ� が発生する可能性があります。

  4. 設定の実行が完了するのを待ってく� さい。

    インスタンスの設定

PROXYプロトコルのTCPポートマッピング

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

での X-Forwarded-For サポートの有効化

X-Forwarded-For プロトコルは、PROXY プロトコルが使用できない� �合に のみ 使用します。 X-Forwarded-For ヘッダーは HTTP と HTTPS でのみ機能します。 SSH経由のGit接続で示されるIPアドレスは、ロードバランサのIPを示します。

警告: とロード バランサーの X-Forwarded-For サポートを構成すると、[Management Console] に接続できない可能性があります。 詳しくは、「エラー: [Management Console] への接続の "セッションの有効期限が切れています"」を参照してく� さい。

  1. GitHub Enterprise Server の管理アカウントから、任意のページの右上隅の をクリックします。

    サイト管理者設定にアクセスするための宇宙船アイコンのスクリーンショット

  2. [サイト管理者] ページにま� 表示されていない� �合は、左上隅の [サイト管理者] をクリックします。

    [サイト管理者] リンクのスクリーンショット 1. 左側のサイドバーで、 [Management Console] をクリックします。 左側のサイドバーの [[Management Console]] タブ 1. 左側のサイドバーで、 [プライバシー] をクリックします。 設定サイドバーの [プライバシー] タブ

  3. [外部ロード バランサー] で、 [HTTP X-Forwarded-For ヘッダーを許可する] を選択します。 HTTP X-Forwarded-For ヘッダーを許可するチェックボックス 1. 左側のサイドバーで、 [設定の保存] をクリックします。

    [Management Console] の [設定の保存] ボタンのスクリーンショット

    注: [Management Console] に設定を保存すると、システ�  サービスが再起動され、ユーザーに表示されるダウンタイ� が発生する可能性があります。

  4. 設定の実行が完了するのを待ってく� さい。

    インスタンスの設定

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

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

健全性チェックの設定

ロードバランサは健全性チェックによって、事前に設定されたチェックが失敗するようになったノードがあれば、反応しなくなったノードへのトラフィックの送信を止めます。 メンテナンスもしくは予想外の障害のためにインスタンスがオフラインになっている� �合、ロード バランサーでは状態ページを表示できます。 High Availability(HA)設定では、ロードバランサはフェイルオーバーの戦略の一部として利用できます。 た� し、HAペアの自動フェイルオーバーはサポートされていません。 レプリカ インスタンスは、手動で昇� �させると要求に応えられるようになります。 詳細については、高可用性のための GitHub Enterprise Server の構成に関するページを参照してく� さい。

以下のURLのいずれかをチェックするようにロードバランサを設定してく� さい。

  • https://HOSTNAME/status HTTPS が有効な� �合 (既定)
  • http://HOSTNAME/status HTTPS が無効な� �合

ノードが正常でエンドユーザーからの要求に応えられる� �合、このチェックによって状態コード 200 (OK) が返されます。

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

ロード バランサーを介した接続のトラブルシューティング

ロード バランサーを介して 上のサービスに接続できない� �合は、次の情� �を確認して問題のトラブルシューティングを行うことができます。

: ステージング環境でネットワーク インフラストラクチャとインスタンス構成に対する変更を常にテストします。 詳細については、「ステージング インスタンスの設定」を参照してく� さい。

エラー: [Management Console] への接続の "セッションの有効期限が切れています"

インスタンスとロード バランサーで X-Forwarded-For ヘッダーのサポートを有効にした� �合、インスタンスの [Management Console] にアクセスできない可能性があります。 [Management Console] と接続に必要なポートについて詳しくは、「管理コンソールへのアクセス」と「ネットワーク ポート」を参照してく� さい。

が、ロード バランサーを介して [Management Console] に接続したときにセッションの有効期限が切れたことが示されている� �合は、ロード バランサーで次のいずれかの構成を試してく� さい。

  • ポート 8080 と 8443 でインスタンスへの接続の X-Forwarded-For ヘッダーを無効にします。
  • レイヤー 4 で動作するようにロード バランサーを構成し、クライアント IP アドレスのパススルーの X-Forwarded-For ではなく PROXY プロトコルを使用します。 詳しくは、「 での PROXY プロトコル サポートの有効化」を参照してく� さい。

詳しくは、ロード バランサーのドキュメントを参照してく� さい。

issue とチェックの実行に対するライブ更新が機能しない

にロード バランサーまたはリバース プロキシ経由でアクセスすると、issue に関する新しいコメントや通知バッジの変更や実行出力の確認などの予想されるライブ更新が、ページが更新されるまで表示されない� �合があります。 これは、リバース プロキシまたはロード バランサーがレイヤー 7 モードで実行されているか、必要な Websocket プロトコルをサポートしていない� �合によくあります。

ライブ更新を有効にするには、ロード バランサーまたはプロキシを再構成する必要がある� �合があります。 詳しくは、ロード バランサーのドキュメントを参照してく� さい。