আপনার কর্পোরেট প্রক্সি কেন একটি Compose সার্ভিসের নাম সমাধান করার চেষ্টা করছে
একটি HTTP ক্লায়েন্ট Docker-এর সার্ভিস-নাম সমাধান ব্যবহার করার আগে তার কনফিগার করা প্রক্সিতে একটি অভ্যন্তরীণ সার্ভিস অনুরোধ পাঠাতে পারে। সঠিক ক্লায়েন্টের জন্য সচেতন বাইপাস যোগ করুন।
অ্যাপ্লিকেশনটি তার কর্পোরেট প্রক্সির মাধ্যমে ইন্টারনেটে পৌঁছায়, কিন্তু http://catalog:8080/ ব্যর্থ হয় এবং প্রক্সি “catalog” সমাধান করতে পারে না। সেই অনুরোধটি হয়তো Docker-এর অভ্যন্তরীণ DNS কখনও ব্যবহার করেনি।
একটি HTTP ক্লায়েন্ট সরাসরি সংযোগ স্থাপনের আগে তার প্রক্সি নির্বাচন করতে পারে। তখন বাহ্যিক প্রক্সি এমন একটি নাম পায় যার অর্থ কেবল Compose নেটওয়ার্কের ভিতরে বিদ্যমান।
- অনুরোধে হোস্টনেম ব্যবহার করুন। Compose সার্ভিসগুলি উপযুক্ত নেটওয়ার্কে সার্ভিসের নামে আবিষ্কারযোগ্য। পরিবর্তনশীল কন্টেইনার IP হার্ড-কোড করার বদলে গ্রাহক ক্লায়েন্টের সমর্থিত বাইপাস কনফিগারেশনে
catalogযোগ করুন। - বিদ্যমান ব্যতিক্রমগুলি সংরক্ষণ করুন। পরিবেশ-সচেতন ক্লায়েন্টের জন্য প্রাসঙ্গিক এন্ট্রিগুলি সংস্থার তালিকার সাথে একত্রিত করুন:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalogইমেজের প্রকৃত লাইব্রেরি বা এক্সিকিউটেবল পরীক্ষা করুন কেস হ্যান্ডলিং, সংস্করণ এবং মিলকরণ ব্যাকরণের জন্য। কোনো সার্বজনীন NO_PROXY পার্সার নেই। ছোট ইমেজে wget নামের একটি প্রোগ্রামকে GNU Wget-এর মতো আচরণ করতে হবে না।
অনুরোধটি সরাসরি রাউটিং নির্বাচন করার পরে, কলার এবং সার্ভিসের যৌথ নেটওয়ার্ক, শোনা সার্ভিস এবং কন্টেইনার পোর্ট পরীক্ষা করুন। প্রকাশিত হোস্ট পোর্ট আরেকটি প্রান্তবিন্দু। একটি বাইপাস অনুপস্থিত নেটওয়ার্ক সংযুক্তি যোগ করতে পারে না, যেমন একটি নেটওয়ার্ক পুনরায় তৈরি করলে বাহ্যিক প্রক্সিকে একটি ব্যক্তিগত Compose নাম শেখানো যায় না।
উদ্দেশ্যপ্রণোদিত বিভাজন রাখুন: অভ্যন্তরীণ অনুরোধগুলি তাদের অভ্যন্তরীণ পথ ব্যবহার করে; বাহ্যিক অনুরোধগুলি অনুমোদিত প্রক্সি রাখে। প্রক্সি বিশ্বব্যাপী নিষ্ক্রিয় করা এই একটি ব্যর্থতা লুকাতে পারে, একই সাথে পরবর্তী বাহ্যিক অনুরোধের জন্য প্রয়োজনীয় পথ সরিয়ে দিতে পারে।