کنٹینر میں چلنے والی Distribution رجسٹری کے لیے جو ماحول سے واقف HTTP ٹرانسپورٹ استعمال کرتی ہے، S3 راستہ رجسٹری کنٹینر کو دیں:

services:
  registry:
    environment:
      HTTP_PROXY: http://proxy.example.internal:8080
      HTTPS_PROXY: http://proxy.example.internal:8080
      NO_PROXY: localhost,127.0.0.1

اسے موجودہ image، اسٹوریج، توثیق اور volumes کے ساتھ ملا دیں۔ یہ ٹکڑا مکمل رجسٹری نہیں ہے۔ پراکسی کا نام اُس کنٹینر سے قابلِ رسائی ہونا چاہیے، اور scheme کو پراکسی لسنر سے مطابقت رکھنی چاہیے۔

تعینات شدہ S3 ڈرائیور اور ٹرانسپورٹ کی تصدیق کریں۔ Distribution 2.8.3 میں مذکور ماخذ AWS SDK سیشن استعمال کرتا ہے؛ حسبِ ضرورت ڈرائیور یا ٹرانسپورٹ کو کوئی دوسری معاون ترتیب درکار ہو سکتی ہے۔

رابطہکون ترتیب یا تحقیق کرتا ہے
کلائنٹ → رجسٹریرجسٹری کا آنے والا HTTP لسنر اور کلائنٹ کا راستہ
Daemon → image ماخذDocker daemon کی پراکسی ترتیبات
رجسٹری → S3رجسٹری عمل کا اسٹوریج HTTP ٹرانسپورٹ

کلائنٹ کا کامیاب لاگ اِن صرف پہلا راستہ ثابت کرتا ہے۔ اسٹوریج ڈرائیور S3 کو اپنی درخواستیں بھیجتا ہے؛ وہ daemon جس نے پہلے رجسٹری image کھینچی تھی وہ یہ کالیں نہیں کرتا۔

blob ڈاؤن لوڈ کے دوران ری ڈائریکٹ بھی جانچیں۔ Distribution صارف کو آبجیکٹ اسٹوریج کی طرف ری ڈائریکٹ کر سکتا ہے، جس سے اُس کلائنٹ کو براہِ راست S3 تک رسائی کی ضرورت پڑتی ہے۔ رجسٹری کی پراکسی ترتیب دینے سے صارف کی ترتیب نہیں بنتی۔ ری ڈائریکٹ رویہ بدلنے سے blob ٹریفک کا بہاؤ بدل جاتا ہے، اس لیے وہ ترتیب بدلنے سے پہلے ناکام ہونے والے بھیجنے والے اور کارروائی کی نشاندہی کریں۔

متعلقہ مضامین