কেন একটি প্রক্সি কন্টেইনার স্বয়ংক্রিয়ভাবে DNS কন্টেইনার ব্যবহার করে না

একই Docker হোস্টে প্রক্সি ও DNS সার্ভার চালালে সেগুলোর DNS পথ সংযুক্ত হয় না। তিনটি পৃথক সম্পর্ক গুরুত্বপূর্ণ:

• নেটওয়ার্ক নাগাল। আলাদা Compose প্রকল্পের সাধারণত আলাদা ডিফল্ট নেটওয়ার্ক থাকে। পরিষেবাগুলো একটি উপযুক্ত শেয়ার্ড নেটওয়ার্কে রাখুন, হয় একটি প্রকল্পের ভেতরে, নয়তো প্রকল্পগুলোর মধ্যে স্পষ্টভাবে শেয়ার করা নেটওয়ার্কের মাধ্যমে।
• পরিষেবা আবিষ্কার। একটি কাস্টম Docker নেটওয়ার্কের অন্তর্নির্মিত DNS কন্টেইনার নাম রিজলভ করতে পারে। এটি একটি অ্যাপ্লিকেশনকে প্রতিবেশী আবিষ্কার করতে দেয়; কিন্তু সেই প্রতিবেশীকে স্বয়ংক্রিয়ভাবে তার DNS রিজলভার হিসেবে বেছে নেয় না।
• রিজলভার নির্বাচন। প্রক্সি কন্টেইনারের ভেতরে ব্যবহৃত রিজলভারটি চিহ্নিত করুন। Compose-এর dns ফিল্ড DNS সার্ভারের ঠিকানা নেয়। অ্যাপ্লিকেশনে রিজলভ হওয়া dns.local-এর মতো নাম সেই ফিল্ডের বৈধ মান হয়ে ওঠে না।

প্রক্সি কন্টেইনার থেকে তার কনফিগার করা রিজলভার ঠিকানা পর্যন্ত কোয়েরিটি অনুসরণ করুন। সেই ঠিকানায় একটি রুট ও একটি DNS লিসেনার আছে কি না নিশ্চিত করুন। হোস্ট পোর্ট 53 প্রকাশ করা হোস্টের দিকে একটি অ্যাক্সেস পথ তৈরি করে; কিন্তু এটি কন্টেইনারদের সেটি ব্যবহার করতে বলে না। একটি নেটওয়ার্ক শেয়ার করা কন্টেইনারগুলো বরং সরাসরি যোগাযোগ করতে পারে।

যদি কনফিগারেশন DNS কন্টেইনারের ঠিকানা উল্লেখ করে, তবে সামঞ্জস্যপূর্ণ IPAM কনফিগারেশনের অধীনে সেটি স্থির রাখুন। গতকালের কন্টেইনার থেকে কপি করা গতিশীলভাবে বরাদ্দ ঠিকানা পুনঃনির্মাণে ব্যর্থ হতে পারে। রিজলভারের আপস্ট্রিম পথও পরীক্ষা করুন: উত্তরহীন কোয়েরি নিজের কাছে ফেরত পাঠানো একটি অগম্য রিজলভারের চেয়ে ভিন্ন ব্যর্থতা তৈরি করে।

শেষে, গন্তব্যটি কে রিজলভ করে তা চিহ্নিত করুন। CONNECT নাম রিজলভ করা একটি HTTP প্রক্সি এই কন্টেইনার পথ ব্যবহার করতে পারে; স্থানীয়ভাবে রিজলভ করা SOCKS ক্লায়েন্ট নাও করতে পারে। হোস্ট লুকআপ হোস্টের রুট প্রমাণ করে, প্রক্সি প্রসেসের নয়।