Hindi naaabot ng Docker build ang pribadong dependency: suriin ito

Ang pribadong package na malinaw na nare-resolve sa iyong makina ay maaaring mabigo sa loob ng build na may 404 o timeout, at bihirang ang Dockerfile ang dahilan. Ang build step ay tumatakbo sa ibang network namespace, may ibang view ng DNS at ibang imbakan ng kredensyal kaysa sa shell kung saan ka nag-test. Dumaan sa mga pagsusuring ito nang sunod-sunod at huminto sa unang mabibigo, dahil ipinapalagay ng bawat susunod na pagsusuri na nakapasa ang nauna. Pinangalanan ng bawat hakbang ang utos na nagtatakda ng usapin.

Magsimula sa pagpangalan ng builder, hindi ng Dockerfile

Ang BuildKit ay maaaring lokal, nasa container, o nasa ibang makina, at bawat isa ay may sariling default na network. Patakbuhin ang docker buildx ls at basahin ang node na may markang asterisk bago magbago ng anuman. Isang docker-container driver o cloud builder ay hindi nagbabahagi ng pribadong ruta sa iyong laptop dahil lang tinipa mo ang utos doon. Kung ang aktibong builder ay malayo, bawat natitirang pagsusuri ay dapat patakbuhin laban sa host na iyon at hindi sa iyong workstation.

May dala rin ang builder ng sarili nitong configuration ng resolver at mga variable ng proxy. Pareho itong binabasa sa oras ng build at hindi namamana mula sa terminal na nag-umpisa ng build.

Patunayan ang ruta ng network mula sa loob ng isang build step

Sumulat ng isang beses-gamitin na yugto na nagre-resolve ng host ng dependency at nagbubukas ng koneksyon dito. Ito ang tanging test na sumasagot sa tanong para sa builder at hindi para sa iyong 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/

I-build ang file na iyon gamit ang parehong builder, network mode, at secret mounts na ginagamit ng tunay mong build: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Kung getent walang ipinapakita, ang depekto ay sa pag-resolve ng pangalan at walang kredensyal ang makakagawa nito. Kung nare-resolve ang pangalan pero nag-uulat ang curl ng timeout, ang hadlang ay ang ruta o ang patakaran sa paglabas sa harap ng registry.

Burahin ang probe sa sandaling sumagot ito. Ito ay diagnostic na yugto at hindi dapat kailanman ma-tag o ma-push.

I-mount ang kredensyal sa halip na kopyahin ito

Kapag gumana ang ruta, ang authentication ang susunod na kabiguan sa pila. Ang BuildKit secret mount ay naglalantad ng file sa isang RUN yugto lamang nang hindi ito isinusulat sa isang layer, at iyon ang kailangan ng dependency tool at iyon ang hindi dapat itago ng image.

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

Ang secret ay dapat ibigay mula sa labas ng Dockerfile: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Nananatili ang file sa client at hindi kailanman pumapasok sa kasaysayan ng image. Ang isang ARG o ENV na may parehong token ay hindi gumagawa nito, dahil pareho silang naitala sa configuration ng image.

Ang image na walang root ay nangangailangan ng sariling target na landas, halimbawa /home/app/.npmrc o ang katumbas na file para sa pip, Maven, o Cargo. Dapat tumugma ang target ng mount sa user na nagpapatakbo ng utos, kung hindi ay mag-uulat ang tool ng kulang na configuration file na talagang naroon.

Suriin kung ano ang iniiwan ng dependency tool sa image

Ang pansamantalang mount ay naglalayo ng kredensyal mula sa isang layer, ngunit hindi nito pinipigilan ang tool na magsulat ng iba pa. Ang mga package manager ay nag-iiwan ng lock file, cache directory, at kung minsan ang na-resolve na registry URL.

Basahin ang tapos na filesystem sa halip na magtiwala sa Dockerfile. docker history --no-trunc image:tag naglilista ng bawat layer command, at docker run --rm image:tag sh -c "ls -a /root" nagpapakita kung ano ang natirang buhay sa tumatakbong container. Kahit na na-mount lang ang file, ang token na nakasulat sa log line habang npm ci ay leak pa rin.

Basahin din ang build log, dahil --progress=plain inililimbag nang literal ang output ng mga utos. Kung lumitaw ang token doon, paikutin ito bago ang anupaman at ipasa sa pamamagitan ng file na tahimik na binabasa ng tool.

Tiyakin na hindi na kailangan ng runtime image ang pribadong ruta

Ang build at ang tumatakbong application ay dalawang magkaibang mamimili ng parehong dependency, at ang una lang ang nangangailangan ng pribadong ruta. Ang tapos na image ay dapat magsimula, mag-resolve ng runtime dependencies nito, at maghatid ng trapiko nang walang kredensyal mula sa build.

Subukan ito kung saan hindi maabot ang pribadong registry, o simulan lang ang container gamit ang --network none at tiyakin na nag-boot ito nang walang naka-mount na secret. Ang container na nagsisimula lamang kapag naroon ang build secret ay nakakabit pa rin sa build environment.

Kung talagang kailangan ng container ang registry sa runtime, iyon ay hiwalay na desisyon sa pag-access, at kabilang ito sa secret store ng orkestrador at hindi sa build. Idokumento ang dalawang landas nang hiwalay upang walang sinumang subukang ayusin ang runtime pull gamit ang build flag. Kapag nakapasa ang lahat ng limang pagsusuri, ang orihinal na sintomas ay may pinangalanang dahilan sa bawat layer sa halip na haka-haka tungkol sa network ng Docker.