CUE に入門する
概要
最近知った CUE という設定ファイル用の言語について入門する。json や yaml ファイルに置き換わるものとして注目されているらしい。
CUE をちゃんと入門したいなと感じたのは yaml と kustomize に明確なツラミを感じたため。とりあえずそれぞれの設定言語に対してのツラミはリストアップしてみた。
既存の設定言語に対する個人的なツラミ
json
見づらい
コメントが使用できない
最後の行のカンマは許容されない
yaml
インデントは辛い
python もかなり辛かったし、インデントが重要な言語はしんどいと個人的には感じている
go みたいに強制的に tab でインデントを入れられるみたいな感じなら心地よいんだけどな
k8s manifest において配列を書く際によく見られるようなのはとても見づらい
code:manifest.yaml
apiVersion: v1
kind: Pod
metadata:
name: app
containers:
- name: nginx # <- これ
image: nginx:latest
ports:
- 80 # <- これ
インデントが深くなってくると地獄
kustomize
CUE を本格的に使用するとなると kustomize が対抗馬となるかと思うので CUE の評価のために kustomize についてもツラミを書き出しておく
kustomize の設計的に少なくとも overlays と base についてはディレクトリを分割せざるを得ないため、kustomize の yaml を見ただけでは全体像が見にくい
patchesStrategicMerge の依存関係をミスると想定とは全く異なる設定ファイルが誕生する
kubectl apply -k が通らない場合は kustomize レイヤでのエラーの可能性も考えられるため、kustomize のキャッチアップについても多少は必要となる
というように現状は感じている・・・。それを解消しうるのは jsonnet ではあると思っていた。libsonnet を import するなどして共通部分を括りだして DRY に書けるのはとても良さそうとは感じていたが、値のバリデーションや import の規則などについては言語レベルでベストプラクティスがあるわけではないため、組織内でそのあたりのルールをある程度は決めておかないとあとから見たときにどの設定がどこにあるのかとても分かりづらいし無法地帯になりがちだと感じている。
というわけで既存の設定周りの言語について少なからずツラミを感じていたため最近知った CUE に入門しようと思う。
気になるところ
導入コスト
バリデーションとかスキーマとかは広く受け入れられるものであるかどうか
このあたりをちゃんとやろうとするとチーム内で CUE で書いた設定ファイルの設計思想が共有されている必要があると感じている
この思想が共有されていないとコードレビューで reviewer が author の PR に対して妥協をしたりであるとか、reviewer の指摘に対して author が ??? となってしまったりなどしてしまいそうな気がしている
コード生成
CUE がとても強力であれば既存の yaml や json についても CUE から生成したものを使用するというアプローチは考えられると思う。そのような運用が通用するのであれば、開発者は CUE 記法だけ認知すれば yaml / json 間でのスイッチングコスト的なものは無くなるとは思う
そもそも yaml / json にスイッチングコストがあるのかどうかは疑問ではあるが・・・。
例えば社内の CI や manifest の共通化は CUE のようなバリデーションが強力そうな言語を用いることでかなり良い感じに出来そうな気はしている
すでに強力なバリデーションがある言語においても CUE にリプレースする価値はあるのか
CUE の設計思想
ファイル構成等である程度の自由度がある言語についてはとりあえず設計思想を知り、その言語の設計思想に沿った設計を行いアプリケーションに落とし込むことがとても大切であると感じている。そうすることにより、最も美しいアプリケーションの設計になるだろうし、チームに新規メンバーが参画した際にもスムーズにキャッチアップができるだろうと考えている。