Сумісність NO_PROXY у curl, .NET і контейнерах
Перетворіть спільну політику прямого маршрутизування на конфігурацію, специфічну для клієнта, використовуючи невеликий набір репрезентативних адресатів.
Команда додає один рядок обходу до спільного файлу середовища. curl іде напряму, інший застосунок використовує проксі, а контейнер поводиться вже інакше. Спільний файл розповсюдив ті самі символи. Він не розповсюдив один спільний синтаксичний аналізатор.
Стійкий об'єкт — це політика: які адресати мають бути прямими і за яких умов? Тримайте її окремо від рядка, потрібного кожній програмі.
Спершу запишіть очікувані маршрути
Використовуйте репрезентативні адреси, включно з межовими випадками, а не лише з простими успіхами:
| Форма адресата | Питання до власника політики |
|---|---|
| Батьківський домен | Його обходити чи лише його дочірні домени? |
| Піддомен | Чи успадковує він той самий маршрут? |
| Буквальна приватна IP | Чи доступна ця адреса безпосередньо з цього клієнта? |
| Той самий сервіс під іменем хоста | Чи мають збігатися запити за іменем і за адресою? |
| Інший порт сервісу | Виняток охоплює хост чи один прослуховувач? |
Далі визначте споживачів: демон, що завантажує образ, програма всередині контейнера, мовна HTTP-бібліотека та інтерактивний браузер можуть бути окремими записами. Конфігурація проксі клієнта Docker може заповнити значення середовища контейнера, не змушуючи кожного клієнта всередині реалізовувати ті самі правила зіставлення.
Перекладайте, а не копіюйте наосліп
Один задокументований приклад реальної різниці — межа батьківського домену. Виняток домену в curl охоплює названий домен і відповідні дочірні. Політика середовища .NET розрізняє голе ім'я та форму піддомену з провідною крапкою. Універсальне правило «завжди додавати провідну крапку» не може надійно виразити обидві політики.
Підтримка діапазонів IP також залежить від споживача та його версії. Машина з новим окремим curl усе ще може запускати застосунок, скомпонований зі старішою libcurl, або клієнт, що використовує зовсім іншу бібліотеку. Випуск операційної системи — не повний перелік клієнтів.
Для кожного споживача запишіть підтримуваний інтерфейс конфігурації та найменший вираз запланованих маршрутів. Короткий явний список хостів може бути кращим за хитрий шаблон, сенс якого ніхто не може пояснити.
Тримайте докази конфігурації окремо від доказів з'єднання
Розібране налаштування або API рішення про маршрут може показати, що вибрала програма. Результат запиту потім показує, чи був цей маршрут придатним. У .NET HttpClient.DefaultProxy.IsBypassed дає таку перевірку з боку конфігурації, коли використовується політика проксі за замовчуванням. Не діагностуйте недоступний прямий сервіс як збій аналізатора обходу лише тому, що запит завершився за тайм-аутом.
Зберігайте межові адресати під час оновлення клієнта чи базового образу. Вони роблять майбутні зміни сумісності видимими, не вимагаючи, щоб уся команда заново з'ясовувала, чому файл містить два схожі записи домену.