Moby: hanya waktu pembuatan -v opsi

Saya mencari solusi serupa.

Masalah

Baru-baru ini perusahaan tempat saya bekerja mengaktifkan proxy Zscaler dengan inspeksi SSL, yang menyiratkan bahwa sertifikat telah diinstal dan beberapa variabel lingkungan ditetapkan selama pembuatan.

Solusi sementara adalah membuat Dockerfile baru dengan sertifikat dan variabel lingkungan yang ditetapkan. Tapi itu sepertinya tidak masuk akal, dalam pandangan jangka panjang.

Jadi, pikiran pertama saya adalah mengatur proxy transparan dengan HTTP dan HTTPS, tetapi sekali lagi saya harus memberikan sertifikat selama pembuatan.

Skenario yang ideal adalah dengan Dockerfile yang sama, saya akan dapat membangun citra saya di laptop saya, di rumah, dan perusahaan.

Solusi yang mungkin

# Enterprise
$ docker build -v /etc/ssl:/etc/ssl -t myimage .

# Home
$ docker build -t myimage .

Saya memiliki kasus penggunaan yang sedikit berbeda untuk fitur ini - paket Caching yang diunduh / diperbarui oleh manajer paket ASP.Net 5 . Manajer paket mengelola folder cache-nya sendiri sehingga pada akhirnya saya hanya perlu folder yang dapat saya gunakan kembali di antara build.

Yaitu:

docker build -v /home/dokku/cache/dnx/packages:/opt/dnx/packages -t "dokku/aspnettest" .

@yngndrw apa yang Anda usulkan akan baik-baik saja untuk saya juga, yaitu, kita perlu memasang sumber daya tambahan pada waktu pembuatan yang tidak diperlukan pada waktu berjalan karena telah dipasang di wadah.

FWIW Saya melihat di suatu tempat di halaman ini seseorang mengatakan sesuatu di sepanjang baris (dan saya harap saya memparafrasekannya dengan benar) "menyelesaikan masalah kompilasi Anda pada mesin Host yang serupa lalu cukup instal artefak atau exe yang dapat digunakan dalam wadah".
Saya khawatir itu tidak sesederhana itu guys. Kadang-kadang, saya perlu menginstal di /usr/bin tetapi saya juga perlu mengedit beberapa file konfigurasi. Saya memeriksa OS yang saya jalankan, params kernel yang perlu saya setel, file yang perlu saya buat tergantung pada variabel atau file build manifesto. Ada banyak dependensi yang tidak puas dengan salinan sederhana dari produk yang dikompilasi.

Saya menyatakan kembali apa yang saya katakan ketika saya membuka masalah: ada perbedaan antara file deklarasi manifes dan prosesnya dan waktu proses artefak.
Jika kita benar-benar percaya pada infrastruktur-sebagai-kode dan lebih jauh lagi pada infrastruktur yang tidak dapat diubah, yang Docker sendiri promosikan lebih lanjut & saya menyukainya btw, maka ini perlu dipertimbangkan secara serius IMO (lihat kembung di posting 1 dengan ini)

Terima kasih lagi

Kasus penggunaan lain yang sangat menarik adalah memutakhirkan perangkat lunak. Ada kalanya, seperti dengan FreeIPA, Anda harus benar-benar menguji dengan salinan data produksi untuk memastikan bahwa semua komponen yang berbeda dapat ditingkatkan dengan bersih. Anda masih ingin melakukan upgrade di lingkungan "build". Anda ingin salinan produksi data berada di tempat lain sehingga saat Anda memindahkan versi baru container yang telah ditingkatkan ke produksi, mereka dapat menyimpan data persis yang Anda lakukan pemutakhiran.

Contoh lain, adalah Satellite/Spacewalk yang sering mengubah skema dan bahkan mengubah database dari Oracle ke Postgresql pada versi 5.6 (IIRC).

Ada banyak, banyak skenario ketika saya sementara membutuhkan akses ke data saat melakukan pemutakhiran perangkat lunak dalam bangunan kemas, terutama dengan layanan terdistribusi/mikro....

Pada dasarnya, saya sekarang dipaksa untuk melakukan pemutakhiran manual dengan menjalankan wadah biasa dengan -v bind mount, lalu melakukan "docker commit." Saya tidak mengerti mengapa kemampuan yang sama tidak tersedia dengan build Dockerfile otomatis?

Pendukung @yngndrw menunjukkan caching: alasan yang sama persis berlaku untuk banyak proyek populer seperti Maven, npm, apt, rpm -- memungkinkan cache bersama dapat secara dramatis mempercepat build, tetapi tidak boleh membuatnya menjadi gambar akhir.

Saya setuju dengan @stevenschlansker. Mungkin banyak persyaratan untuk melampirkan volume cache, atau semacam beberapa gigabyte data, yang harus ada (dalam keadaan diuraikan) pada gambar akhir, tetapi bukan sebagai data mentah.

Saya juga telah digigit oleh resistensi yang konsisten untuk memperluas docker build untuk mendukung volume yang dapat digunakan oleh docker run . Saya belum menemukan mantra 'host-independen builds' sangat meyakinkan, karena tampaknya hanya membuat pengembangan dan iterasi pada gambar Docker lebih sulit dan memakan waktu ketika Anda perlu mengunduh ulang seluruh repositori paket setiap kali Anda membangun kembali sebuah gambar.

Kasus penggunaan awal saya adalah keinginan untuk men-cache repositori paket OS untuk mempercepat iterasi pengembangan. Solusi yang saya gunakan dengan beberapa keberhasilan mirip dengan pendekatan yang disarankan oleh @fatherlinux , yaitu berhenti bergulat dengan docker build dan Dockerfile sama sekali, dan mulai dari awal menggunakan docker run pada skrip shell standar diikuti oleh docker commit .

Sebagai sedikit percobaan, saya memperluas teknik saya menjadi pengganti penuh untuk docker build menggunakan sedikit skrip shell POSIX: dockerize .

Jika ada yang ingin menguji skrip ini atau pendekatan umum, beri tahu saya jika ini menarik atau membantu (atau jika berhasil untuk Anda). Untuk menggunakannya, letakkan skrip di suatu tempat di PATH Anda dan tambahkan sebagai shebang untuk skrip build Anda (hal #! ), lalu atur variabel lingkungan yang relevan sebelum baris shebang kedua yang menandai awal skrip instalasi Docker Anda.

Variabel FROM , RUNDIR , dan VOLUME akan secara otomatis diteruskan sebagai argumen ke docker run .
Variabel TAG , EXPOSE , dan WORKDIR akan secara otomatis diteruskan sebagai argumen ke docker commit .

Semua variabel lain akan dievaluasi di shell dan diteruskan sebagai argumen lingkungan ke docker run , membuatnya tersedia dalam skrip build Anda.

Misalnya, skrip ini akan menyimpan dan menggunakan kembali paket Alpine Linux antar build (VOLUME memasang direktori home ke CACHE, yang kemudian digunakan sebagai symlink untuk cache repositori paket OS di skrip instalasi):

#!/usr/bin/env dockerize
FROM=alpine
TAG=${TAG:-wjordan/my-image}
WORKDIR=/var/cache/dockerize
CACHE=/var/cache/docker
EXPOSE=3001
VOLUME="${HOME}/.docker-cache:${CACHE} ${PWD}:${WORKDIR}:ro /tmp"
#!/bin/sh
ln -s ${CACHE}/apk /var/cache/apk
ln -s ${CACHE}/apk /etc/apk/cache
set -e
apk --update add gcc g++ make libc-dev python
[...etc etc build...]

Jadi, setelah bertemu dengan kontingen Prancis :) dari Docker di MesoCon minggu lalu (sangat menyenangkan teman-teman) saya diberitahu bahwa mereka memiliki masalah yang sama di rumah dan mereka mengembangkan peretasan yang menyalin ke gambar ramping baru apa yang mereka butuhkan .
Saya akan mengatakan bahwa peretasan disambut baik di dunia perusahaan;) dan permintaan ini harus ditangani dengan benar.
Terima kasih sudah mendengarkan teman-teman...

Saya juga mendukung penambahan flag -v build-time untuk mempercepat build dengan membagikan direktori cache di antara mereka.

@yngndrw Saya tidak mengerti mengapa Anda menutup dua masalah terkait. Saya membaca masalah #59 Anda dan saya tidak melihat bagaimana ini berhubungan dengan ini. Dalam beberapa kasus wadah menjadi sangat kembung saat tidak diperlukan saat run-time. Silahkan baca postingan pertama.
Saya harap saya tidak melewatkan sesuatu di sini ... karena ini adalah hari yang panjang :-o

@zrml Masalah https://github.com/aspnet/aspnet-docker/issues/59 terkait dengan caching per-lapisan bawaan yang disediakan buruh pelabuhan selama pembangunan ke semua file buruh pelabuhan, tetapi masalah saat ini agak berbeda kita berbicara tentang menggunakan volume Host untuk menyediakan caching khusus dockerfile yang bergantung pada dockerfile yang memanfaatkan volume secara khusus. Saya menutup masalah https://github.com/aspnet/aspnet-docker/issues/59 karena tidak secara khusus terkait dengan proyek/repositori aspnet-docker.

Masalah lain yang menurut saya Anda maksud adalah masalah https://github.com/progrium/dokku/issues/1231 , yang berkaitan dengan proses Dokku yang secara eksplisit menonaktifkan caching lapisan buruh pelabuhan bawaan. Michael membuat perubahan pada Dokku agar perilaku ini dapat dikonfigurasi dan ini menyelesaikan masalah terkait proyek/repositori Dokku, sehingga masalah itu juga ditutup.

Mungkin masih ada masalah terkait Docker yang luar biasa (Yaitu Mengapa Docker tidak menangani cache lapisan bawaan seperti yang saya harapkan dalam masalah https://github.com/aspnet/aspnet-docker/issues/59), tetapi Saya belum sempat mencari tahu mengapa demikian dan memastikan apakah itu masih terjadi. Jika masih menjadi masalah, maka masalah baru untuk proyek/repositori ini harus diangkat untuk itu karena berbeda dari masalah saat ini.

@yngndrw tepatnya, jadi kami setuju ini berbeda dan dikenal @docker.com jadi saya membukanya kembali jika Anda tidak keberatan ... yah saya tidak bisa. Apakah Anda keberatan?
Saya ingin melihat beberapa komentar dari rekan-rekan kami di SF setidaknya sebelum kami menutupnya

BTW saya diminta oleh @cpuguy83 untuk membuka kasus pengguna dan menjelaskan semuanya, dari log #3156

@zrml Saya tidak yakin saya mengikuti - Apakah https://github.com/aspnet/aspnet-docker/issues/59 yang ingin Anda buka kembali? Ini bukan masalah /aspnet/aspnet-docker jadi saya rasa tidak benar untuk membuka kembali masalah itu. Ini harus benar-benar menjadi masalah baru di /docker/docker, tetapi perlu diverifikasi dan perlu menghasilkan langkah-langkah yang dapat diproduksi ulang terlebih dahulu.

tidak, tidak.. ini #14080 yang kamu tutup kemarin.

Masalah ini masih terbuka?

@yngndrw Saya yakin saya salah membaca ikon "tertutup" merah. Permintaan maaf.

Setuju sekali bahwa build time -v akan sangat membantu.

Membangun caching adalah salah satu kasus penggunaan.

Kasus penggunaan lain adalah menggunakan kunci ssh pada waktu pembuatan untuk membangun dari repo pribadi tanpa disimpan di lapisan, menghilangkan kebutuhan akan peretasan (meskipun direkayasa dengan baik) seperti ini: https://github.com/dockito/vault

Saya berkomentar di sini karena ini adalah neraka di dunia korporat.
Kami memiliki proxy penyadapan SSL, sementara saya dapat mengarahkan lalu lintas melaluinya, banyak proyek menganggap mereka memiliki koneksi SSL yang baik, sehingga mereka mati dengan mengerikan.

Meskipun mesin saya (dan dengan demikian pembuat buruh pelabuhan) mempercayai proxy, gambar buruh pelabuhan tidak.
Praktik terbaik yang masih terburuk sekarang adalah menggunakan curl di dalam wadah, jadi itu menyakitkan, saya harus memodifikasi Dockerfiles untuk membuatnya bahkan membangun. Saya dapat memasang sertifikat dengan opsi -v, dan senang.

Ini dikatakan. Ini bukan kesalahan buruh pelabuhan, lebih banyak kesalahan manajer paket yang menggunakan https ketika mereka seharusnya menggunakan sistem yang mirip dengan cara kerja apt-get. Karena itu masih aman dan dapat diverifikasi, dan juga dapat di-cache oleh proxy http.

@btrepp terima kasih atas kasus penggunaan bagus lainnya.

Saya bisa memikirkan situasi lain.

Salah satu hal yang ingin saya lakukan dengan file docker saya adalah tidak mengirimkan alat build dengan file docker "terkompilasi". Tidak ada alasan aplikasi C membutuhkan gcc, atau aplikasi Ruby membutuhkan bundler dalam gambar, tetapi menggunakan docker build saat ini sementara memiliki ini.

Ide yang saya miliki adalah menentukan dockerfile, yang menjalankan beberapa perintah buruh pelabuhan saat membangun di dalamnya. Dockerfile Psuedo-ish di bawah ini.

File Docker yang membangun orang lain

FROM dockerbuilder
RUN docker build -t docker/builder myapp/builder/Dockerfile
RUN docker run -v /app:/app builder
RUN docker build -t btrepp/myapplication myapp/Dockerfile

btrepp/myapplication dockerfile

FROM debian:jessie+sayrubyruntime
ADD . /app //(this is code thats been build using the builder dockerfile
ENTRYPOINT ["rails s"]

Di sini kami memiliki wadah sementara yang melakukan semua pemasangan bundling/manajemen paket dan skrip build apa pun, tetapi menghasilkan file yang dibutuhkan wadah runtime.

Wadah runtime kemudian hanya menambahkan hasil ini, yang berarti seharusnya tidak membutuhkan lebih dari Ruby yang diinstal. Dalam kasus katakanlah GCC atau bahkan go yang lebih baik terhubung secara statis, kita mungkin tidak memerlukan apa pun selain file OS inti untuk dijalankan.

Itu akan membuat gambar buruh pelabuhan super ringan.

Masalah di sini adalah bahwa wadah pembangun sementara akan hilang pada akhirnya, yang berarti akan sangat mahal tanpa kemampuan untuk memuat semacam cache, kami akan menggunakan debian:jessie berkali-kali.

Saya telah melihat orang-orang menggunakan teknik tertentu seperti ini, tetapi menggunakan server http eksternal untuk menambahkan file build. Saya lebih suka menyimpan semuanya dibangun oleh buruh pelabuhan. Meskipun mungkin ada cara menggunakan gambar buruh pelabuhan untuk melakukan ini dengan benar. Menggunakan run dan dengan demikian dapat memasang volume.

Berikut adalah contoh lain. Katakanlah saya ingin membuat wadah untuk systemtap yang memiliki semua simbol debug untuk kernel di dalamnya (yang adalah Yuuge). Saya harus memasang /lib/modules yang mendasarinya sehingga perintah yum tahu RPM mana yang harus diinstal.

Selain itu, mungkin saya lebih suka ini hidup di tempat lain selain di gambar 1,5GB (dari simbol debug)

Saya pergi untuk menulis Dockerfile, kemudian menyadari itu tidak mungkin :-(

docker run --privileged -v /lib/modules:/lib/modules --tty=true --interactive=true rhel7/rhel-tools /bin/bash
yum --enablerepo=rhel-7-server-debug-rpms install kernel-debuginfo-$(uname -r) kernel-devel-$(uname -r)
docker ps -a
CONTAINER ID        IMAGE                     COMMAND             CREATED             STATUS                        PORTS               NAMES
52dac30dc495        rhel7/rhel-tools:latest   "/bin/bash"         34 minutes ago      Exited (0) 15 minutes ago                         dreamy_thompson
docker commit dreamy_thompson stap:latest

https://access.redhat.com/solutions/1420883

Saya ingin mengulangi kasus penggunaan saya di sini dari #3949 karena bug itu telah ditutup karena alasan lain.

Saya benar-benar ingin mengamplas perangkat lunak berpemilik di buruh pelabuhan. Adalah ilegal bagi saya untuk meng-host-nya di mana saja, dan proses pengunduhan tidak secara realistis (atau legal) dapat diotomatisasi. Secara total, penginstal mencapai sekitar 22GB (dan semakin besar dengan setiap rilis). Saya pikir konyol untuk mengharapkan bahwa ini harus disalin ke dalam gambar buruh pelabuhan pada waktu pembuatan.

Adakah berita dalam fitur yang dibutuhkan ini?
Terima kasih

_POLONGAN PENGGUNA_

_Cara terbaik untuk mendapatkan notifikasi jika ada perubahan dalam diskusi ini adalah dengan mengklik tombol Subscribe di kanan atas._

Orang-orang yang tercantum di bawah ini menghargai diskusi bermakna Anda dengan +1 acak:

@vad

+1 untuk fitur ini!

Kasus penggunaan lain adalah menggunakan kunci ssh pada waktu pembuatan untuk membangun dari repo pribadi tanpa disimpan di lapisan, menghilangkan kebutuhan akan peretasan (meskipun direkayasa dengan baik) seperti ini: https://github.com/dockito/vault

Ini adalah usecase kami juga (kunci ssh dirender menggunakan tmpfs pada Host dalam kasus ini).

Kasus penggunaan lain untuk ini adalah untuk cache lokal dari direktori node_modules pada server CI untuk mengurangi waktu pembuatan.
npm install sangat lambat dan bahkan dalam kasus "terbaik" saat ini di mana package.json adalah ADD ed ke gambar, npm install dijalankan dan hanya kemudian sumber proyek yang sebenarnya ditambahkan dan dibangun berdasarkan perubahan pada package.json semua dependensi harus diunduh ulang lagi.

Lihat npm/npm#8836 untuk masalah tentang ini di sisi Node/npm.

Masalah aspnet-docker terkait mengenai pemulihan paket yang lambat dan ukuran gambar yang dihasilkan dari caching paket saat ini di lapisan. Akan jauh lebih baik menggunakan volume terpasang untuk caching paket.
https://github.com/aspnet/aspnet-docker/issues/123

Ini bukan masalah khusus bahasa, ini akan mempengaruhi banyak orang mengingat manajer paket sekarang menjadi standar yang diterima.

OP telah mengatasi masalah di kepala, dalam "docker build -v" itu akan sangat membantu memisahkan proses build dari lingkungan runtime.

Saya telah melihat beberapa proyek yang sekarang membangun "Mulberry harbours" yang kemudian digunakan untuk membangun buruh pelabuhan yang sebenarnya yang kemudian didorong/didistribusikan. Ini terlalu rumit dari perspektif administrasi dan sumber daya komputasi, yang pada gilirannya menghasilkan CI dan pengujian unit yang lebih lambat, dan secara keseluruhan alur kerja pengembangan yang kurang produktif.

Saya telah memikirkan hal ini, dan opsi lain yang dapat saya pikirkan adalah kemampuan untuk menandai lapisan sebagai lapisan "src".

Sesuatu di sepanjang garis lapisan-lapisan itu hanya dapat diakses selama pembuatan buruh pelabuhan, tetapi tidak menarik file gambar yang dihasilkan.

Dengan cara ini buruh pelabuhan dapat men-cache lapisan/gambar sebelumnya, artefak build sementara, tetapi ini tidak diperlukan untuk memanfaatkan gambar akhir.

Misalnya.

FROM ubuntu
RUN apt-get install gcc
ADDPRIVATE . /tmp/src <--these can be cached by docker locally
RUNPRIVATE make     <-- basically these layers become scoped to the current build process/dockerfile
RUN make install <--result of this layer is required.

Tentu saja ini berarti Anda perlu mengetahui apa yang Anda lakukan dengan lebih baik, karena Anda dapat mengabaikan file penting.

@yngndrw
Solusi yang jauh lebih baik untuk situasi seperti netcore adalah bagi mereka untuk tidak menggunakan HTTPS untuk manajemen paket, maka sepele untuk mengatur iptables+squid untuk memiliki proxy caching transparan untuk build buruh pelabuhan. Pendapat pribadi saya adalah bahwa manajer paket ini harus meningkatkan game, mereka mengerikan untuk digunakan di lingkungan perusahaan karena ssl mengundurkan diri, sedangkan hal-hal seperti apt-get berfungsi dengan baik dan sudah dapat di-cache dengan iptables+squid untuk buruh pelabuhan.

Saya juga dapat melihat kerugian menggunakan volume waktu pembuatan, file docker tidak akan dapat direproduksi, dan itu akan memerlukan pengaturan tambahan di luar docker build -t btrepp/myapp ., Ini juga akan membuat pembuatan otomatis di dockerhub menjadi sulit.

@btrepp : Saya suka saran Anda. Saya bahkan bisa hidup untuk kasus penggunaan saya dengan hardcoded (saya tahu itu umumnya hal yang buruk) dir TMP yang Docker beri tahu kami sehingga mereka tahu kapan mereka membangun artefak terakhir dari semua lapisan yang bisa mereka lupakan/tinggalkan yang satu dipasang di /this_is_the_tmp_explosion_folder_that_will_be_removed_from_your_final_container_image
cukup mudah....

@btrepp Saya sangat menyukai ide lapisan sumber Anda.

Namun mengenai manajer paket yang tidak menggunakan SSL, saya harus tidak setuju.

Jika Anda ingin men-cache paket seperti itu, maka Anda mungkin harus menggunakan feed paket pribadi (Lokal) yang mencerminkan sumber resmi. Mengembalikan ke HTTP sepertinya ide yang buruk bagi saya, terutama mengingat banyak manajer paket tampaknya tidak menandatangani paket mereka dan karena itu mengandalkan HTTPS.

Ada alat tata bahasa/rocker yang dapat digunakan saat masalah ini belum diperbaiki.

@yngndrw

Maksud saya menjadi proxy lokal dll adalah masalah yang sudah lama terpecahkan. Manajer paket hanya perlu verifikasi, mereka tidak membutuhkan privasi. Menggunakan https adalah cara malas untuk memberikan verifikasi, tetapi disertai dengan lampiran privasi.

Tidak ada alasan "super_awesome_ruby_lib" harus bersifat pribadi saat ditarik melalui http. Cara yang lebih baik adalah agar permata ruby ​​​​memiliki gantungan kunci. Atau bahkan kunci publik yang dikenal, dan untuk menandatangani paket. Kurang lebih begini cara kerja apt-get, dan memungkinkan proksi http standar untuk men-cache sesuatu.

Mengenai feed paket pribadi lokal, buruh pelabuhan bahkan tidak mendukung ini dengan baik. Tidak ada cara untuk menonaktifkan umpan standar, dan itu _benar_ kehilangannya jika sertifikat https tidak ada di toko sertifikat. Saya cukup yakin buruh pelabuhan selalu ingin setidaknya memeriksa umpan utama saat menarik gambar juga. Afaik implementasi roket/rkt akan menggunakan penandatanganan+http untuk mendapatkan gambar kontainer.

Jika motivasi utama untuk volume waktu pembuatan hanyalah cache-ing paket, maka saya pikir tekanan harus diberikan pada manajer paket untuk lebih mendukung cache, daripada mengorbankan beberapa otomatis/kemurnian buruh pelabuhan saat ini.

Untuk lebih jelasnya, saya tidak menganjurkan manajer paket untuk beralih hanya menggunakan http dan menghapus https. Mereka memang membutuhkan verifikasi paket untuk mencegah serangan man in the middle. Apa yang tidak mereka butuhkan adalah aspek privasi menggunakan https sebagai penawaran "keamanan menangkap semua palu godam".

Itu pandangan yang sangat sempit. Anda meminta seluruh manajer paket untuk mengubah cara mereka berperilaku agar sesuai dengan resep Docker tentang bagaimana menurut mereka aplikasi akan dibangun.

Ada juga banyak contoh lain mengapa ini diperlukan di utas ini. Mengatakan "baik, Anda harus mengubah cara semua alat yang Anda gunakan untuk membangun aplikasi Anda bekerja" tidak menghilangkan masalah, itu hanya akan mengusir pengguna.

(Saya juga sangat tidak setuju dengan lampiran Docker ke registri publik -- Saya lebih suka melarang akses ke registri publik, dan hanya mengizinkan yang internal kami untuk digunakan. Tapi itu topik yang sama sekali berbeda.)

Bagi saya, saya juga membutuhkan docker build -v .

Dalam kasus kami, kami ingin membuat gambar yang terdiri dari instalasi pra-konfigurasi dari produk yang bersangkutan, dan penginstalnya lebih dari 2GB . Tidak dapat memasang volume Host, kami tidak dapat membuat gambar dengan penginstal meskipun kami telah mengunduh di OS Host, yang untuk itu kami dapat menggunakan berbagai alat/protokol, katakanlah proxy dengan https cert/auth , atau bahkan mungkin sedikit torrent.

Sebagai solusinya, kita harus menggunakan wget untuk mengunduh ulang penginstal selama docker build , yang merupakan lingkungan yang sangat terbatas, jauh lebih tidak nyaman, lebih memakan waktu, dan rawan kesalahan.

Juga karena fleksibilitas dari opsi penginstalan/konfigurasi produk, lebih masuk akal bagi kami untuk mengirimkan gambar dengan produk yang telah dipasang sebelumnya, daripada mengirimkan gambar hanya dengan penginstal.

@thaJeztah ada kemungkinan ini terjadi?

Fwiw ini adalah satu-satunya alasan saya tidak (atau benar-benar, tidak bisa) menggunakan buruh pelabuhan

Kami membawa tambalan dalam versi buruh pelabuhan Red Hat yang menyertakan opsi -v. Tetapi solusi sebenarnya untuk ini adalah membangun cara baru dan berbeda untuk membangun OCI Container Images selain dari build buruh pelabuhan.

@rhatdan RHEL atau Fedora?

Kami juga telah mengimplementasikan opsi -v dari build docker di versi internal docker kami di resin.io. Anda dapat menemukan perbedaannya di sini https://github.com/resin-io/docker/commit/9d155107b06c7f96a8951cbbc18287eeab8f60cc

@rhatdan @petrosagg dapatkah Anda membuat PR untuk ini?

@jeremyherbert tambalan ada di daemon buruh pelabuhan yang hadir di semua versi terbaru RHEL, CentOS, dan Fedora...

@graingert Kami telah mengirimkannya di masa lalu dan telah ditolak.

@rhatdan apakah Anda memiliki tautan ke sana?

@runcom Apakah Anda memiliki tautannya?

@thaJeztah apakah ini sesuatu yang kalian akan tolak?

Berikut daftar masalah yang ada yang telah ditutup atau tidak ditanggapi:
https://github.com/docker/docker/issues/3949
https://github.com/docker/docker/issues/3156
https://github.com/docker/docker/issues/14251
https://github.com/docker/docker/issues/18603

Info tentang patch Project Atomic yang digunakan di RHEL/CentOS/Fedora dapat ditemukan di:
http://www.projectatomic.io/blog/2016/08/docker-patches/

@daveisfera sepertinya mereka hanya menambahkan volume R bukan volume RW, jadi itu tidak akan berfungsi untuk @yngndrw dan kasus penggunaan saya.

@graingert Mengapa Anda membutuhkan volume RW? Saya memahami hanya-baca sebagai solusi untuk kasus-kasus tertentu.

Menguji migrasi skema akan menjadi salah satu alasan bagus...

Pada 11/01/2016 10:36, Brian Goff menulis:

@graingert https://github.com/graingert Mengapa Anda membutuhkan volume RW?
Saya memahami hanya-baca sebagai solusi untuk kasus-kasus tertentu.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/14080#issuecomment -257582035,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAHLZdp0D6fAtuNglajPBIwnpWGq3slOks5q5050gaJpZM4FIdOc.

Scott McCarty

skot. [email protected]

http://crunchtools.com

@fatherlinux

@cpuguy83 Kasus penggunaan lain untuk RW adalah ccache

@fatherlinux Saya tidak yakin saya mengikuti. Mengapa Anda membutuhkan volume untuk ini? Juga mengapa harus dilakukan selama fase build?

Saya memiliki kasus penggunaan yang sedikit berbeda untuk fitur ini - Paket caching yang diunduh/diperbarui oleh manajer paket ASP.Net 5. Manajer paket mengelola folder cache-nya sendiri sehingga pada akhirnya saya hanya perlu folder yang dapat saya gunakan kembali di antara build.

Saya akan mengikat mount misalnya:

docker build -v /home/jenkins/pythonapp/cache/pip:/root/.cache/pip  -t pythonapp .
docker build -v /home/jenkins/scalaapp/cache/ivy2:/root/.ivy2  -t scalaapp .

Karena sering kali migrasi skema harus dilakukan ketika
perangkat lunak diinstal. Jika Anda menjalankan wadah hanya-baca, Anda harus
jangan pernah menginstal perangkat lunak kapan pun selain saat Anda berada di
fase membangun.....

Pada 11/01/2016 10:42, Brian Goff menulis:

@fatherlinux https://github.com/fatherlinux Saya tidak yakin saya mengikuti.
Mengapa Anda membutuhkan volume untuk ini? Juga mengapa harus dilakukan selama
fase membangun?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/14080#issuecomment -257583693,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAHLZfhBG8RUWtqPD-6RaLC7uoCNc-3nks5q50_TgaJpZM4FIdOc.

Scott McCarty

skot. [email protected]

http://crunchtools.com

@fatherlinux

Saya tahu bahwa isi direktori ini tidak akan menyebabkan build bergantung pada Host (kehilangan mount ini akan menyebabkan build tetap berfungsi, hanya lebih lambat)

NFS memecahkan ini seperti 30 tahun yang lalu ...

Pada 11/01/2016 10:45, Thomas Grainger menulis:

Saya tahu bahwa isi direktori ini tidak akan menghentikan pembangunan
menjadi idempoten atau bergantung pada host (kehilangan tunggangan ini akan menyebabkan
membangun untuk bekerja pula)

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/14080#issuecomment -257584576,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAHLZS75Vq0BSEvUjI2oXORsS0el2mwOks5q51CQgaJpZM4FIdOc.

Scott McCarty

skot. [email protected]

http://crunchtools.com

@fatherlinux

NFS memecahkan ini seperti 30 tahun yang lalu ...

Bukan komentar yang membantu

@graingert maaf, itu benar-benar salah. Saya mencoba untuk merespons terlalu cepat dan tidak memberikan konteks yang cukup. Secara serius, kami melihat NFS dalam kombinasi dengan CRIO untuk memecahkan beberapa jenis masalah ini.

Baik image registry maupun buld memiliki banyak kesamaan kualitas. Apa yang Anda bicarakan pada dasarnya adalah masalah caching. NFS, dan khususnya caching bawaan dapat membuat host build menjadi independen dan menangani semua caching untuk Anda.

Oleh karena itu, bahkan dengan opsi -v build time, build tidak harus dikunci hanya ke satu host. Ini mungkin tidak independen dalam skala Internet, tetapi cukup bagi banyak orang yang mengontrol lingkungan build mereka ke satu situs atau lokasi.

@fatherlinux Saya akan menggunakan gitlab atau travis caching untuk mengambil direktori cache dan mengunggah/mengunduh ke S3

@graingert ya, tapi itu hanya berfungsi pada jenis data/aplikasi tertentu, juga hanya pada level bucket yang tepat, bukan pada meta data posix dan level blok. Untuk jenis aplikasi front end dan middleware tertentu, tidak ada masalah. Untuk migrasi skema basis data, Anda agak perlu menguji sebelumnya dan memiliki cache lokal untuk kecepatan dan biasanya harus posix.

Bayangkan saya memiliki cluster MySQL Galera dengan data 1TB dan saya ingin melakukan peningkatan dan semuanya ada dalam wadah. Multi-node kemas/teratur, Galera yang di-shard sangat nyaman. Saya tidak ingin harus menguji migrasi skema secara manual selama setiap peningkatan.

Saya ingin memotret volume data (pv di dunia Kube), mengeksposnya ke server build, lalu menguji upgrade dan migrasi skema. Jika semuanya bekerja dengan benar dan tes lulus, maka kami membangun wadah produksi dan membiarkan migrasi skema terjadi dalam produksi....

@graingert maaf, lupa menambahkan, lalu membuang snapshot yang digunakan dalam uji coba... Saya tidak ingin mengatur acara pembuatan dan pengujian secara terpisah, meskipun itu mungkin...

@fatherlinux Saya pikir itu kasus penggunaan ortogonal...

@graingert bukan komentar yang berguna. Ortogonal untuk apa? Ortogonal dengan permintaan untuk -v selama pembuatan, apa yang saya pahami tentang percakapan ini?

Ada beberapa kegunaan berbeda yang saya lihat untuk bendera ini.

• cache, bagikan di antara server build docker
• kata kunci seperti ADD yang hanya berlaku 'selama pembuatan' dari satu Dockerfile. Misalnya TAMBAHKAN file besar, lalu keluarkan dari gambar.
• Kata kunci seperti ADD+RUN yang mengabaikan semua output. Misalnya TAMBAHKAN file besar, lalu JALANKAN satu langkah dan abaikan perubahan apa pun pada gambar - TAMBAHKAN+Jalankan dalam satu langkah lalu lewati satu lapisan.

Dua kasus penggunaan selanjutnya dapat diselesaikan dengan lebih rapi dengan dua kata kunci baru.

BUILDCONSTFILE <path>

Akan menjalankan COPY <path> sebelum setiap RUN, dan menghapus <path> dari gambar setelahnya.

TEST <cmd> WITH <paths>

Yang akan MENYALIN jalur, menjalankan perintah, lalu dengan 0 status keluar melanjutkan pembangunan dari gambar induk, jika tidak akan menghentikan pembangunan

Secara pribadi saya pikir TEST ... WITH lebih baik ditangani di langkah CI lain yang menguji wadah Anda secara keseluruhan

Biarkan saya mengawali dengan ini: Saya _think_ Saya setuju dengan menambahkan --mount untuk membangun ("-v" mungkin tidak terlalu banyak). Tidak 100% yakin pada implementasinya, bagaimana caching ditangani (atau tidak ditangani), dll.

Untuk proyek buruh pelabuhan yang kami lakukan adalah membangun image builder.
Ini pada dasarnya memiliki semua yang kita butuhkan, menyalin kode, tetapi tidak benar-benar membangun buruh pelabuhan.
Kami memiliki Makefile yang mengatur ini. Jadi make build membangun gambar, make binary membangun biner dengan build sebagai ketergantungan, dll.

Membuat biner menjalankan gambar build dan melakukan build, dengan ini kita dapat me-mount apa yang kita butuhkan, termasuk cache paket untuk build inkremental.
Sebagian besar dari ini cukup lurus ke depan dan mudah diatur.
Jadi tentu saja ada cara untuk menangani kasus ini hari ini, hanya buruh pelabuhan saja yang tidak dapat menangani 100% (dan itu belum tentu merupakan hal yang buruk) dan Anda harus membuat ini berfungsi dengan sistem CI Anda.

@ cpuguy83 Saya pikir ini akan menyelesaikan sebagian besar kasus penggunaan saya. Supaya saya mengerti, maksud Anda --mount berarti hanya baca? dan -v untuk dibaca/ditulis?

@ cpuguy83 kami juga kebanyakan membangun gambar "pembangun" yang IMHO menjadi pola yang semakin umum ...

@fatherlinux swarm services dan sekarang (untuk 1.13) docker run mendukung --mount yang jauh lebih tepat dan fleksibel: https://docs.docker.com/engine/reference/commandline/service_create/# /tambahkan -bind-mounts-or-volumes

Sepertinya dokumen tidak memiliki tipe pemasangan ke-3, tmpfs .

Aaah, keren sekali, terima kasih...

Pada 11/01/2016 14:20, Brian Goff menulis:

@fatherlinux https://github.com/fatherlinux swarm services dan sekarang
(untuk 1.13) |docker run| mendukung |--mount| yang jauh lebih tepat
dan fleksibel:
https://docs.docker.com/engine/reference/commandline/service_create/#/add -bind-mounts-or-volumes

Sepertinya dokumen tidak memiliki tipe mount ke-3, |tmpfs|.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/14080#issuecomment -257648598,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAHLZXv_VBfVi4WUAjVijE-SKR0ErRC4ks5q54L2gaJpZM4FIdOc.

Scott McCarty

skot. [email protected]

http://crunchtools.com

@fatherlinux

@ cpuguy83 kami juga sering menggunakan pola pembangun dan kami membutuhkan caching yang tidak bertahan dalam gambar dan juga bertahan dari pembatalan lapisan.

Kami membuat gambar Yocto dan kami memiliki cache status bersama di penyimpanan NFS. Kasus penggunaan lainnya adalah cache npm sehingga Anda dapat membatalkan seluruh lapisan RUN npm install tetapi menghitung ulang lebih cepat karena paket yang di-cache.

Sebagai kemungkinan kompromi berdasarkan posting @graingert , dapatkah seseorang tidak memiliki hash opsional dari file besar Anda di dockerfile, dan kemudian buruh pelabuhan memeriksa ini saat menjalankan build? Tidak akan ada masalah dengan build deterministik saat itu, dan akan jelas bagi orang yang membangun bahwa mereka tidak memiliki dependensi yang diperlukan, daripada hanya meledak dengan kesalahan aneh di beberapa titik. Hal yang sama berlaku untuk kunci ssh, dll yang tetap perlu didistribusikan dengan dockerfile.

Saya juga berpikir bahwa ide apa pun yang memerlukan _menyalin_ file besar kurang ideal. Ukuran file yang ingin saya gunakan berada di urutan 10-40GB, dan bahkan dengan SSD yang bagus itu setidaknya satu atau dua menit untuk disalin. Ini adalah masalah saya dengan arahan ADD yang sudah ada di buruh pelabuhan; Saya tidak ingin MENAMBAHKAN 30GB ke gambar saya setiap kali dibuat dan harus berurusan dengan memiliki semua ruang kosong ekstra itu, serta perlu memencet gambar.

Itu tidak akan berhasil untuk apa kami menggunakan ini. Kami memiliki volume yang berisi cache status dari sistem build yocto yang terpasang RW dalam build karena cache yang hilang akan dihitung selama build dan disimpan dalam status untuk yang akan datang. Direktori kami juga berada di ~30GB sehingga menghitung hash akan memakan waktu cukup lama.

Saya tidak pernah mengerti konsep membangun deterministik. Ada cara untuk menembak diri sendiri bahkan dengan semantik hari ini. Misalnya Anda dapat curl sesuatu dari IP internal. Tiba-tiba Dockerfile ini tidak berfungsi di mana-mana dan bergantung pada host. Tapi ada kasus yang sah mengapa Anda ingin melakukan itu. Misalnya cache HTTP lokal.

Jadi karena build tidak deterministik, dan karena seseorang dapat meniru volume yang dipasang-terikat melalui jaringan hari ini, mengapa tidak menyediakan cara asli untuk melakukannya dengan peringatan yang sesuai jika perlu?

@petrosagg @zrml @thaJeztah Yang kami tahu adalah:

• Jika kita menelusuri melalui #7115 #3156 kita dapat menemukan daftar panjang masalah yang sudah bertahun-tahun membahas masalah yang sama ini
• Sebagian besar ditutup dengan alasan kemampuan reproduksi (atau komentar Dockerfile syntax is frozen lama, dan kemudian setelah instruksi HEALTHCHECK ditambahkan, pembekuan dihapus tetapi masalah tetap ditutup)
• Masalah ini telah menghentikan banyak tim dari memiliki kegunaan/produktivitas wadah yang baik dalam pengembangan harian selama bertahun-tahun. Seperti yang dikatakan @btrepp , ini neraka
• Orang-orang Docker mengetahui masalah ini, tetapi ini akan membuat kelas Oh my docker build rusak! masalah karena cache bersama yang tidak bagus
• Tetapi pindah dari cache Disk ke cache Jaringan tampaknya tidak meningkatkan keandalan build dengan cara apa pun, bertindak hanya sebagai cache-over-http yang dimuliakan, dan ternyata memperburuk keadaan (mengunduh internet untuk setiap build, HTTPS, ukuran file, disk thrashing saat membuat container, cache layer, orkestrasi build yang rumit, dll)

Mengingat semua yang kita ketahui, saya pikir ini kemungkinan akan ditutup sebagai Dupe atau WontFix. Tampaknya tidak masalah kasus penggunaan apa yang kami berikan. Pembaruan: Saya senang salah di sini. Proposal terlihat terbuka :)

Perusahaan kami pindah ke runtime container agnostik, dan akan segera beralih ke pengalaman membangun citra agnostik juga. Tapi ini bukan tempat yang tepat untuk membahas itu karena hal-hal negatif tidak membantu. Itu harus menjadi posting terpisah.

@rdsubhas peduli untuk membagikan tautan setelah Anda selesai?

@rdsubhas itu ringkasan yang bagus. Sepertinya utas ini tidak akan ditutup sebagai penipuan/perbaikan karena @cpuguy83 menganggap dia baik-baik saja dengan menambahkan --mount selama pembuatan yang mencakup sebagian besar kasus penggunaan.

Yang ingin saya ketahui adalah bahwa proposal saat ini:

1. tidak mengubah sintaks Dockerfile
2. tidak membuat build lebih bergantung pada host daripada saat ini

Manakah argumen kontra yang tersisa mengenai gagasan tersebut? Jika tidak ada mungkin sebaiknya kita mulai membahas detail implementasi untuk mekanisme --mount .

Untuk menegakkan kembali argumen bahwa build sudah bergantung pada host dan tidak dapat direproduksi, saya memberikan daftar fragmen Dockerfile dengan properti ini:

# Install different software depending on the kernel version of the host
RUN wget http://example.com/$(uname -r)/some_resource

# example.intranet is only accessible from specific hosts
RUN wget http://example.intranet/some_resource

# get something from localhost
RUN wget http://localhost/some_resource

# gcc will enable optimizations supported by the host's CPU
RUN gcc -march=native .....

# node:latest changes as time goes by
FROM node

# ubuntu package lists change as time goes by
RUN apt-get update

# install different software depending on the docker storage driver
RUN if [ $(mount | head -n 1 | awk '{print $5}') == "zfs" ]; then .....; fi

Sejujurnya, jika kita hanya menambahkan --mount dan membiarkan pengguna menangani pembatalan cache ( --no-cache ), saya pikir kita akan baik-baik saja. Kami mungkin ingin melihat kontrol cache yang lebih halus dari CLI daripada semua atau tidak sama sekali, tapi itu topik yang terpisah.

Kasus Penggunaan Saya

Saya telah menghadapi masalah serupa untuk sementara waktu sekarang, tetapi saya telah memilih untuk menggunakan ukuran gambar yang lebih besar sampai solusi diselesaikan. Saya akan mencoba menggambarkan skenario saya di sini jika seseorang menemukan solusi yang lebih baik.

Kondisi

1. CircleCI memiliki kunci ssh untuk mengunduh semua dependensi internal selama pembuatan
2. GitHub menghosting dependensi internal dan yang lainnya dapat diunduh dari dalam gambar selama pembuatan

Pilihan

1. Gunakan --build-arg untuk meneruskan token selama pembuatan (sangat tidak disarankan). Ini adalah opsi yang sangat menarik dan mudah karena "hanya berfungsi" tanpa langkah tambahan apa pun.
2. Unduh semua dependensi dan tambahkan ke konteks build. Sayangnya, ADD dan COPY dieksekusi di lapisan terpisah jadi saya terjebak dengan data dari lapisan sebelumnya.

Ukuran beberapa gambar saya lebih dari dua kali lipat dalam beberapa kasus, tetapi ukuran keseluruhan dapat ditoleransi untuk saat ini. Saya pikir ada PR (sepertinya saya tidak dapat menemukannya) untuk menghapus argumen waktu build dari riwayat build, tetapi itu tidak dapat diterima karena masalah caching irrc.
Saya akan senang mendengar solusi lain yang digunakan di luar sana.

@misakwa kami kemungkinan akan mendukung rahasia di build in 1.14.

Sangat menyenangkan mendengar @cpuguy83. Saya akan mengawasi ketika dirilis. Ini pasti akan menyederhanakan beberapa alur kerja saya.

kami kemungkinan akan mendukung rahasia pada build in 1.14.

Apakah ini juga berfungsi untuk memetakan pemetaan waktu pembuatan dari jenis volume lain seperti misalnya yarn-cache ?

BTW ada cara yang menarik untuk membangun gambar produksi menggunakan docker-compose, saya merasa itu berfungsi dan cukup efektif:

Jadi Anda telah menulis file docker-compose.build.yml sesuatu seperti ini:

services: 
  my-app:
    image: mhart/alpine-node:7.1.0
    container_name: my-app-build-container # to have fixed name
    volumes:
    - ${YARN_CACHE}:/root/.cache/yarn # attach yarn cache from host
    - ${HOME}/.ssh:/.ssh:ro    # attach secrets
    - ./:/source
    environment: # set any vars you need
     TEST_VAR: "some value"    
    ports:
    - "3000"
    working_dir: /app/my-app # set needed correct working dir even if if doesn't exist in container while build type
    command: sh /source/my-app.docker.build.sh # build script

1) Anda membuat wadah menggunakan komposisi buruh pelabuhan:

$ docker-compose -f docker-compose.build.yml up --force-recreate my-app

itu membuat wadah dan menjalankan skrip build Shell my-app.docker.build.sh , saya tidak menggunakan Dockerfile dan melakukan semuanya dalam skrip build:

• instal paket os yang dibutuhkan
• salin kode sumber yang diperlukan (dari folder /source yang dipetakan)
• instal dependensi
• membangun/mengkompilasi/menguji jika diperlukan
• hapus paket dan hal-hal yang tidak diperlukan agar target env berfungsi (untuk mengurangi ukuran gambar akhir)

Kemudian Anda membuat gambar dari wadah, menggantikan CMD yang perlu dijalankan di target env:

docker commit -c "CMD npm run serve" my-app-build-container my-app-build-image:tag

Jadi gambar Anda sudah siap, gunakan cache benang eksternal dan kunci rahasia eksternal yang hanya tersedia saat waktu pembuatan.

@whitecolor ya itu berfungsi :) kecuali untuk satu hal: docker build sangat efektif dalam mengunggah konteks build. Sayangnya, volume sumber yang dipasang tidak berfungsi dengan daemon buruh pelabuhan jarak jauh (misalnya mesin buruh pelabuhan di cloud untuk laptop berdaya rendah/bandwidth). Untuk itu kita harus melakukan docker run , docker cp , docker run , dll serangkaian perintah buruh pelabuhan dan kemudian memotret gambar akhir, tetapi itu benar-benar hacky.

Sangat membantu untuk memiliki bagian resmi dari build buruh pelabuhan ini, dan menggunakan layering dan membangun konteks

@rdsubhas Ya, Anda benar

@whitecolor Itu adalah solusi yang sangat sederhana dan efektif. Saya baru saja mengurangi 30-40 menit membangun sebuah proyek menjadi sekitar 5 menit. Saya menantikan kemungkinan memiliki --mount pada fitur build tetapi untuk saat ini solusi ini benar-benar membuka blokir saluran saya.

Ini adalah komentar yang saya tinggalkan untuk edisi #17745 yang saya pahami telah ditutup tetapi tidak ditandai sebagai duplikat. Sepertinya saya salah tentang poin terakhir itu: Saya akui saya terbiasa dengan sistem seperti Bugzilla yang secara eksplisit menandai sesuatu sebagai "DUPLIKAT TERSELESAIKAN", dan menampilkannya di area deskripsi teratas bug. Saya bukan pembaca pikiran. (Jadi saya minta maaf @graingert , saya tidak tahu banyak, jadi tidak perlu meneriaki saya dengan font 20pt -- itu berlebihan.)

Dalam kasus saya, di mana ini akan berguna pada sistem Debian: memasang /var/cache/apt sebagai volume, jadi Anda tidak mengunduh ulang file .deb yang sama berulang kali. (Benar-benar kuota Internet "tidak terbatas" tidak ada, terutama di Australia, dan bahkan jika ada, ada waktu yang terbuang untuk menunggu unduhan.)

Atau skenario lain, Anda sedang melakukan pembangunan, tetapi juga menghasilkan laporan pengujian seperti daftar kegagalan dan laporan cakupan kode yang tidak perlu Anda kirimkan bersama gambar, tetapi merupakan artefak yang berguna untuk dimiliki. Ini dapat ditulis ke volume ketika server CI pergi untuk membangun gambar untuk diambil dan dihosting oleh server CI.

Atau malam ini, saya sedang melakukan beberapa gambar berbasis Gentoo untuk diri saya sendiri, saya ingin me-mount /usr/portage dari host. Tidak sulit bagi Dockerfile untuk menyadari, "hei, /usr/portage (dalam wadah) kosong, tidak masalah, saya akan mengambilnya" ketika berjalan tanpa volume terpasang, ATAU, itu hanya menggunakan volume apa adanya, menghemat waktu mengambil salinan baru.

Menambahkan kecerdasan itu adalah pernyataan if yang sepele dalam skrip Bourne shell… JIKA logika yang mendasari untuk memasang volume ada di tempat pertama. Saat ini untuk gambar Gentoo saya, saya harus menarik /usr/portage setiap kali saya melakukan build (untungnya mirror ada di LAN saya) yang berarti perlu beberapa menit untuk menunggu satu langkah itu selesai.

Begitu banyak alasan mengapa ini adalah proposal yang berharga, dan saya ragu bahwa build bersarang yang diusulkan di #7115 akan membantu dalam kasus di atas.

@whitecolor memiliki pendekatan yang menarik, tetapi jika melakukan itu, saya mungkin juga menggunakan Makefile sepenuhnya di luar sistem Docker untuk mencapai build.

@sjlongland Saya tidak meneriaki Anda, saya mengisi pemberitahuan "DUPLIKAT TERSELESAIKAN" besar

Saya menggunakan docker dan docker-compose untuk membangun beberapa wadah untuk infrastruktur kami. Wadahnya adalah layanan mikro, sebagian besar ditulis dalam nodeJS, tetapi ada satu layanan mikro yang digunakan di Java, menggunakan kerangka kerja pakar.
Setiap kali kita membangun kembali wadah Java, puluhan dependensi diunduh dari Maven; ini membutuhkan waktu beberapa menit. Kemudian kode dibuat dalam waktu sekitar 15 detik.

Ini sangat buruk dan berdampak pada strategi CI kami cukup keras.

Dalam skenario ini, tidak masalah jika volume dengan dependensi build hilang atau kosong, karena dalam hal ini dependensi akan diunduh. Reproduksi tidak terpengaruh.

Saya mengerti bahwa ada masalah keamanan, karena saya bisa mengutak-atik dependensi dan menyuntikkan kode jahat di sana; IMHO yang dapat dengan mudah dielakkan dengan tidak mengizinkan gambar dibuat dengan "volume build" untuk diterbitkan di docker-hub atau docker-store.
Untuk mengeja ini secara berbeda, harus ada perbedaan cakupan antara penggunaan perusahaan dan penggunaan pribadi buruh pelabuhan.

@stepps lihat https://pypi.python.org/pypi/shipwright alih-alih docker-compose

Saya telah mengikuti utas ini untuk sementara waktu, mencari solusi yang baik untuk diri saya sendiri. Untuk membangun wadah minimal dengan cara yang fleksibel dengan sedikit usaha, saya sangat suka https://github.com/edannenberg/gentoo-bb oleh @edannenberg.

• Ini memisahkan dependensi build-time dari dependensi run-time
• Pembuatan dilakukan dalam wadah dan diisolasi, bersih, dan dapat diulang
• Menangani dependensi antara gambar dan membangun pemesanan

Ini didasarkan pada penggunaan portage Gentoo dan emerge, jadi @sjlongland Anda mungkin menyukainya untuk gambar berbasis Gentoo Anda. File dist dan paket biner di-cache, jadi tidak perlu mengunduh atau membangunnya lagi untuk membuat pembangunan kembali dengan cepat. Ini memiliki kait untuk menyesuaikan proses pembuatan dengan mudah. Menginstal perangkat lunak pihak ke-3 itu mudah, seperti menggunakan git untuk mengkloning repo dan kemudian membangunnya, hanya menyimpan build di gambar akhir. Ini template Dockerfile.

Contoh sederhananya adalah untuk figlet adalah: -

build.conf:

IMAGE_PARENT="gentoobb/glibc"

Dockerfile.template:

FROM ${IMAGE_PARENT}
ADD rootfs.tar /
USER figlet
CMD ["gentoo-bb"]
ENTRYPOINT ["figlet"]

build.sh

PACKAGES="app-misc/figlet"

configure_rootfs_build() {
        useradd figlet
}

Saya suka solusi @whitecolor sederhana hanya menggunakan teknologi Docker dan kemudian skrip shell sederhana atau apa pun yang ingin Anda gunakan. Saya menggunakan gentoo-bb karena lebih lengkap. Shipwright terlihat bagus dengan lebih banyak fitur yang berfokus pada pengembang seperti berurusan dengan cabang. https://github.com/grammarly/rocker juga tampaknya menarik. Terima kasih telah berbagi semuanya.

Hanya suara lain yang ditambahkan ke tumpukan. Lingkungan dev kami yang sangat kompleks akan jauh lebih sederhana jika kami dapat memasang volume lokal di build.

Solusinya adalah dengan dijalankan selama membangun server http yang mengekspos file lokal dan kemudian menggunakan curl/wget dll. untuk memasukkan file ke dalam build buruh pelabuhan. Tapi saya benar-benar berharap peretasan seperti itu tidak diperlukan.

Kasus penggunaan lain .. Saya ingin membuat gambar buruh pelabuhan untuk membangun OS berpemilik yang sebagai 10-an dari versi yang berbeda. Media instal> 80GB, jadi saya tidak bisa hanya menyalin ini ke lingkungan build buruh pelabuhan. Binding mount akan jauh lebih disukai.

Satu lagi: penggunaan proyek saya mendistribusikan Dockerfiles di repositori untuk membangun dari sumber dalam wadah. Saat ini, kami menarik klon git lain dalam wadah dari github. Ada klon dangkal dan sebagainya, tapi tetap saja...

Jadi, saya baru saja menguji [1] pada host build rhel7, dan build Red Hat dari daemon docker TIDAK memiliki opsi -v untuk build. Saya belum menguji pada CentOS/Fedora, tetapi orang akan membayangkan Fedora/CentOS mungkin memilikinya juga. Ini layak untuk diuji. Juga, langganan Pengembang RHEL sekarang gratis [2]:

@fatherlinux Di bawah Fedora `docker build -v' juga tersedia.

@fatherlinux Versi CentOS 7 menyertakannya.

+1 Saya pikir ini akan menjadi fitur yang sangat berguna untuk ditambahkan ke buruh pelabuhan resmi.

Baru saja diperbarui pada centos dan linuxmint (sekarang menjalankan 17.03.1-ce), Apakah saya melewatkan sesuatu di sini? Saya tidak dapat melihat opsi -v

Pada mint

$ docker build --help

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile

Options:
      --build-arg list             Set build-time variables (default [])
      --cache-from stringSlice     Images to consider as cache sources
      --cgroup-parent string       Optional parent cgroup for the container
      --compress                   Compress the build context using gzip
      --cpu-period int             Limit the CPU CFS (Completely Fair Scheduler) period
      --cpu-quota int              Limit the CPU CFS (Completely Fair Scheduler) quota
  -c, --cpu-shares int             CPU shares (relative weight)
      --cpuset-cpus string         CPUs in which to allow execution (0-3, 0,1)
      --cpuset-mems string         MEMs in which to allow execution (0-3, 0,1)
      --disable-content-trust      Skip image verification (default true)
  -f, --file string                Name of the Dockerfile (Default is 'PATH/Dockerfile')
      --force-rm                   Always remove intermediate containers
      --help                       Print usage
      --isolation string           Container isolation technology
      --label list                 Set metadata for an image (default [])
  -m, --memory string              Memory limit
      --memory-swap string         Swap limit equal to memory plus swap: '-1' to enable unlimited swap
      --network string             Set the networking mode for the RUN instructions during build (default "default")
      --no-cache                   Do not use cache when building the image
      --pull                       Always attempt to pull a newer version of the image
  -q, --quiet                      Suppress the build output and print image ID on success
      --rm                         Remove intermediate containers after a successful build (default true)
      --security-opt stringSlice   Security options
      --shm-size string            Size of /dev/shm, default value is 64MB
  -t, --tag list                   Name and optionally a tag in the 'name:tag' format (default [])
      --ulimit ulimit              Ulimit options (default [])
$ cat /etc/lsb-release 
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=18
DISTRIB_CODENAME=sarah
DISTRIB_DESCRIPTION="Linux Mint 18 Sarah"
$ docker version
Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Fri Mar 24 00:45:26 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.1-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Fri Mar 24 00:45:26 2017
 OS/Arch:      linux/amd64
 Experimental: false

Pada centos 7

# docker build --help

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile

Options:
      --build-arg list             Set build-time variables (default [])
      --cache-from stringSlice     Images to consider as cache sources
      --cgroup-parent string       Optional parent cgroup for the container
      --compress                   Compress the build context using gzip
      --cpu-period int             Limit the CPU CFS (Completely Fair Scheduler) period
      --cpu-quota int              Limit the CPU CFS (Completely Fair Scheduler) quota
  -c, --cpu-shares int             CPU shares (relative weight)
      --cpuset-cpus string         CPUs in which to allow execution (0-3, 0,1)
      --cpuset-mems string         MEMs in which to allow execution (0-3, 0,1)
      --disable-content-trust      Skip image verification (default true)
  -f, --file string                Name of the Dockerfile (Default is 'PATH/Dockerfile')
      --force-rm                   Always remove intermediate containers
      --help                       Print usage
      --isolation string           Container isolation technology
      --label list                 Set metadata for an image (default [])
  -m, --memory string              Memory limit
      --memory-swap string         Swap limit equal to memory plus swap: '-1' to enable unlimited swap
      --network string             Set the networking mode for the RUN instructions during build (default "default")
      --no-cache                   Do not use cache when building the image
      --pull                       Always attempt to pull a newer version of the image
  -q, --quiet                      Suppress the build output and print image ID on success
      --rm                         Remove intermediate containers after a successful build (default true)
      --security-opt stringSlice   Security options
      --shm-size string            Size of /dev/shm, default value is 64MB
  -t, --tag list                   Name and optionally a tag in the 'name:tag' format (default [])
      --ulimit ulimit              Ulimit options (default [])
# docker version
Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Mon Mar 27 17:05:44 2017
 OS/Arch:      linux/amd64
# cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core) 

@wilfriedroset Di CentOS 7, paket Docker non-resmi menyediakan opsi. Saya pikir ini adalah bagian dari repositori EPEL.

terima kasih @nathanjackson. Apakah kami memiliki ETA untuk fitur ini dalam rilis resmi?

@wilfriedroset AFAIK, TIDAK ADA ETA karena diputuskan (beberapa kali) bahwa fitur ini HARUS tidak ada di buruh pelabuhan resmi untuk mempertahankan "membangun portabilitas." alias izinkan Dockerfile Anda berjalan di mana saja termasuk layanan build Docker.

Dalam pengalaman saya, portabilitas build terbatas adalah yang benar-benar diinginkan pelanggan. Mereka ingin menyiapkan lingkungan pembangunan/pertanian dan memastikan bahwa bangunan selalu dapat dibangun kembali di lingkungan itu. Opsi -v build tidak mencegah hal ini dengan cara apa pun.

Misalnya, jika Anda menggunakan mount NFS, pastikan semua server build memiliki mount tersebut di fstabs mereka dan build Anda akan selesai tanpa masalah di mana pun di farm.

Di RHEL 7.3
````
[ root@rhel7 ~]# pembangunan buruh pelabuhan --help

Penggunaan: docker build [OPTIONS] PATH | URL | -

Buat gambar dari Dockerfile

Pilihan:
--build-arg value Setel variabel waktu pembuatan (default [])
--cgroup-parent string Cgroup induk opsional untuk wadah
--cpu-period int Batasi periode CPU CFS (Penjadwal Sepenuhnya Adil)
--cpu-quota int Batasi kuota CPU CFS (Penjadwal Sepenuhnya Adil)
-c, --cpu-shares int pembagian CPU (bobot relatif)
--cpuset-cpus string CPU yang memungkinkan eksekusi (0-3, 0,1)
--cpuset-mems string MEMs untuk mengizinkan eksekusi (0-3, 0,1)
--disable-content-trust Lewati verifikasi gambar (default benar)
-f, --file string Nama Dockerfile (Defaultnya adalah 'PATH/Dockerfile')
--force-rm Selalu keluarkan wadah perantara
--help Penggunaan cetak
--isolasi string Teknologi isolasi kontainer
--label value Mengatur metadata untuk gambar (default [])
-m, --memori string Batas memori
--memory-swap string Batas swap sama dengan memori plus swap: '-1' untuk mengaktifkan swap tanpa batas
--no-cache Jangan gunakan cache saat membuat gambar
--pull Selalu mencoba menarik versi gambar yang lebih baru
-q, --quiet Menekan output build dan mencetak ID gambar jika berhasil
--rm Hapus wadah perantara setelah build berhasil (default benar)
--shm-size string Ukuran /dev/shm, nilai defaultnya adalah 64MB
-t, --tag value Nama dan opsional tag dalam format ' name:tag ' (default [])
--ulimit nilai Opsi ulimit (default [])
-v, --volume value Setel build-time bind mount (default [])
```

kasus penggunaan lain pada proyek node pembangunan CI adalah membagikan cache yarn CI saat membangun semua gambar.

+1 : instal node_modules lagi dan lagi benar-benar mengerikan, terutama untuk layanan mikro nodejs
Saya mencoba menyelesaikan masalah ini dengan nfs , saya pikir "dapat diulang" bukan alasan yang baik untuk tidak mengimplementasikan fitur ini ...

Sepertinya ini akan menjadi lebih penting dengan #31257 dan #32063 digabungkan.

Lihat di #32507

@fatherlinux dapatkah Anda menjelaskan cara kerja portabilitas build ketika Anda dapat memiliki perintah COPY di dalam Dockerfile? Saya memiliki masalah di mana saya ingin menghindari jumlah salinan file besar (karena alasan kompleksitas waktu) dan saya mencari opsi baca-saja build-time untuk berbagi file dengan wadah.

@arunmk Lihat https://github.com/moby/moby/issues/32507

@arunmk @cpuguy83 tepatnya. Idenya adalah Anda benar-benar tidak ingin MENYALIN data ke dalam wadah saat dibuat. Itu bisa membuatnya sangat besar. Kami hanya ingin data tersedia pada waktu pembuatan. Per di atas, Anda dapat melakukan -v bind mount di daemon docker versi Red Hat yang memungkinkan Anda memiliki data yang tersedia, tetapi hanya bisa dibaca sekarang (membakar saya minggu lalu).

Jadi, jika Anda membutuhkannya hari ini, periksa Fedora, CentOS, atau RHEL dan Anda dapat memasang salinan data Hanya Baca pada waktu pembuatan...

Dan, jika Anda membutuhkan portabilitas dalam build farm, saya akan menyarankan NFS atau semacamnya....

Jika Anda tidak peduli untuk menyalinnya tetapi hanya peduli untuk memilikinya di gambar akhir, Anda dapat menggunakan build multi-tahap untuk menangani ini.

Contoh yang dibuat-buat:

FROM fatImage AS build
COPY bigData /data
RUN some_stoff /data

FROM tinyImage
COPY --from=build /data/result

Terima kasih atas klarifikasinya @fatherlinux
@cpuguy83 terima kasih atas detailnya. Izinkan saya menambahkan lebih banyak detail untuk masalah saya yang mungkin tidak biasa: Saya memiliki sistem build yang menghasilkan file 3,3GB. Itu ditambahkan ke RPM yang dibangun di dalam wadah buruh pelabuhan. Jadi ada dua salinan yang dihasilkan: satu dari sistem build ke dalam wadah buruh pelabuhan, satu dari dalam wadah buruh pelabuhan ke dalam RPM. Sekarang, saya tidak bisa menghindari salinan kedua. Saya berpikir untuk menghindari salinan pertama tetapi sepertinya itu juga tidak mungkin, bahkan dengan build multi-tahap.
Saya dapat memahami bahwa, jika file besar digunakan berulang kali, salinan multi-tahap akan mengurangi jumlah salinan berjalan ke '1'. Saya menggunakannya sekali dan ingin mengurangi angkanya menjadi '0'. Apakah saya benar dalam memahami bahwa itu tidak mungkin?

@arunmk Tidak peduli apa itu harus disalin ke instance build dari klien.

@ cpuguy83 terima kasih atas klarifikasinya. Sepertinya saya harus mengambil alih untuk saat ini. Apakah itu memiliki atomisitas?

@fatherlinux

Saya mencoba apa yang Anda katakan, menggunakan -v pada RHEL7 untuk mencoba dan hanya membaca mount direktori selama build, tetapi dapatkan kesalahan ini:

Volume tidak didukung dalam build buruh pelabuhan. Harap gunakan hanya pengikat mount.

Ini hanya akan bekerja dengan paket buruh pelabuhan dari RHEL bukan yang dari Docker. Patch tidak diterima di hulu.

@fatherlinux

Saya mencoba apa yang Anda katakan, menggunakan -v pada RHEL7 untuk mencoba dan hanya membaca mount direktori selama build, tetapi dapatkan kesalahan ini:

Volume tidak didukung dalam build buruh pelabuhan. Harap gunakan hanya pengikat mount.

@fcntl

anda perlu menggunakan bind seperti yang dikatakan kesalahan, Anda mungkin menggunakan -v /something daripada /hostsomething:/containersomething

@thebigb dan mungkin yang lain, kami telah menyiapkan infrastruktur untuk dapat menggunakan ccache selama pembuatan buruh pelabuhan. kami telah menerbitkannya di https://github.com/WebHare/ccache-memcached-server jika itu membantu Anda, meskipun idealnya menyelesaikan masalah ini mungkin akan membuatnya usang.

Saya baru saja akan menambahkan, kasus penggunaan yang sangat saya butuhkan adalah ccache. Saya ingin dapat memasang cache ccache saya selama pembuatan gambar buruh pelabuhan - tidak ada gunanya berada di gambar itu sendiri. @unilynx Saya akan melihat solusi Anda--waktu yang tepat!

Jus suara lain.

Kasus penggunaan saya: saat ini saya menggunakan perintah MOUNT rocker untuk berbagi direktori /root/.cache dan /var/cache/apk .

Untuk beberapa alasan saya memiliki akses jaringan yang sangat (sangat, sangat) lambat ke paket apk dan paket pip. Setiap pembangunan kembali akan membuat prosesnya sangat memakan waktu. Itu membuat segalanya jauh lebih mudah dengan fitur MOUNT build-time ini.

@embray @roxma lihat https://github.com/moby/moby/issues/32507 jika itu akan mengatasi kasus penggunaan Anda; umpan balik selamat datang

Dengan diperkenalkannya build multi-tahap , saya merasa kebutuhan untuk menentukan volume mount untuk Cache Lokal Maven sangat penting.

@gim913 Ini bukan cara Anda berpartisipasi dalam komunitas mana pun. Jika Anda ingin berkontribusi, harap tinjau proposal yang ada yang ditautkan di sini untuk melihat apakah ada yang menyelesaikan kasus penggunaan Anda.

@gim913 Pada tahap integrasi buruh pelabuhan ke berbagai distribusi ini, mengubah lingkungan (yaitu menjatuhkan buruh pelabuhan sepenuhnya) tampaknya jauh lebih mengganggu daripada mengubah 'OS' Anda (saya berasumsi maksud Anda beralih dari distribusi Linux yang berbeda ke versi RedHat yang tampaknya menyertakan -v? )

Bukankah lebih mudah untuk mengambil versi buruh pelabuhan RedHat? Mungkin seseorang di sini dapat mengarahkan Anda ke patch/garpu/komit yang relevan untuk mendapatkan opsi '-v' di build.

@unilynx ini dia

Saya sedang melihat beberapa contoh yang menggunakan wget dan sampai di sini...kasus penggunaan saya serupa...Saya ingin meng-unzip tarball besar dan menjalankannya. Saya tidak ingin mengotori file buruh pelabuhan dengan tarball atau membuang waktu melakukan wget dari server web lokal. Memasang seperti yang dapat Anda lakukan dengan penulisan buruh pelabuhan sepertinya merupakan hal yang masuk akal untuk dilakukan pada waktu pembuatan. Silakan gabungkan perubahan Puneeth jika terlihat ok :-)

Saya mengkompilasi ulang roda python dan ingin menginstalnya di dalam wadah tanpa menyalinnya dan membuat lapisan yang benar-benar tidak saya perlukan, atau entah bagaimana harus mencoba untuk menekan. Hari 1 dan saya sudah melihat ke rocker 😢

Ini akan mudah ditambahkan dan sangat berguna (atau perintah mount, lihat lagi rocker ). Berapa banyak waktu yang dihabiskan (di komunitas) untuk membuat skrip di sekitar fitur ini atau fitur serupa yang hilang?

@awbacker Multi-stag build menyelesaikan ini dengan cukup baik di mana Anda dapat melakukan sesuatu seperti

FROM something AS my_wheels
RUN compile_all_the_things

FROM something
COPY --from my_wheels /wherever
RUN do_stuff_with_wheels

Bagian pertama hanya dijalankan jika ada perubahan. Cache untuk itu dapat dibagikan di antara build/dockerfiles lain juga.
Hal ini membuat seluruh membangun mandiri.

Ada juga proposal yang mengizinkan RUN --mount di mana spesifikasi pemasangan akan memerintahkannya untuk memasang sesuatu dari target pembuatan my_wheels alih-alih menyalinnya.

Seperti untuk @kenyee , ini dapat me-mount sesuatu dari konteks build, yang dalam eksperimen 17,07 hanya dikirim secara bertahap sesuai kebutuhan.

@ cpuguy83 Itu tidak berfungsi dalam praktik - setidaknya untuk Gradle Java build. Saya memiliki gambar Docker dasar yang memiliki file Gradle Jar yang telah di-cache sebelumnya, tetapi build Gradle dari sumber Andalah yang memicu unduhan semua dependensi Anda ke dalam cache.

@ cpuguy83 multi-tahap tidak memungkinkan untuk menghapus roda yang disalin dari gambar yang dihasilkan, itulah yang dibicarakan @awbacker . Dengan demikian konten di folder /wherever akan di-cache dan ukuran gambar akan ditingkatkan.

@BryanHunt Jadi bagian dari proses pembuatan Anda adalah mengunduh deps? Pasti Gradle harus menyediakan cara untuk men-cache ini tanpa melalui dan benar-benar membangun?

@cpuguy83 Ya, deps diunduh sebagai bagian dari build. Pada dasarnya sama dengan Maven. Untuk referensi: https://github.com/gradle/gradle/issues/1049

apakah ada PR untuk build mount di suatu tempat?

@graingert Disini

👍 untuk ini. Di Lunar Way kami ingin melakukan proses "build -> test -> build image produksi" lengkap dalam satu build Docker untuk menghapus dependensi build dan test dari server CI. Dengan build multi-tahap, kita bisa melakukan ini, tetapi kita tidak bisa mendapatkan hasil pengujian dari container perantara dalam proses build. Oleh karena itu, kami harus melakukannya dalam dua langkah sekarang - dengan Dockerfile terpisah untuk membangun image pengujian, menjalankannya, dan kemudian hanya melanjutkan ke langkah build prod image, jika pengujian berhasil.

Opsi -v pada pembangunan buruh pelabuhan akan memungkinkan kami untuk menyimpan hasil pengujian dalam folder yang dipasang dari server CI dan menghapus kebutuhan untuk proses 2 langkah saat ini.

@tbflw Secara default, build Docker tidak menghapus wadah perantara setelah build yang gagal. Jadi jika tes gagal, Anda bisa mendapatkan hasil tes dari itu.

Tolong , kami juga sangat, sangat membutuhkan fitur ini! Menggunakan alat lain seperti rocker atau forking docker dengan patch ad-hoc jauh lebih buruk daripada mematahkan gagasan evangelis tentang "membangun portabilitas".

@BryanHunt @stepps @yngndrw yang lain juga @awhitford
Salah satu cara untuk men-cache dependensi build adalah membuat build Anda berfungsi seperti contoh go build multi-tahap dalam dokumentasi atau python onbuild Dockerfile .
Berikut adalah contoh yang saya buat yang tampaknya berfungsi untuk pakar. Saya akan menyalinnya di sini.

FROM maven
WORKDIR /usr/src/app
# /root/.m2 is a volume :(
ENV MAVEN_OPTS=-Dmaven.repo.local=../m2repo/
COPY pom.xml .
# v2.8 doesn't work :(
RUN mvn -B -e -C -T 1C org.apache.maven.plugins:maven-dependency-plugin:3.0.2:go-offline
COPY . .
RUN mvn -B -e -o -T 1C verify

FROM openjdk
COPY --from=0 /usr/src/app/target/*.jar ./

Itu perlu diatur sehingga mengunduh dependensi sebelum menyalin sisa basis kode. Pastikan juga bahwa tempat artefak Anda disimpan tidak dalam VOLUME .

@sixcorners Itu tidak berfungsi untuk Gradle

@BryanHunt Dockerfile ini atau pendekatan ini tidak berfungsi untuk gradle? cpuguy83 bertanya apakah ada cara untuk mengunduh dependensi tanpa benar-benar melakukan build. Anda menautkan ke tugas penyelesaian dependensi. Tidak bisakah Anda menambahkan file build.gradle dan menjalankan tugas itu?

@sixcorners Ketika Anda memiliki banyak modul, Anda harus mereplikasi struktur direktori Anda bersama dengan file build dan file properti. Saya kira itu bisa dilakukan, tetapi saya melihat ini sangat rawan kesalahan.

Multistage oleh @sixcorners adalah trik yang menarik dan saya telah melihatnya digunakan untuk manajer paket yang berbeda (mis. npm, komposer).

Namun ada masalah, setiap kali daftar dependensi diubah COPY pom.xml pada gambar tahap 0 menyebabkan lapisan dibuang dan dengan demikian seluruh cache hilang. Itu berarti bahwa setiap kali pengembang mengubah apa pun di pom (komentar, ketergantungan 1kBytes), seluruh cache harus diunduh ulang lagi.

Untuk mesin CI yang membangun gambar dan kemudian menjalankan tes dengan dependensi yang terus berubah, yaitu ribuan paket yang harus diunduh ulang (baik dari proxy atau dari upstrea) dan membuat pembangunan kembali cukup lambat. Cache berbasis file lokal yang dipasang sebagai volume jauh lebih cepat.

Itu juga merupakan masalah ketika pengembang mengulangi pembuatan gambar, khususnya jika mereka berada di koneksi yang lambat. Meskipun seseorang dapat menyiapkan instance Nexus lokal dan http_proxy untuk itu, tetapi itu memiliki efek samping lain (seperti menyalurkan permintaan http apa pun melalui Nexus).

Multistage adalah solusi yang bagus, tetapi tidak ideal.

Solusi yang akan kami coba adalah membuat gambar dengan membangun perpustakaan bersama kami dan mempertahankan cache ketergantungan. Gambar ini kemudian akan menjadi gambar build kami untuk aplikasi kami. Ini tidak ideal, tetapi kami pikir itu patut dicoba.

Namun ada masalah, setiap kali daftar dependensi diubah SALIN pom.xml pada gambar tahap 0 menyebabkan lapisan dibuang dan dengan demikian seluruh cache hilang. Itu berarti bahwa setiap kali pengembang mengubah apa pun di pom (komentar, ketergantungan 1kBytes), seluruh cache harus diunduh ulang lagi.

@hashar perhatikan bahwa fitur COPY --from tidak terbatas pada tahap pembuatan; dari referensi Dockerfile :

Opsional COPY menerima flag --from=<name|index> yang dapat digunakan untuk mengatur lokasi sumber ke tahap build sebelumnya (dibuat dengan FROM .. AS <name> ) yang akan digunakan sebagai ganti konteks build yang dikirim oleh pengguna. Bendera juga menerima indeks numerik yang ditetapkan untuk semua tahapan pembangunan sebelumnya yang dimulai dengan instruksi FROM . _ Jika tahap pembuatan dengan nama yang ditentukan tidak dapat ditemukan, gambar dengan nama yang sama dicoba digunakan sebagai gantinya. _

Ini memungkinkan Anda untuk _membangun_ gambar untuk dependensi Anda, menandainya, dan menggunakannya untuk menyalin dependensi Anda. Sebagai contoh:

FROM maven
WORKDIR /usr/src/app
# /root/.m2 is a volume :(
ENV MAVEN_OPTS=-Dmaven.repo.local=../m2repo/
COPY pom.xml .
# v2.8 doesn't work :(
RUN mvn -B -e -C -T 1C org.apache.maven.plugins:maven-dependency-plugin:3.0.2:go-offline
COPY . .
RUN mvn -B -e -o -T 1C verify

docker build -t dependencies:1.0.0 .

Dan tentukan menggunakan gambar dependencies:1.0.0 untuk dependensi Anda;

FROM openjdk
COPY --from=dependencies:1.0.0 /usr/src/app/target/*.jar ./

Atau (hanya contoh yang sangat mendasar untuk diuji);

$ mkdir example && cd example
$ touch dep-one.jar dep-two.jar dep-three.jar

$ docker build -t dependencies:1.0.0 . -f -<<'EOF'
FROM scratch
COPY . /usr/src/app/target/
EOF

$ docker build -t myimage -<<'EOF'
FROM busybox
RUN mkdir /foo
COPY --from=dependencies:1.0.0 /usr/src/app/target/*.jar /foo/
RUN ls -la /foo/
EOF

Di output build, Anda akan melihat:

Step 4/4 : RUN ls -la /foo/
 ---> Running in 012a8dbef91d
total 8
drwxr-xr-x    1 root     root          4096 Oct  7 13:27 .
drwxr-xr-x    1 root     root          4096 Oct  7 13:27 ..
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-one.jar
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-three.jar
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-two.jar
 ---> 71fc7f4b8802

Saya tidak tahu apakah ada yang menyebutkan kasus penggunaan ini (saya mencari halaman secara singkat) tetapi memasang soket autentikasi SSH ke dalam wadah build akan membuat penggunaan dependensi yang digunakan melalui repositori git pribadi menjadi lebih mudah. Akan ada lebih sedikit kebutuhan untuk boilerplate di dalam Dockerfile terkait penyalinan di sekitar kunci dalam tahap pembuatan non-final, dll.

buildkit memiliki dukungan asli untuk git
https://github.com/moby/buildkit

Pemecahan.
Buat skrip bash (~/bin/docker-compose atau suka):

#!/bin/bash

trap 'kill $(jobs -p)' EXIT
socat TCP-LISTEN:56789,reuseaddr,fork UNIX-CLIENT:${SSH_AUTH_SOCK} &

/usr/bin/docker-compose $@

Dan di Dockerfile menggunakan socat:

...
ENV SSH_AUTH_SOCK /tmp/auth.sock
...
  && apk add --no-cache socat openssh \
  && /bin/sh -c "socat -v UNIX-LISTEN:${SSH_AUTH_SOCK},unlink-early,mode=777,fork TCP:172.22.1.11:56789 &> /dev/null &" \
  && bundle install \
...
or any other ssh commands will works

Kemudian jalankan docker-compose build

Untuk membuang use case lain ke tumpukan. Saya menggunakan Docker untuk Windows untuk menghasilkan sistem file untuk membangun sistem linux tertanam dalam satu wadah dan saya ingin membagikan ini dengan wadah lain selama langkah pembuatan mereka. Saya berinteraksi dengan wadah ini mengubah konfigurasi dan membangun kembali dll sehingga melakukan build di Dockerfile dan menggunakan build multi-tahap tidak cocok karena saya akan kehilangan build tambahan. Saya ingin men-cache artefak build saya sebelumnya karena dibutuhkan sekitar 1,5 jam untuk melakukan build bersih. Karena cara Windows menangani tautan simbolik, saya tidak dapat melakukan build ke volume yang dipasang di Host, jadi saya menggunakan volume bernama. Idealnya saya ingin membagikan volume bernama ini dalam langkah-langkah pembuatan gambar saya yang lain; karena saat ini saya harus membuat tar dari output build (sekitar 4gb) kemudian melakukan salinan buruh pelabuhan untuk membuatnya tersedia di host windows untuk build selanjutnya.

Dalam kasus python, ketika kita pip install package itu dan dependensinya diunduh ke folder cache dan kemudian diinstal ke paket situs.
Sebagai praktik yang baik, kami menggunakan pip --no-cache-dir install package untuk tidak menyimpan sampah/cache di lapisan saat ini. Tetapi untuk praktik terbaik, diinginkan untuk meletakkan folder cache di luar konteks build. jadi build time -v akan membantu.
beberapa pengguna yang disebutkan di atas untuk menggunakan COPY . /somewhere/in/container/ tidak apa-apa untuk aplikasi atau file pengguna tetapi tidak untuk cache. karena COPY membuat satu lapisan lagi sebagai miliknya dan menghapus cache di lapisan selanjutnya tidak akan berguna. efek samping buruk lainnya adalah jika cache berubah ketika kita menggunakan COPY konteksnya berubah dan lapisan berikut akan batal dan dipaksa untuk membangun kembali.

@wtayyeb Jika Anda memiliki Dockerfile yang menjalankan pip install ... hanya ketika file persyaratan berubah, maka waktu pembuatan -v tampaknya tidak terlalu penting karena persyaratan tidak berubah sesering yang dilakukan aplikasi saat membangun.

@wtayyeb Anda dapat menggunakan Dockerfile multi-tahap untuk memiliki cache dan gambar ramping. Yaitu, gunakan gambar penginstal untuk menginstal python ke beberapa direktori dan kemudian untuk gambar akhir Anda gunakan SALIN --dari untuk mentransfer hanya file python yang diperlukan tanpa artefak instalasi atau bahkan pip itu sendiri.

@manishtomar , Terima kasih, Ya dan Tidak! Dalam kasus bersih, semua dependensi diunduh lagi dan dibangun dan dikonversi ke roda dan di-cache, kemudian diinstal ke lingkungan tujuan. Jadi jika seseorang memasukkan persyaratan di sana, itu adalah pekerjaan satu kali. Tetapi jika satu dependensi kecil diperbarui, semua dependensi harus diunduh ulang, dibangun kembali dan diroda ulang dan di-cache ulang agar dapat digunakan.
Saat menggunakan CI untuk membangun dan menguji pustaka dan aplikasi Anda dalam matriks beberapa pekerjaan, kalikan pekerjaan di atas dalam jumlah pekerjaan bersamaan di server CI Anda dan akan mendapatkan peningkatan iowait menjadi lebih dari 3 detik dan memuat rata-rata di atas 15 bahkan dengan SSD. (angka-angka ini nyata untuk 2 build dan aplikasi bersamaan dengan ~ 20 dependensi) Saya pikir pip cache melakukannya dengan cara yang benar, menghindari mengunduh ulang, membangun kembali, dan memutar ulang paket yang sudah siap. dan tanpa bind -v kita kehilangan waktu dan sumber daya server.

@ibukanov , Terima kasih. Saya menggunakan Dockerfile multi-tahap untuk membangun paket aplikasi saya dan menggunakannya nanti. Akan membantu jika saya hanya memiliki satu Dockerfile dan ingin membangunnya beberapa kali, tetapi bagaimana jika ada beberapa Dockerfile dan masing-masing dibuat dengan versi python (2.7,3.6 untuk saat ini) dan juga memiliki beberapa ekstensi-c yang perlu dibuat untuk gambar dasar yang dipilih? bagaimana dengan paragraf di atas?

@thaJeztah Saran Anda bagus dan itu akan menghemat waktu kami, namun dalam hal membangun cache, kami benar-benar tidak ingin menyalin apa pun dari gambar lain.
Mengapa kami tidak dapat mengakses gambar lain tanpa menyalinnya?

@thedrow contoh saya adalah dengan fitur-fitur yang ada saat ini; lihat proposal RUN --mount (https://github.com/moby/moby/issues/32507), yang mungkin lebih cocok dengan kasus penggunaan Anda

Membaca utas di atas, saya melihat sejumlah besar orang mencoba menemukan kludges untuk memperbaiki celah fungsionalitas dasar dalam proses pembuatan buruh pelabuhan. Saya tidak melihat argumen yang meyakinkan dari dasar portabilitas tanpa harus menggabungkan tunggangan host dengan tunggangan gambar - argumen yang sejujurnya bermuka-muka dan malas.

Saya juga pengguna kontainer gentoo dan dialihkan dari https://github.com/moby/moby/issues/3156 yang merupakan kasus penggunaan yang sepenuhnya valid untuk fungsi yang hilang ini.

Yang benar-benar saya inginkan adalah kemampuan untuk memasang konten gambar lain pada waktu pembuatan sehingga saya tidak menggembungkan gambar saya.

@kbaegis terdengar sangat cocok dengan fitur yang diusulkan di https://github.com/moby/moby/issues/32507

Tentu. Itu hanya P3 yang tidak diimplementasikan dalam backlog selama satu tahun, bukan 3 tahun.

Sepertinya https://github.com/projectatomic/buildah sebenarnya akan melampaui pembangunan buruh pelabuhan dengan cukup cepat di sini untuk fungsi dasar ini. Saya pikir saya hanya akan mengganti saluran pipa saya begitu itu terjadi.

@kbaegis apa yang Anda datang ke sini untuk menambahkan diskusi ini? Anda menjelaskan kasus penggunaan yang _persis_ cocok dengan proposal yang berbeda;

Yang benar-benar saya inginkan adalah kemampuan untuk memasang konten gambar lain pada waktu pembuatan sehingga saya tidak menggembungkan gambar saya.

Ini open-source, hal-hal tidak muncul secara ajaib.

Apa yang ingin saya tambahkan ke diskusi?

Ringkasnya saya pindah dari toolset ini. Saya yakin itu informasi berharga bagi tim pengembangan karena saya yakin saya tidak sendirian di sana.

Kecepatan glasial dan prioritas rendah untuk mendukung kasus penggunaan ini (dan solusi andal apa pun yang menyediakan fungsionalitas ini) telah memaksa saya ke alat lain dan bahwa saya meninggalkan pipa pembangunan ini karena fungsionalitas yang hilang.

Saya punya kasus penggunaan (pengulangan, saya yakin) untuk ditambahkan. #32507 mungkin lebih cocok dengan ini.

Saya sedang membangun gambar buruh pelabuhan untuk beberapa saluran pipa bioinformatika. Beberapa alat memerlukan beberapa database untuk hadir sebelum kompilasi/instalasi mereka (jangan tanya, itu bukan kode saya ). Basis data ini berbobot minimal 30gb yang indah.

Selama runtime, saya tentu bermaksud agar database tersebut di-mount volume -v . Sayangnya, saya tidak dapat melakukan ini selama proses pembuatan tanpa "memanggang" mereka, menghasilkan gambar berukuran agak tidak senonoh.

@draeath lihat di https://github.com/grammarly/rocker . Ini sudah mendukung instruksi MOUNT yang indah.

@draeath juga, periksa Buildah, ini mendukung mount secara default karena diatur lebih seperti alat pemrograman. Juga mendukung mount dengan Dockerfile:

https://github.com/projectatomic/buildah

Terima kasih @fatherlinux dan @lig - ini akan membantu saya menyelesaikan tugas saya. Saya masih berpikir saya tidak harus menyimpang di luar proyek untuk melakukannya, dan masih ingin melihat ini dan #32507 diimplementasikan;)

Saya datang ke sini melalui beberapa googling untuk meminta fitur yang sama, volume pada waktu 'docker build', bukan waktu 'docker run'.

Kami memiliki sistem tertanam yang berisi CPU. Pabrikan menyediakan alat untuk menyusun citra sistem, dan kemudian mentransfer citra ke CPU. Alat ini adalah pihak ke-3 bagi saya dan saya tidak dapat mengubahnya. Pabrikan juga tidak mungkin mengubahnya atas permintaan saya.

Saya ingin membuat gambar buruh pelabuhan yang melakukan pass pertama "membangun gambar firmware", dan kemudian dapat menelurkan wadah yang hanya mendorong gambar firmware ke PCB baru. Dockerfile mungkin terlihat seperti:
----------[ Potong disini ]----------
DARI gambar dasar sebagai pembangun
SALIN src src
RUN build-src

DARI gambar dasar sebagai flasher
SALIN --from=pembuat artefak bangunan
JALANKAN cpu-build-and-flash --build-only
----------[ Potong disini ]----------
Sayangnya, langkah cpu-build-and-flash memerlukan akses ke perangkat target melalui bus USB, meskipun itu tidak akan mendorong gambar firmware ke perangkat. Jadi saya perlu mengambil '-v /dev/usb/bus:/dev/usb/bus' dari perintah 'docker run' dan memasukkannya ke dalam build.

Jelas bahwa ini tidak mungkin saat ini.

Solusi yang akan saya lakukan adalah membuat gambar yang berkedip secara manual dengan 'kontainer buruh pelabuhan yang mengkomit' wadah ke gambar. Saya lebih suka hanya memasang bus USB pada waktu pembuatan.

Pembaruan untuk siapa saja yang tertarik: Saya baru saja membangun kembali seluruh pipa saya dengan buildah. Saat ini saya menjalankan dua pipeline build secara paralel dan pipeline oci/buildah menghasilkan gambar yang lebih kecil (khususnya menghapus /usr/portage dalam kasus saya dengan menutupinya dengan mount lain).

Dan akhirnya fitur ini ada di sini: https://github.com/docker/docker-py/issues/1498

Tapi saya ingin volume RW untuk cache build

Pada Sabtu, 28 Apr 2018, 17:29 оренберг арк, [email protected] menulis:

Dan akhirnya fitur ini ada di sini: docker/docker-py#1498
https://github.com/docker/docker-py/issues/1498

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/14080#issuecomment-385188262 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAZQTJodLCCzyDdPFtNiIUZ_z85YvLWbks5ttJjagaJpZM4FIdOc
.

Saya juga ingin melihat fitur ini (dengan kemampuan menulis) sehingga file hasil pengujian unit dapat diekspor selama proses pembuatan multitahap dalam pipa CI. Untuk menjaga semangat portabilitas build, jika sakelar -v tidak disediakan, file hanya akan ditulis secara internal di dalam gambar uji pada tahap itu.

Tujuan ideal adalah untuk membangun sekali, menguji sekali, dan masih memiliki file hasil yang diberikan ke sistem host, bahkan jika (dan terutama jika) pengujian gagal, menghentikan pembangunan.

Ya silahkan. Sepanjang hari.

Tidak sepenuhnya relevan, tetapi kami memigrasikan sebagian infrastruktur penerapan kami dan membutuhkan cara untuk menyalin file dari gambar setelah pembuatan. Berikut ini triknya:

docker build -t x .
ID=$(docker create x)
docker cp $ID:/package.deb .
docker rm $ID

Seharusnya sudah ditambahkan ketika file buruh pelabuhan multistage diperkenalkan. Akhirnya semua orang akan menghadapi masalah ini segera setelah mereka akan mulai menjalankan unit test sebagai tahap dalam file buruh pelabuhan multistage khususnya dalam kasus CI build pipelines. Kami juga menghadapi masalah ini di mana kami harus menerbitkan laporan pengujian unit ke VSTS. Sudah menerapkan solusi yang telah disebutkan @hoffa . Tapi bagaimanapun juga itu adalah solusi dan membuat segalanya menjadi rumit.

Haruskah kita membuat masalah yang berbeda untuk orang-orang yang menginginkan/membutuhkan volume waktu pembangunan untuk cache pembangunan?

@ajbouh Ya, mungkin di https://github.com/moby/buildkit/issues

Lihat https://github.com/moby/moby/issues/32507#issuecomment -391685221

Pada hari Rabu, 23 Mei 2018, 19:22 Akihiro Suda [email protected] menulis:

@ajbouh https://github.com/ajbouh Ya, mungkin di
https://github.com/moby/buildkit/issues

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/14080#issuecomment-391566368 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAAcnSqNoVc4j34ElECy53gIfPecQFKfks5t1hlkgaJpZM4FIdOc
.

Meskipun Anda tidak dapat menambahkan volume pada waktu pembuatan, Anda dapat menambahkan host, jadi sekarang saya membuat semua gambar buruh pelabuhan saya dengan sesuatu seperti --add-host yum-mirror:$MIRROR_IP yang menyajikan cermin yum yang kemudian dideteksi oleh gambar bangunan saya melalui pembungkus enak Berguna ketika proyek saya mengubah dependensi berkali-kali dalam sehari dan saya offline atau koneksi yang buruk (bagian dari proyek melibatkan pembaruan dan pembersihan banyak deps).

Saya menemukan penolakan Docker untuk memecahkan masalah ini menyebalkan.

Dukungan eksperimental untuk buildkit baru-baru ini digabungkan, yang disertai dengan opsi untuk RUN --mount=<opts> <command> .

tautan ke @ cpuguy83 catatan: https://github.com/moby/buildkit/pull/442

@glensc @cpuguy83 Kapan kami dapat mengharapkan rilis untuk fitur gabungan ini?

+1

RUN --mount tidak memiliki dukungan volume, jadi hal-hal seperti https://github.com/avsm/docker-ssh-agent-forward tetap tidak mungkin pada waktu pembuatan, apa solusi untuk ini?

@peter-edge https://github.com/moby/buildkit/pull/655

docker build --secret akhirnya tersedia di Docker 18.09 https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

Bisakah kita menutup masalah ini?

--secret tidak dapat digunakan untuk kasus penggunaan caching, dari apa yang saya tahu.

@AkihiroSuda RUN --mount secara umum terlihat seperti sesuatu yang mungkin cocok sebagai solusi untuk masalah ini.

Ya, saya kira RUN --mount=type=cache (untuk volume cache) dan --mount=type=secret dengan docker build --secret (untuk volume rahasia) hampir mencakup masalah ini.

@AkihiroSuda jadi, contoh kerja yang memecahkan masalah asli akan bagus untuk dilihat

@AkihiroSuda Dari artikel (https://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066) Saya melihat 2 kasus penggunaan menggunakan mount selama build: Rahasia dan SSH

[Rahasia]

docker build --secret id=mysite.key,src=path/to/mysite.key .
RUN --mount=type=secret,id=mysite.key,required <command-to-run>

[SSH]

RUN --mount=type=ssh git clone [email protected]:myorg/myproject.git myproject

Ada 2 kasus penggunaan lain (yang saya ingat) yang tidak dijelaskan cara menggunakannya di artikel atau di edisi ini:

1) [Cache] RUN --mount=type=cache
2) Volume secara umum (misalnya, untuk memasang sertifikat SSL, atau dalam kasus volume besar yang harus digunakan selama pembuatan, tetapi tidak disertakan dalam gambar yang dihasilkan, dan seterusnya...)

Setelah use case dipasang yarn workspace sebelum menjalankan webpack

Anda bisa melakukan semua ini..

RUN --mount=type=cache,from=<some image>,source=<path in from image>,target=<target>

Anda juga dapat mengganti from=<some image> menjadi from=<some build stage>

Berikut adalah contoh yang dibuat-buat:

# syntax=docker/dockerfile:1.0.0-experimental
FROM busybox as hello
RUN  echo hello > /hello.txt

FROM scratch
RUN --mount=type=cache,from=busybox,source=/bin,target=/bin --mount=type=cache,from=hello,source=/hello.txt,target=/tmp/hello.txt echo /tmp/hello.txt

Berikut beberapa dokumentasi tentang ini: https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md

Saya setuju dengan @AkihiroSuda , ini harus menangani semua kasus... tapi tolong beri tahu kami jika tidak.

@AkihiroSuda @cpuguy83 : Sayangnya, implementasi saat ini (buildkit di docker 18.09) memiliki masalah dengan pendaftar pribadi. Sampai sekarang, fitur baru ini tidak dapat digunakan jika Anda harus mengambil gambar melalui registri pribadi. Lihat pengujian saya di https://github.com/moby/moby/issues/38303.

Saya pikir ini juga akan digunakan untuk artefak Jenkins, jadi misalnya jika saya membuat gambar Docker dan mengkompilasi sesuatu di dalam saya ingin mendapatkan beberapa artefak seperti mengatakan junit pytest output

Ini akan sangat berguna. Saya benar-benar lebih suka tidak perlu menambahkan --experimental untuk mendukung RUN --mount=type=cache /user/.cache/pip pip install (untuk menghemat banyak bandwidth indeks paket).

buildah bud ( buildah build-using-dockerfile ) memiliki opsi --volume / -v :
https://github.com/containers/buildah/blob/master/docs/buildah-bud.md

buildah dapat menjalankan build sebagai non-root tanpa soket buruh pelabuhan.

Karena unduhan paket dari jaringan lebih dapat direproduksi?

Tidak perlu menambahkan "--experimental", hanya "DOCKER_BUILDKIT=1" pada klien.

Ya, pembangunan jaringan lebih dapat direproduksi karena semua konteksnya ada di Dockerfile. Jika Anda harus memasang konteks dari Host untuk membuat build berfungsi, itu adalah pengalaman yang buruk.

Perhatikan bahwa Anda juga dapat memasang gambar ke dalam build.

Ya, pembangunan jaringan lebih dapat direproduksi karena semua konteksnya ada di Dockerfile.

Tentunya memiliki RUN apt-get update di Dockerfile memastikan bahwa seseorang memiliki semua langkah yang diperlukan untuk membangun image. Namun, itu tidak dapat direproduksi karena konteks tambahan diunduh dari pihak ketiga. Satu-satunya perbedaan dengan mount adalah bahwa semua konteks eksternal memang didefinisikan di Dockerfile.

Jika Anda harus memasang konteks dari Host untuk membuat build berfungsi, itu adalah pengalaman yang buruk.

Pengalaman buruk saya dengan Docker build adalah tidak pernah dapat direproduksi dan kami pasti dapat mengambil manfaat dari memasang cache dari Host yang bisa dibilang akan mempercepat beberapa kasus penggunaan.

Apa yang akhirnya saya lakukan adalah membangun multistage. Satu gambar yang mendapatkan konteks dari jaringan, yang dengan demikian bertindak sebagai snapshot dari konteks jarak jauh. Kemudian beri tag dengan beberapa versi arbitrer, tanggal berfungsi dengan baik. Misalnya:

RUN apt-get update

docker build -t aptupdate-20190417

Dan dalam gambar yang sebenarnya:

FROM aptupdate-20190417
FROM somebaseimage

COPY --from=aptupdate-20190417 /var/apt /var/apt

Ulangi dengan konteks jarak jauh lainnya dan Anda kurang lebih memiliki sesuatu yang dapat direproduksi.

Atau singkatnya: Dockerfile yang bergantung pada akses jaringan mungkin tidak dapat direproduksi. Mount mungkin membuatnya tidak dapat direproduksi tetapi akan membantu membuat beberapa kasus penggunaan dapat direproduksi. Tapi saya kira intinya Dockerfile harus memiliki semua langkah yang diperlukan untuk benar-benar membangun gambar, meskipun dalam pengalaman saya sebagian besar menulis alat mereka sendiri untuk membuat gambar instrumen.

Maksud saya, RUN --mount=type=cache persis untuk ini.
Atau Anda bahkan dapat memasang dari gambar lain dari registri dan itu akan diambil.

Perintah apt Anda dapat dibuat (relatif) dapat direproduksi dengan menyematkan apa yang ingin Anda ambil.
Tetapi jika Anda benar-benar ingin mengontrol semua bit, lalu mengapa Anda menggunakan apt di build Anda? Menyimpan ini di host build tidak dapat direproduksi dan mudah terputus dari host ke host.
Menyimpannya di registri tidak buruk selain potensi kegagalan jaringan ... yang tentu saja merupakan kritik yang adil.

-v pada buildah dan fork redhat secara eksplisit ditolak di sini karena terlalu luas... bukan untuk mengatakan itu tidak berguna, tetapi mudah pecah dari Host ke Host, yang bertentangan dengan desain docker build .
Sementara alasan RH menambahkannya (atau lebih tepatnya mengapa mereka memutuskan untuk mengerjakannya) adalah untuk dapat memasang kredensial RHEL ke dalam lingkungan build.

Ya, pembangunan jaringan lebih dapat direproduksi karena semua konteksnya ada di Dockerfile. Jika Anda harus memasang konteks dari Host untuk membuat build berfungsi, itu adalah pengalaman yang buruk.

Saya sangat tidak setuju. Jaringan mungkin sedang down atau disusupi; dalam hal ini cache lokal mencegah seluruh build agar tidak gagal saat internet mati.

Saya bisa menentukan volumes: sekali di docker-compose.yml saya; tetapi sebaliknya perlu melakukan DOCKER_BUILDKIT=1 dan menambahkan RUN --mount=type=cache di Dockerfiles yang dikelola hulu? Mengapa?

Dengan CI build, kita berbicara tentang jumlah unduhan ulang yang tidak perlu puluhan hingga ribuan paket (puluhan atau ratusan kali sehari) yang hanya dapat di-cache dalam volume mount (dalam build yang berjalan sebagai nonroot tanpa kemampuan untuk mengeksekusi wadah yang diistimewakan dengan volumenya sendiri di host).

Indeks paket dalam banyak kasus dengan murah hati didukung oleh donasi. Membuang-buang uang untuk bandwidth untuk memenuhi beberapa gagasan palsu tentang reproduktifitas yang didasarkan pada keyakinan salah bahwa sumber daya jarak jauh adalah cache komponen build yang lebih dapat direproduksi sangat membuat frustrasi.

Harap tambahkan saja --volume agar docker-compose.yml saya berfungsi.

Harap tambahkan --volume agar docker-compose.yml saya berfungsi.

Membuat "docker-compose" Anda berfungsi adalah mundur.
docker-compose konsumen proyek ini, bukan sebaliknya.

docker-compose berinteraksi dengan soket buruh pelabuhan. docker-compose YAML adalah cara terkonsolidasi untuk menyimpan opsi container (yang dapat dikonversi ke k8s pod defs (yang didukung podman, sampai tingkat tertentu)). Bagaimana saya harus menentukan DOCKER_BUILDKIT=1 dengan cara yang dapat direproduksi? Saya dapat menentukan build_volumes: dengan cara yang dapat direproduksi di docker-compose.yml.

Ketika saya -- dalam skrip build CI saya yang berjalan n kali sehari -- membuat gambar dengan misalnya memanggil docker-compose build (misalnya dengan ansible) atau packer (bukan buildah dan podman), saya memiliki beberapa tujuan:

• Hemat Sumber Daya / Jangan Buang Sumber Daya
  
  
  
  • Jangan terus-menerus mengunduh ulang OS dan paket per bahasa.
  
  
  • Simpan sumber daya bandwidth organisasi saya dengan indeks paket.
  
  
• Pastikan Ketersediaan
  
  
  
  • Seharusnya / harus bekerja offline
  
  
  • Itu harus bergantung pada sesedikit mungkin komponen yang diperlukan
  
  
• Yakinkan Membangun Integritas
  
  
  
  • Mampu membuat ulang gambar yang sama dengan parameter yang sama
  
  
  • Isolasi Varians / Berikan Build yang Dapat Direproduksi
  
  
  • Kami tidak mengontrol sumber daya jarak jauh seperti indeks paket.
  
  
  • Kami tidak mengontrol jalur jaringan
    
    
    
    
    
    • DNSSEC dan DNS melalui HTTPS mungkin tidak diterapkan dengan benar
    
    
    
  
  
  • Kita bisa terkena banned dan cukup rate-limited
  
  
  • Kita harus menggunakan checksum yang ditandatangani untuk memverifikasi sumber daya yang ditandatangani
    
    
    
    
    
    • Otorisasi untuk mengakses dan menandatangani dengan kunci didelegasikan di suatu tempat
    
    
    
    • Variabel ENVironment tersedia untuk semua proses di namespace container
    
    
    
    • Pemasangan volume waktu pembuatan adalah salah satu cara untuk membagikan kunci yang diperlukan hanya pada waktu pembuatan (tanpa membocorkannya ke dalam cache gambar)
    
    
    
  
  
• Pertahankan Build Cepat
  
  
  
  • Cache dan memoize operasi yang sering.
  
  
  • Tembolok memang menambahkan titik kegagalan, varians potensial, dan risiko tidak dapat direproduksi.
    
    
    
    
    
    • Cache Proksi HTTP(S!)
    
    
    
    • Cache Lapisan Aplikasi melalui jaringan
    
    
    
    • Cache sistem file lokal
    
    
    
  
  
  • Terapkan cache yang bodoh dan dapat dibersihkan tanpa ketergantungan eksternal
    
    
    
    
    
    • Cache sistem file lokal
    
    
    
  
  

Jika saya perlu membersihkan volume cache, saya dapat membersihkan volume cache.

0. Status quo

RUN pip install app && rm -rf /root/.cache

• Mungkin hari ini
• O(n_builds): Penggunaan bandwidth
• Tidak akan bekerja offline: Tergantung pada jaringan
• Pembangunan kembali lebih lambat

A. Salinan

COPY . /app/src/app
COPY .cache/pip /app/.cache/pip
RUN pip install /app/src/app \
    && rm -rf /app/.cache/pip

• Mungkin hari ini
• ~O(1) bandwidth indeks paket
• O(n): Pada setiap build (* ONBUILD )
  
  
  
  • Salin cache
  
  
  • Batalkan pengarsipan paket
  
  
  • Menghapus cache
  
  
• Bekerja secara offline
• Pembangunan kembali lebih lambat

B. Fork dan modifikasi setiap Dockerfile dari upstream untuk menambahkan RUN --mount=type=cache dan mengatur variabel lingkungan

# Fork by copying to modify every pip install line
RUN --mount=type=cache /app/.cache/pip pip install /app/src/pip

$ DOCKER_BUILDKIT=1 docker build . [...]

• Mungkin hari ini
• Ini sudah memperkenalkan unreproducibility: ada parameter ekstra- Dockerfile, extra-docker-compose.yml yang memperkenalkan varians dalam output: gambar bawaan bernama.
• Dokumen: cara membersihkan cache --mount=type=cache (?)
• ~O(1) bandwidth indeks paket
• Bekerja secara offline
• Rekonstruksi cepat

C. Tentukan volume yang dipasang pada waktu pembuatan

C.1. bangunan

$ buildah bud -v .cache/pip:/app/.cache.pip

• Mungkin hari ini
• Juga memperkenalkan unreprodusibilitas
• Dokumen: cara membersihkan cache
• ~O(1) bandwidth indeks paket
• Bekerja secara offline
• Rekonstruksi cepat

C.2. buruh pelabuhan (apa yang diminta masalah ini)

C.2.1 CLI buruh pelabuhan

$ docker build -v .cache/pip:/app/.cache.pip

• Tidak mungkin hari ini
• Juga memperkenalkan unreprodusibilitas
• Dokumen: cara membersihkan cache
• ~O(1) bandwidth indeks paket
• Akan bekerja offline
• Rekonstruksi cepat

C.2.2 komposisi buruh pelabuhan

services:
  app:
    image: imgname:latest
    build: .
    build_volumes:  # "build_volumes" ?
    - ./.cache/pip:/app/.cache/pip

$ docker-compose build

• Tidak mungkin hari ini
• Juga memperkenalkan unreprodusibilitas
• Dokumen: cara membersihkan cache
• Akan membutuhkan revisi skema penulisan buruh pelabuhan
• ~O(1) bandwidth indeks paket
• Akan bekerja offline
• Rekonstruksi cepat

...

• SALIN || REMOTE_FETCH || Baca()
  
  
  
  • Manakah dari ini yang paling dapat direproduksi?
  
  

:point_up: Sekedar mengingatkan. Anda dapat menyematkan file yang diunduh dengan memeriksa checksumnya. Beberapa manajer paket, seperti pip, juga mendukungnya.

@westurner Terima kasih atas penjelasan detailnya.

Saya pikir yang berikut ini akan mirip dengan kasus B Anda, tetapi Anda dapat menghapus cache dan itu akan berakhir seperti kasus Anda C2 (apa yang Anda minta, saya pikir):

_docker-compose.yml:_

services:
  my-cache:
    build: ./my-cache
    image: local/my-cache

  my-image:
    build: ./my-image

_my-cache/Dockerfile:_

FROM python

RUN pip install app

_my-image/Dockerfile:_

FROM my-repo/my-image

RUN --mount=target=/export,type=bind,from=local/my-cache

RUN pip install /app/src/app

(https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run---mounttypecache)

Anda dapat membuat gambar cache dengan:

docker-compose build my-cache

Perintah RUN --mount=target=/export,type=bind,from=local/my-cache harus mengikat ke gambar. Jika Anda ingin menyegarkan cache, Anda dapat menghapus dan membangun kembali gambar cache.

Jika ini masih menggunakan cache di RUN --mount... Anda dapat menggunakan file .env dengan versi, sertakan versi di image: local/my-cache:$MY_VERSION dan from=local/my-cache:$MY_VERSION (seharusnya disertakan sebagai argumen build).

Anda dapat menyertakan layanan my-cache dalam file docker-compose lain jika Anda tidak ingin itu berada dalam file yang sama dengan layanan utama Anda.

Anda masih perlu menggunakan DOCKER_BUILDKIT=1 (seperti dalam kasus B Anda, tetapi saya pikir ini tidak akan diperlukan di versi mendatang) dan itu masih tidak dapat direproduksi (tetapi kasing C2 Anda juga tidak).

Apa hukuman yang Anda lihat jika tidak dapat direproduksi? Jika Anda meletakkan gambar cache local/my-cache di hub docker (dengan nama repo yang berbeda) atau di registri pribadi dan menggunakan versi untuk setiap build (yang akan membuat cache yang berbeda), dengan versi yang sama selalu sama cache, bukankah itu membuatnya dapat direproduksi ? Anda bahkan tidak perlu menyertakan layanan dalam file docker-compose dan memanggil perintah build. (Hub Docker harus diakses dari jaringan, tetapi sama untuk gambar Anda yang lain, saya berasumsi, dan setelah Anda mengunduh sekali, itu tidak diperlukan lagi, kecuali Anda membuat versi baru dengan cache baru)

PENOLAKAN: Saya belum menguji kode di atas.

@Yajo Dukungan checksum di pip awalnya diimplementasikan di 'mengintip' dan kemudian digabung menjadi pip. Anda dapat menambahkan hash yang dikenal baik sebagai fragmen URL dalam entri file persyaratan pip. (Ada pendanaan untuk peningkatan keamanan dalam proyek PyPA tahun ini; dukungan TUF (The Update Framework; seperti Docker Notary) di PyPI direncanakan untuk akhir tahun ini.) Bootstrapping pip dan PyPI dengan benar (dengan kunci dan kepercayaan) pada gambar buruh pelabuhan kemungkinan akan menjadi topik akhir tahun ini.
(edit; sedikit OT tetapi untuk yang bersangkutan) https://discuss.python.org/t/pypi-security-work-multifactor-auth-progress-help-needed/1042/

@lucasbasquerotto Terima kasih atas bantuan Anda. Ini jauh lebih rumit daripada hanya menetapkan --volume pada waktu pembuatan. Yaitu, tampaknya membutuhkan:

• Menentukan DOCKER_BUILDKIT=1 di docker build shell env
• Memodifikasi setiap/setiap instruksi RUN Dockerfile upstream dengan (edit) RUN --mount=type=cache dan args
• Akses baca/tulis ke gambar lain? Mutabilitas! Atau dikatakan cache dibekukan dengan versi yang mungkin basi?

Jika saya dapat MENYALIN file dari Host, atau menentukan parameter waktu pembuatan yang tidak disimpan di tempat lain, saya tidak melihat bagaimana memasang volume pada waktu pembuatan kurang dapat direproduksi?

SALIN || REMOTE_FETCH || Baca()

• Manakah dari ini yang paling dapat direproduksi?

@westurner

Menentukan DOCKER_BUILDKIT=1 di docker build shell env

Jika Anda menggunakan docker-compose , seperti yang saya lihat di posting Anda yang lain, dan jika Anda menjalankannya dari sebuah wadah, seperti:

$ sudo curl -L --fail https://github.com/docker/compose/releases/download/1.24.0/run.sh -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose

Kemudian Anda dapat mengedit file yang diunduh di /usr/local/bin/docker-compose untuk menggunakan variabel env itu. Ubah dari:

exec docker run --rm $DOCKER_RUN_OPTIONS $DOCKER_ADDR $COMPOSE_OPTIONS $VOLUMES -w "$(pwd)" $IMAGE "$@"

ke

DOCKER_BUILDKIT=1
exec docker run --rm $DOCKER_RUN_OPTIONS $DOCKER_ADDR $COMPOSE_OPTIONS $VOLUMES -w "$(pwd)" --env DOCKER_BUILDKIT=$DOCKER_BUILDKIT $IMAGE "$@"

Ini adalah perubahan yang sangat mudah dan transparan bagi siapa pun yang menjalankan perintah.

_(Jika Anda tidak menjalankan sebagai wadah, maka hal di atas tidak berlaku)_

Memodifikasi setiap/setiap instruksi RUN Dockerfile upstream dengan RUN --cache dan args

Dalam kasus yang saya paparkan, itu akan menjadi RUN --mount=type=bind... , tetapi bagaimanapun juga, harus mengubah Dockerfile juga merupakan IMO yang buruk. Opsi -v akan jauh lebih baik dan lebih transparan .

Akses baca/tulis ke gambar lain? Mutabilitas! Atau dikatakan cache dibekukan dengan versi yang mungkin basi?

Saat Anda mengikat gambar, itu mungkin akan membuat wadah (atau apa pun namanya, dengan sistem file yang direplikasi), dan perubahan yang dilakukan di sana saat membangun seharusnya tidak mengubah gambar asli (tidak masuk akal). Jadi jika Anda membangun menggunakan gambar cache bernama my-repo/my-cache:my-version dalam sebuah build, di build berikutnya akan sama persis (imutabilitas). Jika Anda ingin menggunakan cache yang lebih baru, Anda dapat membuat gambar baru dengan versi baru dan menggunakannya, seperti my-repo/my-cache:my-new-version .

Manakah dari ini yang paling dapat direproduksi?

Saya menganggap dapat direproduksi sebagai sesuatu yang akan persis sama bahkan jika Anda menjalankannya di komputer lain. Dalam pengertian ini, jika Anda mendorong gambar ke registri buruh pelabuhan (aman dan andal), dan tidak pernah mengubah gambar itu, saya akan menganggapnya dapat direproduksi (jika Anda memiliki kekhawatiran tentang koneksi internet, Anda dapat menggunakan registri pribadi dan mengaksesnya di dalam a VPN atau semacamnya (saya sendiri tidak pernah menggunakan registri pribadi)).

Jika perintah COPY menyalin cache mesin Anda, saya tidak menganggapnya dapat direproduksi karena jika Anda menjalankan pip install (atau apt-get , atau apa pun) di komputer lain, di lain waktu, dapatkah Anda menjamin bahwa isi cache akan sama? Mungkin ini bisa menjadi perhatian Anda. Mungkin tidak.

Di sisi lain, jika Anda memiliki file yang Anda miliki di beberapa tempat andal yang Anda "miliki" (seperti ember S3), unduh file tersebut ke mesin Anda dan salin file tersebut dengan perintah COPY, maka Anda dapat mereproduksinya dari yang lain mesin dengan hasil yang sama (dengan asumsi file tidak berubah, dan mesin lain identik dengan yang sebelumnya). Jadi saya akan menganggap ini sebagai dapat direproduksi. Itu tergantung dari mana file-file itu berasal dan seberapa banyak kendali yang Anda miliki atas mereka.

Sejujurnya, saya tidak menganggap apa pun sebagai 100% dapat direproduksi dalam semua kasus (bagaimanapun, perangkat keras bisa gagal), tetapi semakin dapat diandalkan, semakin baik. Ketika saya merujuk pada beberapa proses yang dapat direproduksi, saya terutama merujuk pada konten dan hasilnya yang sama, dan ini akan mencakup sesuatu yang diunduh dari jaringan, dengan asumsi bahwa konten tidak berubah seiring waktu (saya mempertimbangkan kemungkinan jaringan kegagalan dalam hal ini).

Ada beberapa jenis bug jaringan Docker yang membuat go mod download tidak dapat diandalkan di dalam wadah juga (setidaknya untuk aplikasi ukuran kami), jadi jalankan saja setiap kali untuk mengunduh semua GOPATH/pkg/mod saya lagi adalah tidak hanya boros, tapi rusak. 🤷♀.

Saya dapat menghindari banyak penyalinan file yang tidak perlu jika saya dapat menggunakan --volume !

@kevincantu RUN --mount=type=cache harus mencakup usecase Anda

Itu membutuhkan setidaknya satu pengunduhan modul yang berhasil dari dalam build buruh pelabuhan, dan dalam kasus khusus ini saya belum pernah melihatnya ..

https://github.com/moby/moby/issues/14080#issuecomment -484314314 oleh @westurner adalah ikhtisar yang cukup bagus tetapi saya tidak dapat membuat buildkit berfungsi:

$ sudo docker -v
Docker version 19.03.1, build 74b1e89

$ sudo DOCKER_BUILDKIT=1 docker build .
Ä+Ü Building 0.1s (2/2) FINISHED                                                                                                                
 => ÄinternalÜ load build definition from Dockerfile                                                                                       0.0s
 => => transferring dockerfile: 407B                                                                                                       0.0s
 => ÄinternalÜ load .dockerignore                                                                                                          0.0s
 => => transferring context: 2B                                                                                                            0.0s
failed to create LLB definition: Dockerfile parse error line 8: Unknown flag: mount

Dockerfile saya dimulai dengan # syntax=docker/dockerfile:experimental .

Saya sebenarnya ingin menggunakannya melalui docker-compose . Mencoba ENV DOCKER_BUILDKIT 1 di Dockerfile dan juga meneruskannya dari docker-compose.yml melalui ARG DOCKER_BUILDKIT tetapi semuanya sama:

$ sudo docker-compose up --build
Building web
ERROR: Dockerfile parse error line 10: Unknown flag: mount

@lucasbasquerotto Bagaimana apa yang Anda usulkan di https://github.com/moby/moby/issues/14080#issuecomment -484639378 diterjemahkan ke versi docker-compose yang diinstal?

Akhirnya, saya bahkan tidak yakin apakah ini akan mencakup kasus penggunaan saya, mungkin beberapa dari Anda dapat memberi tahu saya apakah saya harus mengejar ini. Saya ingin menggunakan cache build-time untuk pengembangan lokal yang bertahan di antara build sehingga setelah memperbarui dependensi hanya yang baru yang harus diunduh. Jadi saya akan menambahkan RUN --mount=type=cache,target=/deps ke Dockerfile dan mengatur cache manajer ketergantungan ke /deps .

untuk penulisan buruh pelabuhan, lihat https://github.com/docker/compose/pull/6865 , yang akan menjadi kandidat rilis mendatang dari penulisan

Saya memiliki kasus penggunaan lain... Saya ingin membuat wadah untuk lengan pada host x86_64 dengan binfmt yang dikonfigurasi. Ini mengharuskan saya memiliki emulator qemu cpu statis arsitektur tertentu di /usr/bin .

Solusi saya saat ini adalah menambahkan qemu-arm-static ke dalam wadah sebagai file seperti:

FROM arm32v7/alpine:3.10
COPY qemu-arm-static /usr/bin/qemu-arm-static
RUN apk update && apk upgrade
RUN apk add alpine-sdk cmake
...

Solusi yang lebih mudah adalah memasang file saya hanya jika diperlukan di dalam wadah seperti:
docker build -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static -t test:arm32v7 .
Ini bekerja sangat baik untuk menjalankan buruh pelabuhan, tetapi saya melewatkan fungsi ini untuk membangun wadah.

Apakah ada solusi lain bagaimana saya dapat membangun wadah lengan di host x86_64 atau dapatkah kami mengizinkan volume pada waktu pembuatan setidaknya untuk kasus ini?

Kernel terbaru @jneuhauser memungkinkan binari ini dimuat secara statis, jadi tidak perlu mengonfigurasinya setiap saat. Anda dapat mencapai ini misalnya dengan menjalankan gambar linuxkit/binfmt dalam mode istimewa sekali setelah boot.

kernel terbaru memungkinkan binari ini dimuat secara statis, jadi tidak perlu mengonfigurasinya setiap saat.

@alehaa Bukankah Anda masih membutuhkan biner emulator qemu statis di dalam wadah?

@cybe Ini tidak diperlukan lagi, jika F -flag digunakan (yang dilakukan oleh paket linuxkit/binfmt ). Anda dapat menemukan informasi lebih lanjut tentang ini di sini .

Bisakah seseorang memberikan pengaturan yang berfungsi untuk mencoba buildkit? Saya tidak bisa membuatnya bekerja di Ubuntu. Pengaturan saya adalah sebagai berikut:

cat /etc/docker/daemon.json

{
  "experimental": true
}

Dockerfile

# syntax=docker/dockerfile:experimental

FROM ruby:2.6.3

RUN --mount=type=cache,target=/bundle/vendor

sudo docker -v

Docker versi 19.03.1, build 74b1e89

DOCKER_BUILDKIT=1 sudo docker build .

Respons kesalahan dari daemon: Baris kesalahan penguraian Dockerfile 12: Bendera tidak dikenal: mount

sudo tidak membawa env vars dengan itu kecuali Anda menyuruhnya dengan sudo -E atau mendeklarasikan variabel di dalam sudo.

Saya menulis beberapa kata tentang fitur ini dan membuat beberapa contoh minimal yang menunjukkan cara melakukan cache

• bundler dependensi menggunakan docker
• NPM dependensi menggunakan docker-compose

Sunting: lihat di bawah

@cpuguy83 terima kasih!

@thisismydesign maaf merusak kegembiraan Anda, tetapi Anda tidak bisa --cache node_modules , itu tidak akan ada di gambar akhir, jadi aplikasi Anda rusak.

@glensc Sial, Anda benar .. apakah ada cara untuk membuat cache waktu pembuatan bagian dari gambar akhir?

Sejujurnya, saya pikir ini akan dipertimbangkan untuk fitur yang diiklankan sebagai

memungkinkan wadah build untuk men-cache direktori untuk kompiler dan manajer paket.

Anda seharusnya dapat memetakan ~/.npm sebagai gantinya… https://docs.npmjs.com/files/folders.html#cache

@ini adalah desainku

Anda dapat menggunakan gambar lain sebagai cache, baik dengan membangunnya di Dockerfile Anda atau gambar literal yang disimpan di registri di suatu tempat dan menggunakan COPY --from

FROM example/my_node_modules:latest AS node_modules

FROM nodejs AS build
COPY --from=/node_modules node_modules 
...

Ini hanyalah sebuah contoh Anda dapat menggunakan ini untuk banyak hal yang berbeda.

Ugh aku benci membawa ini dan terlibat di sini (juga hai teman-teman)

tetapi kami memiliki kasus penggunaan untuk ini.

Apakah ada tempat yang bagus saya bisa terlibat atau panggilan atau daftar saya bisa bergabung untuk mendapatkan intisari di sini?

Juga jika kita membutuhkan seseorang untuk menaruh beberapa sumber daya ini saya punya 1 kris nova dan tim kecil saya mungkin bisa membujuk untuk melihat ini.

TLDR Bisakah saya mengkodekan ini? Apakah ada orang yang bisa saya ajak bicara tentang ini?

_TLDR_ Bisakah saya mengkodekan ini? Apakah ada orang yang bisa saya ajak bicara tentang ini?

Saya tidak dapat berbicara untuk Docker tetapi kesan saya adalah mereka tidak terbuka untuk menambahkan pemasangan volume ke build (dan mereka mungkin harus menutup masalah ini)

Banyak kasus penggunaan untuk buildtime -v sekarang dicakup oleh buildkit. Setidaknya itu telah menyelesaikannya untukku.

Saya akan memeriksa buildkit kemudian - Saya juga memiliki beberapa bash hacky yang menyelesaikan pekerjaan jika ada yang tertarik.

terima kasih @unilynx

+1 ke @unilynx saat menutup masalah ini, buildkit memecahkan masalah volume waktu build untuk saya juga.

Saya yakin jika seseorang menjatuhkan beberapa tautan dan sebuah contoh, kami dapat meyakinkan teman-teman kami untuk menekan tombol tutup yang mengilap.

(Saya juga akan mendapat manfaat dari mereka)

Kasus penggunaan caching tidak terpecahkan untuk saya dan banyak lainnya karena volume waktu build dengan buildkit tidak ada di gambar akhir.

Jadi saya dapat menarik semua artefak build saya dari volume sementara yang digunakan pada waktu build dan merekonstruksi gambar lagi dengan cache sebelumnya menggunakan bash yang saya sebutkan di atas.

Saya dapat membangun kembali gambar saya di atas dirinya sendiri sehingga sistem file overlay hanya mengambil delta kecil.

Saya bahkan dapat menggunakan kembali volume untuk gambar lain pada waktu pembuatan.

apakah orang lain tidak bisa melakukan ini?

(cache) mount berada di front-end "eksperimental"; dijelaskan dalam https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md (akan menuju ke rapat, tetapi saya dapat menautkan lebih banyak contoh yang diperluas)

terima kasih @thaJeztah LMK jika saya dapat membantu di sini dengan cara apa pun :)

https://github.com/moby/moby/issues/14080#issuecomment -547662701

@thisismydesign maaf merusak kegembiraan Anda, tetapi Anda tidak bisa --cache node_modules , itu tidak akan ada di gambar akhir, jadi aplikasi Anda rusak.

@thaJeztah Saya tidak percaya masalah di atas terpecahkan. Akan senang untuk melihat beberapa contoh di mana dimungkinkan untuk melakukan cache misalnya npm install selama waktu pembuatan yang juga akan memungkinkan gambar yang dihasilkan untuk menggunakan instalasi yang di-cache.

@kris-nova Saya tidak menyelesaikan masalah ini tetapi sekali lagi saya tidak ingin menggunakan skrip bash. Mungkin kita memerlukan masalah baru tetapi ini adalah kasus penggunaan yang cukup umum yang belum diselesaikan oleh AFAIK.

@thaJeztah Berikut adalah beberapa contoh menggunakan cache mount yang menunjukkan bagaimana gambar akhir tidak akan berisi mount dan di sana tidak mencakup banyak kasus penggunaan caching build-time:

• https://github.com/c-hive/basics/tree/558fbd91d45e56e574ebb05fb8645268d5b01974/docker-build-cache
• https://github.com/c-hive/basics/tree/558fbd91d45e56e574ebb05fb8645268d5b01974/docker-compose-build-cache

Untuk npm: Tidakkah seseorang menggunakan cache mount untuk direktori cache npm (lihat https://docs.npmjs.com/cli-commands/cache.html, biasanya ~/.npm )?

@ankon Itu bisa berhasil, terima kasih, saya akan mencobanya. Kasus penggunaan lain yang saya tidak yakin adalah Bundler dan Ruby.

Jadi saya pikir (belum menguji) untuk Bundler Anda setidaknya dapat menghilangkan ketergantungan jaringan dengan menggunakan volume build di $BUNDLE_PATH dan kemudian selama build

bundle install
bundle package
bundle install --standalone --local

Ini pada dasarnya berarti Anda memiliki direktori instal bundel yang di-cache, dari sana Anda mengemas permata ke ./vendor/cache dan menginstal ulang ke ./bundle . Tapi ini tidak menyisihkan waktu untuk menginstal dan membangun permata, itu mungkin benar-benar membuat langkah pembangunan lebih lama.

Jika Anda ingin menyimpan data yang di-cache ke dalam gambar, lalu salin ke dalam gambar dari cache.

Terima kasih, bagaimanapun, ini masih lebih merupakan solusi karena

• Anda harus melakukan salinan tambahan
• Saya berasumsi Anda harus memiliki direktori yang berbeda antara lingkungan build dan run (Anda tidak dapat menggunakan direktori tempat Anda memasang volume selama build, bukan?) sehingga memerlukan pengaturan tambahan

Saya tidak tahu berapa banyak usaha yang harus dilakukan untuk hanya memiliki opsi asli untuk memasang volume yang sama ke dalam gambar akhir, tetapi saya cukup yakin itu akan membuat penggunaannya lebih mudah. Ini hanya 2 contoh dari bahasa skrip di mana cara menggunakan cache ini tidak jelas bagi saya. Saya pasti bisa membayangkan ini akan muncul dalam konteks yang berbeda juga.

@thisismydesign Sepertinya yang Anda inginkan adalah dapat berbagi cache antara build dan run?

buildkit adalah satu-satunya solusi linux, apa yang kita lakukan di windows?

@thisismydesign Saya tidak yakin mengapa Anda mengharapkan mount (cache) tetap berada di gambar akhir. Saya tidak mengharapkan ini dan saya tidak ingin memiliki ~ 1gb di gambar saya hanya karena menggunakan unduhan cache mount.

buildkit adalah satu-satunya solusi linux, apa yang kita lakukan di windows?

Anda dapat menggunakan buildkit di Windows.

https://docs.docker.com/develop/develop-images/build_enhancements/

Anda mungkin merasa lebih mudah untuk mengatur pengaturan daemon melalui Docker untuk Windows UI daripada mengatur variabel lingkungan sebelum dijalankan.

@nigelgbanks di bagian atas tautan Anda:

Only supported for building Linux containers

Oh maaf saya hanya berasumsi Anda sedang membangun wadah Linux di Windows.

@thisismydesign Sepertinya yang Anda inginkan adalah dapat berbagi cache antara build dan run?

Itu akan menyelesaikan kasus penggunaan saya di sekitar caching, ya.

Membuat ini lebih mudah dapat menghemat jutaan unduhan ulang paket di CI
membangun per tahun.

Apakah ada layanan CI yang mendukung fitur buildkit eksperimental ?

Pada Sabtu, 13 Juni 2020, 14:08 Csaba Apagyi [email protected] menulis:

@thisismydesign https://github.com/thisismydesign Sepertinya apa
yang Anda inginkan adalah dapat berbagi cache antara build dan run?

Itu akan menyelesaikan kasus penggunaan saya di sekitar caching, ya.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/14080#issuecomment-643657987 , atau
berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAAMNS6IEQDCO5F3LNHJK5TRWO6AJANCNFSM4BJB2OOA
.

Apakah ada layanan CI yang mendukung fitur buildkit eksperimental ?

Apakah mereka harus secara eksplisit mendukungnya? Saya menggunakan gitlab-ci dengan buildkit dan itu berfungsi. Bagaimanapun, itu hanya cara yang berbeda untuk menjalankan 'docker build'.

Tentu saja, kecuali Anda membawa runner Anda sendiri ke gitlab, kemungkinan mendapatkan cache hit selama build tetap rendah.

Menyalin dari tahap bernama dari build multi-tahap adalah solusi lain

FROM golang:1.7.3 AS builder
COPY --from=builder

Tapi kemudian lokalitas gambar kontainer masih merupakan masalah yang sebagian besar belum terpecahkan untuk penjadwalan pekerjaan CI

Pelari harus lebih lengket dan membagikan gambar (menengah) dalam sistem file umum untuk meminimalkan permintaan yang tidak perlu ke repo paket (yang selalu kekurangan dana).

Saya baru saja mencoba buildkit tetapi itu hanya sedikit meningkatkan alur kerja saya, yang akan 100% dibantu oleh volume "nyata" atau pengikatan mount ke Host.

Saya menggunakan docker build untuk mengkompilasi silang versi glibc lama yang kemudian harus menjadi bagian dari wadah build baru yang menyediakan glibc s ini untuk dibangun di bawah dan ditautkan.

Sekarang unduhan sumber glibc yang berulang diselesaikan dengan pengikatan (dari buildkit ), arsip hanya dapat dibaca, tidak masalah. Tetapi saya tidak memiliki cara untuk mengakses direktori build untuk analisis setelah build yang gagal, karena container gagal karena kesalahan. (Jika saya memulai ulang untuk mengaksesnya, itu memulai ulang build, jadi itu tidak membantu).

Juga, saya gagal untuk melihat mengapa saya harus melompat melalui lingkaran seperti membangun wadah baru dari yang lama hanya untuk menyingkirkan direktori build saya, di mana jika direktori build akan menjadi mount di tempat pertama, itu akan menjadi begitu mudah. (Lakukan make install setelah build dan saya memiliki wadah bersih tanpa build dir dan tanpa sumber yang diunduh).

Jadi saya masih percaya ini adalah permintaan fitur yang sangat valid dan akan membuat hidup kita jauh lebih mudah. Hanya karena suatu fitur dapat disalahgunakan dan dapat merusak fungsi lain jika digunakan, tidak berarti harus dihindari untuk mengimplementasikannya dengan cara apa pun. Anggap saja itu penggunaan ekstra untuk alat yang lebih kuat.

Tapi saya tidak punya cara untuk mengakses direktori build untuk analisis setelah build gagal

Kedengarannya seperti permintaan fitur untuk buildkit. Ini jelas merupakan bagian yang hilang yang diketahui.

Seseorang dapat melakukan ini hari ini dengan memiliki target untuk mengambil "build dir". Anda baru saja menjalankannya setelah gagal dijalankan, semuanya masih harus di-cache, hanya perlu langkah terakhir untuk mengambil data.
Pahami ini sedikit solusi.

Juga, saya gagal melihat mengapa saya harus melompati rintangan seperti membangun wadah baru dari yang lama hanya untuk menyingkirkan direktori build saya

Bisakah Anda menjelaskan lebih lanjut apa yang Anda inginkan/harapkan di sini?

Bisakah Anda menjelaskan lebih lanjut apa yang Anda inginkan/harapkan di sini?

Dalam hal ini hanya ingin membunuh 2 burung dengan 1 batu:

• memiliki cara mudah untuk mengakses hasil antara dari host (di sini "build dir analysis")
• pastikan ruang penyimpanan ini tidak mencemari gambar yang baru dibuat

Karena ini, dan semua kasus lain di mana wadah build (serta "container build") perlu membuat bangunan semudah mungkin, akan diselesaikan jauh lebih elegan dengan hanya menyediakan fungsionalitas -v , saya punya kesulitan memahami penolakan untuk menyediakan fitur ini. Terlepas dari fungsionalitas "cache-aware" yang tampaknya ditawarkan buildkit , saya hanya dapat melihatnya sebagai cara yang berbelit-belit dan tidak praktis untuk mencapai fungsi ini, dan hanya sebagian saja. (Dan dalam banyak kasus di mana caching adalah tujuan utama, itu juga akan diselesaikan dengan -v , dengan biaya harus mengunci volume yang dipasang ke wadah tertentu selama itu berjalan, tetapi cache dengan buildkit memiliki batasan yang sama.)

Bisakah Anda menjelaskan lebih lanjut apa yang Anda inginkan/harapkan di sini?

Saya menggunakan proses build multi-tahap, di mana lingkungan build itu sendiri ditampung, dan hasil akhirnya adalah gambar yang hanya berisi aplikasi dan lingkungan runtime (tanpa alat build).

Apa yang saya inginkan adalah beberapa cara untuk Docker build container interim untuk menghasilkan pengujian unit dan file hasil cakupan kode ke sistem Host jika build yang berhasil dan build yang gagal, tanpa harus meneruskannya ke gambar output build untuk ekstraksi (karena seluruh proses build mengalami hubungan pendek jika unit test tidak lulus pada langkah sebelumnya, jadi tidak akan ada gambar output dalam situasi itu, dan saat itulah kami paling membutuhkan hasil unit test) . Saya pikir jika volume Host dapat dipasang ke proses pembuatan Docker, maka perintah pengujian internal dapat mengarahkan outputnya ke folder yang dipasang.

@mcattle
Memang sangat mirip juga dengan (salah satu fungsi) yang saya butuhkan.
Sejak pindah ke buildah beberapa hari yang lalu saya mendapatkan setiap fungsi yang saya butuhkan dan banyak lagi. Men-debug wadah build saya sama sekali tidak mungkin tanpa kemungkinan untuk secara fleksibel memasukkan wadah yang keluar dan menautkan ke Host. Sekarang saya seorang kemping yang bahagia. (Saya minta maaf membuat pesta dengan "pesaing", saya akan dengan senang hati menghapus komentar ini jika ada pelanggaran, tetapi itu adalah solusi yang sangat efektif untuk kasus penggunaan yang disajikan di utas ini sehingga saya pikir saya harus menyebutkannya) .

Tidak ada salahnya mengatakan alat lain lebih sesuai dengan kebutuhan Anda.

Jika sesuatu bekerja untuk Anda, itu luar biasa.

Kekurangan dari pembuat v1 di Docker dan pembuat buildkit cukup dipahami dengan baik dalam konteks ini, dan sedang mencari cara untuk mengatasinya, sebaiknya tanpa harus menggunakan pengikatan tunggangan dari klien.
Notifikasi [email protected] menulis:
“@mcattle
Memang sangat mirip juga dengan (salah satu fungsi) yang saya butuhkan.
Sejak pindah ke buildah beberapa hari yang lalu saya mendapatkan setiap fungsi yang saya butuhkan dan banyak lagi. Men-debug wadah build saya sama sekali tidak mungkin tanpa kemungkinan untuk secara fleksibel memasukkan wadah yang keluar dan menautkan ke Host. Sekarang saya seorang kemping yang bahagia. (Saya minta maaf membuat pesta dengan "pesaing", saya akan dengan senang hati menghapus komentar ini jika ada pelanggaran, tetapi itu adalah solusi yang sangat efektif untuk kasus penggunaan yang disajikan di utas ini sehingga saya pikir saya harus menyebutkannya) .”

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau berhenti berlangganan.

tanpa harus menggunakan pengikatan tunggangan dari klien.

Di sini saya menjelaskan mengapa opsi build time -v tidak menggunakan atau mengorbankan reproduktifitas lebih dari bergantung pada sumber daya jaringan pada waktu build.

https://github.com/moby/moby/issues/14080#issuecomment -484314314 :

SALIN || REMOTE_FETCH || Baca()

• Manakah dari ini yang paling dapat direproduksi?

Saya akan menggunakan buildah untuk waktu pembuatan -v (dan cgroupsv2) juga.

@mcattle Saya memiliki persyaratan yang sama. Saya menyelesaikannya dengan pelabelan .

Saya akan menggunakan buildah untuk waktu pembuatan -v (dan cgroupsv2) juga.

Saya serius mempertimbangkan beralih dari Ubuntu (yang baru saja buruh pelabuhan) ke Fedora (yang telah menggantikan buruh pelabuhan dengan podman/buildah) di server build kami karena dukungan "-v".

Omong-omong. Podman juga mendukung mode rootless, dan sejauh ini tampaknya sepenuhnya kompatibel dengan Docker (kecuali untuk perbedaan dalam dampak --user/USER, dan cache gambar, yang berasal dari penggunaan mode rootless alih-alih dijalankan sebagai root seperti yang dilakukan daemon Docker).

PS. sementara cgroups v2 diperlukan untuk operasi tanpa akar, dukungan untuk itu lebih tentang runtime kontainer, daripada buruh pelabuhan. Jika Anda menggunakan CRun alih-alih RunC (seperti yang dilakukan Fedora), Anda akan memiliki dukungan cgroups v2. RunC memang memiliki beberapa dukungan v2 & rootless di Git, tetapi saya memiliki beberapa masalah saat mengujinya di Fedora (31) beberapa bulan yang lalu.

EDIT: Ubuntu memiliki podman/buildah/etc di Groovy, hanya saja tidak di 20,04 LTS terbaru, saya pikir diimpor dari Debian tidak stabil. Itu belum di-backport ke LTS, setidaknya belum. Padahal sudah di Fedora sejak 2018 saya kira.

@eero-t mungkin Anda bisa menjelaskan kasus penggunaan Anda, dan apa yang hilang dalam opsi yang disediakan BuildKit saat ini yang tidak ditujukan untuk itu.