Henting av Docker-basisavbildninger: byggerproxy kontra byggeargumenter
Proxyargumenter som gis til byggetrinn, konfigurerer ikke hver registerforespørsel som byggeren gjør. Finn byggeren som løser basisavbildningen.
En bygging kan mislykkes under oppslaget av FROM før noe Dockerfile-pakkedownload-trinn kjører. Byggerens registerklient trenger sin egen rute for å hente den basisavbildningen.
| Operasjon | Komponent som trenger ruten |
|---|---|
| Løs opp og hent basisavbildningen | Byggerens registerklient |
| Nedlasting under RUN | Prosessen som utfører byggetrinnet |
| Kalle et API ved kjøretid | Applikasjonen som kjører |
Finn byggeren
Den standard Docker-driveren dreier seg om daemonen. Andre Buildx-drivere kan bruke en dedikert BuildKit-container, Kubernetes eller en ekstern tjeneste. Konfigurer den valgte driverens støttede proxymekanisme der den workeren kjører.
En loopback-proxy på en laptop er ikke automatisk tilgjengelig fra en ekstern worker, og det å redigere den lokale daemonen omkonfigurerer ikke den eksterne byggeren.
Et ARG før FROM kan hjelpe med å velge avbildningsreferansen. Det konfigurerer likevel ikke registerklientens nettverksrute. Senere RUN-kommandoer som skriver pakkeinnstillinger eller installerer sertifikater kan ikke reparere denne tidligere forespørselen.
Tillit, kontoer og bufrede data
Godkjent CA-materiale må være tilgjengelig for komponenten som validerer den innledende registerforbindelsen. Registerlegitimasjon og proxylegitimasjon autoriserer ulike parter; en registerinnlogging kan ikke svare på en proxy 407.
En worker som gjenbruker bufrede avbildningsdata, gjentar kanskje ikke den samme nettverksforespørselen som en fersk worker. Sammenlign den faktisk loggede operasjonen. Når tilgangen til basisavbildningen fungerer via den tiltenkte ruten, diagnostiser enhver senere nedlasting i byggetrinnet ved den neste grensen.