A Docker build nem éri el a privát függőséget: ellenőrizze ezt

Egy privát csomag, amely a gépén gond nélkül feloldódik, a builden belül mégis elbukhat egy 404-es hibával vagy időtúllépéssel, és a Dockerfile ritkán az ok. A build lépés más hálózati névtérben fut, más DNS-képpel és más hitelesítőadat-tárral, mint a shell, amelyben tesztelt. Járja végig ezeket az ellenőrzéseket sorrendben, és álljon meg az elsőnél, amely elbukik, mert minden későbbi ellenőrzés feltételezi, hogy az előző átment. Minden lépés megnevezi a parancsot, amely eldönti a kérdést.

Kezdje a builder megnevezésével, ne a Dockerfile-lal

A BuildKit lehet helyi, konténerben futó vagy más gépen futó, és mindegyiknek saját alapértelmezett hálózata van. Futtassa a docker buildx ls parancsot, és olvassa el a csillaggal jelölt csomópontot, mielőtt bármit módosít. Egy docker-container illesztő vagy felhőbeli builder nem osztja meg a laptopján lévő privát útvonalat csak azért, mert ott írta be a parancsot. Ha az aktív builder távoli, minden további ellenőrzést azon a gazdagépen kell futtatni, nem a munkaállomásán.

A builder a saját resolver-konfigurációját és proxy-változóitis hordozza. Mindkettőt a build idején olvassa be, és nem örökli a buildet indító termináltól.

Bizonyítsa a hálózati útvonalat egy build-lépés belsejéből

Írjon egy eldobható szakaszt, amely feloldja a függőség gazdagépét, és kapcsolatot nyit felé. Ez az egyetlen teszt, amely a builder számára válaszol a kérdésre, nem a shellje számára.

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/

Építse meg ezt a fájlt ugyanazzal a builderrel, hálózati móddal és secret-csatolással, amelyet a valódi buildje használ: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Ha a getent semmit nem ír ki, a hiba névfeloldási, és egyetlen hitelesítő adat sem javítja meg. Ha a név feloldódik, de a curl időtúllépésről számol be, az akadály az útvonal vagy a bejegyzés előtti kimenő forgalmi szabály.

Törölje a szondát, amint válaszolt. Ez egy diagnosztikai szakasz, és soha nem szabad címkézni vagy pusholni.

Csatolja a hitelesítő adatot ahelyett, hogy másolná

Amikor az útvonal működik, a hitelesítés a következő hiba a sorban. A BuildKit secret-csatolás egyetlen RUN lépésnek tesz elérhetővé egy fájlt anélkül, hogy rétegbe írná, ezt igényli a függőségi eszköz, és ezt nem tarthatja meg az image.

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

A titkot a Dockerfile-on kívülről kell biztosítani: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. A fájl az ügyfélnél marad, és soha nem kerül be az image előzményeibe. Egy ARG vagy ENV ugyanazzal a tokennel nem végzi el ezt a munkát, mert mindkettő bekerül az image konfigurációjába.

A nem root image-nek saját célútvonalra van szüksége, például /home/app/.npmrc vagy a pip, Maven vagy Cargo megfelelő fájljára. A csatolási célnak meg kell felelnie a parancsot futtató felhasználónak, különben az eszköz hiányzó konfigurációs fájlról számol be, amely valójában ott van.

Vizsgálja meg, mit hagy a függőségi eszköz az image-ben

Az ideiglenes csatolás távol tartja a hitelesítő adatot a rétegtől, de nem akadályozza meg az eszközt abban, hogy mást írjon. A csomagkezelők lock-fájlokat, cache-könyvtárakat és néha a feloldott registry URL-t hagyják maguk után.

Olvassa a kész fájlrendszert ahelyett, hogy megbízna a Dockerfile-ban. docker history --no-trunc image:tag felsorolja az összes rétegparancsot, és a docker run --rm image:tag sh -c "ls -a /root" megmutatja, mi maradt meg a futó konténerben. Még ha a fájl csak csatolva volt, a naplósorba írt token a npm ci során is szivárgás marad.

Olvassa el a build-naplót is, mert a --progress=plain szó szerint kiírja a parancsok kimenetét. Ha a token ott megjelenik, minden más előtt forgassa át, és olyan fájlon keresztül adja át, amelyet az eszköz csendben olvas.

Ellenőrizze, hogy a futtatási image-nek már nincs szüksége a privát útvonalra

A build és a futó alkalmazás ugyanannak a függőségnek két különböző fogyasztója, és csak az elsőnek van szüksége a privát útvonalra. A kész image-nek el kell indulnia, fel kell oldania a futtatási függőségeit, és forgalmat kell kiszolgálnia a build hitelesítő adata nélkül.

Tesztelje ott, ahol a privát registry nem érhető el, vagy indítsa el a konténert egyszerűen --network none és erősítse meg, hogy a csatolt titok nélkül indul el. Az a konténer, amely csak akkor indul, ha jelen van a build-titok, még mindig a build környezetéhez kötődik.

Ha a konténernek futásidőben valóban szüksége van a registryre, az külön hozzáférési döntés, és a helye az orchestrator titoktárában van, nem a buildben. Dokumentálja külön a két útvonalat, hogy senki ne próbáljon egy futásidejű pullt build-kapcsolóval megjavítani. Amikor mind az öt ellenőrzés átmegy, az eredeti tünetnek minden rétegen megnevezett oka van, nem találgatás a Docker hálózatáról.