Docker Compose की 9 ग़लतियाँ जो आपका स्टैक रोक देती हैं (और उन्हें कैसे ठीक करें)

आप किसी ट्यूटोरियल से docker-compose.yml कॉपी करते हैं, कुछ वैल्यू बदलते हैं, docker compose up चलाते हैं, और एक ऐसी ग़लती मिलती है जो एक बिल्कुल ठीक दिखने वाली लाइन की ओर इशारा करती है। या उससे भी बुरा, कोई ग़लती नहीं: स्टैक शुरू हो जाता है, लेकिन एक service में चुपचाप उसका port या environment variables ग़ायब होते हैं। आधा घंटा indentation घूरने के बाद पता चलता है कि यह एक tab character था जो आपको दिख भी नहीं रहा था।

Docker Compose फ़ाइलें छोटी होती हैं, लेकिन YAML कोई ग़लती माफ़ नहीं करता, और Compose उसके ऊपर अपने नियम जोड़ता है। ज़्यादातर फ़ेल स्टैक की वजह गिनी-चुनी वही ग़लतियाँ होती हैं। ये रहीं वे, साथ में यह कि हर एक कैसी दिखती है और उसका सटीक हल।

Compose फ़ाइलें इतनी आसानी से क्यों टूटती हैं

Compose फ़ाइल YAML है, एक ऐसा फ़ॉर्मेट जिसमें indentation का मतलब होता है और एक अक्षर किसी वैल्यू का प्रकार बदल सकता है। उसके ऊपर, Compose एक ख़ास संरचना की उम्मीद करता है: एक services सेक्शन, हर service में image या build, और ऐसी options जिनकी स्पेलिंग बिल्कुल सही होनी चाहिए। जब YAML मान्य हो लेकिन संरचना ग़लत हो, तो Compose शिकायत करने के बजाय ग़लती को अनदेखा कर सकता है, और इसी तरह आपके पास ऐसा container रह जाता है जो शुरू तो होता है लेकिन ठीक से काम नहीं करता।

कुछ भी चलाने से पहले इनमें से ज़्यादातर पकड़ने का तेज़ तरीक़ा है फ़ाइल को Docker Compose Validator में पेस्ट करना। यह YAML को ठीक से parse करता है, सिंटैक्स ग़लतियाँ लाइन और कॉलम के साथ बताता है, और Compose संरचना जाँचता है: ग़ायब images, ग़लत लिखी keys, port फ़ॉर्मेट और depends_on में लिखी वे services जो मौजूद नहीं हैं।

ग़लती 1: indentation में tabs

YAML indentation के लिए सिर्फ़ spaces की अनुमति देता है। एक भी tab, जो अक्सर किसी एडिटर सेटिंग से या वेब पेज से कॉपी करने से आता है, पूरी फ़ाइल को अमान्य बना देता है। ग़लती का मैसेज आम तौर पर "found character that cannot start any token" कहता है, जो कुछ ख़ास मदद नहीं करता।

हल: अपने एडिटर को spaces डालने के लिए सेट करें, और सारे tabs बदल दें। हर स्तर के लिए दो spaces Compose का चलन है।

ग़लती 2: असंगत indentation

यह ज़्यादा चालाक है, क्योंकि फ़ाइल अब भी मान्य YAML हो सकती है, बस वह YAML नहीं जो आप चाहते थे। अगर ports को image से एक space कम indent किया गया है, तो वह service का हिस्सा नहीं रहता और पूरी तरह कुछ और बन जाता है।

services:
  web:
    image: nginx:alpine
   ports:
      - "8080:80"

हल: किसी service की हर option को बिल्कुल एक जैसे indentation पर रखें। ज़्यादातर एडिटर indentation guides दिखा सकते हैं, जिनसे यह साफ़ दिख जाता है।

ग़लती 3: बिना quote वाली port mappings

यह Compose का क्लासिक जाल है। YAML 1.1, जिसे कई parsers मानते हैं, colon वाली कुछ बिना quote की वैल्यू को base 60 के नंबर की तरह पढ़ सकता है। 22:22 जैसी mapping आपके लिखे टेक्स्ट के बजाय एक नंबर बन सकती है, और आपको port की एक उलझाने वाली ग़लती मिलती है।

हल: port mappings को हमेशा quote करें।

ports:
  - "8080:80"
  - "2222:22"

ग़लती 4: ग़लत लिखी keys

imagee, depends_no, enviroment, volumes की जगह volume। आपके Compose वर्ज़न के हिसाब से, अनजान key साफ़ ग़लती दिखा सकती है, या अनदेखी की जा सकती है, जिससे आपके पास ऐसी service रह जाती है जिसमें उसका कॉन्फ़िगरेशन ग़ायब है।

हल: key के नाम ध्यान से जाँचें, या यह काम किसी validator को करने दें। validator हर service key को जानी-पहचानी Compose options से मिलाता है, जिनमें profiles, secrets, configs और deploy जैसी आधुनिक options शामिल हैं, और कस्टम x- extension फ़ील्ड की अनुमति देता है।

ग़लती 5: बिना image और बिना build वाली service

हर service को पता होना चाहिए कि क्या चलाना है: या तो pull करने के लिए एक image या build करने के लिए एक build context। दोनों छोड़ देने पर, जो अक्सर नाम बदलने या refactoring के बाद होता है, ऐसी ग़लती आती है जिसे ग़लत समझना आसान है।

हल: service में image: name:tag या build: ./path जोड़ें।

ग़लती 6: depends_on ऐसी service की ओर इशारा करता है जो मौजूद नहीं

आप db service का नाम बदलकर postgres करते हैं लेकिन भूल जाते हैं कि web में अब भी depends_on: [db] लिखा है। Compose शुरू होने से मना कर देता है।

हल: पक्का करें कि depends_on में हर नाम उसी फ़ाइल में परिभाषित किसी service से मेल खाता है। याद रखें कि depends_on शुरू होने का क्रम तय करता है, तैयार होना नहीं: आपका ऐप डेटाबेस के कनेक्शन स्वीकार करने से पहले भी शुरू हो सकता है। अगर क्रम मायने रखता है, तो डेटाबेस पर healthcheck और condition: service_healthy इस्तेमाल करें।

ग़लती 7: environment variables के लिए list और map स्टाइल मिलाना

ये दोनों मान्य हैं:

environment:
  - POSTGRES_USER=app
  - POSTGRES_DB=app

environment:
  POSTGRES_USER: app
  POSTGRES_DB: app

एक ही ब्लॉक के अंदर दोनों को मिलाना मान्य नहीं है। यही बात labels पर भी लागू होती है।

हल: हर ब्लॉक के लिए एक स्टाइल चुनें। map स्टाइल पढ़ने और एडिट करने में आसान है।

ग़लती 8: पुरानी version key

कई ट्यूटोरियल version: '3.8' से शुरू होते हैं। Compose v2 अब इसका इस्तेमाल नहीं करता और चेतावनी देता है कि यह obsolete है। आम तौर पर इससे कुछ टूटता नहीं, लेकिन यह फ़ालतू शोर है, और संकेत देता है कि उदाहरण का बाक़ी हिस्सा भी पुराना हो सकता है।

हल: लाइन डिलीट कर दें। Compose Specification में कोई वर्ज़न नहीं है।

ग़लती 9: सीक्रेट सीधे फ़ाइल में लिखे हुए

यह सिंटैक्स की ग़लती नहीं, लेकिन कहीं ज़्यादा नुक़सान करने वाली ग़लती है: डेटाबेस पासवर्ड और API keys सीधे environment के नीचे लिखी हुई, और फिर Git में commit।

हल: सीक्रेट को एक ऐसी .env फ़ाइल में ले जाएँ जो commit नहीं होती, और उन्हें variables के रूप में इस्तेमाल करें, या Docker secrets इस्तेमाल करें। अगर किसी नए सीक्रेट के लिए आपको मज़बूत बेतरतीब वैल्यू चाहिए, तो Password Generator आपके ब्राउज़र में एक बना देता है।

environment:
  POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}

validator ${POSTGRES_PASSWORD} को टेक्स्ट के रूप में पढ़ता है; वह आपकी .env फ़ाइल नहीं देख सकता, इसलिए variables सिर्फ़ तब resolve होते हैं जब आप अपनी मशीन पर Compose चलाते हैं।

समय बचाने वाला तरीक़ा

1. फ़ाइल को Docker Compose Validator में पेस्ट करें और जो भी वह बताए, ऊपर से नीचे तक ठीक करें।
2. अपनी मशीन पर docker compose config चलाएँ। यह variables resolve करता है, override फ़ाइलें मिलाता है और वह आख़िरी कॉन्फ़िगरेशन दिखाता है जो Compose असल में इस्तेमाल करेगा।
3. docker compose up से स्टैक शुरू करें और हर service के logs देखें।
4. जाँचें कि आपने क्या खोला है। अगर किसी service तक बाहर से पहुँचना है, तो Ping & Uptime Checker में TCP जाँच से किसी दूसरे नेटवर्क से port टेस्ट करें।

अगर बीच में आप कॉन्फ़िगरेशन को एक फ़ॉर्मेट से दूसरे में बदल रहे हैं, जैसे किसी दूसरे टूल के लिए YAML उदाहरण को JSON में, तो YAML to JSON converter आपको संरचना साफ़ देखने में मदद करता है।

बिना घबराए YAML की ग़लतियाँ पढ़ना

YAML के ग़लती वाले मैसेज उस जगह की ओर इशारा करते हैं जहाँ parser ने हार मानी, जो अक्सर असली ग़लती से एक-दो लाइन बाद होती है। जब कोई ग़लती बिल्कुल ठीक लाइन की ओर इशारा करती लगे, तो उसके ठीक ऊपर देखें: कोई बिना बंद quote, ग़ायब colon, या अपने पड़ोसियों से अलग indent की गई लाइन।

यह याद रखना भी मदद करता है कि Compose की ज़्यादातर समस्याएँ दो समूहों में आती हैं। या तो फ़ाइल मान्य YAML ही नहीं है (tabs, indentation, quotes), या वह मान्य YAML है लेकिन ग़लत आकार की (ग़ायब image, ग़लत लिखी key, टूटा depends_on)। दोनों जाँचने वाला validator आपको दूसरे समूह से बचाता है, जो चुपचाप फ़ेल होता है।

छोटी आदतें जो ज़्यादातर ग़लतियाँ रोकती हैं

• दो spaces से indent करें, कभी tabs से नहीं।
• हर port mapping को quote करें।
• सीक्रेट को फ़ाइल से बाहर और Git से बाहर रखें।
• पुराने उदाहरणों से version वाली लाइन डिलीट करें।
• चलाने से पहले validate करें, फिर आख़िरी फ़ैसला docker compose config को करने दें।

इन जाँचों को पास करने वाली Compose फ़ाइल आम तौर पर बस चल जाती है। और जब नहीं चलती, तो आपको पता होगा कि समस्या आपके ऐप्लिकेशन में है, किसी ऐसे अक्षर में नहीं जो आपको दिख नहीं रहा था।

अगर यह किसी बड़े सर्वर सेटअप का हिस्सा है, तो DNS रिकॉर्ड पर हमारी गाइड अगला क़दम बताती है: अभी डिप्लॉय किए स्टैक की ओर डोमेन करना।