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, сүлжээний горим болон нууц холболтуудтай нь build хий: 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 файл, кеш хавтас, заримдаа шийдэгдсэн бүртгэлийн 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 сүлжээний талаарх таамаг биш.