هي الأداة المساعدة GitOps CLI مفتوحة المصدر الخاصة بنا لبناء التطبيقات وتسليمها إلى Kubernetes. كما وعدت، يمثل بداية إضافة ميزات جديدة إلى werf ومراجعة الأساليب التقليدية. والآن يسعدنا أن نقدم الإصدار v1.1، والذي يمثل خطوة كبيرة في التطوير وأساسًا للمستقبل جامع werf. الإصدار متوفر حاليا في .
أساس الإصدار هو بنية تخزين المرحلة الجديدة وتحسين عمل كلا المجمعين (لـ Stapel وDockerfile). تفتح بنية التخزين الجديدة إمكانية تنفيذ التجميعات الموزعة من مضيفين متعددين والتجميعات المتوازية على نفس المضيف.
يتضمن تحسين العمل التخلص من الحسابات غير الضرورية في مرحلة حساب توقيعات المرحلة وتغيير آليات حساب المجاميع الاختبارية للملف إلى آليات أكثر كفاءة. يؤدي هذا التحسين إلى تقليل متوسط وقت إنشاء المشروع باستخدام werf. ويبني الخمول، عندما تكون كافة المراحل موجودة في ذاكرة التخزين المؤقت مراحل التخزين، أصبحت الآن سريعة حقًا. في معظم الحالات، ستستغرق إعادة تشغيل الإصدار أقل من ثانية واحدة! وينطبق هذا أيضًا على إجراءات التحقق من مراحل عمل الفرق. werf deploy и werf run.
في هذا الإصدار أيضًا، ظهرت استراتيجية لوضع علامات على الصور حسب المحتوى - وضع العلامات على أساس المحتوى، والذي تم تمكينه الآن افتراضيًا وهو الخيار الوحيد الموصى به.
دعونا نلقي نظرة فاحصة على الابتكارات الرئيسية في werf v1.1، وفي الوقت نفسه نخبرك عن خطط المستقبل.
ما الذي تغير في werf v1.1؟
تنسيق جديد لتسمية المرحلة وخوارزمية لاختيار المراحل من ذاكرة التخزين المؤقت
قاعدة إنشاء اسم المرحلة الجديدة. الآن، تُنشئ كل مرحلة إنشاء اسم مرحلة فريدًا، والذي يتكون من جزأين: التوقيع (كما كان في الإصدار 2) بالإضافة إلى معرف مؤقت فريد.
على سبيل المثال، قد يبدو اسم صورة المرحلة الكاملة كما يلي:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
.. أو بشكل عام:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
هنا:
-
SIGNATUREهو توقيع المرحلة، الذي يمثل معرف محتوى المرحلة ويعتمد على تاريخ التعديلات في Git التي أدت إلى هذا المحتوى؛ -
TIMESTAMP_MILLISECهو معرف صورة فريد مضمون يتم إنشاؤه في وقت إنشاء صورة جديدة.
تعتمد خوارزمية اختيار المراحل من ذاكرة التخزين المؤقت على التحقق من العلاقة بين التزامات Git:
- يحسب Werf توقيع مرحلة معينة.
- В مراحل التخزين قد تكون هناك عدة مراحل لتوقيع معين. يختار Werf جميع المراحل التي تطابق التوقيع.
- إذا كانت المرحلة الحالية مرتبطة بـ Git (git-archive، المرحلة المخصصة مع تصحيحات Git:
install,beforeSetup,setup; أو git-latest-patch)، ثم يحدد werf فقط تلك المراحل المرتبطة بالالتزام الذي يمثل سلف الالتزام الحالي (الذي يتم استدعاء البناء من أجله). - من بين المراحل المناسبة المتبقية، يتم اختيار مرحلة واحدة - الأقدم حسب تاريخ الإنشاء.
يمكن أن يكون للمرحلة الخاصة بفروع Git المختلفة نفس التوقيع. لكن werf سيمنع استخدام ذاكرة التخزين المؤقت المرتبطة بفروع مختلفة بين هذه الفروع، حتى لو كانت التوقيعات متطابقة.
.
خوارزمية جديدة لإنشاء وحفظ المراحل في مخزن المرحلة
إذا لم يجد werf مرحلة مناسبة عند اختيار المراحل من ذاكرة التخزين المؤقت، فستبدأ عملية تجميع مرحلة جديدة.
لاحظ أن العمليات المتعددة (على مضيف واحد أو أكثر) يمكن أن تبدأ في بناء نفس المرحلة في نفس الوقت تقريبًا. يستخدم Werf خوارزمية حظر متفائلة مراحل التخزين في لحظة حفظ الصورة المجمعة حديثًا في مراحل التخزين. بهذه الطريقة، عندما يصبح بناء المرحلة الجديدة جاهزًا، يتم إنشاء كتل werf مراحل التخزين ويحفظ الصورة المجمعة حديثًا هناك فقط إذا لم تعد الصورة المناسبة موجودة هناك (عن طريق التوقيع والمعلمات الأخرى - راجع الخوارزمية الجديدة لاختيار المراحل من ذاكرة التخزين المؤقت).
نضمن أن تحتوي الصورة المجمعة حديثًا على معرف فريد TIMESTAMP_MILLISEC (راجع تنسيق تسمية المرحلة الجديدة). في حالة مراحل التخزين سيتم العثور على صورة مناسبة، وسوف يتجاهل werf الصورة المجمعة حديثًا وسيستخدم الصورة من ذاكرة التخزين المؤقت.
بمعنى آخر: أول عملية تنتهي من بناء الصورة (الأسرع) ستحصل على الحق في تخزينها في مرحلة تخزين (ثم هذه الصورة الفردية هي التي سيتم استخدامها لجميع البنيات). لن تمنع عملية البناء البطيئة أبدًا عملية أسرع من حفظ نتائج البناء للمرحلة الحالية والانتقال إلى البناء التالي.
.
تحسين أداء منشئ Dockerfile
في الوقت الحالي، يتكون مسار المراحل للصورة المبنية من ملف Dockerfile من مرحلة واحدة - dockerfile. عند حساب التوقيع، يتم حساب المجموع الاختباري للملفات contextوالتي سيتم استخدامها أثناء التجميع. قبل هذا التحسين، كان werf يتصفح جميع الملفات بشكل متكرر ويحصل على المجموع الاختباري من خلال جمع سياق كل ملف ووضعه. بدءًا من الإصدار 1.1، يمكن لـ werf استخدام المجاميع الاختبارية المحسوبة المخزنة في مستودع Git.
تعتمد الخوارزمية على . تأخذ الخوارزمية في الاعتبار السجلات الموجودة في .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 الصور المنشورة لما يسمى توقيع المرحلة صورة. يتم وضع علامة على كل صورة بتوقيعها الخاص لمراحل هذه الصورة، والذي يتم حسابه وفقًا لنفس قواعد التوقيع العادي لكل مرحلة على حدة، ولكنه معرف عام للصورة.
توقيع مراحل الصورة يعتمد على:
- محتويات هذه الصورة؛
- تاريخ تغييرات 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 سوف تصبح متاحة في هذا الإصدار، والعديد منهم في المستقبل القريب. ستأتي التحديثات عبر التحديثات التلقائية . لا تؤثر هذه الميزات على الجزء المستقر من وظائف الإصدار 1.1، ولن يتطلب مظهرها تدخل المستخدم اليدوي في التكوينات الحالية.
الدعم الكامل لتطبيقات Docker Registry المختلفة (جديد)
- الإصدار: v1.1
- التواريخ: مارس
الهدف هو أن يستخدم المستخدم تطبيقًا مخصصًا دون قيود عند استخدام werf.
لقد حددنا حاليًا مجموعة الحلول التالية التي نعتزم ضمان الدعم الكامل لها:
- الافتراضي (المكتبة/التسجيل)*،
- أوس إيكر
- أزور*،
- مركز عامل الميناء
- جي سي آر*،
- حزم جيثب
- سجل جيتلاب *،
- مرفأ*،
- رصيف.
يتم تمييز الحلول المدعومة بالكامل حاليًا بواسطة werf بعلامة النجمة. وبالنسبة للآخرين هناك دعم، ولكن مع قيود.
ويمكن تحديد مشكلتين رئيسيتين:
- لا تدعم بعض الحلول إزالة العلامات باستخدام Docker Registry API، مما يمنع المستخدمين من استخدام التنظيف التلقائي لـ werf. ينطبق هذا على حزم AWS ECR وDocker Hub وGitHub.
- لا تدعم بعض الحلول ما يسمى بالمستودعات المتداخلة (Docker Hub وGitHub Packages وQuay) أو تفعل ذلك، ولكن يجب على المستخدم إنشاؤها يدويًا باستخدام واجهة المستخدم أو واجهة برمجة التطبيقات (AWS ECR).
سنقوم بحل هذه المشاكل وغيرها باستخدام واجهات برمجة التطبيقات الأصلية للحلول. تتضمن هذه المهمة أيضًا تغطية الدورة الكاملة لتشغيل werf مع إجراء اختبارات لكل منها.
بناء الصورة الموزعة (↑)
- الإصدار: v1.2 v1.1 (تمت زيادة أولوية تنفيذ هذه الميزة)
- التواريخ: مارس-أبريل مارس
في الوقت الحالي، يمكن استخدام werf v1.0 وv1.1 فقط على مضيف واحد مخصص لعمليات إنشاء الصور ونشرها ونشر التطبيق على Kubernetes.
لفتح إمكانيات العمل الموزع لـ werf، عندما يتم إطلاق إنشاء ونشر التطبيقات في Kubernetes على العديد من المضيفين التعسفيين ولا يحفظ هؤلاء المضيفون حالتهم بين البنيات (العدائين المؤقتين)، يلزم werf لتنفيذ القدرة على الاستخدام Docker Registry كمتجر مسرحي.
في السابق، عندما كان مشروع Werf لا يزال يسمى dapp، كان لديه مثل هذه الفرصة. ومع ذلك، واجهنا عددًا من المشكلات التي يجب أخذها في الاعتبار عند تنفيذ هذه الوظيفة في werf.
لاحظ. لا تتطلب هذه الميزة من المجمع العمل داخل كبسولات Kubernetes، لأنه للقيام بذلك، تحتاج إلى التخلص من الاعتماد على خادم Docker المحلي (في جراب Kubernetes، لا يوجد إمكانية الوصول إلى خادم Docker المحلي، لأن العملية نفسها تعمل في حاوية، ولا يدعم werf ولن يدعم العمل مع خادم Docker عبر الشبكة). سيتم تنفيذ دعم تشغيل Kubernetes بشكل منفصل.
الدعم الرسمي لإجراءات GitHub (جديد)
- الإصدار: v1.1
- التواريخ: مارس
يتضمن وثائق werf (الأقسام مرجع и توجيه)، بالإضافة إلى GitHub Action الرسمي للعمل مع werf.
بالإضافة إلى ذلك، سيسمح لـ werf بالعمل على العدائين سريعي الزوال.
ستعتمد آليات تفاعل المستخدم مع نظام CI على وضع تسميات على طلبات السحب لبدء إجراءات معينة لإنشاء/طرح التطبيق.
التطوير المحلي ونشر التطبيقات باستخدام werf (↓)
- الإصدار: v1.1
- التواريخ: يناير-فبراير-أبريل
الهدف الرئيسي هو تحقيق تكوين موحد واحد لنشر التطبيقات محليًا وفي الإنتاج، بدون إجراءات معقدة، خارج الصندوق.
مطلوب أيضًا أن يكون لدى werf وضع تشغيل يكون فيه مناسبًا لتحرير رمز التطبيق وتلقي التعليقات على الفور من التطبيق قيد التشغيل لتصحيح الأخطاء.
خوارزمية تنظيف جديدة (جديد)
- الإصدار: v1.1
- التواريخ: أبريل
في الإصدار الحالي من werf v1.1 في الإجراء cleanup لا يوجد شرط لتنظيف الصور لنظام وضع العلامات على أساس المحتوى - ستتراكم هذه الصور.
أيضًا، يستخدم الإصدار الحالي من werf (v1.0 وv1.1) سياسات تنظيف مختلفة للصور المنشورة ضمن أنظمة وضع العلامات: فرع Git، أو علامة Git، أو التزام Git.
تم اختراع خوارزمية جديدة لتنظيف الصور استنادًا إلى تاريخ الالتزامات في Git، موحدة لجميع أنظمة وضع العلامات:
- لا تحتفظ بأكثر من صور N1 المرتبطة بأحدث عمليات الالتزام N2 لكل git HEAD (الفروع والعلامات).
- قم بتخزين ما لا يزيد عن صور المرحلة N1 المرتبطة بأحدث عمليات الالتزام N2 لكل git HEAD (الفروع والعلامات).
- قم بتخزين جميع الصور المستخدمة في أي من موارد مجموعة Kubernetes (يتم فحص جميع سياقات kube الخاصة بملف التكوين ومساحات الأسماء؛ ويمكنك تقييد هذا السلوك باستخدام خيارات خاصة).
- قم بتخزين جميع الصور المستخدمة في بيانات تكوين الموارد المحفوظة في إصدارات Helm.
- يمكن حذف الصورة إذا لم تكن مرتبطة بأي رأس من git (على سبيل المثال، لأنه تم حذف الرأس المقابل نفسه) ولا يتم استخدامها في أي بيانات في مجموعة Kubernetes وفي إصدارات Helm.
بناء الصورة الموازية (↓)
- الإصدار: v1.1
- التواريخ: يناير-فبراير-أبريل*
يجمع الإصدار الحالي من werf الصور والتحف الموضحة في werf.yaml، بالتتابع. من الضروري موازنة عملية تجميع المراحل المستقلة من الصور والتحف، بالإضافة إلى توفير مخرجات مريحة وغنية بالمعلومات.
* ملاحظة: تم تغيير الموعد النهائي بسبب زيادة الأولوية لتنفيذ التجميع الموزع، مما سيضيف المزيد من إمكانيات التوسع الأفقي، بالإضافة إلى استخدام werf مع GitHub Actions. التجميع المتوازي هو خطوة التحسين التالية، مما يوفر قابلية التوسع الرأسي عند تجميع مشروع واحد.
الانتقال إلى الدفة 3 (↓)
- الإصدار: v1.2
- التواريخ: فبراير-مارس-مايو*
يتضمن الترحيل إلى قاعدة التعليمات البرمجية الجديدة وطريقة مجربة ومريحة لترحيل التركيبات الموجودة.
* ملاحظة: التبديل إلى Helm 3 لن يضيف ميزات مهمة إلى werf، لأن جميع الميزات الرئيسية لـ Helm 3 (دمج ثلاثي الاتجاهات وعدم وجود محراث) تم تنفيذها بالفعل في 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.
خطوة نحو التنمية المفتوحة
نحن نحب مجتمعنا (, ) ونريد المزيد والمزيد من الأشخاص للمساعدة في تحسين العمل، وفهم الاتجاه الذي نتحرك فيه، والمشاركة في التطوير.
في الآونة الأخيرة تقرر التبديل إلى من أجل الكشف عن عملية عمل فريقنا. الآن يمكنك الاطلاع على الخطط الفورية وكذلك العمل الحالي في المجالات التالية:
- ;
- ;
- ;
- .
لقد تم إنجاز الكثير من العمل بشأن القضايا:
- تمت إزالة تلك التي لا علاقة لها بالموضوع.
- يتم تجميع العناصر الموجودة في تنسيق واحد، مع عدد كافٍ من التفاصيل والتفاصيل.
- تمت إضافة قضايا جديدة مع الأفكار والاقتراحات.
كيفية تفعيل الإصدار v1.1
الإصدار متوفر حاليا في (في القنوات مستقر и صخرة صلبة ومع ذلك، ستظهر الإصدارات مع حدوث الاستقرار ea في حد ذاته مستقر بالفعل بدرجة كافية للاستخدام، لأنه ذهبت من خلال القنوات ألفا и بيتا). مفعل بالطريقة الآتية:
source $(multiwerf use 1.1 ea)
werf COMMAND ...اختتام
تفتح بنية تخزين المرحلة الجديدة وتحسينات البناء لمنشئي Stapel وDockerfile إمكانية تنفيذ بنيات موزعة ومتوازية في werf. ستظهر هذه الميزات قريبًا في نفس الإصدار v1.1 وستصبح متاحة تلقائيًا من خلال آلية التحديث التلقائي (للمستخدمين ).
في هذا الإصدار، تمت إضافة استراتيجية وضع العلامات بناءً على محتوى الصورة - وضع العلامات على أساس المحتوى، والتي أصبحت الإستراتيجية الافتراضية. تمت أيضًا إعادة صياغة سجل الأوامر الرئيسي: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
الخطوة المهمة التالية هي إضافة التجميعات الموزعة. أصبحت الإصدارات الموزعة ذات أولوية أعلى من الإصدارات المتوازية منذ الإصدار 1.0 لأنها تضيف قيمة أكبر إلى werf: التوسع الرأسي للمنشئين ودعم المنشئين المؤقتين في أنظمة CI/CD المختلفة، بالإضافة إلى القدرة على تقديم دعم رسمي لإجراءات GitHub . ولذلك، تم تغيير المواعيد النهائية لتنفيذ الاجتماعات الموازية. ومع ذلك، فإننا نعمل على تنفيذ كلا الاحتمالين في أقرب وقت ممكن.
متابعة الأخبار! ولا تنسوا زيارتنا في لإنشاء مشكلة، أو العثور على مشكلة موجودة وإضافة علامة زائد، أو إنشاء علاقة عامة، أو ببساطة مشاهدة تطور المشروع.
PS
اقرأ أيضًا على مدونتنا:
- «»
- «"؛
- سلسلة من الملاحظات حول الابتكارات في werf:
- «"؛
- «"؛
- «"؛
- «".
المصدر: www.habr.com