Un build peut échouer lors de la résolution de FROM avant l'exécution de toute étape de téléchargement de paquets du Dockerfile. Le client de registre du constructeur a besoin de sa propre route pour obtenir cette image de base.

OpérationComposant ayant besoin de la route
Résoudre et récupérer l'image de baseLe client de registre du constructeur
Téléchargement pendant RUNLe processus qui exécute l'étape de build
Appeler une API à l'exécutionL'application en cours d'exécution

Localiser le constructeur

Le pilote Docker par défaut s'articule autour du démon. D'autres pilotes Buildx peuvent utiliser un conteneur BuildKit dédié, Kubernetes ou un service distant. Configurez le mécanisme de proxy pris en charge par le pilote choisi là où ce worker s'exécute.

Un proxy en boucle locale sur un ordinateur portable n'est pas automatiquement joignable depuis un worker distant, et modifier le démon local ne reconfigure pas ce constructeur distant.

Un ARG avant FROM peut aider à choisir la référence d'image. Il ne configure pas pour autant la route réseau du client de registre. Les commandes RUN ultérieures qui écrivent les paramètres de paquets ou installent des certificats ne peuvent pas réparer cette requête antérieure.

Confiance, comptes et données en cache

Le matériel CA approuvé doit être disponible pour le composant qui valide la connexion initiale au registre. Les identifiants de registre et les identifiants de proxy autorisent des parties différentes ; une connexion au registre ne peut pas répondre à un 407 du proxy.

Un worker qui réutilise des données d'image en cache peut ne pas répéter la même requête réseau qu'un worker neuf. Comparez l'opération réellement journalisée. Une fois l'accès à l'image de base fonctionnel via la route prévue, diagnostiquez tout téléchargement ultérieur d'étape de build à cette frontière suivante.

Articles similaires