Unregistry – रजिस्ट्री के बिना सर्वर पर सीधे “docker push”

 (github.com/psviderski)
4 पॉइंट द्वारा GN⁺ 2025-06-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Unregistry एक ओपन सोर्स टूल है जो बाहरी रजिस्ट्री के बिना Docker इमेज को सीधे रिमोट सर्वर पर भेज सकता है
  • docker pussh कमांड SSH के जरिए इमेज को कुशल तरीके से रिमोट सर्वर तक पहुंचाती है और जो लेयर पहले से मौजूद हों उन्हें छोड़ देती है
  • यह पारंपरिक Docker Hub, स्वयं-होस्टेड रजिस्ट्री, और save/load तरीके की जटिलता और अक्षमता को दूर करता है
  • प्रोडक्शन डिप्लॉयमेंट, CI/CD, एयर-गैप्ड वातावरण आदि में तेज़ और सुरक्षित इमेज ट्रांसफर इसका बड़ा फायदा है
  • इंस्टॉलेशन, उपयोग और आवश्यकताएँ बहुत सरल हैं, और किसी अतिरिक्त सर्विस चलाने या पोर्ट एक्सपोज़ करने की ज़रूरत नहीं होती

Unregistry परिचय और मुख्य फायदे

  • Unregistry एक हल्का इमेज रजिस्ट्री है जो Docker daemon के स्टोरेज से सीधे इमेज को स्टोर और सर्व करता है
  • docker pussh कमांड का उपयोग करने पर SSH के जरिए बाहरी रजिस्ट्री के बिना इमेज को सीधे रिमोट Docker सर्वर पर भेजा जा सकता है
  • ट्रांसफर के दौरान सर्वर पर पहले से मौजूद लेयर को छोड़कर सिर्फ ज़रूरी हिस्सा तेज़ी से भेजने की सुविधा मिलती है

मौजूदा Docker इमेज डिप्लॉयमेंट की समस्याएँ

  • लोकल में इमेज build करने के बाद उसे सर्वर तक भेजने के लिए आमतौर पर ये विकल्प होते हैं
    • Docker Hub/GitHub Container Registry: कोड बाहरी रूप से उजागर हो सकता है, या प्राइवेट रिपॉज़िटरी इस्तेमाल करने पर लागत आती है
    • स्वयं की रजिस्ट्री: अलग सर्विस चलानी पड़ती है, और security व storage management का बोझ बढ़ता है
    • Save/Load: हर बार पूरी इमेज भेजनी पड़ती है, इसलिए यह अप्रभावी है
    • सर्वर पर सीधे rebuild: समय और सर्वर resource की बर्बादी होती है, साथ ही debugging समस्याएँ आती हैं

Unregistry समाधान

  • सिर्फ docker pussh myapp:latest user@server कमांड से बिना किसी मध्यवर्ती स्टोरेज के सीधे ट्रांसफर किया जा सकता है

  • अतिरिक्त रजिस्ट्री सेटअप, पोर्ट एक्सपोज़र, स्टोरेज तैयारी या सब्सक्रिप्शन की ज़रूरत नहीं है

  • ट्रांसफर प्रक्रिया

    • SSH tunnel को रिमोट सर्वर से जोड़ा जाता है
    • अस्थायी रूप से unregistry कंटेनर चलाया जाता है
    • रैंडम लोकल पोर्ट को unregistry पोर्ट से जोड़ा जाता है
    • docker push के जरिए सिर्फ वे लेयर भेजी जाती हैं जो मौजूद नहीं हैं (और तुरंत उपयोग योग्य होती हैं)
    • unregistry कंटेनर और SSH tunnel बंद कर दिए जाते हैं

  • यह rsync जैसी सरल और कुशल पद्धति है

  • यह प्रोजेक्ट Uncloud में कई Docker host पर कंटेनर डिप्लॉय करने की जटिलता को सरल बनाने के लिए विकसित किया गया था

उपयोग के उदाहरण

डिप्लॉयमेंट वातावरण में सीधे इमेज ट्रांसफर

  • लोकल में build करने के बाद सीधे प्रोडक्शन सर्वर पर push करें
    • docker build --platform linux/amd64 -t myapp:1.2.3 .
    • docker pussh myapp:1.2.3 deploy@prod-server
    • ssh deploy@prod-server docker run -d myapp:1.2.3

CI/CD पाइपलाइन

  • रजिस्ट्री की जटिलता के बिना build और deployment को सपोर्ट करता है
    • GitHub Action YAML आदि में सीधे ट्रांसफर का उपयोग किया जा सकता है

होमलैब, इंटरनेट-रहित एयर-गैप्ड वातावरण

  • इमेज को इंटरनेट पर सार्वजनिक किए बिना आइसोलेटेड नेटवर्क में सुरक्षित रूप से भेजा जा सकता है

उपयोग का तरीका

  • रिमोट पर SSH user account को docker कमांड इस्तेमाल करने की अनुमति होनी चाहिए
  • SSH private key या custom SSH port जैसे अतिरिक्त विकल्प भी समर्थित हैं
  • मल्टी-प्लेटफ़ॉर्म इमेज ट्रांसफर भी समर्थित है (यदि containerd आधारित हो)

आवश्यकताएँ

लोकल वातावरण

  • Docker CLI (plugin support, 19.03+)
  • OpenSSH client

रिमोट सर्वर

  • Docker इंस्टॉल और रनिंग होना चाहिए
  • ssh user के पास Docker अनुमति होनी चाहिए, और आवश्यकता होने पर password-less sudo docker चलाने की क्षमता भी होनी चाहिए
  • containerd image store इस्तेमाल करने पर प्रदर्शन बेहतर होता है
    • /etc/docker/daemon.json में नीचे दिया गया सेटिंग जोड़ें और Docker को restart करें 
      {
  "features": {
    "containerd-snapshotter": true
  }
}

उन्नत उपयोग

लोकल standalone रजिस्ट्री के रूप में उपयोग

  • अतिरिक्त component के बिना unregistry को लोकल रजिस्ट्री की तरह आसानी से चलाया जा सकता है
  • Docker कमांड से deploy और push किया जा सकता है

SSH custom options का उपयोग

  • SSH config फ़ाइल की मदद से अतिरिक्त authentication, port आदि के लिए विस्तृत सेटिंग की जा सकती है

योगदान और कम्युनिटी

  • बग मिलने पर GitHub issue दर्ज किया जा सकता है
  • Uncloud Discord कम्युनिटी में feature, roadmap और implementation details पर चर्चा की जा सकती है

प्रेरणा और संदर्भ ओपन सोर्स

  • Spegel: containerd आधारित P2P container image registry implementation से प्रेरणा मिली
  • Docker Distribution: वास्तविक registry implementation के आधार के रूप में उपयोग किया गया

सारांश

  • Unregistry एक ऐसा टूल है जो Docker इमेज को आसानी और तेज़ी से सीधे रिमोट सर्वर तक पहुंचाता है और रजिस्ट्री बनाने व मैनेज करने का बोझ खत्म करता है
  • प्रोडक्शन डिप्लॉयमेंट, CI/CD, एयर-गैप्ड वातावरण जैसे कई परिदृश्यों में यह मजबूत लाभ देता है
  • जब सर्वर और एडमिन सिर्फ इमेज को बिना अनावश्यक प्रक्रिया के सरल तरीके से स्थानांतरित करना चाहते हों, तब यह बेहद उपयुक्त है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-06-19
Hacker News राय

  • सर्वर की प्रकृति, security boundaries और hardening के लिहाज़ से मैं Linux पर Homebrew इस्तेमाल करने की सिफारिश नहीं करना चाहूंगा। Linux इंस्टॉल सपोर्ट ऐसा लगता है जैसे बाद में जोड़ा गया हो, और यह package manager से ज़्यादा शतरंज की बिसात पर कबूतर की तरह व्यवहार करता है।

  • मुझे लगता है कि यह उन जगहों के लिए एक शानदार विचार है जहाँ सिस्टम में पहले से Ansible जैसी push deployment tooling इस्तेमाल होती है। साथ ही, जिन कंपनियों में Docker registry को 24x7 सपोर्ट नहीं मिलता, वहाँ यह hotfix deployment तकनीक के रूप में भी उपयुक्त लगती है। मैं यह जानना चाहता हूँ कि क्या यह OCI tooling (जैसे buildah) के साथ भी साफ़-सुथरे तरीके से जुड़ता है, या फिर दोनों तरफ पूरा Docker इंस्टॉल होना ज़रूरी है। मैंने अभी गहराई से नहीं देखा है, लेकिन इस दिशा में काम करने का इरादा है। मुझे लगा कि skopeo के लिए ऐसे माहौल में काम करने हेतु remote server पर अपनी registry bootstrap करने की क्षमता की कमी है।

    • remote server पर containerd चाहिए (Docker और Kubernetes भी containerd का उपयोग करते हैं), और client side पर ऐसा कुछ भी चल सकता है जो registry API को समझता हो (OCI Distribution spec: https://github.com/opencontainers/distribution-spec)। Unregistry API layer के रूप में आधिकारिक Docker registry code को दोबारा इस्तेमाल करता है, इसलिए यह Docker Hub की registry जैसा महसूस होता है। skopeo, crane, regclient, BuildKit आदि OCI registry का उपयोग कर सकते हैं, लेकिन इनके लिए remote host पर unregistry को सीधे चलाना होगा। docker pussh कमांड local Docker का उपयोग करके इस पूरे flow को अपने-आप automate कर देती है। यह एक bash script है, इसलिए इसे एक बार देखना चाहिए: https://github.com/psviderski/unregistry/blob/main/docker-pussh, और चाहें तो इसे अपने मुताबिक बदलना भी आसान है।

    • दोनों तरफ docker daemon चाहिए। यह तरीका दो daemons के बीच layers को ssh के ज़रिए साझा करने का एक काफ़ी चतुर तरीका अपनाता है।

  • मुझे लगता है pussh कमांड याद रखने में आसान, self-descriptive है, और मौजूदा standard command से सिर्फ़ एक अक्षर अलग होने वाला अच्छा wordplay दिखाती है।

    • "pussh" ठीक है, लेकिन automation में "docker push-over-ssh" जैसा ज़्यादा स्पष्ट alias बेहतर हो सकता है। जो व्यक्ति पहली बार "pussh" देखे, वह इसे typo समझ सकता है, और अनावश्यक भ्रम हो सकता है। अगर short version और full flag version दोनों सपोर्ट हों, तो अच्छा होगा।

    • मज़ाक में कहा गया कि एक अतिरिक्त 's' शायद 'sssh' दिखाने के लिए है। किसी और ने कहा कि यह बस typo है।

    • pussh नाम किसी दूसरे command से टकरा सकता है।

  • मुझे लगता है ऐसी सुविधा बहुत पहले से होनी चाहिए थी, और यह बेहद शानदार है। Docker registry अपने-आप में मूल्यवान है, लेकिन कुल मिलाकर यह बहुत जटिल हो गई है और hacker mindset से दूर चली गई है।

    • Docker एक VC-funded कंपनी थी, इसलिए किसी न किसी तरह revenue कमाना उसकी मजबूरी थी।

  • project और इसका approach प्रभावशाली है। महंगी registries से तंग आकर मैंने Zot(https://zotregistry.dev) जैसी चीज़ खुद host करके देखी है, लेकिन कुछ use cases में यह तरीका उससे कहीं सरल लगता है। काश आसान, सस्ती और usage-based private registry services थोड़ी और आम होतीं।

    • किसी ने बताया कि zothub.io का SSL certificate expire हो गया है।

  • मुझे लगता है Docker को शुरू से ही ऐसे काम करना चाहिए था। यह एक शानदार विचार है।

    • image file को archive के रूप में सेव करके server पर भेजने और फिर load करने से भी मिलता-जुलता परिणाम पाया जा सकता है। उदाहरण के लिए docker save -o my-app.tar my-app:latest से सेव करें, फिर docker load -i /path/to/my-app.tar से लोड करें। ansible जैसे automation tools के साथ मिलाकर, Unregistry जो automate करता है उसे हाथ से भी किया जा सकता है। हालांकि GitHub repo के अनुसार save/load तरीके में पूरी image हर बार पूरी की पूरी ट्रांसफर करनी पड़ती है, और image management भी archive files की तुलना में अधिक सुविधाजनक होता है।

  • ऐसे tools और SSH tooling की मदद से self-hosting की ओर वापसी देखना अच्छा लगता है, और यह एक अच्छी तरह बना हुआ परिणाम है। मैं इसे खुद आज़माने का इरादा रखता हूँ।

  • इस tool की वजह से मुझे पहली बार uncloud नाम के project के बारे में पता चला, और यह मुझे उस dokku जैसा लेकिन अधिक शक्तिशाली server deployment solution लग रहा है जिसकी मुझे तलाश थी, इसलिए यह दिलचस्प लगा।

    • इस प्रतिक्रिया से सहमति जताई गई कि uncloud उनके लिए बहुत उपयुक्त है, और कहा गया कि कोई सवाल हो तो Discord पर पूछने का स्वागत है।

    • https://skateco.github.io/ जैसी समान approach वाली service भी है, देखने की सिफारिश की गई।

    • Portainer की सिफारिश की गई। Portainer Community Edition और Portainer Agent का उपयोग करके AWS EC2 की दो machines पर इसे अच्छी तरह चलाया जा रहा है। इसका stack feature (docker compose आधारित) खास तौर पर मज़बूत बताया गया, और एक EC2 पर portainer agent container के रूप में Caddy चलाकर load balancer और reverse proxy की भूमिका निभा रहा है।

  • यह एक नया और दिलचस्प विचार है, लेकिन इस तरह का तरीका service deployment के साथ बहुत कसकर जुड़ जाता है, इसलिए deployment और scaling, जैसे red/green deployment के दौरान, "push" को समझने वाला अतिरिक्त logic चाहिए। सोचने पर लगा कि uncloud में यही भूमिका निभाने वाली संरचना मौजूद है। लेकिन आख़िरकार यह एक trade-off है, और अगर आप एक Hetzner VM पर सादगी को प्राथमिकता देते हैं, तो local में image build भर से भी आप पूरी तरह संतुष्ट हो सकते हैं।

    • हर चीज़ में trade-offs होते हैं, और सबसे अच्छी बात यह है कि स्थिति के हिसाब से सबसे उपयुक्त tool चुना जा सकता है।