Un téléchargement de fournisseur réussi ne dit pas grand-chose d'un appel d'API cloud ultérieur. Commencez par le premier nom d'hôte et la première opération qui échouent, puis identifiez leur responsable :

OpérationSuivez ce chemin
Recherche dans le registre ou téléchargement d'installationProcessus Terraform, source d'installation et environnement proxy
Récupération de module via GitL'URL source et le transport Git ; SSH et HTTPS utilisent des réglages différents
Appel d'API cloudLe plugin du fournisseur et la configuration de routage et de confiance de son SDK
Exécution distanteL'environnement et le réseau de l'exécuteur, pas ceux du portable

Pour un proxy HTTP qui prend en charge CONNECT, cette valeur d'environnement peut le sélectionner correctement pour des destinations HTTPS :

HTTPS_PROXY=http://proxy.example:3128

La variable nomme le schéma de la destination ; la valeur nomme le transport du proxy. N'utilisez https:// que lorsque l'écouteur propose TLS et que le client demandeur le prend en charge. Les fournisseurs sont des plugins distincts et peuvent utiliser des réglages propres au SDK, donc cette valeur n'est pas une promesse pour chaque fournisseur.

Chez le responsable identifié, distinguez la couche d'erreur avant de changer un réglage : une connexion proxy refusée, un proxy 407, un CONNECT rejeté, une erreur de certificat et un 403 de l'API cloud orientent chacun l'investigation suivante différemment. Gardez ensemble la phase, la destination, l'environnement d'exécution et la première erreur.

Appliquez le réglage pris en charge à ce composant. Une exportation sur le portable ne configure pas un exécuteur distant, et les identifiants du proxy ne s'authentifient pas auprès du registre ni de l'API cloud.

Articles similaires