„Terraform“ tarpinio serverio gedimai atsisiunčiant, teikėjams ir nuotoliniams paleidimams
Atskirkite „Terraform“ registro atsisiuntimus, „Git“ modulių gavimą, teikėjo API kreipinius ir nuotolinį vykdymą, kai tarpinis serveris veikia tik dalyje paleidimo.
Sėkmingas teikėjo atsisiuntimas mažai pasako apie vėlesnį debesies API kreipinį. Pradėkite nuo pirmojo nepavykusio pagrindinio kompiuterio vardo ir operacijos, tada nustatykite jų savininką:
| Operacija | Eikite šiuo keliu |
|---|---|
| Registro paieška arba diegimo atsisiuntimas | „Terraform“ procesas, diegimo šaltinis ir tarpinio serverio aplinka |
| „Git“ pagrindu gaunamas modulis | Šaltinio URL ir „Git“ transportavimas; SSH ir HTTPS naudoja skirtingus nustatymus |
| Debesies API kreipinys | Teikėjo papildinys ir jo SDK maršrutizavimo bei pasitikėjimo konfigūracija |
| Nuotolinis vykdymas | Vykdytojo aplinka ir tinklas, o ne nešiojamojo kompiuterio |
HTTP tarpiniam serveriui, palaikančiam CONNECT, ši aplinkos reikšmė gali teisingai jį parinkti HTTPS paskirties vietoms:
HTTPS_PROXY=http://proxy.example:3128Kintamasis įvardija paskirties schemą; reikšmė įvardija tarpinio serverio transportavimą. Naudokite https:// tik kai klausytojas siūlo TLS ir užklausą siunčiantis klientas tai palaiko. Teikėjai yra atskiri papildiniai ir gali naudoti SDK būdingus nustatymus, todėl ši reikšmė nėra pažadas apie kiekvieną teikėją.
Pas nustatytą savininką atskirkite klaidos sluoksnį prieš keisdami nustatymą: atmestas tarpinio serverio ryšys, tarpinis serveris 407, atmestas CONNECT, sertifikato klaida ir debesies API 403 kiekvienas kitaip susiaurina tolesnį tyrimą. Laikykite kartu etapą, paskirtį, vykdymo aplinką ir pirmąją klaidą.
Taikykite palaikomą nustatymą tam komponentui. Eksportas nešiojamajame kompiuteryje nesukonfigūruoja nuotolinio vykdytojo, o tarpinio serverio prisijungimo duomenys neautentifikuoja registro ar debesies API atžvilgiu.