Docker-build kan ikke nå en privat afhængighed: tjek det her

En privat pakke, som sagtens kan slås op på din maskine, kan fejle med en 404 eller en timeout inde i buildet, og Dockerfile er sjældent årsagen. Build-trinnet kører i et andet netværksnavnerum, med et andet DNS-syn og et andet legitimationslager end det shell, du testede i. Gå disse kontroller igennem i rækkefølge, og stop ved den første, der fejler, fordi hver senere kontrol forudsætter, at den forrige gik igennem. Hvert trin navngiver den kommando, der afgør sagen.

Start med at navngive builderen, ikke Dockerfile

BuildKit kan være lokal, containeriseret eller køre på en anden maskine, og hver af dem har sit eget standardnetværk. Kør docker buildx ls og læs den node, der er markeret med en stjerne, før du ændrer noget. En docker-container driver eller en cloud-builder deler ikke den private rute på din laptop, bare fordi du skrev kommandoen der. Hvis den aktive builder er fjern, skal hver resterende kontrol køre mod den vært i stedet for din arbejdsstation.

Builderen har også sine egne resolver-indstillinger og proxy-variabler. Begge læses på build-tidspunktet og nedarves ikke fra den terminal, der startede buildet.

Bevis netværksvejen inde fra et build-trin

Skriv et engangstrin, der slår afhængighedens vært op og åbner en forbindelse til den. Det er den eneste test, der svarer på spørgsmålet for builderen i stedet for for dit shell.

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/

Byg den fil med den samme builder, netværkstilstand og de samme secret-mounts, som dit rigtige build bruger: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Hvis getent ikke udskriver noget, er fejlen navneopløsning, og ingen legitimationsoplysninger retter det. Hvis navnet opløses, men curl rapporterer en timeout, er blokeringen ruten eller egress-politikken foran registret.

Slet sonden, når den har svaret. Det er et diagnostisk trin, og det bør aldrig tagges eller pushes.

Montér legitimationsoplysningen i stedet for at kopiere den

Når ruten virker, er autentificering den næste fejl i rækken. Et BuildKit-secret-mount eksponerer en fil for et enkelt RUN trin uden at skrive den ned i et lag, hvilket er det, afhængighedsværktøjet har brug for, og det, som imaget ikke må beholde.

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

Hemmeligheden skal leveres udefra Dockerfile: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Filen bliver på klienten og kommer aldrig ind i image-historikken. En ARG eller ENV med samme token gør ikke dette arbejde, fordi begge registreres i image-konfigurationen.

Et image uden root har brug for sin egen målsti, som /home/app/.npmrc eller den tilsvarende fil til pip, Maven eller Cargo. Mount-målet skal passe til den bruger, der kører kommandoen, ellers rapporterer værktøjet en manglende konfigurationsfil, som faktisk er der.

Gennemgå, hvad afhængighedsværktøjet efterlader i imaget

Et midlertidigt mount holder legitimationsoplysningen ude af et lag, men det forhindrer ikke værktøjet i at skrive noget andet. Pakkehåndteringer efterlader lock-filer, cache-mapper og nogle gange den opløste registrerings-URL.

Læs det færdige filsystem i stedet for at stole på Dockerfile. docker history --no-trunc image:tag lister hver lagkommando, og docker run --rm image:tag sh -c "ls -a /root" viser, hvad der overlevede ind i den kørende container. Selv når filen kun blev mountet, er et token skrevet i en loglinje under npm ci stadig en lækage.

Læs også build-loggen, fordi --progress=plain udskriver kommandooutput ordret. Hvis tokenet dukker op der, skal du rotere det før alt andet og sende det gennem en fil, som værktøjet læser i stilhed.

Bekræft, at runtime-imaget ikke længere har brug for den private rute

Buildet og den kørende applikation er to forskellige forbrugere af den samme afhængighed, og kun den første har brug for den private rute. Et færdigt image bør starte, opløse sine runtime-afhængigheder og betjene trafik uden build-legitimationsoplysningen.

Test det, hvor det private register er utilgængeligt, eller start blot containeren med --network none og bekræft, at den booter uden den monterede hemmelighed. En container, der kun starter, når build-hemmeligheden er til stede, er stadig koblet til build-miljøet.

Hvis containeren virkelig har brug for registret ved runtime, er det en separat adgangsbeslutning, og den hører i orkestratorens secret store frem for i buildet. Dokumentér de to veje hver for sig, så ingen forsøger at reparere et runtime-pull med et build-flag. Når alle fem kontroller består, har det oprindelige symptom en navngivet årsag på hvert lag i stedet for et gæt om Docker-netværk.