Moby: النسخ مع الملفات المستبعدة غير ممكن

راجع الملف https://docs.docker.com/reference/builder/#dockerignore
يمكنك إضافة إدخالات إلى ملف .dockerignore في جذر المشروع.

.dockerignore لا يحل هذه المشكلة. كما كتبت ، "الجزء الآخر يخضع لنسخة أخرى".

هل تريد نسخًا مشروطًا بناءً على نسخة أخرى؟

يحتوي السياق على الكثير من الدلائل A1 ... A10 ودليل B. A1 ... A10 له وجهة واحدة ، B له وجهة أخرى:

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

وهذا أمر محرج.

أي جزء منه محرج؟ سرد كل منهم على حدة؟

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

هل هذا فعال؟

الأسماء A1..A10، B كانت مزيفة. بالإضافة إلى ذلك ، يجمع COPY A* ... _contents_ الدلائل.

هناك خياران أعترف بهما ، لكنني أعتقد أنهما جميعًا محرجان. ذكرت ثلاثة في رسالتي الأصلية. الخيار الرابع هو إعادة ترتيب شفرة المصدر الخاصة بي بشكل دائم بحيث يتم نقل A1..A10 إلى دليل جديد أ. كنت آمل ألا يكون هذا ضروريًا لأن مستوى التداخل الإضافي ليس شيئًا أرغب فيه ، وكانت أدواتي الحالية بحاجة إلى حالة خاصة لمشاريعي المرسومة بعد ذلك.

(راجع للشغل ، # 6094 (الروابط الرمزية التالية) من شأنه أن يساعد في هذه الحالة. ولكن على ما يبدو ، هذا ليس خيارًا أيضًا.)

bronger إذا كان COPY يتصرف تمامًا مثل cp ، فهل سيحل ذلك حالة الاستخدام الخاصة بك؟

لست متأكدًا من أنني أفهم 100٪.
ربما يمكن أن يلقيduglin نظرة.

bronger أعتقد أن @ cpuguy83 طرح السؤال الصحيح ، كيف ستحل هذا إذا كنت تستخدم "cp"؟ نظرت ولم ألاحظ نوعًا من خيار الاستثناءات على "cp" لذلك لست متأكدًا من كيفية حل هذا خارج "بناء عامل الإرساء" أيضًا.

مع سلوك cp ، يمكنني تحسين الموقف بالقول

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

لا تزال مشكلة صيانة بسيطة لأنني سأفكر في هذا السطر إذا أضفت دليل "A11". لكن هذا سيكون مقبولا

علاوة على ذلك ، لا يحتاج cp إلى استثناءات ، لأن نسخ كل شيء وإزالة الأجزاء غير المرغوب فيها ليس له أي تأثير تقريبًا على الأداء بخلاف النسخ نفسه. مع نسخة عامل الميناء ، فهذا يعني أن ذاكرة التخزين المؤقت غير صالحة بشكل خاطئ في كل مرة يتم فيها تغيير B والصور الأكبر.

bronger يمكنك القيام به:

COPY a b c d /some/where

تمامًا كما كنت تقترح.

بالنسبة لعمل RUN rm ... بعد COPY ... ، نعم سيكون لديك طبقة إضافية ، لكن لا يزال بإمكانك استخدام ذاكرة التخزين المؤقت. إذا رأيت خطأ في ذاكرة التخزين المؤقت بسبب ذلك ، فأعلمني بذلك ، لا أعتقد أنه يجب عليك ذلك.

ولكن

COPY a b c d /some/where/

نسخ محتويات الدلائل abcd معًا ، بدلاً من إنشاء الدلائل / بعض / أين / {أ ، ب ، ج ، د}. إنه يعمل مثل rsync مع شرطة مائلة ملحقة بدليل src. لذلك ، فإن التعليمات الأربعة

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

مطلوبين.

أما بالنسبة للذاكرة المؤقتة ... إذا قلت

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

ثم لا يتم استخدام ذاكرة التخزين المؤقت إذا تغيرت e ، على الرغم من عدم تضمين e بشكل فعال في العملية.

bronger نعم ، للأسف أنت على صواب. أعتقد أنه يمكننا إضافة نوع --exclude zzz من نوع العلم ، ولكن وفقًا لـ https://github.com/docker/docker/blob/master/ROADMAP.md#22 -dockerfile-syntax قد لا تحصل على الكثير من الجر الآن.

عادل بما يكفي. ثم سأستخدم COPY + rm في الوقت الحالي وأضيف تعليق FixMe. شكرا لك على وقتك!

فقط من أجل: +1: هذه المشكلة. يؤسفني بانتظام أن COPY لا يعكس دلالات الخط المائل في rsync. هذا يعني أنه لا يمكنك نسخ أدلة متعددة في بيان واحد ، مما يؤدي إلى تكاثر الطبقات.

أواجه بانتظام حالة حيث أرغب في نسخ العديد من الدلائل باستثناء دليل واحد (سيتم نسخه لاحقًا ، لأنني أريد أن يكون له تأثيرات مختلفة لإبطال الطبقة) ، لذلك سيكون من المفيد أيضًا استخدام --exclude .

أيضًا من 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

أعتقد أنه لا يمكن تغييره الآن دون كسر الكثير من Dockerfile s.

كمثال ملموس ، لنفترض أن لدي دليل يشبه هذا:

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

أريد شيئًا يشبه:

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

لذلك فإن هذا الجزء 1-N لا يبطل بناء /vendor . (نظرًا لأنه نادرًا ما يتم تحديث / البائع مقارنةً بالجزء 1-N).

لقد عملت سابقًا على حل هذا الأمر عن طريق وضع part1-N في الدليل الخاص بهم ، لذلك:

/vendor
/src/part1-N

لكنني واجهت أيضًا هذه المشكلة في المشاريع التي لا أملك الحرية في إعادة ترتيبها بسهولة تامة.

praller مثال جيد ، نحن نواجه نفس المشكلة بالضبط. المشكلة الرئيسية هي أن مسار ملف Go.Match لا يسمح بالكثير من الإبداع مقارنة بالتعبيرات العادية (أي لا يوجد نمط مضاد)

لقد توصلت للتو إلى حل بديل إلى حد ما لهذا الغرض. لا يمكن لـ COPY استبعاد الدلائل ، ولكن ADD _can_ قم بتوسيع tgz.

إنها خطوة بناء إضافية:
tar --exclude = '. / defirmed_copy' -czf all_but_defirmed.tgz.
بناء عامل ميناء ...

ثم في Dockerfile الخاص بك:
إضافة ./all_but_defirmed.tgz / application_dir /
.. الاشياء في الطبقات المتغيرة نادرا ..
يضيف . / application_dir /
.. الاشياء في الطبقات المتغيرة في كثير من الأحيان

يعطي ذلك الصيغة الكاملة للقطران لتضمين / استبعاد / أي شيء بدون كتل من الطبقات الضائعة تحاول التضمين / الاستبعاد.

@ jason-kane هذه خدعة جميلة ، شكرًا للمشاركة. نقطة صغيرة واحدة: يبدو أنه لا يمكنك إضافة علامة z (gzip) إلى tar — إنها تغير قيمة المجموع الاختباري sha256 ، التي تبطل ذاكرة التخزين المؤقت لـ Docker. وإلا فإن هذا النهج يعمل بشكل جيد بالنسبة لي.

+1 لهذه المشكلة ، أعتقد أنه يمكن دعمها بنفس الطريقة التي تدعمها بها الكثير من مكتبات الكرة الأرضية:

إليك اقتراح لنسخ كل شيء باستثناء node_modules

COPY . /app -node_modules/

واجهت نفس المشكلة أيضًا ، وهي نوعًا ما مؤلمة بالنسبة لي عندما يبلغ حجم تطبيقات Java webapps الخاصة بي حوالي 900 ميجابايت ولكن نادرًا ما يتم تغيير 80٪ من ذلك.
إنها حالة مبكرة من تطبيقي وهيكل المجلد مستقر إلى حد ما ، لذا لا أمانع في إضافة طبقة 6-7 نسخ حتى أتمكن من استخدام ذاكرة التخزين المؤقت ، ولكنها ستؤذي بالتأكيد على المدى الطويل عندما يزداد عدد الملفات والمجلدات تم اضافتهم

👍

لدي نفس المشكلة على الرغم من أنه مع docker cp ، أريد نسخ جميع الملفات من مجلد ما عدا مجلد واحد

بالضبط نفس المشكلة هنا. أريد نسخ git repo واستبعاد دليل .git.

oaxlin ، يمكنك استخدام ملف .dockerignore لذلك.

antoineco هل أنت متأكد من أنه سيعمل؟ لقد مر وقت طويل منذ أن حاولت ولكنني متأكد تمامًا من أن .dockerignore لم يعمل مع docker cp ، على الأقل في ذلك الوقت

@ kkozmic-looking متأكد تمامًا :) لكن الأمر الفرعي docker cp CLI الذي ذكرته يختلف عن العبارة COPY الموجودة في Dockerfile ، وهو نطاق هذه المشكلة.

لا علاقة بين docker cp بملف Dockerfile و. dockerignore ، ولكن من ناحية أخرى ، لا يتم استخدامه لبناء الصور.

أود حقًا هذا أيضًا - لتسريع الإنشاء ، يمكنني نسخ بعض المجلدات في أجزاء سابقة من الإنشاء ومن ثم تساعدني ذاكرة التخزين المؤقت ...

لست متأكدًا من أنني أفهم ما هي حالة الاستخدام ولكن لن أتطرق فقط إلى الملفات لاستبعادها قبل COPY لحل المشكلة؟

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

لا يقوم AFAIK COPY بالكتابة فوق الملف ولهذا أعتقد أن هذا قد ينجح.

عفوًا ، لا تهتم بذلك ، يبدو أن COPY يقوم بالفعل بالكتابة فوق الملفات. أشعر الآن بالحيرة قليلاً من خلال https://nodejs.org/en/docs/guides/nodejs-docker-webapp/ الذي يقوم npm بتثبيت ثم تنفيذ COPY . /usr/src/app . أعتقد أنه يفترض أن عامل الإرساء تم تجاهل node_modules ؟ من ناحية أخرى ، قد يكون وجود أمر COPY_NO_OVERWRITE (مطلوب اسم أفضل) طريقة واحدة لتحقيق تجاهل الملفات أثناء النسخ (يجب عليك إنشاء ملفات / dirs فارغة للأشياء التي تريد تجاهلها).

FWIW ، أجد هذا قبيحًا جدًا.

لقد وجدت حل اختراق آخر:

مثال على هيكل المشروع:
تطبيق/
التكوين /
النصي/
المواصفات /
ثابتة/
...

نحن نريد:

1. نسخ ثابت /
2. انسخ الملفات الأخرى
3. نسخ التطبيق /

حل الاختراق:
ADD ./static /home/app
ADD ["./[^s^a]*", "./s[^t]*", "/home/app/"]
ADD ./app /home/app

الإضافة الثانية تعادل: نسخ الكل ، باستثناء "./st " و "./a ".
أي أفكار للتحسين؟

ما هي حالة التعليق ؟

👍

👍

👍

👍

ماذا عن وجود ملف .dockerignore بنفس الطريقة من .gitignore؟

mirestrepo اطلع على أول متابعتين لهذه المشكلة.

حاليًا هذا هو تقدير الأداء الضخم لتطوير C # / dotnet.

ماذا اريد:

• قم أولاً بنسخ كافة ملفات dll الخارجية إلى صور عامل التحميل (كل شيء ما عدا My * .dll)
• ثم انسخ جميع ملفات dll الخاصة بي (بدءًا من My. *. dll).

الآن يبدو أن هذا ليس ممكنًا (بسهولة) لأنني لا أستطيع نسخ كل شيء باستثناء.

لذلك يتم نسخ ملفات dll بشكل مزدوج مما يزيد من حجم ملف عامل التحميل أو يتم نسخ كل شيء في طبقة واحدة.
أصبح لاحقًا nerf ضخمًا لأنه يتم نسخ ملفات dll الخارجية في كل مرة بدلاً من تخزينها مؤقتًا.

adresdvila شكرًا على solutoin لقد تمكنت من تقسيمه إلى:

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

على الرغم من أن هذا لا يزال يترك مشكلة أن ملفات .json يتم نسخها في الأمر الأول

مجرد رنين للتعبير عن الشكر لـ antoineco تم حل مشكلتي. لم أعد أنسخ دليل .git في صوري عامل الإرساء.

أدى هذا إلى تحسين حجم الصورة بشكل كبير ، وجعل صورتي أكثر ملاءمة لنظام التخزين المؤقت لرسو السفن.

لدي نفس المشكلة. لدي ملف كبير أريد نسخه قبل باقي الملفات ، لذا فإن أي تغيير في السياق لا يكرره لأنه يستغرق وقتًا طويلاً لنسخ (ملف bin 7 جيجابايت). هل هناك أي حلول جديدة؟

تكمن المشكلة في نهج COPY و prune في أن الطبقة قبل التقليم لا تزال تحتوي على جميع البيانات.

سيكون COPY . --exclude=a --exclude=b مفيدًا للغاية. ما رأيك ، @ cpuguy83؟

Nowaker يعجبني. يبدو أنه يتماشى مع tar و rsync أي حال.
أعتقد أن هذا يجب أن يدعم نفس التنسيق مثل dockerignore؟

تضمين التغريدة

سيتم التعامل مع هذه الحالة بواسطة # 32507 على ما أعتقد.

تضمين التغريدة أبرزها ، تمشيا مع COPY --chown=uid:gid

dnephin RUN --mount تبدو حالة استخدام مختلفة تمامًا ، تتمحور حول إنشاء شيء ما بناءً على البيانات التي لا نحتاجها بعد إنشاء المخرجات. (على سبيل المثال ، التحويل البرمجي باستخدام Go ، وإنشاء ملفات HTML من ملف Markdown ، إلخ). RUN --mount مخدر وسأستخدمه بالتأكيد في المشروع الذي أعمل عليه حاليًا (إنشاء مستندات API باستخدام Sphinx).

يتمحور COPY somedir --exclude=excludeddir1 --exclude=excludeddir2 حول نسخ البيانات التي يجب أن تنتهي في الصورة ولكن متناثرة عبر عبارات نسخ متعددة ، وليس واحدة فقط. الهدف هو تجنب COPY first second third .... eleventh destination/ عندما يحتوي المشروع على الكثير من الدلائل في الجذر ويكون عرضة للتغيير / الزيادة.

في حالتي ذاتها ، أرغب في نسخ معظم الملفات باستثناء تلك غير الضرورية أولاً للتأكد من استخدام ذاكرة التخزين المؤقت إذا لم تتغير ملفات المصدر. بعد ذلك ، قم بترجمة / إنشاء - واستخدام ذاكرة التخزين المؤقت إذا لم تتغير الملفات المنسوخة (رائع). في البداية ، انسخ الملفات التي استبعدتها سابقًا والتي ربما تغيرت منذ الإنشاء السابق لكن تغييرها لا يؤثر على التجميع / الإنشاء. من الواضح أن لدي الكثير من الملفات والمجلدات بتنسيق. أريد نسخها أولاً ، وأريد نسخ زوجين فقط في مكان ما في النهاية.

الفكرة هي أن RUN --mount قادر على حل الكثير من المشاكل. COPY --exclude يحل مشكلة واحدة فقط.

أفضل إضافة شيء يحل الكثير من المشاكل بدلاً من إضافة مجموعة من القواعد اللغوية لحل المشكلات الفردية. يمكنك استخدام RUN --mount... rsync --exclude ... (أو بعض البرامج النصية التي تنسخ أشياء فردية) وستكون مكافئة لـ COPY --exclude .

dnephin أوه ، لم أفكر في RUN --mount rsync ! ممتاز! 👍

هذا ممتاز بالفعل. ومع ذلك ، لن تتمكن من الاستفادة من التخزين المؤقت بكفاءة Nowaker ، لأنه سيتم إبطال ذاكرة التخزين المؤقت إذا تغير أي شيء في الدليل المثبت ، وليس فقط ما تريده rsync.

إذا كنت تستخدم إخراج rsync هذا كمدخل لشيء آخر ولم يتم تغيير أي ملفات بالفعل هناك ، فسيتم التقاط ذاكرة التخزين المؤقت مرة أخرى. إذا كنت حقًا جاهزًا لذلك ، فيمكنك القيام بذلك حاليًا باستخدام شيء مثل https://gist.github.com/tonistiigi/38ead7a4ed60565996d207a7d589d9c4#file -gistfile1-txt-L130-L140. التغيير فقط في RUN --mount (أو LLB في buildkit) هو أنك لست مضطرًا فعليًا لنسخ الملفات بين المراحل ولكن يمكنك الوصول إليها مباشرة بحيث يكون أسرع بكثير.

ماذا عن استخدام 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 Welp ، إذن لم يعد ممتازًا بعد الآن. شكرا للإشارة ..

MartijnHols هذا حل جيد. شكرا على نشرك.

إلى المشرفين: مع ذلك ، يمكننا أن نقول "لماذا التنفيذ - الموضحة في COPY ، يمكنك استخدام RUN chown في بناء متعدد المراحل". نحتاج --exclude للعقل. هناك الكثير من الحلول في Dockerfiles هذه الأيام.

لدي حالة استخدام يمكن أن تستفيد من COPY --exclude . لدي مجلد بيانات ضخم يجب نسخه إلى الحاوية بالكامل. محتويات هذا الدليل تخضع لتغييرات متكررة. من أجل تحسين أداء ذاكرة التخزين المؤقت ، يوجد ملف واحد كبير في الدليل أريد نسخه إلى طبقته الخاصة ، قبل نسخ الباقي. اعتبارًا من الآن ، من غير الضروري وصف هذا النوع من الحاوية بإسهاب.

ما هي الطريقة الصحيحة لاستخدام التخزين المؤقت الطبقي المتمركز حول المتطلبات. txt

لدي هذا:

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

و 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"]

ما هي الطريقة الصحيحة لاستخدام الأمر COPY الثاني لاستبعاد متطلبات إنشاء ذاكرة التخزين المؤقت ... وبالمثل طبقة التطبيق 1 و التطبيق 2 إذا لم يغيروا كثيرًا؟

axehayz لست متأكدًا مما إذا كان هذا هو ما تطلبه ، لكنني سأفعل شيئًا مشابهًا لسير عمل العقدة في https://medium.com/@guillaumejacquart/node -js-docker-workflow-12febcc0eed8.

أي أنه من المقبول أن تكون نسختك الثانية COPY . ؛ طالما أن pip install يأتي من قبل ، فلن يؤدي ذلك إلى إبطال ذاكرة التخزين المؤقت للحزم المثبتة.

واجهت نفس المشكلة. في الوقت الحالي ، أفضل توسيع الملفات في أدلة مختلفة.

لدي حالة أخرى لـ COPY --exclude = ... --exclude = ...

أحاول عمل نسخة من = oldimage من أجل تقليص حجم صورتي وأحتاج إلى نسخ معظم الملفات ، ولكن بدون بعضها. يمكنني القيام بذلك دليلًا تلو الآخر ، وهو أمر مؤلم ، ولكنه يعمل ... ولكن القدرة على - استبعاد قائمة من dirs / الملفات أو توفير خيارات استبعاد متعددة ستكون أفضل بكثير وأسهل في الصيانة.

إذن بعد ثلاث سنوات ونصف لا يوجد اعتراف على الإطلاق؟

asimonf هناك أطنان من الإقرار ذهابًا وإيابًا لفهم واقعة الاستخدام. أفترض أنك تعني أن أحدا لم يقم بهذا العمل؟ هذا صحيح. علينا جميعًا أن نختار الأشياء التي نعمل عليها.

بصراحة ، يمكن القيام بذلك بسهولة تامة باستخدام الوظائف الحالية حتى لو كان ذلك يعني أنه يتعين عليك كتابة القليل من الإضافات في Dockerfile الخاص بك لتحقيق ذلك.

# 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/* /

مع buildkit لا تحتاج حتى إلى مرحلة إضافية

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

ما لم أفقد شيئًا ما باستخدام بنية متعددة المراحل لا يبدو الحل هنا. ذاكرة التخزين المؤقت لا تزال غير صالحة في مرحلة النسخ.

ما لم أفقد شيئًا ما باستخدام بنية متعددة المراحل لا يبدو الحل هنا. ذاكرة التخزين المؤقت لا تزال غير صالحة في مرحلة النسخ.

هذا صحيح. لأنها المشكلة التي أواجهها الآن.

متعدد المراحل يعمل بشكل رائع بالنسبة لي.

أقوم بتقسيم بنائي إلى متعدد المراحل ، للاستفادة الكاملة من ذاكرة التخزين المؤقت ، يبدو الأمر كما يلي:

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 التحدي في هذه العملية هو أنه كان عليك ترتيب تخطيط التطبيق الخاص بك على وجه التحديد لبناء عامل ميناء ، وهو أمر لا يريد الكثير من الناس القيام به.
يعد استخدام docker أحد الاعتبارات العديدة التي يجب موازنتها عند اكتشاف كيفية تخطيط ملفات التطبيق (على سبيل المثال ، إمكانية الصيانة ، وسهولة الاستخدام للموظفين الجدد ، ومعايير المشروع المتقاطعة ، ومتطلبات إطار العمل ، وما إلى ذلك).

cfletcher لست متأكدًا من أنني فهمت تمامًا ما تقصده.

بالنسبة للتغيير الذي ذكرته أعلاه ، قمت بالفعل بنقل Dockerfile الخاص بي إلى دليل فرعي (مما تسبب لي في العديد من المشكلات عند محاولة استخدام rsync لترتيب هذه الملفات) ، مما يعني أنني كنت أحاول إخفاء Dockerfile الخاص بي.

النهج الذي اقترحته عام كما أتخيل. لنفترض أن لديك 100 ملف في مشروعك. إنه يختار ببساطة واحدًا منهم ليصنع stage0 ، ثم 1 + 10 منهم ليصنع المرحلة 1 ، ثم كل 100 لتشكيل المرحلة 2. كل مرحلة مكدسة فوق المرحلة السابقة ، ولها أمر بناء مختلف. بالنسبة لهيكل المشروع المعقد ، فهذا يعني فقط أن منطق الملفات stagify سيكون معقدًا.

بالنسبة لي ، السبب الأكبر هو أنني قسمت الكود الخاص بي إلى وحدات ، وأحتاج إلى نسخ جميع ملفات package.json قبل تشغيل npm install .

هل ترغب أيضًا في نوع من استبعاد الحجة للنسخ. لدينا أكثر من 20 ملفًا وأكثر من 10 مجلدات في الدليل الجذر. نقوم بالكود بشكل كبير على 2 من الدلائل وعدد قليل من الملفات. أود تقسيم هذه إلى طبقتين نسخ. أحدهما للملفات الثابتة والأدلة التي لا نلمسها أبدًا ، والآخر للملفات والأدلة التي نلمسها دائمًا.

إنه لأمر محزن للغاية أن هذا ما زال يتم تجاهله. كان هذا سيساعدني في توفير 5 دقائق لكل بناء إذا كان بإمكاني استبعاد دليل واحد لعدم إبطال ذاكرة التخزين المؤقت.

مع buildkit ، لا تعتمد ذاكرة التخزين المؤقت على الصورة الأصلية كما لو كانت مجموعة ما قبل الإنشاء.
لذا ، نعم مع حل rsync المذكور ، ستحصل على نتيجة حيث ستحتاج إلى المزامنة في كل مرة يكون هناك بعض التغيير ، ولكن سيتم تخزين المراحل اللاحقة مؤقتًا بناءً على المحتوى ، وإذا لم يتم تغيير محتوى ما يتم نقله بعد ذلك. .. على الأقل في نظريتي الكاملة على الفور يجب أن تستخدم تلك المراحل ذاكرة التخزين المؤقت.

إنه لأمر محزن أن إضافة علامة --exclude بسيطة إلى COPY هي عملية بيع صعبة للغاية. إنها في TOP30 الأكثر تصويتًا ، وهي سهلة التنفيذ نسبيًا مقارنة بتذاكر TOP30 الأخرى. :(

إنها ليست مثيرة للجدل ، إنها تتطلب العمل.

تضمين التغريدة بدت وكأنها مثيرة للجدل / مرفوضة إلى حد ما. هل يعني ذلك أن العلاقات العامة المناسبة مع COPY --exclude من المحتمل أن يتم قبولها ، إذا اجتازت معايير الجودة؟

لا يمكنني التحدث عن كل مشرف ، لكنني تحدثت إلى tonistiigi منذ شهر أو نحو ذلك حول هذا و IIRC أكبر عقبة تتعلق بكيفية ارتباط هذا بـ dockerignore ، وبناء الجملة ، وما إلى ذلك (وحقيقة أن dockerignore غير كافٍ من الناحية التركيبية).

يجب أن يدخل التغيير في buildkit.

Upvoting COPY --exclude=... --exclude=... - مطلوب أيضًا في حالتي من الريبو المترابط

التصويت الإيجابي! حاولت باستخدام COPY !(excludedfile) . والذي يجب أن يعمل على Bash لكنه لا يعمل على Docker

لا أحب الاقتراحات لتكرار كل شيء داخل ملف .dockerignore لكل كشف حساب $ # COPY في Dockerfile . القدرة على البقاء جافًا مع ما سيكون جزءًا من الصورة ولا يجب أن تكون أولوية ، imho.

بالنظر إلى # 33923 ، لا أعتقد أنه من قبيل الصدفة أن ما تريد استبعاده من سياق الإنشاء هو بالضبط نفس الأشياء التي تريد استبعادها من عبارات COPY . أعتقد أن شيئًا كهذا سيكون حلاً جيدًا:

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

أو ربما شيء من هذا القبيل:

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

بمعرفة كيف أن .dockerignore عادة ما يكون نسخة 90٪ من .gitignore بالفعل ، فإنه يشعر بمزيد من الإزعاج لضرورة تكرار كل ملف ومجلد تم تجاهله مرة أخرى لكل كشف COPY . حتما توجد طريقة افضل.

asbjornu .gitignore و. dockerignore ليسا نفس الأشياء على الإطلاق. خاصة بالنسبة للبنيات متعددة المراحل حيث يتم إنشاء القطع الأثرية في مرحلة البناء ولا توجد في git على الإطلاق ، ومع ذلك يجب تضمينها في الصورة الناتجة.
ونعم ، مع تقديم الإنشاءات متعددة المراحل ، يجب أن تكون هناك قدرة على استخدام ملفات .dockerignore مختلفة لكل مرحلة - بالتأكيد.

غالبًا ما أرغب في نسخ "بناء عامل ميناء". في هذه الحالات ، لا يقوم .dockerignore بأي شيء. نحن بحاجة إلى تعديل لـ "docker cp" ، إنه الحل الوحيد المعقول

لقد مرت 5 سنوات على فتح هذه القضية. في سبتمبر 2020 ، ما زلت أريد هذا. اقترح الكثير من الأشخاص الاختراقات لحلها ، لكن جميعهم تقريبًا وآخرون طلبوا علامة exclude بشكل أو بآخر. من فضلك لا تدع هذه المشكلة تمر دون حل لمزيد من الوقت الآن.

إذا كنت تريد شيئًا ما ، فأنت بحاجة إلى العمل عليه أو البحث عن شخص ما للعمل عليه.

إذا كنت تريد شيئًا ما ، فأنت بحاجة إلى العمل عليه أو البحث عن شخص ما للعمل عليه.

نحتاج أولاً إلى معرفة ما إذا كان المنبع يريد ذلك.

https://github.com/moby/moby/issues/15771#issuecomment -550571058

بعد مراجعة كود المصدر ، أعتقد أنه يجب علينا توسيع وظيفة النسخ هنا https://github.com/tonistiigi/fsutil/blob/master/copy/copy.go أولاً. بعد ذلك ، يمكننا تمديد backend.go في libsolver ، وبعد ذلك فقط سيكون من الممكن تمديد AST والواجهة الأمامية لـ buildkit.
ولكن بعد ذلك ، ستكون النسخة قريبة من rsync الدلالية من unix cp.

تحديث: نعم ، بعد تمديد copy.go ، سيصبح كل شيء قريبًا من https://github.com/moby/buildkit/pull/1492 بالإضافة إلى تحليل قائمة المستبعدين.