ecspressoとlambrollの紹介と開発の経緯
今回は、ゲストをお呼びしての特別回となります。 藤原さんに来ていただきました。
よろしくお願いします。
藤原さんは本当にたくさんのOSSを作っているんですけど、 今回はAWSの環境にデプロイするというところで、
エスプレッソとラムロールの話を中心に 聞いていきたいなと思っているので、よろしくお願いします。
よろしくお願いします。藤原です。
では早速、エスプレッソとラムロールは それぞれ何をするツールなのか教えてもらっていいですか?
エスプレッソはAmazonのECSという コンテナのサービスがありますけれども、
そこに対してのデプロイツールですね。
コンテナのサービス定義とタスク定義という 2つの概念があるんですけど、
それをファイルで管理しつつデプロイできるという 一種のIACツールというかそういうものです。
ラムロールはそれのラムダ版ということになってまして、 AWSラムダに対して同じように関数定義をファイルで管理して、
それをデプロイするというようなツールになってますね。
どちらもGoで書かれたCLIで手元でも動かせますし、 GitHub Actionsとかそういうところでも動かすことができるというようなものになってます。
なるほど。そもそも何で作ったんですかね。 どういう経緯で作ったかって教えてもらいたいですね。
そうですね。これはもう10年近く前の話なんですけど、 当時仕事でですね、そのECSを使い始めようということになりまして、
それでECSってデプロイにあんまりデファクトなツールとか 公式でこれが決定版みたいなものはなくて、
当時みんないろんなものを作って使ってたんですよね。
それでいろいろECSのデプロイツールを GitHubとかで探して見ててですね、
でもこれなら作れるなみたいな。
というのは、APIを3回ぐらい叩くとできるんですね、 デプロイっていうのは。
なので、それで自作してもいいかなと思って 作り始めてしまったというのが最初のところですね。
デプロイツールっていろいろありまして、 テラフォームとかCDKみたいに全部を管理するタイプのツール。
いわゆる環境からネットワークから、 IAMの権限とか、
そういうものも全部一つのツールで 管理するっていうタイプもありますけども、
EspressoっていうのはECSに関するものだけを扱う。
それ以外のは参照だけしてですね、 取り込む機構を後から説明すると思いますけど、
そういうものをECSだけを扱う。
ラムロールも基本的にはラムダのみを扱う みたいな感じで用途を絞ったツールになってますね。
CloudFormationを経由しない選択とその理由
ありがとうございます。
例えばラムダとかだったら、 一応公式ツールもあるかなとは思うんですけど、
そういったツールを選ばなかった理由っていうのは どういうところにありますか?
そうですね。ラムダは当時、 これはラムロールを作ったのは2019年なんですけど、
当時Apexというツールがありまして、 これもラムダのデプロイツールだったんですよね。
これはGoで書かれていたツールで、 簡単にデプロイできて、
ラムダだけを扱うみたいなツールだったんですけど、 これがメンテナンスを停止してしまったんですよね。
Apexでデプロイしてたんで、 それが使えなくて困るなと思って、
サムとかサーバーレスって今でも有名なやつ、 公式のやつとか非常に大きなシェアのあるやつがあったんで、
それを使おうと思ったんですが、 ちょっと性に合わなかったというかですね、
バックエンドがクラウドフォーメーションだったり するんですよね。
なのでデプロイツールをデプロイすると、 クラウドフォーメーションのスタックができて、
それがガチャガチャと動いて デプロイされるみたいな仕組みで、
どうも体験が良くないというか、 第一は遅い。
クラウドフォーメーションの実行って そんなに早くなくてですね、
数秒で終わらなくて、結構待たされたりとか、
あと何か問題があったときに クラウドフォーメーションの中に手を入れないといけない、
見に行かないといけなくて、 それがちょっと嫌だなという感じで、
基本的には僕はあんまりクラウドフォーメーションを 好まないタイプの人だったので、
なのでAPEX同じようなものを作れるなと思って 作ったらできたというのがRAMロールですね。
なるほど、なるほど。 自分も以前サム確か一瞬使おうとして、
クラウドフォーメーションのエラーがドバーって出てきて、 なんだこれってなっちゃったんですよね。
それでRAMロール使ってみたらあっさりできたんで、 これでいいじゃんって当時なったことがあって、
やっぱり明らかにクラウドフォーメーション使うのは オーバースペックというか、
なんでこれ経由するんだろうみたいな感じだったんですよね。 やっぱりそういうところですよね。
そういうところですね。 実際デプロイで作ってみると分かるんですけど、
APIを何回か叩けばできるんですよね。 一発だと大体できないんですけど、
いくつかのAPIを組み合わせて何個か呼び出しするとできて、 CLIでもできますしSDKでもできるので、
それをクラウドフォーメーションみたいな 汎用的な仕組みに乗っける必要はあまりないなと。
特に用途を絞っているので、この利用者は。 他の例えばIAMをコントロールしたりとか、
ネットワークまで面倒見たりとなると、 呼び出すAPIがすごいいっぱい増えちゃって、
そうなると手当たり次第にAPIを叩いてても なかなかツールとしてまとまらないんですけど、
そういうことを考えないでですね。 AWSラムダとECS、この2つに絞っているので、
結構比較的簡単に実装ができるみたいな感じですね。
インフラとアプリケーションのデプロイ分業とecspressoの役割
ありがとうございます。 今のネットワークの話とかも出たんですけど、
ネットワーク周りとかってあんまり変わらないから、 設定が。
テラフォームとかでやった方がいいってなると思うんですよね。
エスプレッソとかラムロールいいなと思うのは、
テラフォームであんまり変わらないところはテラフォームで、
アプリケーションエンジニアが触りたいところは、 よく変更するところはエスプレッソとかラムロールで、
別で管理できるっていうのがすごいちょうどいいな っていうふうに感じているんですけど、
そこも意識した部分なんですか?
これはですね、最初に意識したというよりは、
エスプレッソを作るときに最初に仕事で作ったんですよね。
仕事で実は分業するような仕事があって、
僕の当時いた会社はアプリケーションを作ります。
アプリケーションはデプロイ当然したい。
他のインフラを管理する会社さんは別にいたっていう協業的な案件がありまして、
そうするとですね、お互いの作業がぶつかることがあるんですね。
一つのツールで両方やろうとすると、
インフラの会社さんはこういう変更をした、
うちはこういう変更をしたいみたいなのが、
ちょっとなかなかすんなりいかない。
当時まだスラックのチャンネルとかでも一緒にやるようなことしてなくて、
全部チケットベースでとなると非常に手間がかかって大変だったっていうのがあって、
それをその前にですね、
EC2の上でサーバー、普通のVMの上で同じようなことをやってて、
本当に苦労したんですよね。
例えばVMの上だとエンジンXとかフルエントDみたいな、
ミドルウエアというかインフラというかアプリケーションというかミドルウエアというか、
そういうちょっと扱いが難しいというか、
どっちも触りたくなるようなところがあるんですけど、
そういうものを管理が非常に2社でお見合いになったり、
お互いを壊したりみたいなことがあって大変だったので、
次の案件はECSにしたかったんですよね。
ECSにするときにインフラはその会社さんに全部お任せします。
AMとかは1回作るとそんな変わらないんで、
1回権限を作ってもらってチケット発行してやってもらったらそれを使います。
ただアプリケーションは本当に毎日毎日デプロイしたいので、
じゃあECSの上だけは僕らに権限をくださいと、
ECSのAM権限全部くださいと言って、
そこを分解点にしたんですよね。
そういう関係があったのでインフラ周りはいじらないし、
アプリケーションのことは基本的には全部いじるみたいなツールになったという、
それは最初から考えたというよりは業務汚染引きしたからそうなったという感じですね。
なるほど、そういう経緯だったんですね。
だけど実務でも同じ会社でインフラもアプリケーションもどっちも見ているケースでも、
明らかに更新頻度が違うと思うんですよね。
やっぱりアプリケーションに近いレイヤーとネットワークとかのレイヤーって、
なのでそこの分解点が結局いろんな会社でハマったんじゃないかなという気がしますね。
それはありますね。
特にEC2からECSに移行しますみたいな案件だとか、
部分的にラムダを使いますみたいな案件ってあるじゃないですか。
そういう状態だとネットワークとかもあるんですよね。
なのでそれを例えばコンテナのデプロイのためにわざわざVPCから作りますみたいなことはしないので、
そういう意味ではありものに乗っかって動けるっていうのが、
変更頻度が高いものを単独でできるっていうのが1つ使いやすくなったポイントかなとは思います。
めっちゃいいと思います。
Terraformとの連携とtfstate-lookup
あとやっぱり最近だと今のインフラの構成のところってテラフォーム使うケースが多いと思うんですよね。
その辺の組み合わせとかって何か考慮されている部分はあるんですか?
組み合わせとしてはそうですね。
例えばECSでいうとVPCのサブネットとかセキュリティグループとかそういう概念が
そのECSのほうにIDで指定するみたいなのが出てきますし、
ラムダでも同じですね。
セキュリティグループとかIAMのロールとかが入ってくるんですけど、
そういうものはテラフォームで代替しているので、
それのIDをカードコードしたくないっていうのがあります。
そのECS側にはIDを書かなきゃいけないんですけど、
そのIDって要するに規則性のないランダムな数字でできているので、
これをどうやって管理するかっていうのがポイントになってくるんですけど、
これはですね、テラフォームにはTFStateっていうそのステートファイルがあって、
あるリソースの実際の属性の値とかをそのステートファイルに保存してあるというのがありますね。
例えば、aws-subnet-azaのIDみたいな感じで、
リソースのアドレスがあると思うんですけど、テラフォームの。
それの実際のIDであるとか、実際の設定内容であるとか、
そういうものがJSONになって実はステートファイルに詰まっているんですね。
それを参照するに行くと、
論理的な名前から実際のリソースIDの名前解決ができるので、
なのでTFStateを見に行って、
そこで名前解決をしてIDだけ引っ張り出すみたいなことができるようになっていて、
これはそれ用のライブラリも僕は作っていてですね、
TFStateLookupっていうやつがあるんですけど、
これをライブラリとして使うと、
awsのリソース名.idみたいな感じでやると実際のIDが取れるみたいになってて、
それをエスプレッソの設定ファイルの中からある記法で書いてやると呼び出せるので、
そうすると連携が非常に簡単になる。
論理的な名前を書いておけば、
あとはTFStateを見たら実際の値が参照できるので、
というような仕組みになってますね。
なるほど、いいですね。
TFStateと組み合わせて使ってもちゃんと使いやすいようになってるんですね。
そうですね。
これはなんかジャストアイディアというか最初は全く仕組みなくて、
環境変数を展開する機能しかなかったんで、
環境変数をあらかじめ自分らで定義しておいて埋めてたんですけど、
これはTFStateを読めばできるなってことに途中で気がついて、
その機能を作りました。
なるほど。
ecspressoの機能進化：VerifyとDiff
やっぱそういうちょっと便利な機能みたいなのをどんどん自分で作ってるからこそ、
ちょっとずつ拡張できるっていうのもやっぱOSS自分で見てるからってのありますよね。
そうですね。最初は本当に300行ぐらいだったんですかね。
非常に小さいツールだったんですけど、今はテスト込めたら1万行ぐらいあるんですけど、
ちょっとずついろんな機能を足してて、最初は本当にデプロイだけができる、
デプロイしかできないツールだったんですけど、
それに付随して自分らで運用順で使っていく便利な機能とかをいろいろ足していって、
育てていったみたいな感じですね。
なるほど、いいですね。
その辺の進化の過程っていうのがすごく気になるんですよね。
以前こうだったけど、今はこうなってるとか、ここちょっと微妙だったからやっぱりやめましたとか、
そういうのいろいろあれば聞きたいなと思うんですけど、何かありますか。
そうですね。
気に入ってる機能としてはVerifyっていうのがありまして、エスプレッソなんですけど、
ECSの例ですね、サービスとかを定義して、タスク定義っていって、
どういうコンテナがどういうイメージで動いて環境変数は何ですよみたいな定義があるんですけど、
それをデプロイしたときにだいたい一発でうまく動かないっていうのがあって、
これは結構経験を積んでても、何かよくわからないけどデプロイしてみてしばらく経つと、
ダメでしたみたいなのがわかるみたいなのがあって、非常にストレスだったんですよね。
あとデプロイして、何かを変えてデプロイしてみたらコケましたみたいなのがあって、
これもストレスなんで、
デプロイできる前にわかることは先に検出したいよねっていうのがありました。
で、Verify機能っていうのがあって、
Verifyは例えばタスク定義に書いてあるイメージが存在するかとか、
イメージにアクセスできるかとかですね、
例えばサブネットとかそういうさっき言ったIDで解決するものがあるんですけど、
それが実際に存在するかとか、
そういうようなないとデプロイは受け付けられるんだけど、
実際にはタスクは起動しないみたいな、
そういうやつを実際にデプロイ前に検証できるようになってて、
それが通ると割といい確率でちゃんと動くみたいな。
なるほど、それめっちゃ嬉しいですね。
そうですね、これはもう本当に困ってたから、
これは先にチェックしたいよなと思って作りましたね。
確かに初期だと入れないだろうなと思いつつ、
使ってたら入れたいってなる機能ですよね。
そうですね、いっぱいありますね、そういうのは。
他にもありますか?
他には、Diffですよね。
Diffっていうのは、エスプレッソって、ラムラムもですけど、
ある構成ファイルがあって、そのファイルをAWS側に送り付けてデプロイを行うんですけど、
その時に何が変更されるかというのを先に知りたいですね。
というのはAWSのマネコンの方で手でもいじれちゃうので、
誰かがもしかして先に手でいじってるかもしれないじゃないですか、設定とか。
その時に知らないでコードの方からデプロイすると先途外れしちゃう。
というのがあって、そうするとやっぱり先にDiffを見たい。
これはコードをオマージュする前にDiffを見るのと一緒ですね。
なので、手元で設定ファイルをレンダリングした結果と、
今そのAWS側のリモートにある最新状態を設定ファイルにレンダリングし直したものをDiffを取る。
これは普通の文字列Diffなんですけど、JSONにしてDiffを取るみたいな感じで、
そうすると例えば、イメージのタグが違うよねとか、環境変数がこれが違うよねとかがわかる。
これもデプロイ前にわかるので、うっかり壊さないようにみたいなことができるとかですね。
なるほど。
こういう小粒な機能なんですけど、あると便利みたいなものがどんどん増えてますね。
なるほど。めっちゃいいですね。
その中で藤原さんが使ってて気づいたってやつもあると思うんですけど、
Run Task機能とOSSメンテナンスのリアル
他の人が使ってて気づいたやつとか、ドプリリクエスト送ってもらったやつとかもあるんじゃないかなと思うんですけど、そういうのってありますか?
そうですね。これは結構初期の頃なんですけど、
RuntaskっていうECSのAPIがあって、
Espressoっていうのは基本的にサービスをデプロイするためのもので、
サービスの定義と、サービスってデプロイするとそのサービスからタスクが入るんですね。
そのサービスに定義されたようなタスクが入って、それがずっと基本的には維持される。
落ちたら上がり直すし、みたいな概念なんですけど、
それと同じくですね、サービスに属さないタスクっていうのもECSにあって、
それはワンショットでポンとコンテナが起動して、役割終わったら落ちるみたいなやつですね。
これは例えばですけど、データベースのマイグレーションとかによく使われていて、
Webアプリケーションはサービスでずっと動き続けてるんだけど、
マイグレーションはコマンド一発打ちたいだけですので、
マイグレーションはコマンド一発打ちたいだけで、
それは一発のワンショットタスクで実行しておしまいみたいな使い方をするんですけど、
これのランタスク機能というのがなかったんですね。
これはプロリクいただいて、
そうするとエスプレッソが管理しているサービスとタスク定義を使って、
ワンショットのタスクが起動できるみたいなのがあって、
これは結構大変なんですけど、
意外と違ってタスクとサービスってすごい似てるんですけど、
ちょこちょこ違うところがあって、
なかなかバグを入れやすくて難しかったんですけど、
でも非常に便利に使われているのでいいなとは思いますね。
なるほど、ありがとうございます。
そうですね、他にも何か。
ちなみになんですけど、
先ほどのプロリク取り込んでっていうような機能なんですが、
藤原さん自身はその機能を使っていたりするんですかね、
運用されているのかなというのがちょっと気になって。
そうですね、今現職でちょっと転職しちゃって、
Amazonを使わない職業になってしまったので、
テストでしか使わないですけど、
当時は本当にエスプレッソ開発してからずっとですね、
転職するまで、1年ちょっと前に転職する前は、
ずっとAWS上でECSを使っていたので、
基本的にはほぼ全部の機能を自分らで使うみたいにやってましたね。
さっきのタスク一発起動の機能も使われていたという感じですかね。
はい、使うことがあります。
じゃあプロリク取り込んで実際に自分たちでも使ってっていうようなループが、
すでに確立されていて、
ちゃんとドックフーディングされている状態になっていたんですね、
エスプレッソの状態で。
ただ一個だけあんまり使っていない機能があって、
ECSのデプロイって、
ECSのネイティブコントローラーっていうデプロイメントコントローラーでやるタイプと、
コードデプロイという別のサービスがデプロイしてくれるタイプがあるんですよね。
昔はコードデプロイを使わないとブルーグリーンとかはできなかったので、
コードデプロイのデプロイコントローラーに対応したいよって言って、
これは僕は使ってなかったのでプロリクいただいて、
動くねって言ってやったんですけど、
やっぱり自分が使ってないやつはたまに壊れていることに気がつかないみたいなことがあって、
やっぱり大変だなとは思いました。
メンテナンスをしていく上で、
自分が使わない機能っていうのはどんどん忘れ去られていくわけではないですけど、
気づいたら壊れるみたいなことが結構ありがちですかね。
藤原さん今までOSSたくさん作られている中でも結構あったりします?
そうですね、やっぱり普段触っていると何かが変わった時にすぐは気がつくんですけど、
特に仕事で触っていると、
これが仕事で触っていない機能は、
自分らのツールが壊れることももちろんあるんですけど、
例えばデプロイって相手のあることなので、
AWS側で滅多にないんですけど、
滅多にないんですけど何かが変わって、
壊れているわけではなくて変わった結果にこっちが対応できていないのが急に発覚するみたいな、
例えば絶対にニルになることがなかった値がニルになることがあるみたいな、
たまたまですね、それは仕様上はニルになるかもしれなかったんだけど、
そういうのを見逃すってなくてパニックしちゃうとか、
そういうことはやっぱりたまにありますね。
なので使ってたら割とすぐ気づくけど、
使ってない機能は作れるので、
でも割とみんな教えてくれるのかな?
あと他のXを割とエゴサしていてですね、
エスプレッソとかで検索していて見ているので、
そうすると何か壊れたよみたいなのが見つかって、
おーってなって直したりしたこともありますね。
やっぱりそこは結構ユーザーさんがもうすでに多数使ってくれている方がいるからこそ、
フィードバックが結構くるっていうところがかなりありますよね。
あとちょっと思ったのが、
先ほどちょっと前ですかね、
インフラを管理するチームとアプリケーションを管理するチーム、
別々だったっていう話があったじゃないですか。
それでインフラのほうはテラフォームで管理しているっていう話だったんですけど、
アプリケーションのほうを管理しているから、
エスプレッソっていうようなツールができたって話だったんですが、
逆にインフラの会社さん、チームから、
エスプレッソに対してこういう要望をちょっと追加してくれないか、
みたいなのってなかったんですかね?
インフラ起点であったりしたんですかね?
それともなかったですか?
インフラ起点でっていうと、
テラフォームを使っていない人たちも当然いるわけですよね。
例えばCDKを使ってますとか、
CDKもクラウドフォーメーションも最終的にはクラウドフォーメーションになるという意味で一緒なんですけど、
使っているとリソース参照が動かないんですよね。
テラフォームのIDでリソースを解決してたので。
っていうのがあって、
それでですね、CDKスタックにはエクスポーツとかアウトプットっていうのがあって、
CDKの方から値を外から見れる形で参照できるっていう機能があるんで、
それを見に行けるようにっていうのを追加したりとかしましたね。
それはそうですね、やっぱりテラフォームだけじゃないんで使っている人たちっていうのは。
やっぱりインフラ面であったとしても、
テラフォーム以外のところの対応っていうところは若干意識しつつ、
ただメインはテラフォームみたいなところはあったりするんですかね?
エスプレッソに関しては。
テラフォームが一番扱いやすいですよね。
ずっとそれを想定して作ってきたというのはありますけど、
ただ何でもできるようになっていて、
例えばSSMパラメーターの値を参照するっていう機能もあるんですよね。
なので、例えばあるセキュリティグループの名前とIDっていうのを、
SSMパラメーターにインフラ側でなんとかして登録してさえもらえれば、
あとはアプリケーションからSSMの名前だけを見に行けばいいみたいにできるので、
そうなるとインフラ側としては、
とアプリケーションが逆にもっと完全に切り離されるようになりますね。
TFステッドってどうしてもインフラの持ち物なので、
権限的に見せたくないとか、
あとは関係ないクレデンシャルも入っているから、
アプリケーションには見せたくないみたいなことが結構あって、
そういうのは別の仕組みでさらに外せるようになってますね。
なるほど、S3の権限がもらえないパターンもあり得るってことですかね、
考えないといけないパターンとしては。
そうですね。
なるほど、確かにそれはありそうだなと思いました。
ありがとうございます。
なるほど、ありがとうございます。
Jsonnet導入とテンプレート記法との衝突
あとそうですね、以前藤原さん確かブログ書いたかなと思うんですけど、
テンプレートのところでJSONnetに対応したって話があったと思うんですけど、
この辺り変遷というか、どういう経緯でそうなったのかなっていうのを聞いていいですか。
はい、そうですね。
エスプレッソもRAMロールもなんですけど、
もともとそのJSONファイルをテンプレートしたものが、
JSONのIACの元ネタみたいになってるんですね。
というのは、AWSのAPIで取れるものっていうのがJSONでレンダリングできるからなんですけど、
これはちょっと一つ特徴というか、僕が作ってるものの特徴としては、
AWSのAPIが返してくるもの、
AWSのSDKで扱える構造体っていうのを基本的にそのままダンプしたものが
設定ファイルになってるみたいな作りになってます。
もうちょっと抽象化したものにするっていう作り方もあるんですけど、
例えばAWSのコンテナをデプロイするときに、
CPUとイメージとメモリと環境変数と、
そこら辺あればいいよねって言って、
自分で何か定義ファイルを自分で定義したものに値を埋めるとできますよっていう風に作れるんですよね。
そこからAWSのAPIのように構造を変換してAPIを叩けばできるんですけど、
それをやってなくて、
基本的にはSDKが提供してくれる構造体をそのままダンプしたものが
JSONのファイルになってるみたいな感じになってます。
これの用紙や詳はあって、
いいことはいっぱいあるんですけど、悪いこととしてはJSONなので、
人間がちょっと扱いづらいんですよね。
まつびかんまとかの問題もあって、
そういうところで若干扱いづらかったり、
エスケープがめんどくさいとか書くのがめんどくさい単にとかいろいろありますよね。
それを解消するのにいろいろ方法があるんですけど、
Googleの出しているJSONnetというものがありまして、
これはJSONの上位互換ですごく表現力の高いJSONみたいな感じですね。
例えば外部ファイルをインクルードできたりとか、
変数を定義できたりとか関数を定義できたりとか、
そういういろんな、あとは組み込み関数もいっぱいありますね。
そういうのを使うと、わりとプログラミング言語に近い感じで定義したやつが、
最終的には全部JSONになるんですけど、
JSONを出力するための言語というのがあって、JSONnetというのがあって、
これがJSONそのものも読めるので、
JSON部分的にJSONnetにできるみたいな特徴もあるという感じで非常に便利なんですよ。
これを扱えるようにしたくて、
最初はですね、外部で自分でJSONnetからJSONに変換して、
そのJSONをエスプレッソが読んでデプロイみたいなワークフローを組んでたんですよね。
そのうち、GoにGoJSONnetというライブラリがありまして、
これ今はもうJSONnetの本家なのかなと思うんですけど、
Goのアプリケーションの中からJSONnetをライブラリとして呼べる、
単独のコマンドではなくですね、みたいになっているので、
それをエスプレッソに組み込んでしまえば、
エスプレッソがJSONnetをそもそも読み込んでレンダリングして、
デプロイまでワンバイナリでいけるようになるので、
そういう機能を入れたんですよね。
それも便利になったんですけど、
たまに便利にしたつもりが壊れたというか、
うまくいかなくなっちゃったこともやっぱりありまして、
JSONnetとして変換してからJSONにするのか、
最初ってテンプレート機構で文字列テンプレートの置き換えがあったんですよ。
だいたいイメージのタグとか、そういうよく変わる部分っていうのは、
環境変数にしておいて、デプロイ時に外から環境変数で与えるとテンプレートを書き換えないで、
テンプレートそのままデプロイできるっていうのが元々の仕組みなんですけど、
JSONを文字列テンプレートで展開するっていう仕組みが最初になったんですね。
それとJSONnetを組み合わせると、
変換順のせいでうまく動かないっていう問題が出てきちゃうことに、
入れた後に気づいて、これはどうしようもないなとなってですね。
だからJSONnetなんだけどテンプレートも使えるみたいな、
あいのこみたいな状態になっちゃった。
でもあれですよね、やりたいことはどっちも似てるというか、かぶってますよね。
かぶってますね。
テンプレート機構だけだとわかりやすいんですけど、
ちょっと凝ったことができないとか、文字列のところにしかうまく展開できなかったりするんですよね。
数値とかブルーの値がうまく展開できなかったりとかですね。
いろいろあって、とはいえ互換性は大事なので、
テンプレート機構もそのまま使えるようにしたいねってなって、
そういう組み合わせが悪かったみたいなことはありましたね。
最終的には解決できたというかですね、
JSONnet側に関数定義を、
Goの関数をJSONnetの関数として見せるみたいな仕組みが実はあって、
それを使うと、
環境変数展開がですね、
JSONnetには実はなくて、
もともとのオリジナルのJSONnetはないんですけど、
環境変数を展開する関数っていうのをエスプレッソが使えるようにしてやると、
全部JSONnetでできて、文字列展開がなくなるので、
うまくいくみたいな。
ついこれが解決できたのが2024年とかなんで、
作り始めてから7年後とかにやっと、
最終的にうまくいったみたいな物語はありました。
これって途中からJSONnetに機能追加されたってことなんですか?
そうですそうです。JSONnetも途中からですね。
なるほどなるほど。
それでやりたいことができるようになったから解決したんですね。
そうですね。
さらにJSONnetから顔をやった直後はそういう問題があって、
テンプレートとの組み合わせ問題があったんですけど、
それも最終的にはJSONnetで全部関数が書けるようになって、
解決したみたいな感じですね。
なるほど。
これって藤原さんが報告したとかではないんですか?
いやもうこれはアプリケーションの問題というか、
使い方の問題なんで、
JSONnet自体には昔からネイティブ関数があったのかな。
僕は知らなかっただけだと思いますね。
なるほど。
あれですね、JSONnet。
なるほど。
藤原さんの使い方は?
文字列で一回のテンプレートですね。
文のテキストテンプレートを使ってたんですよ最初。
それでその文字列で雑に置換するやり方と、
JSONnetみたいに綺麗にこう分解されてから動くやり方を混ぜると、
ぶっ壊れるみたいな。
簡単に言うとそういう話ですね。
そうですね。
最初は良さそうだけど混ぜると微妙に変なことが起こったときに、
解決方法を確かに分からなそうだなって思いますね。
そうなんですよね。
なるほど。
ありがとうございます。
ECSとLambdaのAPI変更への追従
そうですね。
なんか最近の変化っていうのはありますか?
最近なんかこういうことあったよとか。
それで言うと、
ECS側が結構変わっていて、
ECSのデプロイって昔ロールバックができなかったんですよね。
ロールバックできないってどういうことかって感じがあるんですけど、
できなくて本当に。
ロールバックしようと思うと、
1個前の定義を自分でアップし直してそっちに差し替えろみたいなことしかできなかったんですよずっと。
で、それがですね、
去年ぐらいですかね、
2025年ぐらいから、
もうちょっと前かな。
ECS側にいろいろデプロイのライフサイクルがちょっと変える概念が追加されたりとかしてですね、
そこら辺が結構内部的に変わってきたんですよね。
それでネイティブなロールバックAPIっていうのができて、
進行中のデプロイをAPI叩くと止められますみたいなのもできたりとか、
あとそれの例ですね、
昔はコードデプロイ使わないとできなかった、
ブルーグリーンだとかカナリーとか、
そういうこともECSをネイティブでできるようになるために、
いろいろこの概念が裏で拡張されてるんですよね。
ここ数年。
で、それについていくというか、
上手いことを辻褄合わせるのが若干大変かなというのがありました。
なんかね、新しい概念が増えるんですよ。
デプロイメントとか、
見た目はマネコンで見てるとあんまりわかんないんですけど、
裏では実は別の概念が増えていって、
デプロイの概念が内部で差し替わってるみたいな感じになってまして、
そうするとAPIを直叩きしている側としてはですね、
若干叩き方が変わってくるなみたいなところがあって、
そういうことがありましたね。
なるほど。
いや、確かに自作してるとそういうところも考えないといけないですよね。
これはでもRAMロールにも同じことがあって、
昔はAPI一個呼ぶと即座に反映されますみたいな素朴な感じだったんですけど、
ある時からですね、APIを叩いてそのステートがちゃんとステーブルになるまで
自分で待ってから次の操作をしないとエラーになるよみたいになったんですよね。
整合性が、ちゃんと整合性を取るタイミングが決まったみたいに、
途中から変わってRAMのAPIの使用的に。
なので、今までは叩きっぱなしでポンポンと2個叩いて終わりって言ってたのが、
ちゃんとそのステートが変わるのをボーリングしながら見て、
次に進むみたいなことを内部でしなくちゃいけなくなったりとかして、
やっぱりここら辺は動的な部分、デプロイの裏で実際のクラウド側のコントロールプレーンとかデータプレーンが
強調してガチャガチャとステートを変えていくところなんで、
これは裏でAWS側が変えてくるところがあるんですよね。
そういうのもやっぱり影響は受けますね。API読んでる方としても。
なるほど、そうですね。
管理画面使ってたらほとんどの人は気づかないですよね。
そうですね。管理画面も多分同じようなことをやっていて、
どうせ対応はしてるんですけど、それはあんまり見えないんで画面だと。
なるほど、そうですね。やっぱり内部のAPI叩いてると、
まあまあそれはそれで辛いことたくさんありそうだなと思ってます。
AI対応とREADMEのバイナリ埋め込み
なるほど、他何かありますか?最近の変化とかは。
最近はそうですね、でもちょこちょこと機能を足したりはしてますね、やっぱり。
サブコマンドがひっそり増えてて、マイナーバージョンがちょこちょこ上がったりとかそういう変化はありますけど。
そういえば最近これ使ってる人いるのかなと思うんですけど、
AI対応をちょっとやろうと思って。
AI対応っていうのはですね、AIってCLはよく使うじゃないですか。
コーディングエージェントとかに使わせると。
ただその使い方をちゃんと公式のやつを読んでくれなくて、
ウェブ検索で読んできたやつでやろうとしたりとか、
最新のやり方をあまり知らないとか、
あとヘルプだけだと情報が足んないみたいなこともあって、
なのでその使い方をちゃんと説明してあげたほうがいいんじゃないかと思ってですね。
エスプレッソにそのDocsコマンドって言って、
readmeを全部バイナリーの中に同梗して、
グレップとかも簡易的な全文検査もできるようにして、
そうするとエスプレッソDocsを叩いて、
使い方を調べてねっていうようにやっておくと、
AIに指示を与えておくと、
エスプレッソを使うときにそれを見て、
今使ってるエスプレッソのドキュメントを読んだ上で何かやってくれるはずと、
いうような機能を足しましたね。
なるほどなるほど。
実際手元で使ってみた感じですか?
手元で実装した後にいろいろ使ってみたんですけど、
やっぱり最新情報がですね、
そのバイナリーにそのバージョンのreadmeが埋め込んであるので、
最新の情報が確実に読めるんですよね。
だから追加したばっかりの機能とかもそれで見つけられるので、
ウェブ検索とかに頼られて、
古いのを見てそんな機能あるのみたいになることあるんですけど、
それより全然確実にやりたいことをやれるようになっているような感じがしますね。
なるほど。
確かに結構僕も嘘つかれたことたくさんあるんですよね。
なんかそんな機能はないって言われて、
いや最近足されたんだよねみたいなことを自分が言って、
やっと信じてくれるみたいなのも結構経験あるんで、
やっぱエスプレッソみたいにいろいろ細かい機能も足してますってなると、
この最新のreadmeちゃんと内部で入れておくっていうのは結構大事そうですね。
そうですね。
仕組み的としては単純で単にGoのエンベドでバイタリーの中に丸ごと埋め込んでるだけなんで、
単純なんですけど効果はあるんじゃないかなとは思ってはいます。
ちなみにDocsとスキルも提供してるのかなと思うんですけど、
エージェントスキルですね。
その何か差分とかあったりするんですか?
スキルはですね、普通にテキストで書いてるだけなんですよね。
これもテキストで書いてるんですけど、
これはソンムーさんという人が作ってるSkillsmithというライブラリーがあって、
これを使うとSkillsコマンドっていうのが生やせることができて、
そのスキルをうまくエージェントにインストールするとかを勝手にやってくれるみたいなのがあるんで、
それもちょっと入れてですね。
スキルにはだからDocsを読むと書いてるんですね、要するに。
基本的には。
例えばJSONnetのほうがオススメだよみたいな、若干僕の好みが入ってますね。
JSONとJSONnet両方使えるんですけど、
やっぱり昔からのある記事は全部JSONで書かれていて、
JSONテンプレート記法は結構今でもよく見るんですよね、新規の記事でも。
これはやっぱり記事が多いっていうのと、
そういう性もあるんだなと思って、
スキルのほうは今はJSONnetのほうがオススメですよみたいなことも入れて、
そっちのほうが確実にきれいに書けるんで、みたいなことも入れてたりしますね。
いいですね、スキルのほうでDocsを見ろって書いてあるの、なんかいいなって。
頭いいなと思いましたね、単純に。
あとはデプロイする前にDiffを見ろとか、デプロイする前にVerifyしろとか、
そういう運用上こうやったほうがいいよみたいなことをさらっと書いてあるっていう感じですね。
いいですね。
なるほど、スキルのほうはベストプラクティスみたいな感じなんですかね、意味合い的に。
作者がオススメしたいベストプラクティスを強制できるってすごいいいですよね。
やっぱりGo界隈でも結構Go自体も古いコードの書き方されちゃうから、
やっぱりAIが古いコードのほうが学習してるみたいなのがあるので、
それをどうするのかって今結構ホットな話題だと思うんですよね。
その辺やっぱり作者がオススメの使い方にどんどんAIに教えて強制させていくっていうのは、
これからどんどん注目されていきそうですよね。
そうですね、Goだと最近Go Fixが入って、
あれは結構アグレッシブに古い書き方を新しい書き方に書き換えちゃいますよね。
そうですね。
僕は自分のプロンプトに入れてますね、Go Fixしろって入れてるんで、
何をやっても常にGo Fixを当てるようになってますけど、うちのクロード君は。
そういう機械的にやるといいよっていうのをちゃんと公式が提供するっていうのはいいんじゃないかと思いますね。
いいですね。自分もちょっとやってみようと思いました。ありがとうございます。
ecspressoインスパイアツールの登場とラーメンに例える話
そうですね、最後に何か他に最近面白いことあったよとか何かありましたか?
そうですね、面白いことというと、これは社会的な話なんですけど技術的な話というよりは、
僕はですね、エスプレッソを作った後、ラムロールって言ってそのラムダ版を作ったりだとか、
なんでしょうね、あとはクラウドフロントファンクションズって言って、
クラウドフロントの上で動くエッジファンクションとかもあるんですけど、これのデプロイツールも実は作ったりだとか、
あとはさくらのクラウドというのがありますけど、僕今さくらにいるんですけど、
さくらのクラウドのコンテナサービス用のデプロイツールを作ったりだとかしてですね、
エスプレッソのなんとか版みたいな、なんとか向けみたいなものを自分でいっぱい作ってたんですよね。
これはなんていうか、そういうのが自分が好きで使い勝手が良いと思ってるから、自分の使うものを作るっていう感じで作ってたんですけど、
これがですね、なんか最近エスプレッソのAWSバッジ版を作りましたよっていう人が、
僕はエゴさしてるので、発見しまして、しかも独立で2名全然違う実装を作ってるんですよね、
同じAWSバッジ用のデプロイツールを。
それを見るとエスプレッソインスパイアってちゃんと書いてあって、
エスプレッソのAWSバッジ版ですよみたいなものを作ってる人がいるということに気がついて、
これがなんでかっていうとAIがあるからなんですけど、
AIに頼むとできるんですよね、割とね、今は。
昔は多分僕ぐらいしか作ってなかったんですけど、
僕とですね、前職、前の会社の同僚は真似して作ってたりしましたね。
そういう感じで割と作るのって結構大変じゃないですか、こういうのも。
そうですね。
なんだけど今はAIがあるから、エスプレッソと同じようになつかいがってで、
こういうこれこれこういう風なデプロイツールを作ってくださいっていう頼み方ができるようになったと。
そしたらみんな作り出してですね、あとGoogleのなんだっけ、
クラウドファンクションズ?
Googleクラウドファンクションズはそうですね、ラムダっぽいやつですね。
あれ用のやつも作ってる人が出てきてですね、
なんかみんないろいろ作れるようになってきたなと思って、
これはすごい面白いなという感じがしますね。
なるほど。
なんかね、エスプレッソを聞き写してるわけではないんですよ。
意外と中をさらっと読むと、例えばCLIパーサーとか、
フラグパーサーとかは全然違う実装を使ってて、
僕が好みで使ってるやつとは違うやつ、
多分その人が好きだったやつかもしくはAIが選んだやつかわからないですけど、
を使ってたりとかして、だから内部の実装とかは全然コピーではもちろんなくて、
独立にできてて、で、唯一TFStateLookupは使われてますね。
これはさすがに便利なので、TFStateを見に行くっていうか、
ユースケースがとてもよくあるので、AWS上だと。
これは使ってるんですけど、あとは割と好きに作られてる。
コマンド体系も似てるし、なんかそういう全体のテイストは似てるんだけど、
別実装、完全にコピーではない独立した実装みたいになってて、
これがまあ面白いなっていう感じですね。
いいですね。そういうエッセンスがどんどん引き継がれているというか。
そうなんですよ。
これはエスプレッソのUXというかDXがとても素晴らしかったから、
それが引き継がれているような形なんですかね。
そうだと思いますね。こういう体験が良かった。
エスプレッソを使ってみて、こういう体験が良かったけど、
これ用のツールがないので、じゃあ同じようなのを今なら作れるなって言って
作られたっていう感じがあって、非常に面白いなと思ってます。
なんか面白いですね。共通言語になっているのが面白いですね。
そうですね。これね、何かに似てるなと思って色々AIと壁打ちしながら問んでたらですね、
これはラーメンであるという結論に達して、
家系ラーメンとか二郎系ラーメンってあるじゃないですか。
あれって本家がいて、本家の直系みたいな店があって、
要するにそこで修行した人たちが出してる店とか、
のれんわけみたいなその関係の濃いやつがあって。
で、あとインスパイア系ってのがですね。
ありますね。
テイストは似てるし、割と同じような見た目だし、
同じような味とか構成要素も似てるけど、
全く血縁関係はない。
横からインスパイアして同じようなものを作り上げたみたいな派閥があってですね。
これはだから今年に入ってから色々出てきた。
これはインスパイア系だなと思って。
そういう家系ラーメンとか二郎系ラーメンみたいな一つのジャンルとして
エスプレッソみたいなものっていうのがある程度認知されたのかなと思って、
すごい面白いなって思ってます。
めちゃくちゃいいですね。
藤原家ができてるってことですよね。
僕の元同僚とかは直系というかのれんわけ系で、
全く面識ない人が作ってるやつはインスパイア系だなと思って。
確かに。
今の話で言うとAIができてきたから、
作りやすくなってきたみたいな話なんですけど、
最近OSSでよく聞くのがAIスロップって呼ばれるような問題。
デプロイツール設計における考慮点とOSSのあり方
言い方いろんなのあるかもしれないですけど、
AIでプルリクを爆撃してくるみたいなのも結構聞くなと思うんですけど、
藤原さんが管理してるようなOSSとかってそういうのあったりするんですかね。
いや、それはないですね。
AIが作ったプルリクがきますし、
何しろ僕がAIでそもそも機能とか追加してるのが見えてるから、
ここにはAIで作っていいんだなと思ってるんだろうから、
普通にクローズコード書きましたみたいなやつのプルリクとか来るんですけど、
それはただまともなバグフィックスだったり、
まともな機能追加だったりしますね。
じゃあなんか爆撃的なものは今のところはない?
ないです。
素晴らしい。
これはそこまでメジャーではないというか、
フレームワークみたいにちょっと利用者が多いとあるのかもしれないですね。
なるほど。
デプロイツールだからみたいな、ちょっとニッチな領域だからっていうようなところもあったりするって感じなんですかね。
多分あると思います。治安はいいですね、今のところそういう意味では。
じゃあなんか今から藤原さんが他のデプロイツール、
例えばさくらんのやつ作ったっておっしゃいましたけど、
今からデプロイツール設計するときにこういうの気にするとか、
ここはちょっとこうしたいなとかそういうのってありますか。
そうですね、デプロイツールも僕は型をある程度決まってしまったので、
あれなんですけど、
僕はプロフェッショナルとして運用する立場でもあるので、
結果がちゃんと予測できるツールがいいですよね。
なんかよくわからないけどガチャガチャした逆に壊れましたみたいなことは辛いので運用していると。
なのである程度明示的に多少手数が多くても、
結果と自分のやった変更が繋がって見えるようなものっていうのはやっぱりいいかなとは思いますね。
これはいろいろですよね、全部オールインワンでやってくれて、
細かいところを全部隠してくれて、
なんとなくやるとなんとなくうまくいくみたいなツールが必要な人もいますし、
欲しい人もいるんでしょうけど、
僕はそういうのがあんまり好まないので、という感じはありますね。
そういうツールが好きで作るかなとは思います。
そうですね、今回エスプレッソ、トラムロールの話聞けて、
いろいろ運用上でどうしても必要になった。
一番最初におっしゃっていただいたインフラとアプリケーションを、
チームが別々、会社も別々で、
というところからエスプレッソが生まれたというところがかなり印象的だったなと思っていて、
そういう運用が裏打ちされるというか、
実際にやっていく中で作っていくものっていうのが、
結局、さっきの話でもあった通り、
DXがいい感じなのでどんどん乗り分けしていく、
インスパイアされていくみたいなように結果的につながっていくのかなというのが、
聞いていた範囲で感想としては持ちました。
ありがとうございます。すごい面白いお話でした。ありがとうございます。
公式ツールって割と全部をカバーしようとするけど、
それを多分中の人使っているの?みたいなツールが結構あるじゃないですか。
中の人絶対これでデプロイしてないでしょうみたいなデプロイツールが公式が出てきたりするんですけど、
でも簡単ですよみたいな。
それは何かこう、何でしょうね、狙っているものが違うというか、
例えば初心者を取り込めみたいなこう何というか市場命題があり、
なので簡単に見えるけど実は使い込んでいくとだんだん不満がたまっていくようなものとかが出てきがちなんですよね。
公式の方が逆に出てきがちだったりするみたいな力学があるかもしれなくて、
そういう意味ではやっぱり自分で使っている人が日々の道具をちゃんと、
こういうものが欲しくてこういうものが便利なんだっていうのを自分らで作っていくっていうのは非常に大事かなと思って、
公式だからいいわけではないし、あとね公式だからメンテされるわけでもないんですよね。
非常に重要なところですね。
公式だけど数年でメンテ放棄されましたって言うOSSはとってもよくあるので、
なんであっても放棄されるときは放棄されるんで、
そういうときに逆にオールインワンだったりすると外しづらかったりとかですね、
乗り換えがすごい大変になっちゃったりするんで、
なので僕は割と小さなツールを組み合わせる派閥というか、そういう作り方を好むので、
そういう意味では今のAI時代なんで作りたいものは結構作れるんで、
そういうときにちゃんと節度を持ったものを作るって大事かなと思いますけど、
外せなくなっちゃうようなものを組み込んじゃってメンテしていけなくなると本当に外せなくなってギャーってなると思うんで、
そういう意味ではエスプレッソみたいなツールの作り方みたいなことを念頭に置くと、
多分何かがあったときに切り替えやすいとか、そういうメリットも出てくると思うんで、
そういう作り方を僕は好みますっていう感じですかね。
なるほど。
そこから学べることって小さく作るだったりとか依存を少なくするみたいなところなんですかね、できる限り。
そうですね、依存は意外とエスプレッソ多いのでいろんなライブをしてるんですけど、
なんていうか関係性の持ち方ですよね。
これは置き換えられるんだったら別に依存してもよくて、置き換えられないものに依存しちゃうと本当に依存関係になってしまうので、
そこの見極めみたいなところが大事かなとは思います。
はい、ということで今回ここまでにしたいなと思います。
改めまして藤原さんありがとうございました。
ありがとうございました。
今回ここまでにしたいと思います。
YaoYao'sのOSSでは毎回一つのOSSを取り上げて、
それについてカタツイというヘンテコで技術的なところも深掘りしながら話をしていく番組になっています。
今回みたいな形でちょこちょこゲストの方をお呼びしてお話しできればなと思っておりますので、
今後もよろしくお願いします。
ぜひお聞きのプラットフォームでフォローと高評価の方お願いします。
またこのOSSについて取り上げてみてほしいみたいなのがありましたらコメントとかで教えていただけると非常に嬉しいです。
番組についての感想もお待ちしております。
もしゲストで出てみたいみたいな言い方がありましたらぜひコメントいただけると検討させていただきますのでよろしくお願いします。
Xなどでつぶやく際にはハッシュタグYaoYao'sのOSSをつけてください。
それでは今回もありがとうございました。
ありがとうございました。
ありがとうございました。
