Docker-build berikt gjin privee-ôfhinklikheid: kontrolearje dit

In privee-pakket dat op jo masine sûnder problemen oplost wurdt, kin yn de build mislearje mei in 404 of in time-out, en de Dockerfile is seldsum de oarsaak. De buildstap draait yn in oare netwurknammeromte, mei in oare DNS-byld en in oare bewarplak foar oanmeldgegevens as de shell wêryn’t jo testen. Wurkje dizze kontrôles yn folchoarder troch en stop by de earste dy’t mislearret, want elke lettere kontrôle giet derfan út dat de foarige slagge is. Eltse stap neamt it kommando dat de saak beslist.

Begjin mei de builder te neamen, net de Dockerfile

BuildKit kin lokaal, yn in kontener of op in oare masine draaie, en elk hat syn eigen standertnetwurk. Fier docker buildx ls út en lês de knoop dy’t mei in stjerke markearre is foardat jo wat feroarje. In docker-container stjoerder of in wolkbuilder dielt de privee-rûte op jo laptop net allinne om’t jo it kommando dêr typt hawwe. As de aktive builder op ôfstân is, moat elke oerbleaune kontrôle tsjin dy host rinne, net tsjin jo wurkstasjon.

De builder draacht ek syn eigen resolver-konfiguraasje en proxy-fariabelen. Beide wurde by de build lêzen en wurde net urven fan it terminal dat de build starte.

Bewys it netwurkpaad fan binnen in buildstap

Skriuw in eindoelstadium dat de host fan de ôfhinklikheid oplost en in ferbining dermei iepenet. Dit is de iennige test dy’t de fraach foar de builder beantwurdet en net foar jo 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/

Bou dat bestân mei deselde builder, deselde netwurkmody en deselde secret-mounts as jo echte build brûkt: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. As getent neat printsje lit, is de flater yn nammeoplossing en gjin inkel oanmeldgegevens reparearret dat. As de namme oplost mar curl meldt in time-out, dan is de blokkade de rûte of it útgongbelied foar it register.

Smyt de probe fuort sadree’t er antwurdet. It is in diagnostyske stap en soe nea tagge of pusht wurde moatte.

Mount de oanmeldgegevens yn stee fan se te kopiearjen

As it paad wurket, is autentikaasje de folgjende flater yn de rige. In BuildKit-secret-mount biedt in bestân oan ien RUN stap oan sûnder it yn in laach te skriuwen, dat is wat it ôfhinklikheidsark nedich hat en wat de image net hâlde mei.

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

It geheim moat fan bûten de Dockerfile levere wurde: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. It bestân bliuwt by de klient en komt nea yn de image-skiednis. In ARG of ENV mei itselde token docht dit wurk net, want beide wurde yn de image-konfiguraasje fêstlein.

In image sûnder root hat in eigen doelpaad nedich, lykas /home/app/.npmrc of it ekwivalinte bestân foar pip, Maven of Cargo. It mount-doel moat oerienkomme mei de brûker dy’t it kommando draait, oars meldt it ark in ûntbrekkend konfiguraasjebestân dat der eins wol is.

Kontrolearje wat it ôfhinklikheidsark yn de image efterlit

In tydlike mount hâldt de oanmeldgegevens bûten in laach, mar it stopet it ark net om wat oars te skriuwen. Pakketbehearders litte lock-bestannen, cache-mappen en soms de oploste register-URL efter.

Lês it klearresysteem yn stee fan de Dockerfile te fertrouwen. docker history --no-trunc image:tag listet elke laachopdracht op, en docker run --rm image:tag sh -c "ls -a /root" lit sjen wat yn de draaiende kontener oerlibbe. Sels as it bestân allinnich mount wie, bliuwt in token dat by npm ci yn in logrigel skreaun wurdt, in lek.

Lês ek it build-log, want --progress=plain printet komando-útfier wurdlik. As it token dêr ferskynt, rotearje it dan foar al it oare en jow it troch in bestân dat it ark stil lêst.

Kontrolearje dat de runtime-image it privee-paad net mear nedich hat

De build en de draaiende applikaasje binne twa ferskillende brûkers fan deselde ôfhinklikheid, en allinnich de earste hat it privee-paad nedich. In klear image soe starte moatte, syn runtime-ôfhinklikheden oplosse en ferkear betsjinje sûnder de build-oanmeldgegevens.

Test it dêr’t it privee-register net berikber is, of start de kontener gewoan mei --network none en befêstigje dat er opstart sûnder it mounte geheim. In kontener dy’t allinnich start as it build-geheim oanwêzich is, is noch hieltyd oan de build-omjouwing keppele.

As de kontener it register echt by runtime nedich hat, is dat in aparte tagongsbeslissing, en dy heart yn de secret-store fan de orkestrator en net yn de build. Dokumintearje de twa paden apart, sadat nimmen in runtime-pull mei in build-flag besiket te reparearjen. As alle fiif kontrôles slagje, hat it oarspronklike symptoom op elke laach in neamd oarsaak yn stee fan in gissing oer Docker-netwurk.