Henting av Docker-basisbilder: byggerproxy versus byggeargumenter
Proxyargumenter som gis til byggetrinn, konfigurerer ikke hver registerforespørsel som byggeren gjør. Finn byggeren som løser basisbildet.
En bygging kan mislykkes under oppslaget av FROM før noe Dockerfile-pakkedownload-trinn kjører. Byggerens registerklient trenger sin egen rute for å hente det basisbildet.
| Operasjon | Komponent som trenger ruten |
|---|---|
| Løs opp og hent basisbildet | 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 bilreferansen. 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 bildedata, gjentar kanskje ikke den samme nettverksforespørselen som en ny worker. Sammenlign den faktisk loggede operasjonen. Når tilgangen til basisbildet fungerer via den tiltenkte ruten, diagnostiser enhver senere nedlasting i byggetrinnet ved den neste grensen.