Збої проксі в Terraform під час завантажень, провайдерів і віддалених запусків
Розрізняйте завантаження з реєстру Terraform, отримання модулів Git, виклики API провайдера та віддалене виконання, коли проксі працює лише для частини запуску.
Успішне завантаження провайдера мало говорить про наступний виклик хмарного API. Почніть з першого імені хоста й операції, що завершуються помилкою, потім визначте їхнього власника:
| Операція | Дотримуйтеся цього шляху |
|---|---|
| Пошук у реєстрі або завантаження встановлення | Процес Terraform, джерело встановлення й середовище проксі |
| Отримання модуля через Git | URL джерела й транспорт Git; SSH і HTTPS використовують різні налаштування |
| Виклик хмарного API | Плагін провайдера та його конфігурація маршрутизації й довіри в SDK |
| Віддалене виконання | Середовище й мережа виконавця, а не ноутбука |
Для HTTP-проксі, що підтримує CONNECT, це значення середовища може правильно вибрати його для призначень HTTPS:
HTTPS_PROXY=http://proxy.example:3128Змінна називає схему призначення; значення називає транспорт проксі. Використовуйте https:// лише коли слухач пропонує TLS і клієнт, що надсилає запит, це підтримує. Провайдери — окремі плагіни й можуть використовувати налаштування, специфічні для SDK, тож це значення не є обіцянкою щодо кожного провайдера.
У визначеного власника розрізняйте шар помилки перед зміною налаштування: відхилене з'єднання з проксі, проксі 407, відхилений CONNECT, помилка сертифіката й хмарний API 403 кожен по-своєму звужує наступне розслідування. Тримайте разом етап, призначення, середовище виконання й першу помилку.
Застосуйте підтримуване налаштування до цього компонента. Експорт на ноутбуці не налаштовує віддалений виконавець, а облікові дані проксі не автентифікують у реєстрі чи хмарному API.