LoginSignup
10
6

More than 5 years have passed since last update.

@takeyan

BluemixのDiego移行に伴い、Node-REDランタイムの対応が必要になる件

Last updated at Posted at 2016-12-28

Bluemixのベース技術のCloud Foundryのアーキテクチャーが、最新バージョン（V3）でDiegoと呼ばれるものに置き換わることになっており、Bluemixにおいても水面下で移行が進んでいます。
Bluemix Blog記事によると、Bluemixは2017年1月中にDiego環境がGA（正式に提供開始）となり、2017年の早い時期にユーザーのアプリケーションをすべてDiego環境へ移行する措置が取られるそうです。
BluemixのDiego移行の影響については、Bluemixのオンラインマニュアルに「既知の問題」として注意点の記述がありますが、実はNode-REDランタイム（IoT Platform StarterボイラープレートやNode-RED Starterボイラープレートで作成したランタイム）が、最近作成したものを除いて1この「既知の問題」に該当することがわかりました。
該当するNode-REDランタイムを放置しておくと、Diego環境への移行措置が取られた後に動かなくなることも考えられます。リスクを抱えてモヤモヤするよりも、早めに対応してスッキリしましょう。

対応方法はシンプルです。以下に手順を紹介します。

  1. BluemixのDiego移行の影響のおさらい
  2. Node-REDランタイムへの影響の有無の見分け方
  3. Node-REDランタイムのDiego対策
  4. Node-REDランタイムをDiegoに移行

※Bluemixに限らずCloud FoundryをベースとするPaaSはDiego移行の影響への考慮が必要になるはずです。Cloud FoundryのオンラインマニュアルにMigrating Apps to Diegoとして移行ガイドを掲載しているので参考にして下さい。

1. BluemixのDiego移行の影響のおさらい

Bluemixのカタログを見ると2016年12月時点で「インフラストラクチャー」「アプリ」「サービス」という３つのカテゴリーがあります。
この中でアーキテクチャーがDiegoに移行するのは「アプリ」の中にある「Cloud Foundryアプリ」の実行環境（ランタイム）です。これはLiberty for Java、SDK for Node.js等のプログラム実行環境を提供するものです。Cloud Foundryアプリは「ボイラープレート」にも含まれています。従ってこの２つのカテゴリーのアーキテクチャーがDiegoに移行することになります。
Screen Shot 2016-12-28 at 7.57.46.png

それ以外（「インフラストラクチャー」や「サービス」のすべて、および「アプリ」の中の「コンテナー」「OpenWhisk」「モバイル」）は影響を受けません。
Diego移行の注意点は「既知の問題」としてBluemixのオンラインマニュアルに記述があります。以下にそのまま引用します。

既知の問題

Diego の使用に関して、以下の既知の問題があります。

  • --no-route オプションでデプロイされたワーカー・アプリケーションが、正常として報告されません。これを回避するには、cf set-health-check APP_NAME none コマンドでポート・ベースのヘルス・チェックを無効にしてください。
  • VCAP_APP_HOST 環境変数が Diego で使用されません。コードでこの変数を参照する場合は、それを 0.0.0.0 に置き換えてください。
  • VCAP_APP_PORT 環境変数が Diego で使用されません。コードでこの変数を参照する場合は、それを PORT (デフォルトで 8080 に設定されます) に置き換えてください。
  • cf files コマンドはもうサポートされていません。cf ssh コマンドに置き換えられました。cf ssh コマンドについて詳しくは、cf ssh を参照してください。
  • アプリによっては、多くのファイル記述子 (inode) を使用することがあります。この問題が発生した場合は、cf scale APP_NAME [-k DISK] コマンドでアプリのディスク割り当て量を増やす必要があります。

BluemixのボイラープレートのNode-REDは、このうち三番目のVCAP_APP_PORTをつい最近までソースコードに含んでいました。したがってVCAP_APP_PORTを含んでいた頃に作成したNode-REDランタイムは、上記の既知の問題に該当することになります。次章以降で見分け方と対応方法を紹介します。

2. Node-REDランタイムへの影響の有無の見分け方

2-1. VCAP_APP_PORTの使用箇所

Node-REDランタイムの中には、bluemix-settings.jsというコードが含まれています。ソースコードがDiego対応されるまでは、このbluemix-settings.jsの中でVCAP_APP_PORTが使用されていました。以下に該当箇所を引用します。影響を受けるケースでは2行目のuiPortの行でVCAP_APP_PORTを使用しています。

影響を受けるケース
var settings = module.exports = {
    uiPort: process.env.VCAP_APP_PORT || 1880,
    mqttReconnectTime: 15000,
    serialReconnectTime: 15000,
    debugMaxLength: 1000,
影響を受けないケース
var settings = module.exports = {
    uiPort: process.env.PORT || 1880,
    mqttReconnectTime: 15000,
    serialReconnectTime: 15000,
    debugMaxLength: 1000,

2-2. bluemix-settings.jsの目視確認方法

稼働中のNode-REDランタイムのダッシュボードで、bluemix-settings.jsの中味を見ることができます。以下に手順を紹介します。

まずBluemixダッシュボードでNode-REDランタイムを選択します。ランタイムはあらかじめスタートしておきます（停止状態ではファイルを参照できません）。
Screen Shot 2016-12-26 at 18.56.13.png

アプリのダッシュボードでランタイムの画面に切り替えて、更にファイルの画面に切り替えます。
Screen Shot 2016-12-26 at 19.00.22.png

左列のappフォルダを展開し、bluemix-settings.jsをクリックしてソースを表示します。以下の例ではVCAP_APP_PORTが使用されています。
Screen Shot 2016-12-26 at 19.05.02.png

3. Node-REDランタイムのDiego対策

対策としては次の２とおり考えられます。
<対策1> bluemix-settings.jsのVCAP_APP_PORTをPORTに変更する
<対策2> 新規にNode-REDインスタンスを作成し、アプリ（Node-REDフロー）をエクスポート／インポートで移行する
対策はどちらかを実施すればOKです。bluemix-settings.jsを修正するのはハードルが高く感じるかもしれませんが、Node-REDフローの移行に伴ってサービスを接続したりノードの定義の抜け漏れを確認したりするほうが面倒かもしれません。どちらも一長一短だと思いますので、手順をひととおり読んでみてから判断して下さい。
以下にそれぞれの手順を紹介します。

※2017年1月にDiegoが正式に提供開始され、新規作成のランタイムは最初からDiego対応済になりました。したがって現時点では対策2を選択した場合は4章の手順が不要になります。

<対策1> bluemix-settings.jsのVCAP_APP_PORTをPORTに変更する

Node-REDのソースコードにアクセスしてbluemix-settings.jsを書き換えます。手順は「Node-REDのfunctionでVCAP_SERVICESを取得する」の「2.Gitリポジトリを作成」「3.bluemix-settings.jsを編集」「4.編集を反映してNode-REDを再起動」と同様ですので、そちらを参考にして下さい。
実は「2.Gitリポジトリを作成」で作成されたリポジトリには最新のソースコードがコピーされているので、対応前の時期に作成したリポジトリでない限りbluemix-settings.jsの該当箇所はDiego対応済（"PORT"に置き換え済）になっています。したがって「3.bluemix-settings.jsを編集」の手順はスキップしても大丈夫です（bluemix-settings.jsを編集する必要はありません）。ただし「4.編集を反映してNode-REDを再起動」の手順は「プッシュ」まで実行してください。これによりDiego対応済のソースコードがビルド／デプロイされて、ランタイムに反映されます。

※「プッシュ」まで実行しランタイムが再起動した後に、もう一度ダッシュボードの「ファイル」の画面でbluemix-settings.jsを表示すると、修正する前の内容が表示されてしまいます。これはブラウザのキャッシュにbluemix-settings.jsが残ってしまっているからなので、修正後に目視確認する場合にはお手数ですがブラウザのキャッシュをリフレッシュするか、別のブラウザに切り替えて（Firefoxを使っていたらChromeに移る等）表示して下さい。
4章の手順でランタイムをDiegoに移行した後は、ダッシュボードの「ファイル」の画面自体が使えなくなります。Diego移行後に目視確認する場合は、ランタイムにsshログインしてファイルの内容を表示して下さい。sshログインのコマンドは以下のとおりです。

$ cf ssh ランタイム名

Screen Shot 2017-01-05 at 15.57.15.png

<対策2> 新規にNode-REDランタイムを作成し、既存アプリ（Node-REDフロー）をエクスポート／インポートで移行する

これまで作り溜めたNode-REDフローの中には、今後使いそうにないものも多数あるはずです。ときめかないフロー達をこの機会に断捨離して、使うものだけを新しいNode-REDランタイムに移行してはいかがでしょうか。
Node-REDフローはエクスポート／インポートで簡単に移行できます。以下にエクスポートの操作例を紹介します。

まずエクスポートしたいフローをマウスドラッグで選択します。複数のフローを一度に選択しても大丈夫です。選択されたノードは縁取りがオレンジ色に変わります。
Screen Shot 2016-12-28 at 9.52.32.png

次に画面右上の三本線のアイコンからプルダウンメニューを展開してExportのClipboardを選択します。
Screen Shot 2016-12-28 at 9.56.49.png

ポップアップウィンドウにNode-REDフローのソースコードがJSON形式の文字列として表示されるので、これをCrtl+C等でクリップボードにコピーしてインポートに使用します。
Screen Shot 2016-12-28 at 10.05.00.png

インポートも右上の三本線からプルダウンメニューを展開し、ImportのClipboardを選択してポップアップウィンドウを開きます。そこにJSON形式のNode-REDフローをCtrl+V等でペーストします。

Node-REDフローの移行に伴って考慮点がいくつかあります。経験上わかっている範囲で紹介します。

  • 移行元のNode-REDランタイムに接続されているサービス（IoT Platform、Cloudant等）を使い続ける場合には、新規Node-REDランタイムにも既存のサービスとして接続して下さい。サービスは複数のランタイムに接続できるので、移行元のNode-REDランタイムから切り離す必要はありません。
  • APIキーの値やクレデンシャル情報はエクスポートの際にコピーされないことがあります。これらを指定しているノードがありましたら移行後に指定し直して下さい。
  • Node-REDランタイムのURLが変わるので、URLを参照している箇所があったら修正しておいて下さい。

4. Node-REDランタイムをDiegoに移行

3章の<対策1>または<対策2>でDiegoへの移行準備が整ったら、Node-REDランタイムをDiegoに移行します。移行にはCloud Foundry CLI（cfコマンド）を使用します。cfコマンドのセットアップ方法は、こちらをご参照下さい。以下、cfコマンドが使える前提で手順を紹介します。

※2017年1月にDiegoが正式に提供開始され、新規作成のランタイムは最初からDiego対応済になりました。したがって現時点では対策2を選択した場合は4章の手順が不要になります。

4-1. Diego Enablerをインストール

$ cf add-plugin-repo CF-Community https://plugins.cloudfoundry.org/
$ cf install-plugin Diego-Enabler -r CF-Community

Screen Shot 2016-12-28 at 11.07.29.png

4-2. まだDiegoに移行していないランタイムの一覧表示

以下のコマンドを実行して、移行対象のNode-REDランタイムが表示されることを確認します。

$ cf dea-apps

Screen Shot 2016-12-28 at 16.48.26.png

4-3. ランタイム停止

$ cf stop ランタイム名

Screen Shot 2016-12-28 at 11.23.16.png

4-4. Node-REDランタイムをDiego対応に変換

cf enable-diego ランタイム名

Screen Shot 2016-12-28 at 14.38.02.png

4-5. Diegoに移行済のランタイムの一覧表示

以下のコマンドを実行して、移行対象のNode-REDランタイムが表示されることを確認します。

$ cf diego-apps

Screen Shot 2016-12-28 at 14.40.32.png

4-6. 念の為Node-REDランタイムの起動を確認

bluemix-settings.jsが未修正（VCAP_APP_PORTが残ったまま）の状態で、上記4-4のコマンドでDiego対応に変換すると、ランタイムは起動できなくなります。変換後に念の為起動確認しておくと安心です。

$ cf start ランタイム名

Screen Shot 2016-12-28 at 14.44.21.png

補足. Node-REDランタイムのDiego対応以前への戻し手順

Diegoに移行したランタイムは、以下のコマンドで移行以前の状態（DEAを使用）に戻すことができます。移行／戻しは何度でも実行できます。

$ cf disable-diego ランタイム名

以上です。

参照：
https://www.ibm.com/blogs/bluemix/2016/11/bluemix-cloud-foundry-upgrading-dea-diego-architecture/
https://console.ng.bluemix.net/docs/manageapps/depapps.html#deployingapps
http://qiita.com/ibmamnt/items/03a5619d2452c3138fa8
https://github.com/ibmets/node-red-bluemix-starter/issues/6
http://qiita.com/Ra1nmaker/items/cd0e80a97b18623cf4b5

  1. 2016年11月中のどこかのタイミングでボイラープレートが修正されたようです。それ以前に作成したNode-REDインスタンスは基本的にすべて該当します。 ↩

10
6
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
10
6