皆様、なかなか梅雨に入りませんね。調子を崩しやすい時期ではあるので、ご注意を。
さて、今日はまあありきたりな話で、S3のCreate ObjectからBatch走らせよう、と思ったのです。BatchにFargateジョブ定義して、ジョブキュー定義して、S3にEventBridge通知有効化して、EventBridgeでフィルタしてルール定義して。
まあ、問題なく実装して、さあテストです。問題なく動作します。
というかこの辺で躓くことはあまりないんです。
が。
良く躓くのが、AWSさんのAPIでのデータ仕様。ペイロードの中身。これが、API実装時期だとか、サービスの変化だとか、いろんな要素でちょいちょい統一性がない。
今回はS3トリガーなのでバッチ起動するFargateコンテナに当然発生したS3のオブジェクト情報を渡したいわけです。イベントメッセージに入ってるじゃん、とか思うんですが、相手先様のアプリケーションはイベント駆動で作られていないのと、APIエンドポイント叩くわけじゃないんですよね。
と、なればまあ楽に思いつくのはジョブのパラメータをオーバーライトすればいいじゃない。となるわけです。入力トランスフォームで変形してBatchに渡してやればいい。
で、さらっと検索するとParametersでやれ、というRe:Postがヒットします。しかし、PrametersはCommandに対するプレースホルダーである、と書かれています。
いやいやいやｗ
いちいちCMDでexport hoge=Ref::hogehogeとかやれと？ いやだよめんどくさい。環境変数あるんだからこれ書き換えたいよ。
というわけで似たような事例を探しに行きましたが、ふつうにありそうな事例だと思ってたんですが、なんかほとんど見当たらない。というかこんなんで躓くのが私だけなのか。
そもそもですね。
containerOverrides以下の仕様があっちこっちで全然違う。StepFunctionsから呼ぶケースや、昔のCloudWatchEventから呼んでいるケース、まあいろんなパターンの中でそれぞれがびっみょーに違う。
environment { “hogehoge”: “fuga” }だったり、Name: hogehoge , Value:fugaだったり、ContainerOverridesだったり、containerOverridesだったり、environmentだったりEnvironmentだったり、APIの仕様書読んだらcontainerOverridesはOverride {} の一要素だと書かれていたり、とにかく「どこから呼ぶのか」によって結構細かく違う。
そのうえで、呼び出し先が「どのようなペイロードを期待するか」でそれらの内容がさらに変わる。
これは、AWSではよくあることなのでまあ一通り調べていろいろやってみて、うまくいかなかったらさっさかサポートに聞く、ということも多いのですが、今回はまあ普通にみんなやってるでしょ？くらいにしか思ってなかったのであーだこーだとやっていました。
結局1日調べて（いろいろ組み合わせてテストして）もわからなかった（というか正解にヒットしなかった）のでサポートに聞いたんですが…。
なんかふと思って、Re:Postをまじめに読んでたら
{"Parameters": {"name":"test"}, "ContainerOverrides": { "Command": ["echo","Ref::name"] } }とありますので、containerOverridesはContainerOverridesでこの高さに入れ込むのが正解っぽい。テストしてみると動く。てこたぁあとはEnvironmentとKey-Valueの書き方だけだな！
というわけで。
{ "ContainerOverrides": { "Environment":[ { "Name": "Bucket" , "Value": <S3Bucket> }, { "Name": "Object" , "Value": <S3ObjectKey> } ] } }
みたいなことになって無事解決。いやー、ちゃんと最初に一番近そうな話題なんだからちゃんと読め、という話ですね。Parametersじゃねぇんだよ！ってなってさくっと読み飛ばした自分が悪いですね。
コンテナ定義部分はcontainerOverridesみたいな頭は小文字スタートがほとんどなんですが、どうやらここではキャメルらしい。とはいえ、これはEventの仕様っぽい書きっぷりのドキュメントもあって、これがEventの仕様なのかBatchがこうなのかはよくわかっていない。StepFunctionsから呼んでいるケースではキャメルじゃないので、なんとなくEventの仕様っぽいんだよなぁ…。
environmentもサービスによって{}だったり[]だったりで結構迷うｗｗｗ
とはいえ、この定義うっかりちょっと間違ってたりするとAWS Batchがリクエストを拒否ってしまうので、コンテナがそもそも起動すらしない状態になったりします。デバッグしにくかったです…。
※裏でBatchキュー用のリクエストボディに整形しているんだろうけど、きっちりフォーマット正しくないと変換がコケるんだろうな…。
いちいちCloudTrail見るのもねぇ…。
ということで解決したので開いちゃったサポートケースにはご報告だけして解決クローズ。AWSの中の人、アサインされて作業中になってしまっていてお手間かけてごめんなさい。
というわけで、まあまたこんどやるときにどうだったけなぁ？ ってなるのは間違いないので、メモ代わりに残します。
