Приватни пакет који се на вашем рачунару решава без проблема може пасти унутар build-а са грешком 404 или timeout-ом, а Dockerfile је ретко разлог. Корак build-а ради у другом мрежном простору имена, са другачијим погледом на DNS и другим складиштем акредитива од љуске у којој сте тестирали. Прођите ове провере редом и зауставите се на првој која падне, јер свака каснија претпоставља да је претходна прошла. Сваки корак именује команду која решава питање.

Почните именовањем buildera, а не Dockerfile-а

BuildKit може бити локалан, у контејнеру или на другом рачунару, и сваки од њих има своју подразумевану мрежу. Покрените docker buildx ls и прочитајте чвор означен звездицом пре него што било шта измените. Један docker-container драјвер или cloud builder не дели приватну руту на вашем лаптопу само зато што сте команду откуцали тамо. Ако је активни builder удаљен, свака преостала провера мора се извршити на том хосту, а не на вашој радној станици.

Builder носи и своју конфигурацију resolver-а и proxy променљиве. Обе се читају у време build-а и не наслеђују се од терминала који је build покренуо.

Докажите мрежну путању из унутрашњости корака build-а

Напишите привремену фазу која разрешава host зависности и отвара везу ка њему. То је једини тест који одговара на питање за builder, а не за вашу љуску.

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/

Изградите ту датотеку истим builder-ом, мрежним режимом и истим монтажама тајни које користи ваш прави build: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Ако getent ништа не испише, квар је у разрешавању имена и никакав акредитив га неће поправити. Ако се име разреши али curl пријави timeout, препрека је рута или излазна политика испред регистра.

Обришите сонду чим одговори. То је дијагностичка фаза и не треба је никада означавати ни потискивати.

Монтирајте акредитив уместо да га копирате

Кад путања проради, аутентификација је следећи квар у реду. BuildKit монтажа тајне излаже датотеку једном RUN кораку без уписивања у слој, што је оно што алат за зависности треба и што слика не сме да задржи.

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

Тајна мора да се достави изван Dockerfile-а: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Датотека остаје на клијенту и никада не улази у историју слике. Један ARG или ENV са истим токеном не обављају тај посао, јер се обоје бележи у конфигурацији слике.

Слика без root-а треба сопствену циљну путању, на пример /home/app/.npmrc или одговарајућу датотеку за pip, Maven или Cargo. Циљ монтаже мора да одговара кориснику који извршава команду, иначе ће алат пријавити конфигурациону датотеку која недостаје, а заправо постоји.

Проверите шта алат за зависности оставља у слици

Привремена монтажа држи акредитив изван слоја, али не спречава алат да упише нешто друго. Менаџери пакета остављају lock датотеке, кеш директоријуме и понекад разрешену URL адресу регистра.

Читајте готови датотечни систем уместо да верујете Dockerfile-у. docker history --no-trunc image:tag наводи сваку команду слоја, а docker run --rm image:tag sh -c "ls -a /root" показује шта је преживело у покренутом контејнеру. Чак и када је датотека само монтирана, токен уписан у линију лога током npm ci извршавања и даље је цурење.

Прочитајте и build лог, јер --progress=plain исписује излаз команди дословно. Ако се токен тамо појави, ротирајте га пре свега другог и прослеђујте га кроз датотеку коју алат чита тихо.

Проверите да runtime слици више није потребна приватна путања

Build и апликација која ради су два различита потрошача исте зависности, и само првом је потребна приватна рута. Готова слика треба да се покрене, разреши своје runtime зависности и служи саобраћај без акредитива из build-а.

Тестирајте то тамо где је приватни регистар недоступан, или једноставно покрените контејнер са --network none и потврдите да се диже без монтиране тајне. Контејнер који се покреће само кад је build тајна присутна и даље је везан за build окружење.

Ако контејнеру регистар заиста треба у runtime-у, то је одвојена одлука о приступу и припада у secret store оркестратора, а не у build. Документујте две путање одвојено да нико не покуша да поправи runtime pull build флагом. Када свих пет провера прође, изворни симптом има именован узрок на сваком слоју уместо нагађања о Docker мрежи.

Повезани чланци