Errori del proxy in Terraform tra download, provider ed esecuzioni remote
Distinguere i download del registro Terraform, il recupero dei moduli Git, le chiamate API del provider e l'esecuzione remota quando il proxy funziona solo per una parte di un'esecuzione.
Un download del provider riuscito dice poco su una successiva chiamata all'API cloud. Iniziate dal primo nome host e dalla prima operazione che falliscono, poi identificate il responsabile:
| Operazione | Seguite questo percorso |
|---|---|
| Ricerca nel registro o download dell'installazione | Processo Terraform, origine dell'installazione e ambiente proxy |
| Recupero di moduli tramite Git | L'URL di origine e il trasporto Git; SSH e HTTPS usano impostazioni diverse |
| Chiamata all'API cloud | Il plugin del provider e la configurazione di routing e fiducia del suo SDK |
| Esecuzione remota | L'ambiente e la rete dell'esecutore, non quelli del portatile |
Per un proxy HTTP che supporta CONNECT, questo valore d'ambiente può selezionarlo correttamente per destinazioni HTTPS:
HTTPS_PROXY=http://proxy.example:3128La variabile nomina lo schema della destinazione; il valore nomina il trasporto del proxy. Usate https:// solo quando il listener offre TLS e il client richiedente lo supporta. I provider sono plugin separati e possono usare impostazioni specifiche dell'SDK, quindi questo valore non è una promessa su ogni provider.
Presso il responsabile identificato, distinguete il livello dell'errore prima di cambiare un'impostazione: una connessione proxy rifiutata, un proxy 407, un CONNECT rifiutato, un errore di certificato e un 403 dell'API cloud restringono ciascuno l'indagine successiva in modo diverso. Tenete insieme fase, destinazione, ambiente di esecuzione e primo errore.
Applicate l'impostazione supportata a quel componente. Un export sul portatile non configura un esecutore remoto, e le credenziali del proxy non autenticano verso il registro o l'API cloud.