GCP Workflows チョットワカッタ
概念としては、
Batch はスケジューラというか、これこれこういうスペックのマシンでこういうスクリプトを都合いいときに実行してくれる屋さん
コンテナをランタイムとするパターンと、GCE をランタイムとするパターンがあり、今回は後者を使う
Workflows は GCP の API を数珠繫ぎにしたり、並列実行したりなんだりできて、Cloud Scheduler で Workflows にランタイム引数を渡してあげると、最終
yaml が錬成されて、それをステップ実行してくれる屋さん
GCP の API であれば割と柔軟性は高そうで、今回は Batch の api を yaml に書いて batch をキューに追加して実行する〜てな yaml を書けば OK だった
まずは Batch でどんな感じでタスクが実行されるのかいろいろ確認してたのだが、コンソール上でディスクをマウントするオプションはあるのだけど、GCE でやりたいってのはいろいろ下ごしらえをしたイメージをブートしてやりたいので、どーすりゃええねんとなった
正解は、GCE のイメージってところで「イメージを作成する」ってのをやると、実行中(一応インスタンスはシャットダウンしてある)の GCE の VM からブータブルのイメージを作成してくれて、これを allocationPolicy.instances[].policy.bootDisk.image に設定してやると下ごしらえしたイメージから起動できた
んでもってコンソール上ではこのオプションは存在してなくて、ローカルで json ファイルを作成して gcloud で submit して動作確認ができた
Workflows で扱う時は結局この API の形が再利用できる
同様に policy.provisioningModel を SPOT にするとスポットインスタンスで起動してくれるらしい。どれぐらい安いのかはわからん
あとデフォルトだと e2 の highCPU 的なやつが立ち上がってきて、そんなにいらないので policy.machineType にほどほどのスペックを指定してやればよかった
あとはまあ、Workflows のシンタックスリファレンスを読みつつ、久々に yaml をがんばって書いた
yaml で困ったのは、今回ちょっとめんどい話で
script.text にシリアライズした
JSON をコマンドの引数として渡したいというのがあって、さらに Workflows のランタイム引数もとるので
${"hoge \"" + foo + "\" {\\\"hoge... みたいな、嵐のようなバックスラッシュを連打させられたという
あとは yaml なのか GCP のパーサの問題なのかわからんが、Expression のダブルクォートの中に : が含まれてると壊れるという問題もあって、init.assign 以下に逃がしてあげて、シングルクォートで定義して、変数として指定する、というアホな解決法で乗り切った
今回 GCE 起点でいろいろサービスを経由したりキックしたりする感じのことをやったのだけど、個人的にかつて
IFTTT とかでパイプ処理みたいなピタゴラ装置を作ってきたので、こうしていろいろなサービスをオーケストレーションするのは楽しい
ただ....yaml を書くのが楽しいかというとそういうわけではないのだけど....
