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

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

タグ:nodejs

まだ同期/非同期処理の違いに戸惑いながら Node.js を使っています。で、先日こんな実行時エラーに遭遇しました:
  :
  :
events.js:141 throw er; // Unhandled 'error' event ^ Error: EMFILE: too many open files, open '/home/kkimura/XXX/images/*****.jpg` at Error (native)

その時のコード(抜粋)がこちらです:
var fs = require( 'fs' );
fs.readdir( './images', function( err, files ){  // ./images/ フォルダを開く
  if( err ) throw err;
  
  files.forEach( function( jpgfile ){  // ./images/ フォルダの全ファイルを1つずつ取り出して、、、
          :
    (各ファイルに対する処理)
          :
  });
});

現在のディレクトリから、fs モジュールを使って images/ サブフォルダの中にある画像ファイル全てを取り出して、各ファイルに対して何らかの処理をする・・・という、よくあるとまで言えるかどうかはわかりませんが、ごく普通の内容だと思います。この処理中に上記のエラーが発生しました。エラーそのものもネイティブコードの中で発生しているので、どの画像ファイルを読み込んでいる時のエラーかはわかるのですが、何が原因のエラーなのかのヒントはほとんどありませんでした(結論としては画像ファイル側の問題ではないので、どの画像ファイルであったかは解決の上ではあまり重要な情報ではありませんでした)。

が、エラーメッセージそのものから原因はなんとなく推測できました。

まず、この処理は特定のフォルダ(./images)の中にある全てのファイルを取り出し、forEach() ループで各ファイル毎になんらかの処理をする、というものです。そしてエラーメッセージは "Too many open files(ファイルを開きすぎている)"。 実際、このフォルダ内には非常に多くのファイルが存在していたのですが、それらを同時に開きすぎて、処理の限界を超えてしまった、というエラーが発生していたようです。

というわけで原因はなんとなくわかりました。しかし本当の問題はここから。


Node.js(JavaScript) は非同期に処理を実行します。つまり上記のようなケースでは「ファイルを1つずつ開いて処理をして、終わったら閉じて次へ」ではなく、「同時に(非同期に)全ファイルを開いて、同時に(非同期に)全ファイルに処理を施して・・・」という形で実行されます。そしてその際に多くのファイルを開きすぎて "Too many open files" というエラーが発生していたのでした。このエラーは多くのファイルが保管されているディレクトリへの処理を非同期に実行する以上は解決しにくい問題のように思えますが、さてどうする・・・


これ、自分以外でも悩んでいる人が多かったらしく、StackOverflow などでも議論(後述)されていました。結果的には fs ライブラリそのものを改良したものを使う、という方法が紹介されていました。その改良モジュール(graceful-fs)はこちら:
https://github.com/isaacs/node-graceful-fs

この graceful-fs は fs の代わりに使うことができ、かつ "Too many open files" エラー時に発生する EMFILE イベントを検知したら、少し待ってからやり直し処理を行う(という方法でエラーを回避しながら全ファイルを処理する)、という処理が実装されたもののようです。

graceful-fs モジュールを使うには、まず npm 等でインストールを行います:
$ npm install graceful-fs

そしてコードを書き換えます。といっても require( 'fs' ) を require( 'graceful-fs' ) にするだけで、他は変更なしでそのままエラーもなく動きました:
var fs = require( 'graceful-fs' );
fs.readdir( './images', function( err, files ){
  if( err ) throw err;
  
  files.forEach( function( jpgfile ){
          :
    (jpgfile に対する処理)
          :
  });
});


それにしても同期/非同期処理の頭を素早く切り替え出来るのって、それだけで才能ではないかと思う。。。


(参考)
http://stackoverflow.com/questions/8965606/node-and-error-emfile-too-many-open-files

2016 年の年初に「マンホライザー」というサービスを作って動かしていました:
http://dotnsf.blog.jp/archives/1048853473.html

マンホライザーはわかりやすく言うと「マンホール顔ハメ画像作成サービス」です(わかりやすいか??)。先日のマンホールサミット 2017 埼玉に参加した際にも、こんなアナログな顔ハメ写真サービスを提供させていただいたのですが、意外と人気があったのでした。それをウェブ上からもできるようにしよう、というわけで生まれたサービスでした。IBM Watson の画像認識機能を使って実装しており、「テクノロジーの無駄使い」な点も自己採点ポイントが高いものになっています(笑):
2017020701


上記リンク先の、2016 年に公開した当初は PHP で実装していました。その時のソースコードはこちらです:
https://github.com/dotnsf/Manholizer


このコードはこれはこれで現在も動く(注 Visual Recognition API の古いものを使っているので、顔ハメはうまく動きません)ものですが、いくつかの課題もありました。その1つが「スマホからの利用を想定していなかった」という致命的な点です。見た目でのスマホのウェブブラウザ最適化という意味では実現したつもりでしたが、想定外だったのは「スマホのカメラで撮影した画像の解像度が予想以上に高かった&今後は更に高くなることが想定される」ということです。

ある程度詳しい人には常識かもしれませんが、iPhone をはじめとする最近のスマートフォンのカメラはかなり高い解像度の写真を撮影することができます(特に設定を変更しない場合は、高解像度撮影が標準機能になっていることが多いです)。撮影した写真を低解像度にしてメールで送る、といったことは可能ですが、内部的には高解像度のまま保存されていることになります。これは1枚の写真画像のファイルサイズが非常に大きいということを意味しています。これは2つの点で問題になります。

1つはアプリケーションサーバー側の制約を受ける可能性があるという点です。例えば PHP を普通にインストールしたアプリケーションサーバーの場合、アップロードサイズは 2MB に設定されることが多いです。もちろんこの設定を変更できればいい話ですが、最近は PaaS などでミドルウェア設定を変更できないケースもあるので、そうなるとこの制約を受けてしまいます。

もう1つは API 側の仕様上の制約を受ける可能性です。このマンホライザーでは画像から顔の位置を認識・特定する必要があるのですが、その部分に IBM Watson の Visual Recognition API を使っています。この API の制約として現在は「画像は 2MB まで」という制約があるのでした。つまり上記のアプリケーションサーバー側の制約を取り除いただけでは解決にならないことも出てきてしまうのです。

上記で紹介した、以前作った PHP 版のマンホライザーにはこれら2つの課題があり、スマホからの利用を想定すると期待通りに動かないケースが出てきてしまいました。というわけで、ミドルウェアや設計段階から見直したマンホライザーを作り直すことにしたのでした。


上記2点を解決するため、まず PHP のアップロードファイルサイズ制約をうけないよう、アプリケーションサーバーは Node.js を使うことにしました。PHP から Node.js への移植を行いました。これによって 2MB を超える画像もアップロードできるようにしました。

また API 側のサイズ制約については、アップロードした画像を一旦内部的にリサイズし、API が実行できるレベルにまでサイズを減らしてから実行する、というロジックに変更することで対処しました。細かい点ですが、画像を小さくしてから実行するため、API からのレスポンスは「小さくなった画像に対する顔の位置」になります。アプリケーション側ではアップロードした画像のプレビューが表示されており、その画像にマンホールの位置とサイズを調整して「ハメる」わけですが、元の画像サイズに対するレスポンスにはなっていないので、その辺りも考慮する必要が生じます。

そんなこんなの変更を加えてできあがったのがこちらです:
https://manholizer.mybluemix.net/

2017020701

↑ちとズレてるが・・・


使い方は PC またはスマホのウェブブラウザでアプリケーションサーバー(https://manholizer.mybluemix.net/ とか)にアクセスしてください。で、「参照」ボタンをクリック:
2017020702

 

手元のローカルファイルシステムまたはフォトライブラリ等から画像ファイルを選択します。今回は「フリー素材アイドル」の Mika x Rika さんの画像を使わせていただきました:
顔4


この画像を指定して、しばらく待つと・・・
2017020703


こんな感じになりました:
2017020704


合成用マンホールのデザインとして使っているのは(マンホーラーであればおなじみの)東京都マンホールです:
2017020706


(2つの)顔の位置を識別し、うまく顔ハメになるようマンホールの位置と大きさが調整されて合成されています。またマンホールの色がピンクなのは「女性」であると認識されている様子です(男性の場合は青いマンホール画像を合成します)。また2人の上部に "-17" と表示されていますが、これは推定年齢でふたりとも「17才以下」であると推測されている、ということを意味しています(お二人の年齢は存じ上げませんが、全体的に日本人の顔は若く判定される傾向があるようです):
2017020705



なお、このサービスのソースコードはこちらで公開しています。興味ある方はご自身の環境でもどうぞ:
https://github.com/dotnsf/manholizerDemo


自分の環境に導入して使いたい場合の方法は README.md にも記述していますが、IBM Bluemix の Node.js ランタイムで使う場合であれば、まず Bluemix にログインして、SDK for Node.js ランタイムを1つ作成します(この時の名前を後で使います)。また Visual Recognition サービスインスタンスを生成し、その API KEY を取得しておきます(この値も後で使います)。

次に上記サイトからソースコードをダウンロード&展開するか git clone して、以下の2ファイルを編集します。

1つ目は settings.js です。この中の exports.vr_apikey の値に、上記で取得した自分の Watson Visual Recognition サービスの API Key の値を設定します(以下は API Key が abcdabcdabcdabcdabcdabcd であった場合の例です):
(settings.js)

: exports.vr_apykey = 'abcdabcdabcdabcdabcdabcd'; :

もう1つは manifest.yml です。この中を実際に運用するランタイムの情報に設定します。例えば eu-gb リージョンを使って、my_manholizer という名前のランタイムで運用する場合は以下のようになります(ng リージョンの場合、domain は変更せずにそのままで構いません):
(manifest.yml)

: domain: eu-gb.mybluemix.net name: my_manholizer host: my_manholizer :

この状態で cf コマンドを使ってアプリケーションを push すると、作成した Node.js ランタイム上にマンホライザーがデプロイされます:
$ cf push

IBM Bluemix を使わずに運用する場合は・・・ まあ普通に Node.js をインストールして npm install して使ってください(適当)。


IBM Watson の画像認識 API である Visual Recognition を使った類似画像検索サービスを作り、そのソースコードを公開しました:
https://github.com/dotnsf/imageSearchDemo


コードは Node.js で作りました。プロジェクト自体に(著作権フリーな)サンプル画像もいくつか含まれていますが、サンプル画像を置き換えて使うことでご自身が所有している画像を使った類似画像検索サービスにすることも可能です。

また基本的に Watson API は使いやすいものばかりだと思ってますが、このサンプルアプリもその特徴を最大限に活かして、単純に「学習させたい画像を用意すれば動く」ようにしました。細かな実装内容はソースコードを参照ください。


上記 github 上のリポジトリの README.md の中に使い方も(英語で)記載していますが、このブログでは日本語での簡単な使い方とカスタマイズについて紹介します。前提としてログインできる CentOS/RHEL のインスタンスに git と Node.js がインストールされている環境をご用意ください。また最終的なウェブアプリケーションは IBM Bluemix 上で動かすことにします(この場合は cf コマンドもインストールしておいてください)。異なるプラットフォームでも動くと思いますが、適宜読み替えてください。


準備

何はともあれ、IBM Watson の API を利用するためには IBM Bluemix のアカウントが必要です。まだアカウントをお持ちでない場合はトップページの「フリーアカウントを作成」ボタンから 30 日間無料で使えるトライアルアカウントを作成できます:
2017012601


Bluemix のアカウントでログインし、カタログ内 "Watson" カテゴリの "Visual Recognition" を選択して、この API を追加してください:
2017012602


なお作成時に "Free" プランを選択すると1日に 250 API call まで無料で利用できるプランになります。本格的に利用する場合はその下の "Standard" プランを検討ください:
2017012603


Visual Recognition API を作成後に、ダッシュボードから作成した同サービスを選択して、サービス資格情報から資格情報を確認します(なければ追加します)。そして "api_key" の値(下図ではモザイクにしています)がこの後必要になるのでメモしておきます:
2017012604


改めて github からソースコードを用意します。いくつかの方法がありますが、git が使える場合は git clone してください(または zip をダウンロードして展開してください):
$ git clone https://github.com/dotnsf/imageSearchDemo
$ cd imageSearchDemo

ソースコードを展開したディレクトリの直下に settings.js というファイルがあります。この中の exports.vr_apikey の値を先程メモした Visual Recognition API の API Key の値に書き換えて保存してください:
2017012605


他はそのままでも動きます。なお、exports.limit の値(デフォルトだと 5)はウェブアプリケーションで類似画像を検索した結果として、上位いくつまでの結果を表示対象とするかの数値です。学習させる画像の数などにもよりますが、必要に応じて書き換えて使ってください。

最後に、この後の学習時に必要な Node.js のミドルウェア: watson-developer-cloud を npm でインストールしておきます:
$ npm install watson-developer-cloud

この結果、プロジェクトのホームディレクトリ(imageSearchDemo)に node_modules というフォルダが作られていれば watson-developer-cloud の導入に成功したことになり、学習処理が行えるようになります。


画像の学習

最終的には類似画像を検索する仕組みを作りますが、そのためにはあらかじめ検索結果となる画像を学習させておく必要があります(学習させた画像の中から類似画像を探します)。そして学習のためにはある程度の枚数の画像が必要です。

上記ソースコードの public/images/ の中にはサンプルとして著作権フリーな画像が含まれています。これらをそのまま使って学習させることもできますし、手元にある画像で類似画像検索システムを作りたい場合はそれらを使うこともできます(その場合は public/images/ 以下のサンプル画像を全て削除した上で、ご自身の画像をこのフォルダ内に格納してください):
2017012606


そして、以下のコマンドを実行すると public/images/ フォルダ以下にある画像を Watson に学習させます(上記の settings.js ファイルの編集を忘れずに行っておいてください):
$ node learnImages.js
imagelearn_xxxxxx

学習が正しく行われた結果、画面には imagelearn_xxxxxx という文字列が表示されます。これが collection_id と呼ばれるもので、後述の Watson API Explorer などでこの API を実行する際には必要になります。またこのコマンドの実行後に setting.js の最終行に以下のような1行が追加されているはずです:
exports.vr_collection_id = 'imagelearn_xxxxxx';


ウェブアプリケーションとして利用

では学習した内容を使った類似画像検索ウェブアプリケーションを作成します。今回は IBM Bluemix 上のランタイムとして作成するので、SDK for Node.js ランタイムを1インスタンス作成します:
2017012607


アプリケーション名は適当にユニークなものを指定します。この例では dotnsf-imagesearch という名前のランタイムを作っています:
2017012608



合わせてソースコードの manifest.yml ファイルを更新します。具体的には name と host 両方の値を、実際に作成するアプリケーション名と同じものにします:
2017012609


ここまで準備できたらアプリケーションをデプロイします。cf コマンドを使ってログインし、プッシュします:
$ cf login -a http://api.ng.bluemix.net/
   :
   :

$ cf push

しばらくするとアプリケーションの転送とステージングが完了して、ランタイムが起動した旨のメッセージが表示されます:
2017012601


この段階でアプリケーションにアクセス可能です。PCかスマホのブラウザでアプリケーションの URL (上記の例だと http://dotnsf-imagesearch.mybluemix.net/)を指定して開くと、このような画面が表示されます:
2017012601


「参照」ボタンをクリックして、類似画像の対象となる画像を選択します。今回は学習データの中に野球ボールがあったので、それが検索できるかどうかを調べる目的で、学習データとは異なる野球ボール画像を指定してみることにします:
野球ボール


画像を指定すると画面が暗転して、類似画像検索が行われます:
2017012602


しばらくすると結果が得られて画面の暗転が戻ります。画面を下にスクロールすると学習データの中の類似画像候補が指定数(デフォルトでは5)表示されます。一番左に野球ボールが検索できているのがわかります。まあこんな感じのウェブアプリケーションサンプルです:
2017012603


画像を学習する部分は learnImages.js で実装しています。学習時に与えるメタデータ(画像検索の結果と一緒に取得できるテキスト情報)の内容を変更する場合はこのファイルをカスタマイズしてください。またウェブアプリケーション部分は app.js で、そしてウェブアプリケーションの見栄え部分は public/ フォルダ内の index.html に依存しています。見栄えを含めたウェブアプリケーションの挙動の変更はこれらのファイルを自由にカスタマイズしてお使いください(ソースコードは MIT ライセンスで配布しています)。



なお、API Key や collection_id を利用して実際に Visual Recognition API を実行する場合は、こちらの Watson API Explorer をお使いいただくのが便利です。仮に作成した collection_id を一度削除するような場合はこの画面から DELETE を実行いただくことができます:
https://watson-api-explorer.mybluemix.net/apis/visual-recognition-v3

また、Watson Visual Recognition API の関数リファレンスはこちらを参照ください:
https://www.ibm.com/watson/developercloud/visual-recognition/api/v3/



IBM Bluemix からも提供しているビジュアルフローエディタ Node-RED の最新バージョン v0.16 がリリースされました(2017/Jan/17 時点での最新版は v0.16.1):
https://libraries.io/npm/node-red/


新機能などの情報についてはこちらの公式ブログエントリや、
http://nodered.org/blog/2017/01/11/version-0-16-released

こちらのリリースノートを参照ください:
https://github.com/node-red/node-red/releases/tag/0.16.0


さて、上記ブログエントリにも書かれているのですが、この v0.16 より Node.js の v0.10 および v0.12 がサポート外になりました。Node.js も v4 以上のものを用意する必要があります。

これで問題になるのが CentOS/RHEL 6.x を使っている場合です。現在、CentOS/RHEL 6.x で(epel リポジトリなどを使って)普通に Node.js を導入すると v0.10.48 が導入されます:
# node -v
v0.10.48

IBM からも IBM SDK for Node.js として IBM 版の Node.js がリリースされていますが、こちらも CentOS/RHEL 6.x は v0.12 までしか用意されておらず、Node.js v4 以上を使おうとすると CentOS/RHEL であれば 7.x を使う必要があります:
https://developer.ibm.com/node/sdk/

2017011702


ちなみに Node.js v0.10.x が導入された状況下で深く考えずに npm を使って Node-RED を導入すると、最新バージョン(今であれば v0.16.1)が導入されてしまいます。その結果起動時にエラーが発生し、ユーザー画面にもエラーメッセージが表示されてしまいます:
# npm install node-red -g  (このコマンドは成功する)

# node-red
  :
  :
Welcome to Node-RED
===================

17 Jan 10:10:33 - [info] Node-RED version: v0.16.1
17 Jan 10:10:33 - [info] Node.js  version: v0.10.48
17 Jan 10:10:33 - [error] *****************************************************************
17 Jan 10:10:33 - [error] * Unsupported version of Node.js. Requires: >=4 Found: v0.10.48 *
17 Jan 10:10:33 - [error] *****************************************************************
17 Jan 10:10:33 - [info] Linux 2.6.32-642.11.1.el6.x86_64 x64 LE
17 Jan 10:10:33 - [info] Loading palette nodes

/usr/lib/node_modules/node-red/node_modules/mqtt/lib/connect/index.js:100
    const isSecure = ['mqtts', 'wss'].indexOf(opts.protocol) !== -1
    ^^^^^
17 Jan 10:10:35 - [warn] ------------------------------------------------------
17 Jan 10:10:35 - [warn] [rpi-gpio] Info : Ignoring Raspberry Pi specific node
17 Jan 10:10:35 - [warn] [mqtt] SyntaxError: Use of const in strict mode.
17 Jan 10:10:35 - [warn] ------------------------------------------------------
17 Jan 10:10:35 - [info] Settings file  : /root/.node-red/settings.js
17 Jan 10:10:35 - [info] User directory : /root/.node-red
17 Jan 10:10:35 - [info] Flows file     : /root/.node-red/flows_xxxxxxxx.xxxxx.xxx.json
17 Jan 10:10:35 - [info] Creating new flow file
17 Jan 10:10:35 - [info] Server now running at http://127.0.0.1:1880/
17 Jan 10:10:35 - [info] Starting flows
17 Jan 10:10:35 - [info] Started flows

↑起動が成功したように見えるが、バージョン非互換のエラーが発生している

2017011701


では改めて CentOS/RHEL 6.x のバージョンアップをせずにどうやって Node-RED を導入すればよいでしょうか? Node-RED の最新版を動かすために工夫する、というのも1つの方法ですが、Node-RED が最新版でなくてもよい場合であれば Node-RED v0.14.x を使う、という方法もあります。このバージョンであれば CentOS/RHEL 6.x でも動作します。

その場合の手順を紹介します。まず上記のコマンドを実行してしまって Node-RED v0.16.x を導入してしまった場合はアンインストールします:
# npm uninstall node-red -g

リリースサイトを見ると、v0.14.x の最新バージョンは v0.14.6 のようです(2017/Jan/17 時点)。というわけで、改めてこのバージョンを指定して npm でインストールします:
# npm install node-red@0.14.6 -g

こうしてインストールした Node-RED を起動すればエラーは発生しません:
# node-red
  :
  :
Welcome to Node-RED
===================

17 Jan 10:15:55 - [info] Node-RED version: v0.14.6
17 Jan 10:15:55 - [info] Node.js  version: v0.10.48
17 Jan 10:15:55 - [info] Linux 2.6.32-642.11.1.el6.x86_64 x64 LE
17 Jan 10:15:55 - [info] Loading palette nodes
17 Jan 10:15:58 - [warn] ------------------------------------------------------
17 Jan 10:15:58 - [warn] [rpi-gpio] Info : Ignoring Raspberry Pi specific node
17 Jan 10:15:58 - [warn] ------------------------------------------------------
17 Jan 10:15:58 - [warn] Missing node modules:
17 Jan 10:15:58 - [warn]  - node-red: yaml
17 Jan 10:15:58 - [info] Removing modules from config
17 Jan 10:15:58 - [info] Settings file  : /root/.node-red/settings.js
17 Jan 10:15:58 - [info] User directory : /root/.node-red
17 Jan 10:15:58 - [info] Flows file     : /root/.node-red/flows_xxxxxxxx.xxxxx.xxx.json
17 Jan 10:15:58 - [info] Creating new flow file
17 Jan 10:15:58 - [info] Starting flows
17 Jan 10:15:58 - [info] Started flows
17 Jan 10:15:58 - [info] Server now running at http://127.0.0.1:1880/

↑起動成功

というわけで、現時点で比較的簡単に CentOS/RHEL 6.x で Node-RED を動かす場合はこの方法になるのかな、と思ってます:
2017011703


なお、CentOS/RHEL 6.x に Node.js v4.x を導入してから Node-RED v0.16.x を入れる、という方法もあります。CentOS/RHEL 6.x に Node.js v4.x を入れる方法についてはこちらに詳しく書かれていました:
CentOS 6.xにLTS(4.3.0)のnode.jsをインストールする

メインフレーム(IBM z Systems)上で動く Linux である IBM LinuxONE の上で Node.js を動かすことに挑戦してみます。環境は IBM LinuxONE のクラウドサービスである IBM LinuxONE コミュニティクラウドの、RHEL 6.x のサーバーインスタンスを使うことにします。

なお IBM LinuxONE コミュニティクラウド上に RHEL 6.x サーバー環境を構築する手順についてはこちらを参照ください:
IBM LinuxONE コミュニティクラウドを使う(2017年1月版)


まず、そもそも LinuxONE 上に Node.js をインストールできるのか!? という問題があります。yum のリポジトリが用意されているわけではないし、ソースからビルドするのもライブラリが充分ではなかったりします。さて、どうするか・・・

実は Node.js に関しては IBM SDK for Node.js という形で、IBM から多くのプラットフォーム向けインストーラーバイナリが提供されています。LinuxONE もその対象プラットフォームの中の1つなのでした:
https://developer.ibm.com/node/sdk/


上記サイトからは x86 の Linux や Windows, Mac OS だけでなく、 AIX や Power Linux、そして LinuxONE 環境で動く Node.js の各バージョンがバイナリの形で提供されています。

実際には全てのバージョンが全ての環境で動作するわけではありません。例えば Node.js V6 の場合は以下のプラットフォームで動くものが提供されています。LinuxONE(IBM 64-bit z Systems) の RHEL の場合、7.x だけが動作環境に指定されています(他に SLES 12 と Ubuntu 16.04 で動きます。RHEL 6.x ではライブラリが足りないので動かないようです):
2017011601



逆に LinuxONE の RHEL 6.x で動く最も上位のバージョンを探してみると・・・ Node.js V1.2 であれば動きそうでした:
2017011602


というわけで、以下のサイトから LinuxONE(Linux on System z 64-bit) 向けの IBM SDK for Node.js V1.2 の最新版モジュールをダウンロードします。私がダウンロードした時点では ibm-1.2.0.17-node-v0.12.18-linux-s390x.bin というファイルがダウンロードできました。以下このファイルをダウンロードした前提で説明しますが、バージョンが異なっている場合は適宜読み替えてください:
https://developer.ibm.com/node/sdk/#v12

2017011603


ダウンロードしたファイルに管理者権限で実行権限を与え、実行します:
# chmod +x ibm-1.2.0.17-node-v0.12.18-linux-s390x.bin
# ./ibm-1.2.0.17-node-v0.12.18-linux-s390x.bin

後は画面の指示に従ってインストールするだけ。指定箇所があるとすればインストール先フォルダですが、私は /data/ibm/node というディレクトリを指定しました。

インストールが完了したら実行します。まずは IBM SDK for Node.js のバージョンを確認してみましょう:
# cd /data/ibm/node/bin
# ./node -v
v0.12.18

上記のように "v0.12.18" というバージョン名が表示されればインストール成功です! 後は /etc/bashrc などでパスを通しておけば、コマンドプロンプトから便利に使うことができるようになります:
# vi /etc/bashrc

    :
(以下の3行を最後に追加)
    :
# node.js
export NODEJS_HOME=/data/ibm/node
export PATH=$PATH:$NODEJS_HOME/bin

なお、npm(node package manager) コマンドも node と同じディレクトリに入っているので同様に使えるようになります。




このページのトップヘ