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 желісі туралы болжам емес.