Docker-build ne atingas privatan dependecon: kontrolu ĉi tion

Privata pako, kiu solviĝas senprobleme sur via maŝino, povas malsukcesi ene de la build per 404 aŭ per tempolimo, kaj la Dockerfile malofte estas la kaŭzo. La build-paŝo ruliĝas en alia reta nomspaco, kun alia DNS-rigardo kaj alia konservujo de akreditaĵoj ol la ŝelo, en kiu vi testis. Trairu ĉi tiujn kontrolojn laŭorde kaj haltu ĉe la unua, kiu malsukcesas, ĉar ĉiu posta kontrolo supozas, ke la antaŭa sukcesis. Ĉiu paŝo nomas la komandon, kiu decidas la aferon.

Komencu per nomado de la konstruilo, ne de la Dockerfile

BuildKit povas esti loka, en ujo aŭ sur alia maŝino, kaj ĉiu el ili havas sian propran defaŭltan reton. Rulu docker buildx ls kaj legu la nodon markitan per steleto antaŭ ol ŝanĝi ion ajn. Unu docker-container pelilo aŭ nuba konstruilo ne dividas la privatan itineron sur via tekkomputilo nur ĉar vi tajpis la komandon tie. Se la aktiva konstruilo estas fora, ĉiu cetera kontrolo devas ruliĝi kontraŭ tiu gastiganto anstataŭ via laboretacio.

La konstruilo ankaŭ portas sian propran agordon de la solvilo kaj proprajn prokseajn variablojn. Ambaŭ estas legataj je build-tempo kaj ne estas heredataj de la terminalo, kiu lanĉis la build.

Pruvu la retan itineron el interne de build-paŝo

Skribu unuuzan etapon, kiu solvas la gastiganton de la dependeco kaj malfermas konekton al ĝi. Ĝi estas la sola testo, kiu respondas la demandon por la konstruilo anstataŭ por via ŝelo.

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/

Konstruu tiun dosieron per la sama konstruilo, reta reĝimo kaj sekretaj muntaĵoj, kiujn uzas via reala build: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Se getent presas nenion, la fuŝo estas nom-solvado kaj neniuj akreditaĵoj riparos ĝin. Se la nomo solviĝas sed curl raportas tempolimon, la baro estas la itinero aŭ la elira politiko antaŭ la registrejo.

Forigu la sondilon, kiam ĝi respondis. Ĝi estas diagnoza etapo kaj neniam estu etikedata aŭ puŝata.

Muntu la akreditaĵon anstataŭ kopii ĝin

Kiam la itinero funkcias, aŭtentikigo estas la sekva fuŝo en la vico. Sekreta muntaĵo de BuildKit montras dosieron al unu RUN paŝo sen skribi ĝin en tavolon, kion la dependeca ilo bezonas kaj kion la bildo ne rajtas konservi.

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

La sekreto devas esti liverita de ekster la Dockerfile: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. La dosiero restas ĉe la kliento kaj neniam eniras la bildan historion. Unu ARG aŭ ENV kun la sama ĵetono ne faras ĉi tiun laboron, ĉar ambaŭ registriĝas en la bilda agordo.

Bildo sen root bezonas sian propran celvojon, ekzemple /home/app/.npmrc aŭ la ekvivalentan dosieron por pip, Maven aŭ Cargo. La munta celo devas kongrui kun la uzanto, kiu rulas la komandon, alie la ilo raportos mankantan agordan dosieron, kiu fakte ĉeestas.

Kontrolu, kion la dependeca ilo lasas en la bildo

Provizora muntaĵo tenas la akreditaĵon ekster tavolo, sed ĝi ne malhelpas la ilon skribi ion alian. Pakaĵmastrumiloj lasas ŝlosildosierojn, kaŝmemorajn dosierujojn kaj foje la solvitan registrejan URL-on.

Legu la finitan dosiersistemon anstataŭ fidi la Dockerfile. docker history --no-trunc image:tag listigas ĉiun tavolan komandon, kaj docker run --rm image:tag sh -c "ls -a /root" montras, kio postvivis en la ruliĝantan ujon. Eĉ kiam la dosiero nur estis muntita, ĵetono skribita en protokolan linion dum npm ci restas liko.

Legu ankaŭ la build-protokolon, ĉar --progress=plain presas la eligon de komandoj laŭvorte. Se la ĵetono aperas tie, rotaciu ĝin antaŭ ĉio alia kaj pasigu ĝin tra dosiero, kiun la ilo legas silente.

Kontrolu, ke la rultempa bildo jam ne bezonas la privatan itineron

La build kaj la ruliĝanta aplikaĵo estas du malsamaj konsumantoj de la sama dependeco, kaj nur la unua bezonas la privatan itineron. Finita bildo devas starti, solvi siajn rultempajn dependecojn kaj servi trafikon sen la build-akreditaĵo.

Testu ĝin tie, kie la privata registrejo neatingeblas, aŭ simple startigu la ujon per --network none kaj konfirmu, ke ĝi ekfunkcias sen la muntita sekreto. Ujo, kiu startas nur kiam la build-sekreto ĉeestas, ankoraŭ estas kunligita al la build-medio.

Se la ujo vere bezonas la registrejon rultempe, tio estas aparta alirdecido, kaj ĝi apartenas al la sekreta konservujo de la orkestrilo, ne al la build. Dokumentu la du vojojn aparte, por ke neniu provu ripari rultempan elŝuton per build-flago. Kiam ĉiuj kvin kontroloj pasas, la origina simptomo havas nomitan kaŭzon ĉe ĉiu tavolo anstataŭ konjekton pri la reto de Docker.