Docker-bygget når ikkje fram til ein privat avhengnad: sjekk dette

Ein privat pakke som blir løyst utan problem på maskina di, kan feile inne i bygget med ein 404 eller eit tidsavbrot, og Dockerfile er sjeldan årsaka. Byggjestegget køyrer i eit anna nettverksnamnerom, med eit anna DNS-bilete og eit anna lager for innloggingsinformasjon enn skalet du testa i. Gå gjennom desse kontrollane i rekkjefølgje og stopp ved den første som feilar, fordi kvar seinare kontroll føreset at den førre gjekk gjennom. Kvart steg namngjev kommandoen som avgjer saka.

Start med å namngje builderen, ikkje Dockerfile

BuildKit kan vere lokalt, i ein container eller på ei anna maskin, og kvar av dei har sitt eige standardnettverk. Køyr docker buildx ls og les knutepunktet som er merkt med ei stjerne, før du endrar noko. Ein docker-container drivar eller ein skybuilder deler ikkje den private vegen på laptopen din berre fordi du skreiv kommandoen der. Viss den aktive builderen er ekstern, må kvar gjenverande kontroll køyre mot den verten og ikkje mot arbeidsstasjonen din.

Builderen ber òg sin eigen resolver-konfigurasjon og proxyvariablar. Begge blir lesne ved byggjetid og blir ikkje arva frå terminalen som starta bygget.

Prov nettverksvegen inne frå eit byggjesteg

Skriv eit eingongsteg som slår opp verten for avhengnaden og opnar ei tilkopling til han. Dette er den einaste testen som svarar på spørsmålet for builderen og ikkje for skalet ditt.

FROM alpine:3.20
RUN apk add --no-cache curl bind-tools  && getent hosts registry.example.internal  && curl -sS -o /dev/null -w "%{http_code}
" https://registry.example.internal/simple/

Bygg den fila med same builder, nettverksmodus og dei same secret-monteringane som det verkelege bygget ditt brukar: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Viss getent ikkje skriv ut noko, ligg feilen i namneoppslaget og ingen innloggingsinformasjon rettar det. Viss namnet blir løyst, men curl rapporterer tidsavbrot, er hindringa vegen eller egress-policyen framfor registeret.

Slett sonden så snart han svarar. Det er eit diagnostisk steg og bør aldri taggast eller pushast.

Monter innloggingsinformasjonen i staden for å kopiere han

Når vegen verkar, er autentisering den neste feilen i rekkja. Ei BuildKit secret-montering eksponerer ei fil for eitt RUN steg utan å skrive ho til eit lag, og det er det avhengnadsverktøyet treng og det image ikkje må halde på.

RUN --mount=type=secret,id=npmrc,target=/root/.npmrc     npm ci --omit=dev

Hemmelegheita må leverast frå utsida av Dockerfile: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Fila blir verande hjå klienten og kjem aldri inn i image-historia. Ein ARG eller ENV med same token gjer ikkje denne jobben, fordi begge blir registrerte i image-konfigurasjonen.

Eit image utan root treng sin eigen målveg, til dømes /home/app/.npmrc eller den tilsvarande fila for pip, Maven eller Cargo. Monteringsmålet må samsvare med brukaren som køyrer kommandoen, elles rapporterer verktøyet ei manglande konfigurasjonsfil som faktisk er der.

Gå gjennom kva avhengnadsverktøyet legg att i image

Ei mellombels montering held innloggingsinformasjonen utanfor eit lag, men ho hindrar ikkje verktøyet i å skrive noko anna. Pakkehandsamarar legg att lock-filer, cache-katalogar og stundom den oppløyste register-URL-en.

Les det ferdige filsystemet i staden for å stole på Dockerfile. docker history --no-trunc image:tag listar kvar lagkommando, og docker run --rm image:tag sh -c "ls -a /root" viser kva som overlevde inn i den køyrande containeren. Sjølv når fila berre vart montert, er eit token skrive i ei loggline under npm ci framleis ein lekkasje.

Les òg byggjeloggen, fordi --progress=plain skriv ut utdata frå kommandoane ordrett. Viss tokenet dukkar opp der, roter det før alt anna og send det gjennom ei fil som verktøyet les stille.

Stadfest at runtime-imaget ikkje lenger treng den private vegen

Bygget og applikasjonen som køyrer er to ulike brukarar av same avhengnad, og berre den første treng den private vegen. Eit ferdig image bør starte, løysa runtime-avhengnadene sine og betene trafikk utan byggje-innloggingsinformasjonen.

Test det der det private registeret ikkje er tilgjengeleg, eller start containeren ganske enkelt med --network none og stadfest at han startar utan den monterte hemmelegheita. Ein container som berre startar når byggjehemmelegheita er til stades, er framleis knytt til byggjemiljøet.

Viss containeren verkeleg treng registeret ved runtime, er det ei eiga tilgangsavgjerd, og ho høyrer heime i secret store hjå orkestratoren og ikkje i bygget. Dokumenter dei to vegane kvar for seg, slik at ingen prøver å reparere ein runtime-pull med eit byggjeflagg. Når alle fem kontrollane går gjennom, har det opphavlege symptomet ei namngjeven årsak på kvart lag i staden for ei gissing om Docker-nettverk.