Proxyfeil i Terraform ved nedlastingar, leverandørar og fjernkøyringar
Skil mellom nedlastingar frå Terraform-registeret, henting av Git-modular, leverandør-API-kall og fjernkøyring når proxyen berre verkar for ein del av ei køyring.
Ei vellukka leverandørnedlasting seier lite om eit seinare sky-API-kall. Start med det første vertsnamnet og den første operasjonen som feilar, og finn deretter eigaren:
| Operasjon | Følg denne vegen |
|---|---|
| Registeroppslag eller installasjonsnedlasting | Terraform-prosess, installasjonskjelde og proxy-miljø |
| Git-basert modulhenting | Kjelde-URL-en og Git-transporten; SSH og HTTPS brukar ulike innstillingar |
| Sky-API-kall | Leverandørpluginen og ruting- og tillitskonfigurasjonen til SDK-et |
| Fjernkøyring | Miljøet og nettverket til køyraren, ikkje den berbare |
For ein HTTP-proxy som støttar CONNECT, kan denne miljøverdien velja han rett for HTTPS-destinasjonar:
HTTPS_PROXY=http://proxy.example:3128Variabelen namngir skjemaet til destinasjonen; verdien namngir transporten til proxyen. Bruk https:// berre når lyttaren tilbyr TLS og klienten som spør støttar det. Leverandørar er eigne plugin-modular og kan bruka SDK-spesifikke innstillingar, så denne verdien er ikkje eit løfte om kvar leverandør.
Hjå den identifiserte eigaren, skil feillaget før du endrar ei innstilling: ei avvist proxyforbinding, proxy 407, avvist CONNECT, sertifikatfeil og sky-API 403 snevrar kvar inn den neste undersøkinga på ulikt vis. Hald fase, destinasjon, køyringsmiljø og første feil saman.
Bruk den støtta innstillinga på den komponenten. Ein eksport på den berbare konfigurerer ikkje ein fjernkøyrar, og proxy-legitimasjon autentiserer ikkje mot registeret eller sky-API-et.