Сбои прокси в 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.