Docker-build bereikt een privéafhankelijkheid niet: controleer dit

Een privépakket dat op uw machine zonder problemen wordt opgelost, kan binnen de build mislukken met een 404 of een time-out, en de Dockerfile is zelden de oorzaak. De buildstap draait in een andere netwerknaamruimte, met een ander DNS-beeld en een ander opslagplaats voor inloggegevens dan de shell waarin u testte. Loop deze controles in volgorde door en stop bij de eerste die mislukt, want elke latere controle gaat ervan uit dat de vorige slaagde. Elke stap noemt het commando dat de knoop doorhakt.

Begin met de builder te benoemen, niet de Dockerfile

BuildKit kan lokaal, in een container of op een andere machine draaien, en elk daarvan heeft zijn eigen standaardnetwerk. Voer docker buildx ls uit en lees het knooppunt met het sterretje voordat u iets wijzigt. Een docker-container driver of een cloudbuilder deelt de privéroute op uw laptop niet alleen omdat u het commando daar hebt getypt. Als de actieve builder op afstand staat, moet elke resterende controle tegen die host lopen en niet tegen uw werkplek.

De builder draagt ook zijn eigen resolverconfiguratie en proxyvariabelen. Beide worden tijdens de build gelezen en worden niet geërfd van de terminal die de build startte.

Bewijs het netwerkpad van binnenuit een buildstap

Schrijf een wegwerpstadium dat de host van de afhankelijkheid oplost en er een verbinding mee opent. Dit is de enige test die de vraag voor de builder beantwoordt en niet voor uw 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/

Bouw dat bestand met dezelfde builder, netwerkmodus en dezelfde secret-koppelingen als uw echte build gebruikt: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Als getent niets afdrukt, zit de fout in naamresolutie en geen enkele inloggegevenslossing verhelpt dat. Als de naam wel wordt opgelost maar curl een time-out meldt, is de route of het egress-beleid voor het register de blokkade.

Verwijder de probe zodra die antwoordt. Het is een diagnostisch stadium en het mag nooit getagd of gepusht worden.

Koppel de inloggegevens in plaats van ze te kopiëren

Als het pad werkt, is authenticatie de volgende fout in de rij. Een BuildKit-secretkoppeling stelt een bestand beschikbaar aan één RUN stap zonder het in een laag te schrijven, en dat is wat de afhankelijkheidstool nodig heeft en wat de image niet mag bewaren.

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

Het geheim moet van buiten de Dockerfile komen: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Het bestand blijft bij de client en komt nooit in de imagegeschiedenis. Een ARG of ENV met hetzelfde token doen dit werk niet, omdat beide in de imageconfiguratie worden vastgelegd.

Een image zonder root heeft een eigen doelpad nodig, bijvoorbeeld /home/app/.npmrc of het equivalente bestand voor pip, Maven of Cargo. Het koppeldoel moet overeenkomen met de gebruiker die het commando uitvoert, anders meldt de tool een ontbrekend configuratiebestand dat er in werkelijkheid is.

Controleer wat de afhankelijkheidstool in de image achterlaat

Een tijdelijke koppeling houdt de inloggegevens buiten een laag, maar weerhoudt de tool er niet van iets anders te schrijven. Pakketbeheerders laten lockbestanden, cachemappen en soms de opgeloste register-URL achter.

Lees het voltooide bestandssysteem in plaats van de Dockerfile te vertrouwen. docker history --no-trunc image:tag somt elk laagcommando op, en docker run --rm image:tag sh -c "ls -a /root" laat zien wat het draaiende container heeft overleefd. Zelfs als het bestand alleen gekoppeld was, blijft een token dat tijdens npm ci in een logregel wordt geschreven, een lek.

Lees ook de buildlog, want --progress=plain drukt de uitvoer van commando’s woordelijk af. Als het token daar opduikt, roteer het dan voor al het andere en geef het door via een bestand dat de tool stil leest.

Controleer dat de runtime-image de privéroute niet meer nodig heeft

De build en de draaiende applicatie zijn twee verschillende gebruikers van dezelfde afhankelijkheid, en alleen de eerste heeft de privéroute nodig. Een voltooide image zou moeten starten, zijn runtime-afhankelijkheden oplossen en verkeer bedienen zonder de build-inloggegevens.

Test het waar het privéregister onbereikbaar is, of start de container gewoon met --network none en bevestig dat hij opstart zonder het gekoppelde geheim. Een container die alleen start als het build-geheim aanwezig is, blijft aan de buildomgeving gekoppeld.

Als de container het register echt tijdens runtime nodig heeft, is dat een aparte toegangsbeslissing, en die hoort in de secret store van de orchestrator en niet in de build. Documenteer de twee paden apart, zodat niemand een runtime-pull met een build-flag probeert te repareren. Als alle vijf controles slagen, heeft het oorspronkelijke symptoom op elke laag een benoemde oorzaak in plaats van een gok over Docker-netwerken.