Провали на прокси в 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.