Terraform-proxyfejl ved downloads, udbydere og fjernkørsler
Skeln mellem Terraform-registrydownloads, Git-modulhentninger, udbyder-API-kald og fjernudførelse, når proxyen kun virker for en del af en kørsel.
En vellykket udbyderdownload siger lidt om et senere cloud-API-kald. Start med det første værtsnavn og den første handling, der fejler, og find derefter ejeren:
| Handling | Følg denne vej |
|---|---|
| Registry-opslag eller installationsdownload | Terraform-proces, installationskilde og proxy-miljø |
| Git-baseret modulhentning | Kilde-URL og Git-transport; SSH og HTTPS bruger forskellige indstillinger |
| Cloud-API-kald | Udbyder-pluginet og dets SDK's routing- og tillidskonfiguration |
| Fjernudførelse | Runnerens miljø og netværk, ikke laptopens |
For en HTTP-proxy, der understøtter CONNECT, kan denne miljøværdi vælge den korrekt til HTTPS-destinationer:
HTTPS_PROXY=http://proxy.example:3128Variablen angiver destinationens skema; værdien angiver proxyens transport. Brug kun https://, når lytteren tilbyder TLS, og den anmodende klient understøtter det. Udbydere er separate plugins og kan bruge SDK-specifikke indstillinger, så denne værdi er ikke et løfte om hver udbyder.
Ved den identificerede ejer skal du skelne fejllaget, før du ændrer en indstilling: en afvist proxyforbindelse, proxy 407, afvist CONNECT, certifikatfejl og cloud-API 403 indsnævrer hver den næste undersøgelse forskelligt. Hold fase, destination, kørselsmiljø og første fejl sammen.
Anvend den understøttede indstilling på den komponent. En eksport på laptopens konfigurerer ikke en fjern-runner, og proxy-legitimationsoplysninger godkender ikke over for registret eller cloud-API'et.