Docker build shaxsiy bogʻliqlikka yetib bormaydi: buni tekshiring

Sizning mashinangizda muammosiz hal boʻladigan shaxsiy paket build ichida 404 yoki vaqt tugashi bilan muvaffaqiyatsiz boʻlishi mumkin, va Dockerfile kamdan-kam sabab boʻladi. Build qadami boshqa tarmoq nomlar fazosida ishlaydi, DNS koʻrinishi va hisob maʼlumotlari ombori siz sinagan shell-dan farq qiladi. Bu tekshiruvlarni tartib bilan bajaring va birinchi muvaffaqiyatsiz boʻlganida toʻxtang, chunki har bir keyingi tekshiruv avvalgisi oʻtgan deb hisoblaydi. Har bir qadam masalani hal qiluvchi buyruqni nomlaydi.

Dockerfile bilan emas, builder nomi bilan boshlang

BuildKit mahalliy, konteynerda yoki boshqa mashinada ishlashi mumkin, va har birining oʻz standart tarmogʻi bor. Ishga tushiring docker buildx ls va biror narsani oʻzgartirishdan oldin yulduzcha bilan belgilangan tugunni oʻqing. Bitta docker-container drayver yoki bulut builder faqat buyruqni oʻsha yerda yozganingiz uchun noutbukingizdagi shaxsiy yoʻlni baham koʻrmaydi. Agar faol builder uzoqda boʻlsa, qolgan har bir tekshiruv sizning ish stansiyangizda emas, oʻsha xostda bajarilishi kerak.

Builder shuningdek oʻzining resolver konfiguratsiyasi va proxy oʻzgaruvchilariniolib yuradi. Ikkalasi ham build vaqtida oʻqiladi va build-ni boshlagan terminaldan meros qilib olinmaydi.

Tarmoq yoʻlini build qadami ichidan isbotlang

Bogʻliqlik xostini hal qiladigan va unga ulanish ochadigan bir martalik bosqich yozing. Bu savolga builder uchun javob beradigan yagona sinov, sizning shellingiz uchun emas.

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/

Bu faylni haqiqiy buildingiz ishlatadigan builder, tarmoq rejimi va sir bogʻlashlar bilan build qiling: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Agar getent hech narsa chop etmasa, xato nom hal qilishda va hech qanday hisob maʼlumoti uni tuzatmaydi. Nom hal boʻlsa-yu curl vaqt tugaganini xabar qilsa, toʻsiq yoʻl yoki reyestr oldidagi chiqish siyosatidir.

Zond javob berishi bilan uni oʻchiring. Bu diagnostik bosqich va unga hech qachon teg yoki push qilinmasligi kerak.

Hisob maʼlumotini nusxalash oʻrniga bogʻlang

Yoʻl ishlagandan soʻng, keyingi muvaffaqiyatsizlik autentifikatsiya. BuildKit sir bogʻlashi faylni bitta RUN qadamga ochib beradi, uni qatlamga yozmasdan; bogʻliqlik asbobiga aynan shu kerak va image buni saqlamasligi kerak.

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

Sir Dockerfile tashqarisidan taʼminlanishi kerak: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Fayl mijozda qoladi va hech qachon image tarixiga kirmaydi. Xuddi shu tokenga ega ARG yoki ENV bu ishni bajarmaydi, chunki ikkalasi ham image konfiguratsiyasida qayd etiladi.

Root boʻlmagan image oʻz maqsad yoʻliga muhtoj, masalan /home/app/.npmrc yoki pip, Maven yoki Cargo uchun mos fayl. Bogʻlash maqsadi buyruqni bajarayotgan foydalanuvchiga mos kelishi kerak, aks holda asbob aslida mavjud boʻlgan konfiguratsiya faylini yoʻq deb xabar qiladi.

Bogʻliqlik asbobi image ichida nima qoldirishini tekshiring

Vaqtinchalik bogʻlash hisob maʼlumotini qatlamdan tashqarida tutadi, lekin asbobni boshqa narsa yozishdan toʻxtatmaydi. Paket menejerlari lock fayllar, kesh kataloglari va baʼzan hal qilingan reyestr URL manzilini qoldiradi.

Dockerfile-ga ishonish oʻrniga tayyor fayl tizimini oʻqing. docker history --no-trunc image:tag har bir qatlam buyrugʻini sanab chiqadi, va docker run --rm image:tag sh -c "ls -a /root" ishlayotgan konteynerga nima yetib kelganini koʻrsatadi. Fayl faqat bogʻlangan boʻlsa ham, log satriga yozilgan token npm ci davomida ham oqish boʻlib qoladi.

Build logini ham oʻqing, chunki --progress=plain buyruqlar chiqishini soʻzma-soʻz chop etadi. Agar token u yerda koʻrinsa, uni hamma narsadan oldin almashtiring va asbob jimgina oʻqiydigan fayl orqali oʻtkazing.

Ishlash image-iga endi shaxsiy yoʻl kerak emasligini tasdiqlang

Build va ishlayotgan dastur bir xil bogʻliqlikning ikki xil isteʼmolchisi, va shaxsiy yoʻl faqat birinchisiga kerak. Tayyor image build vaqtidagi hisob maʼlumotisiz ishga tushishi, ishlash bogʻliqliklarini hal qilishi va trafikni xizmat qilishi kerak.

Buni shaxsiy reyestr yetib boʻlmaydigan joyda sinab koʻring, yoki konteynerni shunchaki --network none bilan ishga tushirib, bogʻlangan sirsiz yuklanishini tasdiqlang. Faqat build siri mavjud boʻlganda ishga tushadigan konteyner hali ham build muhitiga bogʻlangan.

Agar konteynerga ishlash vaqtida reyestr haqiqatan kerak boʻlsa, bu alohida kirish qarori, va uning oʻrni orkestratorning sir ombori, build emas. Ikki yoʻlni alohida hujjatlashtiring, hech kim ishlash vaqtidagi tortishni build bayrogʻi bilan tuzatishga urinmasin. Beshta tekshiruvning barchasi oʻtgach, asl belgi har bir qatlamda nomlangan sababga ega boʻladi, Docker tarmogʻi haqidagi taxmin emas.