Terraform-proxyfoute by aflaaie, verskaffers en afstandlopies
Onderskei Terraform-registeraflaaie, Git-module-ophalings, verskaffer-API-oproepe en afstanduitvoering wanneer 'n proxy net vir 'n deel van 'n lopie werk.
Dat 'n verskafferaflaai slaag, sê min oor 'n latere wolk-API-oproep. Begin by die eerste gasheernaam en bewerking wat misluk en identifiseer dan die eienaar daarvan:
| Bewerking | Volg hierdie pad |
|---|---|
| Registeropsoek of installasie-aflaai | Terraform-proses, installasiebron en proxy-omgewing |
| Git-gebaseerde module-ophaling | Die bron-URL en Git-transport; SSH en HTTPS gebruik verskillende instellings |
| Wolk-API-oproep | Die verskaffer-inprop en sy SDK se roetering- en vertrouenskonfigurasie |
| Afstanduitvoering | Die loper se omgewing en netwerk, nie die skootrekenaar s'n nie |
Vir 'n HTTP-proxy wat CONNECT ondersteun, kan hierdie omgewingswaarde dit korrek vir HTTPS-bestemmings kies:
HTTPS_PROXY=http://proxy.example:3128Die veranderlike noem die bestemmingskema; die waarde noem die proxy se transport. Gebruik https:// net wanneer die luisteraar TLS bied en die aanvraende kliënt dit ondersteun. Verskaffers is aparte inproppe en kan SDK-spesifieke instellings gebruik, so hierdie waarde is nie 'n belofte oor elke verskaffer nie.
By die geïdentifiseerde eienaar, onderskei die foutlaag voordat jy 'n instelling verander: 'n geweierde proxyverbinding, proxy 407, verwerpte CONNECT, sertifikaatfout en wolk-API 403 vernou elk die volgende ondersoek anders. Hou die fase, bestemming, uitvoeringsomgewing en eerste fout bymekaar.
Pas die ondersteunde instelling op daardie komponent toe. 'n Skootrekenaar-uitvoer stel nie 'n afstandloper op nie, en proxy-geloofsbriewe verifieer nie by die register of wolk-API nie.