Docker-Basisimages pullen: Builder-Proxy versus Build-Argumente
Proxy-Argumente, die an Build-Schritte übergeben werden, konfigurieren nicht jede Registry-Anfrage des Builders. Finden Sie den Builder, der das Basisimage auflöst.
Ein Build kann beim Auflösen von FROM fehlschlagen, bevor ein Dockerfile-Paketdownload-Schritt läuft. Der Registry-Client des Builders braucht eine eigene Route, um dieses Basisimage zu beziehen.
| Vorgang | Komponente, die die Route benötigt |
|---|---|
| Basisimage auflösen und abrufen | Der Registry-Client des Builders |
| Download während RUN | Der Prozess, der den Build-Schritt ausführt |
| API-Aufruf zur Laufzeit | Die laufende Anwendung |
Den Builder lokalisieren
Der Standard-Docker-Treiber dreht sich um den Daemon. Andere Buildx-Treiber können einen dedizierten BuildKit-Container, Kubernetes oder einen entfernten Dienst nutzen. Konfigurieren Sie den vom gewählten Treiber unterstützten Proxy-Mechanismus dort, wo dieser Worker läuft.
Ein Loopback-Proxy auf einem Laptop ist von einem entfernten Worker nicht automatisch erreichbar, und das Bearbeiten des lokalen Daemons konfiguriert diesen entfernten Builder nicht um.
Ein ARG vor FROM kann helfen, die Image-Referenz zu wählen. Damit wird jedoch nicht die Netzwerkroute des Registry-Clients konfiguriert. Spätere RUN-Befehle, die Paketeinstellungen schreiben oder Zertifikate installieren, können diese frühere Anfrage nicht reparieren.
Vertrauen, Konten und zwischengespeicherte Daten
Freigegebenes CA-Material muss der Komponente zur Verfügung stehen, die die anfängliche Registry-Verbindung validiert. Registry-Anmeldedaten und Proxy-Anmeldedaten berechtigen unterschiedliche Parteien; eine Registry-Anmeldung kann keine Proxy-407 beantworten.
Ein Worker, der zwischengespeicherte Image-Daten wiederverwendet, wiederholt möglicherweise nicht dieselbe Netzwerkanfrage wie ein frischer Worker. Vergleichen Sie den tatsächlich protokollierten Vorgang. Sobald der Zugriff auf das Basisimage über die vorgesehene Route funktioniert, diagnostizieren Sie jeden späteren Download im Build-Schritt an dieser nächsten Grenze.