IBM Cloud Docs
Satellite ホスト用の HTTP プロキシーの構成

Satellite ホスト用の HTTP プロキシーの構成

Satellite ホストからのすべてのアウトバウンド・トラフィックがプロキシーを経由するように HTTP プロキシーを構成できます。

HTTP プロキシーのセットアップは、許可リストに登録されているアカウントでのみ使用できます。

HTTP プロキシーを使用するには、どのタイプのロケーションを使用する必要がありますか?

以下のタイプのロケーションを考慮してください。

既存の RHEL ベースのロケーション
プロキシーをセットアップするには、ロケーションで Red Hat CoreOS (RHCOS) が有効になっている必要があります。 既存のロケーションが RHCOS 対応でない場合は、HTTP プロキシーを構成できません。 RHCOS 対応のロケーションを作成してから、HTTP プロキシーの構成を作成します。
ホストが接続されている既存の Red Hat CoreOS 対応ロケーション
HTTP プロキシーをセットアップするには、まず、ロケーションからホストの削除を行う必要があります。 ホストを削除した後、HTTP プロキシーの構成を参照してください。 ロケーション・コントロール・プレーンを構成するホストも更新する必要があることに注意してください。 Satellite ロケーション・コントロール・プレーン・ホストの更新を参照してください。
新しい Red Hat CoreOS 対応ロケーション
ホストをロケーションに接続する前に、 HTTP プロキシーを構成します

どのタイプのホストを使用できますか?

HTTP プロキシーをセットアップするときに、RHEL または Red Hat CoreOS ホストを使用できます。 コントロール・プレーンを構成するホストを含め、ロケーションに接続されている各ホストを編集する必要があります。 proxy.conf ファイルに http または https を含めることを忘れないでください。

HTTP プロキシーについて他に知っておく必要があることは何ですか?

Satellite ロケーションおよびクラスターがプロキシーと連動するには、 Satellite ロケーションにデプロイされたコントロール・プレーン・インフラストラクチャー・ノード上の kubelet が、 IBM Cloud コントロール・プレーン・ノード API サーバーと通信できる必要があります。 この通信を有効にするには、以下のいずれかの要件を満たす必要があります。

  • オプション 1: 削減されたファイアウォール接続スクリプトを使用します。

  • オプション 2: 現行プロキシーは、長時間存続する TCP 接続 (TCP トンネリング) をサポートできます。

  • オプション 3: 長期 TCP 接続をサポートする Satellite ホストと同じネットワーク内の VSI に 2 次プロキシーを作成できます。

  • オプション 4: TCP 接続を許可するためにファイアウォール・アウトバウンドを開くことができます。 詳しくは、 すべてのリージョンのホストに必要なアウトバウンド接続 を参照してから、リージョンに固有のアウトバウンド・ネットワーク要件を確認してください。

ワーカーからマスターへの通信用、またはパッケージ・ミラーへの接続用に HTTP プロキシーを構成することはできません。

TCP トンネリングのセットアップ

プロキシーは、TCP トンネリングを使用してセットアップする必要があります。 特定のステップはプロバイダーによって異なる場合がありますが、TCP トンネリングをセットアップするには、以下の一般的なステップに従ってください。

  1. 4 つのロケーション・パブリック・サービス・エンドポイントすべてのトラフィックをトンネリングするように HTTP プロキシーをセットアップします。 エンドポイントを見つけるには、

    ibmcloud sat location get --location LOCATION_NAME
    

    出力で、パブリック・サービス・エンドポイント URL フィールドを見つけます。 そのフィールドから、エンドポイントを派生させることができます。 例えば、フィールド値がhttps://c131-e.us-south.satellite.cloud.ibm.com:31726の場合、エンドポイントはhttps://c131-1.us-south.satellite.cloud.ibm.com:31726https://c131-2.us-south.satellite.cloud.ibm.com:31726、およびhttps://c131-3.us-south.satellite.cloud.ibm.com:31726です。

  2. HTTP プロキシーのリスナー・ポートが IBM Cloudと同じであることを確認してください。

  3. すべての Satellite ホスト上の/etc/hostsを更新して、IBM Cloud エンドポイントではなくプロキシーにトラフィックを転送するロケーション・パブリック・サービス・エンドポイントを含めます。

ご使用の構成は、プロバイダーによって異なる場合があります。 ご使用のインフラストラクチャーで構成が機能するように、Satellite 環境の外部でプロキシーをセットアップすることを検討してください。 次に、Satellite 環境でプロキシーを構成します。 HTTP プロキシーのセットアップおよび構成について詳しくは、ブログ Proxying In Cluster Kube-APIServer Traffic in IBM Cloud Satelliteを参照してください。

許可リストへのアクセスの要求

HTTP プロキシーの許可リストにアクセスするには、 IBM サポートに チケットを作成 してください。

例えば、以下の要求をテンプレートとして使用します。

Title: Request for addition of HTTP_PROXY config to
       location <LOCATION_ID>

Request Body:
We are requesting the following HTTP_PROXY info be added to
the location_ID listed in the title of this ticket.

Use the following HTTP_PROXY info
BE SURE to include the protocol (http:// or https://)
AND the port (`:PORT_NUMBER`) in the endpoint.


HTTP_PROXY: https://my-proxy-endpoint.com:PORT_NUMBER
HTTPS_PROXY: https://my-proxy-endpoint.com:PORT_NUMBER

サポートがチケットを処理した後、ロケーションが更新されたことを示す通知を受け取ります。 変更が必要な場合は、新しいパラメーターを指定して新しいチケットをオープンする必要があります。 ibmcloud sat locationsを実行してLOCATIONIDを見つけます。

HTTP プロキシーの構成

HTTP プロキシーを構成するには、コントロール・プレーン内のホストを含め、各ホストを編集する必要があります。 コントロール・プレーンを構成するホストを含め、ホストが既にロケーションに接続されている場合は、編集する前に場所からそれらを削除するする必要があります。 プロキシーを構成した後、ロケーションへのホストの再接続。 コントロール・プレーン・ホストの更新について詳しくは、 Satellite ロケーション・コントロール・プレーン・ホストの更新 を参照してください。

  1. プロキシーに使用する ミラー・ロケーション を選択します。 このミラー・ロケーションは、プロキシーのセットアップ時に使用されます。

  2. NO_PROXYの値を見つけます。

    • コントロール・プレーン・ホストの場合、RHCOS には172.20.0.1、RHEL にはNO_PROXY=172.20.0.1,$<REDHAT_PACKAGE_MIRROR_LOCATION>を使用します。

    • Red Hat OpenShift ホストの場合、NO_PROXY for Red Hat OpenShift ホストには、Red Hat OpenShift クラスターに使用されるサービス・サブネットの最初の IP が含まれている必要があります。 この IP を見つけるには、**cluster get**コマンドを実行します。

      ibmcloud ks cluster get --cluster <ClusterID>
      

      出力例

      Name:                           hyp-20220306-1-d2   
      ID:                             <ClusterID>  
      ...
      Service Subnet:                 172.21.0.0/16
      ...
      

      この出力から、最初の IP は 172.21.0.1 であることに注意してください。この例では、RHEL ホストの場合は NO_PROXY=172.20.0.1,172.21.0.1,$REDHAT_PACKAGE_MIRROR_LOCATION 、RHCOS ホストの場合は NO_PROXY=172.20.0.1,172.21.0.1,.REGION.satellite.appdomain.cloud 、この特定のクラスターに関連付けられているホストの完全な出力が作成されます。 例えば、 NO_PROXY=172.20.0.1,172.21.0.1,.eu-gb.satellite.appdomain.cloud は、RHCOS ホストのロンドンのミラー・ロケーションに適しています。 RHCOS 値には、領域の前に . が含まれていることに注意してください。

      ワーカー・ノードからクラスター・サービスへのトラフィックはすべて、 NO_PROXY に含める必要があります。 例えば、イメージ・レジストリー・サービスを使用してイメージを保管するには、ワーカー・ノードごとに image-registry.openshift-image-registry.svcNO_PROXY に追加します。この値はコントロール・プレーンに含める必要はありません。

  3. ホスト上の/etc/systemd/system.conf.dにナビゲートします。 そのファイルが存在しない場合は、以下のコマンドを使用して作成します。 ステップ 2 の<VALUE> for NO_PROXYを入力します。

    mkdir -p /etc/systemd/system.conf.d
    cat >"/etc/systemd/system.conf.d/proxy.conf" <<EOF
    [Manager]
    DefaultEnvironment="HTTP_PROXY=https://my-proxy-endpoint.com:PORT_NUMBER" "HTTPS_PROXY=https://my-proxy-endpoint.com:PORT_NUMBER" "NO_PROXY=<VALUE>"
    EOF
    chmod 0644 /etc/systemd/system.conf.d/proxy.conf
    
  4. 以下のコマンドを実行して、 ibm-proxy.sh ファイルを作成します。 ステップ 2 の<VALUE> for NO_PROXYを入力します。

    mkdir -p /etc/profile.d
    cat >"/etc/profile.d/ibm-proxy.sh" <<EOF
    #!/usr/bin/env bash
    HTTP_PROXY="https://my-proxy-endpoint.com:PORT_NUMBER"
    HTTPS_PROXY="https://my-proxy-endpoint.com:PORT_NUMBER"
    NO_PROXY="<VALUE>"
    export HTTP_PROXY
    export HTTPS_PROXY
    export NO_PROXY
    EOF
    chmod 0755 /etc/profile.d/ibm-proxy.sh
    
  5. この変更を反映するには、ホストをリブートしてください。

  6. ホストをその場所に接続または再接続します。

  7. ホストを、以前に割り当てられていた コントロール・プレーン または サービス に割り当てます。

  8. ホストごとに、これらのステップを繰り返します。

REDHAT_PACKAGE_MIRROR_LOCATIONの値は、Red Hat パッケージ・ミラーの場所によって異なります。 複数のミラーを使用する場合は、REDHAT_PACKAGE_MIRROR_LOCATIONをワイルドカードにすることができます。 詳しくは、 システム全体のプロキシーを適用する方法を参照してください。

共通ミラー・ロケーション

以下のリストは、いくつかの一般的なミラー・ロケーションを示しています。

Azure
個別に定義: rhui-1.microsoft.comrhui-2.microsoft.comrhui-3.microsoft.com
baseurlの下の/etc/yum.repos.d/rh-cloud.repo
Google クラウド・プロバイダー
cds.rhel.updates.googlecloud.com
mirrorlistの下の/etc/yum.repos.d/rh-cloud.repo
Amazon Web サービス
ワイルドカード: aws.ce.redhat.com
rhui3.REGION.aws.ce.redhat.com
mirrorlistの下の/etc/yum.repos.d/redhat-rhui.repo
IBM Cloud
ワイルドカード: service.networklayer.com
dal10: rhncapdal1001.service.networklayer.com
baseurlの下の/etc/yum.repos.d/redhat.repo