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： Satellite ホストと同じネットワーク内にある VSI 上に、長期にわたる TCP 接続をサポートするセカンダリプロキシを作成できます。

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

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

TCP のトンネリング設定

プロキシーは、TCP トンネリングを使用してセットアップする必要があります。 以下の手順は、 TCP のトンネリングに関する一般的な設定について説明したものです。プロバイダ固有の手順については、ご利用のプロバイダのドキュメントをご参照ください。

  1. HTTP プロキシを設定し、4か所のパブリックサービスエンドポイントすべてへのトラフィックをトンネル経由で転送するようにしてください。 エンドポイントを見つけるには、

    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:31726、https://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

サポートチームがチケットを処理した後、お客様の所在地が更新された旨の通知が届きます。 変更が必要な場合は、新しいパラメータを明記した新しいチケットを作成してください。 LOCATIONID を確認するには、 ibmcloud sat locations を実行してください。

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>
    ```
    出力例

    ```sh {: screen}
    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.svc` を `NO_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.com、rhui-2.microsoft.com、rhui-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