अपनी इमेज रजिस्ट्री

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

सरल विकल्प: registry:2

services:
  registry:
    image: registry:2
    restart: unless-stopped
    environment:
      REGISTRY_AUTH: htpasswd
      REGISTRY_AUTH_HTPASSWD_REALM: Registry
      REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
      REGISTRY_STORAGE_DELETE_ENABLED: "true"
    volumes:
      - ./data:/var/lib/registry
      - ./auth:/auth:ro
    ports:
      - "127.0.0.1:5000:5000"

पासवर्ड इस तरह बनाएँ:

mkdir -p auth
docker run --rm --entrypoint htpasswd httpd:2 -Bbn deploy 'long-password' > auth/htpasswd
docker compose up -d

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

इसके साथ काम करना

docker login registry.example.com
docker tag myapp:1.5.0 registry.example.com/myapp:1.5.0
docker push registry.example.com/myapp:1.5.0
docker pull registry.example.com/myapp:1.5.0

curl -u deploy https://registry.example.com/v2/_catalog
curl -u deploy https://registry.example.com/v2/myapp/tags/list

docker login के बाद क्रेडेंशियल ~/.docker/config.json में प्लेन टेक्स्ट में रहते हैं (base64 एन्क्रिप्शन नहीं है)। बिल्ड मशीनों पर रीड-ओनली अधिकारों वाला अलग अकाउंट बनाएँ।

बिना साइज़ लिमिट और बिना क्लीनअप वाली रजिस्ट्री डिस्क भरने का सबसे तेज़ तरीका है। हर बिल्ड लेयर जोड़ता है, और टैग डिलीट करने से जगह खाली नहीं होती: आपको गार्बेज कलेक्शन चाहिए। 40 GB वाले VDS-1 पर एक सक्रिय प्रोजेक्ट की रजिस्ट्री कुछ हफ़्तों में डिस्क भर देगी।

क्लीनअप

टैग डिलीट करना और उसके बाद गार्बेज कलेक्शन:

docker compose exec registry registry garbage-collect \
  --delete-untagged /etc/docker/registry/config.yml

गार्बेज कलेक्शन चलते समय आपको रजिस्ट्री रोकनी होगी — वरना साथ-साथ चल रहा push लेयर खो सकता है:

docker compose stop registry
docker compose run --rm registry registry garbage-collect --delete-untagged /etc/docker/registry/config.yml
docker compose start registry

इसे हफ़्ते में एक बार शेड्यूल्ड जॉब के तौर पर सेट करें और डिस्क स्पेस पर नज़र रखें।

विकल्प: Git सर्वर के साथ बंडल की गई रजिस्ट्री

अगर आपने पहले ही Forgejo या Gitea सेट कर लिया है, तो उनमें पैकेज स्टोर बिल्ट-इन होता है, जिसमें Docker इमेज भी शामिल हैं। आपको अलग सर्विस की ज़रूरत नहीं: एक्सेस उन्हीं अकाउंट से होता है, और इमेज कोड के बगल में दिखती हैं। छोटे प्रोजेक्ट के लिए यह अलग registry:2 से ज़्यादा सुविधाजनक है।

आम गलतियाँ

• रजिस्ट्री बिना ऑथराइज़ेशन के खुली है। इसके ज़रिए कोई आपकी ही प्रोडक्शन मशीन पर डिप्लॉय होने वाली इमेज डाल सकता है।
• वर्ज़न की जगह latest टैग। रजिस्ट्री रिप्रोड्यूसिबिलिटी का स्रोत रहना बंद कर देती है: यह साफ़ नहीं रहता कि असल में क्या डिप्लॉय हुआ है। देखें कंटेनर अपडेट करना।
• डेटाबेस वाली ही डिस्क पर स्टोरेज। push में उछाल डिस्क बैंडविड्थ खा जाता है और प्रोडक्शन सर्विस धीमी कर देता है — देखें डिस्क स्पीड।
• ./data डायरेक्टरी आपके बैकअप में नहीं है। आप उन सभी इमेज से हाथ धो बैठेंगे जिनके सोर्स आपके पास मौजूद नहीं हैं। देखें क्या बैकअप लें।