Build-i i Docker nuk arrin te një varësi private: kontrollojeni këtë

Një paketë private që në makinën tuaj zgjidhet pa probleme mund të dështojë brenda build-it me 404 ose me skadim kohe, dhe Dockerfile është rrallë shkaku. Hapi i build-it ekzekutohet në një hapësirë tjetër emrash rrjeti, me një pamje tjetër të DNS-së dhe një depo tjetër kredencialesh sesa shell-i ku testuat. Kaloji këto kontrolle sipas radhës dhe ndalu tek i pari që dështon, sepse çdo kontroll pasues supozon se i mëparshmi kaloi. Çdo hap emërton komandën që e zgjidh çështjen.

Filloni duke emërtuar build-erin, jo Dockerfile

BuildKit mund të jetë lokal, në një kontejner ose në një makinë tjetër, dhe secili ka rrjetin e vet të parazgjedhur. Ekzekutoni docker buildx ls dhe lexoni nyjen e shënuar me yll përpara se të ndryshoni diçka. Një docker-container drejtues ose një build-er në re nuk e ndan rrugën private në laptopin tuaj vetëm sepse e shkruat komandën atje. Nëse build-eri aktiv është i largët, çdo kontroll i mbetur duhet të ekzekutohet ndaj atij hosti dhe jo ndaj stacionit tuaj të punës.

Build-eri mbart edhe konfigurimin e resolver-it dhe variablat proxytë vetat. Të dyja lexohen në kohën e build-it dhe nuk trashëgohen nga terminali që e nisi build-in.

Provoni rrugën e rrjetit nga brenda një hapi build-i

Shkruani një fazë njëpërdorimëshe që zgjidh hostin e varësisë dhe hap një lidhje me të. Ky është testi i vetëm që i përgjigjet pyetjes për build-erin dhe jo për shell-in tuaj.

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/

Ndërtoni atë skedar me të njëjtin build-er, modalitet rrjeti dhe të njëjtat montime sekretesh që përdor build-i juaj i vërtetë: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Nëse getent nuk shtyp asgjë, defekti është në zgjidhjen e emrave dhe asnjë kredencial nuk e rregullon. Nëse emri zgjidhet por curl raporton skadim kohe, pengesa është rruga ose politika e daljes përpara regjistrit.

Fshijeni sondën sapo të përgjigjet. Është një fazë diagnostike dhe nuk duhet etiketuar ose shtyrë kurrë.

Monto kredencialin në vend që ta kopjosh

Kur rruga funksionon, vërtetimi është dështimi tjetër në radhë. Një montim sekreti i BuildKit ekspozon një skedar ndaj një RUN hapi të vetëm pa e shkruar në një shtresë, dhe kjo është ajo që i duhet mjetit të varësive dhe ajo që imazhi nuk duhet ta mbajë.

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

Sekreti duhet të furnizohet nga jashtë Dockerfile: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Skedari mbetet te klienti dhe nuk hyn kurrë në historikun e imazhit. As ARG as ENV me të njëjtin token nuk e bëjnë këtë punë, sepse të dy regjistrohen në konfigurimin e imazhit.

Një imazh pa root ka nevojë për rrugën e vet të destinacionit, për shembull /home/app/.npmrc ose skedarin ekuivalent për pip, Maven ose Cargo. Destinacioni i montimit duhet të përputhet me përdoruesin që ekzekuton komandën, përndryshe mjeti do të raportojë një skedar konfigurimi që mungon, ndërsa në fakt është aty.

Auditoni çfarë lë mjeti i varësive në imazh

Një montim i përkohshëm e mban kredencialin jashtë një shtrese, por nuk e pengon mjetin të shkruajë diçka tjetër. Menaxherët e paketave lënë skedarë lock, drejtori cache dhe ndonjëherë URL-në e regjistrit të zgjidhur.

Lexoni sistemin e skedarëve të përfunduar në vend që t’i besoni Dockerfile. docker history --no-trunc image:tag rendit çdo komandë shtrese, dhe docker run --rm image:tag sh -c "ls -a /root" tregon çfarë mbijetoi në kontejnerin që po ekzekutohet. Edhe kur skedari u montua vetëm, një token i shkruar në një rresht log gjatë npm ci mbetet një rrjedhje.

Lexoni edhe log-un e build-it, sepse --progress=plain shtyp daljen e komandave fjalë për fjalë. Nëse token-i shfaqet atje, rrotullojeni para çdo gjëje tjetër dhe kalojeni përmes një skedari që mjeti e lexon në heshtje.

Verifikoni që imazhi i ekzekutimit nuk ka më nevojë për rrugën private

Build-i dhe aplikacioni që ekzekutohet janë dy konsumatorë të ndryshëm të së njëjtës varësi, dhe vetëm i pari ka nevojë për rrugën private. Një imazh i përfunduar duhet të nisë, të zgjidhë varësitë e ekzekutimit dhe të shërbejë trafik pa kredencialin e build-it.

Provojeni aty ku regjistri privat është i paarritshëm, ose thjesht nisni kontejnerin me --network none dhe konfirmoni se niset pa sekretin e montuar. Një kontejner që niset vetëm kur sekreti i build-it është i pranishëm është ende i lidhur me mjedisin e build-it.

Nëse kontejneri vërtet ka nevojë për regjistrin në kohën e ekzekutimit, ky është një vendim i veçantë aksesi dhe i takon depove të sekreteve të orkestruesit, jo build-it. Dokumentoni dy rrugët veçmas, që askush të mos provojë të rregullojë një pull ekzekutimi me një flamur build-i. Kur të përfundojnë të pesë kontrollet, simptomi origjinal ka një shkak të emërtuar në çdo shtresë, në vend të një hamendjeje për rrjetin e Docker.