YAML, समझाया गया: वो कॉन्फ़िग भाषा जो एक कविता की तरह दिखती है

एक लाइन में

YAML, स्ट्रक्चर्ड डेटा लिखने का एक इंसानों के लिए आसान तरीका है, जो अपने भाई-बंधुओं के कर्ली ब्रेसिज़ और कोट्स को छोड़कर, एक सलीके से बनी ग्रोसरी लिस्ट जैसी साफ-सुथरी इंडेंटेशन इस्तेमाल करता है।

ये कौनसी समस्या सुलझाता है

शुरुआत में, सिर्फ़ chaos था। फिर आईं कॉन्फ़िगरेशन फ़ाइलें। .ini जैसे शुरुआती फॉर्मेट आसान तो थे, लेकिन कॉम्प्लेक्स, नेस्टेड डेटा को हैंडल नहीं कर सकते थे। फिर आया XML, जो पावरफुल और स्ट्रक्चर्ड था, लेकिन इतना ज़्यादा शब्दों और टैग्स से भरा हुआ था कि उसे पढ़ना ऐसा लगता था जैसे IKEA का फर्नीचर कानूनी भाषा में लिखे मैन्युअल से जोड़ने की कोशिश कर रहे हों। इंसानों को इसे लिखना बिल्कुल पसंद नहीं था।

इसके बाद JSON (JavaScript Object Notation) आया और यह एक बहुत बड़ा सुधार था। यह हल्का-फुल्का था, ज़्यादातर प्रोग्रामिंग भाषाओं में डेटा स्ट्रक्चर्स से सीधे मैप हो जाता था, और XML की तुलना में आँखों को ज़्यादा सुकून देता था। लेकिन जिन फ़ाइलों को इंसानों को बहुत ज़्यादा लिखना और एडिट करना पड़ता था—जैसे कि DevOps स्क्रिप्ट्स, एप्लिकेशन सेटिंग्स, और इंटरनॅशनलाइज़ेशन टेक्स्ट्स—उनके लिए JSON का सिंटैक्स अभी भी एक बोझ जैसा लगता था। वो सारे कर्ली ब्रेसिज़, कॉमा, और कोटेशन मार्क्स विज़ुअल नॉइज़ थे और उनमें गलती करना बहुत आसान था।

और फिर एंट्री हुई YAML की। इसका नाम एक रिकर्सिव एक्रोनिम है जो इसकी भावना को पूरी तरह से दर्शाता है: "YAML Ain't Markup Language" (YAML कोई मार्कअप लैंग्वेज नहीं है)। इसे शुरू से ही एक खास ऑडियंस के लिए डिज़ाइन किया गया था: स्क्रीन को घूर रहा इंसान। इसने JSON जैसे ही बेसिक डेटा स्ट्रक्चर्स (की-वैल्यू पेयर्स, लिस्ट्स, और सिंपल वैल्यूज़) लिए और पूछा, "इसे दिखाने के लिए हमें कम से कम कितने सिंटैक्स की ज़रूरत है?"

जवाब था इंडेंटेशन। स्ट्रक्चर दिखाने के लिए व्हाइटस्पेस का इस्तेमाल करके, YAML ने एक ऐसा फॉर्मेट बनाया जो अक्सर इतना साफ़ होता है कि खुद ही सब कुछ समझा देता है। इसे कॉन्फ़िगरेशन की दुनिया के लिए बनाया गया था, जहाँ एक हाई-थ्रूपुट API की मशीन-ऑप्टिमाइज़ेशन ज़रूरतों से ज़्यादा ज़रूरी स्पष्टता और एडिटिंग में आसानी होती है।

ये अंदर से कैसे काम करता है

YAML का "जादू" सिर्फ़ इंडेंट किए गए टेक्स्ट को स्ट्रक्चर्ड डेटा में बदलने के लिए कुछ सरल, cohérent नियमों का एक सेट है। यह JSON का एक सुपरसेट है, जिसका मतलब है कि आप अक्सर एक मान्य JSON को YAML फ़ाइल में पेस्ट कर सकते हैं और वह काम कर जाएगा। लेकिन असली पावर इसके अपने, मिनिमलिस्ट सिंटैक्स से आती है।

बिल्डिंग ब्लॉक्स: स्केलर्स, सीक्वेंसेज़, और मैपिंग्स

YAML में सारा डेटा इन तीन चीज़ों पर आधारित होता है:

मैपिंग्स (Mappings) (या डिक्शनरीज़/ऑब्जेक्ट्स): ये आपके क्लासिक key: value पेयर्स हैं। key एक स्ट्रिंग होती है, और वैल्यू कुछ भी हो सकती है: एक और मैपिंग, एक सीक्वेंस, या एक स्केलर।
```
# A simple mapping
character: "Bilbo Baggins"
race: "Hobbit"
age: 111
```
सीक्वेंसेज़ (Sequences) (या लिस्ट्स/एरेज़): ये आइटम्स की एक क्रमित (ordered) सूची होती है। हर आइटम को एक हाइफ़न और एक स्पेस (- ) से दर्शाया जाता है।
```
# A sequence of strings
fellowship_members:
  - Frodo Baggins
  - Samwise Gamgee
  - Gandalf
  - Legolas
  - Gimli
```
स्केलर्स (Scalars) (या सिंपल वैल्यूज़): यह सिर्फ़ एक अकेली वैल्यू होती है, जैसे कि एक स्ट्रिंग, नंबर, या बूलियन। YAML टाइप का अनुमान लगाने में काफी स्मार्ट है। 123 एक नंबर है, true एक बूलियन है, और Hello world एक स्ट्रिंग है। आपको आमतौर पर कोट्स की ज़रूरत नहीं होती, लेकिन अगर आपकी स्ट्रिंग को गलत समझा जा सकता है तो आपको उनका इस्तेमाल करना चाहिए (उदाहरण के लिए, "true", "1.23")।

सीक्रेट मसाला: इंडेंटेशन और व्हाइटस्पेस

यह YAML में सबसे महत्वपूर्ण कॉन्सेप्ट है। नेस्टिंग दिखाने के लिए कोई ब्रेसिज़ {} या ब्रैकेट्स [] नहीं होते। इसके बजाय, आप बस इंडेंट करते हैं। नियम सरल है: यदि कोई लाइन अपने ऊपर वाली लाइन से ज़्यादा इंडेंट की गई है, तो वह उस लाइन की चाइल्ड बन जाती है।

आइए अपने बिल्डिंग ब्लॉक्स को मिलाते हैं। यहाँ एक कैरेक्टर प्रोफ़ाइल है जिसमें इन्वेंट्री आइटम्स की एक लिस्ट है।

# A nested structure
character:
  name: "Gollum"
  aliases:
    - "Sméagol"
    - "My Precious"
  possessions:
    - item: "The One Ring"
      description: "A plain gold ring, surprisingly heavy."
    - item: "A fish"
      description: "Juicy and sweet!"
  is_wretched: true

स्ट्रक्चर को देखिए। name, aliases, possessions, और is_wretched सभी character की प्रॉपर्टीज़ हैं क्योंकि वे इसके नीचे इंडेंटेड हैं। aliases सीक्वेंस character मैपिंग के अंदर एक वैल्यू है। possessions सीक्वेंस में दो मैपिंग ऑब्जेक्ट्स हैं, जिनमें से प्रत्येक में एक item और एक description है।

इंडेंटेशन की मात्रा मायने नहीं रखती, जब तक कि वह एक ही ब्लॉक के भीतर consistent हो। दो स्पेस कम्युनिटी स्टैंडर्ड है। लेकिन आपको स्पेस का उपयोग करना चाहिए, टैब्स का नहीं। टैब्स का उपयोग करना अदृश्य दर्द की दुनिया में खुद को डालने का #1 तरीका है।

एडवांस्ड ट्रिक्स: एंकर्स, एलियासेज़ और टैग्स

YAML में कुछ पावर-यूज़र फ़ीचर्स हैं जो JSON में नहीं हैं, जिन्हें आपकी फ़ाइलों को DRY (Don't Repeat Yourself - खुद को दोहराएं नहीं) रखने के लिए डिज़ाइन किया गया है।

एंकर्स (&) और एलियासेज़ (*): यदि आपके पास डेटा का एक हिस्सा है जिसे आपको फिर से उपयोग करने की आवश्यकता है, तो आप उसे एक एंकर (&anchor_name) के साथ एक नाम दे सकते हैं और फिर एक एलियास (*anchor_name) के साथ कहीं और उसका संदर्भ दे सकते हैं।
```
# Define a default user profile with an anchor
default_user: &default_user_profile
  theme: "dark"
  notifications: "enabled"
  permissions: "read-only"

# Now create specific users who inherit the defaults
users:
  - name: "Alice"
    # Use an alias to pull in the default profile
    <<: *default_user_profile
    # And override a specific key
    permissions: "admin"
  - name: "Bob"
    # Bob gets the standard profile
    <<: *default_user_profile
```
यहाँ, << एक विशेष मर्ज की (merge key) है। एलिस और बॉब दोनों को डिफ़ॉल्ट प्रोफ़ाइल मिलती है, लेकिन एलिस की permissions की ओवरराइड हो जाती है। यह जटिल कॉन्फ़िगरेशन में एक लाइफ़सेवर है।
टैग्स (!!): YAML आमतौर पर टाइप का अनुमान लगाता है, लेकिन आप टैग्स के साथ स्पष्ट हो सकते हैं। यह अस्पष्टता से बचने के लिए उपयोगी हो सकता है। उदाहरण के लिए, यदि आप स्ट्रिंग "12.0" चाहते हैं, न कि नंबर 12.0।
```
version: !!str 12.0 # Force this to be a string
not_a_boolean: !!str "no" # Force this to be a string
```

असल दुनिया की कहानियाँ

गायब होती पाइपलाइन का मामला

एक जूनियर DevOps इंजीनियर, मान लीजिए उसका नाम क्लोई है, को अपनी कंपनी की CI/CD पाइपलाइन में एक नया सिक्योरिटी स्कैन जोड़ने का काम सौंपा गया था, जो gitlab-ci.yml फ़ाइल में डिफाइन था। उसने नया जॉब जोड़ा, अपना कोड पुश किया, और... कुछ नहीं हुआ। पाइपलाइन चली, लेकिन उसका नया स्कैन जॉब कहीं नहीं था। यह फेल नहीं हुआ; यह बस गायब हो गया। दो घंटे तक, क्लोई ने अपनी स्क्रिप्ट सिंटैक्स, रनर कॉन्फ़िगरेशन, और फेज़ डेफिनिशन की जाँच की। अंत में, निराश होकर, उसने एक सीनियर इंजीनियर से देखने के लिए कहा। सीनियर डेव की आँखों ने फ़ाइल को लगभग पाँच सेकंड तक स्कैन किया और फिर एक लाइन की ओर इशारा किया। क्लोई ने अपने नए जॉब को हर जगह इस्तेमाल किए गए दो स्पेस के बजाय तीन स्पेस से इंडेंट किया था। YAML पार्सर ने इसे पिछले जॉब के एक गलत चाइल्ड के रूप में देखा, न कि एक नए टॉप-लेवल जॉब के रूप में, और चुपचाप इसे अनदेखा कर दिया।

सबक: YAML में, व्हाइटस्पेस ही सिंटैक्स है। एक गलत जगह पर लगा स्पेस आपकी फ़ाइल का पूरा मतलब बदल सकता है। इन गलतियों को तुरंत पकड़ने के लिए एक लिंटर या एक स्ट्रक्चर्ड एडिटर का उपयोग करें जो डेटा ट्री को विज़ुअलाइज़ करता है।

वो कॉन्फ़िग जो जंगल बन गई

एक छोटा स्टार्टअप अपने एप्लिकेशन एनवायरनमेंट्स (डेवलपमेंट, स्टेजिंग, प्रोडक्शन) को एक ही config.yml से मैनेज कर रहा था। पहले तो यह सरल था। लेकिन जैसे-जैसे उन्होंने और एनवायरनमेंट्स (prod-us, prod-eu, dev-feature-x) जोड़े, फ़ाइल फट गई। डेटाबेस यूआरएल, एपीआई कीज़, और फ़ीचर फ़्लैग्स के लिए कॉन्फ़िगरेशन के बड़े-बड़े ब्लॉक हर एनवायरनमेंट के लिए कॉपी-पेस्ट किए गए थे, जिनमें केवल मामूली बदलाव थे। फ़ाइल एक 500-लाइन का राक्षस बन गई, और टाइमआउट सेटिंग जैसी एक साझा वैल्यू को बदलने के लिए उसे पाँच अलग-अलग जगहों पर ढूंढना और बदलना पड़ता था। एक नए कर्मचारी ने, जो एक बड़ी कंपनी से आया था, यह देखा और YAML एंकर्स का उपयोग शुरू किया। उसने सभी सामान्य सेटिंग्स के साथ एक &default_config ब्लॉक डिफाइन किया। फिर, प्रत्येक एनवायरनमेंट की कॉन्फ़िगरेशन ने बस डिफ़ॉल्ट (<<: *default_config) को एलियास किया और उन कुछ वैल्यूज़ को ओवरराइड किया जो अलग थीं। 500-लाइन की फ़ाइल सिकुड़कर 100 लाइनों से भी कम हो गई।

सबक: खुद को दोहराएं नहीं। यदि आप खुद को एक YAML फ़ाइल के भीतर बड़े ब्लॉक्स को कॉपी-पेस्ट करते हुए पाते हैं, तो यह एंकर्स और एलियासेज़ को सीखने और उपयोग करने का समय है।

नॉर्वे की समस्या

एक डेवलपर एक ऐसा फ़ीचर बना रहा था जो यूज़र्स को ड्रॉपडाउन से अपना देश चुनने देता था। कंट्री कोड्स की सूची एक सरल YAML फ़ाइल में स्टोर की गई थी: supported_countries: [ US, DE, UK, NO ]। टेस्टिंग के दौरान, नॉर्वे (NO) के यूज़र्स ने शिकायत की कि वे साइन अप नहीं कर पा रहे हैं। डेवलपर ने घंटों तक कोड को डीबग किया, वेरिएबल्स को ट्रेस किया, लेकिन समस्या नहीं देख सका। NO वैल्यू फ्रंटएंड से सही ढंग से पास हो रही थी। अंत में, उसने YAML फ़ाइल से लोड हो रहे डेटा का निरीक्षण किया। उसके प्रोग्राम में supported_countries एरे ['US', 'DE', 'UK', false] था। YAML पार्सर ने, स्पेक के एक पुराने संस्करण का पालन करते हुए, बिना कोट्स वाले NO को "false" के लिए एक बूलियन वैल्यू के रूप में समझ लिया था।

सबक: जब संदेह हो, तो अपनी स्ट्रिंग्स को कोट्स में रखें। कोई भी स्केलर जो एक नंबर ("1.0"), एक बूलियन ("yes", "no", "on", "off"), या एक विशेष वैल्यू की तरह दिख सकता है, उसे स्पष्ट रूप से कोट किया जाना चाहिए ताकि पार्सिंग में कोई आश्चर्य न हो।

आम गलतियाँ और जाल

स्पेस के बजाय टैब्स का उपयोग करना। यह YAML का सबसे बड़ा पाप है। स्पेसिफिकेशन टैब्स को प्रतिबंधित करता है। क्योंकि वे अदृश्य होते हैं, वे पार्सिंग एरर्स का कारण बन सकते हैं जिन्हें खोजना बेहद मुश्किल होता है। अपने एडिटर को YAML फ़ाइलों के लिए स्पेस का उपयोग करने के लिए कॉन्फ़िगर करें।
असंगत इंडेंटेशन (Inconsistent indentation)। यदि एक लिस्ट आइटम दो स्पेस से इंडेंट किया गया है और अगला चार से, तो आपका समय खराब होने वाला है। स्ट्रक्चर गलत तरीके से पार्स किया जाएगा। इंडेंटेशन लेवल को consistent रखें।
अस्पष्ट स्ट्रिंग्स को कोट करना भूल जाना। "नॉर्वे की समस्या" एक क्लासिक उदाहरण है। Yes, No, true, false, On, Off जैसी स्ट्रिंग्स को बूलियन के रूप में पार्स किया जाएगा। लीडिंग ज़ीरो या विशेष वर्णों वाले नंबर गलत तरीके से पार्स हो सकते हैं। जब संदेह हो, तो इसे "quotes" में लपेटें।
मल्टीलाइन स्ट्रिंग में कन्फ्यूजन। | (लिटरल स्टाइल, न्यूलाइन्स को संरक्षित करता है) और > (फोल्डेड स्टाइल, न्यूलाइन्स को स्पेस में बदलता है) के बीच का अंतर भूल जाना। इससे आपका सावधानी से स्वरूपित टेक्स्ट या शेल स्क्रिप्ट का ब्लॉक बिगड़ सकता है।
अप्रत्याशित null वैल्यूज़। कोलन के बाद कुछ भी नहीं वाली की (key: ) एक null वैल्यू है। यह अक्सर एक आकस्मिक डिलीशन होता है और यदि आपका कोड null की जाँच नहीं करता है तो यह चुपचाप विफलताओं का कारण बन सकता है।

यह आपके रडार पर क्यों होना चाहिए

अगर आप 2024 में कोड लिखते हैं, तो आप YAML से बच नहीं सकते। यह कॉन्फ़िगरेशन का निर्विवाद बादशाह है।

DevOps & Infrastructure-as-Code: Kubernetes, Ansible, Docker Compose, GitHub Actions, AWS CloudFormation, और अनगिनत अन्य टूल्स YAML को अपनी प्राथमिक परिभाषा भाषा के रूप में उपयोग करते हैं।
एप्लिकेशन कॉन्फ़िगरेशन: कई फ्रेमवर्क (जैसे Symfony और Ruby on Rails) और एप्लिकेशन सेटिंग्स फ़ाइलों के लिए YAML का उपयोग करते हैं क्योंकि यह डेवलपर्स के लिए पढ़ना और संशोधित करना बहुत आसान है।
स्टेटिक साइट जेनरेटर्स: Jekyll और Hugo जैसे टूल्स पोस्ट और पेजों के लिए मेटाडेटा को परिभाषित करने के लिए "फ्रंटमैटर" के लिए YAML का उपयोग करते हैं।

YAML जानना सिर्फ़ कॉन्फ़िग फ़ाइलें लिखने के बारे में नहीं है। यह उन सिस्टम्स के स्ट्रक्चर को समझने के बारे में है जिनके साथ आप काम करते हैं। एक सूक्ष्म इंडेंटेशन एरर को पकड़ने में सक्षम होना या यह जानना कि कब एंकर का उपयोग करना है, एक त्वरित फ़िक्स और डीबगिंग में खोए हुए एक दिन के बीच का अंतर हो सकता है।

और गहराई में जाएं

YAML Spec 1.2.2: सच्चाई का आधिकारिक स्रोत। यह घना है, लेकिन यह अंतिम संदर्भ है।
Wikipedia: YAML: भाषा के इतिहास, विशेषताओं और संस्करणों का एक शानदार उच्च-स्तरीय अवलोकन।
Learn YAML in Y minutes: लाइव उदाहरणों के साथ एक शानदार, सिंगल-पेज चीटशीट जो 80% वह सब कुछ कवर करती है जिसकी आपको कभी आवश्यकता होगी।
YAML Lint: एक ऑनलाइन वैलिडेटर जो उन pesky सिंटैक्स एरर्स को खोजने और यह समझने के लिए अमूल्य है कि पार्सर "क्या देखता है"।
GitHub Docs: Workflow syntax for GitHub Actions: पूरी तरह से YAML में परिभाषित एक जटिल प्रणाली का एक उत्कृष्ट वास्तविक दुनिया का उदाहरण। इसका अध्ययन करने से कई सामान्य पैटर्न का पता चलता है।