第39回 PaaS勉強会に参加してきました。

一昨日(10/16)は、「第39回 PaaS勉強会」に参加してきました。

paas.connpass.com

f:id:kabukawa:20181016182647j:plain

観覧席側が少し上に上る感じになるという、劇場感あふれる会場でした。奥にサンドバッグとかダーツがあって、不思議空間ともいう（笑）

なんで参加したか

PaaS勉強会への参加は2度めです。クラウド使っていたと言いながら知らないことがまだまだ多いので、勉強をするために参加しています。主催者、スタッフの方々をはじめ、講演者の方も参加者の方も非常に真面目に参加されているので、懇親会とか無くていいからPaaSについて勉強したい！という方にはおすすめです。

参加してみて

当日はいくつかのアクシデントが重なり、予定されていた発表がキャンセルになってしまいましたが、その分発表時間に余裕ができてしっかり聞くことができました。質問も活発に出されて、結果的にはいい感じの時間で収まっていたので、なんか運営も参加者の協力もすごいなぁと思いました。

HelmとService Brokerで始める検証環境自動構築

最初は、Teppei Fukuda(@knqyf263)さんから、「HelmとService Brokerで始める検証環境自動構築」というタイトルでの発表でした。

speakerdeck.com

資料が非常に丁寧に作られているので、余計な説明をしなくても資料を読むだけで伝わると思います。内容としては以下のような流れで一つづつステップを追って説明をしていただきました。

検証環境自動構築の定義
Helmによる検証環境自動構築
Service Brokerによる外部サービスプロビジョニング
Helm + Service Broker
Service Brokerの現状の問題点

この資料を一晩で書き上げたとのことですが、凄いですよね。。。時間に余裕があったというのもありますが、セッション後の質疑応答も活発に行われていてよかったです。

個人的にはこのセッションで

HelmとChartの関係が整理ができ、条件分岐などを使えることもわかった
Helmだけだとクラウドのリソースをプロビジョニングできないので、Service Brokerを使う
Helm + Service Brokerの組み合わせでクラウドを含めた検証環境作成を自動化できそう
但し、Service Brokerは発展途上なので安定的に使えるようになるにはもう少し時間が必要そう
でも、逆に言えばService Brokerの開発に関わるチャンスでもある

ということを学ぶことができました。分かっていないことも多かったので、非常に参考になりました。

なお、Open Service Brokerに興味が出た人はこのブログエントリを読むのがおすすめとのことです。

https://blog.ik.am/entries/497

Cloud Native Buildpacksで、めんどうなコンテナイメージ作成を自動化しよう

続いては草間さん(@jacopen)から「Cloud Native Buildpacksで、めんどうなコンテナイメージ作成を自動化しよう」というタイトルでの発表でした。

speakerdeck.com

内容は、

Docker Imageを作るのに yaml書いたり docker buildするの、面倒だよね？
Cloud FoundryとかHelokにアプリをデプロイするのは1コマンドで簡単
これらのPaaSでも、実際にはコンテナでデプロイされたものを動かしている
このとき裏で動いているのがBuildpacks
これを使うと色々捗るんじゃね？

という感じの流れから、このBuildpacksについての話に。

Cloud Native Buildpacks

どんなものから上記ページから引用すると

Buildpacks were first conceived by Heroku in 2011. Since then, they have been adopted by Cloud Foundry and other PaaS such as Gitlab, Knative, Deis, Dokku, and Drie.

The Cloud Native Buildpacks project was initiated by Pivotal and Heroku in January 2018 and joined the Cloud Native Sandbox in October 2018. The project to unify the buildpack ecosystems with a platform-to-buildpack contract that is well-defined and that incorporates learnings from maintaining production-grade buildpacks for years at both Pivotal and Heroku.

ということで、雑な訳をすると

「Buildpacks は2011年にHelokが考案して、その後Cloud Foundry やその他の PaaSにも採用された。 Cloud Native Buildpacks プロジェクトは Pivotal と Heroku によって2018年2月に開始され、2018年10月にCloud Native Sandboxに参加した。プロジェクトは、明確に定義されているプラットフォームとビルドパックの仕様とPivotalとHerokuの両方で何年もの間、プロダクショングレードのビルパックを保守することから得た知見によってBuildpacksエコシステムの統一を目指している。」

という感じのことが書かれています。

で、使い方は簡単で pack build コマンドを実行するだけです。

pack build --path <path to source code> <repository name>:<image tag (optional)>

コマンドを実行すると、Buildpacksによってビルドをするべき builder がチェック、実行されるようになっています。なので、どの言語を使っているから、というようなことは使う側は意識する必要はなく、コンテナのビルドをよしなにやってくれる、と。 yamlを自分で書かなくてもコンテナのビルドができるってすごくないですか？僕は結構感動しました。

ただ、この Cloud Native Buildpacks は、PaaS間で異なっていた仕様の統一も行っているので、これまでの builder がそのままは動きません。セッションでは、正式に対応しているのは Node.js とJava のみのようです。もちろん、今後対応言語は増えていくので、これからに期待というところだと思います。