كنت أحاول إضافة دعم لاستدعاء docker build
كـ docker buildx build
لكنني أخشى أن الأمر قد يكون أكثر تعقيدًا من ذلك
أعتزم إضافة هذا النوع من المعلمات:
ثم يمكننا تخزين Docker لإنشاء طبقات بطريقة أكثر فاعلية. على أي حال ، الخيارات --cache-to
و --cache-from
متوفرة فقط في Docker Buildx ، مثل الكثير من الخيارات الأخرى التي قد أرغب في استخدامها
في الماضي ، نجحت في تمكين وحدات تخزين ذاكرة التخزين المؤقت للمجمع داخل Dockerfile ، بحيث لا تؤدي التغييرات التي تم إجراؤها على Gemfile و Gemfile.lock إلى إعادة حساب كاملة لتبعيات وقت إنشاء الصورة ، ولكن بدلاً من ذلك ستنشئ من ذاكرة التخزين المؤقت بحيث تم إعادة حساب التبعيات الجديدة فقط.
بينما من الواضح أن هذا يعد تحسينًا متخصصًا ، إلا أن هناك حالات استخدام أخرى أكثر شيوعًا لا يمكن التعامل معها بشكل جيد إلا باستخدام buildx. أصبحت مجموعة أدوات buildkit قياسية جدًا الآن IMHO. سأحب ذلك إذا كان من الممكن استدعاء Kuby build بطريقة تستخدم buildx!
قد أحاول تنفيذ هذا مرة أخرى لاحقًا ، فقد يكون من الأسهل الآن أن يتم تحرير 0.15.0 بقوة. في غضون ذلك ، هناك مثال عملي لإجراءات GitHub التي هي ويب ولكنها تبدو حاليًا جيدة جدًا على: https://github.com/kingdonb/kuby_test
مع تكوين التخزين المؤقت بشكل صحيح في هذا المكان الأخير ، واثنين من التغييرات الأخرى ، أعتقد أن هذا جاهز تقريبًا لوضع علامة عليه وتقديم مثال للخروج منه للمساهمة في kuby-core ، أو للعيش في مكان ما في مشروع getkuby 👍
يا!
من الممكن استخدام buildx الآن ، إذا قمت بتعيينه كمنشئ افتراضي .
إليك مثال Github Action الذي يستخدم buildx وقدرات التخزين المؤقت الخاصة به: https://github.com/anycable/anycable_rails_demo/pull/25/files#diff -28802fbf11c83a2eee09623fb192785e7ca92a3f40602a517c011b947a1822d3R
راجع أيضًا https://evilmartians.com/chronicles/kubing-rails-stressless-kubernetes-deployments-with-kuby#deploying -continuously-with-kuby-and-github-Actions
كنت أبحث فقط عن شيء مثل علامة --only
، حيث كنت أواجه مشكلة في إعداد التخزين المؤقت! خطرت لي فكرة أنني بحاجة إلى فصل النطاقات لكل نوع بناء ، كما أرى أنك قمت بذلك هنا.
شكرًا جزيلاً على المراجع المفيدة 👍 أنا أتابعها الآن لمعرفة ما إذا كانت تصلني عبر الخط!
بالتأكيد كنت أفتقد أيضًا ميزة الإنشاء الافتراضية لـ setup-buildx-action ( install: true
)
يبدو أنه يعمل الآن! لقد رأيت للتو إنشاء صورة تطبيق مكتمل في أقل من 10 ثوانٍ. هناك مشاكل أخرى أواجهها الآن ، ربما يكون الانحدار الذي وجدته حيث لا يتم تصدير RAILS_MASTER_KEY بشكل صحيح ، لكنني سأذهب وأقرأ المصدر لمعرفة ذلك الآن.
إذا استخدمت install: true
like في هذا الالتزام ، فإن طريقة build
من lib/kuby/docker/cli.rb
تستدعي buildx
، ويمكنني تمرير إنشاءات buildx مثل --cache-to
بعد --
$ لإحضارهم في مصفوفة *docker-args
لذلك يمكن إغلاق هذا ، باستثناء أنه قد يكون من الجيد لـ kuby-core توثيق كيفية استخدامه مع buildx ، إنها ليست مشكلة kuby
مع المثال في:
https://github.com/kingdonb/kuby_test/commit/d74bf51e04253359b0d54aae7ddd6723ea6fd41d#diff -e2ad06bfd6b3aefc2d5f4fe8f60e0015b16947abc16764adef02e433
يمكنني استخدام buildx ، لذلك يمكن إغلاق هذه المشكلة.
هذا رائع حقًا ، شكرًا لك على اكتشاف أشياء buildx! كان لدي انطباع بأنه يمكنك تعيين متغير بيئة ، وسيكون هذا مجرد عمل ™ ، فهل هذا ما يفعله هذا الإجراء docker/setup-buildx-action@v1
؟ يبدو أن buildx يأتي مع Docker Desktop وإصدارات أحدث مثبتة عبر حزم deb / rpm ، لذلك أتساءل عما إذا كان بإمكان Kuby ببساطة استخدام التطبيق الافتراضي. إذا كان قابلاً للتكوين عبر env var ، فربما لا يكون استدعاء docker buildx build
ضروريًا؟ ربما يستطيع Kuby اكتشافه والعودة إلى الوضع الطبيعي docker build
؟
نعم ، هذا ممكن (وهذا ما يفعله install: true
في GitHub Action): https://docs.docker.com/buildx/working-with-buildx/#set -buildx-as-the-default- باني
حسنًا ، إذا كان docker build
مجرد اسم مستعار لـ docker buildx
، فلا أرى حاجة لـ Kuby للقيام بأي شيء خاص. يجب أن يكون الأمر متروكًا للمستخدم لإعداد المنشئ الذي يريده.
التعليق الأكثر فائدة
حسنًا ، إذا كان
docker build
مجرد اسم مستعار لـdocker buildx
، فلا أرى حاجة لـ Kuby للقيام بأي شيء خاص. يجب أن يكون الأمر متروكًا للمستخدم لإعداد المنشئ الذي يريده.