Proxyfel i Terraform vid nedladdningar, leverantörer och fjärrkörningar
Skilj mellan Terraform-registrets nedladdningar, Git-modulhämtningar, leverantörens API-anrop och fjärrexekvering när proxyn bara fungerar för en del av en körning.
En lyckad leverantörsnedladdning säger lite om ett senare moln-API-anrop. Börja med det första värdnamnet och den första åtgärden som misslyckas och identifiera sedan ägaren:
| Åtgärd | Följ den här vägen |
|---|---|
| Registersökning eller installationsnedladdning | Terraform-process, installationskälla och proxy-miljö |
| Git-baserad modulhämtning | Käll-URL:en och Git-transporten; SSH och HTTPS använder olika inställningar |
| Moln-API-anrop | Leverantörens plugin och dess SDK:s routnings- och förtroendekonfiguration |
| Fjärrexekvering | Runnerns miljö och nätverk, inte laptopens |
För en HTTP-proxy som stöder CONNECT kan det här miljövärdet välja den korrekt för HTTPS-destinationer:
HTTPS_PROXY=http://proxy.example:3128Variabeln namnger destinationens schema; värdet namnger proxyns transport. Använd https:// bara när lyssnaren erbjuder TLS och klienten som begär det stöder det. Leverantörer är separata plugin och kan använda SDK-specifika inställningar, så värdet är inget löfte om varje leverantör.
Hos den identifierade ägaren, skilj på fellagret innan du ändrar en inställning: en nekad proxyanslutning, proxy 407, nekad CONNECT, certifikatfel och moln-API 403 begränsar var och en nästa undersökning på olika sätt. Håll fas, destination, körningsmiljö och första fel tillsammans.
Tillämpa den stödda inställningen på den komponenten. En export på laptopen konfigurerar ingen fjärrkörning, och proxyuppgifter autentiserar inte mot registret eller moln-API:t.