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 Linkコンポーネント（トンネルサーバーとコネクタ）が、 IBM Cloud と Satellite のロケーションにあるリソース間のネットワークトラフィックを、安全な TLS 接続を介してプロキシします。 本書では、 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 アドレス (リンク専用アドレス) に終了します。

目標

すべてのトラフィックを Direct Link 経由でルーティングすることで、パブリックインターネットへのアクセスがない環境でも、 Red Hat CoreOS 対応のロケーションを作成します。

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

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 Location。

Direct Link を使用して IBM Cloud アカウントにログインし、 Red Hat CoreOS が有効になっているロケーションを作成してください。

リレーの作成

このリレーは、 HTTP / HTTPS のリバースプロキシであり、セキュアな WebSocket 接続をサポートしています。VSI、 Red Hat OpenShift、または IBM Cloud Kubernetes Service Classic もしくは VPC 上に展開可能です。

必須の要件の 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 ファイルの内容を、ローカルディレクトリにコピーしてください。 この設定では、トンネルサーバーの Direct Link エンドポイントに対して、ws-リバースプロキシまたはhttpsリバースプロキシのいずれかが適用されます。 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 ホストのトラフィックをリダイレクトします。