YAML क्या है? मानव-अनुकूल डेटा भाषा
सामान्य शब्दों में YAML
YAML का पूरा नाम 'YAML Ain't Markup Language' है — यह एक रिकर्सिव मज़ाक है जो आपको बताता है कि यह क्या नहीं है। यह HTML की तरह दस्तावेज़ों को मार्कअप करने के लिए नहीं है। इसके बजाय, YAML एक डेटा सीरियलाइज़ेशन प्रारूप है जिसे किसी व्यक्ति द्वारा मैन्युअल को अगली टैब में खोले बिना पढ़ने और संपादित करने के लिए डिज़ाइन किया गया है। यह पहली बार 2001 में सामने आया, जिसे क्लार्क इवांस, इंगी डॉट नेट और ओरेन बेन-किकी ने बनाया था। तब से, यह Kubernetes, Ansible, GitHub Actions, Docker Compose और Ruby on Rails जैसे आवश्यक उपकरणों के लिए डिफ़ॉल्ट कॉन्फ़िगरेशन भाषा बन गया है। अपने मूल में, YAML डेटा संरचनाओं जैसे कि कुंजी-मूल्य जोड़े और सूचियों को दर्शाने के लिए इंडेंटेशन का उपयोग करता है। आपको यहां एंगल ब्रैकेट या कर्ली ब्रेसिज़ नहीं मिलेंगे। एक साधारण Docker Compose फ़ाइल इसे स्पष्ट रूप से दिखाती है: version: '3.9' services: web: image: nginx:latest ports: - '80:80' इसे समतुल्य JSON के सामने रखें और इसका आकर्षण स्पष्ट है। कोई कॉमा नहीं, कुंजियों पर कोई उद्धरण नहीं, और कोई क्लोजिंग ब्रेसिज़ नहीं जो बेमेल हो सकें। इसके लिए यह समझौता करना पड़ता है कि इंडेंटेशन महत्वपूर्ण हो जाता है। यदि आप इसे एक भी स्थान से गलत करते हैं, तो फ़ाइल पार्स होने में विफल हो सकती है या, इससे भी बदतर, चुपचाप कुछ और ही मतलब निकाल सकती है। आसान पढ़ने और सख्त संरचना के बीच यह तनाव YAML अनुभव को परिभाषित करता है। इसका अच्छी तरह से उपयोग करने की कुंजी इसके साथ सहज होना है।
YAML डेटा को कैसे संरचित करता है: तीन मूल खंड
प्रत्येक YAML दस्तावेज़ समान मूल भागों से बना होता है: स्केलर, सीक्वेंस और मैपिंग। एक स्केलर सिर्फ एक एकल मान होता है, जैसे कि एक स्ट्रिंग, एक संख्या, एक बूलियन, या नल। YAML प्रकार का अनुमान लगाने में चतुर है, जो अधिकतर सहायक होता है लेकिन कभी-कभी उल्टा पड़ सकता है। 'yes' स्ट्रिंग को पुराने YAML 1.1 मानक में बूलियन `true` के रूप में पार्स किया जाता है, जिसका उपयोग अभी भी PyYAML और अन्य विरासत उपकरण करते हैं। हालांकि, YAML 1.2 इसे एक सादे स्ट्रिंग के रूप में सही ढंग से मानता है। उस संस्करण के अंतर के कारण वास्तविक दुनिया में उत्पादन बग हुए हैं, इसलिए आपको निश्चित रूप से यह जानने की आवश्यकता है कि आपके उपकरण किस पार्सर का उपयोग कर रहे हैं। एक सीक्वेंस सिर्फ एक क्रमबद्ध सूची होती है। आप इसे एक अग्रणी डैश और एक स्थान के साथ लिखते हैं: fruits: - apple - banana - mango A मैपिंग कुंजी-मूल्य जोड़ों का एक सेट है, जो आपको कॉन्फ़िगरेशन फ़ाइलों में सबसे अधिक बार देखने को मिलेगा। आप मैपिंग को किसी भी गहराई तक नेस्ट कर सकते हैं, और संरचना पूरी तरह से सुसंगत इंडेंटेशन द्वारा परिभाषित की जाती है। YAML स्पेसिफिकेशन इस पर स्पष्ट है: आपको स्पेस का उपयोग करना चाहिए, कभी टैब का नहीं। YAML दोहराव को कम करने के लिए शक्तिशाली सुविधाएँ भी प्रदान करता है। एंकर (&) और उपनाम (*) आपको डेटा के एक ब्लॉक को एक बार परिभाषित करने और इसे कहीं और पुन: उपयोग करने देते हैं। CI/CD पाइपलाइन में यह एक जीवनरक्षक है जहाँ कई जॉब एक ही पर्यावरण चर ब्लॉक को साझा कर सकते हैं। लंबी स्ट्रिंग के लिए, YAML में दो ब्लॉक शैलियाँ हैं: लिटरल ब्लॉक स्केलर (|) नई लाइनों को बिल्कुल वैसे ही संरक्षित करता है, जबकि फोल्डेड ब्लॉक स्केलर (>) उन्हें स्पेस में ढहा देता है। यह लंबी शैल कमांड के लिए एकदम सही है जिन्हें आप फ़ाइल में पठनीय रखना चाहते हैं बिना कमांड में वास्तविक लाइन ब्रेक जोड़े।
YAML का वास्तव में कहाँ उपयोग किया जाता है
YAML इन्फ्रास्ट्रक्चर और डेवलपर टूलिंग की दुनिया में फल-फूल रहा है। संख्याएँ झूठ नहीं बोलतीं। 2024 तक, GitHub Actions प्रतिदिन 100 मिलियन से अधिक वर्कफ़्लो रन संसाधित करता है, हर एक परियोजना की .github/workflows डायरेक्टरी में एक .yml फ़ाइल द्वारा संचालित होता है। Kubernetes, अधिकांश क्लाउड-नेटिव अनुप्रयोगों के पीछे का इंजन, प्रत्येक संसाधन को परिभाषित करने के लिए YAML पर निर्भर करता है: Deployments, Services, ConfigMaps, आप इसका नाम लें। एक विशिष्ट माइक्रोसेर्विसेज एप्लिकेशन आसानी से सैकड़ों YAML फ़ाइलें जमा कर सकता है। Ansible, एक IT ऑटोमेशन टूल जिसका उपयोग 25,000 से अधिक संगठन (Red Hat के अनुसार) करते हैं, अपने सभी प्लेबुक के लिए YAML का उपयोग करता है। एक Ansible प्लेबुक में एक मानक कार्य इस तरह दिखता है: - name: Install nginx ansible.builtin.package: name: nginx state: present DevOps क्षेत्र से परे, आपको Jekyll जैसे स्टैटिक साइट जनरेटर में YAML मिलेगा, जो मार्कडाउन फ़ाइलों में मेटाडेटा स्टोर करने के लिए YAML फ्रंट मैटर का उपयोग करता है। Hoppscotch और Insomnia जैसे API टेस्टिंग टूल पर्यावरण कॉन्फ़िगरेशन के लिए इसका उपयोग करते हैं। यहां तक कि डेटा साइंस पाइपलाइन भी इसका उपयोग करती हैं; DVC (Data Version Control) जैसे उपकरण YAML फ़ाइलों में प्रयोग मापदंडों को ट्रैक करते हैं। एक जगह जहाँ आपको बहुत अधिक YAML नहीं दिखेगा, वह वेब सेवाओं के बीच डेटा इंटरचेंज में है। REST APIs अनुरोध और प्रतिक्रिया निकायों के लिए लगभग सार्वभौमिक रूप से JSON का उपयोग करते हैं। क्यों? क्योंकि JSON पार्सर हर ब्राउज़र में निर्मित होते हैं और प्रारूप की सख्ती अस्पष्टता के लिए कोई जगह नहीं छोड़ती है। यह मुख्य अंतर है: YAML डिस्क पर फ़ाइलों को संपादित करने वाले मनुष्यों के लिए है; JSON नेटवर्क पर डेटा पास करने वाली मशीनों के लिए है। उस सरल नियम को याद रखने से यह तय करने में बहुत भ्रम से बचा जा सकेगा कि कौन सा प्रारूप चुनना है।
YAML बनाम JSON बनाम TOML: सही प्रारूप चुनना
जब एक कॉन्फ़िगरेशन प्रारूप चुनते हैं, तो आप आमतौर पर YAML, JSON और TOML के बीच चयन कर रहे होते हैं। उनमें से प्रत्येक का एक विशिष्ट व्यक्तित्व होता है। JSON (JavaScript Object Notation) सबसे सख्त है। प्रत्येक स्ट्रिंग को उद्धृत किया जाना चाहिए, प्रत्येक सूची और ऑब्जेक्ट को स्पष्ट रूप से बंद किया जाना चाहिए, और इसमें टिप्पणियों के लिए कोई समर्थन नहीं है। वह अंतिम बात डेवलपर्स के लिए निराशा का एक प्रमुख स्रोत है जो कॉन्फ़िगरेशन को एनोटेट करना चाहते हैं। लेकिन JSON की ताकत इसकी कठोर, असंदिग्ध पार्सिंग है; कोई भी दो अनुरूप पार्सर एक ही इनपुट से समान डेटा संरचनाएं उत्पन्न करेंगे। इसकी फ़ाइल का आकार आमतौर पर विशिष्ट कॉन्फ़िगरेशन के लिए YAML के बराबर होता है। TOML (Tom's Obvious, Minimal Language) JSON में टिप्पणियों की कमी और YAML के मुश्किल व्हाइटस्पेस नियमों को ठीक करने के लिए बनाया गया था। यह एक INI-शैली सिंटैक्स का उपयोग करता है और इसे Rust के Cargo पैकेज मैनेजर और Python के pyproject.toml मानक द्वारा अपनाया गया है। TOML फ्लैट या कम गहराई वाले नेस्टेड कॉन्फ़िगरेशन के लिए शानदार है, लेकिन जब आपको गहराई से नेस्टेड डेटा को दर्शाने की आवश्यकता होती है तो यह अनाड़ी और वर्बोज़ हो जाता है। तो YAML कहाँ फिट बैठता है? जब आपके कॉन्फ़िगरेशन में महत्वपूर्ण नेस्टिंग गहराई होती है, जब आप दोहराव को खत्म करने के लिए एंकर और उपनाम का उपयोग कर सकते हैं, या जब गैर-तकनीकी लोगों को फ़ाइल को संपादित करने की आवश्यकता होती है, तो YAML स्पष्ट विजेता होता है। यह गलत विकल्प है जब आपकी टीम लगातार इंडेंटेशन त्रुटियों से जूझ रही होती है या जब टाइप इन्फ्रेंस आश्चर्य पैदा करता है (जैसे कुख्यात नॉर्वे समस्या, जहाँ देश कोड 'NO' को बूलियन `false` के रूप में पार्स किया गया था)। यदि आपको प्रारूपों के बीच कनवर्ट करने की आवश्यकता है, तो CocoConvert विश्वसनीय YAML-से-JSON और JSON-से-YAML रूपांतरण प्रदान करता है। हालांकि, यह TOML को आउटपुट प्रारूप के रूप में समर्थन नहीं करता है। यदि आपको YAML से TOML में जाना है, तो आपको `yq` जैसे कमांड-लाइन टूल का उपयोग करना होगा। यह पहले से जानना बेहतर है।
सामान्य YAML गलतियाँ और उनसे कैसे बचें
YAML त्रुटियों का सबसे आम स्रोत असंगत इंडेंटेशन है। जिसने भी एक घंटे तक CI पाइपलाइन को डीबग करने में बिताया है और फिर एक गलत जगह पर एक स्पेस पाया है, वह इस दर्द को जानता है। Python के विपरीत, जो किसी भी सुसंगत इंडेंट चौड़ाई को स्वीकार करता है, YAML को एक ही स्तर पर सिबलिंग कुंजियों के लिए बिल्कुल समान इंडेंटेशन की आवश्यकता होती है। एक फ़ाइल में दो-स्पेस और चार-स्पेस इंडेंटेशन को मिलाने से पार्स त्रुटि होगी या, इससे भी बदतर, चुपचाप आपके डेटा को पुनर्गठित कर देगा। काम करने का एकमात्र सुरक्षित तरीका अपने संपादक को टैब के लिए स्पेस का उपयोग करने और एक सुसंगत इंडेंट आकार लागू करने के लिए कॉन्फ़िगर करना है। Kubernetes और GitHub Actions के लिए दो स्पेस एक डिफ़ैक्टो मानक है। अनकोटेड विशेष वर्ण एक और जाल हैं। एक स्पेस के बाद एक कोलन एक कुंजी-मूल्य विभाजक है, इसलिए 'http://example.com:8080' जैसी स्ट्रिंग को उद्धृत किया जाना चाहिए। उद्धरण भूल जाएं, और आपको एक पार्स त्रुटि मिलेगी। इसी तरह, `{`, `[`, या `%` से शुरू होने वाले मानों को उद्धृत करने की आवश्यकता होती है क्योंकि YAML सिंटैक्स में उनका विशेष अर्थ होता है। फिर टाइप कोएर्सियन के आश्चर्य हैं। हमने पहले ही बताया है कि 'no' कैसे `false` बन सकता है। लेकिन क्या आप जानते हैं कि अग्रणी शून्य वाली संख्याओं को ऑक्टल पूर्णांक के रूप में पार्स किया जा सकता है? मान 0755, एक सामान्य यूनिक्स फ़ाइल अनुमति, दशमलव 493 बन जाता है जब तक कि आप इसे उद्धृत न करें। दिनांक एक और बारूदी सुरंग हैं; 2024-01-01 बिना उद्धरण के एक दिनांक ऑब्जेक्ट बन जाता है, न कि एक स्ट्रिंग, जो उन उपकरणों को तोड़ सकता है जो एक स्ट्रिंग की उम्मीद करते हैं। सबसे अच्छा बचाव यह है कि आप इसे कमिट करने से पहले अपने YAML को लिंट करें। `yamllint` एक आवश्यक कमांड-लाइन टूल है जो इंडेंटेशन त्रुटियों, ट्रेलिंग स्पेस और अन्य सामान्य समस्याओं को पकड़ता है। आपकी CI पाइपलाइन में निश्चित रूप से एक `yamllint` चरण शामिल होना चाहिए। एक त्वरित वन-ऑफ जांच के लिए, अपनी फ़ाइल को CocoConvert के YAML-से-JSON कनवर्टर में पेस्ट करना एक बेहतरीन सैनिटी टेस्ट है। यदि परिणामी JSON संरचना आपकी इच्छित चीज़ जैसी नहीं दिखती है, तो आपके YAML में समस्या है।
YAML फ़ाइलों को परिवर्तित करना: CocoConvert क्या कर सकता है
CocoConvert दो सबसे आम रूपांतरण आवश्यकताओं के लिए उपकरण प्रदान करता है: YAML से JSON और JSON से YAML। प्रक्रिया सरल है: अपनी सामग्री पेस्ट करें या एक .yaml फ़ाइल अपलोड करें, अपना लक्ष्य प्रारूप चुनें, और परिणाम डाउनलोड करें। कनवर्टर आपके डेटा की नेस्टेड संरचना को सटीक रूप से संरक्षित करता है। यह मल्टी-डॉक्यूमेंट YAML फ़ाइलों (जहाँ दस्तावेज़ --- द्वारा अलग किए जाते हैं) को भी सही ढंग से संभालता है, प्रत्येक को एक बड़े ऐरे के भीतर एक अलग JSON ऑब्जेक्ट में परिवर्तित करता है। YAML को JSON में परिवर्तित करते समय, आउटपुट को एक मानक दो-स्पेस इंडेंटेशन के साथ स्वरूपित किया जाता है, जिससे यह पठनीय और लगभग सभी JSON टूल के साथ संगत हो जाता है। यदि आपको एक कॉम्पैक्ट, सिंगल-लाइन JSON स्ट्रिंग की आवश्यकता है — शायद एक पर्यावरण चर के लिए या पेलोड आकार को कम करने के लिए — तो परिणाम पृष्ठ पर एक मिनिफ़ाई विकल्प उपलब्ध है। JSON से YAML में जाते समय, कनवर्टर दो-स्पेस इंडेंटेशन का उपयोग करता है और एकल दस्तावेज़ों के लिए दस्तावेज़ स्टार्ट मार्कर (---) को छोड़ देता है। यदि इनपुट में कई JSON ऑब्जेक्ट शामिल हैं, तो प्रत्येक `---` मार्कर द्वारा अलग किया गया एक अलग YAML दस्तावेज़ बन जाता है। महत्वपूर्ण रूप से, यह स्वचालित रूप से स्ट्रिंग मानों को उद्धृत करता है जिन्हें बूलियन, नल या संख्याओं के रूप में गलत समझा जा सकता है, इसलिए आपको 'true' या '1.0' जैसी स्ट्रिंग के कारण समस्याओं के बारे में चिंता करने की आवश्यकता नहीं है। आइए सीमाओं के बारे में सीधे बात करें। CocoConvert रूपांतरण के दौरान YAML टिप्पणियों को संरक्षित नहीं करता है। यह एक टूल की कमी नहीं है; टिप्पणियाँ YAML के औपचारिक डेटा मॉडल का हिस्सा नहीं हैं, इसलिए उन्हें पार्सर द्वारा हटा दिया जाता है। एंकर और उपनाम भी हल हो जाते हैं, जिसका अर्थ है कि अंतिम आउटपुट में संदर्भों के बजाय दोहराए गए मान शामिल होंगे। अंत में, बहुत बड़ी फ़ाइलें (10 MB से अधिक) मुफ्त टियर पर टाइम आउट हो सकती हैं। उन बड़ी नौकरियों के लिए, `yq` जैसा कमांड-लाइन टूल बेहतर विकल्प है।
YAML का उपयोग कब करें और कब इससे बचें
YAML काम के लिए सही उपकरण है जब कुछ शर्तें पूरी होती हैं। फ़ाइल मनुष्यों द्वारा पढ़ी और संपादित की जाएगी, डेटा में सार्थक नेस्टेड संरचना है, और आसपास का इकोसिस्टम पहले से ही YAML का उपयोग करता है। Kubernetes मैनिफेस्ट, CI/CD पाइपलाइन, और Ansible प्लेबुक इसके पोस्टर चाइल्ड हैं। इन परिदृश्यों में JSON का उपयोग करने की कोशिश करने से बिना किसी वास्तविक लाभ के जीवन कठिन हो जाता है। इसके विपरीत, YAML गलत विकल्प है जब एक फ़ाइल को केवल मशीनों द्वारा ही छुआ जाता है। मशीन-से-मशीन संचार के लिए, JSON या अधिक कुशल बाइनरी प्रारूप जैसे MessagePack या Protocol Buffers का उपयोग करें। यह एक खराब विकल्प भी है यदि आपकी टीम लगातार इंडेंटेशन त्रुटियों से जूझ रही है और उसमें लिंटर का उपयोग करने का अनुशासन नहीं है। ऐसी स्थिति में, TOML का सरल सिंटैक्स, या यहां तक कि एक पूर्व-संसाधित JSON फ़ाइल, कम उत्पादन घटनाओं का कारण बनेगी। यदि आप Python प्रोजेक्ट्स में YAML का उपयोग कर रहे हैं, तो एक महत्वपूर्ण सुरक्षा जोखिम है जिसे आपको समझना चाहिए। PyYAML का डिफ़ॉल्ट `yaml.load()` फ़ंक्शन YAML फ़ाइल में एम्बेडेड मनमाने कोड को निष्पादित कर सकता है। यदि आप एक अविश्वसनीय स्रोत से YAML को पार्स कर रहे हैं, तो आपको हमेशा `yaml.safe_load()` का उपयोग करना चाहिए। यह एक सैद्धांतिक भेद्यता नहीं है; इसका वास्तविक आपूर्ति श्रृंखला हमलों में शोषण किया गया है। यह प्रारूप दो दशकों से अधिक समय से हमारे साथ है और कहीं नहीं जा रहा है। YAML 1.2 स्पेसिफिकेशन, जिसने संस्करण 1.1 से अधिकांश कष्टप्रद प्रकार के कोएर्सियन मुद्दों को ठीक कर दिया था, अब PyYAML 6.0+, js-yaml 4.x, और Go के yaml.v3 जैसे आधुनिक पार्सर द्वारा व्यापक रूप से समर्थित है। मेरी सबसे मजबूत सिफारिश: यदि आप एक ऐसे प्रोजेक्ट पर काम कर रहे हैं जो YAML पर बहुत अधिक निर्भर करता है, तो 1.2-अनुरूप पार्सर में माइग्रेट करना सबसे प्रभावशाली अपग्रेड है जो आप कर सकते हैं। यह आपको कॉन्फ़िगरेशन की एक भी लाइन बदले बिना सूक्ष्म बग्स के एक पूरे वर्ग को खत्म कर देगा।