سازگاری NO_PROXY در curl، .NET و کانتینرها
یک سیاست مسیریابی مستقیم مشترک را با مجموعه‌ای کوچک از مقصدهای نمونه به پیکربندی مخصوص هر کلاینت تبدیل کنید.
یک تیم یک رشته عبور را در یک فایل محیطی مشترک قرار می‌دهد. curl مستقیم می‌رود، برنامه دیگری از پروکسی استفاده می‌کند و کانتینر دوباره طور دیگری رفتار می‌کند. فایل مشترک همان کاراکترها را توزیع کرد. اما یک تجزیه‌کننده مشترک را توزیع نکرد.
شیء پایدار سیاست است: کدام مقصدها باید مستقیم باشند و تحت چه شرایطی؟ آن را از رشته‌ای که هر برنامه نیاز دارد جدا نگه دارید.
ابتدا مسیرهای مورد انتظار را بنویسید
از نشانی‌های نمونه استفاده کنید، از جمله مرزها و نه فقط موفقیت‌های آسان:
| شکل مقصد | پرسش از مالک سیاست |
|---|---|
| دامنه والد | آیا باید عبور کند یا فقط فرزندانش؟ |
| یک زیردامنه | آیا همان مسیر را به ارث می‌برد؟ |
| یک IP خصوصی تحت‌اللفظی | آیا آن نشانی مستقیماً از این کلاینت قابل دسترسی است؟ |
| همان سرویس زیر یک نام میزبان | آیا درخواست‌های مبتنی بر نام و مبتنی بر نشانی باید یکسان باشند؟ |
| درگاه سرویس دیگر | آیا استثنا میزبان را پوشش می‌دهد یا یک شنونده را؟ |
سپس مصرف‌کننده‌ها را شناسایی کنید: دیمونی که یک ایمیج را می‌کشد، برنامه داخل کانتینر، یک کتابخانه HTTP زبان و یک مرورگر تعاملی می‌توانند همه ورودی‌های جداگانه باشند. پیکربندی پروکسی کلاینت Docker می‌تواند مقادیر محیطی کانتینر را پر کند بدون اینکه هر کلاینت درون آن مجبور باشد همان قواعد تطبیق را پیاده‌سازی کند.
ترجمه کنید نه کپی کورکورانه
یک نمونه مستند از تفاوت واقعی، مرز دامنه والد است. استثنای دامنه در curl دامنه نام‌برده و فرزندان منطبق را پوشش می‌دهد. سیاست محیطی .NET بین نام خالی و شکل زیردامنه با نقطه پیشرو تمایز می‌گذارد. قاعده جهانی همیشه یک نقطه پیشرو اضافه کن نمی‌تواند هر دو سیاست را به‌طور قابل اعتماد بیان کند.
پشتیبانی از بازه‌های IP نیز به مصرف‌کننده و نسخه آن بستگی دارد. ماشینی با curl مستقل جدید هنوز می‌تواند برنامه‌ای را اجرا کند که به libcurl قدیمی‌تر پیوند خورده است، یا کلاینتی که کتابخانه‌ای کاملاً دیگر را به کار می‌برد. نسخه سیستم‌عامل فهرست کامل کلاینت‌ها نیست.
برای هر مصرف‌کننده، رابط پیکربندی پشتیبانی‌شده و کوچک‌ترین بیان مسیرهای مورد نظر را ثبت کنید. فهرست کوتاه و صریح میزبان‌ها می‌تواند بهتر از یک الگوی هوشمندانه باشد که هیچ‌کس نمی‌تواند معنایش را توضیح دهد.
شواهد پیکربندی را از شواهد اتصال جدا نگه دارید
یک تنظیم تجزیه‌شده یا API تصمیم‌های مسیریابی می‌تواند نشان دهد برنامه چه چیزی را انتخاب کرده است. سپس نتیجه درخواست نشان می‌دهد آیا آن مسیر قابل استفاده بود. در .NET، HttpClient.DefaultProxy.IsBypassed آن بررسی سمت پیکربندی را فراهم می‌کند وقتی پروکسی پیش‌فرض سیاست در حال استفاده است. یک سرویس مستقیم دسترس‌ناپذیر را فقط به این دلیل که مهلت درخواست تمام شد، خرابی تجزیه‌کننده عبور تشخیص ندهید.
هنگام به‌روزرسانی یک کلاینت یا ایمیج پایه، مقصدهای مرزی را نگه دارید. آن‌ها تغییرات سازگاری آینده را قابل مشاهده می‌کنند بدون اینکه کل تیم مجبور شود دوباره کشف کند چرا فایل دو ورودی دامنه شبیه به هم دارد.