Proxyfouten in Terraform bij downloads, providers en externe runs
Onderscheid Terraform-registrydownloads, Git-moduleophalingen, provider-API-aanroepen en externe uitvoering wanneer de proxy maar voor een deel van een run werkt.
Een geslaagde providerdownload zegt weinig over een latere cloud-API-aanroep. Begin bij de eerste hostnaam en bewerking die mislukken en bepaal daarna de eigenaar:
| Bewerking | Volg dit pad |
|---|---|
| Registeropzoeking of installatiedownload | Terraform-proces, installatiebron en proxyomgeving |
| Git-gebaseerde moduleophaling | De bron-URL en Git-transport; SSH en HTTPS gebruiken verschillende instellingen |
| Cloud-API-aanroep | De providerplug-in en de routerings- en vertrouwensconfiguratie van zijn SDK |
| Externe uitvoering | De omgeving en het netwerk van de runner, niet die van de laptop |
Voor een HTTP-proxy die CONNECT ondersteunt, kan deze omgevingswaarde hem correct selecteren voor HTTPS-bestemmingen:
HTTPS_PROXY=http://proxy.example:3128De variabele benoemt het schema van de bestemming; de waarde benoemt het transport van de proxy. Gebruik https:// alleen wanneer de listener TLS biedt en de aanvragende client dit ondersteunt. Providers zijn afzonderlijke plug-ins en kunnen SDK-specifieke instellingen gebruiken, dus deze waarde is geen belofte over elke provider.
Bij de geïdentificeerde eigenaar onderscheidt u de foutlaag voordat u een instelling wijzigt: een geweigerde proxyverbinding, proxy 407, geweigerde CONNECT, certificaatfout en cloud-API 403 vernauwen elk het volgende onderzoek anders. Houd fase, bestemming, uitvoeringsomgeving en eerste fout bij elkaar.
Pas de ondersteunde instelling toe op dat onderdeel. Een export op de laptop configureert geen externe runner, en proxyreferenties authenticeren niet bij het register of de cloud-API.