Docker build ne stiže do privatne ovisnosti: provjerite ovo

Privatni paket koji se na vašem računalu rješava bez problema može pasti unutar builda s greškom 404 ili timeoutom, a Dockerfile je rijetko razlog. Korak builda radi u drugom mrežnom prostoru imena, s drugačijim pogledom na DNS i drugim skladištem vjerodajnica od ljuske u kojoj ste testirali. Prođite ove provjere redom i zaustavite se na prvoj koja padne, jer svaka kasnija pretpostavlja da je prethodna prošla. Svaki korak imenuje naredbu koja rješava pitanje.

Počnite imenovanjem buildera, a ne Dockerfilea

BuildKit može biti lokalan, u kontejneru ili na drugom računalu, i svaki od njih ima svoju zadanu mrežu. Pokrenite docker buildx ls i pročitajte čvor označen zvjezdicom prije nego što bilo što promijenite. Jedan docker-container drajver ili cloud builder ne dijeli privatnu rutu na vašem prijenosniku samo zato što ste naredbu otipkali tamo. Ako je aktivni builder udaljen, svaka preostala provjera mora se izvršiti na tom hostu, a ne na vašoj radnoj stanici.

Builder nosi i svoju konfiguraciju resolvera i proxy varijable. Oboje se čita u vrijeme builda i ne nasljeđuje se od terminala koji je build pokrenuo.

Dokažite mrežnu putanju iz unutrašnjosti koraka builda

Napišite privremenu fazu koja razrješava host ovisnosti i otvara vezu prema njemu. To je jedini test koji odgovara na pitanje za builder, a ne za vašu ljusku.

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/

Izgradite tu datoteku istim builderom, mrežnim načinom i montažama tajni koje koristi vaš pravi build: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Ako getent ništa ne ispiše, kvar je u razrješavanju imena i nikakve vjerodajnice ga neće popraviti. Ako se ime razriješi ali curl prijavi timeout, prepreka je ruta ili izlazna politika ispred registra.

Obrišite sondu čim odgovori. To je dijagnostička faza i ne treba je nikada označavati ni potiskivati.

Montirajte vjerodajnicu umjesto da je kopirate

Kad putanja proradi, autentifikacija je sljedeći kvar u redu. BuildKit montaža tajne izlaže datoteku jednom RUN koraku bez upisivanja u sloj, što je ono što alat za ovisnosti treba i što slika ne smije zadržati.

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

Tajna se mora dostaviti izvan Dockerfilea: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Datoteka ostaje na klijentu i nikada ne ulazi u povijest slike. Jedan ARG ili ENV s istim tokenom ne obavlja taj posao, jer se oboje bilježi u konfiguraciji slike.

Slika bez roota treba vlastitu ciljnu putanju, na primjer /home/app/.npmrc ili odgovarajuću datoteku za pip, Maven ili Cargo. Cilj montaže mora odgovarati korisniku koji izvršava naredbu, inače će alat prijaviti nedostajuću konfiguracijsku datoteku koja zapravo postoji.

Provjerite što alat za ovisnosti ostavlja u slici

Privremena montaža drži vjerodajnicu izvan sloja, ali ne sprječava alat da upiše nešto drugo. Upravitelji paketa ostavljaju lock datoteke, keš direktorije i ponekad razriješenu URL adresu registra.

Čitajte gotov datotečni sustav umjesto da vjerujete Dockerfileu. docker history --no-trunc image:tag navodi svaku naredbu sloja, a docker run --rm image:tag sh -c "ls -a /root" pokazuje što je preživjelo u pokrenutom kontejneru. Čak i kada je datoteka samo montirana, token upisan u liniju loga tijekom npm ci izvršavanja i dalje je curenje.

Pročitajte i build log, jer --progress=plain ispisuje izlaz naredbi doslovno. Ako se token tamo pojavi, rotirajte ga prije svega drugog i prosljeđujte ga kroz datoteku koju alat čita tiho.

Provjerite da runtime slici više nije potrebna privatna putanja

Build i aplikacija koja radi dva su različita potrošača iste ovisnosti, i samo prvom je potrebna privatna ruta. Gotova slika treba se pokrenuti, razriješiti svoje runtime ovisnosti i služiti promet bez vjerodajnice iz builda.

Testirajte to tamo gdje je privatni registar nedostupan, ili jednostavno pokrenite kontejner s --network none i potvrdite da se diže bez montirane tajne. Kontejner koji se pokreće samo kad je build tajna prisutna i dalje je vezan za build okruženje.

Ako kontejneru registar zaista treba u runtimeu, to je odvojena odluka o pristupu i pripada u secret store orkestratora, a ne u build. Dokumentirajte dvije putanje odvojeno da nitko ne pokuša popraviti runtime pull build flagom. Kada svih pet provjera prođe, izvorni simptom ima imenovan uzrok na svakom sloju umjesto nagađanja o Docker mreži.