Docker build xüsusi asılılığa çatmır: bu yoxlamalara baxın

Maşınınızda problemsiz həll olunan xüsusi paket build daxilində 404 və ya timeout ilə uğursuz ola bilər və Dockerfile buna səbəb olmur. Build mərhələsi başqa şəbəkə ad məkanında, başqa DNS görünüşü və sınaqdan keçirdiyiniz shell-dən fərqli etimad anbarı ilə işləyir. Bu yoxlamaları ardıcıllıqla keçin və ilk uğursuz olanda dayanın, çünki hər sonrakı yoxlama əvvəlkinin keçdiyini güman edir. Hər addım məsələni həll edən əmri göstərir.

Dockerfile ilə deyil, builder-in adından başlayın

BuildKit lokal, konteynerdə və ya başqa maşında ola bilər və hər birinin öz standart şəbəkəsi var. İşə salın docker buildx ls və hər hansı dəyişiklik etməzdən əvvəl ulduzla işarələnmiş node-u oxuyun. Bir docker-container sürücüsü və ya bulud builder-i sadəcə əmri orada yazdığınız üçün laptopunuzdakı xüsusi marşrutu paylaşmır. Aktiv builder uzaqdadırsa, qalan bütün yoxlamalar iş stansiyanızda deyil, həmin hostda aparılmalıdır.

Builder həmçinin öz resolver konfiqurasiyasını və proxy dəyişənlərinidaşıyır. Hər ikisi build zamanı oxunur və build-i başladan terminaldan miras alınmır.

Şəbəkə yolunu build addımının içindən sübut edin

Asılılıq hostunu həll edən və ona bağlantı açan müvəqqəti mərhələ yazın. Bu, sualı shell-iniz üçün deyil, builder üçün cavablandıran yeganə testdir.

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/

Həmin faylı real build-inizin istifadə etdiyi builder, şəbəkə rejimi və sirr mount-ları ilə build edin: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Əgər getent heç nə çap etmirsə, problem ad həllidir və heç bir etimad məlumatı bunu düzəltməyəcək. Ad həll olunur, amma curl timeout bildirirsə, maneə marşrut və ya registrin qarşısındakı çıxış siyasətidir.

Zond cavab verdikdən sonra onu silin. Bu diaqnostik mərhələdir, heç vaxt tag-lənməməli və push edilməməlidir.

Etimad məlumatını kopyalamaq əvəzinə mount edin

Yol işlədikdən sonra autentifikasiya növbəti uğursuzluqdur. BuildKit sirr mount-u faylı bir RUN addımına təqdim edir və onu laya yazmır; asılılıq alətinin ehtiyacı budur və image bunu saxlamamalıdır.

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

Sirr Dockerfile-dan kənarda verilməlidir: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Fayl klientdə qalır və heç vaxt image tarixçəsinə düşmür. Eyni tokeni saxlayan ARG və ya ENV bu işi görmür, çünki hər ikisi image konfiqurasiyasında qeyd olunur.

Qeyri-root image öz hədəf yoluna ehtiyac duyur, məsələn /home/app/.npmrc və ya pip, Maven, Cargo üçün ekvivalent fayl. Mount hədəfi əmri işlədən istifadəçi ilə uyğun olmalıdır, əks halda alət əslində mövcud olan konfiqurasiya faylını itmiş kimi bildirəcək.

Asılılıq alətinin image-də nə buraxdığını yoxlayın

Müvəqqəti mount etimad məlumatını laydan kənarda saxlayır, amma alətin başqa bir şey yazmasının qarşısını almır. Paket menecerləri lock faylları, keş qovluqları və bəzən həll olunmuş registr URL-ini geridə qoyur.

Dockerfile-a güvənmək əvəzinə hazır fayl sistemini oxuyun. docker history --no-trunc image:tag hər lay əmrini siyahıya alır və docker run --rm image:tag sh -c "ls -a /root" işləyən konteynerə nəyin keçdiyini göstərir. Hətta fayl yalnız mount olunmuşdusa da, log sətrinə yazılan token npm ci zamanı sızıntı olaraq qalır.

Build logunu da oxuyun, çünki --progress=plain əmrin çıxışını hərfi çap edir. Token orada görünürsə, hər şeydən əvvəl onu dəyişdirin və alətin səssizcə oxuduğu fayl vasitəsilə ötürün.

Runtime image-ın artıq xüsusi marşruta ehtiyacı olmadığını yoxlayın

Build və işləyən tətbiq eyni asılılığın iki fərqli istehlakçısıdır və yalnız birincisi xüsusi marşruta ehtiyac duyur. Hazır image build zamanı etimad məlumatı olmadan başlamalı, runtime asılılıqlarını həll etməli və trafikə xidmət etməlidir.

Bunu xüsusi registrin əlçatmaz olduğu yerdə sınayın və ya konteyneri sadəcə --network none ilə başladın və mount edilmiş sirr olmadan qalxdığını təsdiqləyin. Yalnız build sirri mövcud olduqda başlayan konteyner hələ də build mühitinə bağlıdır.

Konteyner runtime-da registrə həqiqətən ehtiyac duyursa, bu ayrı giriş qərarıdır və build-də deyil, orkestratorun sirr anbarında olmalıdır. İki yolu ayrı sənədləşdirin ki, heç kim runtime pull-u build flag-ı ilə düzəltməyə çalışmasın. Beş yoxlamanın hamısı keçdikdə, ilkin simptomun hər layda adı çəkilən səbəbi olur, Docker şəbəkəsi haqqında təxmin deyil.