Cloud Native BuildpackでToilを減らす
Kazuto Kusama氏：始めさせていただきたいと思います。よろしくお願いします。
今日は「Cloud Native BuildpackでToil減らしていこうという話」をしていきたいと思っております。
さっきご紹介いただいたんですけれども、私はPivotal Japanという会社で働いております、草間と申します。
よろしくお願いします。ようやくこのNoOps Meetupの場に立つことができました。というのも、第1回のときからサポーターというかたちで参加させていただいております。
事の発端は、後ろにいる運営メンバーの川崎さんが突然Facebookでメッセージを送ってきて、「サポーターとして参加してみません？」みたいに言われて。なんかおもしろそうだから「お、いいですよー」みたいに返したんですよ。
ただぶっちゃけ、このとき「NoOpsって何？」っていうくらい、なにも知らなかったんですね。NoOpsって字面だけ見ると、なるほど、「運用がない」？ 必要ないってこと？ みたいに読めました。僕の立場からすると「え、それPaaSじゃん」って思ったんですよ。
とはいえ字面だけで勘違いしてもいけないので、川崎さんからメッセージをもらいつつ、「NoOpsって何やろう？」って横でググってたんですよ。そしたら、岡さんのこういった記事がいっぱい出てくるわけですよ。
いろいろ読んでいくんですけど、システムの回復とかそのあたりについて述べられているわけですね。これを見て、僕はこう思いました。「PaaSじゃん」。
（会場笑）
まあ、まだわかんないと。記事だけ読んで本当に理解できたのかどうかわからないので、第1回からサポーターとして参加させていただいています。
さっきもありましたよね。
「システム運用の“嬉しくない”をなくそう」って書いてあるんですよ。これを見て、どう思ったか。「PaaSじゃん」。
（会場笑）
僕の立場上、PaaSと聞いたら来ないわけにいかないなと思ってます。というのも、PaaS勉強会をかれこれ7年くらいやってまして。2011年からやってて、もう39回ですね。
それくらいPaaSに思い入れがあって。
PaaSを使い始めたきっかけ
なんでこんなにPaaSに思い入れがあるかと言うと、ちょっと僕の昔の話をするんですけれども。何年前だっけ？ 9年前か。受託開発をやってる、小さな会社にいたんです。
「うちもWebサービスやってみたい」みたいなことを、社長が言い始めたんですよ。
「いいんだけど、誰が運用するの？」と。インフラまで詳しい人って、ぶっちゃけそんなにいないよねみたいな話をしたら、「キミができるやろ、よろしく！」みたいな。「ちょっと待って」みたいになりますよね。
そのとき自分がどうしたかというと、みなさんWindows Azureって知ってます？ 今はもうMicrosoft Azureって名前ですけども、そのころはWindows Azureっていう名前でした。
Azureって、今でこそいろんなサービスがあるんですけど、そのときってPaaSしかなかったんです。9年前はPaaS専門だったAzureを使ってやってみたんですよ。
そしたらどうなったらかと言うと、運用担当はたった僕1人だけでできてしまったんですね。運用まで含めて全部。自分はそのあと1年ちょっとで退職しちゃったんですけど、聞くところによると、つい最近まで動いていたと。これってすごくないですか。この経験が僕にはものすごく衝撃的で、PaaSってすごいなと。
すごく衝撃だったので、そのあとPaaSに興味を持っていろいろやってたんですけども。そしたらCloud FoundryというオープンソースのPaaSが登場して、それは個人的に趣味でやってました。
その後、とある通信企業がCloud FoundryをベースにしたPaaSを開発してるよという話を聞いて、これはぜひ参加したいと思って「PaaSやりたいです！」という一心で転職して。そこから5年間、その通信企業でPaaSの開発をやってきました。
そのうち「もっといろんなことをやってみたい」「見てみたい」と思うようになり、Cloud Foundryの開発の本家本元のPivotalという今の会社に転職したというのが、2年前の話になります。ということで、個人的にも8年間ずっとPaaSをやってきてるので、すごく思い入れがある。
PaaSって何がすごいの？
PaaSって使われたことがある方もいらっしゃるかもしれないので、改めてそうじゃない方々に向けて、すごいところを説明していきたいんですけれども。これまた、岡さんのスライドばっかり出てきます。
NoOpsシステムが備えるべき3つの能力。観察力・構成力・復元力。このあとほかにも要素が出てきますけれども。このあたりの要素をPaaSは満たしています。
しかも最近になって満たしたとかそういう話ではなくて。少なくとも、自分が初めてPaaSを触った2010年とか2011年のころからこのあたりのことを実現している。なのでNoOpsって言ってますけど、ようやく「PaaSの域まで至ったか」みたいなくらいに考えているんですけれども。
それはそれで置いといて、今DockerとかKubernetesとかコンテナって流行ってるじゃないですか。実際に使って運用してるよとか開発してるよって方は、どのくらいいらっしゃいます？
（会場挙手）
けっこう多いですよね。半分超えてますよね。今手を挙げた方の中で、「Dockerfile書くなんて造作もない」っていう人は、どのくらいいらっしゃいます？
（会場挙手）
数人いらっしゃいますね（笑）。まあ、ガッと減っちゃいましたよね（笑）。実際そのあたりって、けっこう大変じゃないですか。
DockerってBuild-Ship-Runという3フェーズを提唱しているんですけども。どれもまあまあ考えなきゃいけないポイントがあり、特にこのbuildのところは大変なんじゃないかなって、個人的には思います。それ特化のミートアップが世の中にはあるくらいのレベルなので、やっぱ面倒くさいとかけっこう大変だなと。
レイヤー構造をちゃんと理解したうえで美しいDockerfileを書いてたら半日終わったとか。初めて触る人にDockerのADDとCOPYの違いを説明してたら、それだけで半日過ぎてたとか。いろんなつらいポイントってあるじゃないですか。このあたりがコンテナのつらいところだよね、みたいな話を、去年JapanContainerDaysというイベントで話したりもしていました。
これまでのワークフロー
先ほどの話をワークフローで言うと、開発者がいたとして、最初にDockerfileを作るところからbuildをやって、そのあとDocker pushをして。
Kubernetesとかを使うんだったら、それを使う用にmanifestを書いてapplyして……みたいな流れになりますよね。これを手動でやるのはあまりよくないので、CI/CD使ったりして、基本的にはこれを自動化するという話になるわけです。
このあたりをやってると、けっこう考えなきゃいけないポイントいっぱいありますよね。
今話したようにDockerfileをいかに書くかという知識も必要ですし、あとはそもそもimageを、プライベートレジストリをどうするかとか、そもそもbase image何にするかとか。けっこう考えなきゃいけないポイントがあります。
そんな感じで四苦八苦やってようやくコンテナを使った開発とか運用ができるようになったところで、詳しい人とかがやってきて「このDockerfileクソですね（笑）」「イメージサイズ、超でかくないですか？（笑）」みたいなことを言ってくるわけですよ。「クソが！」って思うじゃないですか。
これってToilじゃないですか。すごく。
（会場笑）
しかも自分だけならまだいいでしょう。ただチームで、マイクロサービスみたいに言ってるくらいですから、それぞれのチームでそれぞれのDocker Imageを書いて、さっきのフローを回すわけですよね。そうすると、詳しい人が来てディスってくるわけじゃないですか。結局これってToilじゃないですか。
クソが、みたいになるわけです。
一方、自分がずっと見てきたPaaSだったらどうなるか？ デモって書いてるんですけど、ちょっと時間もかかるので動画にしてあります。Cloud Foundryを使ったときのデプロイの様子を動画にしてきたんですけれども。
今これディレクトリの上にNode.jsのアプリがポン置きしてあります。DockerImageやDockerfileとか、まったく置いてません。Node.jsのアプリだけです。
これをcf pushみたいなコマンドを打つだけで、自動的にPaaSであるCloud Foundryのところにデプロイが始まって、内部でなんかいろいろ処理が行われてるな～と。これはただ見てるだけです。
終わりましたと。Routesっていう感じでURLが出ているので、これをブラウザでアクセスしてみるとどうなるかというと、これだけで動いてますと。
さっき話したようなアプリを開発して、Dockerfile書いて、buildして、pushして、manifest書いて……みたいなフローと考えると、めちゃくちゃ楽じゃないですか？
Cloud Foundrについて
PaaSの例ということで、Cloud Foundryの例を挙げてみました。
有名なパブリックPaaSの、Herokuを使ってもほとんどフローは一緒です。cf pushがgit pushになるくらいの違いです。コマンド一発でデプロイしたら、あとは全部お任せっていう世界になってます。
このときコンテナイメージとか、コンテナレジストリとか、マニフェストとか、そういったものは一切気にする必要がないんですね。
「なんでこんなことができるのか？」なんですけれども、それを解く鍵がBuildpackという魔法なんですね。
HerokuとかCloud Foundryを使ったことがある方はご存じだとは思うんですけれども。このあたりの自動化の鍵はBuildpackにあります。Buildpackが内部でうまいことやってくれるから、さっきみたいな魔法ができるんですね。
Buildpackって何かと言うと、もともとはHerokuが作った仕組みで、それにCloud Foundryが乗っかったかたちなんです。
PaaSの上に任意の言語とかフレームワークというのを使えるようにするための仕組みなんですね。最近ではGitLabもいろんな機能が増えてまして、その一環でBuildpackが使えるようになっています。
