- कंटेनर रजिस्ट्री ऊपर से देखने पर सरल लगती है, लेकिन गलत टैग, प्लेटफ़ॉर्म mismatch, layer की कमी, या वास्तविक deletion fail जैसी समस्याओं को debug करने के लिए इसकी आंतरिक कार्यप्रणाली को समझना ज़रूरी है
- रजिस्ट्री का मूल एक content-addressable blob storage है, जहाँ सभी layer, configuration file, और artifact digest को पते की तरह इस्तेमाल करके संग्रहीत किए जाते हैं
- image push, blob upload करने के बाद उन्हें manifest में बाँधने के क्रम में होता है, और pull में पहले manifest लिया जाता है, फिर blob क्रम से डाउनलोड होते हैं — यानी यह उलटा क्रम है
- image deletion केवल untag करने से पूरी तरह नहीं होती; पहले यह देखना पड़ता है कि कहीं दूसरे manifest वही shared layer इस्तेमाल तो नहीं कर रहे, उसके बाद ही blob को सीधे delete करना चाहिए
- multi-platform image को मौजूदा API endpoint वैसे ही रखते हुए image index (manifest list) नाम की एक अतिरिक्त indirect layer जोड़कर लागू किया जाता है
Registry API का अवलोकन
- आधुनिक कंटेनर रजिस्ट्री का अधिकांश हिस्सा OCI Distribution Specification को implement करता है, और यह spec content distribution को standardize करने वाला API protocol परिभाषित करता है
- Registry API वास्तव में संक्षिप्त और समझने में आसान है, और केवल
curl से भी इसे सीधे संचालित किया जा सकता है
Blob upload और download
- रजिस्ट्री मूल रूप से एक content-addressable blob storage है, जहाँ फ़ाइल को लोकल में hash करने के बाद digest को पते की तरह इस्तेमाल कर upload किया जाता है
- सबसे सरल upload तरीका Monolithic PUT है, जिसमें
POST से session initialize करने के बाद PUT से blob भेजा जाता है — यानी 2-स्टेप संरचना
- बड़े फ़ाइलों के लिए
POST + PATCH + PUT chunk upload तरीका अधिक efficient है, लेकिन छोटे blob के लिए Monolithic PUT पर्याप्त है
- upload सफल होने पर
HTTP/2 201 Created response के साथ नया blob कहाँ है यह बताने वाला Location header लौटाया जाता है
- download, केवल digest पता होने पर
GET /v2/<repo>/blobs/<digest> से सीधे किया जा सकता है
image Push
- image push की प्रक्रिया: (1) हर rootfs layer blob upload → (2) image configuration blob upload → (3) सभी digest को एक JSON document में बाँधने वाली manifest फ़ाइल push
- manifest को
PUT /v2/<repo>/manifests/<tag> endpoint पर upload किया जाता है, और इसी समय tag बनता है
- वास्तविक client (जैसे
docker push) blob upload को parallel में करता है, लेकिन सिद्धांत समझने के लिए sequential processing भी संभव है
- image directory संरचना का उदाहरण:
config.json, layer-1.tar.gz, layer-2.tar.gz, manifest.json
tag सूची देखना
GET /v2/<repo>/tags/list endpoint से किसी खास repository के सभी tag की सूची देखी जा सकती है- यह सुविधा
docker CLI में exposed नहीं है, और केवल curl या crane, regctl जैसे tools से ही access की जा सकती है
crane, regctl इसी endpoint को ls command के रूप में wrap करते हैं
image Pull
- pull प्रक्रिया push का उलटा है: (1)
GET /v2/<repo>/manifests/<tag> से manifest प्राप्त करना → (2) manifest में दिए गए digest के आधार पर सभी blob download करना
- आधुनिक manifest, rootfs layer और image configuration के अलावा Helm chart, SBOM, provenance attestation, LLM weights जैसे मनचाहे artifact को blob के रूप में refer करने वाले general-purpose storage की तरह भी काम करते हैं
image deletion
- image deletion सरल नहीं है, और केवल tag हटाने (untag) से manifest खुद delete नहीं होता
- पूरी deletion प्रक्रिया:
- (1)
DELETE /v2/<repo>/manifests/<tag> से tag हटाना
- (2) digest के ज़रिए manifest को देखकर उससे refer होने वाले सभी blob की पहचान करना
- (3) केवल वे blob चुनकर delete करना जो किसी दूसरे manifest के साथ shared न हों
- (4)
DELETE /v2/<repo>/blobs/<manifest-digest> से manifest blob delete करना
- चूँकि रजिस्ट्री एक content-addressable storage है, इसलिए एक ही rootfs layer कई image में shared हो सकती है, और deletion के समय उसका असर उस layer को refer करने वाली सभी image पर पड़ सकता है
- एक विकल्प यह भी है कि सभी tag हटाकर रजिस्ट्री की garbage collection setting पर निर्भर रहा जाए, लेकिन public registry में यह हमेशा enabled नहीं होती
multi-platform image
- multi-platform image को Registry API की संरचना बदले बिना लागू किया जाता है — endpoint जोड़ने या बदलने की ज़रूरत नहीं, मौजूदा API ही इस्तेमाल होती है
- संरचना का तरीका:
- हर single-platform variant (amd64, arm64 आदि) को अलग manifest के साथ digest-आधारित रूप में पहले push किया जाता है
- उसके बाद image index (manifest list) कहलाने वाला ऊपरी manifest tag के साथ push किया जाता है
GET /v2/<repo>/manifests/<tag> call पर single-platform manifest या image index, इनमें से एक लौटता है, और caller को लौटे हुए document के content type से उन्हें अलग पहचानना होता है- नतीजतन, multi-platform support मौजूदा संरचना में सिर्फ एक indirect layer और index document upload/download का एक अतिरिक्त चरण जोड़ता है
Registry API की सुरक्षा
- OCI Distribution Spec authentication तरीका सख्ती से परिभाषित नहीं करता, लेकिन अधिकांश वास्तविक रजिस्ट्री HTTP Basic authentication का इस्तेमाल करती हैं
- credentials को plain text में भेजे जाने से बचाने के लिए इसे हमेशा HTTPS पर ही चलाना चाहिए
अभी कोई टिप्पणी नहीं है.