curl, .NET এবং কন্টেইনার জুড়ে NO_PROXY সামঞ্জস্য
একটি সাধারণ সরাসরি-রাউটিং নীতি ছোট সংখ্যক প্রতিনিধিত্বমূলক গন্তব্য ব্যবহার করে ক্লায়েন্ট-নির্দিষ্ট কনফিগারেশনে রূপান্তর করুন।
একটি দল একটি বাইপাস স্ট্রিং একটি সাধারণ পরিবেশ ফাইলে রাখে। curl সরাসরি যায়, অন্য একটি অ্যাপ্লিকেশন প্রক্সি ব্যবহার করে, আর একটি কন্টেইনার আবার ভিন্নভাবে আচরণ করে। সাধারণ ফাইলটি একই অক্ষর বিতরণ করেছিল। কিন্তু এটি একটি সাধারণ পার্সার বিতরণ করেনি।
স্থায়ী বস্তুটি হলো নীতি: কোন গন্তব্যগুলো সরাসরি হওয়া উচিত, কোন শর্তে? প্রতিটি প্রোগ্রামের প্রয়োজনীয় স্ট্রিং থেকে এটিকে আলাদা রাখুন।
প্রথমে প্রত্যাশিত রুটগুলো লিখুন
শুধু সহজ সাফল্য নয়, সীমানাসহ প্রতিনিধিত্বমূলক ঠিকানা ব্যবহার করুন:
| গন্তব্যের আকৃতি | নীতি মালিকের জন্য প্রশ্ন |
|---|---|
| মূল ডোমেইন | এটি বাইপাস করবে, নাকি শুধু এর সন্তানগুলো? |
| একটি সাবডোমেইন | এটি একই রুট উত্তরাধিকার করে? |
| একটি আক্ষরিক ব্যক্তিগত IP | এই ঠিকানাটি কি এই ক্লায়েন্ট থেকে সরাসরি পৌঁছানো যায়? |
| হোস্টনামের অধীনে একই পরিষেবা | নাম-ভিত্তিক এবং ঠিকানা-ভিত্তিক অনুরোধ কি একমত হওয়া উচিত? |
| অন্য একটি পরিষেবা পোর্ট | ব্যতিক্রমটি কি হোস্টকে নাকি একটি শ্রোতাকে কভার করে? |
তারপর গ্রাহকদের চিহ্নিত করুন: ইমেজ টানা ডেমন, কন্টেইনারের ভেতরের প্রোগ্রাম, একটি ভাষার HTTP লাইব্রেরি এবং একটি ইন্টারঅ্যাকটিভ ব্রাউজার সবই আলাদা এন্ট্রি হতে পারে। একটি Docker ক্লায়েন্ট প্রক্সি কনফিগারেশন কন্টেইনার পরিবেশের মান পূরণ করতে পারে, ভেতরের প্রতিটি ক্লায়েন্টকে একই মিলকরণ নিয়ম প্রয়োগ করতে না দিয়েই।
অন্ধভাবে অনুলিপি না করে অনুবাদ করুন
বাস্তব পার্থক্যের একটি নথিভুক্ত উদাহরণ হলো মূল-ডোমেইন সীমানা। curl-এর ডোমেইন বাদ দেওয়া নামকৃত ডোমেইন এবং মিলে যাওয়া সন্তানদের কভার করে। .NET-এর পরিবেশ নীতি খালি নামটিকে শুরুর বিন্দু সাবডোমেইন রূপ থেকে আলাদা করে। সবসময় শুরুর বিন্দু যোগ করুন এমন একটি সর্বজনীন নিয়ম দুটি নীতিই নির্ভরযোগ্যভাবে প্রকাশ করতে পারে না।
IP পরিসরের সমর্থনও গ্রাহক এবং তার সংস্করণের উপর নির্ভর করে। নতুন স্বতন্ত্র curl থাকা একটি মেশিন এখনও পুরোনো libcurl-এর সাথে সংযুক্ত অ্যাপ্লিকেশন, বা সম্পূর্ণ ভিন্ন লাইব্রেরি ব্যবহার করা ক্লায়েন্ট চালাতে পারে। অপারেটিং সিস্টেমের সংস্করণ সম্পূর্ণ ক্লায়েন্ট তালিকা নয়।
প্রতিটি গ্রাহকের জন্য তার সমর্থিত কনফিগারেশন ইন্টারফেস এবং অভিপ্রেত রুটগুলোর ক্ষুদ্রতম প্রকাশ লিপিবদ্ধ করুন। একটি সংক্ষিপ্ত স্পষ্ট হোস্ট তালিকা এমন একটি চতুর প্যাটার্নের চেয়ে ভালো হতে পারে যার অর্থ কেউ ব্যাখ্যা করতে পারে না।
কনফিগারেশন প্রমাণ সংযোগ প্রমাণ থেকে আলাদা রাখুন
একটি পার্স করা সেটিং বা রাউটিং-সিদ্ধান্ত API দেখাতে পারে প্রোগ্রামটি কী বেছে নিয়েছে। তারপর একটি অনুরোধের ফলাফল দেখায় সেই রুটটি ব্যবহারযোগ্য ছিল কিনা। .NET-এ, HttpClient.DefaultProxy.IsBypassed এই কনফিগারেশন-পক্ষের যাচাই সরবরাহ করে যখন ডিফল্ট প্রক্সিই ব্যবহৃত নীতি। শুধু অনুরোধের সময় শেষ হওয়ার কারণে একটি অপ্রাপ্য সরাসরি পরিষেবাকে বাইপাস-পার্সার ব্যর্থতা হিসেবে নির্ণয় করবেন না।
ক্লায়েন্ট বা বেস ইমেজ আপডেট করার সময় সীমানা গন্তব্যগুলো রাখুন। এগুলো ভবিষ্যতের সামঞ্জস্য পরিবর্তনগুলো দৃশ্যমান করে, পুরো দলকে ফাইলে দুটি একইরকম দেখতে ডোমেইন এন্ট্রি কেন আছে তা আবার আবিষ্কার করতে না দিয়েই।