Build Dockeru nedosiahne na súkromnú závislosť: skontrolujte to

Súkromný balíček, ktorý sa na vašom stroji vyrieši bez problémov, môže vnútri buildu zlyhať s chybou 404 alebo s časovým limitom, a Dockerfile je len zriedka príčinou. Krok buildu beží v inom sieťovom mennom priestore, s iným pohľadom na DNS a iným úložiskom prihlasovacích údajov než shell, v ktorom ste testovali. Prejdite tieto kontroly po poradí a zastavte sa pri prvej, ktorá zlyhá, pretože každá ďalšia predpokladá, že predchádzajúca prešla. Každý krok pomenúva príkaz, ktorý to rozhodne.

Začnite pomenovaním buildera, nie Dockerfile

BuildKit môže byť lokálny, v kontajneri alebo na inom stroji a každý z nich má vlastnú predvolenú sieť. Spustite docker buildx ls a prečítajte si uzol označený hviezdičkou, skôr než čokoľvek zmeníte. Jeden docker-container ovládač alebo cloudový builder nezdieľa súkromnú trasu na vašom notebooku len preto, že ste tam príkaz napísali. Ak je aktívny builder vzdialený, každá zostávajúca kontrola musí bežať proti tomu hostiteľovi, nie proti vašej pracovnej stanici.

Builder si nesie aj vlastnú konfiguráciu resolvera a premenné proxy. Oboje sa číta v čase buildu a nededí sa z terminálu, ktorý build spustil.

Dokážte sieťovú cestu zvnútra kroku buildu

Napíšte jednorazovú fázu, ktorá preloží hostiteľa závislosti a otvorí k nemu spojenie. Je to jediný test, ktorý odpovedá na otázku za builder, nie za váš 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/

Zostavte tento súbor tým istým builderom, sieťovým režimom a tými istými pripojeniami tajomstiev, aké používa váš skutočný build: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Ak getent nič nevypíše, ide o chybu prekladu mien a žiadne prihlasovacie údaje to nespravia. Ak sa meno preloží, ale curl hlási časový limit, prekážkou je trasa alebo výstupná politika pred registrom.

Sondu zmažte, hneď ako odpovie. Je to diagnostická fáza a nemala by sa nikdy označovať ani odosielať.

Prihlasovacie údaje pripájajte, nekopírujte

Keď trasa funguje, ďalšia v poradí je autentifikácia. Pripojenie tajomstva v BuildKite sprístupní súbor jednému RUN kroku bez toho, aby ho zapísalo do vrstvy, čo je to, čo nástroj pre závislosti potrebuje a čo si image nesmie ponechať.

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

Tajomstvo sa musí dodať zvonka Dockerfile: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Súbor zostáva u klienta a nikdy nevstúpi do histórie image. Ani ARG ani ENV s tým istým tokenom túto prácu nerobia, pretože oba sa zaznamenávajú do konfigurácie image.

Image bez rootu potrebuje vlastnú cieľovú cestu, napríklad /home/app/.npmrc alebo zodpovedajúci súbor pre pip, Maven alebo Cargo. Cieľ pripojenia musí zodpovedať používateľovi, ktorý príkaz spúšťa, inak nástroj ohlási chýbajúci konfiguračný súbor, ktorý v skutočnosti existuje.

Preverte, čo nástroj pre závislosti v image zanecháva

Dočasné pripojenie drží prihlasovacie údaje mimo vrstvy, ale nebráni nástroju zapísať niečo iné. Správcovia balíčkov zanechávajú lock súbory, adresáre cache a niekedy aj vyriešenú adresu registra.

Čítajte hotový súborový systém, namiesto toho, aby ste verili Dockerfile. docker history --no-trunc image:tag vypisuje každý príkaz vrstvy a docker run --rm image:tag sh -c "ls -a /root" ukazuje, čo prežilo do bežiaceho kontajnera. Aj keď bol súbor len pripojený, token zapísaný do riadku logu počas npm ci je stále únik.

Prečítajte si aj build log, pretože --progress=plain tlačí výstup príkazov doslovne. Ak sa token objaví tam, vymeňte ho skôr než čokoľvek iné a odovzdávajte ho cez súbor, ktorý nástroj číta potichu.

Overte, že runtime image už súkromnú trasu nepotrebuje

Build a bežiaca aplikácia sú dvaja rôzni spotrebitelia tej istej závislosti a súkromnú trasu potrebuje len prvý. Hotový image by mal naštartovať, vyriešiť svoje runtime závislosti a obsluhovať prevádzku bez prihlasovacích údajov z buildu.

Otestujte to tam, kde je súkromný register nedostupný, alebo jednoducho spustite kontajner s --network none a potvrďte, že nabehne bez pripojeného tajomstva. Kontajner, ktorý štartuje len vtedy, keď je prítomné build tajomstvo, je stále zviazaný s build prostredím.

Ak kontajner register pri behu naozaj potrebuje, je to samostatné rozhodnutie o prístupe a patrí do úložiska tajomstiev orchestrátora, nie do buildu. Zdokumentujte obe cesty oddelene, aby sa nikto nepokúšal opraviť runtime pull buildovým príznakom. Keď všetkých päť kontrol prejde, pôvodný symptóm má na každej vrstve pomenovanú príčinu namiesto dohadu o sieti Dockeru.