🗒️

[メモ] 構成ファイル/DSL/IaC

2023/06/29に公開

tl;dr

この記事は未完成です。
世の中にあるDSLや構成ファイルといわれるものについて、調べたメモです。
社内の勉強会の為に作りました。
あとちょっとだけIaC周りの各プロダクトの取り組みについても(ほんとちょこっとだけ)書いています。

目的

  • 構成ファイル周りの今をざっとおさらい
  • ツラミを共有使用
  • 株式会社DSLのCTOとしてどの未来にべットすべきか考えてみよう!

DSL/構成ファイルとは

  • Data Serialization Language
  • Domain Specific Language
  • Configuration file format

ややこしいのは2つの異なる言葉の略語が同じ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

https://github.com/bevry/cson
Coffee Script版JSON

JSON5

https://github.com/json5/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するまでわからない
    • 型ほしいときある
    • duration5mと書く? timeYYYY/MM/DD/hh/mm/ssと書く?
  • 依存関係が追いにくい
    • depends_onはまだいいほう
  • UIとの差異
    • UIから容易に想像しにくい
  • "本物"のExampleがない
    • 実際に本番で動いている構成は誰も公開しない
  • デバッグ
    • しにくい
    • 宣言型言語のデバッグ方法ってなんだ?
    • 手続き言語のステップ毎のデバッグとか
    • そもそも宣言型言語ってどうやって読み込まれてるのか知らない

いろいろな試み

StrictYAML

https://github.com/crdoconnor/strictyaml
https://github.com/crdoconnor
によって作られたYAMLのサブセット
YAMLの様々な型問題を解決するためにできた。「うんうん」とうなずいている自分がいる。

Protobuf

  • ここではprotobuf IDL(Interface Description Language)を指しています。
    割愛

Jsonnet

https://github.com/google/jsonnet
Googleが作ったJSON拡張

  • ちなみにSonnetとは「1編が14行から成る詩型」のこと
  • コメント
  • 参照
  • 演算と条件演算子
  • 配列とオブジェクトの構築
  • モジュール
  • 関数
  • ライブラリもまあまあある

HCL

HashiCorpが作った
https://github.com/hashicorp/hcl#why

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

https://pkg.go.dev/text/template

  • Go言語標準のDSL
  • Helmでお世話になるやつ
  • 個人的にはめちゃ辛い。そんなことない?

CUE

https://cuelang.org/

  • 期待の新生(といっても話題になってから結構経つ)
  • 色々な機能をコンパクトにまとめたやつ
    • スキーマ
    • バリデーション
    • スクリプト
    • ポータビリティ(JSON、YAML、OpenAPI、Protobufなど)

Kustomize

https://kustomize.io/

  • パッチを当てる
  • OOPの継承に似てる(辛くなりそうな未来が見える)

jsonnet-libs/k8s

https://github.com/jsonnet-libs/k8s

  • k8sのjsonnetライブラリ
  • そりゃ誰か作るよね!ってやつ

Ksonnet

https://github.com/ksonnet/ksonnet

  • プロジェクトはすでに終了

ArgoCD ApplicationSet

https://zenn.dev/kassshi/articles/argocd-applicationset

今どんな感じ?

k8s

YAML

Helm

Go Template

Terraform

もちろんHCL

Github Actions

YAML

Daggar

CUE, Go, Python

OAM

Open Application Model
全てYAMLで管理しようぜ!

実装はCrossplane

Plumi

https://www.pulumi.com/product/
やっぱりもう書きやすい手続き言語で書こうぜ!

私たちが本当にほしいのはこれなのか?

https://www.pulumi.com/ai/

Discussion