タグ：cloud

2023/07/20

IBM watsonx.ai のカスタムノードを公開しました

コメント数:
0 コメント
by dotnsf

先日このブログでも紹介した IBM watsonx.ai のベータ版 REST API を使って、Node-RED のカスタムノードを作り、公開してみました。以下で使い方を紹介しますが、実際に利用するには前回 REST API を利用する紹介をした時のブログでも作成した Watson Studuio と Watson Machine Learning を使ったプロジェクトを登録しておく必要があります（そのプロジェクトの ID が必要です）。またこれも同様に前回紹介しましたが、実行するユーザーの IBM Cloud IAM API キーを生成／取得しておく必要があるのでこちらも準備の上で試してみてください。

なお以下で紹介する内容では Node-RED v2.2.3 を使って動作確認しています。また私が提供しているものは公式のものではなく、あくまで個人的に開発したものを個人的に公開しているだけであること、現時点で提供されている REST API 自体がベータ版のため、今後近い将来の API 変更などにより動かなくなる可能性があることをご了承ください（とはいえ、私も使うので、少なくとも公式ノードが出るまではなるべくタイムリーにメンテナンスするつもりです）。

【パレットに watsonx.ai ノードを追加】
Node-RED のパレット画面を開き、右上のメニューから「パレットの管理」を選択してパレットのカスタマイズ画面に移動します。ここで「ノードを追加」タブを選び、"node-red-contrib-dotnsf-watsonxai" を検索してください（2023年7月20日時点では "watsonx" と検索すると１つだけ（！）見つかるのがそれです）。検索できたら「ノードを追加」ボタンをクリックします：

以下のような確認ダイアログが表示されるので「追加」をクリックします：

正しくインストールされると「ノードをパレットへ追加しました」というメッセージが表示されます。パレット管理画面を閉じます：

元のパレット画面に戻ると、"watsonx.ai" というノードが追加されているはずです：

【watsonx.ai ノードを使う】
では追加された watsonx.ai ノードを使ってみます。watsonx.ai ノードの前後に適当なノードを追加します。以下ではシンプルで分かりやすい代表として、inject ノードと debug ノードで挟んでみました：

watsonx.ai ノードにデータを渡すノード（上図では inject ノード）からは、msg.payload にいわゆる「プロンプト」のテキストを指定します。watsonx.ai ノードは自分に送られてきたデータの msg.payload にプロンプト指定がされている前提でそのテキスト内容に書かれた指示の返答テキストを生成します。

以下の例では msg.payload の内容を（前回のブログで紹介した内容に合わせて）以下のようにしてみました：

入力:\nAbout Watson Discovery\\nIBM Watson® Discovery is an intelligent document processing engine that helps you to gain insights from complex business documents.\n翻訳\n

入力内容が英語で書かれていて、最後に「翻訳（してね）」と指示している内容です。watsonx.ai ノードの手前のノード（inject ノード）の設定内容は以上です。

次に watsonx.ai ノード自体にも設定が必要です。watsonx.ai ノードをダブルクリックしてプロパティ設定画面を開き、API Key と Project ID をそれぞれ入力します：

このうち API Key は IBM Cloud の IAM API キーの値で、Project ID は Watson Studio と Watson Machine Learning で作成したプロジェクトの ID です。これらも前回のブログで紹介したものと同じ内容の問い合わせを行うサンプルなので、この作業について詳しくはこちらも参照してください。

全ての設定が完了したら作成したフローを「デプロイ」します：

デプロイ後に inject ノード左のボタンをクリックしてメッセージを送信すると、watsonx.ai ノードが API キー、プロジェクト ID 、そしてプロンプトテキスト内容を元に問い合わせを行い、その結果が画面右のデバッグ画面内に表示されます：

私が 2023 年7月20日に試した際の結果は "Watson Discoveryはビジネスドキュメントに関する意見を得るための知能型ドキュメント処理エンジンです。" と表示されました。上述の英語文章を翻訳してほしい、というプロンプトだったので、質問意図を正しく理解して実行できているようでした。

（いずれにせよベータ版 API を使うことになりますが）REST API を直接実行することでカスタムアプリケーションを作ることもできますが、今回紹介した Node-RED のカスタムノードを使うことで、より手軽に watsonx.ai のテキスト生成機能を体験できるようになったのではないかと思っています。

タグ：: #cloud; #ibm; #watsonx; #watsonx.ai; #nodered; #node-red

2023/02/04

IBM Cloud の仮想プライベートクラウド OpenShift 上にデプロイしたコンテナアプリに HTTPS パブリックアクセスを許可する

コメント数:
0 コメント
by dotnsf

以前のブログエントリで OpenShift 関連の以下２つの紹介をしていました：
・IBM Cloud の VPC(Virtual Private Cloud) でプライベート OpenShift クラスタ環境を構築する
・IBM Cloud の仮想プライベートクラウド OpenShift 上にデプロイしたコンテナアプリに HTTP パブリックアクセスを許可する

前者は IBM Cloud の VPC(Virtual Private Cloud) 環境を使って、プライベートな OpenShift クラスタ環境を作る手順（と VPN を使ったプライベート OpenShift へのアクセス手順）を紹介しました。　また後者ではこのプライベート環境を使ってデプロイしたプライベートなアプリケーションに対して、VPN なしでパブリックインターネットアクセスを（HTTPS ではなく、HTTP で）行うための設定手順を紹介しました。

今回のブログエントリではこの最終形ともいえる「デプロイしたアプリケーションに対する HTTPS によるアクセス」を実現するための手順を紹介します。上で紹介した２つのエントリの、後者に近い内容ではありますが、純粋な続きというわけではありません。前者の環境が構築済みであるという前提のもとで、oc CLI を使ったアプリケーションのデプロイと、プライベートアクセスを可能にするための手順を紹介していきます。

【３通りの方法】
今回のブログエントリの結論めいたことを最初に紹介します。この「プライベートクラウドにデプロイしたアプリケーションにパブリックにアクセスする」には目的や制約に応じた３通りの方法があります（うち（１）は前回説明済み）：
（１）HTTP でパブリックアクセスする（前回説明）
（２）HTTPS でパブリックアクセスする（自己証明書を使う場合）
（３）HTTPS でパブリックアクセスする（有効な証明書を使う場合）

要は「HTTP でいいのか？ HTTPS が必要か？」と「HTTPS の場合、自己証明書でいいか？NGか？」という２つの考慮点があり、その要件によって選択肢を選ぶ必要がある、ということです。「この中でどれか？と言われたら（３）でしょ？」と思うかもしれませんが、それぞれに制約事項があったりして（例えば（１）、（２）は IBM Cloud 内の設定のみで実現できますが、（３）の場合はカスタムドメインが別途必要になります）、検証目的なのか本運用なのか、といった背景によっても選択肢は変える必要が生じるものだと思います。

以下では、最終的には（３）を実現する前提として、（１）から順に実現手順を紹介します。なお（１）と同じことを前回紹介しているのですが、（３）まで行うことを考えると（１）も少し手順を変える必要があるので、改めて（１）から実現手順を、以下で順に紹介します。

【0. 事前準備】
まず事前準備としてプライベートクラウドでの OpenShift クラスタ環境と、同環境にアクセスするための VPN が必要です。これらの構築手順はシリーズ初回で紹介しているので、こちらの手順を参照してプライベートクラウドの OpenShift クラスタと、同クラスタにアクセスするための VPN 環境を作っておいてください。

ここまでが完了している前提で以下の説明を続けます。

【1. プライベート OpenShift クラスタにアプリケーションをデプロイし、パブリックアクセスのパスを定義する】

以前にも紹介した内容ですが、今回は HTTPS でのアクセスまでを考慮した手順を紹介します。そのため、HTTP でアクセスするこの部分から以前とは異なる、oc CLI コマンドと yaml ファイルを使ってアプリケーションをデプロイする手順を紹介します。

まず前提として、以下のようなプライベート OpenShift クラスタ環境が IBM Cloud 内に作られているものと仮定します：

OpenShift クラスタ名： kkimura-mycluster-jp-osa-2-priv

Ingress が定義したサブドメイン名： kkimura-mycluster-jp-osa-6fe57c7eaf38abe6232341d97eae54c0-i000.jp-osa.containers.appdomain.cloud

アプリケーションをデプロイする OpenShift プロジェクト（ネームスペース）: default

OpenShift にデプロイするアプリ：DockerHub 上の ibmcom/guestbook:v1

※ちなみにこの ibmcom/guestbook をデプロイしてウェブブラウザでアクセスするとこのような↓画面が表示されます。この画面が表示されればデプロイとアクセスが成功している、と判断してください：

以下では上述の名称や設定を前提として説明します。適宜自分の環境での名称や設定に読み替えてください。

では実際に oc CLI を使って、アプリケーションをプライベート OpenShift クラスタにデプロイします。まずはプライベート環境へアクセスする VPN を有効にした上で「OpenShift Web コンソール」を開きます（VPN が有効でないと開けません）：

OpenShift Web コンソールが開きます。今回は oc CLI と呼ばれるコマンドラインツールを使ってアプリケーションのデプロイや設定変更を行うので、まだこのツールをインストールしていない場合は導入が必要です。OpenShift Web コンソール画面上部のクエスチョンマークをクリックし、コンテキストメニューから「コマンドラインツール」を選択して、自分の PC 環境にあった oc CLI ツールをダウンロード＆インストールしておいてください：

同様にして ibmcloud CLI コマンドも（未導入の場合は）インストールしておきます：
https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli&locale=ja

oc CLI ツールと ibmcloud CLI ツールがインストールできている状態で、改めて OpenShift Web コンソール画面右上の名前部分をクリックしてコンテキストメニューを開き、「ログインコマンドのコピー」を選択します：

新しいウィンドウが開くと、"Display Token" とだけ表示されているので、この部分をクリックしてトークン情報を参照します：

するとトークン情報が書かれたページが表示されます。この中の "Log in with this token" で書かれた部分を（この後ペーストするので）コピーします：

ターミナルを開き、さきほどコピーした内容をペーストして Enter キーを押すと、ターミナル画面で IBM Cloud の OpenShift 環境にログインできます：

同様にして ibmcloud CLI ツールからも IBM Cloud へのログインを行っておきます：

$ ibmcloud login

ではここからプライベート OpenShift クラスタ内にアプリケーションをインストールします。改めて以下のような内容の yaml ファイル（guestbook_deployment.yaml）を用意します：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: guestbook
  labels:
    app: guestbook
spec:
  replicas: 1
  selector:
    matchLabels:
      app: guestbook
  template:
    metadata:
      labels:
        app: guestbook
    spec:
      containers:
      - name: guestbook
        image: ibmcom/guestbook:v1
        imagePullPolicy: Always
        env:
          - name: NODE_ENV
            value: production
---
apiVersion: v1
kind: Service
metadata:
  name: guestbook-svc
  labels:
    app: guestbook
spec:
  type: ClusterIP
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 3000
  selector:
    app: guestbook
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: guestbook-route
  labels:
    app: guestbook
spec:
  host: guestbook.kkimura-mycluster-jp-osa-6fe57c7eaf38abe6232341d97eae54c0-i000.jp-osa.containers.appdomain.cloud
  to:
    kind: Service
    name: guestbook-svc
    weight: 100
  port:
    targetPort: 3000
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect
  wildcardPolicy: None

この yaml ファイルは Deployment, Service, Route を１つずつ含んでいて、これ一つでアプリケーションをデプロイして、クラスタ外に公開して、ホスト名でアクセスできるようなルーティングを設定しています。数か所ある太字部分を補足します。

まず Deployment 内の image 名で ibmcom/guestbook:v1 と記載している部分、これがデプロイするアプリケーションのイメージです。別のイメージを使う場合はここを変えてください。

また数か所ある 3000 という数字、これは ibmcom/guestbook アプリが内部的に待ち受けるポート番号です。使うアプリイメージによって変わるので、ここもそのアプリ向けの正しい値を指定してください。

最後に Route 内の host 名、ここは　（アプリ固有の名）.（Ingress サブドメイン）　を指定します。今回の例ではアプリ固有の名として guestbook とし、Ingress サブドメインは上記で調べた値（kkimura-mycluster-jp-osa-6fe57c7eaf38abe6232341d97eae54c0-i000.jp-osa.containers.appdomain.cloud）を使っています。

では用意した yaml ファイルを使って実際にプライベート OpenShift にデプロイします：

$ oc apply -f guestbook_deployment.yaml

成功したら上述の host 名に HTTPS でアクセスし、期待通りに動作することを確認します（この時点でプライベートクラウドへはデプロイできました）：

次にこのアプリケーションをパブリッククラウドから（最初は HTTP で）アクセスできるように設定します。大まかな手順としては以下のことを行います：
・OpenShift 内にパブリック・ルーター（の Pod）とパブリック・ロードバランサーを作成し、
・パブリック・ロードバランサー　→　パブリック・ルーター　を経由して、アプリケーションだけにアクセスできるようなパスを通し、
・パブリック・ロードバランサーの外部ホスト名でアプリケーションを公開できるよう DNS を変更する

では順に実行していきます。ロードバランサーを OpenShift のパブリックネットワーク側に作りたいのですが、その際の（パブリックネットワーク用の）サブドメインを決める必要があります。まずは以下の ibmcloud コマンドを実行します：

$ ibmcloud oc nlb-dns ls --cluster kkimura-mycluster-jp-osa-2-priv
（最後のパラメータは OpenShift クラスタ名）

（以下、実行結果例）
OK
Subdomain                                                                                          Target(s)                            SSL Cert Status   SSL Cert Secret Name                                             Secret Namespace    Status
kkimura-mycluster-jp-osa-6fe57c7eaf38abe6232341d97eae54c0-i000.jp-osa.containers.appdomain.cloud   59aa36c3-jp-osa.lb.appdomain.cloud   created           kkimura-mycluster-jp-osa-6fe57c7eaf38abe6232341d97eae54c0-i000   openshift-ingress   OK

この実行結果例では１行しか表示されていませんが、複数行表示されることもあります。で、この結果の Subdomain を見ると "i000" と表示されている部分があります。この "i" で始まって数字が３桁続くサブドメインはプライベートネットワークであることを示しています。

新たにパブリックなサブドメインを追加したいのですが、その名称は、
・↑の方法でプライベートネットワークのサブドメインのうち、"i" 以降の数字が最も大きいもの（今回であれば "000"）を探して、
・その数字に１を追加し、"i" をゼロ（0）にしたもの（今回であれば "0001"）
にします。つまり今回の例であれば、

kkimura-mycluster-jp-osa-6fe57c7eaf38abe6232341d97eae54c0-0001.jp-osa.containers.appdomain.cloud

をパブリック用のサブドメインとします。

パブリック用のサブドメインが決まったら、以下のような yaml ファイル（ingresscontroller.yaml）を作って実行し、パブリックネットワークにパブリックルーターとパブリックロードバランサーを作ります（太字部分はパブリック用サブドメイン）：

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: public
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  domain: kkimura-mycluster-jp-osa-6fe57c7eaf38abe6232341d97eae54c0-0001.jp-osa.containers.appdomain.cloud
  endpointPublishingStrategy:
    loadBalancer:
      scope: External
    type: LoadBalancerService

$ oc apply -f ingresscontroller.yaml

そして以下を実行し、結果の "EXTERNAL-IP" を参照します：

$ oc get svc router-public -n openshift-ingress

NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                          PORT(S)                      AGE
router-public   LoadBalancer   172.21.191.252   5ca5ada9-jp-osa.lb.appdomain.cloud   80:31127/TCP,443:30992/TCP   32h

この例では EXTERNAL-IP は "5ca5ada9-jp-osa.lb.appdomain.cloud" となっています。これがパブリックロードバランサーのホスト名となります。

このサービスのパブリック VPC ホスト名を DNS に登録します。以下のコマンドを実行します：

$ ibmcloud oc nlb-dns create vpc-gen2 --cluster （OpenShiftクラスタ名） --lb-host （ロードバランサーホスト名） --type public

※今回の例だと、
　OpenShift クラスタ名： kkimura-mycluster-jp-osa-2-priv
　ロードバランサーホスト名： 5ca5ada9-jp-osa.lb.appdomain.cloud

最後にアプリのサービスをパブリックルーターで expose します：

$ oc expose svc/guestbook-svc --name guestbook-public --hostname guestbook.kkimura-mycluster-jp-osa-6fe57c7eaf38abe6232341d97eae54c0-0001.jp-osa.containers.appdomain.cloud

これでサービス（guestbook.kkimura-mycluster-jp-osa-6fe57c7eaf38abe6232341d97eae54c0-0001.jp-osa.containers.appdomain.cloud）がパブリックネットワーク上で HTTP で公開されました。いったん VPN を切ってから、パブリックホスト名（http://guestbook.kkimura-mycluster-jp-osa-6fe57c7eaf38abe6232341d97eae54c0-0001.jp-osa.containers.appdomain.cloud）に HTTP でアクセスできることを確認してみましょう：

【2. プライベート OpenShift クラスタにアプリケーションをデプロイし、自己証明書の HTTPS アクセスができるよう定義する】

1. で説明した作業の続きとして、パブリックロードバランサー名（今回であれば "5ca5ada9-jp-osa.lb.appdomain.cloud"）で自己証明書を使った HTTPS アクセスを可能にします。

そのためにはアプリケーションのデプロイ時に使った yaml ファイル（guestbook_deployment.yaml）を少し改良します。具体的には以下の青字部分を（自分の環境のホスト名やパブリックロードバランサー名を使って）追加します：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: guestbook
  labels:
    app: guestbook
spec:
  replicas: 1
  selector:
    matchLabels:
      app: guestbook
  template:
    metadata:
      labels:
        app: guestbook
    spec:
      containers:
      - name: guestbook
        image: ibmcom/guestbook:v1
        imagePullPolicy: Always
        env:
          - name: NODE_ENV
            value: production
---
apiVersion: v1
kind: Service
metadata:
  name: guestbook-svc
  labels:
    app: guestbook
spec:
  type: ClusterIP
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 3000
  selector:
    app: guestbook
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: guestbook-route
  labels:
    app: guestbook
spec:
  host: guestbook.kkimura-mycluster-jp-osa-6fe57c7eaf38abe6232341d97eae54c0-i000.jp-osa.containers.appdomain.cloud
  to:
    kind: Service
    name: guestbook-svc
    weight: 100
  port:
    targetPort: 3000
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect
  wildcardPolicy: None
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: guestbook-route
  labels:
    app: guestbook
spec:
  host: guestbook.kkimura-mycluster-jp-osa-6fe57c7eaf38abe6232341d97eae54c0-0001.jp-osa.containers.appdomain.cloud
  to:
    kind: Service
    name: guestbook-svc
    weight: 100
  port:
    targetPort: 3000
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect
  wildcardPolicy: None
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: guestbook-route
  labels:
    app: guestbook
spec:
  host: 5ca5ada9-jp-osa.lb.appdomain.cloud
  to:
    kind: Service
    name: guestbook-svc
    weight: 100
  port:
    targetPort: 3000
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect
  wildcardPolicy: None

これによりパブリックロードバランサー（5ca5ada9-jp-osa.lb.appdomain.cloud）への HTTPS アクセスが可能になります。ただ証明書が自己証明書のため、アクセス制約がかかります。この yaml ファイルでデプロイしなおします（VPN を切ったままの場合は再接続してから）：

$ oc apply -f guestbook_deployment.yaml

そしてブラウザでアクセスしてみます。具体的には以下のようになります。VPN を切断後にブラウザで https://5ca5ada9-jp-osa.lb.appdomain.cloud にアクセスすると、以下のような画面になります。「詳細設定」をクリックします：

証明書が自己証明書なので安全ではない、というメッセージが表示されます。安全ではないことを理解した上でアクセスしてみます：

すると、（保護はされていないけれど）一応 HTTPS でアクセスできることが確認できます：

このパブリックロードバランサーのドメインは OpenShift 環境から自動発行されたもので、内部的に使うぶんにはこれで問題ないのですが、ユーザーが直接使う場合はちょっと気になる部分ではあります：

後述の手順で正しい証明書を使った HTTPS アクセス方法を紹介しますが、こちらにも別の制約事項があるので、両方理解した上でどちらを使うべきか検討してください。

【3. プライベート OpenShift クラスタにアプリケーションをデプロイし、カスタムドメインの証明書を使って HTTPS アクセスができるよう定義する】

最後のケースは HTTPS としては完成形のような位置づけですが、これまでのケースにはない制約事項が１つあります。それは「カスタムドメインを使う」必要がある点です。2. では IBM Cloud 発行のドメインを使って HTTPS ができなかったのを、自前のドメインを使うことで回避する方法になります。

例えば "pi314.jp" というカスタムドメインを使うことにして、2. までに説明してきたアプリケーションを "guestbook.pi314.jp" というホスト名で HTTPS アクセス可能にする、という想定で以下の説明を行います。

まずカスタムドメインの DNS を設定します。契約したドメイン会社や DNS 移管先によって具体的な設定手順は異なりますが、guestbook という CNAME に対して、パブリックロードバランサー名を設定します（下図は CloudFlare.com を使った場合のスクリーンショット）：

更にデプロイ用の guestbook_deployment.yaml をもう一度改良して、赤字部分を更に追加します：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: guestbook
  labels:
    app: guestbook
spec:
  replicas: 1
  selector:
    matchLabels:
      app: guestbook
  template:
    metadata:
      labels:
        app: guestbook
    spec:
      containers:
      - name: guestbook
        image: ibmcom/guestbook:v1
        imagePullPolicy: Always
        env:
          - name: NODE_ENV
            value: production
---
apiVersion: v1
kind: Service
metadata:
  name: guestbook-svc
  labels:
    app: guestbook
spec:
  type: ClusterIP
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 3000
  selector:
    app: guestbook
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: guestbook-route
  labels:
    app: guestbook
spec:
  host: guestbook.kkimura-mycluster-jp-osa-6fe57c7eaf38abe6232341d97eae54c0-i000.jp-osa.containers.appdomain.cloud
  to:
    kind: Service
    name: guestbook-svc
    weight: 100
  port:
    targetPort: 3000
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect
  wildcardPolicy: None
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: guestbook-route
  labels:
    app: guestbook
spec:
  host: guestbook.kkimura-mycluster-jp-osa-6fe57c7eaf38abe6232341d97eae54c0-0001.jp-osa.containers.appdomain.cloud
  to:
    kind: Service
    name: guestbook-svc
    weight: 100
  port:
    targetPort: 3000
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect
  wildcardPolicy: None
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: guestbook-route
  labels:
    app: guestbook
spec:
  host: 5ca5ada9-jp-osa.lb.appdomain.cloud
  to:
    kind: Service
    name: guestbook-svc
    weight: 100
  port:
    targetPort: 3000
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect
  wildcardPolicy: None
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: guestbook-route
  labels:
    app: guestbook
spec:
  host: guestbook.pi314.jp
  to:
    kind: Service
    name: guestbook-svc
    weight: 100
  port:
    targetPort: 3000
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect
  wildcardPolicy: None

この yaml ファイルを（VPN が切れている場合は再接続してから）再度適用します：

$ oc apply -f guestbook_deployment.yaml

そして VPN を切断し、ブラウザでカスタムドメイン側に登録した名前（guestbook.pi314.jp）に HTTPS アクセスしてみましょう：

警告などが表示されることなく、ちゃんと HTTPS でパブリックアクセスできることが確認できるはずです。

以上、コンテナ環境を運用する上で
・コンテナ管理はプライベートネットワークで運用し、
・デプロイしたアプリはパブリックネットワークから利用する

という要件はあってもおかしくなさそうですが、今回紹介したような方法で実現できそうです。自己証明書を使うページはスマホから利用するのが難しいのですが、カスタムドメインという高めのハードルを越えることができればその問題もなくなります。利用環境や目的に応じて検討してください。

タグ：: #roks; #loadbalancer; #lb; #ibm; #cloud; #openshift; #private

2023/01/17

OpenShift 上で RedHat CodeReady Workspaces オペレーターを使ってアプリケーション開発環境を作る

コメント数:
0 コメント
by dotnsf

ウェブアプリケーションの開発ハンズオン（オンライン含めて）を行う場合、その開発環境の準備が面倒です。参加者の PC を使おうとすると言語ランタイムやエディタのインストールやバージョン管理を含めて事前に準備してもらう項目が多く、また特にオンライン環境だとネットワークの設定が問題になったりするので、色んな環境のケースを想定した準備が必要になります。

そんな「開発環境構築」を比較的容易にする RedHat CodeReady Workspaces を使う機会があったので、使い方やこれを使って構築する開発環境がどんなものかまとめてみました：

【事前準備】
今回は RedHat OpenShift クラスタ環境を使って CodeReady Workspaces を準備します。というわけで OpenShift クラスタ環境が必要です。以下では IBM Cloud 上に作った OpenShift クラスタ環境を使って紹介しますが、他のクラウドやオンプレミス版などを使っていても構いません。

【OpenShift に RedHat CodeReady Workspaces を導入】
まずは OpenShift クラスタに RedHat CodeReady Workspaces を導入します。RedHat CodeReady Workspaces は OpenShift 上のオペレータとして提供されているのでこれを使って環境を作ります。最初に OpenShift のウェブコンソールを開いて、Administrator パースペクティブで左メニューから Operator - OperatorHub を選択します。そこでプロジェクト（例えば "default"）を１つ選び、検索フィールドに "codeready" などと入力して "Red Hat CodeReady Workspaces" を見つけてクリックします：

Red Hat CodeReady Workspaces の説明画面が表示されたら「インストール」ボタンをクリックします：

次の画面を下までスクロールしてもう一度「インストール」ボタンをクリックします：

ここでしばらく待つと RedHat CodeReady Workspaces オペレータがインストールされます：

インストールが完了すると以下のような画面になるので、「Operator の表示」ボタンをクリックします：

インストールされた RedHat CodeReady Workspaces オペレータが表示されます。実際に CodeReady Workspaces インスタンスを動かすために「提供される API」欄の "CodeReady Workspaces Instance Specification" の下の「インスタンスの作成」をクリックします：

もう一度下までスクロールして「作成」ボタンをクリックするとインスタンスの作成が始まります：

インスタンスが作成されると以下のような画面になるので、"codeready-workspaces" と書かれた箇所をクリックします：

下のような画面になります。この画面ではまだインスタンスは準備中ですが、用意ができると "CodeReady Workspaces URL" の下にリンク URL 文字列が表示されます：

このような表示になるとインスタンスの作成も完了しています。早速 CodeReady Workspaces URL 下のリンクをクリックします：

最初の１回だけアクセス権の設定を行う必要があります。"user-full" にチェックが入っていることを確認して "Allow selected permissions" ボタンをクリックします：

するとアカウント情報の画面が表示されます：

この画面内でユーザー名、メールアドレス、ファースト／ラストネームを入力して、最後に Submit ボタンをクリックします。これでアカウント情報の登録も行われます：

CodeReady Workspaces の起動が開始します。ここまで行うことができれば RedHat CodeReady Workspaces の環境構築手順は無事に成功しました：

【RedHat CodeReady Workspaces を使ってアプリケーション開発を行う】

RedHat CodeReady Workspaces の起動が完了すると最初のワークスペースを作るようナビゲートされます：

Git リポジトリを指定してソースコード一式をインポートすることもできますが、今回はテンプレートからワークスペースを作ってみます。（なんでもいいのですが）画面下の "NodeJS Express" と書かれた Node.js のシンプルなソースコードをベースに選択して、ここからワークスペースを作ることにしてみましょう：

すると指定されたテンプレートを元にしたソースコード一式が作成されるので、完了するまで少し待ちます：

ワークスペースの生成が完了するとこのような画面が表示されます。ウェブ版の VSCode が起動し、（今回の例であれば）シンプルな Node.js + Express のウェブアプリケーションの雛形となるソースコードが読み込まれています。指定したファイルを開いたり、その内容を変更することもできます（最初は README.md がプレビューモードで開かれています）：

依存関係や起動コマンドを確認するため、package.json を開いてみました。ここから最初に起動するべきファイルは app/app.js であることがわかります：

実際に app/app.js も開いて内容を確認してみました。いわゆる「ハローワールド」のウェブ版のアプリケーションのようです：

このアプリを起動するには VSCode 内でターミナルを起動します。メニューの Terminal - Open Terminal in specific container を選択し、"vscode-nodeajs" を選択します：

すると画面右下にターミナルが現れ、CLI コマンドを実行できるようになります：

実際にアプリケーションを起動してみましょう。まずはターミナルで "npm install" と入力してライブラリをインストールします：

そして "node app/app.js" と入力してウェブアプリケーションを起動します。すると画面右下に「起動したウェブアプリケーションをブラウザで表示するか？」と聞かれるので、「新しいタブで起動(Open In New Tab)」を選択します：

新しいブラウザタブが開いて、そこで起動したアプリケーションが実行されます。期待通り、"Hello World!" が表示できました。CodeReady Workspaces で作ったオンライン開発環境を使ってアプリケーションを開発／実行／動作確認までできることが確認できました：

CodeReady Workspaces のエディタ画面で編集したアプリケーションをウェブブラウザで実行（表示）することができました：

【まとめ】
OpenShift コンテナクラスタ環境を使うことで、開発環境も実行環境もコンテナ上で簡単に構築・実現することができました。個人の PC にはランタイムや CLI などを導入する必要がなく、ネットワークも（HTTP/HTTPS さえインターネットに通っていればいいので）環境による試行錯誤はほぼ不要だと思います。簡易的なアプリケーション開発環境の構築程度であれば非常に用意に作れると感じました。

タグ：: #ibm; #cloud; #openshift; #redhat; #codeready; #workspaces

2023/01/16

IBM Cloud の仮想プライベートクラウド OpenShift 上にデプロイしたコンテナアプリに HTTP パブリックアクセスを許可する

コメント数:
0 コメント
by dotnsf

先日のブログで IBM Cloud の VPC（Virtual Private Cloud : 仮想プライベートクラウド）上に OpenShift クラスタ環境を構築する手順を紹介しました：
IBM Cloud の VPC(Virtual Private Cloud) でプライベート OpenShift クラスタ環境を構築する

↑で紹介した内容は完全にインターネットと断絶したプライベートクラウドではなく、「プライベートクラウド側からインターネット側へのアクセスは許す」というものでした。デプロイ時に GitHub や DockerHub などを参照する場合はこのような設定になるので（それも許さない場合はこれらに相当する機能も VPC 内に用意する必要があるため）そこまで珍しい構成ではないと思っています。

今回紹介するのはもう１段階緩めのプライベートクラウドと言えるもので、「デプロイしたアプリはパブリックインターネットから利用できるようにする」というものです。OpenShift クラスタのウェブコンソールや oc CLI コマンドの利用は VPC 必須としたたま、コンテナとしてデプロイしたアプリはインターネットからでも利用可能にする、という設計です。OpenShift の管理者機能のみを VPC 内に入れ（VPN 必須として）、クラスタにデプロイしたアプリケーションについては利用制約を設けないというもので、これも現実的には珍しくないプライベートクラウド環境であると思っています。

【構築手順】
この環境を作る上で、まずは前回紹介した VPC での OpenShift 環境が必要です。こちらの内容を参照して仮想プライベートクラウド内に OpenShift クラスタを構築しておいてください：
IBM Cloud の VPC(Virtual Private Cloud) でプライベート OpenShift クラスタ環境を構築する

ここまでの環境準備ができ、かつ構築した VPN 接続ができている前提で以下を説明します。改めて IBM Cloud ダッシュボードにログインし、作成した OpenShift クラスタを表示します：

この画面の "OpenShift Web コンソール" ボタンをクリックしてコンソール画面を表示します（VPN 接続していないとエラーになります）：

OpenShift ウェブコンソール画面が表示されたら右上の ID 部分をクリックし「ログインコマンドのコピー」を選択します：

"Display Token" をクリックすると oc CLI でのログインコマンドが表示されます。"oc login" で始まるコマンドを確認します：

ここまでできたら CLI で IBM Cloud (ibmcloud)および OpenShift (oc)環境にログインします：

$ ibmcloud login

$ oc login --token=sha256xxxxx（↑で確認したコマンド）

ログイン後、まずはドメイン名を調べます。以下のコマンドを入力します：

$ ibmcloud oc nlb-dns ls -c （OpenShift クラスタ名）

実行結果の "Subdomain" 欄（上図では "kkimura-mycluster-jp-tok2-6fe57c7eaf38abe6232341d97eae54c0-i000.jp-tok.containers.appdomain.cloud）を確認します。これが IBM Cloud から割り振られたドメイン名です。途中 i000 となっている部分がプライベートドメインであることを意味しています（i00x がプライベート、000x がパブリック）。パブリック用にこの x を１つカウントアップして（i000 -> 0001 として）以下のような IngressController 作成用 yaml ファイル（ingresscontroller-0001.yaml）を作成します：

(ingresscontroller-i001.yaml)

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: public
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  domain: kkimura-mycluster-jp-tok2-6fe57c7eaf38abe6232341d97eae54c0-0001.jp-tok.containers.appdomain.cloud
  endpointPublishingStrategy:
    loadBalancer:
      scope: External
    type: LoadBalancerService

そしてこれを実行します：

$ oc create -f ingresscontroller-0001.yaml

成功すると router-public という Pod が作成されているはずです：

$ oc get pods -n openshift-ingress

NAME                             READY   STATUS    RESTARTS   AGE
router-default-58cb7bcc6-6nmtv   1/1     Running   0          6h28m
router-default-58cb7bcc6-mxlkd   1/1     Running   0          6h28m
router-public-55cf9586d-5qwkv    1/1     Running   0          77s
router-public-55cf9586d-bqnv6    1/1     Running   0          77s

この時、裏側でパブリックロードバランサーが作成されています。ロードバランサーのホスト名を確認します。結果の EXTERNAL-IP（下の場合であれば "b881dcc5-jp-tok-lb.appdomain.cloud）が確認できます：

$ oc get svc/router-public -n openshift-ingress

NAME            TYPE           CLUSTER-IP      EXTERNAL-IP                          PORT(S)                      AGE
router-public   LoadBalancer   172.21.233.58   b881dcc5-jp-tok.lb.appdomain.cloud   80:31920/TCP,443:32264/TCP   3m17s

パブリック用ドメイン名とロードバランサーのホスト名を紐づけて DNS 登録します：

$ ibmcloud oc nlb-dns create vpc-gen2 -c kkimura-mycluster-jp-tok2 --lb-host b881dcc5-jp-tok.lb.appdomain.cloud --type public --secret-namespace openshift-ingress

$ ibmcloud oc nlb-dns ls -c kkimura-mycluster-jp-tok2
OK
Subdomain
               Target(s)                            SSL Cert Status   SSL Cert Secret Name                                              Secret Namespace    Status
kkimura-mycluster-jp-tok2-6fe57c7eaf38abe6232341d97eae54c0-0001.jp-tok.containers.appdomain.cloud   b881dcc5-jp-tok.lb.appdomain.cloud   creating          kkimura-mycluster-jp-tok2-6fe57c7eaf38abe6232341d97eae54c0-0001   openshift-ingress   OK
kkimura-mycluster-jp-tok2-6fe57c7eaf38abe6232341d97eae54c0-i000.jp-tok.containers.appdomain.cloud   57a0f594-jp-tok.lb.appdomain.cloud   created           kkimura-mycluster-jp-tok2-6fe57c7eaf38abe6232341d97eae54c0-i000   openshift-ingress   OK

サービスをパブリックルーターで公開します。--hostname には 0001 のドメイン名に任意のサブドメインを指定します：

$ oc expose svc/hostname --name hostname-public --hostname hostname.kkimura-mycluster-jp-tok2-6fe57c7eaf38abe6232341d97eae54c0-0001.jp-tok.containers.appdomain.cloud

これでパブリッククラウドへの公開ができたはずです。VPN 接続を切ってから curl やウェブブラウザ等で --hostname に指定したホストに HTTP アクセスし、正しくアクセスできることを確認します：

（VPN 接続してプライベートアクセスした場合）

（VPN 接続を切ってからパブリックアクセスした場合）

プライベートネットワークにデプロイしてアプリケーションがパブリックインターネット経由でもアクセスできるようになりました。今回紹介した内容はパブリックインターネットから HTTP でアクセスする例でしたが、HTTPS でアクセスする場合の方法は別の機会に紹介するつもりです。

（参照）

Red Hat OpenShift on IBM Cloud on VPCへのプライベート接続方式を検証してみた（設定編）

タグ：: #ibm; #cloud; #openshift; #roks; #private; #loadbalancer; #lb

2023/01/09

IBM Cloud の VPC(Virtual Private Cloud) でプライベート OpenShift クラスタ環境を構築する

コメント数:
1 コメント
by dotnsf

あけましておめでとうございます。これが 2023 年最初のブログエントリとなります。本年もよろしくお願いいたします。

これまで IBM Cloud で OpenShift クラスタ環境を何度も作って（＆そして削除して）来ました。が、それらは全てパブリッククラウド環境としての OpenShift クラスタでした。　このたびプライベートクラウド環境としての OpenShift クラスタを作る機会がありました。その考慮点や手順がパブリッククラウドの時と比べてかなり複雑だったので、備忘録の意味も含めて最初から最後まで手順をまとめてみました。

【プライベートクラウドの設計】
一言で「プライベートクラウド」といっても、その制約というか仕様には色々なパターンが考えられます。例えば「プライベートクラウド」なので、ウェブの管理コンソールや管理 CLI の操作、クラスタにデプロイしたアプリケーションにインターネットからアクセスできない（インターネット側からプライベートクラウドへのアクセスは不可とする）、というのは共通仕様だと思っています。一方で、デプロイするアプリケーションのイメージは Docker ハブから使いたい（つまりプライベートクラウド側からインターネットへのアクセスは許可したい）というケースはあるかもしれませんし、そこも制約として許可したくないケースもあると思います（後者の場合でイメージからデプロイするにはイメージリポジトリもプライベートクラウド内に構築する必要も出てきます）。

以下で手順を紹介するのは「前者」のパターンとします。つまり、
・CLI やウェブコンソールを含めて、インターネットからの直接アクセスは許可しない
・専用の VPN 環境を構築し、この VPN 接続が有効な場合のみアクセスを許可する
・プライベートクラウド側からインターネットへのアクセスは許可する（Docker ハブなどからのアプリケーションデプロイを可能とする）

という条件でプライベートクラウド環境を構築します。なお以下の作業を行う上で必要なユーザー権限は全て取得済みであるものとします。

【VPC とサブネットの作成】
まず、今回のようなパブリックインターフェースを持たないプライベートインターフェースのみの OpenShift クラスタを IBM Cloud に作る場合、クラシックインフラではなく VPC（Virtual Private Cloud）インフラに作る必要があります。そのためまずは OpenShift クラスタを作成するための VPC（Virtual Private Cloud：仮想プライベートクラウド）環境を作成します。IBM Cloud のダッシュボードから「リソースの作成」をクリックします：

カタログ画面の検索バーに "Virtual Private" と入力すると選択候補の中に "Virtual Private Cloud" というのが出てくると思うので、これを選択します：

VPC 環境を作成するロケーションを選択します。以下の例では「アジア太平洋地域」の「東京」を選択しています。ここは自分の環境にあったもの（なるべく利用者に近い場所）を選択してください。そして VPC の名称（下の例では "kkimura-vpc"）を入力します：

下にスクロールするとデフォルト接頭部とサブネットに関する情報が表示されます。デフォルトでは選択したロケーション（この場合は東京）の３つのゾーンに１つずつサブネットが用意されます。このままでもよければこのまま進めることもできますが、今回は規模の小さいプライベートクラウド環境を作る想定なので、デフォルト設定を無効にした上でサブネットを１つだけ用意することにします：

というわけで、「各ゾーンのデフォルト接頭部の作成」のチェックを外してください。最後に「仮想プライベート・クラウドの作成」ボタンをクリックします：

仮想プライベート・クラウドの一覧画面に遷移し、先ほど指定した名前の VPC が追加されたことを確認し、これを選択します：

VPC の中身を確認するとアドレス接頭部が空になっています。ここに１つだけ追加することにします：

同じ画面の「アドレス接頭部」タブを選択して「作成」ボタンをクリックします：

画面右から「アドレス接頭部の作成」というウィンドウが表示されます。ここに作成するアドレス空間の範囲（下の例では 10.10.0.0/18）と、そのアドレス空間を作るロケーション（下の例では東京２）を指定して「作成」ボタンをクリックします：

指定した値（10.10.0.0/18）のアドレス空間が定義できました：

アドレス空間が定義できたので、次にサブネットを作成します。画面左ペインから「サブネット」を選択し、「作成」ボタンをクリックします：

ロケーション（下の例ではアジア太平洋の東京２）とサブネットの名称（下の例では "sn-tok2"）を指定します。まだ入力項目があるので、そのまま下にスクロールします：

このサブネットを使う VPC を指定し、最後にアドレス接頭部（10.10.0.0/18）内のどの部分をサブネットとして利用するかを指定します（下の例では "10.10.0.0/24" を指定しています）。ここまで指定できたら最後に「サブネットの作成」ボタンをクリックします：

VPC 用のサブネットを新しく１つ定義できました。この後 OpenShift 環境を構築する場合に、このサブネット上に構築することになります：

【パブリックゲートウェイの作成】
今回のプライベートクラウドでは「プライベート環境側からインターネット側へのアクセスは許可する」前提で環境を構築します。これを実現するには「パブリックゲートウェイ」と呼ばれるゲートウェイをサブネットに紐づけることで実現します。　以下ではその手順を紹介します。なお「プライベート環境側からインターネット側へのアクセスも禁止する」というポリシーで構築する場合は、このパブリックゲートウェイ作成手順は読み飛ばしてください。

VPC インフラストラクチャー画面の左ペインで「パブリック・ゲートウェイ」を選択し、「作成」ボタンをクリックします：

画面右からパブリック・ゲートウェイの設定画面が現れます。まずはパブリック・ゲートウェイを作成するロケーション（下の例ではアジア太平洋の東京２）を指定します：

画面を下にスクロールして設定の続きを行います。作成するパブリック・ゲートウェイの名前（"kkimura-pgw"）、対象となる VPC（"kkimura-vpc"）を指定し、最後に「作成」ボタンをクリックします：

しばらく待つとパブリック・ゲートウェイが作成されます。ただこの時点では作成されただけで、まだ対象となるプライベート・サブネットとの接続ができていない状態です：

というわけで、プライベート・サブネットとの接続を行います。対象パブリック・ゲートウェイの右（必要に応じてスクロールしてください）のメニューをクリックして「接続」を選択します：

接続するサブネットを選択します。ここでは先ほど作成した "sn-tok2" サブネットを指定しています。最後に「作成」ボタンをクリックします：

パブリック・ゲートウェイとサブネットとの接続ができました。これで対象サブネット内に作られるサーバーリソースからインターネット側へアクセスすることができるようになりました：

【Secrets Manager で証明書を管理】
この後 OpenShift クラスタをプライベート環境内に作るのですが、プライベート環境なのでそのままでは（ウェブコンソールにも oc CLI からも）アクセスできません。というわけで、プライベート環境にアクセスするための VPN をあらかじめ用意しておくことにします。

この VPN 接続をセキュアにするためには証明書が必要で、その証明書を Secrets Manager を使って管理します。したがってまず最初に Secrets Manager を（まだ使ったことがなければ）作成します。

IBM Cloud のダッシュボードから「リソースの作成」をクリックし、カタログ内の検索画面で "Secrets" と入力すると "Secrets Manager" が見つかるはずです。これを選択します：

Secrets Manager の構成画面ではまずロケーション（下の例では「東京」）を選択します。また Secrets Manager の料金プランを選択します。Secrets Manager を初めて使う場合は無料の「トライアル」プランを 30 日間だけ使うこともできます：

最後に、作成する Secrets Manager の名称（下の例では "kkimura-secrets-manager-tok2"）を指定し、「以下のご使用条件を読み、同意します」にチェックを入れて「作成」します：

Secrets Manager が作成できたら VPN サービスから Secrets Manager を使うことができるよう権限を設定する必要があります。IBM Cloud の画面右上のメニューから　管理→アクセス（IAM）　を選択します：

左ペインで「許可」を選択して許可の管理画面を表示してから「作成」をクリックします：

サービス許可の設定をします。ここでは以下のように指定します：
　ソースアカウント：当該アカウント
　ソースサービス：VPC Infrastructure Services
　アクセス権限の範囲の指定：選択された属性に基づくリソース
　リソースタイプにチェックして "Client VPN for VPC" を選択
　（下に続く）

　（上から続く）
　ターゲット・サービス： Secrets Manager
　アクセス権限の範囲の指定：全てのリソース
　サービス・アクセス：シークレット・リーダーにチェック

最後に「作成」ボタンをクリックします：

指定した内容の許可レコードが作成されたことを確認します：

ここまで準備できたら実際に証明書を作成します。ターミナル等で以下を実行します：

Easy-RSA 3 リポジトリをローカルフォルダに複製
$ git clone https://github.com/OpenVPN/easy-rsa.git

$ cd easy-rsa/easyrsa3

新しい PKI と CA を作成
$ ./easyrsa init-pki

$ ./easyrsa build-ca nopass

VPN サーバー証明書(vpn-server.vpn.ibm.com)を生成
$ ./easyrsa build-server-full vpn-server.vpn.ibm.com nopass

（プロンプトが止まったら "yes" と入力）

VPN クライアント証明書(client1.vpn.ibm.com)を生成
$ ./easyrsa build-client-full client1.vpn.ibm.com nopass

（プロンプトが止まったら "yes" と入力）

証明書ファイルの取り出し
./pki/ 以下をまとめて取り出しておく

作成した Secrets Manager に、作成した証明書を登録します。IBM Cloud で作成した Secrets Manager インスタンスを選択し、画面左の「シークレット」を選択し、画面右の「作成」をクリックします：

次の画面では「TLS 証明書」を選択します：

次の画面では「証明書のインポート」を選択します。また、この時点でシークレットの名称（下の例では "kkimura-vpn-certs" ）を指定します：

画面を下方向に、ファイルを３つアップロードするところまでスクロールします：

３か所に、先ほど作成した証明書からそれぞれ以下のファイルを選択して指定します：
　証明書： "./pki/issued/vpn-server.vpn.ibm.com.crt"
　秘密鍵："./pki/private/vpn-server.vpn.ibm.com.key"
　中間証明書："./pki/ca.crt"
最後に「作成」ボタンをクリックします：

正しく処理が行われて、新しいシークレットが作成されたことを確認します：

これで VPN 接続をセキュアに行うための証明書を作成して Secrets Manager で管理するところまでの作業が完了しました。この後はこれらの情報を使って実際に VPN 環境を構築します。

【VPN 環境の作成】
改めて IBM Cloud の VPC のプライベート環境にアクセスするための VPN 環境を作ります。IBM Cloud のカタログから "client vpn for vpc" を検索して選択します：

VPN の設定項目を指定しながら作成していきます。まず VPN タイプには「クライアントとサイト間のサーバー」を選択し、ロケーションは VPN サーバーをどのロケーションに設置するかを指定（下の例では「東京」）します：

設定を続けます。次に VPN サーバー名を適当に（下の例では "kkimura-client-vpn"）入力し、接続対象となる VPC（下の例では上で作成した "kkimura-vpc"）を入力します。その下のクライアント IPv4 アドレスプールには VPN 接続したマシンに割り振られる IP アドレスの範囲（下の例では 10.244.0.0/16）を指定します。ここは上で作成したサブネットと被らないアドレス帯を指定してください：

設定を続けます。VPN サーバーモードは「スタンドアロン・モード」を選択し、そのサブネットは上で作成したサブネット（下の例では "sn-tok2"）を指定します：

設定を続けます。次は認証に関わる設定を行います。サーバー認証の証明書ソースは "Secrets Manager" を選択し、「インスタンスで検索」をクリックしてからサーバー・シークレット・マネージャーとサーバー SSL 証明書として先ほど作成したもの（下の例では "kkimura-secrets-manager-tok2" と "kkimura-vpn-certs"）を指定します：

設定を続けます。次はクライアント認証の設定を行います。「クライアント証明書」にチェックを入れ、証明書ソースは "Secrets Manager"、「インスタンスで検索」を選んでから、上同様にクライアント・シークレット・マネージャーとクライアント SSL 証明書をそれぞれ先ほど作成したもの（下の例では "kkimura-secrets-manager-tok2" と "kkimura-vpn-certs"）を指定します：

設定を続けます。次は一番下までスクロールして追加の構成部分を設定します。トランスポートプロトコルは "UDP" 、VPN ポートは 443 を指定します。またトンネルモードは「フル・トンネル」か「分割トンネル」かを選びます。クライアントがこのプライベートネットワークに VPN 接続中もインターネットの利用をさせる場合は「分割トンネル」を、VPN 接続中はインターネットアクセスを無効にさせる場合は「フルトンネル」を、それぞれ目的に応じて選択します（下の例では「分割トンネル」）。最後に「VPN サーバーの作成」ボタンをクリックして作成します：

作成して状況が「安定」になるまで少し時間がかかりますが、VPN の「クライアントとサイト間のサーバー」タブに VPN が１つ追加されたことが確認できます：

直前の設定で UDP/443 ポートを使う旨を指定しましたが、この設定内容がセキュリティグループでも許可されている必要があります。そのための設定を追加します。

VPC インフラストラクチャー画面の左ペインで「セキュリティ・グループ」を選択します。そこから今設定している VPC（下の例であれば "kkimura-vpc"）のセキュリティグループになっているものを探してクリックします：

セキュリティグループの「ルール」タブを選択して、「作成」ボタンをクリックします：

新しいインバウンドルールを追加します。今回の例であればプロトコルは "UDP"、ポートは「ポート範囲」を選択した上で、最小値と最大値の両方に "443" を入力します。またソースタイプは「すべて」を選択して、最後に「作成」ボタンをクリックします：

これで新しいインバウンドルールが追加され、セキュリティグループでも UDP/443 を許可することができました：

VPN の設定項目はまだ必要なのですが、ここまでの作業ができたら一旦終わりとして、次はプライベートな OpenShift クラスタを作ります。

【プライベート OpenShift クラスタ環境の作成】
パブリックな OpenShift 環境の場合はいきなり OpenShift クラスタを作ってそのまま使い始めることができますが、プライベート環境の場合は（そのセキュリティポリシーにもよりますが）かなり準備が必要でした。が、ここまでできていればあと少しで、OpenShift クラスタを作ることもできます。

IBM Cloud のダッシュボードから「リソースの作成」を選び、カタログの検索バーに "OpenShift" と入力すると "Red Hat OpenShift on IBM Cloud" が見つかるのでこれを選択します：

作成する OpenShift クラスタの設定項目を指定していきます。まずセットアップの種類は「手動セットアップ」で、インフラストラクチャーは "VPC" を選びます。なお、この後マスターサービス・エンドポイントを指定する項目があるのですが、そこで「プライベートのみ」を選択できるのはここで "VPC" を選んだ場合のみです。つまりプライベートクラウドとしての OpenShift 環境を構築するにはここで VPC を選択する必要があり、そのためこの上で準備したような設定を行う必要があったのでした：

続けて利用する VPC（"kkimura-vpc"）とクラウド・オブジェクト・ストレージを指定します。クラウド・オブジェクト・ストレージを使っていない場合は新規に１つ作ってからここで指定します。また OpenShift のバージョンは特にこだわりがなければ最新版を、OCP ライセンスは「このワーカー・プールの追加ライセンスを購入する」を選択します：

ワーカー・ゾーンはワーカーノードをどのゾーンのどのサブネットに配置するかを指定します。サブネットを作成したゾーンと、そのサブネットを指定します。それ以外のゾーンのチェックを外します。またワーカープールのノード数は「２」を指定します（ここで１以下を指定すると作成前のチェックでエラーになりますが、この後の作業でワーカー・ノードは１つに変更できます）。ワーカープールのフレーバー（１台あたりのスペックは必要に応じて適宜変更してください）：

マスター・サービス・エンドポイントを指定します。ここで「プライベート・エンドポイントのみ」を指定します（OpenShift を VPC で作成する場合はプライベートのみが選択できます。Classic 環境だとプライベートのみという選択肢はありません）。また適当な名称でクラスター名を指定します：

最後の統合項目ではアクティビティトラッキングやロギング、モニタリングを有効にすることも可能ですが、不要の場合はチェックを外しても問題ありません。最後に「作成」ボタンをクリックします：

これでプライベート版 OpenShift クラスタ環境のセットアップが開始されます。セットアップが完了するまでしばらく（30分ほど？）待ちます：

ステータスが「正常」になり、Ingress まで含めた全ての機能が正常に稼働している状態になることを確認します：

この状態で「OpenShift Web コンソール」ボタンをクリックしても「OpenShift Web コンソール URL に到達できませんでした」というエラーになることを確認します。この環境はプライベートネットワーク上に構築されているので、これまでのようにインターネット経由でのアクセスができないからです（つまり現時点ではアクセスできないことが正しい状態で、クラスタがプライベートネットワーク上に構築されていることを意味します）：

では次にこのプライベート OpenShift クラスタにアクセスすることができるようになる VPN 環境を構築します：

【VPN サーバー環境の作成】
最後にもう一度 VPN の設定を行います。VPN の経路情報を登録します。VPC インフラストラクチャー画面の左ペインで "VPN" を選択し、「クライアントとサイト間のサーバー」タブに表示される VPN を選択します：

この VPN の「VPN サーバー経路」タブを選択して「作成」ボタンをクリックします：

まずサブネット 10.10.0.0/24 へのアクセスはそのまま通す必要があるので、CIDR に "10.10.0.0/24"、アクションは「配信」を選択して「作成」します（名前は適当に）：

同様に、他のクラウドサービスへもアクセスできる必要があるため、同じ作業を繰り返して、CIDR に "166.8.0.0/14" 、アクションは「変換」でルールを１つ追加します：

下図のように VPN サーバー経路が２つ登録できていれば VPN の経路に関する設定は終わりです：

【VPN クライアント環境の作成】
VPN サーバーの準備ができたので、次に VPN クライアントを用意します。まずは VPN クライアント用のプロファイルをダウンロードします。VPN インフラストラクチャー画面の左ペインで VPN を選び、「クライアントとサイト間のサーバー」タブから先ほど作成した VPN 接続を選択します：

そして「クライアント」タブ内の「クライアント・プロファイルのダウンロード」を選択します。すると .ovpn という拡張子がついた Open VPN 向けプロファイルがダウンロードできます：

自分が付けた VPN 名（この例では "kkimura-client-vpn"）に ".ovpn" という拡張子が付いたファイル名のプロファイルがダウンロードされているはずです。このファイルをテキストエディタで開きます：

ファイルの最後に近いあたりにある "#cert " で始まる行と、"#key " で始まる行両方の "#" を削除します。加えて "cert", "key" に続く文字列を以下のように変更して保存します：
　cert client1.vpn.ibm.com.crt
　key client1.vpn.ibm.com.key

そして証明書ファイルを作った際の ./pki/issued/client1.vpn.ibm.com.crt および ./pki/private/client1.vpn.ibm.com.key の２つのファイルを OVPN ファイルを同じフォルダにコピーします：

これで VPN 接続用プロファイルが準備できました。後は VPN クライアントを用意して、このプロファイルを適用するだけです。

VPN クライアントは（2023/01/04 時点では）OpenVPN クライアントの V2 および V3 が推奨されています。今回はこちらから OpenVPN V3 をダウンロード＆インストールしました。自分のシステム環境プラットフォームにあったものを選んでダウンロードしてください：
https://openvpn.net/vpn-client/#tab-windows

OpenVPN クライアントのインストールが環境したら起動します。初回起動時にプロファイルのインポート画面になるので、FILE タブを選んで"BROWSE" ボタンをクリックし、上で用意した OVPN ファイル（kkimura-client-vpn.ovpn）を指定します：

OVPN ファイルが正しく作成され、また正しく編集できていれば鍵ファイルごと読み込まれてプロファイルのインポートが完了します。ここで "CONNECT" ボタンを押すと VPN 接続が開始します：

設定にミスがなければ VPN 接続は一瞬で完了するはずです。"CONNECTED" と表示されていれば接続できていることになります：

試しにこの VPN 接続ができている間を使ってプライベート OpenShift クラスタが正しく作られていることを確認してみます。IBM Cloud のダッシュボード画面に戻り、作成した OpenShift クラスタを選択して「OpenShift Web コンソール」ボタンをクリックしてみます（先ほどはエラーになったオペレーションです）：

今回は OpenShift のウェブコンソール画面が表示されるはずです。VPN 接続が有効になっているので、この URL にアクセスすることができました。なお IBM Cloud の OpenShift では URL のリージョン部分（例えば "jp-tok"）の直前が "0000" であればパブリック、"i000" であればプライベートな URL になっているとのことで、今回は "****-i000-jp-tok.***" というパターンになっているので、ここでもプライベートな URL にアクセスできていることが確認できます：

ついでに今回は「プライベートクラウド側からインターネット側へのアクセスは許可」するポリシーで環境を構築しました。上述のパブリックゲートウェイが有効になっているので、プライベートクラウド側から Docker ハブ等にもアクセスできるはずなので、それを確認してみます。まずはパースペクティブを切り替えるため、画面左の "Administrator" と書かれた部分をクリックして "Developer" に変更します：

Developer パースペクティブの状態で「＋追加」をクリックし、プロジェクト（例えば "default"）を選択してから「コンテナイメージ」を選択します（新しいアプリケーションをコンテナイメージから作る、という指示を意味しています）：

今回動作検証用に使うアプリケーションのイメージはこれを使うことにします。私が作って Docker ハブで公開しているもので、HTTP でアクセスすると /etc/hostname の内容を読み取って text/plain で返す、というシンプルなアプリケーションです。イメージ名は dotnsf/hostname です：

このイメージを指定します。OpenShift の画面には docker.io/dotnsf/hostname と入力します（Docker ハブ上の dotnsf/hostname という指定です）。入力後に「検証済み」と表示されるまで少し待ちます：

これ以外のオプションは特に変更の必要はありませんが、名称などはお好きなように指定してください。ただ「生成するリソースタイプの選択」は「デプロイメント」を指定するようにしてください。最後に「作成」ボタンをクリックします：

少し時間がかかりますが、以下のような画面が表示されればデプロイ完了です。アイコン右上のリンクボタンをクリックして動作確認してます：

別のウィンドウタブが開いて、プライベート OpenShift 上にデプロイされた dotnsf/hostname アプリにアクセスできることを確認します。またこの URL パターンが "***.i000-jp-tok***" となっていて、プライベート OpenShift のパターンになっていることも合わせて確認します：

無事にプライベート OpenShift 環境を構築することができました。VPN 接続を切る場合、Windows であればタスクバーなどから OpenVPN クライアントを選択して disconnect することもできます：
2023010405

タグ：: #2023; #ibm; #cloud; #vpc; #openshift; #roks; #private

まだプログラマーですが何か？

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf