[メモ] 構成ファイル／DSL／IaC
tl;dr
この記事は未完成です。
世の中にあるDSLや構成ファイルといわれるものについて、調べたメモです。
社内の勉強会の為に作りました。
あとちょっとだけIaC周りの各プロダクトの取り組みについても（ほんとちょこっとだけ）書いています。
目的
- 構成ファイル周りの今をざっとおさらい
- ツラミを共有使用
- 株式会社DSLのCTOとしてどの未来にべットすべきか考えてみよう！
DSL／構成ファイルとは
- Data Serialization Language
- Domain Specific Language
- Configuration file format
ややこしいのは２つの異なる言葉の略語が同じDSLだということ。しかもシリアライズ目的の言語が構成ファイルとして使われていたりする。分かりにくすぎると思うのですが、どうですか？
構成ファイルってなに？
Apacheのhttp.confのこと。あれみて、プログラミング初心者はオレオレサーバー断念する。
生のDSL
勝手に「生」という言葉を使っているが、英語のrawみたいな意味で適当に私がつけただけです。
INI file
これ
[Files]
one=Hello
two=3.14
[Item]
user=Henry
- Windowsアプリの挙動を変えようとして、このファイルがいっぱいあるフォルダまで来たら引き返すやつ
- 階層データを表現できない。
- 今見たらTOMLににてるな
XML
- 読みにくい
- 配列なし
- SIer時代よく見たなーというイメージ
- SalesforceのSOAP APIをエクセルのVBAから叩いて表に出すみたいなことしてた
JSON
- Wikipediaによると2000年代前半にでてきたあらしい
- みんな知ってて、どこにでもいるやつ
- Date型なし、（バイナリ型なし）
- コメント書けない
Better JSON
CSON
Coffee Script版JSON
JSON5
YAML
- yet another markup language <- この命名みんな好き。世の中のモノは基本Yet anotherだろ。
- 読みやすい
- インデント形式では、構文エラーや検証エラーが発生しやすい。
- JSONのサブセットと言っている人もいる
TOML
TOML は、アプリケーションの構成やデータのシリアル化に使用される他のファイル形式 (YAML や JSON など) と特性を共有します。TOML と JSON は両方ともシンプルであり、ユビキタスなデータ型を使用するため、コーディングやマシンでの解析が容易になります。TOML と YAML はどちらも、特定の行の目的を理解しやすくするコメントなど、人間が読みやすい機能を重視しています。TOML はこれらを組み合わせる点で異なり、(JSON とは異なり) コメントを許可しますが、(YAML とは異なり) 単純さを維持します。
構成／設定ファイルの辛いところ
ここで、ツラミを考えてみよう。
- DRY(Don't Repeat Yourself)違反
- 同じキー何回も書く
- どれを設定したらいいのかわからない
- Required, Optionalわからん
- プログラミング言語の関数だったらIDEで分かる
- 宣言元に飛べない
- HelmとかKustomizeとか最終的なyamlをみて、どこで設定されたのかわからない
- 説明がない
-
cpuは分かる。pspEnabledはなんだっけ？ググるしかない
-
- 項目ごとの依存関係がわからない
-
foo.enableしたらfee.setupは無視される。そうなんだ
-
- バリデーションがない
- 結局設定をapplyするまでわからない
- 型ほしいときある
-
durationは5mと書く？timeはYYYY/MM/DD/hh/mm/ssと書く？
- 依存関係が追いにくい
-
depends_onはまだいいほう
-
- UIとの差異
- UIから容易に想像しにくい
- "本物"のExampleがない
- 実際に本番で動いている構成は誰も公開しない
- デバッグ
- しにくい
- 宣言型言語のデバッグ方法ってなんだ？
- 手続き言語のステップ毎のデバッグとか
- そもそも宣言型言語ってどうやって読み込まれてるのか知らない
いろいろな試み
StrictYAML
によって作られたYAMLのサブセット
YAMLの様々な型問題を解決するためにできた。「うんうん」とうなずいている自分がいる。
Protobuf
- ここではprotobuf IDL(Interface Description Language)を指しています。
割愛
Jsonnet
Googleが作ったJSON拡張
- ちなみにSonnetとは「1編が14行から成る詩型」のこと
- コメント
- 参照
- 演算と条件演算子
- 配列とオブジェクトの構築
- モジュール
- 関数
- ライブラリもまあまあある
HCL
HashiCorpが作った
Whereas JSON and YAML are formats for serializing data structures, HCL is a syntax and API specifically designed for building structured configuration formats.
JSONとYAMLがデータ構造をシリアライズするためのフォーマットであるのに対し、HCLは構造化されたコンフィギュレーション・フォーマットを構築するために特別に設計された構文とAPIである。
Go Template
- Go言語標準のDSL
- Helmでお世話になるやつ
- 個人的にはめちゃ辛い。そんなことない？
CUE
- 期待の新生（といっても話題になってから結構経つ）
- 色々な機能をコンパクトにまとめたやつ
- スキーマ
- バリデーション
- スクリプト
- ポータビリティ（JSON、YAML、OpenAPI、Protobufなど）
Kustomize
- パッチを当てる
- OOPの継承に似てる（辛くなりそうな未来が見える）
jsonnet-libs/k8s
- k8sのjsonnetライブラリ
- そりゃ誰か作るよね！ってやつ
Ksonnet
- プロジェクトはすでに終了
ArgoCD ApplicationSet
今どんな感じ？
k8s
YAML
Helm
Go Template
Terraform
もちろんHCL
Github Actions
YAML
Daggar
CUE, Go, Python
OAM
Open Application Model
全てYAMLで管理しようぜ！
実装はCrossplane
Plumi
やっぱりもう書きやすい手続き言語で書こうぜ！
私たちが本当にほしいのはこれなのか？
Discussion