Docker derlemesi özel bir bağımlılığa ulaşmıyor: bunu kontrol edin

Kendi makinenizde sorunsuz çözülen özel bir paket, derleme içinde 404 veya zaman aşımıyla başarısız olabilir ve Dockerfile nadiren nedendir. Derleme adımı başka bir ağ ad alanında, test ettiğiniz shell’den farklı bir DNS görünümü ve farklı bir kimlik bilgisi deposuyla çalışır. Bu kontrolleri sırayla yapın ve ilk başarısız olanda durun, çünkü sonraki her kontrol öncekinin geçtiğini varsayar. Her adım, konuyu çözen komutu adlandırır.

Dockerfile ile değil, builder’ı adlandırarak başlayın

BuildKit yerel, bir container içinde veya başka bir makinede çalışabilir ve her birinin kendi varsayılan ağı vardır. Şunu çalıştırın: docker buildx ls ve herhangi bir şeyi değiştirmeden önce yıldızla işaretli düğümü okuyun. Bir docker-container sürücü veya bulut builder’ı, komutu orada yazdığınız için dizüstü bilgisayarınızdaki özel rotayı paylaşmaz. Etkin builder uzaktaysa, kalan her kontrol sizin iş istasyonunuzda değil o ana makinede çalıştırılmalıdır.

Builder ayrıca kendi resolver yapılandırmasını ve proxy değişkenlerinitaşır. İkisi de derleme sırasında okunur ve derlemeyi başlatan terminalden miras alınmaz.

Ağ yolunu bir derleme adımının içinden kanıtlayın

Bağımlılığın ana makinesini çözen ve ona bir bağlantı açan tek kullanımlık bir aşama yazın. Soruyu sizin shell’iniz için değil builder için yanıtlayan tek test budur.

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 dosyayı gerçek derlemenizin kullandığı builder, ağ modu ve secret bağlamalarıyla derleyin: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Eğer getent hiçbir şey yazdırmıyorsa sorun ad çözümlemesindedir ve hiçbir kimlik bilgisi bunu düzeltmez. Ad çözülüyor ama curl zaman aşımı bildiriyorsa engel, rotadır veya kayıt defterinin önündeki çıkış ilkesidir.

Sonda yanıt verdiği anda onu silin. Tanılama aşamasıdır ve asla etiketlenmemeli veya push edilmemelidir.

Kimlik bilgisini kopyalamak yerine bağlayın

Yol çalıştığında sıradaki başarısızlık kimlik doğrulamadır. BuildKit secret bağlaması bir dosyayı tek bir RUN adıma sunar ve onu bir katmana yazmaz; bağımlılık aracının ihtiyacı budur ve imajın saklamaması gereken de budur.

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

Secret, Dockerfile dışından sağlanmalıdır: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Dosya istemcide kalır ve asla imaj geçmişine girmez. Aynı token’ı tutan bir ARG veya ENV bu işi yapmaz, çünkü ikisi de imaj yapılandırmasına kaydedilir.

Root olmayan bir imaj kendi hedef yoluna ihtiyaç duyar, örneğin /home/app/.npmrc veya pip, Maven ya da Cargo için eşdeğer dosya. Bağlama hedefi komutu çalıştıran kullanıcıyla eşleşmelidir, yoksa araç aslında var olan bir yapılandırma dosyasını eksik diye bildirir.

Bağımlılık aracının imajda ne bıraktığını denetleyin

Geçici bir bağlama kimlik bilgisini katman dışında tutar, ama aracın başka bir şey yazmasını engellemez. Paket yöneticileri lock dosyaları, önbellek dizinleri ve bazen çözülmüş kayıt defteri URL’sini geride bırakır.

Dockerfile’a güvenmek yerine tamamlanmış dosya sistemini okuyun. docker history --no-trunc image:tag her katman komutunu listeler ve docker run --rm image:tag sh -c "ls -a /root" çalışan container’a neyin kaldığını gösterir. Dosya yalnızca bağlanmış olsa bile, günlük satırına yazılan bir token npm ci sırasında da sızıntı olarak kalır.

Derleme günlüğünü de okuyun, çünkü --progress=plain komut çıktısını kelimesi kelimesine basar. Token orada görünürse, her şeyden önce onu döndürün ve aracın sessizce okuduğu bir dosya üzerinden geçirin.

Çalışma zamanı imajının artık özel rotaya ihtiyaç duymadığını doğrulayın

Derleme ve çalışan uygulama aynı bağımlılığın iki farklı tüketicisidir ve özel rotaya yalnızca ilki ihtiyaç duyar. Tamamlanmış bir imaj, derleme kimlik bilgisi olmadan başlamalı, çalışma zamanı bağımlılıklarını çözmeli ve trafiğe hizmet etmelidir.

Bunu özel kayıt defterine ulaşılamayan bir yerde test edin ya da container’ı yalnızca --network none ile başlatın ve bağlanmış secret olmadan açıldığını doğrulayın. Yalnızca build secret varken başlayan bir container hâlâ derleme ortamına bağlıdır.

Container’ın çalışma zamanında kayıt defterine gerçekten ihtiyacı varsa bu ayrı bir erişim kararıdır ve yeri derleme değil, orkestratörün secret deposudur. İki yolu ayrı ayrı belgeleyin ki kimse çalışma zamanı çekimini bir derleme bayrağıyla onarmaya çalışmasın. Beş kontrolün tümü geçtiğinde, özgün belirtinin her katmanda adlandırılmış bir nedeni olur, Docker ağı hakkında bir tahmin değil.