Distribution রেজিস্ট্রির S3 অনুরোধের জন্য প্রক্সি সেটিংস

S3-এ প্রবেশ করে এমন Distribution রেজিস্ট্রি প্রক্রিয়ায় প্রক্সি সেটিংস রাখুন, এবং অবজেক্ট স্টোরেজে রিডাইরেক্ট হওয়া ক্লায়েন্টদের আলাদাভাবে হিসাব করুন।

পরিবেশ-সচেতন HTTP ট্রান্সপোর্ট ব্যবহার করা কন্টেইনারভিত্তিক Distribution রেজিস্ট্রির জন্য 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 session ব্যবহার করে; একটি কাস্টম ড্রাইভার বা ট্রান্সপোর্টের অন্য একটি সমর্থিত কনফিগারেশন লাগতে পারে।

সংযোগযে পক্ষ কনফিগার বা তদন্ত করবে
ক্লায়েন্ট → রেজিস্ট্রিরেজিস্ট্রির ইনকামিং HTTP লিসেনার ও ক্লায়েন্ট পথ
Daemon → image উৎসDocker daemon প্রক্সি সেটিংস
রেজিস্ট্রি → S3রেজিস্ট্রি প্রক্রিয়ার স্টোরেজ HTTP ট্রান্সপোর্ট

সফল ক্লায়েন্ট লগইন কেবল প্রথম পথটি প্রমাণ করে। স্টোরেজ ড্রাইভার S3-এ নিজের অনুরোধ পাঠায়; আগে যে daemon রেজিস্ট্রি image টেনেছিল সে এই কলগুলো করে না।

blob ডাউনলোডের সময় রিডাইরেক্টও পরীক্ষা করুন। Distribution একজন ব্যবহারকারীকে অবজেক্ট স্টোরেজে রিডাইরেক্ট করতে পারে, যা সেই ক্লায়েন্টের জন্য সরাসরি S3 পৌঁছানোর প্রয়োজন তৈরি করে। রেজিস্ট্রির প্রক্সি কনফিগার করলে ব্যবহারকারী কনফিগার হয় না। রিডাইরেক্ট আচরণ বদলালে blob ট্রাফিকের গতিপথ বদলায়, তাই ওই সেটিং বদলানোর আগে ব্যর্থ প্রেরক ও অপারেশন চিহ্নিত করুন।

সম্পর্কিত নিবন্ধ