Heat/Helm/Kustomize/Vagrant/Ansibleが気に入らなければもっと強力な道具を自前で書くことができるよ
-
TuvianNavy
- 860
- 1
- 0
- 0

フリーフォーマットじゃない(文脈自由言語じゃない)計算機言語ってトランスレータが作りやすい(単純字句置換だけで相当なことができる)という利点があるんだよなあ
2020-07-12 11:19:55
で、今は文脈の抽出自体はjqとかでできるから、予約語さえ定義できればフリーフォーマットじゃないのと同じことになる
2020-07-12 11:21:15
jq使う場合でも部分構文木の抽出(単一化)フェーズと構文木の代入・書き換え(生成文法の人が始終やってるやつ)フェーズは分けた方が判りやすいかなあ
2020-07-12 11:27:27
JSON上で定義するDSLの場合最終的なコード生成自体はbashとかの仕事になる場合が多いかな、ここが何かのバイトコードアセンブラになると面白いっちゃ面白い
2020-07-12 11:30:14
いやまあWebAssemblyあるのに他のVM向けコードとか吐く必要あるかっていわれるとアレだけど
2020-07-12 11:30:59
いやほんとjqとbashとアセンブラがあれば(見栄えがJSONなのはいかんともしがたいけど)任意の言語のコンパイラが書けるってことで
2020-07-12 11:32:59
トークナイザとパーザを書かないで済むかわりにJSONな見栄えになる、というのは用途によっては十分に引き合う
2020-07-12 11:37:11
まあMAX_SAFE_INTEGERを上回る大きさの数を扱うとかだとだめだけど、2^15を越えない整数しか扱わないDSLとかふつーにありそうだし
2020-07-12 11:41:46
まあ何が言いたいかというとHeat/Helm/Kustomizeが気に入らなければもっと強力な道具を自前で書くことができるよ、という話
2020-07-12 11:53:54
devopsでオレオレDSLを使いたい場合、最適化フェーズ(主に体系化されたVM名の生成と機能の割り付け)とコード生成フェーズ(docker startとかが「1命令」)の中身を理解して書けるのはインフラの中身を知っている人間だけなので
2020-07-12 12:03:09
curlでレジスタをロード/ストアし、dockerやgitやsshでアドレスを持たない特殊なI/Oを行う、というのがクラウドインフラの「機械語レベル」の操作になる
2020-07-12 12:05:26あとkubectlとかVBoxManageとかgovcとかawsとかgcloudとか

計算機としてのクラウドインフラが極端にヘテロジニアスかつアドホックなアーキテクチャなので、「機械語」も極端にヘテロジニアスかつアドホックなものにならざるを得ない
2020-07-12 12:10:49
あとまあ、機械語そのものはチューリング完全である必要はないというか、むしろ積極的に条件分岐を排除する理由があって(curlが勝手にリダイレクトするとかそういうのはよしなにやってもらえばいいのだが)生成した「機械語」が例えばJSONの配列に並ぶとすると、それを読むのは人間であるし
2020-07-12 12:27:36人間も読む可能性がある、の間違い

それに実際生成したいのが「ある一連の作業の中で厳密にn回、ほとんどの場合は1回だけやればいい操作」が多い
2020-07-12 12:29:56
KubernetesのOperator的な閉ループ制御を行いたい場合にはもちろん「機械語」レベルで条件分岐が必要になるので、今議論しているユースケースからは外れる
2020-07-12 12:42:12
ただしこの閉ループを頻繁にカスタマイズするようであれば、定数を畳み込んだシェルスクリプトやgoのソースを「バイナリ」として出力する「リンカ」を書く必要があるだろう
2020-07-12 12:44:32
正直、カスタマイザブルなController/Operatorの仕様を脳が水滴奪って乾くレベルまで考えて書くよりその方が全然楽だし開発負担も小さくて済むと思う
2020-07-12 12:51:14