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

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

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

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

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](https://docs.cloudfoundry.org/running/apps-enable-diego.html)として移行ガイドを掲載しているので参考にして下さい。

## 1. BluemixのDiego移行の影響のおさらい
Bluemixのカタログを見ると2016年12月時点で「インフラストラクチャー」「アプリ」「サービス」という３つのカテゴリーがあります。
この中でアーキテクチャーがDiegoに移行するのは「アプリ」の中にある「Cloud Foundryアプリ」の実行環境（ランタイム）です。これはLiberty for Java、SDK for Node.js等のプログラム実行環境を提供するものです。Cloud Foundryアプリは「ボイラープレート」にも含まれています。従ってこの２つのカテゴリーのアーキテクチャーがDiegoに移行することになります。
<img width="1280" alt="Screen Shot 2016-12-28 at 7.57.46.png" src="https://qiita-image-store.s3.amazonaws.com/0/32083/f04b70fd-9444-e7b8-4152-2bc9f80bcb14.png">

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

> #### 既知の問題
>
> 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を使用しています。

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

```js:影響を受けないケース
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ランタイムを選択します。ランタイムはあらかじめスタートしておきます（停止状態ではファイルを参照できません）。
<img width="1280" alt="Screen Shot 2016-12-26 at 18.56.13.png" src="https://qiita-image-store.s3.amazonaws.com/0/32083/ffce8722-6fd9-53a4-1f49-4df4a84c136b.png">


アプリのダッシュボードでランタイムの画面に切り替えて、更にファイルの画面に切り替えます。
<img width="1280" alt="Screen Shot 2016-12-26 at 19.00.22.png" src="https://qiita-image-store.s3.amazonaws.com/0/32083/15d8fe99-a3b1-8c47-ffe0-4576ac6f29d1.png">


左列のappフォルダを展開し、bluemix-settings.jsをクリックしてソースを表示します。以下の例ではVCAP_APP_PORTが使用されています。
<img width="1280" alt="Screen Shot 2016-12-26 at 19.05.02.png" src="https://qiita-image-store.s3.amazonaws.com/0/32083/4fd42456-cae4-c180-ee72-38fb6feb7c56.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を取得する](http://qiita.com/takeyan/items/6a98027a67bc939337d4)」の「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ログインのコマンドは以下のとおりです。

```bash
$ cf ssh ランタイム名
```
<img width="649" alt="Screen Shot 2017-01-05 at 15.57.15.png" src="https://qiita-image-store.s3.amazonaws.com/0/32083/6df39e23-9657-9197-5aaa-e07dee906a3a.png">



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

まずエクスポートしたいフローをマウスドラッグで選択します。複数のフローを一度に選択しても大丈夫です。選択されたノードは縁取りがオレンジ色に変わります。
<img width="1150" alt="Screen Shot 2016-12-28 at 9.52.32.png" src="https://qiita-image-store.s3.amazonaws.com/0/32083/79d54861-8648-dcb6-24e9-397557421a6d.png">

次に画面右上の三本線のアイコンからプルダウンメニューを展開してExportのClipboardを選択します。
<img width="1280" alt="Screen Shot 2016-12-28 at 9.56.49.png" src="https://qiita-image-store.s3.amazonaws.com/0/32083/be79e0b5-26e6-83f8-f1c9-ed98cb9d97e5.png">

ポップアップウィンドウにNode-REDフローのソースコードがJSON形式の文字列として表示されるので、これをCrtl+C等でクリップボードにコピーしてインポートに使用します。
<img width="1280" alt="Screen Shot 2016-12-28 at 10.05.00.png" src="https://qiita-image-store.s3.amazonaws.com/0/32083/837cfe12-c020-bf96-167e-a2325b889a9d.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コマンドのセットアップ方法は、[こちら](https://knowledgelayer.softlayer.com/jp/procedure/bluemix-cloud-foundry-komandorainyuteiritei)をご参照下さい。以下、cfコマンドが使える前提で手順を紹介します。

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


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

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

<img width="917" alt="Screen Shot 2016-12-28 at 11.07.29.png" src="https://qiita-image-store.s3.amazonaws.com/0/32083/023cf274-a242-57f1-eba9-43fd9241b4e9.png">

### 4-2. まだDiegoに移行していないランタイムの一覧表示
以下のコマンドを実行して、移行対象のNode-REDランタイムが表示されることを確認します。

```bash
$ cf dea-apps
```

<img width="451" alt="Screen Shot 2016-12-28 at 16.48.26.png" src="https://qiita-image-store.s3.amazonaws.com/0/32083/4b0dc9c7-82e6-72ba-1c2a-d89e8e457a22.png">

### 4-3. ランタイム停止

```bash
$ cf stop ランタイム名
```

<img width="701" alt="Screen Shot 2016-12-28 at 11.23.16.png" src="https://qiita-image-store.s3.amazonaws.com/0/32083/00d8f389-8f58-7f99-23f4-503c4ed13412.png">

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

```bash
cf enable-diego ランタイム名
```

<img width="549" alt="Screen Shot 2016-12-28 at 14.38.02.png" src="https://qiita-image-store.s3.amazonaws.com/0/32083/1e18f61e-5a3f-fa22-9343-8e657e951f67.png">

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

```bash
$ cf diego-apps
```

<img width="582" alt="Screen Shot 2016-12-28 at 14.40.32.png" src="https://qiita-image-store.s3.amazonaws.com/0/32083/ab131a93-9ffe-d2c9-9c6d-a39ccc994f86.png">


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

```bash
$ cf start ランタイム名
```

<img width="823" alt="Screen Shot 2016-12-28 at 14.44.21.png" src="https://qiita-image-store.s3.amazonaws.com/0/32083/8ed0978f-fd71-3f83-801a-b1a20987f67a.png">

### 補足. Node-REDランタイムのDiego対応以前への戻し手順
Diegoに移行したランタイムは、以下のコマンドで移行以前の状態（DEAを使用）に戻すことができます。移行／戻しは何度でも実行できます。

```bash
$ 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

----