Node Ninja に挑戦 2

前回初めて利用してみた Node Ninja に挑戦の第２弾でござる。

今回はオリジナルの Node プログラムを Git リポジトリに準備してそれをデプロイすると共に、リポジトリ更新によるサーバ自動更新までの動きを確認してみる。

Node Ninja の特徴の１つとして WebSocket に対応している……とは公式サイトには全く書いていないが、Twitter で @node_ninja のニンジャがそう言っているので問題はないだろう。そこで今回は Socket.IO を使って、WebSocket を利用するシンプルなサーバプログラムを準備してデプロイすることにする。

Socket.IO サンプルプログラム

https://github.com/kumatch/sample-socketiopulse

今回の挑戦のために、上記リポジトリのようなつまらないサーバプログラムを準備した。
Socket.IO を使って断続的に通信が発生するため、そのままサーバを更新した際にどの程度ダウンするのかを確認することができる。

Node Ninja Machine へデプロイされるプログラムのルール

Machine 上で動作する Node サーバプログラムとして、現在のところいくつかのルールが設けられている。

• (おそらくトップレベルに) server.js というファイル名でエントリポイントを準備する
• config.json というファイル名で実行する Node バージョンを指定できる
• package.json が機能するので、デプロイ時にモジュールを指定してインストールできる

個人的には、package.json が機能するのだから、それに従って (モジュールとして) サーバが動作するようにできるのではないかと思う。

Git リポジトリを指定してのデプロイ

さて、実際の Machine へのデプロイは以下の簡単なステップで完了する。

以下の例は、前述の Github 上のリポジトリを対象に行ったもの。Git リポジトリ URLは git://github.com/kumatch/sample-socketiopulse.git (読み込み専用) になる。

1. Git Setup の Private タブで Add を押して、Git リポジトリURLを登録する
2. 登録したアプリケーションが Private アプリケーション一覧に表示されるので、Install を押す
3. Machine にデプロイが開始されて稼働開始

その上で、Git の Post-Receive Hooks を利用して、リポジトリが更新された (push された) 際にサーバを自動的を更新する仕組みが備わっている。

1. Git Setup の AutoSync タブで、Git リポジトリの URL を入力して Create
2. Post-Receive 用の専用 URL が発行される
3. (例えば Github 上で) Post-Receive Hooks の設定として、先ほど発行された URL を指定する

これでデプロイ元となるリポジトリへ push すれば、Node サーバアプリケーションは自動更新される。

Git リポジトリ側の Post-Receive Hook がどのタイミングで行われるかにもよるが、push 直後に再デプロイが始まり、ほんのわずかなダウンタイムの後に新しいプログラムで稼働したことを確認できた。

デプロイした Machine の URL はこちら。

http://kumapulse.node-ninja.com/

アクセス後、Chrome/Safari の開発ツール、ないし Firefox の Firebug のコンソール上で断続的に通信されているのが確認できる。IE は知らないが F12 を押そう。

どうやら現在のところ立ち上げることができる Machine は１つのアカウントで１つまでのようで、上記 URL を機能させ続けるならば、もう別の Node アプリケーションをデプロイすることができない。恐らく、後ほど上記 URL の Machine は停止させて頂くことになるだろう。

Node Ninja に挑戦

この前の Node 勉強会で Node PaaS である Node Ninja (https://node-ninja.com/) のアカウントを頂いたにも関わらずさっぱり利用していなかったものの、それはさすがに勿体ないし、可能であればレポートを書いてねとも言われていたので、このたび挑戦してみることに。

実は PaaS 自体はこの Node Ninja が初体験。

稼働までの準備等は Web ブラウザによる設定コンソールにて行っていく。

Machine の作成

アプリケーションを稼働させるために、最初は Machine を準備する。正式サービスが展開されればおそらく性能を選択するようなことになるだろうけども、現在は固定になっている。今は指定項目としては Machine につける名前のみ。ここでは「kumasrv」とつけた。これで Machine の準備は完了。

アプリケーションのデプロイ

この作成した Machine に Node アプリケーションを設定する。現在のところ以下の４つの方法がある。

1. オフィシャルに提供されるアプリケーションから選択してインストールする。

現在はサンプルアプリケーションが準備されているが、今後は Node の有益なアプリケーションがボタン１つでデプロイできて Ready になるのだろうと予想できる。

2. 利用者による Shared アプリケーションから選択してインストールする。

オフィシャルではないものの、他のユーザによって提供されるアプリケーションパッケージの位置づけ。

3. プライベートアプリケーション。選択ではなく、自身で Git リポジトリを指定してでデプロイする。また、ここで追加したアプリケーションを Shared 化することができる（最初はちょっとわからなかった）

4. AutoSync。Git リポジトリから展開した上で、そのリポジトリが更新されると自動的に git pull してくれる。逆にいえば、これまでの３つの方法ではデプロイ後は基本的に「そのまま」となる。ただし、先に設定した SSH key で Machine に接続して、コンソール上でコードを変更したりサーバの起動をしなおしたりといったことは可能。

オフィシャルアプリケーションをデプロイ

今回は、オフィシャルなアプリケーションを展開してみる。hello-http という、おそらく hello world なアプリケーションがあったので、それを選択。Logs 画面に遷移した後、Machine が準備される様子（ログ）が追加されていく！

完了後、kumasrv.node-ninja.com へブラウザで繋いでみる。あれ、繋がらない。どういうことなの、ってことで Machine に SSH で接続する。プロセスを確認すると、Nodeプロセスは存在するものの httpd のようなものは存在していない。

そういうものなのかなーニンともカンともとか言いつつ、実行プログラムの中身を覗いてコードを確認。8080 番で動いていることがわかったので、 kumasrv.node-ninja.com:8080 で接続。無事「Hello World」が表示される。

その後アプリケーション選択ページを見てみると、説明文に「ポート 8080 でHTTPのリクエストを待ち受け」ってちゃんと書いていた。てめえがニンともカンともだった。

別のオフィシャルアプリケーション (express + giraffi) も試す。こちらは普通に80でアクセスすることができた。こちらもコンソールからソースコードを覗くと、たしかにそのまま 80 番で待ち受けるよう記述されていた。ユーザにはそういう権限がある模様。

Machine Logs ページ上ではこのアプリケーションのデモとして、アプリログの様子が記録されているのが分かる。どうやらこれがカラクリの中身らしい。

https://github.com/node-ninja/ninja-giraffi

その他雑多なところ

• Machine 上には mongodb が動いている。情報はないがデモでは普通に使っているし CLI でも接続可能。

• 作成した Machine を削除して再度別名で作成した際、同じ IP が割当てられたにも関わらず名前割当ては古いままだった。切り替わるのに結構な時間を要したのでこの辺はまだまだ調整が必要そう。

今度は自前アプリケーションのデプロイに挑戦する予定。