YAML को हम टेम्पलेट क्यों कर रहे हैं? (2019)

मूल लेख ↗ Hacker News चर्चा ↗

इंजीनियर तर्क देते हैं कि infrastructure और Kubernetes configs के लिए YAML को टेम्पलेट करना एक anti-pattern बन गया है: जो फ़ाइलें कभी साधारण declarative थीं, उनमें अब loops, conditionals, और vendor-specific DSLs जुड़ गए हैं, जिससे वे fragile “yaml-as-programming-language” प्रणालियाँ बन गई हैं जिन्हें validate, debug, और secure करना कठिन है। कई लोग TypeScript, Python, Ruby जैसी वास्तविक programming languages से JSON/YAML generate करना, या Jsonnet, CUE, Dhall, Nix जैसी purpose-built config languages का उपयोग करना पसंद करते हैं; अक्सर CDK, Pulumi, या Tanka जैसे tools के साथ, ताकि logic tested code में रहे और cluster को फिर भी plain manifests मिलें। इसके पीछे एक व्यापक चिंता है कि हर नया config format और template engine वही गलती दोहराता है—existing languages और types, schemas, तथा composition के लिए proper tooling को अपनाने के बजाय एक constrained language को फिर से invent करना।

YAML का उपयोग क्यों होता है और फिर उसे टेम्पलेट क्यों किया जाता है

  • टिप्पणी करने वाले इस बात से सहमत हैं कि YAML मुख्यतः जड़ता और परिचितता के कारण हावी है: उदाहरण और टूलिंग हर जगह हैं, खासकर Kubernetes और CI में।
  • लोग “बस एक साधारण YAML” से शुरू करते हैं, फिर कुछ variables जोड़ते हैं, फिर conditionals/loops, और अंत में एक de‑facto प्रोग्रामिंग भाषा बन जाती है।
  • docs और blogs से snippets को copy-paste करना एक बड़ा कारण है कि लोग उच्च-स्तरीय टूल्स की बजाय raw/templated YAML पर टिके रहते हैं।

YAML स्वयं पर आलोचनाएँ

  • कई लोग YAML को भ्रामक रूप से “human-friendly” मानते हैं: indentation नाज़ुक होती है, लंबे files में context खोना आसान होता है, और spec जटिल है।
  • type system और implicit conversions (जैसे no → false / “Norway” problem, 1.1 बनाम 1.2 के अंतर) बार-बार की जाने वाली शिकायतें हैं।
  • templated YAML को “stringly-typed programming” कहा जाता है: validate, debug, और reason करना कठिन, और vendor-specific semantics के साथ।
  • कुछ लोग छोटे से मध्यम जटिल configs और non-programmers के लिए YAML का बचाव करते हैं (जैसे front-matter, simple docker-compose), खासकर schema validation और linters के साथ।

Templating बनाम वास्तविक भाषाओं से generate करना

  • मजबूत मत: अधूरे template DSLs बनाना बंद करें; data structures बनाने और JSON/YAML emit करने के लिए TypeScript, Python, Ruby, Go, आदि जैसी वास्तविक भाषा का उपयोग करें।
  • बताए गए लाभ: libraries और tooling का पुन: उपयोग, type checking, unit tests, आसान refactoring, “dumb data” और logic के बीच साफ़ separation।
  • प्रतिवाद:
    • CI/IaC में arbitrary languages चलाने से attack surface और complexity बढ़ती है।
    • Config declarative और restricted होना चाहिए; full Turing-complete power spaghetti को आमंत्रित करती है और policy/validation को कठिन बनाती है।

वैकल्पिक config languages / systems

  • अक्सर उल्लेखित: Jsonnet, Dhall, CUE, Nix, Nickel, Starlark-based tools (ytt, Bazel/Starlark, Kurtosis), CDK8s, AWS CDK, Pulumi, Tanka, Kustomize।
  • राय अलग-अलग हैं: कुछ लोग functional, total, या type-safe configuration के लिए Jsonnet/CUE/Nix/Dhall को पसंद करते हैं; अन्य उन्हें बहुत niche, सीखने में कठिन, या libraries की कमी वाला मानते हैं।
  • कई लोग “types के साथ config as code” और compiled artifact के रूप में एक सरल, validated data format (अक्सर JSON, वैकल्पिक रूप से YAML में rendered) का सुझाव देते हैं।

Kubernetes, Helm, CI, और operators

  • Helm charts को व्यापक रूप से दर्दनाक कहा जाता है: text substitution, indentation juggling, खराब error messages, और values.yaml के माध्यम से Kubernetes features को फिर से expose करने की ज़रूरत।
  • कुछ लोग Kustomize या plain manifests पसंद करते हैं; अन्य तर्क देते हैं कि operators या higher-level CDKs, और अधिक YAML templating की तुलना में बेहतर abstraction हैं।
  • CI (GitHub Actions, आदि) के लिए, कई लोग minimal YAML की सलाह देते हैं जो सिर्फ real scripts को exec करे, और config files में जटिल logic से बचें।

कॉन्फ़िगरेशन दर्शन पर गहरी चर्चा

  • बार-बार उभरता विषय: “सारा config Turing completeness की ओर बहता है।”
  • बहस इस बात पर केंद्रित है कि logic कहाँ हो, config को कितनी power मिलनी चाहिए, और complexity बढ़ने पर systems को observable, testable, और maintainable कैसे रखा जाए।