Falhas de proxy no Terraform em downloads, provedores e execuções remotas
Distinga os downloads do registro do Terraform, a obtenção de módulos Git, as chamadas à API do provedor e a execução remota quando o proxy só funciona em parte de uma execução.
Um download de provedor bem-sucedido diz pouco sobre uma chamada posterior à API da nuvem. Comece pelo primeiro nome de host e pela primeira operação que falham e depois identifique o responsável:
| Operação | Siga este caminho |
|---|---|
| Consulta ao registro ou download da instalação | Processo do Terraform, origem da instalação e ambiente do proxy |
| Obtenção de módulos via Git | A URL de origem e o transporte Git; SSH e HTTPS usam configurações diferentes |
| Chamada à API da nuvem | O plugin do provedor e a configuração de roteamento e confiança do seu SDK |
| Execução remota | O ambiente e a rede do executor, não os do laptop |
Para um proxy HTTP que oferece suporte a CONNECT, este valor de ambiente pode selecioná-lo corretamente para destinos HTTPS:
HTTPS_PROXY=http://proxy.example:3128A variável nomeia o esquema do destino; o valor nomeia o transporte do proxy. Use https:// apenas quando o listener oferecer TLS e o cliente solicitante o suportar. Os provedores são plugins separados e podem usar configurações específicas do SDK, então este valor não é uma promessa sobre cada provedor.
No responsável identificado, distinga a camada do erro antes de alterar uma configuração: uma conexão de proxy recusada, um proxy 407, um CONNECT rejeitado, um erro de certificado e um 403 da API da nuvem restringem a próxima investigação de formas diferentes. Mantenha juntos a fase, o destino, o ambiente de execução e o primeiro erro.
Aplique a configuração suportada a esse componente. Uma exportação no laptop não configura um executor remoto, e as credenciais do proxy não autenticam no registro nem na API da nuvem.