Terraform-Proxyfehler bei Downloads, Providern und Remote-Läufen
Unterscheiden Sie Registry-Downloads, Git-Modulabrufe, Provider-API-Aufrufe und Remote-Ausführung, wenn der Proxy nur für einen Teil eines Laufs funktioniert.
Ein erfolgreicher Provider-Download sagt wenig über einen späteren Cloud-API-Aufruf aus. Beginnen Sie mit dem ersten fehlschlagenden Hostnamen und Vorgang und bestimmen Sie dann dessen Eigentümer:
| Vorgang | Diesen Weg verfolgen |
|---|---|
| Registry-Suche oder Installationsdownload | Terraform-Prozess, Installationsquelle und Proxy-Umgebung |
| Git-basierter Modulabruf | Quell-URL und Git-Transport; SSH und HTTPS verwenden unterschiedliche Einstellungen |
| Cloud-API-Aufruf | Das Provider-Plugin und die Routing- und Vertrauenskonfiguration seines SDK |
| Remote-Ausführung | Umgebung und Netzwerk des Runners, nicht des Laptops |
Für einen HTTP-Proxy, der CONNECT unterstützt, kann dieser Umgebungswert ihn für HTTPS-Ziele korrekt auswählen:
HTTPS_PROXY=http://proxy.example:3128Die Variable benennt das Schema des Ziels; der Wert benennt den Transport des Proxys. Verwenden Sie https:// nur, wenn der Listener TLS anbietet und der anfragende Client es unterstützt. Provider sind separate Plugins und können SDK-spezifische Einstellungen verwenden, daher ist dieser Wert kein Versprechen für jeden Provider.
Beim identifizierten Eigentümer unterscheiden Sie die Fehlerebene, bevor Sie eine Einstellung ändern: eine abgelehnte Proxy-Verbindung, Proxy 407, zurückgewiesenes CONNECT, Zertifikatfehler und Cloud-API 403 grenzen die nächste Untersuchung jeweils anders ein. Halten Sie Phase, Ziel, Ausführungsumgebung und ersten Fehler zusammen.
Wenden Sie die unterstützte Einstellung auf diese Komponente an. Ein Export auf dem Laptop konfiguriert keinen Remote-Runner, und Proxy-Anmeldedaten authentifizieren nicht gegenüber der Registry oder der Cloud-API.