FAQ

リレー計算リソースのコストは Satellite サービスのコストに含まれていますか?

リレーおよび Satellite に使用される IBM Cloud リソースは別途請求されます。

Direct Linkを介して IBM Cloud サービスにアクセスするための追加料金がありますか?

いいえ。 Direct Linkを介してサービスにアクセスするための追加料金は発生しません。

Direct Linkが必要なのはなぜですか?

通常、ロケーションから IBM Cloud サービスへのアウトバウンド・トラフィックは、パブリック・インターネットを介して流れる可能性があります。 Direct Linkを使用する場合、ロケーションからのアウトバウンド・トラフィックは、パブリック・インターネットを使用するのではなく、 Direct Linkを経由します。

私の組織は、インターネットへのアクセスを設計上無効にしています。 Direct Linkを使用して、ロケーションに接続されたロケーションとホストを作成および保守できますか?

Direct Linkを使用している場合は、それを Satellite サービスに使用できます。 Direct Linkを使用すると、パブリック・インターネットにアクセスせずに、ロケーションを作成してホストを接続することができます。

RHEL ホストを使用して Direct Linkをセットアップできますか?

いいえ Direct Linkを使用するには、RHCOS 対応のロケーションと、ご使用のロケーションで RHCOS ホストを使用する必要があります。

インターネットの代わりに Direct Link を介してすべてのトラフィックを IBM Cloud にリダイレクトできますか?

現在、すべてのサービスが Direct Linkをサポートしているわけではありません。 そのため、使用するサービスによっては、すべてのトラフィックで Direct Linkを使用できる場合と使用できない場合があります。

インターネット経由でアクセスしないようにするために Direct Link を介してアクセスできる IBM Cloud サービスは何ですか?

これらの指示に従うと、 Satellite 上の Satellite と OpenShift が、 Direct Link をまたいで機能するようになる。 Satellite、公衆インターネットへのアクセスを必要とする機能が追加されるかもしれない。 ロケーションで実行されている各サービスの資料を参照して、接続要件を確認することをお勧めします。

Direct Linkを使用するロケーションが 2 つある場合、それらを Direct Link で使用して、一方のロケーションから他方のロケーションにフェイルオーバーできますか?

この機能はまだ利用できない。

自分のロケーションの Direct Link 容量をサイズ変更するにはどうすればよいですか?

Direct Linkを使用するための追加のサイジング要件はありません。 そのため、使用するサービスに基づいて、通常のロケーションのようにロケーションのサイズを変更できます。

手動エラーを回避するために Direct Link を有効にするために必要なすべてをワンクリックでデプロイできますか?

現在、 Direct Link のワンクリック・デプロイメントは使用できません。 将来使用可能になる可能性があります。

ターゲット・ユース・ケース

現在 IBM とオンプレミスまたはその他のパブリック・クラウドとの間で Direct Link を使用しているお客様は、 Satellite リンクに引き続き使用できます。 これにより、お客様は以下を行う

• IBM Cloud 上の Satellite ロケーションからの Direct Link上のサービスにアクセスします。例: IBM Cloud® Object Storageへのフル・バックアップ
• IBM Cloudから Satellite ロケーションで実行されているサービスにアクセスします。
• IBM Cloudの外部のパブリック・クラウド・サービスにアクセスします。

これらには、インターネットではなく Direct Link を介してトラフィックを経路指定するために作成された Satellite エンドポイント・アドレスを使用してアクセスできます。

これにより、お客様の機密データ (ロギング、バックアップ、ハイブリッド・クラウド・ランドスケープ全体の統合サービス間のデータなど) がパブリック・インターネットを介して送信されないようにします。 これは、入口/出口の料金の最適化にも役立ちます。

概要

デフォルトでは、2 つの Satellite リンク・コンポーネント、トンネル・サーバーとコネクター、 IBM Cloud と Satellite のロケーションを保護します。 この資料では、 Direct Link経由で TLS 接続を使用するユース・ケースについて説明します。

このセットアップでは、トンネル・サーバーのプライベート・クラウド・サービス・エンドポイントを使用して、 IBM Cloud プライベート・ネットワーク (166.9.0.0/8。 サービス・ネットワーク を参照してください。 ただし、トンネル・サーバーのプライベート・クラウド・サービス・エンドポイントへの通信は、 IBM Cloud Direct Linkからルーティングできない IBM Cloud プライベート・ネットワーク上の 166.9.X.X/16 IP アドレス範囲を経由する必要があります。

166.9.X.X/16 範囲へのアクセスを有効にするには、 IBM Cloud アカウント内にリレーを作成します。これにより、着信トラフィックがトンネル・サーバーのプライベート・クラウド・サービス・エンドポイントにリバース・プロキシーされます。 デフォルトでは、リレー Ingress の IP アドレスは、 Direct Link 接続を介してアクセス可能な内部 10.X.X.X/8 IP アドレス範囲内にあります。

以下の図は、トラフィックのフローを示しています。

1. IBM Cloud Satellite クラスターから IBM Cloud サービスへの要求など、ロケーションから発信されるネットワーク・トラフィックは、 Direct Link を経由してリレー・プライベート・ルーティング・テーブルにルーティングされます。
2. リレーは、トンネル・サーバーのプライベート・クラウド・サービス・エンドポイントに要求を転送するための新規セッションを開始します。トンネル・サーバーは、 166.9.X.X/16 範囲内の IP アドレス (リンク専用アドレス) に終了します。

目標

パブリック・インターネットにアクセスすることなく、 Red Hat CoreOS 対応のロケーションを作成できます。 すべてのトラフィックは Direct Link によって処理され、内部にとどまります。

手順の概要は以下のとおりです。

1. Direct Linkを終了する IBM Cloud アカウントを使用して、 Red Hat CoreOS が有効になった Satellite ロケーションを作成します。
2. http/https およびセキュア WebSocket をサポートするリバース・プロキシーであるリレーを作成します。
3. Red Hat CoreOS ホストを用意する。 ステップ 1 で作成したロケーションの添付スクリプトとしてダウンロードしたイグニッション・スクリプトを使用して、ホストをカスタマイズします。

前提条件

• Red Hat CoreOS が有効になっている Satellite のロケーションが必要です。 まだ持っていない場合は、 Creating a Red Hat CoreOS enabled Satellite Location の説明に従って作成します。
• Direct Link は、ターゲットの Satellite ロケーションと IBM Cloud 固有の VPC またはクラシック・クラスターの間で使用可能です。
• IBM Cloud Direct Link 接続が 10.X.X.X/8 IP アドレス範囲にアクセスできることを確認します。 ネットワーク設計を検討して、 Direct Linkの両端の間の IP の競合を回避します。
• IBM Cloud CLI とプラグインをインストール し、 Kubernetes CLI(kubectl)をインストールします。
• IBM Cloud アカウントで、サービス・エンドポイントを使用できる仮想ルーター機能 (VRF) が有効になっていることを確認します。
• 以下のアクセスポリシーがあることを確認してください。 詳しくは、ユーザー許可の確認を参照してください。
  • 管理者 IBM Cloud IBM Cloud Kubernetes Service
  • 管理者 IBM Cloud IBM Cloud Container Registry
  • ライター または マネージャー IBM Cloud IBM Cloud Kubernetes Service
  • 管理者 IBM Cloud IBM Cloud Container Registry
  • 管理者 IBM Cloud IBM Cloud Satellite
  • マネージャー IBM Cloud IBM Cloud Satellite
  • 管理者 IBM Cloud Object Storage
  • ライター または マネージャー IBM Cloud IBM Cloud Object Storage
  • 管理者 IBM Cloud IBM Cloud Certificate Manager
  • ライター または マネージャー IBM Cloud IBM Cloud Certificate Manager
  • ビューアー IBM Cloud Satellite で使用する予定のリソース・グループに対する IAM プラットフォーム・アクセス役割
  • マネージャー IBM Cloud IBM Cloud Schematics
• 具体的には、 Kubernetes クラスターをプロビジョンし、そのクラスターに NGINX リバース・プロキシーをデプロイして Direct Link エンドポイントに転送します。

Red Hat CoreOS 対応 Satellite ロケーションの作成

Red Hat CoreOS が既に有効になっている Satellite ロケーションがある場合は、このステップをスキップできます。

Direct Link を持つ IBM Cloud アカウントにログインし、 Red Hat CoreOS 対応 Satellite ロケーションを作成します。 詳しくは、Satellite ロケーションの作成を参照してください。

リレーの作成

リレーは、セキュア Websocket 接続をサポートする http/https リバース・プロキシーです。 VSI、 Red Hat OpenShift 、または IBM Cloud Kubernetes Service でクラシックまたは VPC として実行できます。 以下のステップは、プライベート専用 VPC Red Hat OpenShift クラスター (VPC プライベート・ノード上) に NGINX リバース・プロキシーをデプロイする例を示しています。

必須の要件の 1 つは、 IBM Cloudでクラスターのプライベート Ingress (リレー Ingress) に割り当てることができる有効な名前と有効な証明書を使用することです。 IBM Cloudでは、プライベート・ノード上の VPC Red Hat OpenShift クラスターには、デフォルトのプライベート・ホスト名と証明書が付属しています。 これらを使用することも、カスタム・ホスト名と証明書を使用することもできます。 この例では、デフォルトのプライベート・ホスト名と証明書を使用します。

このシナリオの VPC クラスターに関する考慮事項:

• ゾーン: 任意の複数ゾーン対応 VPC ゾーン
• ワーカー・ノード・フレーバー: 任意の VPC インフラストラクチャー・フレーバー
• バージョン: 4.x.x
• ワーカー・プール: 少なくとも 2 つのワーカー・ノード
• サブネット：デフォルトの範囲が Satellite 上の Red Hat OpenShift クラスタの --pod-subnet と --service-subnet の値、または Satellite または Red Hat OpenShift ホストがオンプレミスで配置されているネットワークの CIDR と競合する場合は、Ingress Load Balancer IP サブネットを含めます。
• クラウド・サービス・エンドポイント: パブリック・エンドポイントとプライベート・エンドポイントの両方が必要な場合は、 --disable-public-service-endpoint オプションを指定しないでください。
• クラシック・クラスターまたは VPC クラスターの可用性を高めるために、デフォルトのワーカー・プールを複数のゾーンに分散させます。
• 各ゾーンに少なくとも 2 つのワーカー・ノードが存在することを確認します。これにより、後続のステップで構成するプライベート ALB の可用性が高くなり、バージョンの更新を適切に受け取ることができます。

以下の例では、プライベート専用 VPC クラスターとプライベート Ingress コントローラーがデフォルトで作成されます。 ただし、パブリック・クラウド・サービス・エンドポイントを有効にした Red Hat OpenShift クラスターを使用することもできますが、この場合、クラスターはデフォルトでパブリック Ingress コントローラーのみで作成されます。 パブリック・サービス・エンドポイントを持つクラスターを使用してリレーをセットアップする場合は、まずプライベート Ingress コントローラーを有効にし、 Ingress のセットアップ の手順に従ってサブドメインと証明書に登録する必要があります。

1. VPC 上にプライベート専用の Red Hat OpenShift クラスターを作成します。 詳しくは、 VPC クラスターの作成 を参照してください。

   VPC の Red Hat OpenShift クラスターでアプリを公開するには、さまざまな方法があります。 この例では、アプリはプライベート・エンドポイントでのみプライベートに公開されます。これは、 Direct Link のお客様にとって最も一般的なユース・ケースです。 プライベート・エンドポイントでプライベートに公開される Red Hat OpenShift クラスターには、デフォルトのプライベート名と証明書のみが付属しています。 この例では、NGINX リバース・プロキシー・ポッドを公開するために使用されます。 デフォルトのホスト名を使用することも、カスタムのホスト名と証明書を使用することもできます。 詳しくは、 プライベート・クラウド・サービス・エンドポイントのみを使用して VPC クラスターでアプリをプライベートに公開する方法 を参照してください。

2. Secret Managerインスタンスを作成し、前のステップで作成したRed Hat OpenShiftクラスタに登録します。 詳しくは、 Secrets Manager サービス・インスタンスの作成 を参照してください。

3. Direct Linkから Ingress の詳細を取得します。

   ibmcloud oc cluster get --cluster CLUSTER_NAME_OR_ID | grep Ingress
   

   出力例:

   Ingress Subdomain:      mycluster-i000.us-south.containers.appdomain.cloud
   Ingress Secret:         mycluster-i000
   

   このシナリオでは、 nslookup コマンドを Ingress サブドメインに対して実行すると、 IBM サービスのプライベート IP アドレス (10.0.0.0/8) に解決されます。 この資料では、Ingress IP アドレス (10.0.0.0/8) をお客様のオンプレミスから到達可能にするための経路の追加については説明していません。 IBM Cloudでオンプレミスと Ingress リレーの間のルーティングを促進するのはお客様の責任です。

4. 秘密のCRNを手に入れよう。

   ibmcloud oc ingress secret get -c CLUSTER --name SECRET_NAME --namespace openshift-ingress
   

5. NGINX リバース・プロキシーの名前空間を作成します。

   kubectl create ns dl-reverse-proxy
   

6. openshift-ingress のデフォルトの TLS シークレットを、NGINX がデプロイされるプロジェクトにコピーします。

   ibmcloud oc ingress secret create --cluster CLUSTER_NAME_OR_ID --cert-crn CRN --name SECRET_NAME --namespace dl-reverse-proxy
   

7. 以下の Ingress リソース・ファイルの内容をローカル・ディレクトリーにコピーします。 VALUE_FROM_INGRESS_SUBDOMAIN および VALUE_FROM_INGRESS_SECRET を独自の値に置き換えます。

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: dl-ingress-resource
     annotations:
       kubernetes.io/ingress.class: "public-iks-k8s-nginx"
       nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
       nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
   spec:
     tls:
     - hosts:
       - satellite-dl.VALUE_FROM_INGRESS_SUBDOMAIN
       secretName: VALUE_FROM_INGRESS_SECRET
     rules:
     - host: satellite-dl.VALUE_FROM_INGRESS_SUBDOMAIN
       http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: nginxsvc
               port:
                 number: 80
   

8. Ingress を作成します。

   oc apply -f myingressresource.yaml -n <dl-reverse-proxy>
   

9. 次のコマンドを実行して、トンネル・サーバー Direct Link の内部 Ingress ホスト名を取得します。

   ibmcloud sat endpoint ls --location LOCATION_ID
   

10. 出力から、ロケーション・エンドポイントをメモします。 c-01、 c-02、または c-03 を d-01-ws、 d-02-ws、または d-03-ws に置き換え、ポートを削除します。 例えば、 c-01.private.us-south.link.satellite.cloud.ibm.com:40934 は d-01-ws.private.us-south.link.satellite.cloud.ibm.com になります。 この値は、 ConfigMap ファイルの proxy_pass https の値として使用できます。

11. NGINX ConfigMap ファイルの内容をローカル・ディレクトリーにコピーします。 この構成は、ws-reverse プロキシーまたは https リバース・プロキシーのいずれかをトンネル・サーバー Direct Link エンドポイントに適用します。 VALUE_FROM_INGRESS_SUBDOMAIN および VALUE_FOR_PROXY_PASS を独自の値に置き換えます。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: confnginx
    data:
      nginx.conf: |
        user  nginx;
        worker_processes  1;
        error_log  /var/log/nginx/error.log warn;
        events {
            worker_connections  4096;
        }
        http {
          include       /etc/nginx/mime.types;
          default_type  application/octet-stream;
          log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                              '$status $body_bytes_sent "$http_referer" '
                              '"$http_user_agent" "$http_x_forwarded_for"';
          access_log  /var/log/nginx/access.log  main;
          sendfile        on;
          keepalive_timeout  65;
          server_names_hash_bucket_size  128;
          server {
            listen 80;
            server_name VALUE_FROM_INGRESS_SUBDOMAIN;
            proxy_connect_timeout 180;
            proxy_send_timeout 180;
            proxy_read_timeout 180;
            location /ws {
              proxy_pass https://VALUE_FOR_PROXY_PASS;
              proxy_ssl_server_name on;
              proxy_http_version 1.1;
              proxy_set_header Upgrade $http_upgrade;
              proxy_set_header Connection "upgrade";
            }
            location / {
              proxy_pass https://VALUE_FOR_PROXY_PASS;
            }
          }
        }
    

12. NGINX デプロイメント・ファイルをコピーします。

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      selector:
        matchLabels:
          app: nginx
      replicas: 2
      template:
        metadata:
          labels:
            app: nginx
      spec:
        containers:
          - name: nginx
            image: nginx:alpine
            ports:
            - containerPort: 80
            volumeMounts:
              - name: nginx-config
                mountPath: /etc/nginx/nginx.conf
                subPath: nginx.conf
        volumes:
          - name: nginx-config
            configMap:
              name: confnginx
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: nginxsvc
      labels:
        app: nginx
    spec:
      type: NodePort
      ports:
      - port: 80
        protocol: TCP
        name: http
      - port: 443
        protocol: TCP
        name: https
      - port: 8080
        protocol: TCP
        name: tcp
      selector:
        app: nginx
    

13. NGINX (dl-reverse-proxy) の ConfigMap を作成します。

    oc apply -f confnginx.yaml -n dl-reverse-proxy
    

14. 正しい scc プロファイルを設定し、NGINX (dl-reverse-proxy) を作成します。

    oc adm policy add-scc-to-user anyuid system:serviceaccount:dl-reverse-proxy:default
    oc apply -f nginx-app.yaml -n dl-reverse-proxy
    

15. ポッドをリストして、NGINX が実行されていることを再確認します。

    oc get pods
    

    NAME                     READY   STATUS    RESTARTS   AGE
    nginx-757fbc9f85-gv2p6   1/1     Running   0          53s
    nginx-757fbc9f85-xvmrj   1/1     Running   0          53s
    

16. ログを確認してください。

    oc logs -f nginx-757fbc9f85-gv2p6
    

    /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
    /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
    /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
    10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
    10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
    /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
    /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
    /docker-entrypoint.sh: Configuration complete; ready for start up
    

17. Ingress を確認します。

    oc get ingress
    

    NAME                  CLASS    HOSTS                                                                                                       ADDRESS                                                                                                     PORTS     AGE
    dl-ingress-resource   <none>   mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud   router-default.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud   80, 443   19m
    

18. リバースプロキシの URLに接続する。

    curl -k https://mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud
    

    {"status":"UP"}
    

トラフィックをDirect Linkを使うようにリダイレクトする。パス

リレーがトンネルサーバ内部Ingressに着信トラフィックをプロキシする準備ができたので、LocationホストまたはConnectorがリレーを介してトラフィックをリダイレクトするように設定できます。 これにより、すべてのトラフィックがプライベート・ネットワーク内のDirect Link・パスに留まり、トラフィックがパブリック・インターネットを使用することがなくなります。

以下の手順に従って、Connector エージェントまたは Location ホストのトラフィックをリダイレクトします。