Hämtning av Docker-basavbildningar: byggarproxy kontra byggargument
Proxyargument som ges till byggsteg konfigurerar inte varje registerförfrågan som byggaren gör. Hitta byggaren som löser basavbildningen.
En byggnation kan misslyckas när FROM löses upp innan något Dockerfile-paketnedladdningssteg körs. Byggarens registerklient behöver sin egen väg för att hämta den basavbildningen.
| Åtgärd | Komponent som behöver vägen |
|---|---|
| Lös upp och hämta basavbildningen | Byggarens registerklient |
| Nedladdning under RUN | Processen som utför byggsteget |
| Anropa ett API vid körtid | Programmet som körs |
Hitta byggaren
Standard-Docker-drivrutinen kretsar kring daemonen. Andra Buildx-drivrutiner kan använda en dedikerad BuildKit-container, Kubernetes eller en fjärrtjänst. Konfigurera den valda drivrutinens proxy-mekanism där den workern körs.
En loopback-proxy på en laptop är inte automatiskt nåbar från en fjärrworker, och att redigera den lokala daemonen omkonfigurerar inte den fjärrbyggaren.
Ett ARG före FROM kan hjälpa till att välja avbildningsreferens. Det konfigurerar dock inte därmed registerklientens nätverksväg. Senare RUN-kommandon som skriver paketinställningar eller installerar certifikat kan inte reparera denna tidigare förfrågan.
Förtroende, konton och cachelagrade data
Godkänt CA-material måste vara tillgängligt för komponenten som validerar den första registeranslutningen. Registeruppgifter och proxyuppgifter auktoriserar olika parter; en registerinloggning kan inte svara på en proxy 407.
En worker som återanvänder cachelagrade avbildningsdata upprepar kanske inte samma nätverksförfrågan som en ny worker. Jämför den faktiskt loggade åtgärden. När åtkomsten till basavbildningen fungerar via den avsedda vägen, diagnostisera eventuell senare nedladdning i byggsteget vid den nästa gränsen.