Eșecuri ale proxy-ului în Terraform la descărcări, furnizori și rulări la distanță
Distingeți descărcările din registrul Terraform, obținerea modulelor Git, apelurile API ale furnizorului și execuția la distanță atunci când proxy-ul funcționează doar pentru o parte a unei rulări.
O descărcare reușită a unui furnizor spune puțin despre un apel API ulterior către cloud. Începeți cu primul nume de gazdă și prima operațiune care eșuează, apoi identificați proprietarul acestora:
| Operațiune | Urmați această cale |
|---|---|
| Căutare în registru sau descărcarea instalării | Procesul Terraform, sursa instalării și mediul proxy |
| Obținerea unui modul prin Git | URL-ul sursei și transportul Git; SSH și HTTPS folosesc setări diferite |
| Apel API către cloud | Pluginul furnizorului și configurația de rutare și de încredere a SDK-ului său |
| Execuție la distanță | Mediul și rețeaua executorului, nu ale laptopului |
Pentru un proxy HTTP care acceptă CONNECT, această valoare de mediu îl poate selecta corect pentru destinații HTTPS:
HTTPS_PROXY=http://proxy.example:3128Variabila numește schema destinației; valoarea numește transportul proxy-ului. Folosiți https:// numai când listenerul oferă TLS și clientul care face cererea îl acceptă. Furnizorii sunt pluginuri separate și pot folosi setări specifice SDK-ului, așa că această valoare nu este o promisiune despre fiecare furnizor.
La proprietarul identificat, distingeți stratul erorii înainte de a schimba o setare: o conexiune proxy refuzată, proxy 407, CONNECT respins, eroare de certificat și 403 de la API-ul cloud restrâng fiecare altfel investigația următoare. Țineți împreună faza, destinația, mediul de execuție și prima eroare.
Aplicați setarea acceptată acelui component. Un export pe laptop nu configurează un executor la distanță, iar acreditările proxy nu se autentifică la registru sau la API-ul cloud.