werf هي أداة GitOps CLI
مفتوحة المصدر لبناء وتسليم التطبيقات إلى Kubernetes. يدعم werf تجميع صور التطبيقات باستخدام Dockerfile أو أداة التجميع المدمجة الخاصة به (بناءً على بناء جملة YAML ، مع دعم Ansible وإعادة بناء تزايدي استنادًا إلى Git). يتم استخدام تنسيق التكوين المتوافق مع Helm لتسليم التطبيق. يتم تخزين رمز التطبيق وتكوين الصور التي تم جمعها وتكوين التطبيق للتطبيق في مستودع Git واحد.
الإصدار الثابت الذي طال انتظاره
1.0 هو الإصدار الأساسي للأداة المساعدة المكتملة بواسطة الوظائف
(رقم الإصدار الدقيق للإصدار المستقر الأول هو 1.0.6) . في الإصدار الأساسي ، يدعم werf الدورة الكاملة لتسليم التطبيق وصيانته. يتضمن ذلك تجميع صور التطبيقات ونشرها على Kubernetes وتنظيف الصور غير المستخدمة.
من المهم أنه في الإصدار 1.0 ، يجب إجراء جميع العمليات في مشروع واحد (
deploy ،
cleanup ،
cleanup ) من مضيف واحد. هذا يعني أنه يجب استخدام عامل ثابت في نظام CI. في الوقت نفسه ، لا توجد قيود على توازي المهام: werf يحل هذه المشكلة تمامًا. يمكنك أيضًا توزيع مشاريع مختلفة بين مختلف العمال.
في هذه المقالة المخصصة للإصدار ، سنلقي نظرة فاحصة على ما يقدمه هذا الإصدار ولا يقدمه ، وكذلك خططنا للإصدارات المستقبلية. ولكن سنبدأ بفهم فهم مصطلح "GitOps" ودور werf في عمليات التكامل المستمر وتسليم التطبيق (CI / CD).
لماذا werf هو GitOps
إذن ماذا نعني بـ GitOps وما هي المناطق التي يغطيها werf؟
لقد صاغت شركة Weaveworks مصطلح "GitOps" منذ حوالي 2.5 عام ، وقد
ترجمنا مؤخرًا مقالة من مؤلفيها تكشف عن جوهر هذه الظاهرة الجديدة للمدونة. في فهمنا ، الفكرة الرئيسية والمعنى الرئيسي لـ GitOps هو أن
Git هي "مصدر وحيد للحقيقة" . بوابة مخازن:
- رمز التطبيق
- كل التبعيات
- معلومات حول كيفية جمع الحاويات ؛
- معلومات حول كيفية النشر إلى Kubernetes ؛
- وغيرها
ثم هناك "شيء ما" يجعل
الواقع يتغير وفقًا لتغيرات Git . يمكن تنفيذ هذا النهج ليس فقط عن طريق تثبيت بعض المشغلين في Kubernetes الذي يراقب Git ، ولكن أيضًا باستخدام أداة مساعدة لوحدة التحكم يمكن استدعاءها من أي نظام CI. علاوة على ذلك ، من وجهة نظرنا ، لا يفرض النهج مع CLI الأداة قيودًا غير ضرورية: يمكننا أن نفعل CI مع أي أداة ومع أي عدد من الفروق الدقيقة ، مع استدعاء أداة CLI التي تزامن "الواقع" (أي Kubernetes) مع حالة Git .
يوفر werf واجهة CLI عالية المستوى تحتوي على أوامر أساسية لبناء ونشر الصور ، وتقديم التطبيقات وتنظيف الصور:
werf build-and-publish werf deploy werf build-and-publish ،
werf deploy ،
werf dismiss ،
werf cleanup . من المفترض أن هذه الأوامر الأساسية مضمنة في نظام CI معين وتوفر المزامنة اللازمة مع الواقع. بالإضافة إلى ذلك ، يوفر werf أيضًا واجهة CLI منخفضة المستوى لإدارة الأنظمة الفرعية المختلفة - راجع
أوامر الإدارة منخفضة المستوى في الوثائق.
لا يهم ما إذا كان CI / CD المدمج سيعمل وفقًا لنموذج
الدفع أو السحب
(اقرأ المزيد عنها هنا ) ، لأنه
يمكن تضمين werf في أي طراز . في الوقت نفسه ، يغلق werf مشاكل مثل العمل مع أدوات مساعدة منخفضة المستوى منفصلة مثل
git و docker و kubernetes api-server ، كونه "الجزء المفقود" لتكوين تطبيق CI / CD موحد.
ما هو werf 1.0 مستقرة
1. تجميع ونشر وتنظيف الصور
إذا كان التطبيق الخاص بك يتطلب إنشاء صور Docker ، فيمكنك باستخدام werf 1.0:
- وصف قواعد تجميع الصور (يمكن أن يكون لديك عدة) في تهيئة
werf.yaml واحدة ؛ - جمع الصور ونشرها على سجل دوكر
- تنظيف دوكر التسجيل بشكل دوري لسياسات مخصصة.
يدعم werf
طريقتين لوصف التجميع : ربط
werf.yaml Dockerfiles الموجودة وتعليمات
جامع Stapel . للبناء باستخدام Stapel مزاياه: إعادة بناء تزايدي أسرع عند تغيير رمز التطبيق في Git ، باستخدام بناء جملة Ansible للتجميع ، وغيرها. يمكنك
معرفة المزيد عن هذا المجمع وبناء الجملة
في الوثائق ، ويرد مثال على استخدامه في
الدليل .
تتوفر مخططات مختلفة لوضع علامات / إصدار الصور التي تم جمعها مع الإشارة إلى Git commits والفروع والعلامات.
يعد تجميع الصور مرحلة اختيارية لنشر التطبيق ويمكن تخطيه في غياب الصور المجمعة الخاصة بك.
2. تخزين المرحلة على مضيف واحد فقط
يقدم werf مفهوم مراحل التخزين. تستخدم أوامر werf الرئيسية تخزين المرحلة كما يلي:
- حفظ نتائج التجميع - صور عامل الميناء في متجر المسرح
- استخدام الصور من متجر المسرح كذاكرة تخزين مؤقت لإعادة البناء وتجميع صور جديدة ؛
- استخدم المستودع للحصول على معلومات حول الصور المجمعة لاستخدامها مرة أخرى (على سبيل المثال ، عند تسليم تطبيق إلى Kubernetes).
عند نشر تطبيق واحد ، يجب استخدام تخزين أحادي المرحلة لجميع الفرق (التجميع ، النشر ، تنظيف الصور ، نشر التطبيق).
في الإصدار 1.0 ، يمكن فقط تخزين المضيف المحلي بمثابة تخزين المرحلة (المعلمة المطابقة للأوامر هي:
--stages-storage=:local ). عند استخدام
:local يتم تخزين المراحل
:local على القرص. نتيجة هذا: لا يمكن استخدام
werf 1.0 إلا
على مضيف واحد لتنظيم نشر
تطبيق واحد . يجب على هذا المضيف حفظ البيانات بين عمليات إطلاق الأوامر حتى يعمل werf بشكل صحيح.
في الإصدار 1.0 ، لا يوجد دعم لتخزين المراحل في وحدة التخزين الخارجية ، حيث يمكنك تنظيم مجموعة موزعة. ومع ذلك ، ستظهر هذه الوظيفة في الإصدارات المستقبلية من werf
(انظر أدناه لمزيد من التفاصيل) .
3. طرح التطبيق والتحقق من توافر
لطرح التطبيق ، يصف المستخدم المخطط بتنسيق متوافق مع Helm: مجموعة من Kubernetes تظهر ومعلمات القالب.
تقوم werf بتشغيل التطبيق في Kubernetes وتقدم ضمانًا ببدء التشغيل ووظائفه قبل إكمال عملية بدء التطبيق. يتضمن ذلك إخراج سجلات المكون والاستجابة الفورية لأخطاء بدء التشغيل عندما يحدث خطأ ما - سيتم إسقاط أمر بدء التشغيل برمز غير صفري. وبالتالي ، عند استخدام التطبيق werf في CI / CD ،
نحصل على تعليقات كافية من البرنامج : يتم تنزيل التطبيق من عدمه ، وهناك معلومات كافية لتصحيح المشكلات وحلها (دون الحاجة إلى تشغيل أدوات مساعدة أخرى للعثور على مشاكل مثل
kubectl ).
werf متوافق تمامًا مع عمليات تثبيت Helm 2 الحالية ، ولكن لدى werf العديد من المزايا. على سبيل المثال ، كآلية لتحديث الموارد ، تستخدم Kubernetes
تصحيحات دمج ثلاثية ، وهناك أيضًا إمكانية تلقي الملاحظات عند تسليم التطبيق إلى الكتلة. توجد قائمة كاملة بالاختلافات موضحة في
هذه الصفحة .
4. العلاقة بين الصور التي تم جمعها وعملية تسليم التطبيق
تقوم werf بدمج الصور التي تم جمعها في نظام واحد ، وهي عملية وضع علامات عليها وإصدارها مع عملية تسليم التطبيق إلى Kubernetes. يمكن استخدام الصور التي تجمعها werf في قوالب وصف موارد Kubernetes.
نظرًا لهذه الوظائف ، يمكننا القول أن
werf يوفر واجهة ذات مستوى أعلى من Helm و Docker وغيرهم من شركات البناء والأدوات المساعدة للنشر بشكل منفصل. تتيح لك هذه الواجهة ببساطة دمج werf في أي نظام CI / CD حالي وعدم حل مشاكل دمج جميع المكونات المستخدمة - فهو يتولى هذه المهمة.
5. التكامل مع أنظمة CI / CD الحالية
في الإصدار 1.0 ، يتوفر التكامل التلقائي فقط مع
نظام GitLab CI . للقيام بذلك ، يتم توفير الأمر
werf ci-env . يتلقى المعلومات الضرورية من نظام CI / CD ويقوم تلقائيًا بتكوين werf للعمل بشكل صحيح في بيئة CI.
يمكنك قراءة المزيد حول كيفية عمل التكامل مع أي نظام CI / CD في الكتيبات (
المراجعة ،
تفاصيل GitLab CI ،
التكامل مع الأنظمة الأخرى ).
6. التنمية عبر منصة لينكس ، ويندوز وماك
1.0 werf هو ملف ثنائي مرتبط بشكل ثابت يعمل بشكل مستقل مع كل من إصدارات Docker و Helm. التبعيات الخارجية على النظام المضيف:
- عامل الميناء الخفي المحلي
- فائدة بوابة.
يمكن تشغيل werf على أي من أنظمة التشغيل وبيئات GNU / Linux أو Windows أو macOS. علاوة على ذلك ، ستكون نتيجة التجميع هي نفسها بغض النظر عن النظام المستخدم: نفس التوقيع على مراحل ذاكرة التخزين المؤقت ، ونفس تعبئة المراحل ، بغض النظر عن النظام الذي تم جمع هذه المرحلة فيه. التغييرات في التكوين للعمل في أنظمة مختلفة غير مطلوبة أيضًا.
وبالتالي ، يوفر werf 1.0 أدوات عبر الأنظمة الأساسية لإنشاء وتقديم التطبيقات إلى Kubernetes.
تجدر الإشارة هنا أيضًا إلى أن werf يجمع صور Docker القياسية للعمل في بيئة Linux ، ولكن
حاويات Windows غير مدعومة في الإصدار 1.0.
7. تغطي وظائف مع الاختبارات
حاليا 60 ٪ من رمز werf تتم تغطيتها بواسطة اختبارات التكامل e2e واختبارات الوحدة.
يتم اختبار werf على جميع أنظمة التشغيل المدعومة (Linux و Windows و macOS) باستخدام GitHub Actions لتنظيم إطلاقها. تتوفر بعض تفاصيل الاختبار أيضًا على
Code Climate .
8. الإصدار werf
في الوقت الحالي ، بإصدار الإصدار 1.0 ، تم إجراء
حوالي 700 إصدار في المشروع.
يستخدم werf نظام إطلاق متقدم مع قنوات ثبات:
ألفا ،
بيتا ،
عصام (الوصول المبكر) ،
مستقر وصلب صلب . تم توقيت هذا المنشور ليتزامن مع إصدار الإصدار الأول 1.0 في القناة
المستقرة . تمر التغييرات غير المستقرة على الإصدار أولاً بسلسلة من القنوات وينتهي بها الأمر في النهاية
إلى مادة صلبة . غالبًا ما يتم إصدار البيانات (عدة مرات يوميًا) ويتم تقديم التغييرات باستمرار في "أجزاء صغيرة".
تتيح لك قنوات الاستقرار والعديد من الإصدارات المتكررة الحصول على تعقيبات مستمرة بشأن التغييرات الجديدة ، والقدرة على استرجاعها بسرعة وضمان الاستقرار العالي للبرنامج بشكل عام وفي نفس الوقت سرعة مقبولة لتطويره.
النقطة المهمة هي أنه عند التبديل بين الإصدارات 1.0-> 1.1 ، 1.1-> 1.2 ، فإن التغييرات على werf ممكنة والتي تتطلب تدخل يدوي من قبل المستخدم (يمكن أن يكون هذا البرنامج النصي للترحيل أو مجرد تعليمات للتنفيذ اليدوي الموضح في الإصدار). يضمن تحديث الإصدارات داخل 1.0 (1.0.1 ، 1.0.2 ، ... 1.0.6-alpha.1 ، 1.0.6-beta.2 ، وما إلى ذلك) أن هذه التغييرات اليدوية ليست مطلوبة.
يمكنك قراءة المزيد حول الوعد بالتوافق مع الإصدارات السابقة
هنا .
خطط أخرى
إليك ما تبدو عليه مجالات العمل الرئيسية للإصدارات المستقبلية والشروط التقريبية لتنفيذها:
1. التنمية المحلية ونشر التطبيقات مع werf
الهدف الرئيسي هو تحقيق تكوين موحد واحد لنشر التطبيقات محليًا وفي الإنتاج ، بدون إجراءات معقدة ، خارج الصندوق.
يحتاج Werf أيضًا إلى وضع التشغيل الذي سيكون من المناسب فيه تعديل رمز التطبيق وتلقي الملاحظات فورًا من تطبيق يعمل لتصحيح الأخطاء.
الإصدار 1.1 ، يناير-فبراير 20202. وضع العلامات على المحتوى
وضع علامات على الصور عند نشرها ، بناءً على محتويات هذه الصورة فقط. على عكس الأوضاع المرتبطة بربط Git ، سيتخلص هذا الوضع تمامًا من عمليات إعادة البناء غير الضرورية. Git-الالتزام-id ليس معرفًا عامًا لمحتوى ساحة العمل (على الرغم من أنه يعتمد عليه).
في حالة عدم تغيير رمز التطبيق ، ولكن تم إجراء التزام جديد ، فإن وضع العلامات الحالي لإجراءات Git سينشئ صورة باسم جديد عند نشره. سوف يستلزم هذا أيضًا استرجاع الموارد باستخدام هذه الصورة في Kubernetes. في الوقت نفسه ، لم تتغير محتويات الصورة نفسها.
لحل هذه المشكلات ، ستقدم werf نوعًا جديدًا من العلامات بناءً على حسابات المجموع الاختباري
لمحتوى التطبيق -
وضع العلامات على المحتوى .
الإصدار 1.1 ، فبراير-مارس 20203. الانتقال إلى هيلم 3
ويشمل الانتقال إلى قاعدة رمز
Helm 3 الجديدة وطريقة مجربة ومناسبة لترحيل المنشآت الحالية.
الإصدار 1.1 ، فبراير-مارس 20204. التجمع الموازي للصور
في الوقت الحالي ، يجمع werf 1.0 جميع مراحل الصور والتحف المعلنة بالتتابع
werf.yaml . يتطلب القدرة على موازنة عملية التجميع المرحلة.
الإصدار: 1.1 ، يناير-فبراير 20205. توزيع تجميع الصور
في الوقت الحالي ، لا يمكن استخدام werf 1.0 إلا على مضيف واحد مخصص
(انظر النقطة أعلاه حول تخزين المرحلة على مضيف واحد فقط) .
لفتح إمكانيات التجميع الموزع ، عندما يتم تشغيل التجميع على عدة مضيفين ولا تحتفظ هذه المضيفات بحالتها بين التجميعات (المتسابقين المؤقتين) ، يلزم werf لتطبيق إمكانية استخدام Docker Registry كمستودع للمرحلة.
سابقا ، عندما كان يسمى مشروع werf أيضا dapp ، كان لديه مثل هذه الفرصة. ومع ذلك ، واجهنا عددًا من المشكلات التي يجب مراعاتها عند تنفيذ هذه الوظيفة في werf.
الإصدار 1.2: مارس-أبريل 20206. Jsonnet لوصف التكوين Kubernetes
سوف تدعم werf وصف التكوين لـ
Kubernetes بتنسيق
Jsonnet . في نفس الوقت ، سيبقى werf متوافقًا مع Helm وسيكون من الممكن تحديد تنسيق وصف.
والسبب هو حقيقة أن قوالب لغة Go ، وفقًا للعديد من الأشخاص ، لها عتبة دخول كبيرة ، كما تعاني وضوح التعليمات البرمجية لهذه القوالب.
كما يتم النظر في خيارات أخرى لتطبيق أنظمة وصف تكوين Kubernetes (مثل Kustomize).
الإصدار 1.1: من يناير إلى فبراير 20207. العمل داخل Kubernetes
الغرض: ضمان تجميع الصور وتسليم التطبيق باستخدام المتسابقين في Kubernetes. أي يمكن أن يحدث تجميع للصور الجديدة ونشرها وتنظيفها ونشرها مباشرةً من قرون Kubernetes.
لتحقيق هذه الميزة ، تحتاج أولاً إلى القدرة على توزيع الصور بطريقة موزعة
(انظر الفقرة أعلاه) .
كما يتطلب دعمًا لوضع بنية التشغيل دون استخدام البرنامج الخفي Docker (مثل ، بناء يشبه Kaniko أو
بناء في مساحة المستخدمين ).
ستدعم werf تصميمات Kubernet ليس فقط مع Dockerfile ، ولكن أيضًا مع منشئ Stapel الخاص به مع عمليات إعادة بناء تدريجية.
الإصدار 1.2: أبريل-مايو 20208. أخرى
ومن المخطط أيضا:
- ترقية إصدار Ansible والقدرة على استخدام إصدارات مختلفة من Ansible ؛
- دعم للأدوار ansible.
- دعم لمراحل التجميع التعسفي في Stapel (يدعم werf حاليًا مجموعة ثابتة من المراحل:
beforeInstall install ، install ، beforeSetup setup ، setup ) ؛ - تحسين بناء جملة
werf.yaml ، والتحول إلى configVersion: 2 (يرتبط ، في جملة أمور ، بالنقطتين السابقتين) ، دعم لمواصفات OpenAPI ؛ - دعم Git LFS في Stapel لتخزين الملفات الكبيرة في Git ؛
- تحسين آليات تنظيف الصور (ترتبط العيوب غير الحرجة في الإصدار الحالي بصور لم يتم الإعلان عنها في
werf.yaml config في الفرع الرئيسي الرئيسي - سيتم حذف هذه الصور عن طريق التنظيف الدوري) ؛ - مزيد من العمل الصحيح مع مساحة اسم Kubernetes المشتركة ، عند نشر العديد من التطبيقات في مساحة اسم واحدة ؛
- التراجع التلقائي للتطبيق إلى أحدث إصدار العمل في حالة النشر غير الناجح.
في المجموع
سأكون موجزا في تلخيص. نحن:
- مشى طويلا إلى ظهور الإصدار 1.0 ؛
- أخذت في الاعتبار الكثير من الخبرة الحقيقية ؛
- نقدم لاستخدام أداة مجربة مع وظائف مستقرة ، يتم التحقق منها من قبل عشرات الآلاف من النشرات.
يمثل إصدار الإصدار 1.0 بداية مرحلة تطوير جديدة لـ werf ، حيث سيتم إضافة ميزات جديدة بشكل أساسي. اتبع الأخبار! وانضم أيضًا إلى
werf_ru tg-channel ، حيث يشارك كل من مطوري werf المباشرين ومهندسينا ومستخدمي الأداة المساعدة خارج شركة Flant.
PS
اقرأ أيضًا في مدونتنا: