werf - أداتنا لـ CI / CD في Kubernetes (نظرة عامة وتقرير فيديو)

27 مايو في القاعة الرئيسية لمؤتمر DevOpsConf 2019 ، الذي عقد كجزء من المهرجان RIT ++ 2019، في إطار قسم "التسليم المستمر" ، تم إعداد تقرير "werf - أداتنا لـ CI / CD في Kubernetes". يتحدث عن هؤلاء المشاكل والتحديات التي يواجهها الجميع عند النشر في Kubernetes، بالإضافة إلى الفروق الدقيقة التي قد لا تكون ملحوظة على الفور. تحليل الحلول الممكنة ، نوضح كيف يتم تنفيذ ذلك في أداة المصدر المفتوح werf.

منذ العرض التقديمي ، تجاوزت فائدتنا (المعروفة سابقًا باسم dapp) معلمًا تاريخيًا في 1000 نجمة على جيثب - نأمل أن يعمل المجتمع المتنامي لمستخدميه على تسهيل الحياة على العديد من مهندسي DevOps.

لذلك ، نحن نقدم فيديو مع التقرير (حوالي 47 دقيقة ، أكثر إفادة بكثير من المقالة) والمقتطف الرئيسي منه في شكل نص. يذهب!

تسليم التعليمات البرمجية إلى Kubernetes

لن يدور الحديث في التقرير حول werf بعد الآن ، ولكن حول CI / CD في Kubernetes ، مما يعني أن برنامجنا معبأ في حاويات Docker (لقد تحدثت عن هذا في تقرير 2016)، وسيتم استخدام K8s لتشغيله في الإنتاج (المزيد عن هذا في 2017 العام).

كيف يبدو التسليم في Kubernetes؟

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

هناك بعض الملاحظات المهمة هنا:

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

دعنا نعود إلى مخطط التسليم Kubernetes الموضح أعلاه: لم نبتكره فقط من قبلنا ، ولكن حرفيًا كل من تعامل مع هذه المشكلة. في الواقع ، يسمى هذا النمط الآن GitOps (لمزيد من المعلومات حول المصطلح والأفكار الكامنة وراءه ، انظر هنا). دعونا نلقي نظرة على مراحل المخطط.

مرحلة البناء

يبدو أنه في عام 2019 ، ما يمكن قوله حول إنشاء صور Docker ، عندما يعرف الجميع كيفية كتابة Dockerfiles وتشغيله docker build؟ .. فيما يلي الفروق الدقيقة التي أود الانتباه إليها:

1. وزن الصورة المسائل ، لذلك استخدم متعددة المراحللترك فقط في الصورة ما هو مطلوب حقًا للتطبيق حتى يعمل.
2. عدد الطبقات يجب التقليل من خلال الجمع بين السلاسل من RUN- الأوامر بالمعنى.
3. ومع ذلك ، فإن هذا يضيف إلى المشكلة تصحيح الأخطاء، لأنه عندما يقع التجميع ، عليك أن تجد الأمر الصحيح من السلسلة التي تسببت في المشكلة.
4. سرعة التجميع مهم لأننا نريد طرح التغييرات بسرعة وإلقاء نظرة على النتيجة. على سبيل المثال ، لا تريد إعادة بناء التبعيات في مكتبات اللغة في كل مرة تقوم فيها بإنشاء تطبيق.
5. في كثير من الأحيان ، من مستودع Git واحد ، تحتاج العديد من الصور، والتي يمكن حلها عن طريق مجموعة من ملفات Dockerfiles (أو مراحل مسماة في ملف واحد) ونص باش بتجميعها المتسلسل.

كان هذا مجرد غيض من فيض يواجهه الجميع. لكن هناك مشاكل أخرى ، وعلى وجه الخصوص:

1. غالبًا في مرحلة التجميع نحتاج إلى شيء تتعدد (على سبيل المثال ، تخزين نتيجة أمر مثل apt'a في دليل جهة خارجية مؤقتًا).
2. نحن نريد Ansible بدلا من الكتابة في شل.
3. نحن نريد بناء بدون عامل ميناء (لماذا نحتاج إلى جهاز افتراضي إضافي نحتاج فيه إلى تهيئة كل شيء لهذا عندما يكون هناك بالفعل مجموعة Kubernetes يمكن تشغيل الحاويات فيها؟).
4. الجمعية الموازية، والتي يمكن فهمها بطرق مختلفة: أوامر مختلفة من Dockerfile (إذا تم استخدام متعدد المراحل) ، وعدة التزامات من نفس المستودع ، والعديد من ملفات Dockerfiles.
5. التجميع الموزع: نريد أن نجمع شيئًا في كبسولات "سريعة الزوال" لأن يفقدون ذاكرة التخزين المؤقت ، مما يعني أنه يجب تخزينها في مكان ما بشكل منفصل.
6. أخيرًا ، سميت ذروة الرغبات أوتوماجيك: سيكون من المثالي الذهاب إلى المستودع ، وكتابة بعض الأوامر والحصول على صورة جاهزة ، مجمعة مع فهم كيف وماذا تفعل بشكل صحيح. ومع ذلك ، أنا شخصياً لست متأكدًا من إمكانية توقع جميع الفروق الدقيقة بهذه الطريقة.

وها هي المشاريع:

• moby / buildkit - جامع من Docker Inc (مدمج بالفعل في الإصدارات الحالية من Docker) ، والذي يحاول حل كل هذه المشاكل ؛
• كانيكو - منشئ Google الذي يسمح لك بالبناء بدون Docker ؛
• buildpacks.io - محاولة من قبل CNCF لصنع حل آلي ، وعلى وجه الخصوص ، حل مثير للاهتمام مع تغيير الأساس للطبقات ؛
• ومجموعة من المرافق الأخرى مثل بناءا, genuinetools / img...

... واطلع على عدد النجوم الموجودة على GitHub. هذا هو ، من ناحية ، docker build هو ويستطيع أن يفعل شيئًا ، ولكن في الواقع شيء ما لم يتم حل المشكلة بالكامل - والدليل على ذلك هو التطوير الموازي للمجمعات البديلة ، كل منها يحل جزءًا من المشاكل.

التجمع في werf

لذلك وصلنا إلى werf (سابقا معروف مثل dapp) - شركة المرافق المفتوحة المصدر "فلانت" ، والتي نقوم بها منذ سنوات عديدة. بدأ كل شيء منذ 5 سنوات بنصوص Bash التي تعمل على تحسين تجميع Dockerfiles ، وعلى مدى السنوات الثلاث الماضية ، تم تنفيذ تطوير كامل في نفس المشروع مع مستودع Git الخاص به (أولاً في روبي ، ثم بعد ذلك إعادة كتابتها on Go ، وفي نفس الوقت أعيدت تسميته). ما هي قضايا البناء التي يتم حلها في werf؟

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

مرحلة النشر في السجل (النشر)

يحرز هدف docker push... - ما الذي يمكن أن يكون صعبًا بشأن تحميل صورة إلى التسجيل؟ ثم يطرح السؤال التالي: "ما العلامة التي يجب وضعها على الصورة؟" ينشأ لسبب لدينا جيت فلو (أو إستراتيجيات Git الأخرى) و Kubernetes ، وتريد الصناعة التأكد من أن ما يحدث في Kubernetes يتبع ما يحدث في Git. بعد كل شيء ، جيت هو مصدر الحقيقة الوحيد لدينا.

ما هو الأمر الصعب في هذا؟ ضمان التكاثر: من التزام في Git غير قابل للتغيير بطبيعته (ثابت)، إلى صورة Docker ، والتي يجب أن تظل كما هي.

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

استراتيجيات وضع العلامات

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

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

الخيار الثاني - بوابة الالتزام + العلامة. الفرع الرئيسي له علامة 1.0؛ لذلك في التسجيل - نشر صورة للإنتاج. بالإضافة إلى ذلك ، تحتوي مجموعة Kubernetes على حلقات معاينة وتدريج. بعد ذلك ، نتبع Gitflow: upstream for development (develop) نصنع ميزات جديدة ، ونتيجة لذلك يظهر التزام بمعرف #c1. نقوم بجمعها ونشرها في التسجيل باستخدام هذا المعرف (#c1). باستخدام نفس المعرف ، نبدأ للمعاينة. افعل نفس الشيء مع الالتزامات #c2 и #c3.

عندما أدركنا أن هناك ميزات كافية ، بدأنا في تثبيت كل شيء. قم بإنشاء فرع في Git release_1.1 (على القاعدة #c3 من develop). لن تحتاج إلى تجميع هذا الإصدار ، لأن. تم ذلك في الخطوة السابقة. لذلك ، يمكننا ببساطة طرحها على مرحلة الإعداد. إصلاح الخلل في #c4 وطرحها بالمثل في مرحلة الإعداد. في نفس الوقت ، تطوير develop، حيث يتم أخذ التغييرات بشكل دوري release_1.1. في مرحلة ما ، نحصل على التزام مُجمَّع ومُطرح بالتدريج ، ونحن راضون عنه (#c25).

ثم ندمج (مع التقديم السريع) فرع التحرير (release_1.1) في الماجستير. نضع علامة بالإصدار الجديد على هذا الالتزام (1.1). لكن هذه الصورة مدمجة بالفعل في السجل ، لذا حتى لا يتم بناؤها مرة أخرى ، نضيف فقط علامة ثانية إلى الصورة الحالية (الآن بها علامات في التسجيل #c25 и 1.1). بعد ذلك ، نطرحه للإنتاج.

هناك عيب يتمثل في طرح صورة واحدة للتشغيل المرحلي (#c25) وحول الإنتاج - حيث كان مختلفًا (1.1) ، لكننا نعلم أن هذه هي نفس الصورة من التسجيل "جسديًا".

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

يمكنك المضي قدمًا والقيام بالخدعة ... فكر في مثال بسيط لملف Docker:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

لننشئ ملفًا منه وفقًا للمبدأ الذي نأخذه:

• SHA256 من معرفات الصور المستخدمة (ruby:2.3 и nginx:alpine) ، وهي مجاميع اختبارية لمحتوياتها ؛
• كل الأوامر (RUN, CMD وما إلى ذلك وهلم جرا.)؛
• SHA256 من الملفات التي تمت إضافتها.

... وأخذ المجموع الاختباري (مرة أخرى SHA256) من هذا الملف. هذا إمضاء أي شيء يحدد محتويات صورة Docker.

دعنا نعود إلى الرسم التخطيطي و بدلاً من الالتزامات ، سوف نستخدم مثل هذه التوقيعات، أي. وسم الصور بالتوقيعات.

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

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

وضع العلامات في werf

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

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

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

وبالتالي ، فإن صور المرحلة هي ذاكرة تخزين مؤقت يمكن تخزينها وتوزيعها ، ويتم تحميل صور الصور التي تم إنشاؤها بالفعل منها في Docker Registry.

تنظيف السجل

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

ما هي استراتيجيات التنظيف؟

1. ربما لا شيء لا تنظف. في بعض الأحيان يكون من الأسهل حقًا دفع القليل مقابل مساحة إضافية بدلاً من كشف مجموعة متشابكة من العلامات. لكن هذا يصل إلى نقطة معينة فقط.
2. إعادة تعيين كامل. إذا حذفت جميع الصور وأعدت إنشاء تلك ذات الصلة فقط في نظام CI ، فقد تظهر مشكلة. إذا تم إعادة تشغيل الحاوية في الإنتاج ، فسيتم تحميل صورة جديدة لها - صورة لم يختبرها أي شخص بعد. هذا يقتل فكرة البنية التحتية غير القابلة للتغيير.
3. أزرق أخضر. بدأ أحد التسجيلات في الفائض - نقوم بتحميل الصور في سجل آخر. نفس المشكلة كما في الطريقة السابقة: في أي نقطة يمكن مسح السجل الذي بدأ في تجاوز الفائض؟
4. بالوقت. هل تريد حذف جميع الصور التي مضى عليها أكثر من شهر؟ ولكن ستكون هناك بالتأكيد خدمة لم يتم تحديثها لمدة شهر كامل ...
5. يدويا تحديد ما يمكن إزالته.

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

ما وصلنا إليه werf؟ نجمعها:

1. Git head: جميع العلامات ، جميع الفروع ، - بافتراض أن كل ما تم وضع علامة عليه في Git ، نحتاج في الصور (وإذا لم يكن الأمر كذلك ، فسنحتاج إلى حذفه في Git نفسه) ؛
2. جميع الكبسولات التي يتم طرحها حاليًا على Kubernetes ؛
3. مجموعات النسخ المتماثلة القديمة (التي تم تنزيلها مؤخرًا) ، ونخطط أيضًا لفحص إصدارات Helm وتحديد أحدث الصور هناك.

... وقم بعمل قائمة بيضاء من هذه المجموعة - قائمة بالصور التي لن نحذفها. نقوم بتنظيف كل شيء آخر ، وبعد ذلك نجد صور المرحلة اليتيمة ونحذفها أيضًا.

مرحلة النشر

التصريح الموثوق

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

1. معرفات؛
2. معلومات رسمية
3. مجموعة من القيم الافتراضية ؛
4. قسم مع الوضع الحالي ؛
5. التغييرات التي تم إجراؤها كجزء من خطاف الويب الخاص بالقبول ؛
6. نتيجة عمل وحدات التحكم المختلفة (والمجدول).

لذلك عندما يظهر تكوين مورد جديد (جديد) ، لا يمكننا فقط أخذ التكوين "المباشر" الحالي والكتابة فوقه (حي). للقيام بذلك ، علينا المقارنة جديد مع آخر تكوين تم تطبيقه (آخر تطبيق) وتدحرج حي تلقى التصحيح.

هذا النهج يسمى دمج في اتجاهين. يتم استخدامه ، على سبيل المثال ، في هيلم.

هناك أيضا دمج في اتجاهينوالذي يختلف في ذلك:

• المقارنة آخر تطبيق и جديد، ننظر إلى ما تمت إزالته ؛
• المقارنة جديد и حي، ننظر إلى ما تم إضافته أو تغييره ؛
• يتم تطبيق التصحيح الملخص حي.

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

حالة الطرح الحقيقية

بعد الحدث التالي ، أنشأ نظام CI تكوينًا جديدًا لـ Kubernetes ، ويمرره للاستخدام (يتقدم) إلى الكتلة - باستخدام Helm أو kubectl apply. بعد ذلك ، يتم دمج N-way الموصوف بالفعل ، والذي تستجيب له Kubernetes API بشكل مقبول لنظام CI ، وهذا النظام لمستخدمه.

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

للقيام بكل شيء بشكل صحيح ، يتطلب هذا المخطط رابطًا إضافيًا - أداة تعقب خاصة ستتلقى معلومات الحالة من Kubernetes API وتنقلها لمزيد من التحليل للوضع الحقيقي للأمور. لقد أنشأنا مكتبة مفتوحة المصدر في Go - com.cubdog (انظر إعلانها هنا)، الذي يحل هذه المشكلة وهو مدمج في werf.

يتم تكوين سلوك هذا المتعقب على مستوى werf باستخدام التعليقات التوضيحية التي يتم وضعها في عمليات النشر أو StatefulSets. التعليق التوضيحي الرئيسي - fail-mode يفهم المعاني التالية:

• IgnoreAndContinueDeployProcess - نتجاهل مشاكل طرح هذا المكون ونواصل النشر ؛
• FailWholeDeployProcessImmediately - خطأ في هذا المكون يوقف عملية النشر ؛
• HopeUntilEndOfDeployProcess - نأمل أن يعمل هذا المكون بنهاية النشر.

على سبيل المثال ، مجموعة من الموارد وقيم التعليقات التوضيحية fail-mode:

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

هناك نوعان من التعليقات التوضيحية الأخرى لـ kubedog في werf:

• failures-allowed-per-replica - عدد السقوط المسموح به لكل نسخة طبق الأصل ؛
• show-logs-until - ينظم اللحظة التي يعرض فيها werf (في stdout) السجلات من جميع القرون التي تم لفها. الافتراضي هو PodIsReady (لتجاهل الرسائل ، وهو ما لا نريده حقًا عندما يبدأ الكبسولة في تلقي حركة المرور) ، ولكن القيم صالحة أيضًا ControllerIsReady и EndOfDeploy.

ماذا نريد أيضًا من النشر؟

بالإضافة إلى النقطتين الموصوفتين بالفعل ، نود أن:

• شاهد السجلات - وما يلزم فقط ، وليس كل شيء على التوالي ؛
• مسار تقدم، لأنه إذا توقفت الوظيفة "بصمت" لعدة دقائق ، فمن المهم فهم ما يحدث هناك ؛
• иметь التراجع التلقائي في حالة حدوث خطأ ما (وبالتالي فمن الأهمية بمكان معرفة الوضع الحقيقي لعملية النشر). يجب أن يكون الطرح ذريًا: إما أنه يمتد حتى النهاية ، أو يعود كل شيء إلى حالته السابقة.

نتائج

نحن ، كشركة ، نحتاج إلى نظام CI وأداة مساعدة لتنفيذ جميع الفروق الدقيقة الموصوفة في مراحل مختلفة من التسليم (الإنشاء والنشر والنشر). werf.

بدلاً من الاستنتاج:

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

مقاطع الفيديو والشرائح

فيديو من العرض (47 دقيقة تقريبًا):

عرض التقرير:

PS

تقارير أخرى حول Kubernetes في مدونتنا:

• «القياس التلقائي وإدارة الموارد في Kubernetes» (ديمتري ستولياروف ؛ 27 أبريل 2019 في ستاتشكا);
• «تمديد واستكمال Kubernetes» (أندري بولوفوف ؛ 8 أبريل 2019 في Saint HighLoad ++);
• «قواعد البيانات و Kubernetes» (ديمتري ستولياروف ؛ 8 نوفمبر 2018 على HighLoad ++);
• «المراقبة و Kubernetes» (ديمتري ستولياروف ؛ 28 مايو 2018 في RootConf);
• «أفضل ممارسات CI / CD مع Kubernetes و GitLab» (ديمتري ستولياروف ؛ 7 نوفمبر 2017 على HighLoad ++);
• «تجربتنا مع Kubernetes في المشاريع الصغيرة» (ديمتري ستولياروف ؛ 6 يونيو 2017 في RootConf).

المصدر: www.habr.com