Kubernetes上で稼働するCloud Foundry - Cloud Foundry Enterprise Environment 事始め

Cloud Foundry Enterprise Environment(CFEE)とは

IBM Cloudでは2014年にBluemixとしてサービスを提供を開始して以来、Cloud Foundryのアプリケーション実行環境をマネージド・サービスが利用可能です。Cloud FoundryはPaaSのアプリケーション・プラットフォームであり、アプリケーションを実行するためのリソースについて、細かな管理をしなくても柔軟にアプリケーションの稼働環境を利用できる特徴があります。具体的にはビルドパックという仕組みを使って複数の言語をサポート可能なほか、デプロイされたアプリケーションのスケーリング、障害からの回復性、高可用性かつ災害対策を考慮した構成などをとることできるあたりが特徴的です。
IBM Cloud上のサービスではマルチテナントで稼働するPublicサービスの他に、IBM Cloud内のシングルテナント環境で稼働する専有型のサービスがあり、CFEEはこの専有型サービスにあたります。お客様が稼働されるアプリケーションの種類により、非常に安価に利用できるPublicサービスと専有環境を構築できるCFEEを使い分けることが可能です。

今回はCFEEがどのようなものかというところをお伝えしたいと思います。

CFEEの稼働スタック

CFEEはCloud Foundry Publicサービスとは異なり利用者のアカウントの中でワークロードが稼働できます。一方で利用者のアカウント内のリソースについては利用者が維持・運用する必要があります。そのため、どういうスタックで稼働するかを利用者側で意識する必要があります。CFEEが稼働するスタックは以下の図のような環境です。

CFEEを一言で表すとKubernetesクラスター上で稼働するように構成されたCloud Foundry環境です。そのため、Kubernetesの実行環境が必要となります。IBM CloudではKubernetes Service(IKS)の上で稼働します。Kubernetesクラスター上にCFEEのDiegoセルとControl Planeがそれぞれ別のノードとして稼働します。Diegoセルはお客様のアプリケーション・インスタンスが稼働するサーバーでこのセルの数を増やしたりスペックをあげることでCFEE環境全体の処理能力を増強させることができます。冗長性の観点から2つ以上のDiegoセルを配置することがお勧めです。Control Planeは利用者のアプリケーション以外の管理機能を含みます。Diegoセルの構成によらず、冗長構成がとられ、複数台のサーバー上で稼働されるように構成されます。
Databases for PostgreSQLとCloud Object StorageはCloud Foundry環境を管理するためのメタデータやBlobオブジェクトが配置されます。利用者が意識的に管理する必要はありませんが、これらのサービスも使われていることは意識する必要があります。CFEEを稼働させるための最小構成ではこれらのサービスも必要で、利用量に応じた課金が発生します。
CFEEサービス管理とIKS Master Nodeはマネージド・サービスとして運用する上で必要な機能をIBM側で用意し、維持・運用しているものです。利用者の視点ではネットワーク越しにアクセスできる環境を維持する必要があります。

CFEEのプロビジョニング

アクセスポリシーの設定

CFEEのプロビジョニングを開始するために利用者にIBM Cloudユーザー管理におけるアクセス権限を付与しておく必要があります。詳細はIBM Cloud Docsのページにてご確認ください。
プロビジョニングして諸々の操作をを行うためには以下の権限を設定するのがよいと思います。

• CFEEを作成するリソース・グループに対する 「ビューアー」 役割
• CFEEサービスに対する 「プラットフォーム・アクセス」の「管理者」 役割
• Kubernetesサービスに対する 「プラットフォーム・アクセス」の「管理者」 役割
• Databases for PostgreSQLサービスに対する 「プラットフォーム・アクセス」の「管理者」 役割
• クラシック・インフラストラクチャーサービスにおける Power Users許可セット
• Object Storageサービスに対する「プラットフォーム・アクセス」の「エディター」 および 「サービス・アクセス」の「管理者」役割
• アカウント管理サービスSupport Centerに対する「エディター」役割

カタログ上におけるプロビジョニングの設定

まずはIBM Cloudのカタログにアクセスしましょう。「Cloud Foundry Enterprise Environment」というタイルはなく「Cloud Foundry」とまとめられているので、そちらを探してクリックします。

Cloud FoundryのPublicサービスとCFEEを選択する画面が表示されるので「エンタープライズ環境」の「作成」ボタンをクリックします。次の画面では「続行」ボタンをクリックします。

「Cloud Foundry Enterprise Environmentの構成」画面は縦に長いので順番に説明していきます。

• 「プラン」は現在は「Standard」プランしかありません。
• 「環境の選択」では「クラシック」を選択します。

• 「名前」にはCFEE環境の名称を設定します。
• 「リソース・グループ」は変更する理由がなければ「Default」のままで構いません。
• 「可用性」は用途に応じて選択します。本番環境として利用される場合には複数のアベイラビリティーゾーンに分散配置される「複数ゾーン」の利用がおすすめです。
• 「リージョン」は「東京」とすることで東京リージョンにデプロイされます。
• 「ワーカー・ゾーン」はデプロイする先のゾーンを選択します。この例では東京2(tok04), 東京3(tok05)を選択していますが、2つのゾーンにデプロイする設定となっています。
• 「ハードウェアの分離」は共有型(マルチテナント)の仮想サーバーを使用するか、専有型(シングルテナント)の仮想サーバーを使用するかを選択します。
• 「ローカル・ディスクの暗号化」は仮想サーバーの内蔵ディスクを暗号化するか否かを選択します。デフォルトはチェックありなので、そのままチェックを入れておきます。
• 「管理に使用するサービス・アクセス・エンドポイント」はアカウントの状況により、プライベート・ネットワークを利用できる場合にはプライベート・ネットワークを利用し、それ以外はパブリック・ネットワークが使用されます。
  

最後にクラスターを構成するノードの台数とスペックを指定します。

• 「ゾーンあたりのセルの数」にはアベイラビリティー・ゾーンあたりのセルの数を指定します。右側の「コントロール・ブレーン・ノード数」は「ワーカー・ゾーン」として指定されたゾーンの数に応じてControl Planeのデプロイ先とその数が決まります。単一ゾーン構成の場合には指定されたゾーンに2台のControl Planeノードが設定され、複数ゾーン構成の場合には指定されたゾーンに各1ノードずつデプロイされます。イメージが湧くように下に図示してみました。

• 「セル・ノード」と「コントロール・プレーン・ノード」はそれぞれ仮想サーバーのスペックを選択します。「4コア 16GB RAM」もしくは「8コア 32GB RAM」から選択します。組み合わせで利用できない組み合わせ（下表参照）もあります。

	セル・ノード 4コア16GB	セル・ノード 8コア32GB
コントロール・プレーン・ノード 4コア16GB	○	×
コントロール・プレーン・ノード 8コア32GB	○	○

最後に「作成」(もしくは「Create」)ボタンをクリックすると環境作成が始まります。

今回は1時間半ほどでプロビジョニングが完了しました。「概要」をクリックすると稼働しているノード（セル、コントロール・プレーン）の稼働状況が表示されます。ここまでで専有のCloud Foundry環境ができました。

なお、この画面を閉じてしまい、戻れなくなった場合にはリソース・リストのCloud Foundry enterprise environmentsのサービス名（以下の例ではmycfee）をクリックすると戻れます。

組織とスペースを作ってみる

ここからはCloud Foundryアプリケーションを稼働させるための手順となります。Cloud FoundryのPublicサービスでも組織とスペースを作成しますが、CFEEを利用する場合にはCFEEサービスのインスタンスごとにそれらを管理します。
サービスインスタンスの「組織」を表示します。プロビジョニング時に作成されるsystemという組織がリストされます。
今回は開発チームがデモを行うための組織とスペースを作っていきます。
まず、新しいdevという組織を作成していきます。「組織の作成」ボタンをクリックします。

• 「組織名」はdevとします。
• 「管理者」はIBM Cloudアカウントに招待されているメンバーを設定する必要があります。
• 「割り当て量プラン」はdefaultのままで構いませんが、qxGBという表示の別のプランに変更しても構いません。アプリケーションで利用できるメモリー量の合計、サービス・インスタンス数の上限、Cloud Foundryアプリケーションの経路の数がプランにより異なります。
• 「追加」ボタンをクリックします。

devという組織が作成されたので、表内の「dev」をクリックします。

「スペース」タブを選択します。まだスペースは作成されていないので空の表が表示されます。
次に新しいdemoというスペースを作成していきます。「スペースの作成」ボタンをクリックします。

• 「スペース名」はdemoとします。
• 「管理者」はIBM Cloudアカウントに招待されているメンバーを設定する必要があります。組織の管理者と同一である必要はありません。
• 「追加」ボタンをクリックします。

必要に応じて追加のメンバーを組織やスペースに追加し、必要な役割を与えます。この辺りの考え方はCloud Foundry Publicサービスと同じ考え方です。操作画面が異なることを除けば新しいことは何もありません。

簡単なアプリをデプロイしてみる

組織とスペースを作成したので、サンプルアプリケーションをデプロイしていきましょう。IBM Cloud CLIもしくはCloud Foundry CLIをインストールしておく必要があります。
サンプルアプリケーションとしてはNode.jsのHello WorldアプリケーションURLを利用します。ローカル環境にcloneしておきます。

今回はCloud Foundfry CLIを使っていきます。まずはcf loginコマンドでログインします。-aオプションで指定するAPIのエンドポイントは管理今ソースのCFEEのサービスインスタンスの「概要」画面の右上に表示されるのでコピーして使います。
また、組織を選択する箇所ではdevという組織を使用するのでそちらの番号を選択します。(下記の例では1番)

$ cf login -a https://api.mycfee-cluster-c82xxx5867b41450588f492846xxx9a8-0000.jp-tok.containers.appdomain.cloud
API エンドポイント: https://api.mycfee-cluster-c82xxx5867b41450588f492846xxx9a8-0000.jp-tok.containers.appdomain.cloud


Email: <IBMidのE-mailアドレス>

パスワード: 
認証中です...

OK


Select an org:
1. dev
2. system

組織 (enter to skip): 1
Targeted org dev

Targeted space demo



API エンドポイント:   https://api.mycfee-cluster-c82xxx5867b41450588f492846xxx9a8-0000.jp-tok.containers.appdomain.cloud (API version: 3.72.0)
ユーザー:             <IBMidのE-mailアドレス>
組織:                 dev
スペース:             demo

ログインできました。それではアプリケーションをデプロイしていきます。Cloud Foundryアプリケーションではcf pushコマンドを実行します。バインドされるサービスなどがある場合にはオプションを指定する必要がありますが、今回はスタンドアローンで稼働するアプリケーションなので、コマンドだけを実行します。

$ cf push
<IBMidのE-mailアドレス> としてマニフェストから組織 dev / スペース demo にプッシュしています...
マニフェスト・ファイル /<ファイルを配置したパス>/node-helloworld/manifest.yml を使用しています
アプリ情報を取得しています...
これらの属性でアプリを作成しています...
+ 名前:       hello-node
  パス:       /<ファイルを配置したパス>/node-helloworld
+ メモリー:   128M
  経路:
+   hello-node-rested-porcupine-ap.mycfee-cluster-c82xxx5867b41450588f492846xxx9a8-0000.jp-tok.containers.appdomain.cloud

アプリ hello-node を作成しています...
経路をマップしています...
ローカル・ファイルをリモート・キャッシュと比較しています...
Packaging files to upload...
ファイルをアップロードしています...
 15.19 KiB / 15.19 KiB [======================================================================================================================================================================] 100.00% 1s

API がファイルの処理を完了するのを待機しています...

アプリをステージングし、ログをトレースしています...
   Downloading xpages_buildpack_v1_2_2...
   Downloading ruby_buildpack...
   Downloading binary_buildpack...
   Downloading nodejs_buildpack...
   Downloading go_buildpack...
   Downloaded binary_buildpack
   Downloading python_buildpack...
   Downloaded go_buildpack (4.5M)
   Downloading php_buildpack...
   Downloaded nodejs_buildpack (4.6M)
   Downloading swift_buildpack...
   Downloaded ruby_buildpack (5M)
   Downloading liberty-for-java...
   Downloaded python_buildpack (4.5M)
   Downloading sdk-for-nodejs...
   Downloaded php_buildpack (324.7K)
   Downloading dotnet-core...
   Downloaded sdk-for-nodejs (155.8M)
   Downloading staticfile_buildpack...
   Downloaded staticfile_buildpack (5M)
   Downloading xpages_buildpack...
   Downloaded xpages_buildpack (307.5M)
   Downloading java_buildpack...
   Downloaded dotnet-core (944.6M)
   Downloading dotnet-core_v2_4-20190912-1554...
   Downloaded java_buildpack (207.1K)
   Downloading liberty-for-java_v3_38-20191031-1433...
   Downloaded xpages_buildpack_v1_2_2 (307.5M)
   Downloading sdk-for-nodejs_v4_0_1-20190930-1425...
   Downloaded liberty-for-java (757M)
   Downloading swift_buildpack_cflinuxfs3_v2_1_0-20190404-1206...
   Downloaded swift_buildpack (813.4M)
   Downloaded sdk-for-nodejs_v4_0_1-20190930-1425 (155.8M)
   Downloaded dotnet-core_v2_4-20190912-1554 (944.6M)
   Downloaded liberty-for-java_v3_38-20191031-1433 (757M)
   Downloaded swift_buildpack_cflinuxfs3_v2_1_0-20190404-1206 (813.4M)
   Cell diego-cell-1 creating container for instance 0e59af6b-d11a-4b93-8ac8-57c17aac87fb
   Cell diego-cell-1 successfully created container for instance 0e59af6b-d11a-4b93-8ac8-57c17aac87fb
   Downloading app package...
   Downloaded app package (15.2K)
   cat: /VERSION: No such file or directory
   -----> IBM SDK for Node.js Buildpack v4.0.1-20190930-1425
          Based on Cloud Foundry Node.js Buildpack 1.6.53
          
   -----> Installing binaries
          engines.node (package.json): unspecified
          engines.npm (package.json): unspecified (use default)
          **WARNING** Node version not specified in package.json or .nvmrc. See: http://docs.cloudfoundry.org/buildpacks/node/node-tips.html
          Attempting to install: 10.16.3
   -----> Installing node 10.16.3
          Copy [/tmp/buildpacks/700edfaeef3b2e3a8718371a6adec764/dependencies/9afdb4f3300cc6a181909f11075912df/node-10.16.3-linux-x64-cflinuxfs3-33294d36.tgz]
          Using default npm version: 6.9.0
   -----> Installing yarn 1.17.3
          Copy [/tmp/buildpacks/700edfaeef3b2e3a8718371a6adec764/dependencies/748132b4ee4ecaf8bbb5bfa5932e6689/yarn-1.17.3-any-stack-e3835194.tar.gz]
          Installed yarn 1.17.3
   -----> Creating runtime environment
          PRO TIP: It is recommended to vendor the application's Node.js dependencies
          Visit http://docs.cloudfoundry.org/buildpacks/node/index.html#vendoring
          NODE_ENV=production
          NODE_HOME=/tmp/contents291082166/deps/0/node
          NODE_MODULES_CACHE=true
          NODE_VERBOSE=false
          NPM_CONFIG_LOGLEVEL=error
          NPM_CONFIG_PRODUCTION=true
   -----> Building dependencies
          Installing node modules (package.json + package-lock.json)
   added 59 packages from 44 contributors and audited 135 packages in 1.141s
   found 0 vulnerabilities
          **WARNING** Unmet dependencies don't fail npm install but may cause runtime issues
          See: https://github.com/npm/npm/issues/7494
          Contrast Security no credentials found. Will not write environment files.
   Exit status 0
   Uploading droplet, build artifacts cache...
   Uploading droplet...
   Uploading build artifacts cache...
   Uploaded build artifacts cache (703.3K)
   Uploaded droplet (21.9M)
   Uploading complete
   Cell diego-cell-1 stopping instance 0e59af6b-d11a-4b93-8ac8-57c17aac87fb
   Cell diego-cell-1 destroying container for instance 0e59af6b-d11a-4b93-8ac8-57c17aac87fb
   Cell diego-cell-1 successfully destroyed container for instance 0e59af6b-d11a-4b93-8ac8-57c17aac87fb

アプリが開始するのを待機しています...

名前:                   hello-node
要求された状態:         started
経路:                   hello-node-rested-porcupine-ap.mycfee-cluster-c82xxx5867b41450588f492846xxx9a8-0000.jp-tok.containers.appdomain.cloud
最終アップロード日時:   
スタック:               cflinuxfs3
ビルドパック:           sdk-for-nodejs

タイプ:           web
インスタンス:     1/1
メモリー使用量:   128M
開始コマンド:     node server
     状態   開始日時               cpu    メモリー        ディスク      詳細
#0   実行   2019-12-               0.0%   128M の中の 0   1G の中の 0   

Cloud Foundryアプリケーションが稼働できました。念のため、URLにアクセスして画面を表示してみましょう。経路の情報は上のコマンドの実行結果の最後から10行目の「経路:」に表示されるものです。アクセスしてみると、無事に表示されますね。

このセクションでの操作内容を振り返ると、Cloud Foundry環境にログインして、cf pushコマンドを実行するところまで、Publicサービスにおけるそれと全く同じ手順なのがわかると思います。違うのはログイン時に利用したAPIのエンドポイントだけです。

管理コンソール(Stratos)をインストールする

プロビジョニング直後の状態では、Cloud Foundryの詳細な情報にアクセスできるGUIベースの管理コンソールは利用できません。Cloud FoundryのStratosという管理コンソールをインストールすることで利用することができます。StratosもCFEE環境上で稼働するKubernetesもしくはCloud Foundryアプリケーションです。
この先サービスの管理など行うためにインストールしていきます。CFEEサービスインスタンスの概要画面右上にある「Stratos Consoleのインストール」ボタンをクリックします。

インストール・オプションの設定画面が表示されるので、今回は「Kubernetesのデプロイメント」としてアプリ・インスタンスを2としてインストールします。Cloud Foundryアプリの場合には後ほど説明する組織とスペースの作成をあらかじめ実施する必要があります。

インストールは3分程度で終わりました。終わると「Stratos Console」というボタンが表示されるのでそちらをクリックします。

StratosコンソールのHome画面が表示されます。まだ何も実施していないので空の画面となっています。

参考: StratosのKubernetes Deploymentの確認

インストール後にIKS上で稼働中のデプロイメントやポッドを確認するとstratosというネームスペースにデプロイメントが作成され、先ほど指定したとおり2つのポッドが稼働していることがわかります。
なお、IKS上に直接利用者のアプリケーションをインストールして稼働させることは技術的にはできますが、CFEE利用上は非推奨となっていますので、別途IKSのクラスターを準備する必要があります。

Node-REDを稼働させてみる

先ほど簡単なスタンドアロンアプリケーションは簡単に稼働できました。最後にもう少し複雑なアプリケーションの例としてNode-REDを稼働させてみましょう。IBMがサンプルとして公開しているNode-RED Starterを使ってみます。

Node-RED Starterは以下のアプリとサービスから構成されます。

• Node.jsで稼働するNode-REDアプリケーション
• フローデータを保存するCloudantデータベース

Node-RED Starterを稼働させるためにはこれらをデプロイした後に正しくこれらをバインドして起動する必要があります。ここでは以下のような手順で進めていきます。

• (手順1) Cloudantサービスインスタンスの作成
• (手順2) Node-REDアプリケーションの設定ファイルの変更
• (手順3) Node-REDアプリケーションのデプロイ
• (手順4) Node-REDアプリケーションとCloudantサービスインスタンスのバインド
• (手順5) Node-REDアプリケーションの起動と稼働確認

(手順1) Cloudantサービスインスタンスの作成

さきほど作成したStratosコンソールにアクセスします。左側のメニューで「Marketplace」を選択します。MarketplaceはIBM Cloudでいうところのカタログで利用可能なサービスがリストされます。ここではCloudantを作成するので、「Cloudant」のパネルをクリックします。

次の画面では右上「+」をクリックします。

• 「Organization」にdevを設定します。
• 「Space」にdemoを設定します。
• 「Next」をクリックします。

• 次の画面ではサービスのプランを選択します。ここではstandardを選択します。
• 「Next」をクリックします。

• 次の画面ではバインドするアプリケーションを選択しますが、まだありませんので初期設定のまま「Next」をクリックします。

Cloudantのリソースに関する設定を行います。

• 「Name」はCFEE内で利用できるサービス・インスタンスの名称を指定します。Cloudant-dev-demo-noderedという名称にします。
• 「Tag」と「Service Parameters」は特に設定しません。
• 「Resource Group」にはResource GroupのIDを設定します。IBM Cloudのアカウントにかかるリソース・グループのページにアクセスし、ID列の値を取得します。今回はDefaultというリソース・グループを使うので、その値をコピーして貼ります。
• 「Target」はサービスインスタンスをデプロイするリージョンを選択します。ここではbluemix-jp-tokを選択します。
• 「Instance Name」はIBM Cloudからみたときのサービス・インスタンス名を指定します。特に「Name」と区別する必要はないので、同じ Cloudant-dev-demo-noderedという名称にします。
• 「Finish」をクリックします。

リソースグループのIDの取得

しばらくするとインスタンスが作成されます。Stratosのコンソール上は以下のように表示されます。

(手順2) Node-REDアプリケーションの設定ファイルの変更

Node-REDアプリケーションが作成したCloudantサービスインスタンスを参照できるように設定を変更します。
アプリケーションからバインドされたサービスインスタンスの名称を参照できるようにします。具体的には環境変数にNode-REDをカスタマイズする際に使用する変数を設定します。

NODE_RED_STORAGE_NAME: Cloudant-dev-demo-noderedの1行を挿入します。

node-red-starter/manifest.yaml

applications:
- memory: 256M
  env:
    OPTIMIZE_MEMORY: true
    NODE_RED_STORAGE_NAME: Cloudant-dev-demo-nodered
  command: node index.js --settings ./bluemix-settings.js -v

(手順3) Node-REDアプリケーションのデプロイ

Node-REDアプリケーションをプッシュしていきましょう。ただし、サービスとのバインドなど必要な手続きがあるので、プッシュしたのちに起動しない設定(--no-startオプションあり)でプッシュします。

$ cf push node-red-starter --no-start
<IBMidのE-mailアドレス> としてマニフェストから組織 dev / スペース demo にプッシュしています...
マニフェスト・ファイル /U<ファイルを配置したパス>/node-red-bluemix-starter/manifest.yml を使用しています
アプリ情報を取得しています...
これらの属性でアプリを作成しています...
+ 名前:       node-red-starter
  パス:       /Users/ibm/cfeeapp/node-red-bluemix-starter
+ コマンド:   node index.js --settings ./bluemix-settings.js -v
+ メモリー:   256M
  環境:
+   NODE_RED_STORAGE_NAME
+   OPTIMIZE_MEMORY
  経路:
+   node-red-starter.mycfee-cluster-c82xxx5867b41450588f492846xxx9a8-0000.jp-tok.containers.appdomain.cloud

アプリ node-red-starter を作成しています...
経路をマップしています...
ローカル・ファイルをリモート・キャッシュと比較しています...
Packaging files to upload...
ファイルをアップロードしています...
 39.23 KiB / 39.23 KiB [======================================================================================================================================================================] 100.00% 1s

API がファイルの処理を完了するのを待機しています...

名前:                   node-red-starter
要求された状態:         stopped
経路:                   node-red-starter.mycfee-cluster-c82xxx5867b41450588f492846xxx9a8-0000.jp-tok.containers.appdomain.cloud
最終アップロード日時:   
スタック:               
ビルドパック:           

タイプ:           web
インスタンス:     0/1
メモリー使用量:   256M
開始コマンド:     node index.js --settings ./bluemix-settings.js -v
     状態     開始日時               cpu    メモリー     ディスク     詳細
#0   ダウン   2019-12-               0.0%   0 の中の 0   0 の中の 0   

(手順4) Node-REDアプリケーションとCloudantサービスインスタンスのバインド

アプリケーションとサービスインスタンスをバインドしていきましょう。
まず、Stratosコンソールの「Applications」にアクセスすると「node-red-starter」が追加されていることがわかります。「node-red-starter」をクリックします。

アプリケーションの詳細が表示されます。左側の「Services」をクリックします。

「+」をクリックしてサービスを追加していきます。

• 「Marketplace Service」をクリックします。

• Serviceのリストから「cloudantNoSQLDB」を選択します。
• 「Next」をクリックします。

• プランはリストから「Standard」を選択します。
• 「Next」をクリックします。

• 「Next」をクリックします。

• 「Bind to an Existing Service Instance」を選択します。
• Service Instanceとして先ほど作成した Cloudant-dev-demo-starterを選択します。
• 「Finish」をクリックします。

バインドできると以下のような画面が表示され、アプリケーションからバインドできたことがわかります。

(手順5) Node-REDアプリケーションの起動と稼働確認

それではアプリケーションを起動します。cf startコマンドでnode-red-starterアプリケーションを起動します。

$ cf start node-red-starter
<IBMidのE-mailアドレス> として組織 dev / スペース demo 内のアプリ node-red-starter を開始しています...

アプリをステージングし、ログをトレースしています...
   Downloading xpages_buildpack_v1_2_2...
   Downloading staticfile_buildpack...
   Downloading sdk-for-nodejs...
   Downloading dotnet-core...
   Downloading liberty-for-java...

(中略)

   Uploading droplet, build artifacts cache...
   Uploading droplet...
   Uploading build artifacts cache...
   Uploaded build artifacts cache (21.7M)
   Uploaded droplet (67.3M)
   Uploading complete
   Cell diego-cell-1 stopping instance 8daxxxxxx94d3-4b0c-8398-91axxxxxxdb4
   Cell diego-cell-1 destroying container for instance 8daxxxxxx94d3-4b0c-8398-91axxxxxxdb4
   Cell diego-cell-1 successfully destroyed container for instance 8daxxxxxx94d3-4b0c-8398-91axxxxxxdb4

アプリが開始するのを待機しています...

名前:                   node-red-starter
要求された状態:         started
経路:                   node-red-starter.mycfee-cluster-c82xxx5867b41450588f492846xxx9a8-0000.jp-tok.containers.appdomain.cloud
最終アップロード日時:   
スタック:               cflinuxfs3
ビルドパック:           sdk-for-nodejs

タイプ:           web
インスタンス:     1/1
メモリー使用量:   256M
開始コマンド:     node index.js --settings ./bluemix-settings.js -v
     状態   開始日時               cpu    メモリー        ディスク      詳細
#0   実行   2019-12-               0.0%   256M の中の 0   1G の中の 0   

コマンドの実行結果の下から10行目あたりの「経路」のURLにアクセスします。Node-REDの設定画面が表示され、アプリは起動したことがわかりました。

Node-REDの設定を終えたのちにNode-RED Editorにログインして、簡単なフローを作ってみます。
デプロイしたのちにInject操作を行い、debugメッセージが表示されることを確認します。
きちんとメッセージが表示されていますね。これでアプリとしての稼働確認は終了です。

最後にCloudantにデータが本当にできているのかというところだけ確認しましょう。

Stratosコンソールにアクセスし、「Services」でインスタンスを表示させます。Dashboardの「View」をクリックします。

画面右上の「Launch Cloudant Dashboard」をクリックします。

DatabasesにnoderedstarterというDBができています。

さらに文書をみると「noderedstarter/flow」には作成したフローの情報が格納されていて、アプリとバインドしたサービスにも正しくアクセスできていたことがわかります。

おわりに

Kubernetes上で稼働するCloud Foundry環境であるCloud Foundry Enterprise Environment(CFEE)についてプロビジョニングして簡単なアプリケーションを稼働させるところまでを実施してみました。環境をプロビジョニングする部分もアプリケーションをpushする部分もPublicサービスのそれらを同じようにごく簡単な操作で実施できますね。

CFEEはRed Hat OpenShift上での稼働についてもサポートされる予定で来年は稼働させる環境の幅が広がりそうです。また、記事には含めませんでしたが、Cloud Foundry FoundationのProject Eiriniについてもbeta版の公開が行われていました。EiriniはCloud FoundryアプリケーションをKubernetes環境上でも稼働させる取り組みで、現状はDiegoで行われているスケジュール機能をKubernetesのそれと置き換えることを可能とします。すでにbeta版の提供は終了していますが、来年以降CFEEの環境がCloud Foundryコミュニティの新しい機能をさらに取り込むことが期待されます。