Cloud Penguins

Flying pengiuns in the cloud.

HUISリモコンとNode-REDを繋げるやつの仕組み

Node-RED Advent Calendar 2016の14日目!

以前、Node-RED UG勉強会 Vol.1 で発表したHUISとNode-REDの連携のやつですが、とある人から仕組みを教えてくれと言われてました。

・・・が、すっかり失念しておりました(すみません)

ということで、Advent Calendarにあわせてあれの仕組みを書いてみます。

先にHUISの話

ソニーのハイテクリモコン、HUISですが、発表の後も順調にアップデートされています。先月にはHUIS UI Creator ver 2.0、HUISソフトウェア ver 4.0が出ています。

http://huis.jp/

特にHUISソフトウェアは、10月に出たver 3.1から本体の動作速度が劇的に向上しており、かなり使い勝手が良くなりました。

赤外線連携部分

HUIS x Node-REDと書いてますが、正確には赤外線リモコンのデータをNode-REDで受け取って処理するという話なので、これから書く内容は普通のリモコンでも同じように利用できます。

赤外線受信

赤外線の受信には、BitTradeOneから出ているUSB接続 赤外線リモコンKITというのを使っています

公式に提供されているツールはWindows用なのですが、Linuxで利用できるコマンド btr_ir_cmd というものがGitHubで公開されているので、今回はそれを利用しました。

https://github.com/kjmkznr/bto_ir_cmd

このコマンドで受信も送信も可能なのですが、今回は受信のみを使います。

$ sudo bto_ir_cmd -r
Receive mode
  Received code: C1AA5A8F302081

赤外線を受信すると、このようにコードが表示されます。

Node-REDとの連携

bto_ir_cmdだと、待機中に表示される文字列が邪魔だったので、以下のようなシンプルなラッパーを書き、btoというコマンド名にしました。

#!/bin/bash
echo `bto_ir_cmd -r | grep code`

フローについては

  1. Node-REDのexec nodeを使ってbtoを実行(待ち受け状態になる)
  2. 信号を受信すると標準出力が得られるので、出力をパースしてコードを取り出し
  3. コードごとにswitch nodeで処理を分岐。分岐させたあとはお好きなように
  4. exec nodeをループさせて再度btoを待ち受け状態に

という流れでやっています。

Node-REDでbto_ir_cmdを叩くフロー

ハマったポイントとしては

  • exec nodeでは、"Use spawn() instead of exec()?“ にチェックを入れること(標準出力と、さらにReturn codeをloopに使うため)
  • bto_ir_cmdではExtendedモードを使わないこと
  • Extendedを使うと大幅にレスポンスが悪化し、実用に耐えなくなる

くらいでしょうか。フロー自体は非常にシンプルなので、Node-REDに慣れている方であればすぐに応用できると思います。

Gistにフローを貼っておいたので必要であれば参考にしてください。 https://gist.github.com/jacopen/72468a6176162e9a88f5cf5f654750b5

最後に

勉強会資料の最後にもちらっと書いてますが、HUISはBluetoothに対応しており、8月にはBluetooth対応のクレードルも出ました。

Bluetoothを使えば連携の幅をさらに広げることができるので、こちらのほうも試してみたいなーと考えてます。

k8sが導入するService Brokerの仕組みとは

Kubernetes Advent Calendarの9日目!

発端

数ヶ月前、こんな記事がありました。

Cloud Foundry’s Service Broker API Role in Kubernetes and Open Source Platforms

Kubernetesに、Cloud FoundryのService Brokerの仕組みを持ち込むという話です。

このService Broker、一体どういうものなんでしょうか。これを持ち込むことによって、どのようなメリットがk8sにもたらされるんでしょうか。今回は、Cloud Foundryを例に説明してみます。

あ、ちなみに。 Service Brokerと聞いてKubernetes勢は混乱しているかもしれません。Kubernetesにも"Service"の概念がありますからね。

Service BrokerのいうServiceとは、KubernetesのServiceを指すのではなく、MySQLやRabbitMQなどなどバックエンドサービスを指すと考えてください。

Service Brokerって何

Service Brokerを一言で表現すると、 Cloud Foundryと外部サービスを疎結合に結びつける仕組み となるでしょうか。

具体的に見ていきましょう。

以下はCloud FoundryでMySQLのDBを作成し、アプリケーションにバインドする際のコマンドです。ちなみにcfコマンドはCloud FoundryのCLIです。

cf create-service mysql free app1-mysql
cf bind-service app1 app1-mysql

Cloud Foundry内にapp1-mysqlという名前を付けたMySQLを立ち上げて、それとアプリを紐付けしている。そんなイメージが湧くのではないでしょうか。図にするとこんな感じ。

f:id:jaco-m:20170901162143p:plain

しかし、実際には違うのです。より実体に近い形で図を起こすとこうなります。

f:id:jaco-m:20170901162149p:plain

そう、cf create-serviceで作成されるものは、Cloud Foundryの中ではなく、外側にあるのです。このとき、Cloud Foundryと外部サービスの橋渡しをしているのが、Service Brokerです。

Service Brokerのフロー

Cloud FoundryがService Brokerと連携する際、Cloud Foundryがクライアント、Service Brokerがサーバーという位置づけになります。

Cloud Foundry FoundationによりService Broker APIというAPIが定められています。これを実装したものがService Brokerとなるわけです。

実際にCreate Serviceをした際のフローは以下のようになります。

f:id:jaco-m:20170901162152p:plain

Service BrokerはCloud Foundryからのリクエストを受け付けて返すだけ。クライアント/サーバー型の位置づけになっていることが分かるでしょうか。

次に、作成したサービスとアプリケーションを紐付ける作業、バインド時のフローです。

f:id:jaco-m:20170901162159p:plain

create時と同じく、CFからService Brokerにリクエストが飛んでいることが分かりますね。

Serviceをバインドすると何が起きるのか

アプリケーションとサービスをバインドすると聞くと、間にオーバーレイのネットワークが出来上がって直接通信して・・・みたいなことを想像してしまうかもしれませんが、残念ながらそこまではやってくれません。 サービスをバインドすると、そのサービスに関する情報が環境変数でアプリケーションに渡されます。基本、それだけです。

環境変数なんてデプロイするときに自分で設定出来るんだから、こんなの要らないじゃん

そう思う人もいるかもしれません。その考え方は間違ってはいません。 しかし、以下のようなケースの場合を考えてみましょう。

f:id:jaco-m:20170901162202p:plain

Microservicesが叫ばれる昨今、機能単位で細かくアプリケーションを分けるシーンも増えてきています。その場合、MQなどを用いてアプリケーション間でデータのやり取りを行う必要があるわけですが・・・

たとえばこの状態でMySQLやRabbitMQを作り直したり、プラン変更でエンドポイントを変更するとなるとどうでしょう。全てのアプリケーションの環境変数を変更する必要がありますね。

ただ、運用を考えると、同じ設定をあちこちに入れるのはあまり美しくありません。出来る限りDRYにいきたいものです。

MySQLやRabbitMQを、ひとつのリソースとして見立て、必要なアプリケーションからそれぞれリソースをバインドする。こういうモデルにすることで、何か変更が発生した場合も、リソース側だけを差し替えれば済みます。1アプリケーションだけ設定を間違えて問題がおきるといったこともありません。

12 Factor Appで示されるベストプラクティスの1つ、バックエンドサービスをアタッチされたリソースとして扱う が実現出来るわけですね。

k8sがService Brokerをどう取り入れていくのか

CFは優れたPaaSですが、その設計思想からしてもDBのようなステートフルなサービスを運用するには向いていないのです。Service BrokerはそのようなCFとその他のサービスを疎結合で結びつけることで、より柔軟な拡張性を持たせるための仕組みということですね。

Kubernetesは最近のアップデートを見る限り、ステートフルなアプリケーションも極力サポートしようという動きがみられます。しかしながら、「動かせる」ことと「動かしたいかどうか」は別に考える必要があります。 たとえば、メールサーバーを動かすのもやろうと思えば可能でしょうけど、メールサーバーの運用経験がある人であれば自分で運用したいとは二度と思わないでしょうし、ましてやKubernetesの上に載せたいなんて考えすらしないでしょう。

そうなると、やはり同じように外部サービスに投げることになるわけで、そこでService Brokerのような仕組みがあれば、より簡単にKubernetes上のアプリにバインドすることができるわけですね。

現在は、service-catalogという名前で実装が進みつつあるようです。

また、このService Broker開発にも関わるDeisのチームは、stewardと言う名前で何かを開発しているようですが、これがどう絡んでいるのかは深く追っていないので分かりません。

というわけで、今回の記事はこれでおしまい。

HUISソフトウェア3.1で使い勝手が別物になった

10/3に、HUISのソフトウェア バージョン3.1がリリースされました。 http://huis.jp/news/20161003/

変更点を見ると以下のように書かれています。

  • リモコン画面の切り替え方法を改善しました。従来の画面端からのスワイプによる切り替えに対して、画面上のどの位置からのスワイプでも画面を切り替えられるようになりました。
  • 画面切り替え速度が向上しました。
  • ボタンの応答速度が向上しました。
  • リモコン画面のヘッダーと現在位置表示のデザインが変更されました。

なるほど、確かに今まで画面の切り替えには一呼吸置くくらいの待ち時間が発生していたので、速度の向上は嬉しいですね。

しかし、リリースノートでは控えめの表現になっていますが、中の人曰く、今回のアップデートでは『劇的に』速くなっているそうで。

ということで、早速比較してみました。

こ、これは確かに速い!

スワイプによる画面切り替えは速度の問題で使いづらかったのですが、今回のアップデートで一気に実用になった感があります。さらに、これまで要求されたエッジからのスワイプが不要になり、より気楽に画面切り替えができるようになりましたね。これは嬉しい。

動画では表現出来ていませんが、ボタンの反応速度も速くなっています。

これ、マイナーアップデートじゃなくてメジャーアップデートでも良かったんじゃないでしょうか。っていうくらい、劇的に使い勝手が向上するので、HUISを持っている方はアップデート必須ですねー。

VMwareのHarborがすごくいいという話

社内勉強会で発表したのですが、最近発表されたVMwareのDocker Registry、 Harborがすごくいい感じです。

OSSで公開されており、気軽に試せます。 https://github.com/vmware/harbor

DockerとDocker Composeが入っている環境であれば、以下のようにやるだけで立ち上げられます。

$ cd Deploy

$ ./prepare
Generated configuration file: ./config/ui/env
Generated configuration file: ./config/ui/app.conf
Generated configuration file: ./config/registry/config.yml
Generated configuration file: ./config/db/env

$ docker-compose up -d

ボリュームマウントの都合上、Docker for macやDocker for windowsだとエラーが出ちゃうところは注意。Linuxであれば一発で動くはずです。

複数ユーザーでの利用やプロジェクト単位のロール管理、LDAP認証といった企業内で使うのに必要な仕組みが揃ってます。

Harbor間の同期もでき、正直Docker Trusted RegistryやQuay Enterprise使うよりもこっち使ったほうが幸せになれる気がします。

HUIS UI CREATORのMac版を作りました

更新履歴

2017/06/24 公式版についての注釈追加 2017/01/04 HUIS UI CREATOR for Mac ver 2.0 公開 2016/08/27 HUIS UI CREATOR for Mac ver 1.3 公開


SONYが出している、電子ペーパーを使ったハイテク学習リモコン、HUIS。

このHUISに、自分で好きにリモコン画面をデザインし、カスタマイズできるようにするのがHUIS UI CREATORです。

このエントリーを書いている段階ではまだ正式リリースされていませんが、実はこのHUIS UI CREATORGitHubでコードが公開されています。 https://github.com/sony/huis-ui-creator

SONYは今の所Windows版しか提供していませんが、アプリはクロスプラットフォームであるElectronを使って書かれているため、上手くやればMac版が作れるのではないか?と思い、いくらか手を加えてみたところ、予想通り動かすことができました。

というわけで、野良ビルド版としてMac版HUIS UI CREATORを公開します。

2017年3月に、同様の修正が取り込まれた公式Mac版が提供開始されました。今後は、この公式版を利用することを強く推奨します。 huis.jp


◆ ver 2.0 (2017/01/04)

◆ ver 1.3 (2016/08/27)

HUIS UI CREATORを利用する前に、HUISのファームウェアをアップデートする必要があります。

HUIS UI CREATORで遊んでみよう(準備編) を参考に、アップデートを行って下さい。

GitHubで公開されているコードを元に修正を加えた行った非公式版です。本ソフトウェアに関しての問い合わせをソニー株式会社に行うことはご遠慮ください。 動作についての問い合わせや不具合の報告は、 @jacopen までお願いします。

Flowを自動でgit commitする仕組みを作ってみた話

Node-RED Advent Calenadarの14日目! 遅くなってすみません。 今回は、Node-REDのフローを自動でgit管理する仕組みを作ってみた話です。

そう、Node-RED LT祭でデモしたアレです。結局記事に出来ていなかったので、今回の記事ネタにしてしまおうと思ってしまった次第。

きっかけ

Node-REDはGUIでガシガシFlowを作っていけるところがウリなのですが、過去のFlowに戻す方法がなくて困ったことが何度かありました。 ブラウザを閉じるまでは、Ctrl+zでUndoできるので、数手前までは戻すことができます。が、ブラウザを閉じてしまうともう戻せなくなってしまいますし、そうでなくてもだいぶ前のFlowの状態に戻すというのは、今のNode-REDでは難しいです。 いい手を思い付いたと思ってガシガシFlowを変更してみたはいいが、実は前のヤツのほうが良かった・・・という時に、何らかの方法で戻す方法が欲しい。

もちろん、手を加える前にJSONでexportしておけばよいのですが、ものぐさな自分にとってはちょっとそれが面倒くさい。

というわけで、試しに自動で変更をgit commitする仕組みを作ってみました。

しくみ

Node-REDのFlowは、userDirの下にJSONで保存されています。Node-RED上でDeployするたびに、このJSONファイルが更新される仕組みです。 であれば、このJSONファイルが更新される度にgit commitすれば、過去の変更をgitで管理できるのではないか、と。

そこで、今回はGruntを使って自動化することにしました。

GulpではなくGruntを使った理由は、Node-REDのpackage.jsonで元々Gruntが含まれている (Node-RED本体の開発用)からです。Gulpを使っても同様のことは可能だと思われます。

次に、JSONファイルのwatchにはgrunt-contrib-watchを利用。これもNode-REDのpackage.jsonに含まれています。 Gitの操作はgrunt-gitを利用。

userDirはデフォルトだとNode-REDのインストーディレクトリになりますが、今回はconfigディレクトリを作成し、その中にJSONが作られるように設定しました。

userDir: 'config'

Gruntfile

Gruntfileは、こんな感じになりました。 リポジトリの指定やファイル名の指定はもうちょっと上手いやり方があるような気がします。

せめて相対パスで書ければもう少しスッキリするはずなんですが、相対パスで書くと何故かgrunt-gitが意図したとおりに動作してくれないため、現時点では絶対パスで指定しています。

使い方

使い方は、Node-REDを起動した後、grunt watchコマンドを実行してJSONファイルのwatchをするだけです。

Node-RED上でFlowを編集し、Deployするとgrunt側ではこのような表示になります

>> File "config/king.json" changed.
Running "gitcommit:task" (gitcommit) task

Done, without errors.
Completed in 0.943s at Tue Dec 15 2015 21:13:51 GMT+0900 (JST) - Waiting...

git logしてみると、このようにコミットが積まれていることが分かります

$ git log
commit 310db8be68829a7f47937a5d5c6cfb41ecb5b5f2
Author: Kazuto Kusama 
Date:   Tue Dec 15 21:13:51 2015 +0900

    2015-12-15T21:13:51+09:00

developからmasterへのマージ

デフォルトでは、developブランチにコミットを積むようになっています。

$ git log --graph --decorate --pretty=oneline --abbrev-commit --all
* d90cf6e (HEAD, develop) 2015-12-15T21:18:05+09:00
* 310db8b (master) 2015-12-15T21:13:51+09:00

developブランチで開発をすすめ、良い感じになってきたらmasterにマージするという、よくあるフローも今回取り入れてみました。 今回作ったGruntfileでは、versionという名前のファイルもwatchしています。

このversionファイルが更新されると

  • versionファイルの数字を読み取り
  • developブランチをmasterブランチにmerge
  • versionファイル内の数字でtag付け

という作業を行います。 versionファイルの更新は、Node-RED上でInject Nodeを押すだけで行われるようにしました。

Node-RED___10_9_8_171

ボタンを押すと、以下のようになります。masterとdevelopが同じIDになり、v2タグが降られていることが分かります

$ git log --graph --decorate --pretty=oneline --abbrev-commit --all
* 4067c47 (HEAD, tag: v2, master, develop) 2015-12-15T21:22:51+09:00

Kubernetesベースに生まれ変わるDeis v2

Open PaaS Advent Calendar 2015 の1日目の記事です。

DeisはHerokuライクな使い勝手を実現したDocker PaaSです。

現在のDeisはCoreOSの上にDockerコンテナとして各コンポーネントが稼働する形になっています。

しかしDeis v2では、Kubernetesをベースとしたものに生まれ変わるようです。 Deis v2 Design Document #4582

KubernetesベースになるDeis

PDFでDesign Document が上がっているので、興味のある方は読んでみると良いかもしれません。

Kubernetesによって提供される概念(Service, Pod, ReplicationController, Namespaceなど)はそのまま残るようです。

それに加えて

  • S3/Swift互換のObject Storage機能を提供(RiakCSやMinioを使う)
  • Docker Registryを提供(保存先はObject Storage)
  • Buildpack, docker image, dockerfileによるデプロイ(Deis v1と同じ)
  • Deisクラスタのintegration testの仕組みを提供(Portunesという機能らしい)

などが目に付きますね。

また、これまでモノリシックなアーキテクチャだったコンポーネントを、より細かい単位に分割するようです。

OpenShift v3との違い

KubernetesベースのPaaSといえば、Red HatのOpenShift v3が思い浮かびます。

[slideshare id=46843273&doc=dockerpaaswithopenshift-150410013201-conversion-gate01]

それでは、このOpenShift v3とDeis v2の違いは何でしょう?

Design Documentを読む限りだと、一番大きな違いは「ユーザーの使い勝手」のように感じます。

Deis v2の使い勝手

Design Documentのp6には、buildpackを使った際のデプロイフローが記載されています。 これを読む限りだと、ユーザーは

git push deis master

するだけで、アプリがデプロイできるようです。これは、Deis v1の使い勝手と一緒です。

Dockerfileを使うときも、Dockerfileをgit pushすればデプロイされるようです。 Docker imageを使うときは、内部Docker registryにDocker pushしてからデプロイする形になるようですね。

いずれにせよ、使い方は大きく変わらないように見えます。

OpenShift v3の使い勝手

一方OpenShift v3はデプロイ方法がかなり特徴的です。Kubernetesと同じように、「どんな構成のアプリにするか」を記載したjsonやymlを作成し、それを専用CLIで指定するとデプロイされる・・・という仕組みです。

たとえば、GitHubにあるサンプルアプリだとこんな感じです

application-template-stibuild.json

・・・アプリケーションを構築する前に、このJSONファイルを作成する大きな仕事が必要になりそうですね。 一方、このJSONひとつで「どういうコンテナをどういう形でデプロイし、それらはどういう形で接続されるか」といった、アプリケーションを構築する要素すべてを定義することができます。

いつ出てくるの?

現在でも、Deis v1系の開発は進んでいます。これを執筆している時点でのバージョンは 1.12.1ですが、1.13, 1.14のリリースが予定されています。

Deis v2については、最初のalphaリリースが今年末に予定されているようです。