Docker Pull: रजिस्ट्रियाँ, प्रमाणीकरण, और ट्रबलशूटिंग

docker pull कमांड अपने-आप में काफी स्पष्ट है, लेकिन पृष्ठभूमि में बहुत कुछ होता है, जिसे अनुभवी विशेषज्ञ भी हमेशा नहीं जानते।

हर डेवलपर को यह पता होना चाहिए। आप रोज़ाना इमेज खींचते हैं, लेकिन जब कुछ टूटता है, तो कारण ढूँढ़ना कठिन हो जाता है। या तो बिना स्पष्ट वजह के प्रमाणीकरण विफल हो जाता है, या रेट लिमिट लागू हो जाती है, या प्रोडक्शन में गलत इमेज वर्ज़न पहुँच जाता है। प्रत्येक विफलता आपके दिन का समय लेती है, जबकि ऐसा होना ही नहीं चाहिए था।

यह समझना कि docker pull वास्तव में कैसे काम करता है, आपको नियंत्रण देगा। आप जानेंगे कि इमेज कहाँ से आती हैं, उन्हें कैसे खींचना है, और प्रोडक्शन तक पहुँचने से पहले समस्याओं का ट्रबलशूट कैसे करना है।

इस लेख में, मैं बताऊँगा कि अंदरखाने इमेज पुलिंग कैसे काम करती है, रजिस्ट्रियाँ कैसे शामिल होती हैं, और लोकल डेवलपमेंट व प्रोडक्शन परिवेश दोनों में इमेज कैसे खींचें।

यदि आप Docker में बिलकुल नए हैं, तो मैं आपको हमारे Introduction to Docker कोर्स से गुज़रने की सिफारिश करूँगा, क्योंकि यह इस लेख को समझने के लिए ज़रूरी बुनियादी बातें कवर करता है।

पर्दे के पीछे docker pull कैसे काम करता है

इस खंड में, मैं docker pull कमांड की यांत्रिकी पर जाऊँगा और पर्दे के पीछे क्या होता है, उस पर किसी भी भ्रम को दूर करूँगा।

docker pull के दौरान क्या होता है

बेसिक सिंटैक्स सरल है:

docker pull python:3.14.2-bookworm

यह कमांड डिफ़ॉल्ट रूप से Docker Hub से बात करता है, Python इमेज डाउनलोड करता है, और उसे आपकी मशीन पर लोकली स्टोर कर देता है। लेकिन दिखने से कहीं अधिक कुछ और भी चल रहा होता है।

फ़्लो इस प्रकार है:

• आपका Docker क्लाइंट रजिस्ट्री को रिक्वेस्ट भेजता है (Docker Hub, जब तक आप कुछ और निर्दिष्ट न करें)

• रजिस्ट्री इमेज मैनिफेस्ट के साथ जवाब देती है, जिसमें उन सभी लेयर्स की सूची होती है जो इमेज बनाती हैं

• फिर आपका क्लाइंट हर वह लेयर डाउनलोड करता है जो उसके पास पहले से नहीं है, और उन्हें Linux सिस्टम पर /var/lib/docker में, तथा Docker Desktop द्वारा प्रबंधित डायरेक्टरीज़ में स्टोर करता है (उदाहरण के लिए, macOS पर ~Library/Containers/… के अंतर्गत और Windows पर C:\Users\[Username]\AppData\... के अंतर्गत)।

जब आप संस्करण निर्दिष्ट नहीं करते, तो :latest टैग Docker का डिफ़ॉल्ट होता है। docker pull python बिना टैग के चलाएँ, और आपको python:latest मिलेगा। यह सुविधाजनक लगता है, लेकिन जोखिमभरा है। :latest का मतलब "सबसे नवीनतम स्थिर संस्करण" नहीं है। इसका अर्थ है "जो भी इमेज मेंटेनर ने latest के रूप में टैग किया है"। यह पुल्स के बीच बदल सकता है और बिना चेतावनी के आपके बिल्ड तोड़ सकता है।

इमेज लेयर्स और कंटेंट-एड्रेसेबल स्टोरेज

Docker इमेज लेयर्स से बनी होती हैं।

हर लेयर पिछली से एक परिवर्तन का प्रतिनिधित्व करती है। जब आप इमेज बनाते हैं, तो आपके Dockerfile में हर RUN, COPY, या ADD निर्देश एक नई लेयर बनाता है। फाइनल इमेज इन्हीं लेयर्स का क्रमबद्ध स्टैक होती है।

उदाहरण के लिए, ऊपर वाली Python 3.14 इमेज के पीछे के कमांड्स पर नज़र डालें - काफी कुछ चल रहा है।

कंटेंट-एड्रेसेबल स्टोरेज यह सब संभव बनाता है। हर लेयर को उसकी सामग्री के आधार पर एक यूनिक हैश मिलता है। यदि दो इमेज एक ही बेस लेयर साझा करती हैं (जैसे ubuntu:24.04), तो Docker उस लेयर को केवल एक बार स्टोर करता है। जब आप कोई नई इमेज खींचते हैं जो वही बेस इस्तेमाल करती है, Docker उसे डाउनलोड करना छोड़ देता है।

इससे बैंडविड्थ और स्टोरेज की बचत होती है। अलग-अलग टैग्स वाली दस Python इमेज खींचें, और Docker उन सबमें कामन लेयर्स का पुन: उपयोग कर लेता है। आपको केवल वही डाउनलोड करना पड़ता है जो वास्तव में अलग है।

docker pull बनाम docker image pull

दोनों कमांड फंक्शनली समान हैं। ये रजिस्ट्रियों से इमेज खींचते हैं और उन्हें लोकली स्टोर करते हैं।

अंतर संगठनात्मक है। Docker ने CLI को अधिक सहज बनाने के लिए docker image कमांड समूह पेश किया। ताकि docker pull, docker rmi और docker images इधर-उधर बिखरे रहने के बजाय, इमेज-संबंधी कमांड्स को docker image pull, docker image rm और docker image ls के तहत समूहित किया गया।

जो चाहें उपयोग करें। docker pull छोटा है और डॉक्यूमेंटेशन में अधिक सामान्य है। docker image pull अधिक स्पष्ट है और उन स्क्रिप्ट्स में बेहतर बैठता है जहाँ स्पष्टता मायने रखती है। एक शैली चुनें और अपनी टीम में उसी पर टिके रहें।

Docker इमेज रेफ़रेंस समझाया गया

किसी इमेज रेफ़रेंस में अधिकतम पाँच हिस्से हो सकते हैं: HOST/NAMESPACE/REPOSITORY:TAG@DIGEST.

हर हिस्से का अर्थ यह है:

• HOST: रजिस्ट्री का पता (जैसे, docker.io, gcr.io, quay.io)। यदि छोड़ दें, तो Docker डिफ़ॉल्ट रूप से Docker Hub लेता है।

• NAMESPACE: आमतौर पर आपका यूज़रनेम या संगठन (जैसे, आधिकारिक इमेज के लिए library, या निजी इमेज के लिए mycompany)।

• REPOSITORY: वास्तविक इमेज नाम (जैसे, python, nginx, redis)।

• TAG: संस्करण पहचानकर्ता (जैसे, 3.14.2-bookworm, latest)। यदि आप इसे छोड़ते हैं तो डिफ़ॉल्ट :latest होता है।

• DIGEST: इमेज मैनिफेस्ट का SHA256 हैश (जैसे, @sha256:abc123...)। यह अपरिवर्तनीय होता है - टैग बदल सकते हैं, डाइजेस्ट नहीं।

अधिकांश पुल इस तरह दिखते हैं:

docker pull python:3.14.2-bookworm

यह परदे के पीछे docker.io/library/python:3.14.2-bookworm में विस्तारित हो जाता है।

निजी रजिस्ट्रियों के लिए, आपको पूरा रेफ़रेंस चाहिए:

docker pull myregistry.example.com/myteam/myimage

सटीक रेफ़रेंस (विशिष्ट टैग या डाइजेस्ट) उपयोग करना आपकी डिप्लॉयमेंट्स को पुनरुत्पादन योग्य रखता है। आज और अगले महीने python:3.14.2-bookworm खींचें, और आपको वही इमेज मिलेगी। python:latest दो बार खींचें, और बहुत संभव है कि नहीं मिले।

Docker रजिस्ट्रियाँ और इमेज कहाँ से आती हैं

रजिस्ट्रियाँ वे जगहें हैं जहाँ Docker इमेज को स्टोर और वितरित करता है - आप जो भी docker pull कमांड चलाते हैं, उसका स्रोत वही हैं।

डिफ़ॉल्ट रजिस्ट्री के रूप में Docker Hub

जब तक आप कुछ और निर्दिष्ट नहीं करते, सभी docker pull कमांड्स के लिए Docker Hub डिफ़ॉल्ट रजिस्ट्री है।

docker pull python:3.14.2-bookworm चलाएँ, और Docker इसे अपने-आप docker.io/library/python:3.14.2-bookworm में अनुदित कर देता है। सार्वजनिक इमेज के लिए आपको लॉगिन की ज़रूरत नहीं - Docker Hub उन्हें अनाम रूप से सर्व करता है, हालाँकि बिना प्रमाणीकरण वाले उपयोगकर्ताओं के लिए रेट लिमिट होती है।

Docker Hub पर दो प्रकार की इमेज होती हैं: Official Images और community images।

• Official Images सत्यापित पब्लिशर्स से आती हैं और Docker या सॉफ़्टवेयर वेंडर्स स्वयं उन्हें मेंटेन करते हैं। ये library नेमस्पेस के अंतर्गत रहती हैं (जिसे Docker आपसे छुपा देता है)। जब आप python, nginx, या redis खींचते हैं, तो आपको Official Images मिलती हैं जो सुरक्षा और नियमित अपडेट्स के लिए Docker की सर्वोत्तम प्रथाओं का पालन करती हैं।

• Community images बाकी सब हैं। कोई भी अपने यूज़रनेम या संगठन के अंतर्गत Docker Hub पर इमेज प्रकाशित कर सकता है। johndoe/python-custom खींचें, और आप भरोसा कर रहे हैं कि johndoe उस इमेज को ठीक से मेंटेन करता है। कुछ कम्युनिटी इमेज शानदार हैं और अच्छी तरह से मेंटेन की गई हैं। अन्य वर्षों से अपडेट नहीं हुईं और ज्ञात कमजोरियाँ रखती हैं।

यहाँ भरोसा मायने रखता है। Official Images को नियमित सुरक्षा पैच मिलते हैं और स्पष्ट डॉक्यूमेंटेशन होता है। लेकिन कम्युनिटी इमेज के साथ, आपको खुद सत्यापित करना होता है कि उन्हें कौन मेंटेन करता है और वे उपयोग के लिए सुरक्षित हैं या नहीं।

निजी और कस्टम रजिस्ट्रियाँ

अधिकांश कंपनियाँ नहीं चाहतीं कि उनकी कंटेनर इमेज सार्वजनिक Docker Hub पर पड़ी रहें।

निजी रजिस्ट्रियाँ ही समाधान हैं। आप तय करते हैं कि कौन इमेज खींच सकता है, आप रिटेन्शन नीतियाँ नियंत्रित करते हैं, और स्वामित्त्व वाला कोड अपनी इन्फ्रास्ट्रक्चर के अंदर रखते हैं। यह अनुपालन, सुरक्षा, और टीमों में एक्सेस मैनेजमेंट के लिए अहम है।

सामान्य निजी रजिस्ट्री समाधान शामिल हैं:

• Harbor: इनबिल्ट सुरक्षा स्कैनिंग और एक्सेस कंट्रोल वाली ओपन-सोर्स रजिस्ट्री
• JFrog Artifactory: एंटरप्राइज़ समाधान जो Docker इमेज के साथ अन्य आर्टिफैक्ट प्रकार भी संभालता है
• क्लाउड रजिस्ट्रियाँ: AWS ECR, Google Container Registry (GCR), Azure Container Registry (ACR)

बेशक, कस्टम रजिस्ट्री का उपयोग करते समय इमेज रेफ़रेंस बदल जाएँगे। python:3.14.2-bookworm की जगह अब आपको पूरा पाथ बताना होगा:

docker pull myregistry.company.com/team/python:3.14.2-bookworm

पहले रजिस्ट्री होस्टनेम आता है, फिर आपका नेमस्पेस (आमतौर पर टीम या प्रोजेक्ट का नाम), फिर रेपोजिटरी और टैग। जब Docker को कस्टम होस्टनेम दिखता है, तो वह Docker Hub पर डिफ़ॉल्ट नहीं करता - सीधे आपकी निजी रजिस्ट्री पर जाता है।

प्रमाणीकरण, रेट लिमिट, और एक्सेस कंट्रोल

प्रमाणीकरण इमेज पुश और पुल दोनों के लिए होता है, और जब आप रेट लिमिट पर पहुँचते हैं या निजी रजिस्ट्री एक्सेस करते हैं, तब यह विशेष रूप से महत्वपूर्ण हो जाता है।

लॉगिन करना और क्रेडेंशियल्स प्रबंधित करना

आप docker login कमांड का उपयोग करके किसी रजिस्ट्री के साथ प्रमाणीकरण कर सकते हैं:

docker login

यह आपसे Docker Hub यूज़रनेम और पासवर्ड माँगेगा। निजी रजिस्ट्री के लिए, बस होस्टनेम निर्दिष्ट करें:

docker login myregistry.company.com

लॉगिन के बाद Docker आपके क्रेडेंशियल्स लोकली स्टोर करता है। Linux पर ये ~/.docker/config.json में जाते हैं। macOS पर, बेहतर सुरक्षा के लिए Docker सिस्टम कीचेन का उपयोग करता है।

समस्या यह है कि यह कॉन्फ़िग फ़ाइल डिफ़ॉल्ट रूप से क्रेडेंशियल्स को base64 एन्कोडिंग में स्टोर करती है, जो एन्क्रिप्शन नहीं है। आपके होम डायरेक्टरी तक पहुँच रखने वाला कोई भी उन्हें डिकोड कर सकता है। शमन के लिए, आप क्रेडेंशियल हेल्पर का उपयोग कर सकते हैं - Docker नेटिव OS कीचेन को सपोर्ट करता है जो पासवर्ड सुरक्षित रूप से स्टोर करते हैं।

क्रेडेंशियल प्रबंधन के लिए कुछ सर्वोत्तम प्रथाएँ यहाँ हैं:

• क्रेडेंशियल हेल्पर्स का उपयोग करें (docker-credential-osxkeychain, docker-credential-wincred)

• config.json को कभी भी वर्ज़न कंट्रोल में कमिट न करें

• जहाँ संभव हो पासवर्ड की बजाय एक्सेस टोकन का उपयोग करें

• क्रेडेंशियल्स को नियमित रूप से रोटेट करें, खासकर साझा खातों के लिए

Docker Hub रेट लिमिट

Docker Hub एक समय खिड़की के भीतर आप कितनी इमेज खींच सकते हैं, उस पर सीमा लगाता है।

अनाम उपयोगकर्ताओं (कोई लॉगिन नहीं) को प्रति IP पता छह घंटों में 100 पुल मिलते हैं। प्रमाणित नि:शुल्क उपयोगकर्ताओं को छह घंटों में 200 पुल मिलते हैं। पेड प्लान्स में स्तर के अनुसार अधिक ऊँची या असीमित लिमिट मिलती है।

ये सीमाएँ तब महत्वपूर्ण हो जाती हैं जब आप CI/CD पाइपलाइन्स चला रहे हों, डेवलपमेंट के दौरान बार-बार इमेज खींच रहे हों, या साझा इन्फ्रास्ट्रक्चर पर काम कर रहे हों जहाँ कई उपयोगकर्ता एक ही IP साझा करते हैं। जब आप सीमा तक पहुँच जाते हैं, तो आपकी पुल विफल होंगी जब तक कि विंडो रीसेट न हो जाए।

आप अपनी वर्तमान रेट लिमिट स्थिति की जाँच कर सकते हैं:

TOKEN=$(curl "<https://auth.docker.io/token?service=registry.docker.io&scope=repository:ratelimitpreview/test:pull>" | jq -r .token)
curl --head -H "Authorization: Bearer $TOKEN" <https://registry-1.docker.io/v2/ratelimitpreview/test/manifests/latest>

रेट लिमिट बढ़ाने के कुछ तरीके यहाँ हैं (ज्यादातर डेवलपर्स के लिए यह मुद्दा नहीं होगा):

• अपने पुल्स को प्रमाणित करें: लॉगिन करें ताकि ऊँची लिमिट मिल सके, भले ही फ्री अकाउंट हो
• रजिस्ट्री मिरर्स का उपयोग करें: एक पुल-थ्रू कैश सेट करें जो इमेज को लोकली स्टोर करे
• निजी रजिस्ट्री अपनाएँ: अपनी रजिस्ट्री होस्ट करें ताकि Docker Hub लिमिट से पूरी तरह बचा जा सके
• इमेज लोकली कैश करें: एक बार पुल करें, बार-बार उपयोग करें; बार-बार पुल करने से बचें

सबसे आसान उपाय बस लॉगिन करना है। यही कदम आपकी रेट लिमिट दोगुनी कर देता है।

उन्नत इमेज पुलिंग विकल्प

ये उन्नत विकल्प आपको सटीकता और नियंत्रण देते हैं, जो प्रोडक्शन परिवेश में बिल्कुल आवश्यक है।

डाइजेस्ट के आधार पर इमेज खींचना

डाइजेस्ट इमेज के कंटेंट हैश पर आधारित अपरिवर्तनीय पहचानकर्ता होते हैं।

टैग बदल सकते हैं। कोई व्यक्ति उसी टैग के साथ नई इमेज पुश कर देता है, और अचानक python:3.14.2-bookworm कल की तुलना में अलग कंटेंट की ओर इशारा करता है। डाइजेस्ट नहीं बदल सकते - वे इमेज मैनिफेस्ट के SHA256 हैश होते हैं। वही डाइजेस्ट का मतलब हमेशा वही सटीक इमेज।

डाइजेस्ट से पुल ऐसे करें:

docker pull python@sha256:6d58c1a9444bc2664f0fa20c43a592fcdb2698eb9a9c32257516538a2746c19a

docker pull --platform linux/amd64 python:3.14.2-bookworm

यह बात CI/CD और प्रोडक्शन में सबसे अधिक मायने रखती है। आप किसी विशिष्ट इमेज पर टेस्ट करते हैं, आप वही सटीक इमेज डिप्लॉय करते हैं। कोई आश्चर्य नहीं, परिवेशों के बीच कोई ड्रिफ्ट नहीं। यदि आपकी डिप्लॉयमेंट किसी विशिष्ट संस्करण पर निर्भर है, तो टैग नहीं - डाइजेस्ट का उपयोग करें।

मल्टी-आर्किटेक्चर इमेज पुल्स

मल्टी-आर्क इमेज एक ही इमेज रेफ़रेंस में अलग-अलग CPU आर्किटेक्चर के लिए संस्करणों को बंडल करती हैं।

python:3.14.2-bookworm खींचें, और Docker अपने-आप आपके सिस्टम के लिए सही संस्करण चुन लेता है - x86 मशीनों के लिए amd64, Apple Silicon या ARM सर्वर्स के लिए arm64। रजिस्ट्री बिना आपके कुछ किए सही आर्किटेक्चर सर्व करती है।

लेकिन कभी-कभी आपको किसी विशिष्ट आर्किटेक्चर की आवश्यकता होती है। --platform फ़्लैग का उपयोग करें:

docker pull --platform linux/amd64 python:3.14.2-bookworm

यह तब उपयोगी है जब आप Apple Silicon पर डेवलप कर रहे हों पर प्रोडक्शन में चलने वाले amd64 संस्करण का परीक्षण करना हो, या जब आप अपने बिल्ड मशीन से अलग आर्किटेक्चर के लिए इमेज बना रहे हों।

एकाधिक टैग खींचना

--all-tags फ़्लैग किसी रेपोजिटरी के सभी टैग खींच लेता है:

docker pull --all-tags python

यह सभी Python टैग्स डाउनलोड कर देता है - दर्जनों संस्करण, वैरिएंट्स, और आर्किटेक्चर। आपके पास गीगाबाइट्स में इमेज इकट्ठी हो जाएँगी।

जब तक वास्तव में ज़रूरत न हो, इसका उपयोग न करें। बैंडविड्थ की लागत होती है, स्टोरेज जल्दी भरता है, और आपको शायद हर एक पुराने से पुराना Python संस्करण नहीं चाहिए। इसके बजाय वे विशिष्ट टैग्स खींचें जिनका आप वास्तव में उपयोग करते हैं।

किसी पुल को रद्द करना

प्रगति पर चल रहे पुल को रद्द करने के लिए Ctrl+C या CMD+C दबाएँ।

Docker नई लेयर्स डाउनलोड करना बंद कर देता है, लेकिन जो लेयर्स वह पहले ही पूरी कर चुका है, उन्हें रखता है। अगली बार जब आप वही इमेज खींचेंगे, तो यह शुरू से शुरू करने के बजाय वहीं से फिर शुरू कर देगा जहाँ छोड़ा था।

यह तब उपयोगी है जब आपने गलती से गलत इमेज खींचना शुरू कर दिया हो, जब धीमे कनेक्शन पर पुल में बहुत समय लग रहा हो, या जब आपको एहसास हो कि अभी वास्तव में उस इमेज की ज़रूरत नहीं है। इसे रद्द करें, अपना कमांड ठीक करें, और पहले से किए गए काम को बर्बाद किए बिना फिर से पुल करें।

docker pull के साथ परफॉर्मेंस संबंधी विचार 

वास्तविक दुनिया के नेटवर्क में सीमाएँ होती हैं, जैसे बैंडविड्थ लिमिट, प्रॉक्सी, और धीमे कनेक्शन। ये इमेज पुल्स को अपेक्षा से अधिक समय ले सकते हैं, तो आइए देखें आप क्या कर सकते हैं।

पुल परफॉर्मेंस का अनुकूलन

Docker डिफ़ॉल्ट रूप से इमेज लेयर्स को समांतर रूप से डाउनलोड करता है।

एक समय में एक लेयर खींचने के बजाय, Docker कई कनेक्शन खोलता है और एक साथ कई लेयर्स डाउनलोड करता है। यह तेज़ कनेक्शन्स पर पुल्स को तेज़ करता है, लेकिन धीमे नेटवर्क पर जहाँ बैंडविड्थ बाधा है, वहाँ अंतर कम दिखेगा।

दो आम रणनीतियाँ और मदद करती हैं:

• कैशिंग खींची गई इमेज को लोकली स्टोर रखती है। एक बार इमेज खींचें, सैकड़ों बार उपयोग करें। Docker डाउनलोड करने से पहले जाँचता है कि आपके पास पहले से लेयर्स हैं या नहीं। यदि इमेज नहीं बदली है, तो पुल तुरंत पूरा हो जाता है।
• प्रीलोडिंग का मतलब है ऑफ-पीक घंटों में या आपकी डिप्लॉयमेंट प्रक्रिया के हिस्से के रूप में इमेज खींचना। CI/CD सिस्टम अक्सर बिल्ड एजेंट्स पर बेस इमेज को कैश करते हैं ताकि डेवलपर्स को हर बिल्ड चलाते समय पुल का इंतज़ार न करना पड़े। प्रोडक्शन सर्वर डिप्लॉयमेंट के दौरान अपने कैश को वार्म कर सकते हैं ताकि ट्रैफ़िक आने पर इमेज खींचने से बचा जा सके।

प्रॉक्सी के पीछे इमेज खींचना

कॉर्पोरेट नेटवर्क सुरक्षा, मॉनिटरिंग, और एक्सेस कंट्रोल के लिए ट्रैफ़िक को प्रॉक्सी के माध्यम से रूट करते हैं।

इमेज खींचने के लिए Docker को इन प्रॉक्सी के बारे में पता होना चाहिए। बिना प्रॉक्सी कॉन्फ़िगरेशन के, पुल कनेक्शन टाइमआउट या DNS त्रुटियों के साथ विफल हो जाते हैं क्योंकि Docker रजिस्ट्रियों तक सीधे पहुँचने की कोशिश करता है, प्रॉक्सी के माध्यम से नहीं।

आप दो स्तरों पर प्रॉक्सी कॉन्फ़िगर करते हैं: Docker क्लाइंट और Docker डेमन। क्लाइंट (आपका docker कमांड) अपने-आप आपके सिस्टम की HTTP प्रॉक्सी सेटिंग्स का उपयोग करता है। डेमन को /etc/docker/daemon.json में या systemd सर्विस फ़ाइलों के माध्यम से स्पष्ट कॉन्फ़िगरेशन की आवश्यकता होती है।

आम पुल समस्याओं का ट्रबलशूटिंग

जब पुल विफल हों - जो होंगी - तब के लिए यहाँ एक व्यावहारिक चेकलिस्ट है, ताकि आप जानें पहले क्या जाँचना है।

आम त्रुटियाँ और उनका निदान कैसे करें

प्रमाणीकरण विफलताएँ "unauthorized" या "access denied" त्रुटियों के रूप में दिखती हैं।

जाँचें कि आप docker login से लॉगिन हैं या नहीं। यदि हैं, तो आपके क्रेडेंशियल्स की समय-सीमा समाप्त हो चुकी हो सकती है या वे गलत हो सकते हैं। docker logout से लॉगआउट करें, फिर दोबारा लॉगिन करें। निजी रजिस्ट्री के लिए, सुनिश्चित करें कि आप अपने लॉगिन कमांड में सही होस्टनेम का उपयोग कर रहे हैं।

मिसिंग टैग्स आपको "manifest unknown" या "not found" त्रुटियाँ देते हैं।

टैग मौजूद नहीं है। टैग नाम को दोबारा जाँचें क्योंकि टाइपो आम हैं। रजिस्ट्री के वेब इंटरफ़ेस में देखें कि वास्तव में कौन-से टैग मौजूद हैं। याद रखें कि टैग हटाए भी जा सकते हैं, इसलिए जो कल काम करता था वह आज उपलब्ध न हो।

नेटवर्क टाइमआउट तब होते हैं जब Docker रजिस्ट्री तक नहीं पहुँच पाता।

पहले, अपना इंटरनेट कनेक्शन जाँचें। फिर सत्यापित करें कि आप रजिस्ट्री तक सीधे पहुँच सकते हैं - ping registry-1.docker.io या curl -I <https://registry-1.docker.io> चलाएँ। यदि आप प्रॉक्सी के पीछे हैं, तो सुनिश्चित करें कि Docker को उसके बारे में पता है। यदि रजिस्ट्री निजी है, तो फ़ायरवॉल नियम और VPN कनेक्शन जाँचें।

परमिशन समस्याएँ "denied" त्रुटि के रूप में दिखती हैं, भले ही आप प्रमाणित हों।

आप लॉगिन हैं, लेकिन आपके खाते को इस विशिष्ट रेपोजिटरी के लिए पुल एक्सेस नहीं है। एक्सेस पाने के लिए रेपोजिटरी मालिक या अपने रजिस्ट्री प्रशासक से संपर्क करें। Docker Hub पर, इसका अर्थ आमतौर पर यह होता है कि इमेज निजी है और आप एक्सेस सूची में नहीं हैं।

DNS और नेटवर्क रेजॉल्यूशन समस्याएँ

DNS विफलताएँ Docker को रजिस्ट्री सर्वर खोजने से रोकती हैं।

आपको "no such host" या "temporary failure in name resolution" जैसी त्रुटियाँ दिखेंगी। वास्तव में होता यह है कि Docker रजिस्ट्री होस्टनेम को IP पते में अनुवाद नहीं कर पाता, इसलिए कनेक्शन नहीं बन पाता।

समाधान के लिए, nslookup registry-1.docker.io या dig registry-1.docker.io से DNS रेज़ॉल्यूशन जाँचें। यदि ये कमांड विफल हों, तो आपका DNS सर्वर अप्राप्य है या गलत कॉन्फ़िगर है। अस्थायी रूप से 8.8.8.8 जैसा सार्वजनिक DNS सर्वर स्विच करके देखें कि क्या समस्या सुलझती है।

कॉर्पोरेट नेटवर्क में, DNS सर्वर केवल आंतरिक होस्टनेम रेज़ॉल्व कर सकता है। सुनिश्चित करें कि आपकी निजी रजिस्ट्री का होस्टनेम DNS सर्वर में है, या DNS ठीक होने तक /etc/hosts में उसे जोड़ें।

समन्वित और लोकल वर्कफ़्लो में docker pull

अब मज़ेदार हिस्से पर आते हैं - आपके रोज़मर्रा के काम में मिलने वाले परिदृश्यों में docker pull कमांड कैसे काम करती है।

Kubernetes में इमेज पुल्स

Kubernetes इमेज को स्वतः खींचता है जब आप पॉड्स डिप्लॉय करते हैं।

आप अपने पॉड स्पेक में किसी कंटेनर को इमेज रेफ़रेंस के साथ परिभाषित करते हैं, और Kubernetes आपके लिए पुल संभाल लेता है। हर नोड पर kubelet जाँचता है कि इमेज लोकली मौजूद है या नहीं। यदि नहीं, तो कंटेनर शुरू करने से पहले वह रजिस्ट्री से खींच लेता है।

पुल नीतियाँ नियंत्रित करती हैं कि Kubernetes कब इमेज खींचे:

• Always: हर बार इमेज खींचो, भले ही वह लोकली मौजूद हो

• IfNotPresent: केवल तभी खींचो जब इमेज नोड पर पहले से न हो (टैग्ड इमेज के लिए डिफ़ॉल्ट)

• Never: कभी न खींचो, यदि इमेज लोकली नहीं है तो फेल हो जाओ

अपने पॉड स्पेक में imagePullPolicy से नीति सेट करें। डेवलपमेंट में अपडेट पाने के लिए :latest टैग्स के लिए Always उपयोग करें। प्रोडक्शन में अनावश्यक पुल से बचने के लिए विशिष्ट टैग्स के साथ IfNotPresent का उपयोग करें।

imagePullSecrets Kubernetes को निजी रजिस्ट्रीज़ तक पहुँच देता है। आप अपनी रजिस्ट्री क्रेडेंशियल्स के साथ एक सीक्रेट बना सकते हैं, फिर उसे अपने पॉड स्पेक में संदर्भित कर सकते हैं। इसके बिना, Kubernetes केवल सार्वजनिक इमेज ही खींच सकता है।

Docker Compose और लोकल डेवलपमेंट

Compose मल्टी-सर्विस एप्लिकेशन शुरू करते समय पुल्स को स्वचालित कर देता है।

docker compose up चलाएँ, और Compose हर सर्विस की इमेज जाँचता है। यदि कोई इमेज गायब है, तो कंटेनर शुरू करने से पहले Compose उसे खींच लेता है। आपको हर सर्विस के लिए अलग से docker pull चलाने की ज़रूरत नहीं, Compose यह आपके लिए कर देता है।

यह डेवलपमेंट के लिए बेहतरीन काम करता है। आप अपनी सर्विसेज़ को docker-compose.yml में परिभाषित कर सकते हैं, एक कमांड चलाएँ, और Compose आपको ज़रूरत की हर चीज़ खींच लेता है। पहला up रन लंबा लगता है जबकि इमेज डाउनलोड होती हैं, लेकिन बाद के रन, यदि इमेज नहीं बदली हैं, तो तुरंत हो जाते हैं।

docker compose बनाम docker compose pull

ये दो अलग कमांड हैं जो अलग काम करती हैं।

docker compose up आपकी सर्विसेज़ शुरू करता है। यह केवल गायब इमेज को अपने-आप खींचता है, लेकिन तभी जब वे लोकली मौजूद न हों। यदि आपके मशीन पर पहले से python:3.14.2-bookworm है, तो Compose अपडेट्स की जाँच किए बिना उसे ही उपयोग करेगा।

docker compose pull आपकी compose फ़ाइल में परिभाषित सभी इमेज को स्पष्ट रूप से खींचता है, चाहे वे लोकली मौजूद हों या नहीं। यह रजिस्ट्री में अपडेट्स की जाँच करता है और नए संस्करण उपलब्ध होने पर उन्हें डाउनलोड करता है।

आपको docker compose pull कब चाहिए:

• आप :latest टैग्स उपयोग कर रहे हैं और नवीनतम संस्करण चाहते हैं। पहले अपडेट पाने के लिए docker compose pull चलाएँ, फिर नए इमेज के साथ शुरू करने के लिए docker compose up चलाएँ।

• आप डिबग कर रहे हैं और संदेह है कि आपकी लोकल इमेज पुरानी या करप्ट है। docker compose pull से नई कॉपी खींचें, फिर रीस्टार्ट करें।

• आप सेवाओं को वास्तव में शुरू करने से पहले इमेज प्रीलोड करना चाहते हैं। डिप्लॉयमेंट के दौरान docker compose pull चलाएँ ताकि इमेज कैश हो जाएँ, फिर docker compose up बिना डाउनलोड का इंतज़ार किए तुरंत चल पड़े।

मुख्य अंतर यह है कि up केवल वही खींचता है जो गायब है, और pull आपके पास पहले से क्या है, इसकी परवाह किए बिना सब कुछ अपडेट करता है।

निष्कर्ष

docker pull कमांड सरल दिखता है, लेकिन सतह के नीचे बहुत कुछ होता है और आप कई चीज़ें ट्यून कर सकते हैं। याद रखने के लिए कुछ सर्वोत्तम प्रथाएँ यहाँ हैं।

:latest के बजाय स्पष्ट टैग्स या डाइजेस्ट का उपयोग करें। रेट लिमिट से बचने के लिए अपने पुल्स को प्रमाणित करें। इमेज खींचते समय बैंडविड्थ और स्टोरेज का ध्यान रखें, खासकर CI/CD पाइपलाइन्स में जहाँ आप लगातार पुल करते रहते हैं।

इमेज पुल्स को अपनी सुरक्षा पाइपलाइन का हिस्सा मानें। यदि आप अविश्वसनीय स्रोतों या ज्ञात कमजोरियों वाली पुरानी इमेज का उपयोग कर रहे हैं, तो हर पुल एक संभावित अटैक वेक्टर है। स्रोतों को सत्यापित करें, समस्याओं के लिए स्कैन करें, और बेस इमेज को अपडेट रखें।

Docker रजिस्ट्रियाँ और टूलिंग नियमित रूप से बदलते रहते हैं। अपने रजिस्ट्री प्रदाता के अपडेट्स के साथ अद्यतन रहें ताकि आपके वर्कफ़्लो को तोड़ने वाले आश्चर्यों से बचा जा सके।

जब आप अपनी Docker और कंटेनराइज़ेशन कौशल को पेशेवर स्तर पर ले जाने के लिए तैयार हों, तो हमारा Intermediate Docker कोर्स देखें या हमारा पूरा Containerization and Virtualization with Docker and Kubernetes ट्रैक चुनें।