Build Docker tidak sampai kepada kebergantungan peribadi: semak ini

Pakej peribadi yang diselesaikan tanpa masalah pada mesin anda boleh gagal di dalam build dengan 404 atau tamat masa, dan Dockerfile jarang menjadi puncanya. Langkah build berjalan dalam ruang nama rangkaian yang berbeza, dengan pandangan DNS dan stor kelayakan yang berbeza daripada shell tempat anda menguji. Lalui semakan ini mengikut urutan dan berhenti pada yang pertama gagal, kerana setiap semakan berikutnya menganggap yang sebelumnya lulus. Setiap langkah menamakan arahan yang menyelesaikan perkara itu.

Mulakan dengan menamakan builder, bukan Dockerfile

BuildKit boleh berada secara setempat, dalam kontena atau pada mesin lain, dan setiap satu mempunyai rangkaian lalai sendiri. Jalankan docker buildx ls dan baca nod yang ditandakan dengan asterisk sebelum mengubah apa-apa. Satu docker-container pemacu atau builder awan tidak berkongsi laluan peribadi pada komputer riba anda hanya kerana anda menaip arahan itu di sana. Jika builder aktif adalah jauh, setiap semakan yang tinggal mesti dijalankan terhadap hos itu, bukan stesen kerja anda.

Builder juga membawa konfigurasi resolver dan pemboleh ubah proxynya sendiri. Kedua-duanya dibaca pada masa build dan tidak diwarisi daripada terminal yang memulakan build.

Buktikan laluan rangkaian dari dalam langkah build

Tulis peringkat sekali guna yang menyelesaikan hos kebergantungan dan membuka sambungan kepadanya. Ini satu-satunya ujian yang menjawab soalan untuk builder dan bukan untuk shell anda.

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/

Bina fail itu dengan builder, mod rangkaian dan pemasangan secret yang sama seperti build sebenar anda: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Jika getent tidak mencetak apa-apa, kerosakan ada pada penyelesaian nama dan tiada kelayakan dapat membaikinya. Jika nama diselesaikan tetapi curl melaporkan tamat masa, penghalangnya ialah laluan atau dasar keluar di hadapan pendaftaran.

Padam probe itu sebaik sahaja ia menjawab. Ia peringkat diagnostik dan tidak sepatutnya ditag atau ditolak.

Pasang kelayakan itu dan bukannya menyalinnya

Setelah laluan berfungsi, pengesahan ialah kegagalan seterusnya dalam barisan. Pemasangan secret BuildKit mendedahkan fail kepada satu RUN langkah tanpa menulisnya ke lapisan, itulah yang diperlukan oleh alat kebergantungan dan yang tidak boleh disimpan oleh image.

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

Secret mesti dibekalkan dari luar Dockerfile: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Fail itu kekal pada klien dan tidak pernah masuk sejarah image. Satu ARG atau ENV dengan token yang sama tidak melakukan kerja ini, kerana kedua-duanya direkodkan dalam konfigurasi image.

Image tanpa root memerlukan laluan sasarannya sendiri, contohnya /home/app/.npmrc atau fail setara untuk pip, Maven atau Cargo. Sasaran pemasangan mesti sepadan dengan pengguna yang menjalankan arahan itu, jika tidak alat akan melaporkan fail konfigurasi yang hilang sedangkan ia sebenarnya ada.

Audit apa yang ditinggalkan oleh alat kebergantungan dalam image

Pemasangan sementara menyimpan kelayakan di luar lapisan, tetapi tidak menghalang alat daripada menulis perkara lain. Pengurus pakej meninggalkan fail lock, direktori cache dan kadangkala URL pendaftaran yang telah diselesaikan.

Baca sistem fail yang siap dan bukannya mempercayai Dockerfile. docker history --no-trunc image:tag menyenaraikan setiap arahan lapisan, dan docker run --rm image:tag sh -c "ls -a /root" menunjukkan apa yang terselamat ke dalam kontena yang berjalan. Walaupun fail itu hanya dipasang, token yang ditulis ke baris log semasa npm ci masih merupakan kebocoran.

Baca juga log build, kerana --progress=plain mencetak output arahan secara literal. Jika token muncul di sana, putarkannya sebelum apa-apa lagi dan salurkannya melalui fail yang dibaca alat itu secara senyap.

Sahkan image masa jalan tidak lagi memerlukan laluan peribadi

Build dan aplikasi yang berjalan ialah dua pengguna berbeza bagi kebergantungan yang sama, dan hanya yang pertama memerlukan laluan peribadi. Image yang siap sepatutnya bermula, menyelesaikan kebergantungan masa jalannya dan menyajikan trafik tanpa kelayakan build.

Ujinya di tempat pendaftaran peribadi tidak dapat dicapai, atau mulakan kontena itu dengan --network none dan sahkan ia but tanpa secret yang dipasang. Kontena yang hanya bermula apabila secret build hadir masih terikat pada persekitaran build.

Jika kontena benar-benar memerlukan pendaftaran pada masa jalan, itu keputusan akses yang berasingan, dan tempatnya di stor secret orkestrator dan bukan di build. Dokumenkan kedua-dua laluan secara berasingan supaya tiada siapa cuba membaiki tarikan masa jalan dengan bendera build. Apabila kelima-lima semakan lulus, gejala asal mempunyai punca bernama pada setiap lapisan dan bukannya tekaan tentang rangkaian Docker.