Moby: SALIN dengan file yang dikecualikan tidak dimungkinkan

Dibuat pada 22 Agu 2015  ·  82Komentar  ·  Sumber: moby/moby

Saya perlu MENYALIN _bagian_ dari direktori konteks ke wadah (bagian lain tunduk pada SALINAN lain). Sayangnya, kemungkinan saat ini untuk ini kurang optimal:

  1. SALIN dan pangkas. Saya dapat menghapus materi yang tidak diinginkan setelah SALIN tanpa batas. Masalahnya adalah materi yang tidak diinginkan mungkin telah berubah, sehingga cache menjadi tidak valid.
  2. SALIN setiap file dalam instruksi SALIN itu sendiri. Ini menambahkan _lot_ lapisan yang tidak perlu ke gambar.
  3. Menulis pembungkus di sekitar panggilan "docker build" yang mempersiapkan konteks dalam beberapa cara sehingga Dockerfile dapat dengan nyaman menyalin materi yang diinginkan. Rumit dan sulit perawatannya.
arebuilder kinenhancement kinfeature

Komentar yang paling membantu

+1 untuk masalah ini, saya pikir itu dapat didukung dengan cara yang sama dengan banyak perpustakaan glob yang mendukungnya:

Berikut adalah proposal untuk menyalin semuanya kecuali node_modules

COPY . /app -node_modules/

Semua 82 komentar

Lihat https://docs.docker.com/reference/builder/#dockerignore -file
Anda dapat menambahkan entri ke file .dockerignore di root proyek.

.dockerignore tidak menyelesaikan masalah ini. Seperti yang saya tulis, "bagian lain tunduk pada SALINAN lain".

Jadi Anda ingin menyalin secara kondisional berdasarkan salinan lain?

Konteksnya berisi banyak direktori A1...A10 dan direktori B. A1...A10 memiliki satu tujuan, B memiliki yang lain:

COPY A1 /some/where/A1/
COPY A2 /some/where/A2/
...
COPY A10 /some/where/A10/
COPY B some/where/else/B/

Dan ini canggung.

Bagian mana yang canggung? Daftar semuanya satu per satu?

COPY A* /some/where/
COPY B /some/where/else/

Apakah ini bekerja?

Nama A1..A10, B palsu. Selain itu, COPY A* ... menggabungkan _contents_ direktori.

Ada beberapa opsi yang saya akui, tetapi saya pikir semuanya canggung. Saya menyebutkan tiga di posting asli saya. Opsi keempat adalah mengatur ulang kode sumber saya secara permanen sehingga A1..A10 dipindahkan ke direktori baru A. Saya berharap ini tidak perlu karena level bersarang tambahan bukanlah sesuatu yang diinginkan, dan alat saya saat ini diperlukan untuk kasus khusus proyek buruh pelabuhan saya saat itu.

(BTW, #6094 (symlink berikut) akan membantu dalam kasus ini. Namun tampaknya, ini juga bukan pilihan.)

@bronger jika COPY berperilaku persis seperti cp , apakah itu akan menyelesaikan kasus penggunaan Anda?

Saya tidak yakin saya 100% mengerti.
Mungkin @duglin bisa lihat.

@bronger Saya pikir @cpuguy83 mengajukan pertanyaan yang tepat, bagaimana Anda akan menyelesaikan ini jika Anda menggunakan 'cp' ? Saya melihat dan tidak melihat semacam opsi pengecualian pada 'cp' jadi saya tidak yakin bagaimana Anda akan menyelesaikan ini di luar 'docker build' juga.

Dengan perilaku cp, saya bisa memperbaiki situasi dengan mengatakan

COPY ["A1", ... "A10", "/some/where/"]

Ini masih merupakan masalah pemeliharaan ringan karena saya harus memikirkan baris itu jika saya menambahkan direktori "A11". Tapi itu bisa diterima.

Selain itu, cp tidak perlu dikecualikan, karena menyalin semuanya dan menghapus bagian yang tidak diinginkan hampir tidak memiliki dampak kinerja di luar penyalinan itu sendiri. Dengan COPY buruh pelabuhan, itu berarti cache yang salah tidak valid setiap kali B diubah, dan gambar lebih besar.

@bronger yang dapat Anda lakukan:

COPY a b c d /some/where

seperti yang Anda sarankan.

Adapun melakukan RUN rm ... setelah COPY ... , ya Anda akan memiliki lapisan tambahan, tetapi Anda masih harus dapat menggunakan cache. Jika Anda melihat cache hilang karena itu, beri tahu saya, saya rasa Anda tidak harus melakukannya.

Tetapi

COPY a b c d /some/where/

menyalin isi direktori abcd bersama-sama, alih-alih membuat direktori /some/where/{a,b,c,d}. Ini berfungsi seperti rsync dengan garis miring ditambahkan ke direktori src. Oleh karena itu, _empat_ instruksi

COPY a /some/where/a/
COPY b /some/where/b/
COPY c /some/where/c/
COPY d /some/where/d/

dibutuhkan.

Adapun cache ... jika saya katakan

COPY . /some/where/
RUN rm -Rf /some/where/e

maka cache tidak digunakan jika e berubah, meskipun e tidak secara efektif dimasukkan ke dalam operasi.

@bronger ya, sayangnya Anda benar. Saya kira kita dapat menambahkan jenis flag --exclude zzz , tetapi per https://github.com/docker/docker/blob/master/ROADMAP.md#22 -dockerfile-syntax mungkin tidak mendapatkan banyak traksi sekarang.

Cukup adil. Kemudian saya akan menggunakan COPY+rm untuk saat ini dan menambahkan komentar FixMe. Terima kasih atas waktu Anda!

Hanya untuk :+1: masalah ini. Saya secara teratur menyesal bahwa COPY tidak mencerminkan semantik garis miring rsync. Ini berarti Anda tidak dapat MENYALIN beberapa direktori dalam satu pernyataan, yang mengarah ke proliferasi lapisan.

Saya sering menemukan kasus di mana saya ingin menyalin banyak direktori kecuali satu (yang akan disalin nanti, karena saya ingin memiliki efek pembatalan lapisan yang berbeda), jadi --exclude juga akan berguna.

Juga, dari man rsync :

       A trailing slash on the source changes this behavior to avoid  creating
       an  additional  directory level at the destination.  You can think of a
       trailing / on a source as meaning "copy the contents of this directory"
       as  opposed  to  "copy  the  directory  by name", but in both cases the
       attributes of the containing directory are transferred to the  contain‐
       ing  directory on the destination.  In other words, each of the follow‐
       ing commands copies the files in the same way, including their  setting
       of the attributes of /dest/foo:

              rsync -av /src/foo /dest
              rsync -av /src/foo/ /dest/foo

Saya kira itu tidak dapat diubah sekarang tanpa merusak banyak Dockerfile liar.

Sebagai contoh konkret, katakanlah saya memiliki direktori yang terlihat seperti ini:

/vendor
/part1
/part2
/part3
/...
/partN

Saya ingin sesuatu yang terlihat seperti:

COPY /vendor /docker/vendor
RUN /vendor/build
COPY /part1 /part2 ... /partN /docker/ # copy directories part1-N to /docker/part{1..N}/
RUN /docker/build1-N.sh

Sehingga part1-N tidak membatalkan pembuatan /vendor . (karena /vendor jarang diperbarui dibandingkan dengan part1-N).

Saya sebelumnya telah mengatasi ini dengan meletakkan part1-N di direktori mereka sendiri, jadi:

/vendor
/src/part1-N

Tetapi saya juga mengalami masalah ini dalam proyek-proyek yang tidak dapat saya atur ulang dengan mudah.

@praller contoh bagus, kami menghadapi masalah yang sama persis. Masalah utamanya adalah filepath.Match milik Go tidak memungkinkan banyak kreativitas dibandingkan dengan ekspresi reguler (yaitu tidak ada pola anti)

Saya baru saja menemukan solusi yang agak gila untuk ini. SALIN tidak dapat mengecualikan direktori, tetapi ADD _can_ perluas tgz.

Ini satu langkah build tambahan:
tar --exclude='./deferred_copy' -czf all_but_deferred.tgz .
membangun buruh pelabuhan...

Kemudian di Dockerfile Anda:
TAMBAHKAN ./all_but_deferred.tgz /application_dir/
.. barang-barang di lapisan yang jarang berubah ..
MENAMBAHKAN . /aplikasi_dir/
.. hal-hal di lapisan yang sering berubah

Itu memberikan sintaks tar penuh untuk memasukkan/mengecualikan/apa pun tanpa kumpulan lapisan yang terbuang yang mencoba memasukkan/mengecualikan.

@jason-kane Ini trik yang bagus, terima kasih telah berbagi. Satu poin kecil: sepertinya Anda tidak dapat menambahkan flag z (gzip) ke tar —ini mengubah nilai checksum sha256, yang membatalkan cache Docker. Kalau tidak, pendekatan ini sangat cocok untuk saya.

+1 untuk masalah ini, saya pikir itu dapat didukung dengan cara yang sama dengan banyak perpustakaan glob yang mendukungnya:

Berikut adalah proposal untuk menyalin semuanya kecuali node_modules

COPY . /app -node_modules/

Saya juga menemukan masalah yang sama, dan agak menyakitkan bagi saya ketika aplikasi web Java saya sekitar 900MB tetapi hampir 80% dari itu jarang diubah.
Ini adalah keadaan awal aplikasi saya dan struktur folder agak stabil jadi saya tidak keberatan menambahkan 6-7 lapisan COPY untuk dapat menggunakan cache, tetapi itu pasti akan merugikan dalam jangka panjang ketika semakin banyak file dan direktori sudah ditambahkan

👍

Saya memiliki masalah yang sama meskipun dengan docker cp , saya ingin menyalin semua file dari folder kecuali satu

Masalah yang sama persis di sini. Saya ingin menyalin git repo dan mengecualikan direktori .git.

@oaxlin Anda bisa menggunakan file .dockerignore untuk itu.

@antoineco apakah Anda yakin itu akan berhasil? Sudah lama sejak saya mencoba tetapi saya cukup yakin .dockerignore tidak bekerja dengan docker cp , setidaknya pada saat itu

@kkozmic-seek benar-benar yakin :) Tapi perintah docker cp CLI yang Anda sebutkan berbeda dari pernyataan COPY yang ditemukan di Dockerfile, yang merupakan ruang lingkup masalah ini.

docker cp memang tidak ada hubungannya dengan Dockerfile dan . dockerignore, tetapi di sisi lain itu tidak digunakan untuk membangun gambar.

Akan sangat menyukai ini juga - untuk mempercepat build, saya dapat menyalin beberapa folder di bagian awal build dan kemudian cache akan membantu saya ...

Saya tidak yakin saya mengerti apa kasus penggunaannya tetapi tidakkah hanya menyentuh file untuk dikecualikan sebelum SALIN menyelesaikan masalah?

RUN touch /app/node_modules
COPY . /app
RUN rm /app/node_modules

AFAIK COPY tidak menimpa file itulah sebabnya saya pikir ini mungkin berhasil.

Ups, tidak apa-apa, sepertinya COPY benar-benar menimpa file. Saya sekarang agak bingung dengan https://nodejs.org/en/docs/guides/nodejs-docker-webapp/ yang npm instal dan kemudian lakukan COPY . /usr/src/app . Saya kira itu mengasumsikan bahwa node_modules adalah buruh pelabuhan diabaikan? Di sisi lain, memiliki perintah COPY_NO_OVERWRITE (nama yang lebih baik diperlukan) bisa menjadi salah satu cara untuk mengabaikan file selama penyalinan (Anda harus membuat file/dir kosong untuk hal-hal yang ingin Anda abaikan).

FWIW, menurut saya ini sangat jelek.

Saya menemukan solusi peretasan lain:

Contoh struktur proyek:
aplikasi/
konfigurasi/
naskah/
spesifikasi/
statis/
...

Kami ingin:

  1. Salin statis/
  2. Salin file lain
  3. Salin aplikasi/

Solusi peretasan:
ADD ./static /home/app
ADD ["./[^s^a]*", "./s[^t]*", "/home/app/"]
ADD ./app /home/app

ADD kedua setara dengan: salin semua, kecuali "./st " dan "./a ".
Ada ide untuk perbaikan?

Yang mana status komentarnya ?

👍

👍

👍

👍

bagaimana dengan memiliki file .dockerignore dengan cara yang sama dengan .gitignore?

@mirestrepo Lihat dua tindak lanjut pertama untuk masalah ini.

Saat ini ini adalah mega perf nerf untuk pengembangan C# / dotnet.

Apa yang saya inginkan:

  • Pertama-tama salin semua dll eksternal ke gambar buruh pelabuhan (semuanya kecuali My*.dll)
  • Kemudian salin semua dll saya (dimulai dengan My.*.dll).

Sekarang sepertinya ini tidak (mudah) mungkin karena saya tidak dapat menyalin semuanya kecuali.

Jadi baik dll disalin ganda Yang meningkatkan ukuran file buruh pelabuhan atau semuanya disalin dalam satu lapisan.
Yang kemudian menjadi mega nerf karena dll eksternal disalin setiap kali alih-alih di-cache.

@adresdvila terima kasih atas solutoin yang dapat saya bagi menjadi:

COPY ["[^M][^y]*","/app/"] 
COPY ./My* /app/

Meskipun ini masih menyisakan masalah bahwa file .json disalin pada perintah pertama

Hanya menimpali untuk mengucapkan terima kasih kepada @antoineco masalah saya terpecahkan. Saya tidak lagi menyalin direktori .git ke gambar buruh pelabuhan saya.

Ini secara dramatis meningkatkan ukuran gambar, dan membuat gambar saya jauh lebih bersahabat dengan sistem caching buruh pelabuhan.

Saya memiliki masalah yang sama. Saya memiliki file besar yang ingin saya salin sebelum file lainnya sehingga setiap perubahan dalam konteks tidak mengulanginya karena butuh banyak waktu untuk menyalin (file bin 7 GB). Apakah ada solusi baru?

Masalah dengan pendekatan SALIN dan pangkas adalah bahwa lapisan sebelum pemangkasan masih terus memiliki semua data.

COPY . --exclude=a --exclude=b akan sangat berguna. Bagaimana menurut Anda, @cpuguy83?

@Nowaker saya menyukainya. Tampaknya sejalan dengan tar dan rsync .
Saya kira ini harus mendukung format yang sama dengan dockerignore?

@tonistiigi @dnephin

Kasus ini akan ditangani oleh #32507 kurasa.

@cpuguy83 Ya. Terutama, sejalan dengan COPY --chown=uid:gid

@dnephin RUN --mount terdengar seperti kasus penggunaan yang sama sekali berbeda, berpusat pada menghasilkan sesuatu berdasarkan data yang tidak kita perlukan setelah output dihasilkan. (Misalnya kompilasi dengan Go, menghasilkan HTML dari file penurunan harga, dll). RUN --mount adalah obat bius dan saya pasti akan menggunakannya dalam proyek yang sedang saya kerjakan (menghasilkan dokumen API menggunakan Sphinx).

COPY somedir --exclude=excludeddir1 --exclude=excludeddir2 berpusat pada penyalinan data yang harus berakhir di gambar tetapi tersebar di beberapa pernyataan SALIN, bukan hanya satu. Tujuannya adalah untuk menghindari COPY first second third .... eleventh destination/ eksplisit ketika proyek memiliki banyak direktori di root dan dapat diubah/ditambah.

Dalam kasus saya, saya ingin menyalin sebagian besar file kecuali yang tidak penting terlebih dahulu untuk memastikan cache digunakan jika file sumber tidak berubah. Kemudian, kompilasi/hasilkan - dan gunakan cache jika file yang disalin tidak berubah (yay). Pada awalnya salin file yang saya kecualikan sebelumnya yang mungkin telah berubah sejak build sebelumnya tetapi perubahannya tidak memengaruhi kompilasi/hasilkan. Jelas, saya memiliki banyak sekali file dan direktori di . yang ingin saya SALIN terlebih dahulu, dan hanya beberapa yang ingin saya SALIN di suatu tempat di akhir.

Idenya adalah RUN --mount mampu memecahkan banyak masalah. COPY --exclude hanya memecahkan satu masalah.

Saya lebih suka menambahkan sesuatu yang memecahkan banyak masalah daripada menambahkan banyak sintaks untuk memecahkan masalah individu. Anda akan menggunakan RUN --mount... rsync --exclude ... (atau beberapa skrip yang menyalin hal-hal individual) dan itu akan setara dengan COPY --exclude .

@dnephin Oh, saya tidak memikirkan RUN --mount rsync ! Bagus sekali! 👍

Itu bagus sekali. Namun Anda tidak akan dapat memanfaatkan caching secara efisien @Nowaker , karena cache akan menjadi tidak valid jika ada perubahan pada direktori yang dipasang, bukan hanya apa yang ingin Anda rsync.

Jika Anda menggunakan output rsync itu sebagai input untuk sesuatu yang lain dan tidak ada file yang benar-benar berubah di sana, cache akan mengambil lagi. Jika Anda benar-benar siap, Anda dapat melakukannya saat ini dengan sesuatu seperti https://Gist.github.com/tonistiigi/38ead7a4ed60565996d207a7d589d9c4#file -gistfile1-txt-L130-L140 . Satu-satunya perubahan di RUN --mount (atau LLB di buildkit) adalah Anda tidak harus benar-benar menyalin file di antara tahapan tetapi dapat mengaksesnya secara langsung sehingga jauh lebih cepat.

Bagaimana dengan menggunakan https://docs.docker.com/develop/develop-images/multistage-build/?

FROM php:7.2-apache as source
COPY ./src/ /var/www/html/
RUN rm -rf /var/www/html/vendor/
RUN rm -rf /var/www/html/tests/

FROM php:7.2-apache
COPY --from=source /var/www/html/ /var/www/html/

@antoineco Ya ampun , maka itu tidak bagus lagi. Terima kasih telah menunjuk..

@MartijnHols Ini adalah solusi yang baik. Terima kasih telah memposting.

Untuk pengelola: yang mengatakan, kami dapat mengatakan "mengapa mengimplementasikan --chown di COPY, Anda dapat menggunakan RUN chown dalam build multi-tahap". Kami membutuhkan --exclude untuk kewarasan. Ada terlalu banyak solusi di Dockerfiles hari ini.

Saya memiliki kasus penggunaan yang akan mendapat manfaat dari COPY --exclude . Saya memiliki folder data besar yang perlu disalin ke dalam wadah secara keseluruhan. Isi direktori itu sering berubah. Untuk meningkatkan kinerja cache, ada satu file besar di direktori yang ingin saya salin ke lapisannya sendiri, sebelum menyalin sisanya. Sampai sekarang, tidak perlu bertele-tele untuk menggambarkan jenis wadah ini.

Apa cara yang benar untuk menggunakan caching berlapis yang berpusat di sekitar requirements.txt?

Aku punya ini:

/root-app
 - /Dockerfile
 - /requirements.txt
 - /LICENSE
 - /helloworld.py
 - /app-1
     -/app-1/script1
     -/app-1/script2
     -/app-1/script3
 - /app-2
     -/app-2/script1

Dan Dockerfile:

FROM python:slim
COPY ./requirements.txt /
RUN pip install --trusted-host pypi.python.org -r /requirements.txt
WORKDIR /root-app
COPY . /helloworld
CMD ["python", "helloworld.py"]

Apa cara yang benar untuk menggunakan perintah COPY kedua untuk mengecualikan persyaratan build cache ... dan juga melapisi app-1 dan app-2 saya jika tidak banyak berubah?

@axehayz Tidak yakin apakah ini yang Anda minta, tetapi saya akan melakukan sesuatu yang mirip dengan alur kerja simpul di https://medium.com/@guillaumejacquart/node -js-docker-workflow-12febcc0eed8.

Yaitu tidak apa-apa untuk salinan kedua Anda menjadi COPY . ; selama pip install Anda datang sebelumnya, ini tidak akan membatalkan cache untuk paket yang diinstal.

Menghadapi masalah yang sama. Saat ini saya lebih suka memperluas file di direktori yang berbeda.

Saya memiliki kasus lain untuk COPY --exclude=... --exclude=...

Saya mencoba melakukan COPY --from=oldimage untuk mengurangi ukuran gambar saya dan saya perlu menyalin sebagian besar file, tetapi tanpa beberapa file. Saya dapat melakukannya direktori demi direktori, yang menyakitkan, tetapi berhasil ... Tetapi dapat --mengecualikan daftar direktori/file atau menyediakan beberapa --exclude opsi akan jauh lebih baik dan lebih mudah untuk dipelihara.

Jadi setelah tiga setengah tahun tidak ada pengakuan sama sekali?

@asimonf Ada banyak pengakuan dan bolak-balik untuk memahami kasus penggunaan. Saya berasumsi maksud Anda tidak ada yang melakukan pekerjaan ini? Itu betul. Kita semua harus membuat pilihan pada hal-hal yang kita kerjakan.

Sejujurnya ini dapat dilakukan dengan cukup mudah menggunakan fungsionalitas yang ada meskipun itu berarti Anda harus menulis sedikit tambahan di Dockerfile Anda untuk mewujudkannya.

# haven't tested exact syntax, but this is the general idea
FROM myRsync AS files
COPY . /foo
RUN mkdir /result && rsync -r --exclude=<pattern> /foo/ /result/

FROM scratch
COPY --from=files /result/* /

Dengan buildkit Anda bahkan tidak memerlukan panggung tambahan

#syntax=docker/dockerfile:experimental
..
RUN --mount=target=/ctx rsync ... /ctx/ /src/

Kecuali saya melewatkan sesuatu menggunakan build multi-tahap sepertinya bukan solusi di sini. Cache masih tidak valid pada tahap COPY.

Kecuali saya melewatkan sesuatu menggunakan build multi-tahap sepertinya bukan solusi di sini. Cache masih tidak valid pada tahap COPY.

Ini benar. Karena itu adalah masalah yang saya alami saat ini.

Multi-tahap sangat bagus untuk saya.

Saya memecah bangunan saya menjadi multi-tahap, untuk sepenuhnya memanfaatkan cache, terlihat seperti ini:

FROM alpine as source

WORKDIR /app
COPY . ./
RUN scripts/stagify-files

FROM node:12.4.0

WORKDIR /app

# Step 0: Setup environments
COPY --from=source /app/stage0 ./
RUN stage0-build.sh

# Step 1: Install npm packages
COPY --from=source /app/stage1 ./
RUN stage1-build.sh

# Step 2: Build project
COPY --from=source /app/stage2 ./
RUN stage2-build.sh

@zenozen tantangan dengan proses itu adalah Anda harus mengatur tata letak aplikasi Anda secara khusus untuk pembangunan buruh pelabuhan, sesuatu yang tidak ingin dilakukan banyak orang.
Menggunakan buruh pelabuhan adalah salah satu dari banyak pertimbangan yang harus diseimbangkan saat mencari tahu cara mengatur tata letak file aplikasi Anda (misalnya pemeliharaan, kemudahan penggunaan untuk karyawan baru, standar lintas proyek, persyaratan kerangka kerja, dll).

@cfletcher Saya tidak yakin saya sepenuhnya mengerti apa yang Anda maksud.

Untuk perubahan yang saya sebutkan di atas, saya benar-benar memindahkan Dockerfile saya ke sub-sub-direktori (yang menyebabkan saya banyak masalah ketika mencoba menggunakan rsync untuk membuat file-file tersebut stagify), artinya saya mencoba menyembunyikan Dockerfile saya.

Pendekatan yang saya usulkan bersifat umum seperti yang saya bayangkan. Katakanlah Anda memiliki 100 file dalam proyek Anda. Itu hanya memilih 1 dari mereka membuat tahap0, lalu 1+10 dari mereka untuk membuat tahap 1, dan kemudian semua 100 untuk membentuk tahap 2. Setiap tahap ditumpuk di atas yang sebelumnya, dan memiliki perintah build yang berbeda. Untuk struktur proyek yang rumit, itu berarti logika file stagify akan rumit.

Bagi saya, alasan terbesar adalah saya membagi kode saya menjadi beberapa modul, dan saya membutuhkan semua file package.json disalin sebelum menjalankan npm install .

Juga ingin semacam mengecualikan argumen untuk salinan. Kami memiliki 20+ file dan 10+ direktori di direktori root. Kami banyak membuat kode pada 2 direktori dan beberapa file. Saya ingin membagi ini menjadi dua lapisan SALIN. Satu untuk file dan direktori statis yang tidak pernah kita sentuh, dan yang lainnya untuk file dan direktori yang selalu kita sentuh.

Sangat disayangkan hal ini masih diabaikan. Ini akan membantu saya menghemat 5 menit per build jika saya dapat mengecualikan SATU direktori untuk tidak membatalkan cache.

Dengan buildkit, cache tidak bergantung pada gambar induk seperti pra-buildkit.
Jadi ya dengan solusi rsync yang disebutkan, Anda akan menerima pukulan karena Anda harus menyinkronkan setiap kali ada beberapa perubahan, tetapi tahap selanjutnya akan di-cache berdasarkan konten, dan jika konten yang ditransfer tidak diubah maka. .. setidaknya dalam teori saya lengkap di tempat, tahap-tahap itu harus menggunakan cache.

Sangat menyedihkan menambahkan flag --exclude sederhana ke COPY adalah penjualan yang sulit. Itu ada di TOP30 tiket yang paling banyak dipilih , dan implementasinya relatif mudah dibandingkan dengan tiket TOP30 lainnya. :(

Ini tidak kontroversial, itu membutuhkan pekerjaan.

@cpuguy83 Yay. Sepertinya kontroversial / agak ditolak. Apakah ini berarti PR yang layak dengan COPY --exclude kemungkinan besar akan diterima, jika melewati standar kualitas?

Saya tidak dapat berbicara untuk setiap pengelola, tetapi saya telah berbicara dengan @tonistiigi sekitar sebulan yang lalu tentang ini dan IIRC rintangan terbesar bagaimana hal ini berkaitan dengan dockerignore, sintaks, dll. (dan fakta bahwa dockerignore tidak mencukupi secara sintaksis).

Perubahan harus masuk ke buildkit.

Upvoting COPY --exclude=... --exclude=... - juga diperlukan dalam kasus repo monolit saya

Mendukung! Saya mencoba dengan COPY !(excludedfile) . yang seharusnya berfungsi di Bash tetapi tidak di Docker

Saya tidak suka saran untuk mengulang semua yang ada di dalam file .dockerignore untuk setiap COPY pernyataan dalam Dockerfile . Mampu tetap KERING dengan apa yang akan menjadi bagian dari gambar dan tidak harus menjadi prioritas, imho.

Melihat #33923, saya tidak berpikir itu kebetulan bahwa apa yang ingin Anda kecualikan dari konteks build adalah hal yang sama persis dengan yang Anda inginkan untuk dikecualikan dari pernyataan COPY . Saya percaya sesuatu seperti ini akan menjadi solusi yang baik:

COPY --use-dockerignore <source> <target>

Atau mungkin bahkan sesuatu seperti ini:

COPY --use-ignorefile=".gitignore" <source> <target>

Melihat bagaimana .dockerignore biasanya merupakan reproduksi 90% dari .gitignore , rasanya sangat menjengkelkan harus mengulang setiap file dan folder yang diabaikan lagi untuk setiap pernyataan COPY . Harus ada cara yang lebih baik.

@asbjornu .gitignore dan .dockerignore bukanlah hal yang sama sama sekali. Khususnya untuk bangunan multitahap di mana artefak dihasilkan pada tahap pembangunan dan tidak ada di git sama sekali, namun demikian harus disertakan dalam gambar yang dihasilkan.
Dan ya, dengan diperkenalkannya multistage build, HARUS ADA kemampuan untuk menggunakan file .dockerignore yang berbeda per tahap - tentu saja.

Saya sering ingin menyalin di luar "docker build". Dalam kasus ini, .dockerignore tidak melakukan apa-apa. Kami membutuhkan amandemen untuk "docker cp" itu satu-satunya solusi yang masuk akal

Sudah 5 tahun masalah ini dibuka. Di bulan September 2020, saya masih menginginkan ini. Banyak orang telah menyarankan peretasan untuk mengatasinya tetapi hampir semuanya dan yang lain telah meminta tanda exclude dalam beberapa bentuk atau lainnya. Tolong jangan biarkan masalah ini tidak terselesaikan untuk lebih banyak waktu sekarang.

Jika Anda menginginkan sesuatu, Anda perlu mengerjakannya atau mencari seseorang untuk mengerjakannya.

Jika Anda menginginkan sesuatu, Anda perlu mengerjakannya atau mencari seseorang untuk mengerjakannya.

Pertama kita perlu tahu apakah hulu menginginkan ini.

Setelah meninjau kode sumber, saya pikir kita harus memperluas fungsi penyalinan di sini https://github.com/tonistiigi/fsutil/blob/master/copy/copy.go terlebih dahulu. Setelah itu, kita dapat memperluas backend.go di libsolver, dan hanya setelah itu dimungkinkan untuk memperluas AST dan frontend dari buildkit.
Tetapi setelah itu, salinannya akan mendekati semantik rsync daripada unix cp.

PEMBARUAN: ya, setelah memperpanjang copy.go semuanya akan dekat dengan https://github.com/moby/buildkit/pull/1492 ditambah parsing daftar pengecualian.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat