Build Dockeru nedosáhne na privátní závislost: zkontrolujte to

Privátní balíček, který se na vašem stroji bez potíží vyřeší, může uvnitř buildu selhat s chybou 404 nebo timeoutem, a Dockerfile je málokdy příčinou. Krok buildu běží v jiném síťovém jmenném prostoru, s jiným pohledem na DNS a jiným úložištěm přihlašovacích údajů než shell, ve kterém jste testovali. Projděte tyto kontroly popořadě a zastavte se u první, která selže, protože každá další předpokládá, že předchozí prošla. Každý krok pojmenovává příkaz, který to rozhodne.

Začněte pojmenováním builderu, ne Dockerfile

BuildKit může být lokální, v kontejneru nebo na jiném stroji a každý z nich má svou výchozí síť. Spusťte docker buildx ls a přečtěte si uzel označený hvězdičkou, než cokoli změníte. Jeden docker-container ovladač nebo cloudový builder nesdílí privátní trasu na vašem notebooku jen proto, že jste tam příkaz napsali. Pokud je aktivní builder vzdálený, musí každá zbývající kontrola běžet proti tomu hostiteli, ne proti vaší pracovní stanici.

Builder si také nese vlastní konfiguraci resolveru a proměnné proxy. Obojí se čte v době buildu a nedědí se z terminálu, který build spustil.

Dokažte síťovou cestu zevnitř kroku buildu

Napište jednorázovou fázi, která přeloží hostitele závislosti a otevře k němu spojení. To je jediný test, který odpovídá na otázku za builder, ne 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/

Sestavte tento soubor stejným builderem, síťovým režimem a připojeními tajemství, jaká používá váš skutečný build: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Pokud getent nic nevypíše, jde o chybu překladu jmen a žádné přihlašovací údaje to nespraví. Pokud se jméno přeloží, ale curl hlásí timeout, překážkou je trasa nebo výstupní politika před registrem.

Sondu smažte, jakmile odpoví. Je to diagnostická fáze a neměla by se nikdy označovat ani odesílat.

Přihlašovací údaje připojujte, nekopírujte

Když trasa funguje, další v řadě je autentizace. Připojení tajemství v BuildKitu zpřístupní soubor jednomu RUN kroku, aniž by ho zapsalo do vrstvy, což je to, co nástroj pro závislosti potřebuje a co si image nesmí ponechat.

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

Tajemství se musí dodat zvenčí Dockerfile: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Soubor zůstává u klienta a nikdy nevstoupí do historie image. Ani ARG ani ENV se stejným tokenem tuto práci nedělají, protože oba se zaznamenávají do konfigurace image.

Image bez rootu potřebuje vlastní cílovou cestu, například /home/app/.npmrc nebo odpovídající soubor pro pip, Maven nebo Cargo. Cíl připojení musí odpovídat uživateli, který příkaz spouští, jinak nástroj ohlásí chybějící konfigurační soubor, který ve skutečnosti existuje.

Prověřte, co nástroj pro závislosti v image zanechává

Dočasné připojení drží přihlašovací údaje mimo vrstvu, ale nebrání nástroji zapsat něco jiného. Správci balíčků zanechávají lock soubory, adresáře cache a někdy i vyřešenou adresu registru.

Čtěte hotový souborový systém, místo abyste věřili Dockerfile. docker history --no-trunc image:tag vypisuje každý příkaz vrstvy a docker run --rm image:tag sh -c "ls -a /root" ukazuje, co přežilo do běžícího kontejneru. I když byl soubor jen připojený, token zapsaný do řádku logu během npm ci je pořád únik.

Přečtěte si i build log, protože --progress=plain tiskne výstup příkazů doslova. Pokud se token objeví tam, vyměňte ho dřív než cokoli jiného a předávejte ho přes soubor, který nástroj čte potichu.

Ověřte, že runtime image už privátní trasu nepotřebuje

Build a běžící aplikace jsou dva různí spotřebitelé stejné závislosti a privátní trasu potřebuje jen ten první. Hotová image by měla nastartovat, vyřešit své runtime závislosti a obsluhovat provoz bez přihlašovacích údajů z buildu.

Otestujte to tam, kde je privátní registr nedostupný, nebo prostě spusťte kontejner s --network none a potvrďte, že naběhne bez připojeného tajemství. Kontejner, který startuje jen když je přítomné build tajemství, je pořád svázaný s build prostředím.

Pokud kontejner registr v běhu opravdu potřebuje, je to samostatné rozhodnutí o přístupu a patří do úložiště tajemství orchestrátoru, ne do buildu. Zdokumentujte obě cesty odděleně, aby se nikdo nesnažil opravit runtime pull buildovým příznakem. Když všech pět kontrol projde, původní symptom má na každé vrstvě pojmenovanou příčinu místo dohadu o síti Dockeru.