Hentning af Docker-basisimages: builder-proxy kontra build-argumenter
Proxyargumenter, der gives til build-trin, konfigurerer ikke enhver registreringsanmodning, som builderen foretager. Find den builder, der opløser basisimaget.
Et build kan fejle under opløsning af FROM, før noget Dockerfile-pakkedownload-trin kører. Builderens registreringsklient har brug for sin egen rute til at hente dette basisimage.
| Handling | Komponent, der har brug for ruten |
|---|---|
| Opløs og hent basisimaget | Builderens registreringsklient |
| Download under RUN | Processen, der udfører build-trinnet |
| Kald en API ved kørsel | Den kørende applikation |
Find builderen
Den standard Docker-driver centrerer omkring daemonen. Andre Buildx-drivere kan bruge en dedikeret BuildKit-container, Kubernetes eller en ekstern tjeneste. Konfigurer den valgte drivers understøttede proxymekanisme der, hvor den worker kører.
En loopback-proxy på en bærbar computer er ikke automatisk tilgængelig fra en ekstern worker, og redigering af den lokale daemon omkonfigurerer ikke den eksterne builder.
Et ARG før FROM kan hjælpe med at vælge imagereferencen. Det konfigurerer dog ikke dermed registreringsklientens netværksrute. Senere RUN-kommandoer, der skriver pakkeindstillinger eller installerer certifikater, kan ikke reparere denne tidligere anmodning.
Tillid, konti og cachede data
Godkendt CA-materiale skal være tilgængeligt for den komponent, der validerer den indledende registreringsforbindelse. Registreringsoplysninger og proxyoplysninger autoriserer forskellige parter; et registreringslogin kan ikke besvare en proxy 407.
En worker, der genbruger cachede imagedata, gentager måske ikke den samme netværksanmodning som en ny worker. Sammenlign den faktisk loggede handling. Når adgangen til basisimaget virker gennem den tilsigtede rute, diagnosticer enhver senere download i build-trinnet ved den næste grænse.