Get best of the week

إصدار Werf 1.1: تحسينات في المجمع اليوم وخطط للمستقبل



werf هي أداة GitOps CLI مفتوحة المصدر الخاصة بنا لإنشاء التطبيقات وتقديمها إلى Kubernetes. كما وعد ، كان إصدار v1.0 بمثابة بداية لإضافة ميزات جديدة إلى werf ومراجعة المناهج المألوفة. يسرنا الآن أن نصدر v1.1 ، وهي خطوة كبيرة في التطوير والمستقبل في التجميع werf. الإصدار متاح حاليًا في القناة 1.1 عصام .

أساس الإصدار هو الهيكل الجديد لتخزين المسرح وتحسين عمل كلا الجامعين (لـ Stapel و Dockerfile). تفتح بنية التخزين الجديدة إمكانية تنفيذ التجميعات الموزعة من مضيفين متعددين وتجميعات متوازية على مضيف واحد.

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

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

دعونا نلقي نظرة فاحصة على الابتكارات الرئيسية في werf v1.1 ، وفي الوقت نفسه نتحدث عن خطط للمستقبل.

ما الذي تغير في werf v1.1؟


شكل جديد لتسمية المرحلة وخوارزمية اختيار مرحلة التخزين المؤقت


قاعدة جديدة لتوليد اسم المرحلة. الآن كل تجميع مرحلة يولد اسم مرحلة فريد يتكون من جزأين: توقيع (كما في v1.0) بالإضافة إلى معرف مؤقت فريد.

على سبيل المثال ، قد يبدو الاسم الكامل لصورة المسرح بالشكل التالي:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

... أو بشكل عام:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

هنا:

  • SIGNATURE - هذا هو توقيع المرحلة ، الذي يمثل معرف محتوى المرحلة ويعتمد على تاريخ التعديلات في Git التي أدت إلى هذا المحتوى ؛
  • TIMESTAMP_MILLISEC - هذا مضمون معرف فريد للصورة التي تم إنشاؤها في وقت تجميع الصورة الجديدة.

تعتمد خوارزمية تحديد المراحل من ذاكرة التخزين المؤقت على التحقق من علاقة تنفيذ Git:

  1. يحسب Werf توقيع مرحلة ما.
  2. في مراحل التخزين ، يمكن أن يكون هناك عدة مراحل لتوقيع معين. يختار Werf جميع المراحل المناسبة للتوقيع.
  3. إذا يرتبط المرحلة الحالية مع بوابة (بوابة المحفوظات، خطوة المستعمل ج جيت-بقع: install، beforeSetup، setup، أو بوابة، أحدث التصحيح)، ثم werf يختار فقط تلك الخطوات التي تتعلق ارتكابها، وهو الجد من التيار ارتكاب (التي تسبب التجمع )
  4. من المراحل المناسبة المتبقية ، تم تحديد مرحلة - الأقدم حسب تاريخ الإنشاء.

يمكن أن يكون لمرحلة فروع Git المختلفة نفس التوقيع. لكن werf سيمنع استخدام ذاكرة التخزين المؤقت المرتبطة بالفروع المختلفة بين هذه الفروع ، حتى إذا كانت التواقيع متطابقة.

→ التوثيق .

خوارزمية جديدة لإنشاء المراحل وحفظها في مرحلة التخزين


إذا لم يجد werf مرحلة مناسبة أثناء اختيار المراحل من ذاكرة التخزين المؤقت ، تبدأ عملية تجميع مرحلة جديدة.

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

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

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

→ التوثيق .

تحسين أداء جامع Dockerfile


في الوقت الحالي ، يتكون خط أنابيب المرحلة لصورة تم تجميعها من Dockerfile من مرحلة واحدة - dockerfile. عند حساب التوقيع ، يتم النظر في المجموع الاختباري للملفات context، والذي سيتم استخدامه أثناء التجميع. قبل هذا التحسين ، اجتاز werf بشكل متكرر جميع الملفات وحصل على مجموع اختباري ، يلخص سياق ووضع كل ملف. بدءًا من v1.1 ، يمكن استخدام werf الاختبارية المحسوبة المخزنة في مستودع Git.

تعتمد الخوارزمية على git ls-tree . تأخذ الخوارزمية في الاعتبار الإدخالات .dockerignoreوتمرر بشكل متكرر من خلال شجرة الملفات فقط إذا لزم الأمر. وهكذا ، تخلصنا من قراءة نظام الملفات ، ولم contextيكن اعتماد الخوارزمية على الحجم كبيرًا.

تقوم الخوارزمية أيضًا بفحص الملفات غير المتتبع ، وإذا لزم الأمر ، تأخذها في الاعتبار في المجموع الاختباري.

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


يستخدم Werf v1.1 خادم rsync عند استيراد الملفات من القطع الأثرية والصور . سابقًا ، تم إجراء الاستيراد في خطوتين باستخدام تركيب الدليل من النظام المضيف.

لم يعد أداء الاستيراد على macOS يقتصر على وحدات تخزين Docker ، ويتم الاستيراد في نفس الوقت مع Linux و Windows.

وضع العلامات على المحتوى


يدعم Werf v1.1 ما يسمى بالوسم من خلال محتوى الصورة - وضع العلامات على المحتوى . تعتمد علامات صور Docker الناتجة على محتوى هذه الصور.

عند تشغيل الأمر werf publish --tags-by-stages-signatureأو werf ci-env --tagging-strategy=stages-signatureالأمر ، سيتم اختبار الصور المنشورة لما يسمى توقيع مرحلة الصورة. يتم تمييز كل صورة بتوقيعها الخاص لمراحل هذه الصورة ، والتي يتم حسابها وفقًا لنفس القواعد مثل التوقيع المنتظم لكل مرحلة على حدة ، ولكنها معرّف عام للصورة.

يعتمد توقيع مراحل الصورة على:

  1. محتويات هذه الصورة ؛
  2. سجل مراجعة Git الذي أدى إلى هذا المحتوى.

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

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

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

مهم: من الآن فصاعدًا ، يعد توقيع المراحل هو إستراتيجية وضع العلامات الموصى بها فقط . سيتم استخدامه بشكل افتراضي في الفريق werf ci-env(ما لم تحدد بوضوح نظامًا مختلفًا لوضع العلامات).

→ التوثيق . كما سيتم تخصيص منشور منفصل لهذه الميزة. محدث (3 أبريل): تم مقال مع تفاصيل نشر .

مستويات التسجيل


لدى المستخدم الفرصة للتحكم في الإخراج ، وتعيين مستوى التسجيل والعمل مع معلومات التصحيح. خيارات أضاف --log-quiet، --log-verbose، --log-debug.

بشكل افتراضي ، يحتوي الإخراج على الحد الأدنى من المعلومات:



عند استخدام الإخراج التفصيلي ( --log-verbose) ، يمكنك تتبع كيفية عمل werf:



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



خطط مستقبلية


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

دعم كامل لمختلف تطبيقات Docker Registry (جديد)



الهدف هو أن المستخدم يجب أن يستخدم التنفيذ التعسفي بدون قيود عند استخدام werf.

حتى الآن ، حددنا مجموعة الحلول التالية التي سنضمن لها الدعم الكامل:

  • افتراضي (مكتبة / تسجيل) * ،
  • AWS ECR ،
  • أزور * ،
  • مركز عامل الميناء
  • GCR * ،
  • حزم جيثب
  • سجل GitLab * ،
  • مرفأ *،
  • رصيف.

تشير العلامة النجمية إلى الحلول المدعومة بالكامل حاليًا من قبل werf. بالنسبة للبقية هناك دعم ، ولكن مع قيود.

يمكن تمييز مشكلتين رئيسيتين:

  • لا تدعم بعض الحلول إزالة العلامات باستخدام Docker Registry API ، والتي لا تسمح للمستخدمين باستخدام التنظيف التلقائي الذي تم تنفيذه في werf. وينطبق هذا على حزم AWS ECR و Docker Hub و GitHub.
  • لا تدعم بعض الحلول ما يسمى بالمستودعات المتداخلة (Docker Hub و GitHub Packages و Quay) أو الدعم ، ولكن يجب على المستخدم إنشاؤها يدويًا باستخدام واجهة المستخدم أو API (AWS ECR).

سنقوم بحل هذه المشاكل وغيرها باستخدام واجهات برمجة التطبيقات الأصلية للحلول. تتضمن هذه المهمة أيضًا تغطية دورة werf الكاملة باختبارات لكل منها.

تجميع الصور الموزعة (↑)



في الوقت الحالي ، لا يمكن استخدام werf v1.0 و v1.1 إلا على مضيف واحد مخصص لتجميع الصور ونشرها ونشر التطبيقات في Kubernetes.

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

في السابق ، عندما كان مشروع werf لا يزال يسمى dapp ، كان لديه مثل هذه الفرصة. ومع ذلك ، واجهنا عددًا من المشكلات التي يجب مراعاتها عند تنفيذ هذه الوظيفة في werf.

ملحوظة. هذه الميزة لا تعني عمل المجمع داخل قرون Kubernetes ، كما للقيام بذلك ، تخلص من الاعتماد على خادم Docker المحلي (في Kubernetes pod لا يوجد وصول إلى خادم Docker المحلي ، لأن العملية نفسها تعمل في الحاوية ، ولا يدعم werf ولن يدعم العمل مع خادم Docker على الشبكة). سيتم تنفيذ الدعم للعمل في Kubernetes بشكل منفصل.

دعم إجراءات GitHub الرسمية (جديد)



وتشمل الوثائق werf ( إشارة و دليل أقسام )، فضلا عن العمل جيثب الرسمي للعمل مع werf.

بالإضافة إلى ذلك ، سيسمح werf بالعمل على العدائين المؤقتين.

ستقوم آليات تفاعل المستخدم مع نظام CI على وضع التسميات على طلبات السحب لبدء إجراءات معينة لإنشاء / طرح التطبيق.

تطوير التطبيقات المحلية ونشرها باستخدام werf (↓)


  • الإصدار: v1.1
  • التواريخ: يناير-فبراير أبريل
  • القضية

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

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

خوارزمية تنظيف جديدة (جديد)


  • الإصدار: v1.1
  • التواريخ: أبريل
  • القضية

في الإصدار الحالي من werf v1.1 ، cleanupلا يوفر الإجراء تنظيف الصور لنظام وضع العلامات المستند إلى المحتوى - ستتراكم هذه الصور.

أيضًا ، في الإصدار الحالي من werf (v1.0 و v1.1) ، يتم استخدام سياسات تنظيف مختلفة للصور المنشورة بواسطة مخططات وضع العلامات: Git branch أو Git tag أو Git ارتكاب.

تم اختراع خوارزمية موحدة جديدة لتنظيف الصور لجميع مخططات وضع العلامات استنادًا إلى سجل عمليات التنفيذ في Git:

  • لا تخزن أكثر من صور N1 المرتبطة بعمليات N2 الأخيرة لكل من HEAD (الفروع والعلامات).
  • لا تخزن أكثر من مراحل الصور N1 المرتبطة بعمليات N2 الأخيرة لكل من HEAD (الفروع والعلامات).
  • , - Kubernetes ( kube- namespace'; ).
  • , , Helm-.
  • , HEAD git (, HEAD ) Kubernetes Helm.

(↓)


  • : v1.1
  • : - *

يجمع الإصدار الحالي من werf الصور والتحف الموصوفة في werf.yamlالتسلسل. من الضروري موازاة عملية تجميع المراحل المستقلة للصور والتحف ، بالإضافة إلى توفير استنتاج مناسب ومفيد.

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

التبديل إلى Helm 3 (↓)


  • الإصدار: v1.2
  • التواريخ: فبراير - مارس مايو *

يتضمن الانتقال إلى قاعدة التعليمات البرمجية Helm 3 الجديدة وطريقة مثبتة وملائمة لترحيل التثبيتات الموجودة.

* ملاحظة: لن يؤدي الانتقال إلى Helm 3 إلى إضافة ميزات مهمة إلى werf ، نظرًا لأن جميع الميزات الرئيسية لـ Helm 3 (3-way-merge ونقص الحارث) تم تنفيذها بالفعل في werf. علاوة على ذلك ، يحتوي WERF على ميزات إضافية إلى جانب تلك المشار إليها. ومع ذلك ، يبقى هذا التحول في خططنا وسيتم تنفيذه.

وصف تكوين Jsonnet لـ Kubernetes (↓)


  • الإصدار: v1.2
  • التواريخ: يناير-فبراير أبريل-مايو

يدعم Werf وصف التكوين لـ Kubernetes بتنسيق Jsonnet. في الوقت نفسه ، سيظل werf متوافقًا مع Helm وسيكون من الممكن تحديد تنسيق الوصف.

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

كما يتم النظر في خيارات أخرى لتنفيذ أنظمة وصف تكوين Kubernetes (مثل Kustomize).

العمل داخل Kubernetes (↓)


  • الإصدار: v1.2
  • التواريخ: أبريل-مايو مايو-يونيو

الغرض: ضمان تجميع الصور وتسليم التطبيقات باستخدام العدائين في Kubernetes. أولئك. تجميع الصور الجديدة ، يمكن نشرها وتنظيفها ونشرها مباشرة من قرون Kubernetes.

لتحقيق هذه الميزة ، تحتاج أولاً إلى القدرة على إنشاء صور موزعة (انظر الفقرة أعلاه) .

كما يتطلب دعمًا لوضع البناء للتشغيل بدون خادم Docker (أي بناء يشبه Kaniko أو بناء في مساحة المستخدمين).

ستدعم Werf إصدارات Kubernetes ليس فقط مع ملف Dockerfile ، ولكن أيضًا مع منشئ Stapel مع عمليات إعادة البناء الإضافية و Ansible.

خطوة نحو تطوير المصدر المفتوح


نحن نحب مجتمعنا ( GitHub و Telegram ) ونريد المزيد والمزيد من الأشخاص للمساعدة في تحسين الأداء ، وفهم الاتجاه الذي نسير فيه ، والمشاركة في التطوير.

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


تم إنجاز الكثير من العمل بشأن المشكلات:

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

كيفية تمكين الإصدار v1.1


النسخة متاحة حاليا في قناة 1.1 عصام ( النشرات في مستقرة و الصخور الصلبة قنوات ستظهر لأنها الاستقرار، ولكن عصام نفسه هو بالفعل ما يكفي مستقرة للاستخدام، أثناء مرورها ألفا و بيتا قنوات ). يتم تنشيطه من خلال Multiwerf بالطريقة التالية:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

استنتاج


تفتح بنية مخزن المسرح الجديد والأداء المحسن للمجمعين لمجمعي Stapel و Dockerfile إمكانية تنفيذ التجميعات الموزعة والمتوازية في werf. ستظهر هذه الميزات قريبًا في الإصدار v1.1 نفسه وستصبح متاحة تلقائيًا من خلال آلية التحديث التلقائي (للمستخدمين المتعددين ).

في هذا الإصدار ، تمت إضافة إستراتيجية وضع العلامات المستندة إلى المحتوى ، والتي أصبحت الإستراتيجية الافتراضية. وأعيد تصميم وسجل أيضا الأوامر الأساسية: werf build، werf publish، werf deploy، werf dismiss، werf cleanup.

ستكون الخطوة المهمة التالية هي إضافة التجميعات الموزعة. أصبحت التجميعات الموزعة منذ v1.0 أولوية أعلى من التجميعات المتوازية ، لأنها تضيف المزيد من قيمة werf: التحجيم العمودي للجامعين ودعم المجمعات الزائلة في أنظمة CI / CD المختلفة ، بالإضافة إلى القدرة على تقديم الدعم الرسمي لإجراءات GitHub. لذلك ، تم تغيير توقيت تنفيذ التجمعات الموازية. ومع ذلك ، نحن نعمل على تحقيق كلا الاحتمالين بسرعة.

تابع الأخبار! ولا تنس أن تسقط من خلال GitHub لإنشاء مشكلة أو العثور على مشكلة موجودة ووضع علامة زائد أو إنشاء علاقات عامة أو مجرد مشاهدة تطور المشروع.

ملاحظة


اقرأ أيضا في مدونتنا:

More articles:


All Articles