Cloud Penguins

Flying penguins in the cloud.

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があったわけですが、会社規模の大小を問わず同じ課題、同じ悩みを抱えていることが分かりました。

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

などなど。

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

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

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