YAML से JSON: अपना दिमाग खोए बिना कॉन्फ़िगरेशन परिवर्तित करना

YAML से JSON रूपांतरण वास्तव में क्या करता है

YAML और JSON समान आकृतियों का वर्णन करते हैं - मानचित्र, सूचियाँ, तार, संख्याएँ, बूलियन और शून्य - इसलिए रूपांतरण ज्यादातर एक वाक्यविन्यास को दूसरे के रूप में पुन: क्रमबद्ध करने का मामला है। सतह में क्या परिवर्तन होता है: इंडेंटेशन ब्रेसिज़ बन जाता है, टिप्पणियाँ गायब हो जाती हैं, एंकर प्रतियां बन जाती हैं, और मल्टी-लाइन स्ट्रिंग्स `\n` एस्केप में ढह जाती हैं। उन परिवर्तनों में से हर एक एक तरह से हानिपूर्ण है जो मायने रखता है, यही कारण है कि रूपांतरण कदम को बाद में प्रारूपण के रूप में मानने के बजाय जानबूझकर किया जाना चाहिए।

परिवर्तित करने का व्यावहारिक कारण यह है कि JSON वही है जो अगला टूल चाहता है। Kubernetes YAML स्वीकार करता है, लेकिन `kubectl`, जेक्यू पाइपलाइन, API कॉल ​​और जावास्क्रिप्ट सभी JSON अधिक आराम से बोलते हैं। एक बार सही ढंग से कनवर्ट करना, समानांतर रूप से दो प्रारूपों को हाथ से संपादित करने से बेहतर है।

बहु-दस्तावेज़ YAML: मूक प्रथम-दस्तावेज़ समस्या

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

त्रुटियाँ एक पंक्ति और स्तंभ पर इंगित होनी चाहिए

रिक्त स्थान के प्रति YAML की सहनशीलता के कारण ही छोटी-छोटी गलतियाँ ढूंढ़ना कठिन होता है। इंडेंटेशन के लिए टैब अवैध हैं, एक गायब कोलन मैपिंग को एक स्ट्रिंग में बदल देता है, और डुप्लिकेट कुंजियाँ कुछ पार्सर्स द्वारा स्वीकार कर ली जाती हैं और दूसरों द्वारा अस्वीकार कर दी जाती हैं। जब कोई रूपांतरण विफल हो जाता है, तो एकमात्र उपयोगी संदेश पंक्ति और कॉलम को नाम देता है और आपत्तिजनक अंश दिखाता है:

                spec:
  containers:
	- name: web      # tab used for indentation
error: line 3, column 0 — tabs cannot be used for indentation
              

डुप्लिकेट कुंजियाँ खतरनाक मामला हैं: YAML पार्सर आमतौर पर अंतिम मान रखते हैं और कुछ नहीं कहते हैं। यदि `replicas: 3` दो बार प्रकट होता है, तो आपको जो JSON मिलता है वह पूरी तरह से वैध दिखता है - और गलत संख्या।

यात्रा से बचने वाले नियमों का हवाला देते हुए

YAML की तुलना में JSON स्ट्रिंग्स के बारे में अधिक सख्त है, इसलिए रूपांतरण उन मानों के आसपास उद्धरण जोड़ते हैं जो नंगे थे। यह सामान्य है, लेकिन दो YAML विचित्रताएँ वास्तविक बग का कारण बनती हैं: `yes`, `no`, `on` और `off` YAML 1.1 में बूलियन हैं, लेकिन JSON शब्दार्थ में स्ट्रिंग्स, और ज़िप कोड और फ़ोन नंबर जैसे अग्रणी-शून्य मान संख्याओं के रूप में व्यवहार किए जाने पर अपना शून्य खो देते हैं। यदि किसी फ़ील्ड को रूपांतरण के दौरान एक स्ट्रिंग रहना चाहिए, तो उसे स्रोत में उद्धृत करें।

इसे स्थानीय रूप से चलाएँ, विशेष रूप से क्लस्टर कॉन्फ़िगरेशन के लिए

Kubernetes मैनिफ़ेस्ट नियमित रूप से `Secret` ऑब्जेक्ट में क्रेडेंशियल, कॉन्फ़िगमैप्स में कनेक्शन स्ट्रिंग और सीआई फ़ाइलों में टोकन ले जाता है। उन्हें वेब सेवा में चिपकाने से वे एक ऐसे सर्वर को सौंप दिए जाते हैं जिसे आप नियंत्रित नहीं करते हैं। एक ब्राउज़र-आधारित कनवर्टर उसी टैब में पार्स और क्रमबद्ध करता है जिसे आप पढ़ रहे हैं, इसलिए कुछ भी प्रसारित नहीं होता है - और एक पृष्ठ जो नेटवर्क कट ऑफ के साथ काम करता रहता है वह वादे के बजाय इसका प्रमाण है।

एक समझदार कार्यप्रवाह

1. पहले YAML को सत्यापित करें और किसी भी रिपोर्ट की गई पंक्ति, कॉलम और अंश को ठीक करें।
2. चुनें कि बहु-दस्तावेज़ फ़ाइलों को कैसे प्रबंधित किया जाना चाहिए - सरणी, या एक विशिष्ट दस्तावेज़।
3. इंडेंटेशन के साथ कनवर्ट करें जो आपकी कोडबेस शैली (2 या 4 रिक्त स्थान) से मेल खाता है, और यदि आप अलग-अलग आउटपुट कर रहे हैं तो कुंजी को सॉर्ट करें।
4. गिट में YAML को सत्य के स्रोत के रूप में रखें और JSON को एक उत्पन्न कलाकृति के रूप में मानें; टिप्पणियाँ केवल YAML में रहती हैं।