Dockeri build ei jõua privaatse sõltuvuseni: kontrollige seda

Privaatne pakett, mis teie masinas laheneb probleemideta, võib buildi sees ebaõnnestuda 404 või ajapikendusega, ja Dockerfile on harva selle põhjus. Buildi samm töötab teises võrgu nimeruumis, teistsuguse DNS-vaatega ja teistsuguse mandaatide hoiuga kui see shell, milles te testisite. Käige need kontrollid järjest läbi ja peatuge esimesel, mis ebaõnnestub, sest iga järgnev kontroll eeldab, et eelmine läbis. Iga samm nimetab käsu, mis asja otsustab.

Alustage builderi, mitte Dockerfile’i nimetamisest

BuildKit võib olla lokaalne, konteineris või teises masinas, ja igal neist on oma vaikevõrk. Käivitage docker buildx ls ja lugege tärniga märgitud sõlme enne, kui midagi muudate. Üks docker-container draiver või pilvebuilder ei jaga teie sülearvuti privaatset marsruuti ainult seetõttu, et te käsu sinna tipitasite. Kui aktiivne builder on kaugel, peab iga ülejäänud kontroll jooksma selle hosti vastu, mitte teie tööjaama vastu.

Builderil on ka oma resolveri seadistus ja puhverserveri muutujad. Mõlemat loetakse buildi ajal ja neid ei pärita terminalist, mis buildi käivitas.

Tõestage võrgutee buildi sammu sees

Kirjutage ühekordne etapp, mis lahendab sõltuvuse hosti ja avab sellega ühenduse. See on ainus test, mis vastab küsimusele builderi, mitte teie shelli jaoks.

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/

Buildige see fail sama builderi, võrgurežiimi ja samade secret-mountidega, mida teie tegelik build kasutab: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Kui getent ei trüki midagi, on viga nimelahenduses ja ükski mandaat ei paranda seda. Kui nimi laheneb, aga curl teatab ajapikendusest, on takistuseks marsruut või registri ees olev väljundpoliitika.

Kustutage sond, kui see on vastanud. See on diagnostiline etapp ja seda ei tohiks kunagi märgistada ega pushida.

Monteerige mandaat selle asemel, et seda kopeerida

Kui tee töötab, on autentimine järgmine ebaõnnestumine järjekorras. BuildKiTi secret-mount avab faili ühele RUN sammule ilma seda kihina kirjutamata, mida sõltuvustööriist vajab ja mida image ei tohi alles hoida.

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

Secret tuleb tarnida väljastpoolt Dockerfile’i: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Fail jääb kliendi juurde ega jõua kunagi image’i ajalukku. Üks ARG või ENV sama tokeniga ei tee seda tööd, sest mõlemad salvestatakse image’i konfiguratsiooni.

Root-õiguseta image vajab oma sihtteed, näiteks /home/app/.npmrc või vastavat faili pipi, Maveni või Cargo jaoks. Mounti siht peab vastama kasutajale, kes käsu käivitab, muidu teatab tööriist puuduvast konfiguratsioonifailist, mis tegelikult on olemas.

Kontrollige, mida sõltuvustööriist image’isse jätab

Ajutine mount hoiab mandaadi kihist väljas, kuid ei takista tööriista millegi muu kirjutamist. Paketihaldurid jätavad maha lock-failid, vahemälu kataloogid ja mõnikord lahendatud registri URL-i.

Lugege valmis failisüsteemi, selle asemel et Dockerfile’i usaldada. docker history --no-trunc image:tag loetleb iga kihi käsu ja docker run --rm image:tag sh -c "ls -a /root" näitab, mis jõudis töötavasse konteinerisse. Isegi kui fail oli ainult monteeritud, jääb logireale kirjutatud token npm ci ajal siiski lekkimiseks.

Lugege ka build-logi, sest --progress=plain trükib käskude väljundi sõna-sõnalt. Kui token seal ilmub, pöörake see enne kõike muud ja edastage faili kaudu, mida tööriist vaikselt loeb.

Veenduge, et käitusaegne image ei vaja enam privaatset teed

Build ja töötav rakendus on sama sõltuvuse kaks erinevat tarbijat ja ainult esimene vajab privaatset marsruuti. Valmis image peaks käivituma, oma käitusaegsed sõltuvused lahendama ja liiklust teenindama ilma buildi mandaadita.

Testige seda seal, kus privaatne register pole kättesaadav, või käivitage konteiner lihtsalt --network none ja kinnitage, et see bootib ilma monteeritud secretita. Konteiner, mis käivitub ainult siis, kui build-secret on olemas, on endiselt build-keskkonnaga seotud.

Kui konteiner vajab registrit tõesti käitusajal, on see eraldi juurdepääsuotsus ja see kuulub orkestraatori secret-hoidlasse, mitte buildi. Dokumenteerige kaks teed eraldi, et keegi ei üritaks käitusaegset pulli build-lipuga parandada. Kui kõik viis kontrolli läbivad, on algsel sümptomil igal kihil nimetatud põhjus, mitte oletus Dockeri võrgu kohta.