Cloud Penguins

Flying pengiuns in the cloud.

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リリースが今年末に予定されているようです。

メタ勉強会でLTしました

先日、GREEさんところで開催されたメタ勉強会 #metabenkyokai に参加してLTしてきました。

そのときのスライドがこちら。

たまたま @iwashi86 さんが発表するというのをみかけて、じゃあ僕もなにか発表してみようということで飛び込んでみました。

iwashiさんはiwashiさんの部署で活発に社内勉強会を開いていて、僕もなんどか参加しています。 僕は僕で、あまり頻繁にはやれていないけども社内勉強会にトライしていたので、今回はiwashiさんの発表をもうちょっと膨らませる感じで、社内だけでなくグループ会社に広げるにはどうすれば?というテーマで発表しました。

スライドを見て頂いたら分かるように、結局一番大切なことは、横の繋がりを強めていくという点につきるんですよね。それが出来て初めて勉強会を広めていくことができる。横の繋がりができれば、あとは普通の社内勉強会と同じような感覚で開催出来るんじゃないかなと思っています。

今回の勉強会では、3名のセッション+4名のLTがあったわけですが、会社規模の大小を問わず同じ課題、同じ悩みを抱えていることが分かりました。

  • 勉強会開催するも続かない問題
  • 発表資料作るのに時間かかりすぎ
  • どうしても本業を優先しなければいけないので開催出来るとは限らない
  • 発表者が特定の人に偏る、もしくは発表者が居ない

などなど。

主催者はどうしても負担がかかることを覚悟しないと社内勉強会は難しい。しかしながら、負担がかかるのを放置し続けると、結局続かないという結果に陥ってしまうため

  • あまり気合いを入れすぎない
  • たとえば輪読会やもくもく会のように、主催者や発表者に負担がかからない仕組みをうまく取り入れる
  • 昼休みの時間をうまく活用する

などの解決策が提示されていました。 共通の悩みを抱えているということは、共通の解決方法を試みることで良くしていくこともできそうです。 このあたりを実践して、次に機会があったときは勉強会の改善っぷりを報告してみたいですね。