先日開催された MasterCloud #4 で、Cloud Foundryについてお話してきました。
発表資料はこちら
Dockerは便利だけど、自分でイメージの管理するとなると結構手間かかったりするんですよね。 自前でコンテナイメージの作成や管理できるのは便利なケースもある一方、手間ばかりかかって開発速度が落ちるというケースもしばしば。じゃあどうすれば?というときに、Cloud Foundryという選択肢も考えてみてはいかがでしょう という発表内容でした。
先日開催された MasterCloud #4 で、Cloud Foundryについてお話してきました。
発表資料はこちら
Dockerは便利だけど、自分でイメージの管理するとなると結構手間かかったりするんですよね。 自前でコンテナイメージの作成や管理できるのは便利なケースもある一方、手間ばかりかかって開発速度が落ちるというケースもしばしば。じゃあどうすれば?というときに、Cloud Foundryという選択肢も考えてみてはいかがでしょう という発表内容でした。
OpenStackDaysのテクニカルセッションで話したスライドです。
個人的にCFで一番好きな機能がServiceBrokerなんですが、この仕様がCF特化ではなくてより汎用的になって、k8sをはじめとした他のプラットフォームからでも利用可能になるのが、このOpenServiceBroker。
CFの強みのひとつを外だししちゃっていいの?という気持ちはあるけれど、これでエコシステムが拡大するならばそれはそれでありなのかな。
これまでWordPressやGhostなどでBlogを書いていたけれど、そろそろ自前blogも面倒に感じてきた。
実際いちど、消してはいけないVPSアカウントを消してしまい、それまでのブログデータもろとも吹っ飛ばす事故やらかしてからは、もう自前でないほうがいいんじゃないかと。
データ吹っ飛ばす事件以降、blog書く気力も無くしていたので、この際引っ越してそっちで心機一転やろうかなと。
ということで、はてなブログに引っ越してPro契約。独自ドメインは過去のblogのものを引っ越し。 Ghostで書いていたデータはインポート出来なかったんだけど、たいした記事数もなかったんでひとつひとつコピペして引っ越し。markdownでかけるので単純にコピペするだけでよかった。
ということで、今後週1回くらいはかけるようにしたいなー。
あとデザインもちょっといじらないと。デフォルトだとあんまり好みじゃない。
先日書いたこの記事
ですが、Open Service Broker APIとしてサイトが出来ていました。
Open Service Broker APIのspecはこのドキュメントにまとめられていくようですが、現時点ではCloud FoundryのService Broker APIそのものになっていますね。
CF Service Broker APIは、Cloud Foundryにしかないorganization_id
やspace_id
といったパラメータが必須項目になっており、このままではk8sやOpenShiftで利用するのは難しいでしょう。
今後このあたりのCF特化の項目が取り払われていき、より汎用的なAPIになってくのかなと考えられます。
議論はSlackやGoogleGroups/MLで進められていくようなので、興味のある方は参加してみてはいかがでしょうか。
Node-RED Advent Calendar 2016の14日目!
以前、Node-RED UG勉強会 Vol.1 で発表したHUISとNode-REDの連携のやつですが、とある人から仕組みを教えてくれと言われてました。
・・・が、すっかり失念しておりました(すみません)
ということで、Advent Calendarにあわせてあれの仕組みを書いてみます。
ソニーのハイテクリモコン、HUISですが、発表の後も順調にアップデートされています。先月にはHUIS UI Creator ver 2.0、HUISソフトウェア ver 4.0が出ています。
特に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
赤外線を受信すると、このようにコードが表示されます。
bto_ir_cmdだと、待機中に表示される文字列が邪魔だったので、以下のようなシンプルなラッパーを書き、btoというコマンド名にしました。
#!/bin/bash echo `bto_ir_cmd -r | grep code`
フローについては
bto
を実行(待ち受け状態になる)bto
を待ち受け状態にという流れでやっています。
ハマったポイントとしては
bto_ir_cmd
ではExtendedモードを使わないことくらいでしょうか。フロー自体は非常にシンプルなので、Node-REDに慣れている方であればすぐに応用できると思います。
Gistにフローを貼っておいたので必要であれば参考にしてください。 https://gist.github.com/jacopen/72468a6176162e9a88f5cf5f654750b5
勉強会資料の最後にもちらっと書いてますが、HUISはBluetoothに対応しており、8月にはBluetooth対応のクレードルも出ました。
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を一言で表現すると、 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を立ち上げて、それとアプリを紐付けしている。そんなイメージが湧くのではないでしょうか。図にするとこんな感じ。
しかし、実際には違うのです。より実体に近い形で図を起こすとこうなります。
そう、cf create-serviceで作成されるものは、Cloud Foundryの中ではなく、外側にあるのです。このとき、Cloud Foundryと外部サービスの橋渡しをしているのが、Service Brokerです。
Cloud FoundryがService Brokerと連携する際、Cloud Foundryがクライアント、Service Brokerがサーバーという位置づけになります。
Cloud Foundry FoundationによりService Broker APIというAPIが定められています。これを実装したものがService Brokerとなるわけです。
実際にCreate Serviceをした際のフローは以下のようになります。
Service BrokerはCloud Foundryからのリクエストを受け付けて返すだけ。クライアント/サーバー型の位置づけになっていることが分かるでしょうか。
次に、作成したサービスとアプリケーションを紐付ける作業、バインド時のフローです。
create時と同じく、CFからService Brokerにリクエストが飛んでいることが分かりますね。
アプリケーションとサービスをバインドすると聞くと、間にオーバーレイのネットワークが出来上がって直接通信して・・・みたいなことを想像してしまうかもしれませんが、残念ながらそこまではやってくれません。 サービスをバインドすると、そのサービスに関する情報が環境変数でアプリケーションに渡されます。基本、それだけです。
環境変数なんてデプロイするときに自分で設定出来るんだから、こんなの要らないじゃん
そう思う人もいるかもしれません。その考え方は間違ってはいません。 しかし、以下のようなケースの場合を考えてみましょう。
Microservicesが叫ばれる昨今、機能単位で細かくアプリケーションを分けるシーンも増えてきています。その場合、MQなどを用いてアプリケーション間でデータのやり取りを行う必要があるわけですが・・・
たとえばこの状態でMySQLやRabbitMQを作り直したり、プラン変更でエンドポイントを変更するとなるとどうでしょう。全てのアプリケーションの環境変数を変更する必要がありますね。
ただ、運用を考えると、同じ設定をあちこちに入れるのはあまり美しくありません。出来る限りDRYにいきたいものです。
MySQLやRabbitMQを、ひとつのリソースとして見立て、必要なアプリケーションからそれぞれリソースをバインドする。こういうモデルにすることで、何か変更が発生した場合も、リソース側だけを差し替えれば済みます。1アプリケーションだけ設定を間違えて問題がおきるといったこともありません。
12 Factor Appで示されるベストプラクティスの1つ、バックエンドサービスをアタッチされたリソースとして扱う が実現出来るわけですね。
CFは優れたPaaSですが、その設計思想からしてもDBのようなステートフルなサービスを運用するには向いていないのです。Service BrokerはそのようなCFとその他のサービスを疎結合で結びつけることで、より柔軟な拡張性を持たせるための仕組みということですね。
Kubernetesは最近のアップデートを見る限り、ステートフルなアプリケーションも極力サポートしようという動きがみられます。しかしながら、「動かせる」ことと「動かしたいかどうか」は別に考える必要があります。 たとえば、メールサーバーを動かすのもやろうと思えば可能でしょうけど、メールサーバーの運用経験がある人であれば自分で運用したいとは二度と思わないでしょうし、ましてやKubernetesの上に載せたいなんて考えすらしないでしょう。
そうなると、やはり同じように外部サービスに投げることになるわけで、そこでService Brokerのような仕組みがあれば、より簡単にKubernetes上のアプリにバインドすることができるわけですね。
現在は、service-catalogという名前で実装が進みつつあるようです。
また、このService Broker開発にも関わるDeisのチームは、stewardと言う名前で何かを開発しているようですが、これがどう絡んでいるのかは深く追っていないので分かりません。
というわけで、今回の記事はこれでおしまい。
10/3に、HUISのソフトウェア バージョン3.1がリリースされました。 http://huis.jp/news/20161003/
変更点を見ると以下のように書かれています。
なるほど、確かに今まで画面の切り替えには一呼吸置くくらいの待ち時間が発生していたので、速度の向上は嬉しいですね。
しかし、リリースノートでは控えめの表現になっていますが、中の人曰く、今回のアップデートでは『劇的に』速くなっているそうで。
ということで、早速比較してみました。
こ、これは確かに速い!
スワイプによる画面切り替えは速度の問題で使いづらかったのですが、今回のアップデートで一気に実用になった感があります。さらに、これまで要求されたエッジからのスワイプが不要になり、より気楽に画面切り替えができるようになりましたね。これは嬉しい。
動画では表現出来ていませんが、ボタンの反応速度も速くなっています。
これ、マイナーアップデートじゃなくてメジャーアップデートでも良かったんじゃないでしょうか。っていうくらい、劇的に使い勝手が向上するので、HUISを持っている方はアップデート必須ですねー。