Docker build жеке көз карандылыкка жетпейт: муну текшериңиз

Сиздин машинаңызда эч кыйынчылыксыз чечилген жеке пакет build ичинде 404 же убакыт бүтүү менен ишке ашпашы мүмкүн, ал эми Dockerfile сейрек себеп болот. Build кадамы башка тармактык аттар мейкиндигинде иштейт, DNS көрүнүшү да, каттоо маалыматтарынын кампасы да сиз сынаган shellден башкача. Бул текшерүүлөрдү ирети менен аткарып, биринчи ишке ашпаганында токтоңуз, анткени ар бир кийинки текшерүү мурункусу өттү деп эсептейт. Ар бир кадам маселени чечкен буйрукту атайт.

Dockerfile эмес, builderдин атынан баштаңыз

BuildKit жергиликтүү, контейнерде же башка машинада болушу мүмкүн, жана ар биринин өзүнүн демейки тармагы бар. Иштетиңиз docker buildx ls жана бир нерсени өзгөртүүдөн мурун жылдызча менен белгиленген түйүндү окуңуз. Бир docker-container драйвери же булуттук builder ноутбукуңуздагы жеке маршрутту буйрукту ошол жерде тергениңиз үчүн гана бөлүшпөйт. Эгер активдүү builder алыста болсо, калган ар бир текшерүү сиздин жумуш станцияңызда эмес, ошол хостто аткарылышы керек.

Builder ошондой эле өзүнүн resolver конфигурациясын жана proxy өзгөрмөлөрүналып жүрөт. Экөө тең build убагында окулат жана build баштаган терминалдан мураска өтпөйт.

Тармактык жолду build кадамынын ичинен далилдеңиз

Көз карандылыктын хостун чечкен жана ага байланыш ачкан бир жолку этап жазыңыз. Бул суроого builder үчүн жооп берген жалгыз тест, 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/

Бул файлды чыныгы buildиңиз колдонгон builder, тармактык режим жана сыр бекитүүлөр менен куруңуз: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Эгер getent эч нерсе чыгарбаса, кемчилик ат чечүүдө жана эч бир каттоо маалыматы аны оңдобойт. Эгер ат чечилсе, бирок curl убакыт бүткөнүн билдирсе, тоскоол — маршрут же реестрдин алдындагы чыгуу саясаты.

Зонд жооп бергенде эле аны жок кылыңыз. Бул диагностикалык этап жана ага эч качан тег коюп, push жасабоо керек.

Каттоо маалыматтарын көчүрүүнүн ордуна бекитиңиз

Жол иштегенден кийин аутентификация — кезектеги кийинки ишке ашпоочулук. BuildKit сыр бекитүүсү файлды бир RUN кадамга ачат, аны катмарга жазбастан; көз карандылык куралына ушул керек, ал эми image аны сактабашы керек.

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

Сырды Dockerfileдан тышкары берүү керек: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Файл кардарда калат жана эч качан image тарыхына кирбейт. Бир ARG же ENV ошол эле токен менен бул ишти аткарбайт, анткени экөө тең image конфигурациясында жазылат.

Root эмес imageге өзүнүн максаттуу жолу керек, мисалы /home/app/.npmrc же pip, Maven же Cargo үчүн барабар файл. Бекитүүнүн максаты буйрукту аткарган колдонуучуга дал келиши керек, болбосо курал чындыгында бар конфигурация файлын жок деп билдирет.

Көз карандылык куралы imageде эмнени калтырарын текшериңиз

Убактылуу бекитүү каттоо маалыматын катмардан тышкары кармайт, бирок куралдын башка нерсе жазышына тоскоол болбойт. Пакет менеджерлери lock файлдарын, cache каталогдорун жана кээде чечилген реестр URLин калтырат.

Dockerfileга ишенүүнүн ордуна даяр файл системасын окуңуз. docker history --no-trunc image:tag ар бир катмар буйругун тизмелеп чыгат, ал эми docker run --rm image:tag sh -c "ls -a /root" иштеп жаткан контейнерге эмне жеткенин көрсөтөт. Файл гана бекитилген болсо да, журнал сабына жазылган токен npm ci убактысында да агып кетүү бойдон калат.

Build журналын да окуңуз, анткени --progress=plain буйруктардын чыгарылышын сөзмө-сөз басып чыгарат. Эгер токен ошол жерде көрүнсө, аны баарынан мурун алмаштырып, курал үнсүз окуган файл аркылуу өткөрүңүз.

Аткаруу убагындагы imageге жеке жол эми керек эместигин текшериңиз

Build жана иштеп жаткан колдонмо — бир көз карандылыктын эки башка керектөөчүсү, жана жеке маршрут биринчисине гана керек. Даяр image build убагындагы каттоо маалыматысыз иштетилиши, өзүнүн аткаруу көз карандылыктарын чечиши жана трафикти тейлеши керек.

Аны жеке реестр жеткиликсиз жерде сынап көрүңүз же контейнерди жөн гана --network none менен иштетип, бекитилген сырсыз жүктөлөрүн ырастаңыз. Build сыры болгондо гана иштеген контейнер дагы эле build чөйрөсүнө байланган.

Эгер контейнерге реестр аткаруу убагында чын эле керек болсо, бул өзүнчө жеткиликтүүлүк чечими жана анын орду оркестратордун сырлар кампасында, buildде эмес. Эки жолду өзүнчө документтештириңиз, ошондо эч ким аткаруу убагындагы тартууну build желеги менен оңдоого аракет кылбайт. Беш текшерүүнүн баары өткөндө, баштапкы симптомдун ар бир катмарда аталган себеби болот, Docker тармагы тууралуу божомол эмес.