Moby: بناء الوقت فقط الخامس الخيار

أنا أبحث عن حل مماثل.

مشكلة

قامت المؤسسة التي أعمل بها مؤخرًا بتمكين وكيل Zscaler مع فحص SSL ، مما يعني وجود شهادات مثبتة وبعض متغيرات البيئة التي تم تعيينها أثناء الإنشاء.

كان الحل المؤقت هو إنشاء Dockerfile جديد مع مجموعة الشهادات ومتغيرات البيئة. لكن هذا لا يبدو معقولاً من منظور طويل الأمد.

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

السيناريو المثالي هو نفس Dockerfile ، سأكون قادرًا على بناء صورتي على الكمبيوتر المحمول ، في المنزل ، وفي المؤسسة.

حل ممكن

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

# Home
$ docker build -t myimage .

لدي حالة استخدام مختلفة قليلاً لهذه الميزة - حزم التخزين المؤقت التي يتم تنزيلها / تحديثها بواسطة مدير الحزم ASP.Net 5 . يدير مدير الحزم مجلد ذاكرة التخزين المؤقت الخاص به ، لذا في النهاية أحتاج فقط إلى مجلد يمكنني إعادة استخدامه بين الإصدارات.

بمعنى آخر:

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

yngndrw ما تقترحه سيكون مناسبًا لي أيضًا ، على سبيل المثال ، نحتاج إلى تجميع موارد إضافية في وقت الإنشاء والتي لن تكون ضرورية في وقت التشغيل حيث تم تثبيتها في الحاوية.

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

أعيد صياغة ما قلته عندما أفتح الإصدار: هناك فرق بين ملف التصريح الواقي وعمليته ووقت تشغيل الأداة.
إذا كنا نؤمن حقًا بالبنية التحتية ككود بالإضافة إلى البنية التحتية غير القابلة للتغيير ، فإن Docker نفسها تروج بشكل أكبر وأنا أحب ذلك بالمناسبة ، فيجب أن يتم النظر في هذا الأمر بجدية IMO (انظر الانتفاخ في المنشور 1 طيه)

شكرا مرة اخرى

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

مثال آخر ، سيكون القمر الصناعي / السير في الفضاء الذي يغير المخطط كثيرًا وحتى يغير قواعد البيانات من Oracle إلى Postgresql في الإصدار 5.6 (IIRC).

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

بشكل أساسي ، أنا الآن مجبر على إجراء ترقية يدوية عن طريق تشغيل حاوية عادية مع حامل ربط a -v ، ثم القيام بـ "التزام عامل الإرساء". لا أستطيع أن أفهم سبب عدم توفر نفس الإمكانية مع إنشاء Dockerfile الآلي؟

Secondingyngndrw للإشارة إلى التخزين المؤقت: ينطبق نفس المنطق على العديد من المشاريع الشائعة مثل Maven و npm و apt و rpm - يمكن أن يؤدي السماح لذاكرة تخزين مؤقت مشتركة إلى تسريع عمليات الإنشاء بشكل كبير ، ولكن يجب ألا يتم وضعها في الصورة النهائية.

أتفق معstevenschlansker. يمكن أن يكون هناك العديد من المتطلبات لإرفاق حجم ذاكرة التخزين المؤقت ، أو نوعًا ما من عدد قليل من وحدات غيغابايت من البيانات ، والتي يجب أن تكون موجودة (في حالة التحليل) في الصورة النهائية ، ولكن ليس كبيانات أولية.

لقد تعرضت أيضًا للعض من المقاومة المستمرة لتوسيع docker build لدعم الأحجام التي يمكن استخدامها بواسطة docker run . لم أجد شعار "البنيات المستقلة عن المضيف" مقنعًا للغاية ، حيث يبدو أنه يجعل التطوير والتكرار على صور Docker أكثر صعوبة ويستغرق وقتًا طويلاً عندما تحتاج إلى إعادة تنزيل مستودع الحزمة بالكامل في كل مرة تقوم فيها بإعادة البناء صورة.

كانت حالة الاستخدام الأولية الخاصة بي هي الرغبة في التخزين المؤقت لمستودعات حزم نظام التشغيل لتسريع تكرار التطوير. الحل البديل الذي كنت أستخدمه مع بعض النجاح مشابه للنهج الذي اقترحه fatherlinux ، وهو التخلي عن المصارعة بـ docker build و Dockerfile تمامًا ، والبدء من الصفر باستخدام docker run على برنامج نصي شيل قياسي متبوعًا بـ docker commit .

كتجربة صغيرة ، قمت بتوسيع تقنيتي إلى بديل كامل مقابل docker build باستخدام القليل من البرمجة النصية POSIX shell: dockerize .

إذا أراد أي شخص اختبار هذا البرنامج النصي أو النهج العام ، فيرجى إبلاغي بما إذا كان مفيدًا أو ممتعًا (أو إذا كان يعمل من أجلك على الإطلاق). للاستخدام ، ضع النص في مكان ما في PATH وأضفه كـ shebang للنص البرمجي للبناء (الشيء #! ) ، ثم عيّن متغيرات البيئة ذات الصلة قبل سطر shebang الثاني الذي يشير إلى بداية البرنامج النصي لتثبيت Docker.

سيتم تمرير المتغيرات FROM و RUNDIR و VOLUME كوسائط إلى docker run .
سيتم تمرير المتغيرات TAG و EXPOSE و WORKDIR كوسيطات إلى docker commit .

سيتم تقييم جميع المتغيرات الأخرى في الصدفة وتمريرها كوسيطات بيئة إلى docker run ، مما يجعلها متاحة داخل البرنامج النصي للبناء.

على سبيل المثال ، سيقوم هذا البرنامج النصي بالتخزين المؤقت وإعادة استخدام حزم Alpine Linux بين الإصدارات (يقوم VOLUME بتثبيت دليل رئيسي على CACHE ، والذي يتم استخدامه بعد ذلك كرابط رمزي لذاكرة التخزين المؤقت لمستودع حزمة نظام التشغيل في برنامج التثبيت النصي):

#!/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...]

لذلك ، بعد مقابلة الوحدة الفرنسية :) من Docker في MesoCon الأسبوع الماضي (كان من دواعي سروري أيها الرجال) ، علمت أن لديهم نفس المشكلة داخل الشركة وقاموا بتطوير اختراق ينسخ إلى صورة ضئيلة جديدة ما يحتاجون إليه .
أود أن أقول إن الاختراقات هي ملاحظة مرحب بها في عالم المؤسسات ؛) ويجب التعامل مع هذا الطلب بشكل صحيح.
شكرا لاستماعكم يا رفاق ...

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

yngndrw أنا لا أفهم لماذا أغلقت مسألتين مرتبطتين. لقد قرأت مشكلتك رقم 59 ولا أرى مدى ارتباط ذلك بهذا الأمر. في بعض الحالات ، تصبح الحاويات منتفخة للغاية عندما لا تكون هناك حاجة إليها في وقت التشغيل. يرجى قراءة المنشور الأول.
آمل ألا أفقد شيئًا هنا ... لأنه كان يومًا طويلاً: -o

zrml Issue https://github.com/aspnet/aspnet-docker/issues/59 كان مرتبطًا بالتخزين المؤقت المدمج لكل طبقة الذي يوفره عامل الإرساء أثناء إنشاء جميع ملفات عامل الإرساء ، ولكن هذه المشكلة الحالية مختلفة تمامًا مثل نحن نتحدث عن استخدام وحدات التخزين المضيفة لتوفير التخزين المؤقت الخاص بملف عامل ميناء والذي يعتمد على استخدام ملف عامل التحميل بشكل خاص للوحدة. لقد أغلقت المشكلة https://github.com/aspnet/aspnet-docker/issues/59 لأنها لا تتعلق على وجه التحديد بمشروع / مستودع aspnet-docker.

المشكلة الأخرى التي أعتقد أنك تشير إليها هي إصدار https://github.com/progrium/dokku/issues/1231 ، والتي كانت تتعلق بعمليات Dokku التي تعطل صراحة التخزين المؤقت لطبقة عامل الشحن المدمج. أجرى مايكل تغييرًا على Dokku للسماح لهذا السلوك بأن يكون قابلاً للتكوين وهذا حل المشكلة فيما يتعلق بمشروع / مستودع Dokku ، لذلك تم إغلاق هذه المشكلة أيضًا.

ربما لا تزال هناك مشكلة متعلقة بـ Docker معلقة (أي لماذا لم يكن Docker يتعامل مع التخزين المؤقت للطبقة المدمجة كما توقعت في المشكلة https://github.com/aspnet/aspnet-docker/issues/59) ، ولكن لم تتح لي الفرصة لمعرفة سبب ذلك والتأكد مما إذا كان لا يزال يحدث. إذا كانت لا تزال تمثل مشكلة ، فيجب طرح مشكلة جديدة لهذا المشروع / المستودع لأنها تختلف عن هذه المشكلة الحالية.

yngndrw بالضبط ، لذلك نحن نتفق على أن هذا مختلف ومعروف @ docker.com لذا سأعيد فتحه إذا كنت لا تمانع ... حسنًا لا يمكنني ذلك. هل تمانع من فضلك؟
أود أن أرى بعض التعليقات من زملائنا في سان فرانسيسكو على الأقل قبل إغلاقها

راجع للشغل طلب من @ cpuguy83 أن أفتح حالة مستخدم وشرحها كلها ، من السجل # 3156

zrml لست متأكدًا من أنني أتابع - هل تريد إعادة فتح https://github.com/aspnet/aspnet-docker/issues/59 ؟ إنها ليست مشكلة / aspnet / aspnet-docker ، لذا لا أعتقد أنه من الصواب إعادة فتح هذه المشكلة. يجب أن تكون مشكلة جديدة على / docker / docker ، ولكن يجب التحقق منها وستحتاج إلى خطوات قابلة لإعادة الإنتاج يتم إنشاؤها أولاً.

لا ، لا .. هذا # 14080 الذي أغلقته أمس.

هذه القضية لا تزال مفتوحة؟

yngndrw أعتقد أنني أخطأت في قراءة الرمز الأحمر "مغلق". اعتذارات.

أوافق بشدة على أن بناء الوقت -v سيكون مفيدًا للغاية.

إنشاء التخزين المؤقت هو حالة استخدام واحدة.

هناك حالة استخدام أخرى وهي استخدام مفاتيح ssh في وقت الإنشاء للبناء من مستودعات خاصة دون تخزينها في الطبقة ، مما يلغي الحاجة إلى الاختراقات (على الرغم من هندستها الجيدة) مثل هذا: https://github.com/dockito/vault

أنا أعلق هنا لأن هذا هو الجحيم في عالم الشركات.
لدينا وكيل اعتراض SSL ، بينما يمكنني توجيه حركة المرور من خلاله ، تفترض أكوام من المشاريع أن لديهم اتصالات SSL جيدة ، لذلك يموتون بشكل رهيب.

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

هذا يقال. إنه أقل خطأ عامل الإرساء ، ولكن خطأ مديري الحزم الذين يستخدمون https عندما يجب عليهم استخدام نظام مشابه لكيفية عمل apt-get. نظرًا لأن ذلك لا يزال آمنًا ويمكن التحقق منه ، كما يمكن تخزينه مؤقتًا بواسطة وكيل http.

btrepp شكرًا لك على حالة استخدام جيدة أخرى.

يمكنني التفكير في موقف آخر.

من الأشياء التي أود القيام بها مع ملفات dockerfiles عدم شحن أدوات الإنشاء مع ملف عامل الإرساء "المترجم". لا يوجد سبب لاحتياج تطبيق C إلى دول مجلس التعاون الخليجي ، ولا يحتاج تطبيق Ruby إلى أداة تجميع في الصورة ، ولكن باستخدام docker build حاليًا أثناء توفر هذا.

كانت لدي فكرة عن تحديد ملف عامل إرساء ، يقوم بتشغيل أوامر عامل إرساء متعددة عند البناء بداخله. Psuedo-ish dockerfiles أدناه.

ملف Docker الذي يبني الآخرين

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

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

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

هذا من شأنه أن يحافظ على صور عامل الميناء خفيفة للغاية.

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

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

هنا مثال آخر. لنفترض أنني أريد إنشاء حاوية لـ systemtap تحتوي على جميع رموز تصحيح الأخطاء للنواة (وهي Yuuuuge). يجب أن أقوم بتركيب الوحدات النمطية / lib / الأساسية بحيث يعرف الأمر yum أي RPMs يجب تثبيتها.

علاوة على ذلك ، ربما أفضل أن يعيش هؤلاء في مكان آخر غير صورة 1.5 جيجابايت (من رموز التصحيح)

ذهبت لكتابة Dockerfile ، ثم أدركت أنه من المستحيل :-(

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

أرغب في تكرار حالة الاستخدام الخاصة بي هنا من # 3949 حيث تم إغلاق هذا الخطأ لأسباب أخرى.

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

أي أخبار في هذه الميزة المطلوبة؟
شكرا

_USER POLL_

_ إن أفضل طريقة للحصول على إشعار عند حدوث تغييرات في هذه المناقشة هي النقر فوق الزر "اشتراك" في الجزء العلوي الأيسر.

قدّر الأشخاص المدرجون أدناه مناقشتك الكاملة مع إجراء +1 عشوائي:

vad

+1 لهذه الميزة!

هناك حالة استخدام أخرى وهي استخدام مفاتيح ssh في وقت الإنشاء للبناء من مستودعات خاصة دون تخزينها في الطبقة ، مما يلغي الحاجة إلى الاختراقات (على الرغم من هندستها الجيدة) مثل هذا: https://github.com/dockito/vault

هذه هي حالة استخدامنا أيضًا (يتم تقديم مفاتيح ssh باستخدام tmpfs على المضيف في هذه الحالة).

حالة استخدام أخرى لهذا هي ذاكرة التخزين المؤقت المحلية للدليل node_modules على خادم CI لتقليل أوقات الإنشاء.
npm install بطيء جدًا وحتى في الحالة "الأفضل" الحالية حيث يكون package.json ADD ed للصورة ، يتم تشغيل npm install وبعد ذلك فقط تمت إضافة مصادر المشروع الفعلية والمبنية على التغييرات التي تم إجراؤها على package.json ، يجب إعادة تنزيل جميع التبعيات مرة أخرى.

راجع npm / npm # 8836 للتعرف على مشكلة حول هذا في جانب Node / npm.

مشكلة aspnet-docker ذات الصلة فيما يتعلق باستعادة الحزمة البطيئة وحجم الصورة الناتج للتخزين المؤقت للحزم الحالية في الطبقة. سيكون من الأفضل استخدام وحدة تخزين مُثبتة للتخزين المؤقت للحزمة.
https://github.com/aspnet/aspnet-docker/issues/123

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

قام OP بتثبيت المشكلة على رأسها ، في أن "بناء عامل الإرساء -v" سيساعد بشكل كبير في فصل عملية الإنشاء عن بيئة وقت التشغيل.

لقد رأيت العديد من المشاريع التي تبني الآن "موانئ التوت" والتي تُستخدم بعد ذلك لبناء عامل الإرساء الفعلي الذي يتم دفعه / توزيعه بعد ذلك. هذا معقد للغاية من منظور الإدارة وحساب الموارد ، والذي يترجم بدوره إلى اختبار CI أبطأ والوحدة ، وسير عمل تطوير أقل إنتاجية بشكل عام.

لقد كنت أفكر في هذا ، والخيار الآخر الذي يمكنني التفكير فيه هو القدرة على تمييز الطبقات على أنها طبقات "src".

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

وبهذه الطريقة ، يمكن لعامل الإرساء تخزين الطبقات / الصور السابقة مؤقتًا ، وتشكيلات الإنشاء المؤقتة ، ولكن هذه ليست مطلوبة لاستخدام الصورة النهائية.

على سبيل المثال.

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.

بالطبع هذا يعني أنك ستحتاج إلى معرفة ما تفعله بشكل أفضل ، حيث يمكنك ترك الملفات الهامة خارجًا.

تضمين التغريدة
سيكون الحل الأفضل لمواقف مثل netcore هو عدم استخدام HTTPS لإدارة الحزم ، ثم من السهل إعداد iptables + Squid للحصول على وكيل تخزين مؤقت شفاف لبناء عامل ميناء. رأيي الشخصي هو أن مديري الحزم هؤلاء يجب أن يزيدوا لعبة ، فهي سيئة الاستخدام في بيئات الشركات بسبب استقالة SSL ، في حين أن أشياء مثل apt-get تعمل بشكل جيد تمامًا ويمكن تخزينها مؤقتًا بالفعل باستخدام iptables + squid for docker.

يمكنني أيضًا رؤية الجانب السلبي لاستخدام أحجام وقت الإنشاء ، ولن تكون ملفات dockerfiles قابلة للتكرار ، وستتطلب إعدادًا إضافيًا خارج docker build -t btrepp / myapp. ، كما ستجعل الإنشاءات الآلية على dockerhub صعبة.

btrepp : أحب اقتراحك. يمكنني حتى أن أعيش من أجل حالات الاستخدام الخاصة بي باستخدام ملف مضغوط (أعلم أنه أمر سيء بشكل عام) TMP dir الذي يخبرنا به Docker حتى يعرفوا متى يقومون ببناء الأداة النهائية من جميع الطبقات التي يمكنهم نسيانها / تجاهلها مثبتة على / this_is_the_tmp_explosion_folder_that_will_be_removed_from_your_container_image
سهل بما فيه الكفاية ....

btrepp تعجبني فكرة طبقة المصدر تمامًا.

ولكن فيما يتعلق بمديري الحزم الذين لا يستخدمون SSL ، سأعارض ذلك.

إذا كنت تريد تخزين حزم من هذا القبيل مؤقتًا ، فمن المحتمل أن تستخدم موجز حزمة خاص (محلي) بدلاً من ذلك يعكس المصدر الرسمي. يبدو أن العودة إلى HTTP فكرة سيئة بالنسبة لي ، لا سيما بالنظر إلى أن الكثير من مديري الحزم لا يبدو أنهم يوقعون حزمهم وبالتالي يعتمدون على HTTPS.

هناك أداة نحوية / رخوة يمكن استخدامها في حين أن هذه المشكلة لم يتم إصلاحها بعد.

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

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

لا يوجد سبب وجيه لأن "super_awesome_ruby_lib" يجب أن يكون خاصًا عند سحبه لأسفل عبر http (s). أفضل طريقة هي أن يكون لجواهر الياقوت حلقة مفاتيح. أو حتى مفتاح عمومي معروف ، ولكي يوقع الحزم. هذه هي طريقة عمل apt-get بشكل أو بآخر ، ويسمح لبروكسيات http القياسية بتخزين الأشياء مؤقتًا.

فيما يتعلق بتغذية الحزمة الخاصة المحلية ، فإن عامل التحميل لا يدعم هذا جيدًا بنفسه. لا توجد طريقة لتعطيل الخلاصة القياسية ، وستفقدها _بكل حق_ إذا لم تكن شهادة https في مخزن الشهادة. أنا متأكد من أن عامل الشحن يريد دائمًا التحقق على الأقل من الخلاصة الرئيسية عند سحب الصور أيضًا. كان تطبيق Afaik للصاروخ / rkt يستخدم التوقيع + http للحصول على صور الحاوية.

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

لأكون واضحًا ، أنا لا أدعو مديري الحزم إلى التبديل فقط إلى استخدام http وإسقاط https. إنهم بحاجة إلى التحقق من الحزم لمنع الهجمات ضد الرجل في الوسط. ما لا يحتاجون إليه هو جانب الخصوصية باستخدام https كعروض "أمان جميع مطرقة".

هذا منظر ضيق حقًا. أنت تطلب من جميع مديري الحزم تغيير سلوكهم بما يتناسب مع وصفة Docker لكيفية بناء التطبيقات.

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

(أنا أيضًا لا أوافق بشدة على ارتباط Docker بالسجل العام - أفضل بشدة منع الوصول إلى السجل العام ، والسماح فقط باستخدام السجل الداخلي الخاص بنا. ولكن هذا موضوع مختلف تمامًا.)

بالنسبة لي أحتاج أيضًا إلى docker build -v .

في حالتنا ، نريد إنشاء صورة تتكون من تثبيت مُعد مسبقًا للمنتج المعني ، ويكون حجم برنامج التثبيت أكبر من 2 جيجابايت . نظرًا لعدم قدرتنا على تحميل وحدة تخزين مضيفة ، لا يمكننا إنشاء الصورة باستخدام برنامج التثبيت على الرغم من أننا قمنا بالفعل بالتنزيل في نظام التشغيل المضيف ، حيث يمكننا استخدام أدوات / بروتوكولات مختلفة ، على سبيل المثال الوكيل باستخدام https cert / auth ، أو ربما سيل قليلا.

كحل بديل ، يتعين علينا استخدام wget لإعادة تنزيل برنامج التثبيت خلال docker build ، وهي بيئة مقيدة كثيرًا ، وأقل ملاءمة ، وتستغرق وقتًا أطول ، وعرضة للخطأ.

أيضًا نظرًا لمرونة خيارات تثبيت / تكوين المنتج ، فمن المنطقي بالنسبة لنا شحن الصور مع المنتج المثبت مسبقًا ، بدلاً من شحن صورة مع المثبت فقط.

thaJeztah أي فرصة لحدوث هذا؟

Fwiw هذا هو السبب الوحيد الذي يجعلني لا (أو لا أستطيع حقًا) استخدام عامل الإرساء

نحمل تصحيحًا في إصدارات Red Hat من عامل الإرساء الذي يتضمن الخيار -v. لكن الحل الحقيقي لذلك هو بناء طرق جديدة ومختلفة لإنشاء صور حاوية OCI بخلاف بناء عامل الإرساء.

@ rhatdan RHEL أم فيدورا؟

قمنا أيضًا بتنفيذ خيار -v لبناء عامل الإرساء في نسختنا الداخلية من عامل الإرساء في resin.io. يمكنك العثور على الفرق هنا https://github.com/resin-io/docker/commit/9d155107b06c7f96a8951cbbc18287eeab8f60cc

rhatdanpetrosagg هل يمكنك إنشاء علاقات عامة لهذا الغرض؟

jeremyherbert ، التصحيح موجود في Docker daemon الذي يأتي في جميع الإصدارات الحديثة من RHEL و CentOS و Fedora ...

graingert لقد أرسلناه في الماضي وتم رفضه.

@ rhatdan هل لديك رابط لها؟

runcom هل لديك الرابط؟

thaJeztah هل هذا شيء كنتم سترفضونه يا رفاق؟

فيما يلي قائمة بالمشكلات الحالية التي تم إغلاقها أو عدم الرد عليها:
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

يمكن العثور على معلومات حول بقع المشروع الذرية المستخدمة في RHEL / CentOS / Fedora على:
http://www.projectatomic.io/blog/2016/08/docker-patches/

يبدو daveisfera أنهم يضيفون فقط مجلدات R وليس مجلدات RW ، لذلك لن يعمل مع yngndrw وحالة الاستخدام الخاصة بي.

graingert لماذا تحتاج مجلدات RW؟ أنا أفهم القراءة فقط كحل بديل لحالات معينة.

قد يكون اختبار عمليات ترحيل المخطط أحد الأسباب الوجيهة ...

في 11/2016 10:36 صباحًا ، كتب بريان جوف:

graingert https://github.com/graingert لماذا تحتاج مجلدات القراءة والكتابة؟
أنا أفهم القراءة فقط كحل بديل لحالات معينة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/14080#issuecomment -257582035 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAHLZdp0D6fAtuNglajPBIwnpWGq3slOks5q5050gaJpZM4FIdOc.

سكوت مكارتي

سكوت. [email protected]

http://crunchtools.com

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

@ cpuguy83 ستكون حالة استخدام أخرى لـ RW هي ذاكرة التخزين المؤقت

fatherlinux لست متأكدا من متابعة. لماذا تحتاج حجم لهذا؟ أيضا لماذا يجب أن يتم ذلك أثناء مرحلة البناء؟

لدي حالة استخدام مختلفة قليلاً لهذه الميزة - حزم التخزين المؤقت التي يتم تنزيلها / تحديثها بواسطة مدير الحزم ASP.Net 5. يدير مدير الحزم مجلد ذاكرة التخزين المؤقت الخاص به ، لذا في النهاية أحتاج فقط إلى مجلد يمكنني إعادة استخدامه بين الإصدارات.

أود ربط التثبيت على سبيل المثال:

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 .

نظرًا لوجود عدة مرات يجب إجراء ترحيل المخطط عندما
تم تثبيت البرنامج. إذا قمت بتشغيل حاويات للقراءة فقط ، فيجب عليك ذلك
لا تقم أبدًا بتثبيت البرامج في أي وقت بخلاف عندما تكون في
مرحلة البناء .....

في 11/2016 10:42 صباحًا ، كتب بريان جوف:

fatherlinux https://github.com/fatherlinux لست متأكدا من أنني أتابع.
لماذا تحتاج حجم لهذا؟ أيضا لماذا يجب أن يتم ذلك أثناء
مرحلة البناء؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/14080#issuecomment -257583693 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAHLZfhBG8RUWtqPD-6RaLC7uoCNc-3nks5q50_TgaJpZM4FIdOc.

سكوت مكارتي

سكوت. [email protected]

http://crunchtools.com

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

أعلم أن محتويات هذه الدلائل لن تتسبب في أن يكون البناء معتمداً على المضيف (سيؤدي فقدان هذه الحوامل إلى عمل الإنشاء على أي حال ، ولكن بشكل أبطأ)

حل NFS هذا مثل 30 منذ سنوات ...

في 11/2016 10:45 صباحًا ، كتب Thomas Grainger:

أعلم أن محتويات هذه الدلائل لن توقف البناء
كونك عاطلاً عن العمل أو معتمداً على المضيف (سيؤدي فقد هذه الحوامل إلى حدوث ذلك
البناء للعمل على أي حال)

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/14080#issuecomment -257584576 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAHLZS75Vq0BSEvUjI2oXORsS0el2mwOks5q51CQgaJpZM4FIdOc.

سكوت مكارتي

سكوت. [email protected]

http://crunchtools.com

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

حل NFS هذا مثل 30 منذ سنوات ...

لا تعليق مفيد

graingert آسف ، جاء هذا خطأ بجدية. كنت أحاول الرد بسرعة كبيرة ولم أعطي السياق الكافي. بجدية ، نحن نبحث في NFS بالاشتراك مع CRIO لحل بعض هذه الأنواع من المشاكل.

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

ومن ثم ، حتى مع خيار وقت الإنشاء a -v ، لا يجب قفل البنية على مضيف واحد فقط. قد لا يكون مستقلاً عن نطاق الإنترنت ، ولكنه كافٍ تمامًا للعديد من الأشخاص الذين يتحكمون في بيئة الإنشاء الخاصة بهم إلى موقع أو موقع واحد.

fatherlinux سأستخدم التخزين المؤقت gitlab أو travis لأخذ دليل ذاكرة التخزين المؤقت وتحميله / تنزيله إلى S3

graingert نعم ، ولكن هذا يعمل فقط على أنواع معينة من البيانات / التطبيقات ، وأيضًا على مستوى الحاوية فقط ، وليس على مستوى البيانات الوصفية posix ومستوى الحظر. بالنسبة لأنواع معينة من تطبيقات الواجهة الأمامية والبرامج الوسيطة ، لا توجد مشكلة. لترحيل مخطط قاعدة البيانات ، تحتاج نوعًا ما إلى الاختبار مسبقًا والحصول على ذاكرة التخزين المؤقت المحلية للسرعة وعادة ما تحتاج إلى أن تكون posix.

تخيل أن لدي مجموعة MySQL Galera بسعة 1 تيرابايت من البيانات وأريد إجراء ترقية وكلها في حاويات. تعد Galera المُقسمة والمُنسقة متعددة العقد الحاوية / المنسقة مريحة حقًا. لا أريد أن أضطر إلى اختبار ترحيل مخطط يدويًا أثناء كل ترقية.

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

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

fatherlinux أعتقد أن هذه حالة استخدام متعامدة ...

graingert ليس تعليقًا مفيدًا. متعامد إلى ماذا؟ متعامد مع طلب a -v أثناء البناء ما هو ما فهمت أن تكون هذه المحادثة حوله؟

هناك بعض الاستخدامات المختلفة التي أراها لهذه العلامة.

• ذاكرة تخزين مؤقت ، مشاركة بين خوادم بناء عامل ميناء
• كلمة رئيسية تشبه ADD تنطبق فقط "أثناء إنشاء" ملف Dockerfile واحد. على سبيل المثال ، أضف ملفًا ضخمًا ، ثم استبعده من الصور.
• كلمة رئيسية مثل ADD + RUN تتجاهل كل المخرجات. على سبيل المثال ، أضف ملفًا ضخمًا ، ثم نفذ خطوة وتجاهل أي تغييرات على الصورة - إضافة + تشغيل في خطوة واحدة ثم تخطي طبقة.

يمكن حل حالتي الاستخدام الأخيرتين بشكل أكثر وضوحًا باستخدام كلمتين رئيسيتين جديدتين.

BUILDCONSTFILE <path>

سيتم تشغيل COPY <path> قبل كل RUN ، وحذف <path> من الصورة التي تليها.

TEST <cmd> WITH <paths>

الذي من شأنه نسخ المسارات ، وتشغيل الأمر ، ثم مع حالة خروج 0 ، تابع الإنشاء من الصورة الأصلية ، وإلا فسيوقف الإنشاء

أنا شخصياً أعتقد أن TEST ... WITH يتم التعامل معه بشكل أفضل في خطوة CI أخرى تختبر الحاوية الخاصة بك ككل

اسمحوا لي أن أستهل بهذا: _فكر_ أنا موافق على إضافة --mount للبناء ("-v" ربما ليس كثيرًا). لست متأكدًا بنسبة 100٪ من التنفيذ ، وكيف يتم التعامل مع التخزين المؤقت (أو عدم التعامل معه) ، وما إلى ذلك.

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

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

@ cpuguy83 أعتقد أن هذا من شأنه حل معظم حالات الاستخدام الخاصة بي. فقط لكي أفهم ، هل تقصد - يعني القراءة فقط؟ و- v أن تقرأ / تكتب؟

@ cpuguy83 نقوم أيضًا ببناء صور "builder" التي أصبحت IMHO نمطًا أكثر شيوعًا ...

fatherlinux swarm services والآن (مقابل 1.13) docker run يدعم --mount وهو أكثر دقة ومرونة: https://docs.docker.com/engine/reference/commandline/service_create/# / إضافة ربط يتصاعد أو مجلدات

يبدو أن المستندات تفتقد إلى النوع الثالث من الحامل ، tmpfs .

آه ، رائع جدًا ، شكرًا ...

في 11/2016 02:20 مساءً ، كتب Brian Goff:

fatherlinux https://github.com/fatherlinux خدمات السرب والآن
(لـ 1.13) | تشغيل عامل الإرساء | يدعم | - جبل | وهو أكثر دقة
ومرنة:
https://docs.docker.com/engine/reference/commandline/service_create/#/add -bind-mounts-or-volumes

يبدو أن المستندات تفتقد إلى النوع الثالث من التحميل ، | tmpfs |.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/14080#issuecomment -257648598 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAHLZXv_VBfVi4WUAjVijE-SKR0ErRC4ks5q54L2gaJpZM4FIdOc.

سكوت مكارتي

سكوت. [email protected]

http://crunchtools.com

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

@ cpuguy83 ، نستخدم أيضًا نمط الباني كثيرًا ولدينا حاجة إلى التخزين المؤقت الذي لا يستمر في الصورة وينجو أيضًا من إبطال الطبقة.

نحن نبني صور Yocto ولدينا ذاكرة تخزين مؤقت مشتركة للحالة على تخزين NFS. حالة استخدام أخرى هي ذاكرة التخزين المؤقت npm بحيث يمكنك إبطال الطبقة RUN npm install بالكامل ولكن إعادة حسابها بشكل أسرع بسبب الحزم المخزنة مؤقتًا.

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

أعتقد أيضًا أن أي فكرة تتطلب _نسخ_ملف ضخم ليست مثالية. أحجام الملفات التي أرغب في استخدامها هي في حدود 10-40 غيغابايت ، وحتى مع ssd جيد ، فإن نسخها لا تقل عن دقيقة أو دقيقتين. هذه هي مشكلتي مع توجيه ADD بالفعل في عامل الإرساء ؛ لا أرغب في إضافة 30 غيغابايت إلى صورتي في كل مرة يتم بناؤها ويجب أن أتعامل مع كل هذه المساحة الخالية الإضافية ، فضلاً عن الحاجة إلى سحق الصور.

هذا لن يعمل مع ما نستخدمه من أجله. لدينا وحدة تخزين تحتوي على مخابئ sstate من نظام yocto build الذي تم ربطه بـ RW في البناء لأنه سيتم حساب أي خطأ في ذاكرة التخزين المؤقت أثناء الإنشاء وحفظه في الحالة للأغراض المستقبلية. أدلةنا أيضًا بحجم ~ 30 غيغابايت ، لذا فإن حساب التجزئة سيستغرق بعض الوقت.

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

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

petrosaggzrmlthaJeztah ما نعرفه هو:

• إذا واجهنا البلاء من خلال # 7115 # 3156 ، فيمكننا العثور على قائمة طويلة من المشكلات التي مضى عليها عدة سنوات والتي تناقش نفس المشكلة
• تم إغلاق معظمها إما بسبب قابلية إعادة الإنتاج (أو التعليق القديم Dockerfile syntax is frozen ، ثم بعد إضافة التعليمات HEALTHCHECK ، تمت إزالة التجميد ولكن ظلت المشكلات مغلقة)
• لقد أوقفت هذه المشكلة العديد من الفرق من الحصول على قابلية استخدام / إنتاجية جيدة للحاويات في التطوير اليومي لسنوات عديدة. كما قال btrepp هذا هو الجحيم
• يدرك أفراد Docker هذه المشكلة ، ولكن هذا من شأنه أن يؤدي إلى كسر فئة من بناء عامل الإرساء الخاص بي! قضايا بسبب ذاكرة التخزين المؤقت المشتركة وهي ليست جيدة
• ولكن لا يبدو أن الانتقال من ذاكرة التخزين المؤقت على القرص إلى ذاكرة التخزين المؤقت للشبكة يؤدي إلى تحسين موثوقية الإنشاء بأي شكل من الأشكال ، فهو بمثابة ذاكرة تخزين مؤقت ممجدة عبر http ، وقد وجد أنه يجعل الأمور أسوأ (تنزيل الإنترنت لكل إصدار ، HTTPS ، حجم الملفات ، وتحطم القرص عند بناء الحاويات ، والتخزين المؤقت للطبقة ، وتنسيق البناء المعقد ، وما إلى ذلك)

بالنظر إلى كل ما نعرفه ، أعتقد أنه من المحتمل أن يتم إغلاق هذا إما على شكل Dupe أو WontFix. لا يبدو أنه يهم ما هي حالات الاستخدام التي نقدمها. تحديث: يسعدني أن أكون مخطئًا هنا. يبدو الاقتراح مفتوحًا :)

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

rdsubhas تهتم بمشاركة الرابط عند الانتهاء؟

rdsubhas هذا ملخص جميل. لا يبدو أنه سيتم إغلاق هذا الخيط كـ dupe / wontfix لأن @ cpuguy83 يعتقد أنه موافق على إضافة --mount أثناء الإنشاء الذي يغطي معظم حالات الاستخدام.

ما أود معرفته هو أن الاقتراح الحالي:

1. لا يغير بناء جملة Dockerfile
2. لا تجعل البنيات تعتمد على المضيف أكثر مما هي عليه حاليًا

ما هي الحجج المضادة المتبقية فيما يتعلق بالفكرة؟ إذا لم يكن هناك أي شيء ، فربما يجب أن نبدأ في مناقشة تفاصيل التنفيذ لآلية --mount .

لإعادة فرض الحجة القائلة بأن البنيات تعتمد بالفعل على المضيف وغير قابلة للتكرار ، أقدم قائمة بأجزاء Dockerfile بهذه الخاصية:

# 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

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

حالة الاستخدام الخاصة بي

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

الظروف

1. يحتوي CircleCI على مفاتيح ssh لتنزيل جميع التبعيات الداخلية أثناء الإنشاء
2. يستضيف GitHub التبعيات الداخلية ويمكن تنزيل البعض الآخر من داخل الصورة أثناء الإنشاء

خيارات

1. استخدم --build-arg لتمرير رمز مميز أثناء الإنشاء (لا يُنصح بذلك بشدة). هذا خيار جذاب وسهل للغاية لأنه "يعمل فقط" بدون أي خطوات إضافية.
2. قم بتنزيل جميع التبعيات وإضافتها إلى سياق الإنشاء. لسوء الحظ ، يتم تنفيذ ADD و COPY في طبقات منفصلة لذلك أنا عالق مع البيانات من الطبقات السابقة.

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

misakwa من المحتمل أن ندعم الأسرار عند الإنشاء في 1.14.

من المثير جدًا سماع @ cpuguy83. سأراقب عندما يتم إصداره. سيؤدي ذلك بالتأكيد إلى تبسيط بعض مهام سير العمل الخاصة بي.

من المحتمل أن ندعم الأسرار عند البناء في 1.14.

هل سيعمل أيضًا على تعيين خرائط وقت الإنشاء لأنواع أخرى من وحدات التخزين مثل yarn-cache على سبيل المثال؟

راجع للشغل هناك طريقة متداخلة لإنشاء صور إنتاجية باستخدام عامل التركيب ، لقد وجدت أنها تعمل وفعالة للغاية:

لذلك قمت بإنشاء ملف docker-compose.build.yml شيئًا مثل هذا:

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) يمكنك بناء حاوية باستخدام تكوين عامل الإرساء:

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

يقوم بإنشاء حاوية وتشغيل برنامج نصي لإنشاء shell my-app.docker.build.sh ، ولا أستخدم Dockerfile وأقوم بكل شيء في البرنامج النصي للبناء:

• تثبيت حزم نظام التشغيل اللازمة
• نسخ كود soruce المطلوب (من مجلد /source المعين)
• تثبيت التبعيات
• بناء / تجميع / اختبار إذا لزم الأمر
• قم بإزالة الحزم والأشياء التي لا تحتاجها لكي تعمل البيئة المستهدفة (لتقليل حجم الصورة النهائي)

ثم تقوم بإنشاء صورة من الحاوية ، لتحل محل CMD لذلك يجب تشغيلها في بيئة الهدف:

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

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

whitecolor yep يعمل :) باستثناء شيء واحد: docker build فعال حقًا في تحميل سياق الإصدار. لسوء الحظ ، لا تعمل وحدات تخزين المصدر المثبتة مع أدوات عامل الإرساء البعيدة (على سبيل المثال ، جهاز عامل الإرساء على السحابة لأجهزة الكمبيوتر المحمولة منخفضة الطاقة / ذات النطاق الترددي). لذلك علينا القيام بسلسلة مرهقة docker run ، docker cp ، docker run ، إلخ ، سلسلة أوامر عامل الإرساء ، ثم أخذ لقطة للصورة النهائية ، لكنها حقًا مخترقة.

إنه يساعد حقًا في الحصول على هذا الجزء رسميًا من بناء عامل الإرساء ، واستخدام الطبقات وبناء السياق 😄

rdsubhas نعم أنت على صواب

whitecolor هذا حل بسيط وفعال حقًا. لقد قطعت للتو 30-40 دقيقة من البناء في المشروع إلى حوالي 5 دقائق. إنني أتطلع إلى إمكانية وجود ميزة - كمية عند الإنشاء ولكن في الوقت الحالي هذا الحل يزيل حقًا خط الأنابيب الخاص بي.

هذا تعليق تركته للإصدار رقم 17745 الذي فهمت أنه قد تم إغلاقه ولكن لم يتم وضع علامة مكرر عليه. يبدو أنني كنت مخطئًا بشأن هذه النقطة الأخيرة: سأعترف بأنني معتاد على أنظمة مثل Bugzilla التي تحدد بشكل صريح شيئًا ما على أنه "حل مضاعف" ، وعرضه في أعلى منطقة وصف للخلل. أنا لست قارئ عقل. (لذا اعتذاري graingert ، لم يكن لدي طريقة كبيرة في المعرفة ، وبالتالي ليست هناك حاجة للصراخ في وجهي بخط 20 نقطة - كان ذلك مفرطًا.)

في حالتي ، سيكون هذا مفيدًا على أنظمة دبيان: تحميل /var/cache/apt كمجلد ، لذا فأنت لا تعيد تنزيل ملفات .deb نفسها مرارًا وتكرارًا. (لا توجد حصة إنترنت "غير محدودة" حقًا ، خاصة هنا في أستراليا ، وحتى لو كانت موجودة ، فهناك وقت ضائع في انتظار التنزيل.)

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

أو الليلة ، أقوم بعمل بعض الصور المستندة إلى Gentoo لنفسي ، وأود تحميل /usr/portage من المضيف. ليس من الصعب على Dockerfile أن يدرك ، "مرحبًا ، /usr/portage (في الحاوية) فارغ ، لا توجد مشاكل سأحصل عليها" عند التشغيل بدون تحميل وحدة التخزين ، أو ، يستخدم فقط الحجم كما هو ، مما يوفر الوقت في جلب نسخة جديدة.

تعد إضافة هذه الذكاء أمرًا تافهًا في نص Bourne shell script… إذا كان المنطق الأساسي لتركيب وحدة التخزين موجودًا في المقام الأول. في الوقت الحالي بالنسبة لصوري Gentoo ، يتعين عليّ سحب /usr/portage في كل مرة أقوم فيها ببناء (لحسن الحظ ، تكون المرآة على شبكة LAN الخاصة بي) مما يعني أن الانتظار بضع دقائق حتى تكتمل هذه الخطوة.

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

يحتوي whitecolor على نهج مثير للاهتمام ، ولكن إذا قمت بذلك ، فقد أستخدم أيضًا Makefile خارجيًا تمامًا لنظام Docker لتحقيق الإنشاء.

sjlongland لم أكن أصرخ في وجهك ، كنت أقوم بملء إشعار كبير "تم حل المشكلة"

أنا أستخدم عامل الإرساء والتركيب لبناء عدة حاويات لبنيتنا التحتية. الحاويات عبارة عن خدمات مصغرة ، مكتوبة في الغالب في nodeJS ، ولكن هناك خدمة صغيرة واحدة مكتوبة في Java ، باستخدام إطار العمل المخضرم.
في كل مرة نقوم فيها بإعادة بناء حاوية جافا ، يتم تنزيل عشرات التبعيات من Maven ؛ يستغرق هذا عدة دقائق. ثم يتم إنشاء الكود في حوالي 15 ثانية.

هذا قبيح للغاية ويؤثر بشدة على إستراتيجية CI الخاصة بنا.

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

أفهم أن هناك مخاوف أمنية ، لأنني أستطيع العبث بالتبعية وإدخال كود سيئ هناك ؛ IMHO التي يمكن التحايل عليها بسهولة من خلال عدم السماح بإنشاء الصور باستخدام "وحدات تخزين بناء" ليتم نشرها على docker-hub أو docker-store.
لتوضيح ذلك بشكل مختلف ، يجب أن يكون هناك تمييز في النطاقات بين استخدام المؤسسة والاستخدام الشخصي لرسو السفن.

stepps تحقق من https://pypi.python.org/pypi/shipwright بدلاً من docker-compose

لقد كنت أتابع هذا الموضوع لفترة من الوقت ، أبحث عن حل جيد لنفسي. لبناء الحد الأدنى من الحاويات بطريقة مرنة بأقل جهد ، أحب حقًا https://github.com/edannenberg/gentoo-bb بواسطةedannenberg.

• يفصل بين تبعيات وقت البناء وتبعيات وقت التشغيل
• تتم المباني في حاويات وتكون معزولة ونظيفة وقابلة للتكرار
• يعالج التبعيات بين الصور وترتيب البناء

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

مثال بسيط على figlet هو: -

build.conf:

IMAGE_PARENT="gentoobb/glibc"

Dockerfile.template:

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

builld.sh

PACKAGES="app-misc/figlet"

configure_rootfs_build() {
        useradd figlet
}

أحب حل whitecolor ، فهو بسيط باستخدام تقنية Docker فقط ثم برنامج نصي بسيط أو أي شيء آخر تريد استخدامه. أنا أستخدم gentoo-bb لأنه أكثر اكتمالاً. تبدو Shipwright جيدة مع المزيد من الميزات التي تركز على المطور مثل التعامل مع الفروع. https://github.com/grammarly/rocker يبدو أيضًا مثيرًا للاهتمام. شكرا لتقاسم الجميع.

فقط صوت آخر يضاف إلى الكومة. ستكون بيئة التطوير المعقدة للغاية الخاصة بنا أبسط إلى حد كبير إذا تمكنا من زيادة وحدات التخزين المحلية على الإنشاء.

يتمثل الحل البديل في تشغيل خادم http أثناء إنشاء خادم http الذي يعرض الملفات المحلية ثم استخدام curl / wget وما إلى ذلك لإحضار الملفات إلى بنية docker. لكنني أتمنى حقًا ألا تكون مثل هذه الاختراقات ضرورية.

حالة استخدام أخرى .. أرغب في إنشاء صور عامل ميناء لبناء نظام تشغيل خاص به إصدارات مختلفة من 10 ثوانٍ. وسائط التثبيت> 80 غيغابايت ، لذلك لا يمكنني نسخ هذا فقط في بيئة بناء عامل الإرساء. سيكون ربط الربط أفضل بكثير.

واحد آخر: يوزع استخدام مشروعي Dockerfiles في المستودع للبناء من مصادر في الحاوية. حاليًا ، نسحب نسخة git أخرى في الحاوية من github. هناك مستنسخات ضحلة وكل شيء ، لكن لا يزال ...

لذلك ، لقد اختبرت [1] على مضيف بناء rhel7 ، وبنية ريد هات لعفريت عامل الإرساء لديها الخيار -v للبناء. لم أختبر على CentOS / Fedora ، لكن يمكن للمرء أن يتخيل أن Fedora / CentOS ربما يمتلكه أيضًا. الأمر يستحق الاختبار. أيضًا ، أصبحت اشتراكات RHEL Developer مجانية الآن [2]:

fatherlinux تحت Fedora يتوفر أيضًا "docker build -v".

fatherlinux يتضمن إصدار CentOS 7 ذلك.

+1 أعتقد أن هذه ستكون ميزة مفيدة حقًا لإضافتها إلى عامل الإرساء الرسمي.

تم التحديث للتو على كل من centos و linuxmint (يعمل الآن 17.03.1-ce) ، هل أفتقد شيئًا هنا؟ لا يمكنني رؤية الخيار -v

على النعناع

$ 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

على سنتوس 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 في CentOS 7 ، توفر حزم Docker غير الرسمية الخيار. أعتقد أنه جزء من مستودع EPEL.

شكراnathanjackson. هل لدينا ETA لهذه الميزة في الإصدار الرسمي؟

wilfriedroset AFAIK ، لا يوجد وقت متوقع لأنه تقرر (عدة مرات) عدم وجود هذه الميزة في عامل التحميل الرسمي للحفاظ على "إمكانية النقل". يُعرف أيضًا باسم السماح لملفات Dockerfiles الخاصة بك بالعمل في أي مكان بما في ذلك خدمة بناء Docker.

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

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

على RHEL 7.3
""
[ root @ rhel7 ~] # بناء عامل ميناء - مساعدة

الاستخدام: بناء عامل بناء [خيارات] مسار | URL | -

بناء صورة من Dockerfile

خيارات:
--build-arg value تعيين متغيرات وقت البناء (افتراضي [])
--cgroup- سلسلة الأصل الاختيارية cgroup الأصل للحاوية
- فترة وحدة المعالجة المركزية int تحديد فترة CFS لوحدة المعالجة المركزية (جدولة عادلة تمامًا)
- cpu-quota int الحد من حصة CPU CFS (جدولة عادلة تمامًا)
-c، - أسهم وحدة المعالجة المركزية int CPU (الوزن النسبي)
--cpuset-cpus string من وحدات المعالجة المركزية (CPU) التي تسمح بالتنفيذ (0-3 ، 0،1)
--cpuset-mems string MEMs للسماح بالتنفيذ (0-3 ، 0،1)
--disable-content-trust تخطي التحقق من الصورة (صواب افتراضي)
-f، --file string Name of the Dockerfile (الافتراضي هو "PATH / Dockerfile")
--force-rm قم دائمًا بإزالة الحاويات الوسيطة
- تعليمات استخدام الطباعة
- سلسلة العزل تكنولوجيا عزل الحاوية
--label value ضبط البيانات الوصفية للصورة (افتراضي [])
-m ، - حد ذاكرة سلسلة الذاكرة
--memory-swap string Swap Limit يساوي الذاكرة بالإضافة إلى المقايضة: "-1" لتمكين المبادلة غير المحدودة
- no-cache لا تستخدم ذاكرة التخزين المؤقت عند بناء الصورة
--pull حاول دائمًا سحب نسخة أحدث من الصورة
-q ، - قم بإيقاف إخراج البناء وطباعة معرف الصورة عند النجاح
--rm إزالة الحاويات الوسيطة بعد بناء ناجح (صواب افتراضي)
- سلسلة بحجم shm حجم / dev / shm ، القيمة الافتراضية هي 64 ميغا بايت
-t، --tag value الاسم واختياريا علامة بتنسيق ' name: tag ' (افتراضي [])
--ulimit value خيارات Ulimit (افتراضي [])
-v، --volume value تعيين حوامل ربط وقت البناء (افتراضي [])
""

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

+1: تثبيت node_modules مرارًا وتكرارًا أمر مروع حقًا ، خاصة بالنسبة لخدمات nodejs الصغيرة
أحاول حل هذه المشكلة باستخدام nFS ، أعتقد أن "التكرار" ليس سببًا جيدًا لعدم تنفيذ هذه الميزة ...

يبدو أن هذا سيكون أكثر أهمية مع دمج # 31257 و # 32063 في.

الق نظرة على # 32507

fatherlinux هل يمكنك شرح كيفية عمل إمكانية النقل عندما يكون لديك أوامر COPY داخل Dockerfile؟ لدي مشكلة حيث أريد تجنب عدد نسخ ملف كبير (لأسباب تعقيد الوقت) وأبحث عن خيار للقراءة فقط وقت الإنشاء لمشاركة الملف مع الحاوية.

arunmk راجع https://github.com/moby/moby/issues/32507

تضمين التغريدة الفكرة هي أنك لا تريد حقًا نسخ البيانات في الحاوية عند الإنشاء. يمكن أن يجعلها كبيرة جدا. نريد فقط البيانات المتاحة في وقت البناء. كما هو مذكور أعلاه ، يمكنك القيام بربط ربط a -v في إصدار Red Hat من برنامج Docker daemon الذي يسمح لك بالحصول على البيانات المتاحة ، لكنها تتم قراءتها الآن فقط (تم نسخها لي الأسبوع الماضي).

لذلك ، إذا كنت في حاجة إليها اليوم ، تحقق من Fedora أو CentOS أو RHEL ويمكنك تحميل نسخة للقراءة فقط من البيانات في وقت الإنشاء ...

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

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

مثال مفتعل:

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

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

شكرا للتوضيحfatherlinux
@ cpuguy83 شكرا على التفاصيل. اسمحوا لي أن أضيف المزيد من التفاصيل إلى مشكلتي التي قد تكون غير شائعة: لدي نظام إنشاء يقوم بإنشاء ملف 3.3 جيجابايت. يضاف ذلك إلى عدد دورات في الدقيقة مبني داخل حاوية عامل إرساء. لذلك تم إنتاج نسختين: واحدة من نظام الإنشاء إلى حاوية عامل الإرساء ، والأخرى من داخل حاوية عامل الإرساء إلى داخل RPM. الآن ، لا يمكنني تجنب النسخة الثانية. كنت أفكر في تجنب النسخة الأولى ولكن يبدو أن هذا غير ممكن أيضًا ، حتى مع الإنشاءات متعددة المراحل.
أستطيع أن أفهم أنه إذا تم استخدام الملف الكبير بشكل متكرر ، فإن النسخة متعددة المراحل كانت ستقلل من عدد مرات تشغيل النسخة إلى "1". استخدمته مرة واحدة وأردت تقليل الرقم إلى "0". هل أنا محق في فهمي أن ذلك لن يكون ممكنًا؟

arunmk بغض النظر عما يجب نسخه إلى مثيل الإصدار من العميل.

@ cpuguy83 شكرا للتوضيح. يبدو أنني يجب أن أتحمل النفقات العامة في الوقت الحالي. هل هذا يحتوي على ذرية؟

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

لقد جربت ما قلته ، باستخدام -v على RHEL7 لمحاولة تحميل دليل للقراءة فقط أثناء الإنشاء ، ولكن حصلت على هذا الخطأ:

لا يتم دعم وحدات التخزين في بناء عامل الإرساء. الرجاء استخدام حوامل ربط فقط.

سيعمل هذا فقط مع حزمة عامل الإرساء من RHEL وليس حزمة Docker. لم يتم قبول التصحيح المنبع.

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

لقد جربت ما قلته ، باستخدام -v على RHEL7 لمحاولة تحميل دليل للقراءة فقط أثناء الإنشاء ، ولكن حصلت على هذا الخطأ:

لا يتم دعم وحدات التخزين في بناء عامل الإرساء. الرجاء استخدام حوامل ربط فقط.

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

تحتاج إلى استخدام الروابط كما ذكر الخطأ ، فمن المحتمل أنك استخدمت -v /something بدلاً من /hostsomething:/containersomething

thebigb وربما الآخرين ، لقد أنشأنا بنية أساسية لتكون قادرًا على استخدام ذاكرة التخزين المؤقت أثناء إنشاءات عامل الإرساء. لقد نشرناها على https://github.com/WebHare/ccache-memcached-server إذا كان يساعدك ، على الرغم من أن حل هذه المشكلة بشكل مثالي قد يكون عفا عليه الزمن.

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

Juse صوت آخر.

حالة الاستخدام الخاصة بي: حاليًا أستخدم أمر الروك MOUNT لمشاركة الدلائل /root/.cache و /var/cache/apk .

لسبب ما ، لدي وصول بطيء جدًا (جدًا جدًا) للشبكة إلى حزم APK وحزم النقطة. أي إعادة بناء ستجعل العملية تستغرق وقتًا طويلاً بشكل لا يصدق. إنها تجعل الأمور أسهل كثيرًا باستخدام ميزة وقت MOUNT .

embrayroxma ألق نظرة على https://github.com/moby/moby/issues/32507 إذا كان ذلك سيعالج حالة الاستخدام الخاصة بك ؛ نرحب بالتعليقات

مع إدخال البنيات متعددة المراحل ، أجد أن الحاجة إلى تحديد وحدة تخزين لذاكرة التخزين المؤقت المحلية الخاصة بـ Maven أمر بالغ الأهمية.

@ gim913 ليست هذه هي الطريقة التي تشارك بها في أي مجتمع. إذا كنت ترغب في المساهمة ، يرجى مراجعة المقترحات الحالية المرتبطة هنا لمعرفة ما إذا كان أي منها يحل حالة الاستخدام الخاصة بك.

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

ألن يكون من الأسهل أن تأخذ نسخة RedHat من عامل الإرساء؟ ربما يمكن لشخص ما هنا أن يوجهك نحو التصحيحات / الشوكات / الالتزامات ذات الصلة للحصول على خيار "-v" في البناء.

unilynx هنا تذهب

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

أقوم بتجميع عجلات python مسبقًا وأريد تثبيت تلك الموجودة في الحاوية دون نسخها وإنشاء طبقة لا أحتاجها حقًا ، أو يجب أن أحاول بطريقة أو بأخرى سحقها. اليوم الأول وأنا أتطلع بالفعل إلى rocker 😢 😢 😢

سيكون هذا من السهل إضافة ومفيد للغاية (أو أمر تحميل ، انظر rocker مرة أخرى). ما مقدار الوقت الذي يقضيه (في المجتمع) في البرمجة حول هذه الميزات المفقودة أو المشابهة؟

awbacker Multi-stag build يحل هذا الأمر جيدًا حيث يمكنك فعل شيء مثل

FROM something AS my_wheels
RUN compile_all_the_things

FROM something
COPY --from my_wheels /wherever
RUN do_stuff_with_wheels

يتم تشغيل الجزء الأول فقط إذا تغير شيء ما. يمكن مشاركة ذاكرة التخزين المؤقت الخاصة به بين ملفات البناء / dockerfiles الأخرى أيضًا.
هذا يجعل البناء بأكمله قائمًا بذاته.

هناك أيضًا اقتراح من شأنه أن يسمح RUN --mount حيث تخبره مواصفات التحميل بتركيب شيء من هدف my_wheels بدلاً من نسخه.

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

@ cpuguy83 هذا لا يعمل من الناحية العملية - على الأقل بالنسبة لبناء Gradle Java. لدي صورة Docker أساسية تحتوي على ملفات Gradle Jar مخزنة مسبقًا ، ولكن إنشاء Gradle لمصدرك هو ما يؤدي إلى تنزيل جميع تبعياتك في ذاكرة التخزين المؤقت.

لا يسمح @ cpuguy83 متعدد المراحل بإزالة العجلات المنسوخة من الصورة الناتجة ، وهذا ما يتحدث عنه awbacker . وبالتالي ، سيتم تخزين المحتوى الموجود في المجلد / أينما يتم تخزينه مؤقتًا وزيادة حجم الصورة.

BryanHunt إذًا جزء من عملية الإنشاء هو تنزيل الأقسام؟ بالتأكيد يجب أن يوفر Gradle طريقة لتخزين هذه الأشياء مؤقتًا دون المرور والبناء فعليًا؟

@ cpuguy83 نعم ، يتم تنزيل الأقسام كجزء من الإنشاء. في الأساس نفس المخضرم. كمرجع: https://github.com/gradle/gradle/issues/1049

هل كان هناك علاقات عامة لتركيبات البناء في مكان ما؟

graingert هنا

👍 لهذا. في Lunar Way ، نريد إجراء عملية "الإنشاء -> الاختبار -> إنشاء صورة الإنتاج" الكاملة في بناء Docker واحد لإزالة تبعيات البناء والاختبار من خادم CI. من خلال عمليات الإنشاء متعددة المراحل ، يمكننا القيام بذلك ، لكن لا يمكننا الحصول على نتائج الاختبار من الحاوية الوسيطة في عملية الإنشاء. لذلك يتعين علينا القيام بذلك في خطوتين في الوقت الحالي - باستخدام Dockerfile منفصل لبناء صورة الاختبار وتشغيلها ثم الانتقال فقط إلى خطوة إنشاء صورة المنتج ، إذا كانت الاختبارات ناجحة.

سيسمح لنا خيار A -v في بناء docker بتخزين نتائج الاختبار في مجلد تم تحميله من خادم CI وإزالة الحاجة إلى العملية الحالية المكونة من خطوتين.

tbflw بشكل افتراضي ، لا يزيل بناء Docker الحاويات الوسيطة بعد إنشاء غير ناجح. لذلك إذا فشل الاختبار ، يمكنك الحصول على نتائج الاختبار من هؤلاء.

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

تضمين التغريدة _
تتمثل إحدى طرق تخزين تبعيات الإنشاء مؤقتًا في جعل التصميم الخاص بك يعمل مثل المثال متعدد المراحل الذي تم إنشاؤه في التوثيق أو ملف Python onbuild Dockerfile .
هذا مثال قدمته يبدو أنه يعمل لصالح المخضرم. سأقوم بنسخه هنا.

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 ./

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

sixcorners هذا لا يعمل لـ Gradle

BryanHunt هذا Dockerfile أو هذا النهج لا يعمل مع gradle؟ سأل cpuguy83 عما إذا كانت هناك طريقة لتنزيل التبعيات دون إجراء بناء فعليًا. لقد قمت بربط مهمة حل التبعيات. ألا يمكنك فقط إضافة ملف build.gradle وتشغيل هذه المهمة؟

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

تعد المرحلة المتعددة بواسطة sixcorners خدعة مثيرة وقد رأيت أنها تستخدم لمديري الحزم المختلفين (مثل npm ، الملحن).

على الرغم من ذلك ، توجد مشكلة ، كلما تم تغيير قائمة التبعيات COPY pom.xml في صورة المرحلة 0 يتسبب في التخلص من الطبقة وبالتالي اختفاء ذاكرة التخزين المؤقت بالكامل. هذا يعني أنه كلما قام مطور بتغيير أي شيء في pom (تعليق ، تبعية 1kBytes) ، يجب إعادة تنزيل ذاكرة التخزين المؤقت بالكامل مرة أخرى.

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

هذه أيضًا مشكلة عندما يكرر المطورون إنشاء صورة ، خاصةً إذا كانوا في اتصالات بطيئة. على الرغم من أنه يمكن للمرء إعداد مثيل Nexus محلي و http_proxy إليه ، إلا أن ذلك له آثار جانبية أخرى (مثل توجيه أي طلب http عبر Nexus).

يعد تعدد المراحل حلاً لطيفًا ، لكنه ليس مثاليًا.

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

على الرغم من ذلك ، توجد مشكلة ، كلما تم تغيير قائمة التبعيات COPY pom.xml في صورة المرحلة 0 يتسبب في التخلص من الطبقة وبالتالي اختفاء ذاكرة التخزين المؤقت بالكامل. هذا يعني أنه كلما قام مطور بتغيير أي شيء في pom (تعليق ، تبعية 1kBytes) ، يجب إعادة تنزيل ذاكرة التخزين المؤقت بالكامل مرة أخرى.

لاحظ hashar أن ميزة COPY --from لا تقتصر على مراحل البناء ؛ من مرجع Dockerfile :

اختياريًا ، يقبل COPY علامة --from=<name|index> يمكن استخدامها لتعيين موقع المصدر إلى مرحلة بناء سابقة (تم إنشاؤها باستخدام FROM .. AS <name> ) والتي سيتم استخدامها بدلاً من سياق الإصدار المرسل من قبل المستخدم. تقبل العلامة أيضًا فهرسًا رقميًا تم تعيينه لجميع مراحل الإنشاء السابقة التي بدأت بتعليمات FROM . _ في حالة تعذر العثور على مرحلة بناء تحمل اسمًا محددًا ، تتم محاولة استخدام صورة تحمل الاسم نفسه بدلاً من ذلك. _

هذا يسمح لك ببناء صورة للاعتماديات الخاصة بك ، ووضع علامة عليها ، واستخدامها لنسخ التبعيات الخاصة بك من. علي سبيل المثال:

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 .

وحدد استخدام صورة dependencies:1.0.0 للاعتماديات الخاصة بك ؛

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

أو (مجرد مثال أساسي للاختبار) ؛

$ 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

في إخراج البناء ، سترى:

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

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

buildkit لديه دعم أصلي لـ git
https://github.com/moby/buildkit

حل.
إنشاء برنامج bash النصي (~ / bin / docker-compose أو ما شابه):

#!/bin/bash

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

/usr/bin/docker-compose $@

وفي Dockerfile باستخدام 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

ثم قم بتشغيل docker-compose build

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

في حالة Python ، عندما نقوم بتنزيل pip install package ، يتم تنزيله وتبعياته إلى مجلد ذاكرة التخزين المؤقت ثم تثبيته على حزم الموقع.
كممارسة جيدة ، نستخدم pip --no-cache-dir install package لعدم تخزين القمامة / ذاكرة التخزين المؤقت في الطبقة الحالية. ولكن للحصول على أفضل الممارسات ، من المستحسن إخراج مجلد ذاكرة التخزين المؤقت من سياق الإنشاء. لذلك بناء الوقت -v سيساعد.
ذكر بعض المستخدمين أعلاه استخدام COPY . /somewhere/in/container/ ، لا بأس من تطبيق المستخدم أو الملفات ولكن ليس لذاكرة التخزين المؤقت. لأن COPY ينشئ طبقة أخرى كطبقة خاصة به ولن تكون إزالة ذاكرات التخزين المؤقت في الطبقات اللاحقة مفيدة. الآثار الجانبية السيئة الأخرى هي أنه إذا تم تغيير ذاكرة التخزين المؤقت عند استخدام النسخ ، فقد تغير السياق وستؤدي الطبقات التالية إلى إبطال مفعولها وإجبارها على إعادة البناء.

wtayyeb إذا كان لديك Dockerfile الذي يتم تشغيله pip install ... فقط عندما يتغير ملف المتطلبات ، فلا يبدو أن إنشاء time -v مهم لأن المتطلبات لا تتغير كثيرًا كما تفعل التطبيقات عند الإنشاء.

wtayyeb يمكنك استخدام Dockerfile متعدد المراحل للحصول على كل من ذاكرة التخزين المؤقت وصورة بسيطة. أي ، استخدم صورة المثبت لتثبيت python في دليل ما ، ثم بالنسبة لصورتك النهائية ، استخدم COPY - من لنقل ملفات python الضرورية فقط دون أي عناصر تثبيت أو حتى pip نفسها.

manishtomar ، شكرًا ، نعم ولا! في حالة نظيفة ، يتم تنزيل جميع التبعيات مرة أخرى وإنشاءها وتحويلها إلى عجلات وتخزينها مؤقتًا ، ثم تثبيتها في بيئة الوجهة. لذلك إذا وضع أحد المتطلبات هناك فهذه وظيفة لمرة واحدة. ولكن إذا تم تحديث تبعية صغيرة واحدة ، فيجب إعادة تنزيل جميع التبعيات وإعادة بنائها وإعادة تدويرها وإعادة تخزينها مؤقتًا لتكون قابلة للاستخدام.
عند استخدام CI لبناء واختبار مكتباتك وتطبيقاتك في مصفوفة من عدة وظائف ، قم بضرب العمل أعلاه في عدد الوظائف المتزامنة في خادم CI الخاص بك وسوف تحصل على زيادة iowait إلى أكثر من 3 ثوان وتحميل متوسط ​​أعلى من 15 حتى مع محركات أقراص الحالة الصلبة. (هذه الأرقام حقيقية لـ 2 من الإنشاءات المتزامنة والتطبيق مع 20 تبعيات تقريبًا) أعتقد أن ذاكرة التخزين المؤقت للنقطة تقوم بذلك بالطريقة الصحيحة ، وتجنب إعادة التنزيل وإعادة البناء وإعادة تشغيل الحزم الجاهزة. وبدون ربط -v نفقد الوقت وموارد الخادم.

ibukanov ، شكرا. أنا أستخدم Dockerfile متعدد المراحل لبناء حزم تطبيقاتي واستخدامها لاحقًا. سيكون من المفيد إذا كان لدي Dockerfile واحد فقط وأريد إنشاءه عدة مرات ، ولكن ماذا لو كان هناك عدة Dockerfiles وكل واحد منها مبني على إصدار python (2.7،3.6 في الوقت الحالي) ولدي أيضًا العديد من ملحقات c التي تحتاج إلى يتم بناء الصورة الأساسية المختارة؟ ماذا عن الفقرة أعلاه؟

thaJeztah إن اقتراحك رائع وسيوفر لنا بعض الوقت ، ولكن في حالة ذاكرات التخزين المؤقت للبناء ، لا نريد حقًا نسخ أي شيء من الصورة الأخرى.
لماذا لا يمكننا الوصول إلى صورة أخرى دون نسخها؟

thedrow كان المثال الخاص بي مع الميزات الموجودة حاليًا ؛ ألق نظرة على عرض RUN --mount (https://github.com/moby/moby/issues/32507) ، والذي قد يكون أكثر ملاءمة لحالة الاستخدام الخاصة بك

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

أنا أيضًا مستخدم حاوية gentoo وتمت إعادة توجيهي من https://github.com/moby/moby/issues/3156 وهي حالة استخدام صالحة تمامًا لهذه الوظيفة المفقودة.

كل ما أريده حقًا هو القدرة على تحميل محتويات صورة أخرى في وقت الإنشاء حتى لا أقوم بتضخيم صوري.

يبدو kbaegis وكأنه تطابق تام مع الميزة المقترحة في https://github.com/moby/moby/issues/32507

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

يبدو أن https://github.com/projectatomic/buildah سيتفوق في الواقع على بناء عامل الإرساء بسرعة كبيرة هنا لهذه الوظيفة الأساسية. أعتقد أنني سأغير خط الأنابيب الخاص بي بمجرد حدوث ذلك.

kbaegis ماذا أتيت إلى هنا لتضيف إلى هذه المناقشة؟ لقد وصفت حالة استخدام تتطابق تمامًا مع اقتراح مختلف ؛

كل ما أريده حقًا هو القدرة على تحميل محتويات صورة أخرى في وقت الإنشاء حتى لا أقوم بتضخيم صوري.

إنه مفتوح المصدر ، الأشياء لا تظهر للوجود بطريقة سحرية.

ما الذي أتطلع لإضافته إلى المناقشة؟

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

أجبرتني السرعة الجليدية والأولوية المنخفضة لدعم حالة الاستخدام هذه (وأي حل بديل موثوق يوفر هذه الوظيفة) على استخدام أدوات أخرى وأنني أتخلى عن خط أنابيب البناء هذا بسبب فقدان الوظائف.

لدي حالة استخدام (إعادة صياغة ، أنا متأكد) لإضافتها. # 32507 قد يناسب هذا بشكل أفضل.

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

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

draeath ألق نظرة على https://github.com/grammarly/rocker . إنه يدعم بالفعل تعليمات MOUNT الجميلة.

draeath أيضًا ، تحقق من Buildah ، فهو يدعم الحوامل افتراضيًا لأنه تم إعداده مثل أداة البرمجة. يدعم أيضًا الحوامل باستخدام Dockerfile:

https://github.com/projectatomic/buildah

شكرًا لكماfatherlinux و @ lig - سيساعدني هذا في إنجاز مهمتي. ما زلت أعتقد أنه لا ينبغي أن أبتعد عن المشروع للقيام بذلك ، على الرغم من ذلك ، وما زلت أرغب في رؤية هذا و # 32507 يتم تنفيذه ؛)

لقد جئت إلى هنا عبر بعض البحث في googling لأطلب نفس الميزة ، وحدات التخزين في وقت "إنشاء عامل الإرساء" ، وليس وقت "تشغيل عامل الإرساء".

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

أرغب في إنشاء صورة عامل إرساء تقوم بالمرور الأول "إنشاء صورة البرنامج الثابت" ، ثم أكون قادرًا على إنتاج الحاويات التي تدفع فقط صورة البرنامج الثابت إلى ثنائي الفينيل متعدد الكلور الجديد خارج الخط. قد يبدو ملف Dockerfile بالشكل التالي:
----------[ اقطع هنا ]----------
من الصورة الأساسية كمنشئ
نسخ src src
RUN build-src

من الصورة الأساسية كما المتعري
نسخة - من = أدوات بناء المنشئ
تشغيل وحدة المعالجة المركزية والبناء والفلاش - البناء فقط
----------[ اقطع هنا ]----------
لسوء الحظ ، تتطلب خطوة بناء وفلاش وحدة المعالجة المركزية الوصول إلى الجهاز المستهدف عبر ناقل USB ، على الرغم من أنها لن تدفع صورة البرنامج الثابت إلى الجهاز. وبالتالي أحتاج إلى أخذ "-v / dev / usb / bus: / dev / usb / bus" من الأمر "docker run" وإدخاله في الإنشاء بدلاً من ذلك.

من الواضح أن هذا غير ممكن حاليًا.

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

تحديث لأي شخص مهتم: لقد قمت مؤخرًا بإعادة بناء أنبوبتي بالكامل بنجاح مع buildah. لقد حصلت حاليًا على خطي أنابيب يعملان بشكل متوازٍ ، ويقوم خط أنابيب oci / buildah بإنشاء صور أصغر (على وجه التحديد إزالة / usr / portage في حالتي عن طريق إخفائه باستخدام حامل آخر).

وأخيرًا هذه الميزة هنا: https://github.com/docker/docker-py/issues/1498

لكني أريد وحدات تخزين RW لذاكرة التخزين المؤقت للبناء

في السبت ، 28 أبريل 2018 ، 17:29 Коренберг Марк ، كتب [email protected] :

وأخيرًا هذه الميزة هنا: docker / docker-py # 1498
https://github.com/docker/docker-py/issues/1498

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/14080#issuecomment-385188262 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAZQTJodLCCzyDdPFtNiIUZ_z85YvLWbks5ttJjagaJpZM4FIdOc
.

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

الهدف المثالي هو الإنشاء مرة واحدة ، والاختبار مرة واحدة ، والاستمرار في تقديم ملف النتائج للنظام المضيف ، حتى في حالة فشل الاختبارات (وخاصة في حالة الحدث) ، مما يؤدي إلى إيقاف الإنشاء.

نعم من فضلك. طوال اليوم.

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

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

يجب أن يكون قد تمت إضافته بالفعل عند تقديم ملف عامل الإرساء متعدد المراحل. في النهاية سيواجه الجميع هذه المشكلة بمجرد أن يبدأوا في تشغيل اختبارات الوحدة كمرحلة في ملف عامل الإرساء متعدد المراحل خاصةً في حالة إنشاء خطوط أنابيب CI. نواجه أيضًا هذه المشكلة حيث يتعين علينا نشر تقارير اختبار الوحدة إلى VSTS. تم بالفعل تطبيق الحل البديل الذي ذكره hoffa . ولكن بعد كل شيء هو حل بديل ويجعل الأمور معقدة.

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

ajbouh نعم ، ربما على https://github.com/moby/buildkit/issues

راجع https://github.com/moby/moby/issues/32507#issuecomment -391685221

في الأربعاء ، 23 مايو 2018 ، الساعة 19:22 كتب Akihiro Suda [email protected] :

ajbouh https://github.com/ajbouh نعم ربما في
https://github.com/moby/buildkit/issues

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/14080#issuecomment-391566368 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAAcnSqNoVc4j34ElECy53gIfPecQFKfks5t1hlkgaJpZM4FIdOc
.

بينما لا يمكنك إضافة وحدات تخزين في وقت الإنشاء ، يمكنك إضافة مضيفين ، لذلك أقوم الآن بإنشاء جميع صور عامل الإرساء بشيء مثل --add-host yum-mirror:$MIRROR_IP والذي يخدم مرآة yum التي تكتشفها صور البناء الخاصة بي بعد ذلك عبر غلاف حولها يم. يكون مفيدًا عندما يغير مشروعي التبعيات عدة مرات في اليوم وأنا غير متصل بالإنترنت أو في حالة اتصال سيئ (يتضمن جزء من المشروع تحديث وتنظيف أقسامه العديدة).

أجد مقاومة دوكر لحل هذه المشكلة مثيرة للغضب.

تم دمج الدعم التجريبي لـ buildkit مؤخرًا ، والذي يأتي مع خيار RUN --mount=<opts> <command> .

رابط إلى ملاحظة @ cpuguy83 : https://github.com/moby/buildkit/pull/442

glensc @ cpuguy83 متى نتوقع إصدارًا لهذه الميزة المدمجة؟

+1

لا يحتوي RUN --mount على دعم للحجم ، لذا تظل أشياء مثل https://github.com/avsm/docker-ssh-agent-forward مستحيلة في وقت الإنشاء ، ما الحل لذلك؟

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

docker build --secret متاح أخيرًا في Docker 18.09 https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

هل يمكننا إغلاق هذه القضية؟

--secret غير قابل للاستخدام في حالة استخدام التخزين المؤقت ، مما يمكنني قوله.

AkihiroSuda RUN --mount بشكل عام يبدو وكأنه شيء مناسب كحل لهذه المشكلة.

نعم ، أفترض أن RUN --mount=type=cache (لحجم ذاكرة التخزين المؤقت) و --mount=type=secret مع docker build --secret (للحجم السري) يغطي المشكلة تقريبًا.

AkihiroSuda لذا ، سيكون من الجيد رؤية مثال عملي لحل المشكلة الأصلية

AkihiroSuda من المقالة (https://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066) رأيت حالتين لاستخدام الحامل أثناء الإنشاء: Secret and SSH

[سر]

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

هناك حالتا استخدام أخريان (أتذكرهما) لم يتم توضيح كيفية استخدامها في المقالة ولا في هذه المشكلة:

1) [ذاكرة التخزين المؤقت] RUN --mount=type=cache
2) المجلدات بشكل عام (على سبيل المثال ، لتحميل شهادات SSL ، أو في حالة الكميات الكبيرة التي يجب استخدامها أثناء الإنشاء ، ولكن لا يتم تضمينها في الصورة التي تم إنشاؤها ، وما إلى ذلك ...)

بمجرد تركيب حالة الاستخدام على مساحة عمل yarn قبل تشغيل webpack

يمكنك فعل كل هذا ..

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

يمكنك أيضًا استبدال from=<some image> بـ from=<some build stage>

هذا مثال مفتعل:

# 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

إليك بعض الوثائق حول هذا: https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md

أتفق مع AkihiroSuda ، يجب أن يتعامل هذا مع جميع الحالات ... ولكن من فضلك أخبرنا إذا لم يحدث ذلك.

AkihiroSuda @ cpuguy83 : لسوء الحظ ، فإن التطبيق الحالي (buildkit in docker 18.09) به مشاكل مع السجلات الخاصة. اعتبارًا من الآن ، لا يمكن استخدام هذه الميزات الجديدة إذا كان عليك جلب صورك من خلال سجل خاص. راجع اختباراتي في https://github.com/moby/moby/issues/38303.

أعتقد أن هذا سيستخدم أيضًا في قطع Jenkins الأثرية ، لذلك على سبيل المثال ، إذا قمت بإنشاء صورة Docker وتجميع شيء بداخلها ، فأنا أريد الحصول على بعض القطع الأثرية مثل إخراج junit pytest

هذا من الممكن ان يكون مفيد جدا. أنا أفضل حقًا ألا أحتاج إلى إضافة --experimental لدعم RUN --mount=type=cache /user/.cache/pip pip install (من أجل توفير أطنان من عرض النطاق الترددي لمؤشر الحزمة).

يحتوي buildah bud ( buildah build-using-dockerfile ) على خيار --volume / -v :
https://github.com/containers/buildah/blob/master/docs/buildah-bud.md

يمكن لـ buildah تشغيل البنيات على أنها ليست جذرية بدون مقبس عامل إرساء.

لأن تنزيلات الحزم من الشبكة أكثر قابلية للتكرار؟

لا حاجة لإضافة "- تجريبي" ، فقط "DOCKER_BUILDKIT = 1" على العميل.

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

لاحظ أنه يمكنك أيضًا تركيب صورة في البناء.

نعم ، تعد إنشاءات الشبكات أكثر قابلية للتكرار حيث أن السياق موجود بالكامل في ملف Dockerfile.

من المؤكد أن وجود RUN apt-get update في Dockerfile يضمن أن يكون لدى المرء جميع الخطوات اللازمة لبناء الصورة. ومع ذلك ، لا يمكن استنساخه نظرًا لأنه يتم تنزيل سياق إضافي من جهة خارجية. الاختلاف الوحيد مع التحميل هو أن جميع السياقات الخارجية محددة بالفعل في Dockerfile.

إذا كان عليك تحميل السياق من المضيف لجعل البناء يعمل ، فهذه تجربة سيئة.

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

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

RUN apt-get update

docker build -t aptupdate-20190417

وفي الصورة الفعلية:

FROM aptupdate-20190417
FROM somebaseimage

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

كرر ذلك مع سياق بعيد آخر وستحصل بشكل أو بآخر على شيء يمكن استنساخه.

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

أعني ، RUN --mount=type=cache هو بالضبط لهذا.
أو يمكنك حتى التحميل من صورة أخرى من التسجيل وسيتم جلبها.

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

تم رفض -v على شوكة buildah و redhat بشكل صريح هنا لأنه واسع للغاية ... كي لا نقول أنه غير مفيد ، ولكنه ينقطع بسهولة من مضيف إلى مضيف ، وهو ما يتعارض مع تصميم docker build .
وفي الوقت نفسه ، كان سبب إضافته RH (أو بشكل أكثر تحديدًا سبب قرارهم العمل عليه) هو التمكن من تحميل بيانات اعتماد RHEL في بيئة الإنشاء.

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

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

يمكنني تحديد volumes: مرة واحدة في docker-compose.yml؛ ولكن بدلاً من ذلك تحتاج إلى القيام بـ DOCKER_BUILDKIT=1 وإضافة RUN --mount=type=cache في Dockerfiles التي تتم إدارتها في اتجاه المنبع؟ لماذا ا؟

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

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

الرجاء فقط إضافة --volume حتى يعمل docker-compose.yml الخاص بي.

من فضلك فقط أضف المجلد حتى يعمل عامل الإرساء compose.yml الخاص بي.

جعل عملك "إنشاء عامل الميناء" أمرًا عكسيًا.
docker- يؤلف للمستهلكين هذا المشروع ، وليس العكس.

يتفاعل عامل الميناء - يؤلف مع مقبس عامل الإرساء. docker-compose YAML هي طريقة موحدة لتخزين خيارات الحاوية (والتي يمكن تحويلها إلى k8s pod defs (التي يدعمها podman إلى حد ما)). كيف يمكنني تحديد DOCKER_BUILDKIT=1 بطريقة قابلة للتكرار؟ يمكنني تحديد build_volumes: بطريقة قابلة للتكرار في docker-compose.yml.

عندما أقوم - في برنامج CI الخاص بي ببناء البرنامج النصي الذي يتم تشغيله n مرة في اليوم - أنشئ صورة عن طريق الاتصال على سبيل المثال docker-compose build (على سبيل المثال مع ansible) أو packer (بدلاً من buildah و podman) ، فأنا لديها بعض الأهداف:

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

إذا كنت بحاجة إلى مسح وحدة تخزين ذاكرة التخزين المؤقت ، فيمكنني مسح وحدة تخزين ذاكرة التخزين المؤقت.

0. الوضع الراهن

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

• ممكن اليوم
• O (n_builds): استخدام النطاق الترددي
• لن تعمل دون اتصال: يعتمد على الشبكة
• إعادة بناء أبطأ

أ. النسخ

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

• ممكن اليوم
• ~ O (1) حزمة مؤشر النطاق الترددي
• O (n): في كل إصدار (* ONBUILD )
  
  
  
  • ينسخ ذاكرة التخزين المؤقت
  
  
  • يحرر الحزم
  
  
  • يحذف ذاكرة التخزين المؤقت
  
  
• يعمل حاليا
• إعادة بناء أبطأ

ب. تفرع وتعديل كل ملف Dockerfile من المنبع لإضافة RUN --mount=type=cache وتعيين متغير بيئة

# 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 . [...]

• ممكن اليوم
• يقدم هذا بالفعل عدم إمكانية إعادة الإنتاج: هناك معلمة Dockerfile إضافية ، ومعاملة إضافية لـ compose.yml تقدم تباينًا في الإخراج: الصورة المبنية المسماة.
• المستندات: كيف يتم مسح ذاكرة التخزين المؤقت --mount=type=cache (؟)
• ~ O (1) حزمة مؤشر النطاق الترددي
• يعمل حاليا
• يعيد بناء سريع

ج- حدد وحدة تخزين يتم تركيبها في وقت الإنشاء

ج 1. بناءا

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

• ممكن اليوم
• يقدم أيضًا عدم التكرار
• المستندات: كيفية مسح ذاكرة التخزين المؤقت
• ~ O (1) حزمة مؤشر النطاق الترددي
• يعمل حاليا
• يعيد بناء سريع

ج 2. عامل ميناء (ما تطلبه هذه المشكلة)

C.2.1 عامل ميناء CLI

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

• غير ممكن اليوم
• يقدم أيضًا عدم التكرار
• المستندات: كيفية مسح ذاكرة التخزين المؤقت
• ~ O (1) حزمة مؤشر النطاق الترددي
• ستعمل حاليا
• يعيد بناء سريع

C.2.2 عامل الإرساء يؤلف

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

$ docker-compose build

• غير ممكن اليوم
• يقدم أيضًا عدم التكرار
• المستندات: كيفية مسح ذاكرة التخزين المؤقت
• قد يتطلب مراجعة مخطط تكوين عامل الإرساء
• ~ O (1) حزمة مؤشر النطاق الترددي
• ستعمل حاليا
• يعيد بناء سريع

...

• نسخ || REMOTE_FETCH || اقرأ()
  
  
  
  • أي من هؤلاء أكثر استنساخًا؟
  
  

: point_up: فقط للتذكير. يمكنك تثبيت ملف تم تنزيله عن طريق التحقق من المجموع الاختباري الخاص به. بعض مديري الحزم ، مثل النقطة ، يدعمون ذلك أيضًا.

westurner شكرًا على الشرح التفصيلي.

أعتقد أن ما يلي سيكون مشابهًا لحالتك ب ، ولكن يمكنك مسح ذاكرة التخزين المؤقت وستنتهي مثل حالتك C2 (ما تطلبه ، على ما أعتقد):

_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 / ملف Docker: _

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)

يمكنك بناء صورة ذاكرة التخزين المؤقت باستخدام:

docker-compose build my-cache

يجب أن يرتبط الأمر RUN --mount=target=/export,type=bind,from=local/my-cache بالصورة. إذا كنت ترغب في تحديث ذاكرة التخزين المؤقت ، يمكنك إزالة صورة ذاكرة التخزين المؤقت وإعادة بنائها.

إذا كان هذا لا يزال يستخدم ذاكرة التخزين المؤقت في RUN --mount... ، فيمكنك استخدام ملف .env مع إصدار ، قم بتضمين الإصدار في image: local/my-cache:$MY_VERSION و from=local/my-cache:$MY_VERSION (يجب أن يكون كذلك المدرجة كحجة بناء).

يمكنك تضمين خدمة my-cache في ملف docker-compose آخر إذا كنت لا تريد أن تكون في نفس الملف مثل خدماتك الرئيسية.

ستظل بحاجة إلى استخدام DOCKER_BUILDKIT=1 (كما هو الحال في حالة B الخاصة بك ، لكنني أعتقد أن هذا لن يكون ضروريًا في الإصدارات المستقبلية) ولن تكون قابلة للتكرار (ولكن حالة C2 الخاصة بك ليست كذلك).

ماذا ستكون العقوبة التي تراها إذا لم تكن قابلة للتكرار؟ إذا قمت بوضع صورة ذاكرة التخزين المؤقت local/my-cache في Docker hub (باسم ريبو مختلف) أو في سجل خاص واستخدمت إصدارات لكل بناء (سيؤدي ذلك إلى إنشاء ذاكرة تخزين مؤقت مختلفة) ، مع وجود نفس الإصدار دائمًا ذاكرة التخزين المؤقت ، ألا يجعلها قابلة للتكرار ؟ لن تحتاج حتى إلى تضمين الخدمة في ملف docker-compose واستدعاء الأمر build. (يجب الوصول إلى Docker Hub من الشبكة ، لكن هذا هو نفسه بالنسبة لصورك الأخرى ، على ما أفترض ، وبعد التنزيل مرة واحدة ، لن تكون هناك حاجة إليه بعد الآن ، إلا إذا قمت بإنشاء إصدار جديد بذاكرة تخزين مؤقت جديدة)

إخلاء المسؤولية: لم أختبر الكود أعلاه.

Yajo تم تنفيذ دعم المجموع الاختباري بالنقطة في الأصل في "زقزقة" ثم تم دمجه في نقطة. يمكنك إضافة تجزئات جيدة معروفة كأجزاء عنوان URL في إدخالات ملف متطلبات النقطة. (هناك تمويل للتحسينات الأمنية في مشروع PyPA هذا العام ؛ تم التخطيط لدعم TUF (إطار التحديث ؛ تمامًا مثل Docker Notary) في PyPI في وقت لاحق من هذا العام.) من المحتمل أن يكون موضوعًا في وقت لاحق من هذا العام.
(عدل ؛ القليل من الوقت الإضافي لكن للمعنيين) https://discuss.python.org/t/pypi-security-work-multifactor-auth-progress-help-needed/1042/

lucasbasquerotto شكرا لمساعدتكم. هذا الأمر أكثر تعقيدًا من مجرد تحديد --volume في وقت الإنشاء. على وجه التحديد ، يبدو أنه يتطلب:

• تحديد DOCKER_BUILDKIT=1 في بيئة الصدفة docker build
• تعديل أي / كل تعليمات Dockerfile RUN الأولية باستخدام (تحرير) RUN --mount=type=cache و args
• قراءة / كتابة الوصول إلى صورة أخرى؟ التحولية! أم أن ذاكرة التخزين المؤقت المذكورة مجمدة بإصدارات قديمة على الأرجح؟

إذا كان بإمكاني نسخ الملفات من المضيف ، أو تحديد معلمات وقت الإنشاء التي لم يتم تخزينها في مكان آخر ، فلا أرى كيف يكون تحميل وحدة تخزين في وقت الإنشاء أقل قابلية للتكرار؟

نسخ || REMOTE_FETCH || اقرأ()

• أي من هؤلاء أكثر استنساخًا؟

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

تحديد DOCKER_BUILDKIT = 1 في env بنية docker build

إذا كنت تستخدم docker-compose ، كما رأيت في مشاركاتك الأخرى ، وإذا كنت تقوم بتشغيله من حاوية ، مثل:

$ 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

ثم يمكنك تحرير الملف الذي تم تنزيله في /usr/local/bin/docker-compose لاستخدام هذا المتغير env. تغيير من:

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

ل

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

هذا تغيير سهل للغاية وشفاف لمن يدير الأمر.

_ (إذا لم تقم بالتشغيل كحاوية ، فلن ينطبق ما سبق) _

تعديل أي / كل تعليمات Dockerfile RUN الأولية باستخدام RUN --cache و args

في حالة الكشف عنها ، سيكون الأمر RUN --mount=type=bind... ، ولكن على أي حال ، فإن الاضطرار إلى تغيير Dockerfile يعد أيضًا IMO سيئًا. سيكون الخيار -v أفضل بكثير وأكثر شفافية .

قراءة / كتابة الوصول إلى صورة أخرى؟ التحولية! أم أن ذاكرة التخزين المؤقت المذكورة مجمدة بإصدارات قديمة على الأرجح؟

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

أي من هؤلاء أكثر استنساخًا؟

أنا أعتبر قابلاً للتكرار كشيء سيكون هو نفسه تمامًا حتى لو قمت بتشغيله في جهاز آخر. بهذا المعنى ، إذا دفعت صورة إلى سجل عامل ميناء (آمن وموثوق) ، ولم تغير هذه الصورة أبدًا ، فسأعتبرها قابلة للتكرار (إذا كانت لديك مخاوف بشأن الاتصال بالإنترنت ، فيمكنك استخدام سجل خاص والوصول إليه داخل VPN أو شيء من هذا القبيل (لم أستخدم سجلاً خاصًا بنفسي أبدًا)).

إذا كان الأمر COPY ينسخ ذاكرة التخزين المؤقت للجهاز ، فلا أعتبره قابلاً للتكرار لأنه إذا قمت بتشغيل pip install (أو apt-get ، أو أيًا كان) في جهاز آخر ، في وقت آخر ، يمكنك ضمان أن محتويات ذاكرة التخزين المؤقت ستكون هي نفسها؟ ربما قد يكون هذا مصدر قلق بالنسبة لك. ربما لا.

من ناحية أخرى ، إذا كانت لديك ملفات تمتلكها في مكان موثوق به "تمتلكه" (مثل حاوية S3) ، فقم بتنزيل هذه الملفات في جهازك وانسخ هذه الملفات باستخدام الأمر COPY ، ثم يمكنك إعادة إنتاجها من مكان آخر نفس النتائج (بافتراض أن الملفات لم تتغير وأن الجهاز الآخر مطابق للجهاز السابق). لذلك سأعتبر هذا على أنه قابل للتكرار. يعتمد ذلك على المكان الذي تأتي منه هذه الملفات ومدى تحكمك بها.

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

هناك نوع من خطأ شبكة Docker الذي يجعل go mod download غير موثوق به داخل الحاوية أيضًا (على الأقل بالنسبة للتطبيقات بحجمنا) ، لذلك مجرد تشغيله في كل مرة لتنزيل كل GOPATH/pkg/mod الخاص بي مرة أخرى هو ليس مجرد هدر ، بل مكسور. 🤷‍♀

يمكنني تجنب الكثير من نسخ الملفات غير الضرورية إذا كان بإمكاني استخدام --volume !

kevincantu RUN --mount = type = يجب أن تغطي ذاكرة التخزين المؤقت حالة الاستخدام الخاصة بك

يتطلب ذلك تنزيلًا واحدًا ناجحًا على الأقل للوحدات من داخل بناء عامل ميناء ، وفي هذه الحالة بالذات لم أر ذلك مطلقًا ..

https://github.com/moby/moby/issues/14080#issuecomment -484314314 بواسطة westurner نظرة عامة جيدة جدًا ولكني لم أستطع الحصول على buildkit للعمل:

$ 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 بـ # syntax=docker/dockerfile:experimental .

أود بالفعل استخدامه عبر docker-compose . حاولت ENV DOCKER_BUILDKIT 1 في Dockerfile وتمريرها أيضًا من docker-compose.yml عبر ARG DOCKER_BUILDKIT لكنها كلها متشابهة:

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

lucasbasquerotto كيف يمكن ترجمة ما اقترحته في https://github.com/moby/moby/issues/14080#issuecomment -484639378 إلى إصدار مثبت من Docker-compose؟

أخيرًا ، لست متأكدًا مما إذا كان هذا سيغطي حالة الاستخدام الخاصة بي ، ربما يمكن لبعضكم أن يخبرني ما إذا كان ينبغي علي متابعة ذلك. أرغب في استخدام ذاكرة التخزين المؤقت لوقت البناء من أجل التنمية المحلية والتي تظل قائمة بين البنيات بحيث عند تحديث التبعيات ، سيتعين تنزيل العناصر الجديدة فقط. لذلك أود إضافة RUN --mount=type=cache,target=/deps إلى Dockerfile وتعيين ذاكرة التخزين المؤقت لمدير التبعية على /deps .

لتكوين عامل الإرساء ، راجع https://github.com/docker/compose/pull/6865 ، والذي سيكون في الإصدار القادم المرشح للإنشاء

لدي حالة استخدام أخرى ... أريد إنشاء حاويات للذراع على مضيف x86_64 مع binfmt المكون. هذا يتطلب أن يكون لديّ محاكي وحدة المعالجة المركزية qemu الثابت الخاص بالعمارة في / usr / bin .

الحل الحالي هو إضافة qemu-arm-static إلى الحاوية كملف مثل:

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
...

سيكون الحل الأسهل هو تحميل ملفي فقط إذا لزم الأمر داخل الحاوية مثل:
docker build -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static -t test:arm32v7 .
يعمل هذا بشكل جيد جدًا لتشغيل عامل الإرساء ، لكني أفتقد هذه الوظيفة لبناء الحاويات.

هل هناك حل آخر كيف يمكنني إنشاء حاوية arm على مضيفات x86_64 أو هل يمكننا السماح بوحدات تخزين في وقت الإنشاء لهذه الحالة على الأقل؟

تسمح أحدث نوىjneuhauser بتحميل هذه الثنائيات بشكل ثابت ، لذلك ليست هناك حاجة لتكوينها في كل مرة. يمكنك تحقيق ذلك على سبيل المثال عن طريق تشغيل صورة linuxkit/binfmt في وضع الامتياز مرة واحدة بعد التمهيد.

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

alehaa ألا تزال بحاجة لمحاكي qemu الثنائي الثابت داخل الحاوية ، رغم ذلك؟

cybe لم يعد هذا مطلوبًا ، إذا تم استخدام العلامة F (وهو ما تفعله الحزمة linuxkit/binfmt ). يمكنك العثور على مزيد من المعلومات حول هذا هنا .

هل يمكن لشخص ما توفير إعداد عمل لتجربة buildkit؟ لا يمكنني تشغيله على Ubuntu. الإعداد الخاص بي هو كما يلي:

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 19.03.1 ، الإصدار 74b1e89

DOCKER_BUILDKIT=1 sudo docker build .

استجابة خطأ من البرنامج الخفي: سطر خطأ تحليل Dockerfile 12: علامة غير معروفة: mount

لا يحمل sudo متغيرات env إلا إذا أخبرته بـ sudo -E أو قمت بتعريف المتغير داخل sudo.

لقد كتبت بضع كلمات حول هذه الميزة وأنشأت بعض الأمثلة البسيطة التي توضح كيفية التخزين المؤقت

• تبعيات bundler باستخدام docker
• تبعيات NPM باستخدام docker-compose

تحرير: انظر أدناه

@ cpuguy83 شكرا!

thisismydesign آسف لإفساد الإثارة الخاصة بك ، لكن لا يمكنك - تخزين node_modules ، لن يكون موجودًا في الصورة النهائية ، لذا فإن تطبيقك معطل.

glensc اللعنة أنت على حق .. هل هناك طريقة لجعل ذاكرة التخزين المؤقت لوقت البناء جزءًا من الصورة النهائية؟

بصراحة ، اعتقدت أن هذا سيؤخذ في الاعتبار لميزة يتم الإعلان عنها على أنها

يسمح لحاوية البناء بتخزين الدلائل مؤقتًا للمترجمين ومديري الحزم.

يجب أن تكون قادرًا على تعيين ~ / .npm بدلاً من ذلك ... https://docs.npmjs.com/files/folders.html#cache

@هذا تصميمي

يمكنك استخدام صورة أخرى كذاكرة تخزين مؤقت ، إما عن طريق بنائها في Dockerfile الخاص بك أو صورة حرفية مخزنة في سجل في مكان ما واستخدام COPY --from

FROM example/my_node_modules:latest AS node_modules

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

هذا مجرد مثال يمكنك استخدامه للعديد من الأشياء المختلفة.

آخ أنا أكره طرح هذا الأمر والمشاركة هنا (أيضًا مرحبًا يا أصدقاء)

لكن لدينا حالة استخدام لهذا.

هل هناك مكان جيد يمكنني المشاركة فيه أو مكالمة أو قائمة يمكنني الانضمام إليها للحصول على ملخص هنا؟

أيضًا إذا احتجنا إلى شخص ما لوضع بعض الموارد على هذا ، فلدي 1 kris nova وفريق صغير يمكنني على الأرجح إقناعه بالنظر إلى هذا.

TLDR هل يمكنني كتابة هذا من فضلك؟ هل هناك أي شخص يمكنني التحدث معه حول هذا؟

_TLDR_ هل يمكنني ترميز هذا من فضلك؟ هل هناك أي شخص يمكنني التحدث معه حول هذا؟

لا يمكنني التحدث عن Docker ولكن انطباعي هو أنهم ليسوا منفتحين على إضافة وحدة تخزين متزايدة إلى البنيات (وأنه ينبغي عليهم إغلاق هذه المشكلة على الأرجح)

يتم الآن تغطية الكثير من حالات الاستخدام الخاصة بـ buildtime -v بواسطة buildkit. لقد حلها على الأقل بالنسبة لي.

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

شكرا unilynx

+1 إلى unilynx عند إغلاق هذه المشكلة ، حلت buildkit مشكلات حجم وقت الإنشاء بالنسبة لي أيضًا.

أراهن أنه إذا أسقط شخص ما بعض الروابط ومثال على ذلك ، يمكننا إقناع أصدقائنا بالضغط على زر الإغلاق اللامع.

(سأستفيد منهم أيضًا)

لم يتم حل حالة استخدام التخزين المؤقت بالنسبة لي وللعديد من الآخرين نظرًا لأن أحجام وقت الإنشاء باستخدام buildkit غير موجودة في الصورة النهائية.

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

لقد تمكنت من إعادة بناء صورتي فوق نفسها بحيث لا يلتقط نظام ملفات التراكب سوى دلتا صغيرة.

حتى أنني تمكنت من إعادة استخدام الحجم للصور الأخرى في وقت الإنشاء.

هل الناس الآخرين غير قادرين على القيام بذلك؟

(ذاكرة التخزين المؤقت) تتصاعد في الواجهة الأمامية "التجريبية" ؛ الموضحة في https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md (على وشك التوجه إلى اجتماع ، ولكن يمكنني ربط المزيد من الأمثلة الموسعة)

شكرا thaJeztah LMK إذا كان بإمكاني المساعدة هنا بأي طريقة :)

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

thisismydesign آسف لإفساد الإثارة الخاصة بك ، لكن لا يمكنك - تخزين node_modules ، لن يكون موجودًا في الصورة النهائية ، لذا فإن تطبيقك معطل.

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

@ kris-nova لم أحل هذه المشكلة ولكن مرة أخرى لا أبحث عن استخدام نصوص باش. ربما نحتاج إلى مشكلة جديدة ولكن هذه حالة استخدام شائعة جدًا لم يتم حل AFAIK بعد.

thaJeztah فيما يلي بعض الأمثلة على استخدام حوامل ذاكرة التخزين المؤقت التي توضح كيف أن الصورة النهائية لن تحتوي على التحميل ولا تغطي هناك العديد من حالات استخدام التخزين المؤقت لوقت الإنشاء:

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

بالنسبة إلى npm: ألا يستخدم أحد وحدات التخزين المؤقت لدليل ذاكرة التخزين المؤقت npm (راجع https://docs.npmjs.com/cli-commands/cache.html ، عادةً ~/.npm )؟

ankon يمكن أن يعمل ، شكرًا ، سأجربه. حالة استخدام أخرى لست متأكدًا منها هي Bundler و Ruby.

لذلك أعتقد (لم تختبر بعد) بالنسبة لـ Bundler ، يمكنك على الأقل التخلص من تبعية الشبكة باستخدام حجم بناء بسعر $BUNDLE_PATH ثم أثناء الإنشاء

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

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

إذا كنت تريد حفظ البيانات المخزنة مؤقتًا في الصورة ، فقم بنسخها في الصورة من ذاكرة التخزين المؤقت.

شكرًا ، مع ذلك ، لا يزال حلًا بديلًا لأن

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

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

thisismydesign يبدو أن ما تريده هو أن تكون قادرًا على مشاركة ذاكرة التخزين المؤقت بين الإنشاء والتشغيل؟

buildkit هو حل لينكس فقط ، ماذا نفعل على الويندوز؟

thisismydesign لست متأكدًا من سبب توقعك لظهور (ذاكرة التخزين المؤقت) في الصورة النهائية. لا أتوقع هذا ولا أرغب في الحصول على حوالي 1 جيجابايت في صورتي لمجرد استخدام تحميل ذاكرة التخزين المؤقت.

buildkit هو حل لينكس فقط ، ماذا نفعل على الويندوز؟

يمكنك استخدام buildkit على Windows.

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

قد تجد أنه من الأسهل ضبط إعداد البرنامج الخفي من خلال Docker for Windows UI بدلاً من ضبط متغير البيئة قبل التنفيذ.

nigelgbanks أعلى الرابط الخاص بك:

Only supported for building Linux containers

آسف ، أفترض أنك كنت تبني حاويات Linux على Windows.

thisismydesign يبدو أن ما تريده هو أن تكون قادرًا على مشاركة ذاكرة التخزين المؤقت بين الإنشاء والتشغيل؟

هذا من شأنه أن يحل حالة الاستخدام الخاصة بي حول التخزين المؤقت ، نعم.

يمكن أن يؤدي تسهيل ذلك إلى توفير الملايين من عمليات إعادة تنزيل الحزم في CI
يبني في السنة.

هل تدعم أي من خدمات CI ميزات buildkit التجريبية ؟

في يوم السبت 13 يونيو 2020 ، الساعة 2:08 مساءً كتب Csaba Apagyi [email protected] :

thisismydesign https://github.com/thisismydesign يبدو مثل ماذا
الذي تريده هو أن تكون قادرًا على مشاركة ذاكرة التخزين المؤقت بين الإنشاء والتشغيل؟

هذا من شأنه أن يحل حالة الاستخدام الخاصة بي حول التخزين المؤقت ، نعم.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/14080#issuecomment-643657987 ، أو
إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAAMNS6IEQDCO5F3LNHJK5TRWO6AJANCNFSM4BJB2OOA
.

هل تدعم أي من خدمات CI ميزات buildkit التجريبية ؟

هل يتعين عليهم دعمها صراحة؟ أنا أستخدم gitlab-ci مع buildkit وهو يعمل فقط. بعد كل شيء ، إنها مجرد طريقة مختلفة لاستدعاء "بناء عامل الإرساء".

بالطبع ، ما لم تحضر العدائين الخاصين بك إلى gitlab ، فإن احتمالات الحصول على ذاكرة تخزين مؤقت أثناء الإنشاء منخفضة على أي حال.

يعد النسخ من مرحلة محددة لبناء متعدد المراحل حلاً آخر

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

ولكن بعد ذلك ، لا يزال موقع صورة الحاوية يمثل مشكلة لم يتم حلها في الغالب لجدولة وظيفة CI

سيحتاج المتسابقون إلى أن يكونوا أكثر ثباتًا وأن يشاركوا الصور (الوسيطة) في نظام ملفات مشترك لتقليل الطلبات غير الضرورية إلى حزم repos (التي تعاني نقصًا في التمويل).

لقد جربت للتو buildkit ولكنه حسن سير العمل بشكل هامشي فقط ، والذي سيكون مدعومًا بنسبة 100٪ من خلال الحجم "الحقيقي" أو حوامل الربط للمضيف.

أنا أستخدم docker build لتجميع إصدارات glibc القديمة التي يجب أن تكون بعد ذلك جزءًا من حاويات الإنشاء الجديدة التي توفر هذه glibc s للبناء تحتها والارتباط بها.

الآن يتم حل تنزيل المصدر المتكرر glibc عن طريق ربط ربط (من buildkit ) ، يمكن قراءة الأرشيف فقط ، ولا توجد مشكلة. لكن ليس لدي طريقة للوصول إلى دير البناء للتحليل بعد الإنشاءات الفاشلة ، لأن الحاوية تنفجر عن طريق الخطأ. (إذا قمت بإعادة تشغيله للوصول إليه ، فسيتم إعادة تشغيل الإنشاء ، لذلك لا يساعد ذلك).

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

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

لكن ليس لدي طريقة للوصول إلى مسار البناء للتحليل بعد الإنشاءات الفاشلة

يبدو أنه طلب ميزة لـ buildkit. هذه بالتأكيد قطعة معروفة مفقودة.

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

أيضًا ، لا أعرف لماذا يجب أن أقفز عبر الأطواق مثل بناء حاوية جديدة من حاوية قديمة فقط للتخلص من دير البناء الخاص بي

هل يمكنك شرح المزيد عما تريده / تتوقعه هنا؟

هل يمكنك شرح المزيد عما تريده / تتوقعه هنا؟

في هذه الحالة ، نرغب فقط في قتل عصفورين بحجر واحد:

• طريقة سهلة للوصول إلى النتائج الوسيطة من المضيف (هنا "بناء تحليل dir")
• تأكد من أن مساحة التخزين هذه لا تلوث الصورة المبنية حديثًا

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

هل يمكنك شرح المزيد عما تريده / تتوقعه هنا؟

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

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

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

لا توجد مشكلة في قول أن أداة أخرى تناسب احتياجاتك بشكل أفضل.

إذا كان هناك شيء يناسبك ، فهذا رائع.

إن أوجه القصور في كل من v1 builder في Docker و buildkit builder مفهومة جيدًا في هذا السياق ، ويبحثون في كيفية معالجتها ، ويفضل فقط دون الحاجة إلى اللجوء إلى ربط عمليات التحميل من العميل.
كتب GitHub [email protected] :
تضمين التغريدة
في الواقع تشبه إلى حد بعيد أيضًا (إحدى الوظائف) التي أحتاجها.
منذ أن انتقلت إلى buildah قبل أيام قليلة حصلت على كل الوظائف التي احتاجها وأكثر. كان تصحيح أخطاء حاوية التصميم الخاصة بي مستحيلًا تمامًا بدون إمكانية الدخول بمرونة إلى الحاوية الخارجة والروابط إلى المضيف. الآن أنا عربة سعيدة. (يؤسفني أن أقوم بتعطيل الطرف بـ "أحد المنافسين" ، ويسعدني إزالة هذا التعليق إذا تم ارتكاب جريمة ، ولكنه كان حلاً فعالاً لحالات الاستخدام المقدمة في هذا الموضوع الذي اعتقدت أنه يجب أن أذكره) . "

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بإلغاء الاشتراك.

دون الحاجة إلى اللجوء إلى ربط الحوامل من العميل.

أشرح هنا سبب عدم اللجوء إلى خيار وقت الإنشاء أو التضحية بإمكانية التكاثر أكثر من الاعتماد على موارد الشبكة في وقت الإنشاء.

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

نسخ || REMOTE_FETCH || اقرأ()

• أي من هؤلاء أكثر استنساخًا؟

أنا ذاهب مع buildah لوقت البناء -v (و cgroupsv2) أيضًا.

mcattle لقد كان لدي نفس المطلب. لقد حللت مع وضع العلامات .

أنا ذاهب مع buildah لوقت البناء -v (و cgroupsv2) أيضًا.

أنا أفكر بجدية في التبديل من Ubuntu (الذي لديه عامل إرساء فقط) إلى Fedora (الذي استبدل عامل الإرساء بـ podman / buildah) على خادم الإنشاء لدينا بسبب دعم "-v".

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

ملاحظة. بينما هناك حاجة إلى cgroups v2 للتشغيل بدون جذر ، فإن دعم ذلك يتعلق بوقت تشغيل الحاوية أكثر من عامل الإرساء. إذا كنت تستخدم CRun بدلاً من RunC (مثل Fedora) ، فستحصل على دعم cgroups v2. لدى RunC بعض الدعم الخالي من الجذور والإصدار 2 في Git ، لكنني واجهت بعض المشكلات عند اختباره على Fedora (31) قبل بضعة أشهر.

تحرير: يحتوي Ubuntu على podman / buildah / إلخ في Groovy ، ولكن ليس في آخر 20.04 LTS ، أعتقد أنه تم استيراده من Debian غير مستقر. لم يتم نقله إلى LTS ، على الأقل حتى الآن. بينما كان في فيدورا منذ 2018 على ما أعتقد.

@ eero-t ربما يمكنك وصف حالة الاستخدام الخاصة بك ، وما هو مفقود في الخيارات التي يوفرها BuildKit حاليًا والذي لم يتم تناوله لهؤلاء.