S3 का उपयोग container registry के रूप में

S3 का उपयोग container registry के रूप में करना

• पिछले 4 महीनों से Outerbounds के साथ मिलकर एक custom container image builder विकसित किया जा रहा था
• यह पता चला कि S3 का उपयोग container registry के रूप में किया जा सकता है
• अगर S3 bucket को HTTP पर expose किया जाए और किसी खास path पर image upload की जाए, तो docker pull कमांड से image प्राप्त की जा सकती है

डेमो

• cowsay चलाने वाली container image बनाकर उसे S3 bucket में upload किया गया
• मुफ़्त egress देने के लिए R2 का उपयोग किया गया
• R2 और S3 API-compatible हैं

$ docker run --rm pub-40af5d7df1e0402d9a92b982a6599860.r2.dev/cowsay

S3 का उपयोग क्यों करें?

• पारंपरिक रूप से DockerHub, GitHub Container Registry, ECR आदि का उपयोग किया जाता है
• upload speed के मामले में S3 का बड़ा फ़ायदा है
• ECR और S3 की upload speed की तुलना में S3 अधिकतम 8 गुना तेज़ था

S3 तेज़ क्यों है

• S3 एक ही layer के chunks को parallel में upload कर सकता है
• ECR, OCI Distribution Spec का पालन करता है, इसलिए उसे sequentially upload करना पड़ता है
• parallel upload न कर पाने वाला ECR bandwidth का पूरा उपयोग नहीं कर पाता

S3 container registry नहीं है

• सख्ती से कहें तो S3 वास्तव में container registry नहीं है
• docker pull कमांड HTTP request के ज़रिए files download करती है
• अगर S3 bucket को सही तरीके से configure किया जाए, तो उसका उपयोग container registry की तरह किया जा सकता है

सावधानियाँ

• यह तरीका बहुत experimental है
• यह मौजूदा container registry की सुविधाएँ नहीं देता (जैसे security scanning, access control आदि)
• इस पर और research की ज़रूरत है

PS. व्हेल का क्या?

• यह Docker लोगो की ओर इशारा करने वाला एक मज़ाक है

GN⁺ का सार

• यह लेख बताता है कि S3 का उपयोग container registry के रूप में कैसे किया जा सकता है
• S3 की तेज़ upload speed का लाभ उठाया जा सकता है
• चूँकि यह मौजूदा container registry की सुविधाएँ नहीं देता, इसलिए सावधानी ज़रूरी है
• यह experimental है, लेकिन एक दिलचस्प approach है
• इसी तरह की सुविधा देने वाले अन्य प्रोजेक्ट्स में DockerHub, GitHub Container Registry, ECR आदि शामिल हैं

[GN⁺]

Hacker News राय

• यह राय है कि OCI Distribution spec को static files सपोर्ट करना चाहिए

  • इससे simple HTTP server या file protocol को सीधे इस्तेमाल किया जा सकेगा
  • सारा metadata पहले से manifest में शामिल है
  • Content-Type: octet-stream अच्छी तरह काम कर सकता है

• यह राय है कि OCI Distribution spec अच्छी तरह डिज़ाइन नहीं किया गया है

  • layer push क्रमवार होना चाहिए
  • DockerHub और GHCR में chunk upload ठीक से काम नहीं करता
  • Content-Range value format, RFC7233 format से मेल नहीं खाता
  • tag list pagination को standardize करने का मौका चूक गया

• यह जानकारी है कि Cloudflare ने R2 का उपयोग करने वाला container registry server open source किया है

  • पूछा गया है कि क्या किसी ने इसे इस्तेमाल किया है

• यह राय है कि OCI spec में layer push क्रमवार क्यों होना चाहिए, यह जानना चाहेंगे

  • एक single layer की सामग्री को क्रमवार push करना चाहिए
  • कई layers को parallel में push करना संभव है

• Nexus इस्तेमाल करने के कारणों और उसके फायदे-नुकसान पर राय है

  • यह कई तरह के package और repository को support करता है
  • इसकी configuration और resource usage झंझटभरा है
  • Docker pull request सिर्फ simple HEAD और GET request से बनती है
  • यह देखकर हैरानी है कि ज़्यादा simple container registry कम हैं

• यह जानकारी है कि CNCF का Distribution, Cloudfront signed URL के ज़रिए S3 से registry को back करने की सुविधा support करता है

• यह राय है कि S3 और R2 की लागत पर कोई उल्लेख नहीं है, जो अफ़सोसजनक है

• यह जानकारी है कि ECR image layer को कई हिस्सों में upload करने का support देता है

  • संबंधित API:
    • InitiateLayerUpload API: हर image layer upload की शुरुआत में कॉल किया जाता है
    • UploadLayerPart API: हर layer chunk upload के समय कॉल किया जाता है (अधिकतम 20MB)
    • PutImage API: layer upload के बाद image manifest push करते समय कॉल किया जाता है
  • यह अजीब लगता है कि layer chunk को base64 encoding के साथ upload करना पड़ता है

• Docker के Registry को लेकर असंतोष है

• यह राय है कि personal container registry के होने का कारण समझ में नहीं आता

  • हो सकता है कि सिर्फ image files बनाकर उन्हें manage करना ज़्यादा बेहतर हो