Docker सिस्टम स्थिति: सभी सेवाएँ बंद

• Docker के प्रमुख सेवाओं में व्यापक आउटेज हुआ
• कारण क्लाउड सेवा प्रदाता से संबंधित मुद्दा पाया गया
• SaaS सेवाओं में पूरे स्तर पर त्रुटि दर दर्ज की गई
• त्रुटि सुधार के बाद बैकलॉग प्रोसेसिंग और मॉनिटरिंग चरण शुरू हुए
• अंततः समस्या हल होने और सामान्य स्थिति की घोषणा की गई

---

Docker सिस्टम समस्या का अवलोकन

Docker Hub Registry, Docker Authentication, Docker Hub Web Services, Docker Billing, Docker Hub Automated Builds, Docker Hub Security Scanning, Docker Scout, Docker Build Cloud, Testcontainers Cloud, Docker Cloud, Docker Hardened Images सहित कई Docker सेवाओं में व्यापक स्तर पर एक्सेस और उपयोग संबंधी समस्या देखी गई।

20 अक्टूबर 2025, 00:16 PDT / 07:16 UTC

[जाँच जारी]
कई उत्पाद सेवाओं में व्यापक स्तर पर कनेक्शन व उपयोग संबंधी समस्याओं के कारण कारण-जांच शुरू की गई।

20 अक्टूबर 2025, 01:22 PDT / 08:22 UTC

[समस्या की पहचान]
क्लाउड सेवा प्रदाता से जुड़ी समस्या के कारण आउटेज का कारण पता चला।
जब तक सेवा प्रदाता की समस्या हल न हो, अपनी प्रणाली की तैयारी और मॉनिटरिंग जारी रखी गई।

20 अक्टूबर 2025, 02:43 PDT / 09:43 UTC

[निगरानी]
सभी SaaS सेवाओं में त्रुटि दर धीरे-धीरे सुधरने का रुझान दिखाई दिया।
बैकलॉग हैंडलिंग के साथ निरंतर स्थिति मॉनिटरिंग जारी रखी गई।

20 अक्टूबर 2025, 03:05 PDT / 10:05 UTC

[समाधान]
इस आउटेज को आधिकारिक तौर पर हल घोषित किया गया।
सेवाओं की संपूर्ण सामान्य स्थिति की पुष्टि की गई।

[GN⁺]

Hacker News टिप्पणी

• नमस्ते, मैं Docker के Tushar हूँ। अभी AWS संबंधित समस्या के कारण हुए Docker सेवा बंद होने की स्थिति के लिए मैं माफ़ी चाहता हूँ। हमारी टीम AWS के साथ मिलकर सेवा को जितनी जल्दी हो सके बहाल करने की कोशिश कर रही है। dockerstatus.com पर अपडेट लगातार जारी हैं। Docker Hub और हमारी सेवा का दुनिया भर के लाखों डेवलपर्स के लिए कितना महत्व है, यह हम समझते हैं। हम तेज़ बहाली के लिए पूरी कोशिश करेंगे। यह मामला पूरी तरह सुलझने के बाद हम आगे की प्रतिक्रिया के साथ एक विस्तृत पोस्टमॉर्टेम भी पोस्ट करेंगे।
  • मेरे मन में एक अजीब-सा सवाल आया—यदि वही श्रृंखला-प्रतिक्रिया शुरू करने वाली DynamoDB कहीं Docker Hub पर Docker image के रूप में hosted हो, तो दृश्य और भी रोचक होता।
• यह AWS आउटेज का परिणाम है। संदर्भ लिंक
  • कोई अगर कहता है कि "एक cloud service provider में मौलिक समस्या मिली", तो आजकल अधिकांश लोग multi-cloud इस्तेमाल करते हैं। फिर एक ही provider की गड़बड़ी से इतना असर क्यों पड़ा, यह समझना कठिन है।
• हमने भी कई public Docker images पर निर्भर रहकर काम किया है, और सामान्यतः Docker का डिफ़ॉल्ट docker.io उपयोग करके build टूट गया। सौभाग्य से AWS ने docker.io mirror सेवा दी, इसलिए FROM public.ecr.aws/docker/library/{image_name} को बदलने पर सभी build ठीक से चल पड़े। एरर लॉग में अधिकतर https://auth.docker.io पर auth endpoint से "कोई server request process नहीं कर सकता" जैसी समस्या दिख रही थी। AWS mirror पर स्विच करने के बाद बिना किसी समस्या के build सफल हुए।
  • Docker खुद AWS आउटेज से नीचे था, जबकि AWS mirror repository ठीक चल रही थी—यह थोड़ा ironic लगा।
  • docker.io पर rate limits भी होते हैं, इसलिए जैसे-जैसे कोई संगठन grow करता है, build failures बढ़ने लगते हैं। वैसे आज पूरा दिन Quay.io (Red Hat-owned) भी read-only स्थिति में रहा। अगर आपकी container image dependency अधिक है, तो बिना किसी और के भरोसे बैठने की बजाय proper image-hosting solution रखना बेहतर है।
  • public.ecr.aws भी आज AWS आउटेज की वजह से मेरे लिए 5XX errors दे रहा था, यानी pulls fail हो रहे थे। संदर्भ लिंक
  • यह तरीका मेरे केस में काम नहीं आया, लेकिन Google mirror (mirror.gcr.io) से ठीक काम मिला। सिर्फ FROM {image_name} से बदलकर FROM mirror.gcr.io/{image_name} कर दें। उम्मीद है मदद मिलेगी। संबंधित गाइड
  • मैं एक बड़े build system को संभालता हूँ, और आज ECR पर image pull लगभग पूरे दिन unstable रहा।
• लोग जब Nexus जैसे self-hosted registry चलाते हैं और common base image से सीधे container build करते हैं, तो शायद आज वे अपने विकल्प पर अधिक भरोसा महसूस कर रहे होंगे। यह देखना दिलचस्प होगा कि इस outage ने कितने build और redeploy को कितना नुकसान पहुँचाया। Docker और Docker Hub के प्रति कोई नकारात्मकता नहीं—मैं अभी भी इन्हें बहुत उपयोगी रूप से इस्तेमाल करता हूँ।
  • docker image cache को बीच में रखना एक बहुत महत्वपूर्ण habit है। अगर docker अचानक upstream image हटाए/डाउन करे, तो K8s node replacement के समय base image नहीं मिलती और service चालू करना कठिन हो जाता है। यह सिर्फ engineering hygiene का सवाल है।
  • हम भी base image इस्तेमाल करते हैं, लेकिन GitHub Actions के preparation चरण में docker image खींचने के कारण application build होता है, लेकिन deploy नहीं हो पाता। CI/CD Docker Hub पर depend करता है, और कुछ images के लिए pull-through cache का path बदल नहीं सकता, इसलिए यह स्थिति बनी।
  • हमने Harbor चलाया है और Proxy Cache के जरिए सभी base image mirror कर रहे हैं; यह सेटअप हम कई सालों से ठीक से चला रहे हैं। Harbor के कुछ drawbacks हैं, लेकिन कुल मिलाकर हम काफी संतुष्ट हैं।
  • अगर कोई org बिल्कुल containers इस्तेमाल ही न करे, तो यह पल और भी राहत देता है।
  • बिना किसी manual workaround के dev या prod environment में नया काम शुरू न कर पाने की स्थिति थी। मुझे लगता है इसका असर काफी बड़ा था। शायद Signal में भी आज कोई issue था।
• AWS आउटेज अपडेट से ज़्यादा इस outage का HN main पर ऊपर दिखना ही काफी दिलचस्प था।
  • यह किसी वास्तविक गुप्त मुख्य पेज पर नहीं था! active page
• थोड़ा झिझक वाला प्रमोशनल पॉइंट जरूर है, लेकिन अगर Docker Hub पर dependency ज्यादा है तो Kubernetes cluster में Spegel install करने की सलाह दूँगा।
  • अगर यह सच में पूरी तरह open source है, तो landing page पर इसे और साफ तरीके से दिखाया जाना चाहिए। सीधे install करके तुरंत test कर पाना engineer के नजरिये से बड़ा फर्क डालता है, क्योंकि purchase process से होकर नहीं जाना पड़ता।
  • kuik से इसका फर्क समझना चाहूँगा। Spegel शायद मेरे homelab के लिए थोड़ा ज्यादा है, लेकिन कंपनी सेटअप के लिए अच्छा upgrade हो सकता है। Kuik: संदर्भ
  • Docker Hub के बाहर भी कई alternatives हैं जो ज्यादा repositories को mirror करते हैं। ज़्यादातर enterprise-level लगते हैं, लेकिन advertised फीचर्स सही तरीके से काम करते हैं। Artifactory, Nexus Repository, Cloudsmith, ProGet आदि इसी लाइन में हैं। इनकी वजह से हमने कई बार crisis से बाहर निकलना सीखा है।
  • Spegel अच्छा लगता है, लेकिन हम GKE use करते हैं इसलिए अभी केवल workaround-जैसा ही काम कर रहा है। GKE में इसे proper support कब मिलेगा, यह देखना बाकी है।
• यह किसी हद तक intentional design है।
  docker ने private registry सेट करने का विकल्प माँगने पर खुद के लिए यह फीचर नहीं दिया।
  संबंधित stackoverflow
  Red Hat ने docker-compatible Podman बनाकर इस जगह को fill कर दिया।
  /etc/config/docker:
  BLOCK_REGISTRY='--block-registry=all'
  ADD_REGISTRY='--add-registry=registry.access.redhat.com'
  • मुझे लगता है यह तर्क थोड़ा अतिरंजित है। अगर default registry को docker.io के बजाय कहीं और बदल भी दें, अधिकांश लोग ऐसा करने की झंझट नहीं करेंगे। सच पूछिए तो सही तरीके से image tags लगाना ही पर्याप्त है। हमारी कंपनी में एक भी image सीधे docker.io से pull नहीं होता; बस नाम के आगे <company-repo>/ जोड़ने में दो सेकंड लगते हैं।
  • मैं ऐसे 'footgun' को कुछ हद तक स्वीकार करने योग्य मानता हूँ। domain सहित image tag की अभिव्यक्ति से जो गलतफहमी हो सकती है, उससे ज्यादा लाभ है। उदाहरण के लिए, अगर टीम docs में command पुराना हो और docker config update न हो, तो गलती से global public registry से pull हो सकता है। मेरे हिसाब से बेहतर यह होगा कि global registry concept हटाकर साफ दिखाया जाए कि image कहाँ से आ रही है—हालाँकि Docker शायद इसे गंभीरता से नहीं लेगा।
  • जहाँ हमने us-east-1 region में ECR को private registry के रूप में इस्तेमाल किया था, वहाँ यह तरीका काम नहीं आया।
• Docker नीचे था, इसलिए O'Reilly पर login भी नहीं कर पाया; शायद इसलिए कि "Docker डाउन हो तो कुछ और सीख लो" वाला मेरा प्लान इसी कारण अटक गया।
  • हाल ही में use किए सभी packages को store करने के लिए pull-through proxy install कर देना काफी उपयोगी होगा।
• इसी समस्या वाले अन्य लोगों के लिए एक काम आया तरीका था ghcr इस्तेमाल करना। यह पूरी तरह से replacement नहीं है, पर उदाहरण के लिए: docker pull ghcr.io/linuxcontainers/debian-slim:latest
  • यह image एक साल से ज़्यादा समय से अपडेट नहीं हुई थी। संबंधित लिंक. Google Container Registry pull-through mirror देता है, इसलिए सिर्फ mirror.gcr.io को prefix लगाएं। Docker Official Images में user नाम की जगह library उपयोग करके जैसे mirror.gcr.io/library/redis लिखें। redis official page
• 20 अक्टूबर 2025, 09:43 UTC के हिसाब से धीरे-धीरे recovery चल रही है। कुल मिलाकर SaaS सेवाओं में error rate नीचे आता दिख रहा है। हम backlog clear करते हुए स्थिति को लगातार monitor कर रहे हैं।