Descărcarea imaginilor de bază Docker: proxy-ul constructorului versus argumentele de build
Argumentele de proxy transmise pașilor de build nu configurează fiecare cerere către registru făcută de constructor. Găsiți constructorul care rezolvă imaginea de bază.
Un build poate eșua la rezolvarea FROM înainte ca orice pas de descărcare a pachetelor din Dockerfile să ruleze. Clientul de registru al constructorului are nevoie de propria rută pentru a obține acea imagine de bază.
| Operațiune | Componenta care are nevoie de rută |
|---|---|
| Rezolvă și obține imaginea de bază | Clientul de registru al constructorului |
| Descărcare în timpul RUN | Procesul care execută pasul de build |
| Apelarea unei API la rulare | Aplicația care rulează |
Găsiți constructorul
Driverul Docker implicit se centrează pe daemon. Alți driveri Buildx pot folosi un container BuildKit dedicat, Kubernetes sau un serviciu la distanță. Configurați mecanismul de proxy acceptat de driverul ales acolo unde rulează acel worker.
Un proxy de buclă locală pe un laptop nu este accesibil automat dintr-un worker la distanță, iar editarea daemonului local nu reconfigurează acel constructor la distanță.
Un ARG înainte de FROM poate ajuta la alegerea referinței imaginii. Totuși, astfel nu este configurată ruta de rețea a clientului de registru. Comenzile RUN ulterioare care scriu setări de pachete sau instalează certificate nu pot repara această cerere anterioară.
Încredere, conturi și date din cache
Materialul CA aprobat trebuie să fie disponibil componentei care validează conexiunea inițială la registru. Credențialele de registru și cele de proxy autorizează părți diferite; o autentificare la registru nu poate răspunde unui 407 de proxy.
Un worker care refolosește date de imagine din cache poate să nu repete aceeași cerere de rețea ca un worker nou. Comparați operațiunea efectiv înregistrată în log. După ce accesul la imaginea de bază funcționează pe ruta dorită, diagnosticați orice descărcare ulterioară a pasului de build la acea următoare limită.