Fallos de proxy en Terraform en descargas, provedores e execucións remotas
Distinga as descargas do rexistro de Terraform, a obtención de módulos Git, as chamadas á API do provedor e a execución remota cando o proxy só funciona nunha parte dunha execución.
Unha descarga correcta dun provedor di pouco sobre unha chamada posterior á API da nube. Comece polo primeiro nome de host e a primeira operación que fallan e despois identifique o seu responsable:
| Operación | Siga esta ruta |
|---|---|
| Consulta ao rexistro ou descarga de instalación | Proceso de Terraform, orixe da instalación e contorno do proxy |
| Obtención de módulos mediante Git | A URL de orixe e o transporte Git; SSH e HTTPS usan axustes distintos |
| Chamada á API da nube | O complemento do provedor e a configuración de encamiñamento e confianza do seu SDK |
| Execución remota | O contorno e a rede do executante, non os do portátil |
Para un proxy HTTP que admite CONNECT, este valor de contorno pode seleccionalo correctamente para destinos HTTPS:
HTTPS_PROXY=http://proxy.example:3128A variable nomea o esquema do destino; o valor nomea o transporte do proxy. Use https:// só cando o receptor ofreza TLS e o cliente solicitante o admita. Os provedores son complementos separados e poden usar axustes específicos do SDK, así que este valor non é unha promesa sobre cada provedor.
No responsable identificado, distinga a capa de erro antes de cambiar un axuste: unha conexión de proxy rexeitada, un proxy 407, un CONNECT rexeitado, un erro de certificado e un 403 da API da nube acoutan a seguinte investigación de xeito distinto. Manteña xuntos a fase, o destino, o contorno de execución e o primeiro erro.
Aplique o axuste admitido a ese compoñente. Unha exportación no portátil non configura un executante remoto, e as credenciais do proxy non autentican ante o rexistro nin a API da nube.