昔の技術を知ることで、今の技術にも活かせることがある　“デプロイ今昔物語”からmacopy氏が感じたこと

Dockerを使用したデプロイの手法

macopy氏（以下、macopy）：次にアーキテクチャの紹介に戻ります。アーキテクチャの紹介に戻るというか、Dockerはアーキテクチャのほうかなと思ったのでそうしています。

DockerはどちらかというとPull型デプロイなんですよね。オペレーション端末。先ほど言った手元のローカルからdocker push……。tarballの代わりにdocker pushにDocker Registry」「Docker Hubだったり、今回のケースではghcr.ioというGitHubのものを使っていますが、そこにアップロードします。

その後のオーケストレータで、例えばKubernetesだったりECSだったり、今回の例ではなんとSwarmを使っています。シングルノードでSwarmを動かすことをやっています。Docker Swarmというやつですね。

デプロイの指令をすると、オーケストレータが認識しているサーバーに対してdocker pullをして、コンテナイメージを入れ替える作業をやってくれる。Pull型デプロイの正常進化みたいなところがけっこうあります。

Docker Swarmを用いたDockerのデプロイ

macopy：というわけで、Docker Swarmを用いたDockerのデプロイをやっていきます。ctopで見たほうがいいですか？　Dockerが今は2個動いていますね。Dockerというか、Plackのhellodockerというものがあって、これが2コンテナ動いています。

それをデプロイします。（画面を示して）これは何をやっているかというと、docker buildをした上でbuildxを使っているのはARMマシンで、デプロイ先がx86なので、デプロイされるサーバーの側を登録して、そちらでビルドをするという、チートみたいなことをやっています。かつ、その後にSSHしてprovision.shをしています。

（画面を示して）provision.shのほうは何かというと、こんな感じです。これはDocker Swarmのコマンドですが、service update hellodocker --imageと指定してあげるとコンテナが入れ替わるようになっています。ローリングリスタートみたいなことをやっています。

というわけでデプロイします。今、右端のUPTIMEが6時間9分になっているじゃないですか。デプロイするとこれが変わります。

shebang、カートンインストールが長いんだった。あっ、すぐいったな。キャッシュしているからか。こんな感じで入れ替わります。はい、入れ替わりました。というわけで、Docker Swarmですね。

じゃあ見てみましょう。ただ変わらない気がする。こんな感じでデプロイされています（笑）。

（会場拍手）

というわけでDockerの発表は2013年。Pull型デプロイではあるんだけれど、Pull型の何が違うかというと、アプリケーションプログラムに加えてランタイムまで一気にデプロイすることになったという感じですね。

それまではランタイムのほうは普通にサーバーをセットアップする（感じでした）。例えば当時はChefとかでやっていたのが、Dockerの中でPerlをインストールしたりしていた感じですね。

サーバーレスのデプロイ

macopy：最後にいきます。サーバーレスです。サーバーレスが何かはけっこ毛色が違うんだけれど、ローカル端末からAWSに対して関数をアップロードします。

その時点では、それ以外なにも起こりません。ただ、HTTPのリクエストが来た時にmicroVMが起動して、この場合はその中でPerlのプログラムのhandler.plが実行されるという感じですね。

これも見ていきたいんですが、時間がないのでデプロイだけやります。Lambdaです。ここからデプロイをやります。lambrollというAWS APIを使ってデプロイされます。

この後にブラウザが開いて、Lambda側のやつが動きます。Lambdaで動きます。これでPerlのプログラムが動いています。

pidは入れているんですが、microVMの中のpidだからほとんど意味はない（笑）。一応入れているけど、まぁ……という感じですね。

というわけで、アプリケーション制作者が直接管理するレイヤーが、時代を追うごとにどんどん上に上がっていくんですよね。物理サーバーだったり仮想サーバーだったり、IaaSだったりコンテナだったり。

そんな感じなんですが、最後にサーバーレスに来ると、レンタルサーバーとかCGIにけっこう近い、リクエストが来たら起動するみたいな（動きになります）。永続化がされて効率良くできるようになって、それを効率良く管理するのがクラウド事業者側の責務になったというのが、サーバーレスとCGIの違うところかなと思います。あと、PaaSとかありましたね。

昔の技術を知ることで今に活かせることもある

いかがだったでしょうかというわけで、登壇者の感想としては、昔の技術の課題を解消するために、新しい技術が出てきた。つまり試行錯誤の結果、今があって。try/catchかなと思います。

というわけで、昔の技術を知ると「昔のこの部分は良かったな」みたいなことを知ることができて、それは今に活かせるんじゃないのかなと思います。今はアプリケーションが解く課題が複雑になっているから、マイクロサービスだったり、デプロイも複雑になる傾向にあるのかなと思います。

というわけで、あなたの好きな「デプロイ」はありましたか？　発表は以上です。ありがとうございます。

質疑応答

司会者：ありがとうございました。会場にいる方で、質問などある方がいたら、挙手をお願いします。どうぞ。

質問者1：サーバーレスでもパーミッションはチェンジモードにしないと動きませんか。

macopy：ちょっと（画面を）出しましょうか。サーバーレスに関してはパーミッションという概念はそこまでなくて。これはLambdaの場合が、function.jsonの中にhandler.handleという（ものがあって）、（それが）「この関数を読んでください」というかたちになっていて。内部的にはdo（他のファイルに書かれたスクリプトを即時実行する）とかそういうものをしているはずなので。

かつ、その中でhandleという名前空間を入れた上で実行しているかたちになるので、パーミッションに関してはよしなにやってくれているというのが回答かなと思います。

質問者1：あと、デプロイの方法で、本当にサーバーレスというのであれば、ブラウザのテキストエリアにソースをバンと貼ったら実行できるというようにしてもいいと思うんですけど、なぜそういう方法は採られていないんでしょう（笑）？

macopy：Lambdaに関しては、AWSコンソール上で関数をそのままエディタの中で編集した上でデプロイというのはできるんですが、今回に関してはデモなので失敗したくないということで、CUI内でやりました。

質問者1：ありがとうございます。

macopy：ありがとうございます。

司会者：ほかに質問がある方。どうぞ。

質問者2：楽しい発表をありがとうございました。デプロイのプラクティスとかをどう探せばいいか、コツを教えてもらえないでしょうか？というのは、例えばスクリプトとかの権限やユーザーをどうするかとか、本当にいろいろな環境が違って。検索してもぜんぜんいいのが見つからなくて、独自（の方法）でやっちゃって、「本当にこれでいいのかな？」となることが多くて困っています。

macopy：確かにデプロイって、明文化というか標準化されにくい分野ではないかなと思うんですよね。というのも、1回作ってしまえば固定化されてしまうものでもあるから。なので、「じゃあどう探せばいいの？」と言われると言葉に詰まるんですけれど。

どちらかというと、自分が「こうやっているよ」と発信した上で「こうやったほうがいいよ」とほかから情報を仕入れていく。自分がやっていることを外に出していくと情報が集まってくるんじゃないかなと思います。

質問者2：なるほど。ありがとうございます。

会場：サーバーを担ぐので、ちょっと筋力が（必要かもしれない）……。

macopy：まぁ、そうですね（笑）。かもしれないです。

司会者：ほかに質問がある方はいますか？

質問者3：おもしろい発表をありがとうございました。今回、いったんサーバーレスまで説明してもらったと思いますが、最近、新しいものがいろいろ出てきていて。サーバーレスは似ていると思いますが、ワーカーだったらCloudflare Workersとか、CGIの上でなにか動くようなものが出てきていて。そういうところでデプロイのあり方が変わったりしたようなことはなにかあったりしますかね？

macopy：そうですね、デプロイのありがたみという面ではサーバーレスだったりFaaSに近いかなと思うんですよね。ただ、どちらかというとランタイムの管理が必要ないとか、サーバーの管理、台数のスケールとかそういう設定が必要ないとか、チューニングを勝手にやってくれるとか。

そういった面でエッジで動くワーカーとかは、すごく優れていると思っていて。「そこまで管理したくないよ」という人にとっては、すごく良い選択肢なんじゃないかなと思いますね。

質問者3：ありがとうございます。

司会者：ほかに質問は……。

質問者4：Push型のデプロイの時に途中でマシンが増えた場合に、増えたマシンがたぶんデプロイできない問題があると話されていたと思います。Pull型の場合にそこをどういうふうに解決しているかの説明がなかったような気がするんですけど。

macopy：なるほど。ありがとうございます。確かにいい指摘だと思います。

Pull型の場合は、新しくサーバーが立ち上がった時に、起動スクリプトとしてオブジェクトストレージからmanifestファイルだったりアプリケーションファイルを自律的にダウンロードしてきて、そこでいったんデプロイしてしまうかたちにするのが、私がやっていた手法かなと思います。

起動した時にデプロイと同じことをやるということですね。回答になっていますでしょうか？

質問者4：わかりました。ちょっと思ったのは、起動中にデプロイされたら次のバージョンが……。

macopy：けっこう難しい問題なんです。その時は、これは難しいかもしれないですが、オートスケール中は新しいデプロイをやらないとか、キューに溜めておくとか、ロックを取るとか、そういう手法はあるかなと思いますね。

質問者4：わかりました。ありがとうございます。

司会者：ほかに質問は大丈夫でしょうか？　では、ちょうど時間になりましたので、このセッションを以上とします。macopyさん、ありがとうございました。拍手をお願いします。

（会場拍手）

macopy：ありがとうございます。