في 27 مايو ، في القاعة الرئيسية لمؤتمر DevOpsConf 2019 ، الذي عقد كجزء من مهرجان
RIT ++ 2019 ، كجزء من قسم التسليم المستمر ، تم إعداد تقرير "werf هو أداتنا لـ CI / CD في Kubernetes". يتحدث عن
المشكلات والتحديات التي يواجهها الجميع عند النشر إلى Kubernetes ، وكذلك حول الفروق الدقيقة التي قد لا تكون ملحوظة على الفور. تحليل الحلول الممكنة ، نعرض كيف يتم تنفيذ ذلك في أداة مفتوحة المصدر.
منذ العرض ، تغلبت فائدتنا (المعروفة سابقًا باسم dapp) على الحد التاريخي البالغ
1000 نجمة على GitHub - نأمل أن يبسط المجتمع المتزايد لمستخدميه حياة العديد من مهندسي DevOps.
لذلك ، نقدم
الفيديو مع التقرير (حوالي 47 دقيقة ، أكثر إفادة بكثير من المقال) والمستخلص الرئيسي منه في شكل نص. دعنا نذهب!
كود التسليم في Kubernetes
لم يعد النقاش يدور حول werf ، ولكن حول CI / CD في Kubernetes ، مما يعني ضمنا أن برامجنا قد تم تعبئتها في حاويات Docker
(تحدثت عن هذا في تقرير 2016 ) ، وسيتم استخدام K8s لإطلاقه في الإنتاج
(حول هذا - في عام 2017 ) .
كيف يبدو تسليم Kubernetes؟
- هناك مستودع Git مع رمز وتعليمات لبناء عليه. يتم تجميع التطبيق في صورة Docker ونشره على Docker Registry.
- توجد في نفس المستودع إرشادات حول كيفية نشر التطبيق وتشغيله. في مرحلة النشر ، يتم إرسال هذه التعليمات إلى Kubernetes ، التي تتلقى الصورة المطلوبة من السجل وتبدأ تشغيلها.
- بالاضافة الى ذلك ، هناك عادة الاختبارات. يمكن تنفيذ بعضها عند نشر صورة. يمكنك أيضًا (وفقًا لنفس التعليمات) نشر نسخة من التطبيق (في مساحة اسم K8 منفصلة أو في مجموعة منفصلة) وإجراء اختبارات هناك.
- أخيرًا ، نحتاج إلى نظام CI يستقبل الأحداث من Git (أو نقرات الأزرار) ويستدعي جميع المراحل المحددة: الإنشاء ، النشر ، النشر ، الاختبار.
هناك بعض الملاحظات المهمة هنا:
- نظرًا لوجود بنية تحتية ثابتة ، يجب أن تكون صورة التطبيق المستخدمة في جميع المراحل (التدريج ، الإنتاج ، إلخ) واحدة . تحدثت أكثر عن هذا وأمثلة هنا .
- نظرًا لأننا نتبع البنية التحتية كنهج (IaC) للرمز ، يجب أن يوضع رمز التطبيق وإرشادات بناءه وتشغيله في مستودع واحد . لمعرفة المزيد عن هذا ، راجع نفس التقرير .
- عادة ما نرى سلسلة التسليم (التسليم) كما يلي: يتم تجميع التطبيق واختباره وإصداره (مرحلة الإصدار) وهذا كله - لقد حدث التسليم. لكن في الواقع ، يتلقى المستخدم ما تم طرحه ، ليس عند تسليمه للإنتاج ، ولكن عندما كان قادرًا على الذهاب إلى هناك وعمل هذا الإنتاج. لذلك ، أعتقد أن سلسلة التسليم لا تنتهي إلا في مرحلة التشغيل (التشغيل) ، وبشكل أكثر دقة ، حتى في الوقت الذي تمت فيه إزالة الرمز من الإنتاج (استبداله بآخر جديد).
دعنا نعود إلى مخطط التسليم Kubernetes المبين أعلاه: لقد اخترع ليس فقط من قبلنا ، ولكن حرفيًا من قبل كل من تعامل مع هذه المشكلة. في جوهرها ، يسمى هذا النمط الآن GitOps
(المزيد عن المصطلح والأفكار التي تقف وراءه يمكن العثور عليها هنا ) . لنلقِ نظرة على مراحل المخطط.
بناء المرحلة
يبدو أنه في عام 2019 ، يمكنك معرفة تجميع صور Docker ، عندما يعرف الجميع كيفية كتابة Dockerfiles وتشغيل
docker build ؟ .. إليك الفروق الدقيقة التي أود الانتباه إليها:
- إن أهمية الصورة مهمة ، لذا استخدم المراحل المتعددة لترك التطبيق المطلوب فقط للصورة فقط.
- يجب تقليل عدد الطبقات عن طريق الجمع بين سلاسل أوامر
RUN ضمن المعنى. - ومع ذلك ، فإن هذا يضيف إلى مشاكل التصحيح ، لأنه عندما يتعطل التجميع ، يجب عليك العثور على الأمر الضروري من السلسلة التي تسببت في المشكلة.
- بناء السرعة أمر مهم لأننا نريد طرح التغييرات بسرعة وإلقاء نظرة على النتيجة. على سبيل المثال ، لا أريد إعادة تجميع التبعيات في مكتبات اللغات مع كل بنية للتطبيق.
- غالبًا ما يتطلب مستودع Git المفرد العديد من الصور ، والتي يمكن حلها بواسطة مجموعة من Dockerfiles (أو المراحل المحددة في ملف واحد) ونص Bash مع التجميع المتسلسل.
كان مجرد قمة جبل الجليد الذي يواجهه الجميع. ولكن هناك مشاكل أخرى ، وعلى وجه الخصوص:
- غالبًا ما نحتاج إلى تحميل شيء ما في مرحلة التجميع (على سبيل المثال ، التخزين المؤقت نتيجة أمر مثل apt إلى دليل جهة خارجية).
- نريد Ansible بدلا من الكتابة على قذيفة.
- نريد أن نبني بدون Docker (لماذا نحتاج إلى آلة افتراضية إضافية تحتاج فيها إلى تكوين كل شيء لهذا عندما يكون هناك بالفعل كتلة Kubernetes التي يمكنك تشغيل الحاويات فيها؟).
- التجميع المتوازي ، والذي يمكن فهمه بطرق مختلفة: أوامر مختلفة من Dockerfile (إذا تم استخدام متعدد المراحل) ، العديد من الإلتزامات لمستودع واحد ، عدة Dockerfiles.
- التجميع الموزع : نريد جمع شيء ما في القرون التي "سريعة الزوال" ، لأن تختفي ذاكرة التخزين المؤقت ، مما يعني أنه يجب تخزينه في مكان ما بشكل منفصل.
- أخيرًا ، لقد وصفت قمة الرغبات بالرغبة الذاتية: سيكون من المثالي الذهاب إلى المستودع ، كتابة فريق ما والحصول على صورة جاهزة ، يتم تجميعها مع فهم كيفية وما يجب القيام به بشكل صحيح. ومع ذلك ، أنا شخصياً لست متأكداً من أنه يمكن توقع جميع الفروق الدقيقة بهذه الطريقة.
وهنا المشاريع:
... وانظر كم من النجوم لديهم على جيثب. هذا ، من ناحية ، هو
docker build ويمكن القيام بشيء ما ، ولكن في الواقع ،
لم يتم حل المشكلة بالكامل - ويتضح ذلك من خلال التطوير الموازي لبناة بديلة ، كل منها يحل بعض المشاكل.
بناء في werf
لذلك وصلنا إلى
werf ( المعروف سابقًا باسم dapp) - الأداة المساعدة مفتوحة المصدر لـ Flant ، والتي كنا نقوم بها لسنوات عديدة. بدأ كل شيء منذ حوالي 5 سنوات مع البرامج النصية Bash التي تعمل على تحسين تجميع Dockerfiles ، والسنوات الثلاث الأخيرة ، كان التطوير الكامل مستمرًا في إطار مشروع واحد من خلال مستودع Git الخاص به
(الأول في روبي ، ثم تمت إعادة كتابته إلى Go ، ثم تمت إعادة تسميته في نفس الوقت) . ما بناء القضايا يتم حلها في werf؟
تم بالفعل تنفيذ المشكلات المظللة باللون الأزرق ، وتم إجراء التجميع الموازي داخل المضيف نفسه ، ونخطط لاستكمال الأسئلة الصفراء بحلول نهاية الصيف.
مرحلة النشر في السجل (نشر)
docker push ... - ما يمكن أن يكون صعبا في تحميل صورة إلى التسجيل؟ ثم السؤال الذي يطرح نفسه: "ما العلامة لوضع الصورة؟" تنشأ لسبب وجود
Gitflow (أو استراتيجية Git أخرى) و Kubernetes ، وتلتزم الصناعة بضمان أن ما يحدث في Kubernetes يتبع ما يجري في Git. بوابة هو مصدر الحقيقة الوحيد.
ما هو معقد جدا؟
تأكد من إمكانية التكاثر : من الالتزام في Git ، وهو أمر
غير قابل للتغيير بطبيعته ، إلى صورة Docker يجب الحفاظ عليها كما هي.
من المهم أيضًا بالنسبة لنا
تحديد الأصل ، لأننا نريد أن نفهم من أي التزام تم إنشاء التطبيق الذي تم تشغيله في Kubernetes (بعد ذلك يمكننا أن نفعل الاختلافات وأشياء مماثلة).
استراتيجيات العلامات
الأول هو
علامة بوابة بسيطة. لدينا سجل مع صورة تحمل علامة
1.0 . Kubernetes لها مرحلة وإنتاج ، حيث يتم ضخ هذه الصورة. في Git ، نلتزم ونضع العلامة
2.0 عند نقطة ما. نجمعها وفقًا لتعليمات المستودع ونضعها في السجل باستخدام علامة
2.0 . نحن نطرحها على خشبة المسرح ، وإذا كان كل شيء على ما يرام ، ثم على الإنتاج.
المشكلة في هذا النهج هي أننا وضعنا العلامة أولاً ، وبعد ذلك فقط قمنا باختبارها وطرحها. لماذا؟ أولاً ، هذا أمر غير منطقي: نمنح إصدارًا من البرامج لم نختبره حتى (لا يمكننا القيام بذلك ، لأنه من أجل التحقق ، تحتاج إلى وضع علامة). ثانياً ، هذه الطريقة غير متوافقة مع Gitflow.
الخيار الثاني هو
بوابة الالتزام + العلامة . هناك علامة
1.0 في الفرع الرئيسي ؛ بالنسبة له في التسجيل - صورة نشرت للإنتاج. بالإضافة إلى ذلك ، تحتوي مجموعة Kubernetes على حلقات معاينة وتدريج. علاوة على ذلك ، نتبع Gitflow: في الفرع الرئيسي للتطوير ، نقوم
develop ميزات جديدة ، ونتيجة لذلك يوجد التزام
#c1 . نجمعها وننشرها في السجل باستخدام هذا المعرف (
#c1 ). نطرح المعاينة بنفس المعرف. نحن نفعل الشيء نفسه مع ارتكاب
#c2 و
#c3 .
عندما أدركنا أن هناك ميزات كافية ، نبدأ في تثبيت كل شيء. في Git ، قم بإنشاء فرع
release_1.1 (استنادًا إلى
#c3 من
develop ). جمع هذا الإصدار غير مطلوب ، لأن تم ذلك في الخطوة السابقة. لذلك ، يمكننا فقط طرحه على التدريج. نحن نصلح الأخطاء في
#c4 بالمثل التدريج. في الوقت نفسه ، يجري
develop في مرحلة
develop ، حيث يتم إجراء تغييرات من
release_1.1 بشكل دوري. في مرحلة ما ، نحصل على التزام
#c25 إلى الالتزام بالتدريج ، وهو ما يسعدنا (
#c25 ).
ثم نقوم بدمج (مع التقديم السريع) لفرع الإصدار (
release_1.1 ) بشكل رئيسي. نضع علامة مع الإصدار الجديد (
1.1 ) على هذا الالتزام. لكن هذه الصورة قد تم تجميعها بالفعل في السجل ، لذا حتى لا نجمعها مرة أخرى ، نضيف فقط علامة ثانية إلى الصورة الحالية (الآن لها علامات
#c25 و
1.1 في السجل). بعد ذلك ، نحن نخرجه إلى الإنتاج.
يوجد عيب في أن صورة واحدة (
#c25 ) يتم
#c25 على مراحل ، ويتم
#c25 أخرى (
1.1 ) على الإنتاج ، لكننا نعرف أنها "فعليًا" هي نفس الصورة من السجل.
ناقص حقيقي هو أنه لا يوجد دعم لدمج الالتزام ، تحتاج إلى القيام بسرعة إلى الأمام.
يمكنك الذهاب أبعد من ذلك والقيام بالخدعة ... خذ بعين الاعتبار مثال Dockerfile بسيط:
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 ، نسميها
مرحلة وصورة .
يقوم مستودع wit git بتخزين إرشادات بناء محددة تصف المراحل المختلفة للبناء (
قبل التثبيت ،
التثبيت ،
قبل الإعداد ،
الإعداد ). نقوم بتجميع صورة المرحلة الأولى بتوقيع محدد على شكل المجموع الاختباري للخطوات الأولى. ثم نضيف الكود المصدري ، لصورة المسرح الجديدة التي نعتبرها الاختباري ... تتكرر هذه العمليات لجميع المراحل ، ونتيجة لذلك نحصل على مجموعة من الصور المسرحية. ثم نصنع الصورة النهائية للصورة التي تحتوي أيضًا على بيانات وصفية حول أصلها. ونضع علامة على هذه الصورة بطرق مختلفة (التفاصيل لاحقًا).
دع بعد ذلك يظهر التزام جديد ، حيث يتم تغيير رمز التطبيق فقط. ماذا سيحدث؟ سيتم إنشاء تصحيح لتغييرات الرمز ، وسيتم إعداد صورة مرحلة جديدة. سيتم تعريف توقيعه على أنه المجموع الاختباري لصورة المرحلة القديمة والتصحيح الجديد. من هذه الصورة سيتم تشكيل صورة نهائية جديدة. سيحدث سلوك مماثل مع التغييرات في المراحل الأخرى.
وبالتالي ، فإن صور المرحلة هي ذاكرة التخزين المؤقت التي يمكن توزيعها ، ويتم تحميل صور الصور التي تم إنشاؤها بالفعل من ذلك في Docker Registry.
تنظيف السجل
لا يتعلق الأمر بحذف الطبقات التي تظل معلقة بعد العلامات المحذوفة - إنها ميزة قياسية في Docker Registry نفسه. هذا هو الموقف الذي تتراكم فيه الكثير من علامات Docker ونفهم أننا لم نعد بحاجة إلى بعض منها ، وأنها تشغل مساحة (و / أو ندفع ثمنها).
ما هي استراتيجيات التنظيف؟
- لا يمكنك تنظيف أي شيء. في بعض الأحيان يكون من الأسهل حقًا دفع القليل مقابل المساحة الإضافية بدلاً من كشف كرة ضخمة من العلامات. ولكن هذا يعمل فقط حتى نقطة معينة.
- إعادة تعيين كامل . إذا قمت بحذف جميع الصور وأعدت بناء الصور ذات الصلة فقط في نظام CI ، فقد تنشأ مشكلة. في حالة إعادة تشغيل الحاوية عند الإنتاج ، سيتم تحميل صورة جديدة لها - لم يتم اختبارها من قبل أي شخص حتى الآن. هذا يقتل فكرة البنية التحتية غير القابلة للتغيير.
- الأزرق والأخضر . بدأ أحد السجلات في تجاوز - تحميل الصور إلى آخر. نفس المشكلة كما في الطريقة السابقة: في أي نقطة يمكنك تنظيف السجل الذي بدأ في تجاوز السعة؟
- بمرور الوقت هل تريد حذف جميع الصور الأقدم من شهر واحد؟ ولكن من المؤكد أن هناك خدمة لم يتم تحديثها لمدة شهر ...
- تحديد ما يمكن حذفه يدويًا .
هناك خياران قابلان للتطبيق حقًا: لا تنظف أو تجمع بين الأزرق والأخضر + يدويًا. في الحالة الأخيرة ، نتحدث عن ما يلي: عندما تفهم أن الوقت قد حان لتنظيف السجل ، قم بإنشاء سجل جديد وإضافة جميع الصور الجديدة إليه ، على سبيل المثال ، لمدة شهر. بعد شهر ، تعرف على القرون الموجودة في Kubernetes التي لا تزال تستخدم السجل القديم ، وقم بنقلها إلى السجل الجديد أيضًا.
أين ذهبنا إلى
werf ؟ نحن نجمع:
- Git head: جميع العلامات ، وجميع الفروع ، - على افتراض أن كل شيء تم اختباره في Git ، نحتاجه في الصور (وإذا لم يكن الأمر كذلك ، نحتاج إلى الحذف في Git نفسه) ؛
- جميع القرون التي يتم تنزيلها الآن في Kubernetes ؛
- ReplicaSets القديمة (شيء تم ضخه مؤخرًا) ، وكذلك نخطط لمسح إصدارات Helm وتحديد أحدث الصور هناك.
... وننشئ قائمة بيضاء من هذه المجموعة - قائمة بالصور التي لن نحذفها. نقوم بتنظيف كل شيء آخر ، وبعد ذلك نجد الصور المسرحية اليتيمة ونحذفها أيضًا.
مرحلة النشر (النشر)
التصريح القوي
النقطة الأولى التي أود لفت الانتباه إليها في عملية النشر هي طرح تكوين الموارد المحدّث ، المصرح به. يختلف مستند YAML الأصلي الذي يصف موارد Kubernet دائمًا عن النتيجة التي تعمل بالفعل في الكتلة. لأن Kubernetes يضيف إلى التكوين:
- معرفات.
- معلومات الخدمة ؛
- العديد من القيم الافتراضية ؛
- القسم مع الوضع الحالي.
- التغييرات التي تم إجراؤها كجزء من webhook القبول ؛
- نتيجة عمل مختلف وحدات التحكم (وجدولة).
لذلك ، عندما يظهر تكوين جديد لمورد (
جديد ) ، لا يمكننا فقط أن نأخذ ونستبدل به التكوين الحالي "المباشر" (
مباشر ). للقيام بذلك ، يتعين علينا مقارنة
الجديد مع آخر تطبيق تم تطبيقه (
آخر تطبيق ) ولف التصحيح الناتج إلى
البث المباشر .
ويسمى هذا النهج
دمج 2-way . يتم استخدامه ، على سبيل المثال ، في هيلم.
هناك أيضًا
دمج ثلاثي الاتجاهات ، والذي يختلف في ذلك:
- مقارنة بين آخر تطبيق والجديد ، ونحن ننظر إلى ما تمت إزالته.
- مقارنة بين الجديد والحي ، نرى ما تمت إضافته أو تغييره ؛
- تطبيق التصحيح تلخيص للعيش .
نقوم بنشر أكثر من 1000 تطبيق باستخدام Helm ، لذلك نعيش في الواقع مع دمج ثنائي الاتجاه. ومع ذلك ، لديه عدد من المشكلات التي قمنا بحلها باستخدام تصحيحاتنا التي تساعد Helm على العمل بشكل طبيعي.
حالة التشغيل الفعلي
بعد الحدث التالي ، قام نظام CI الخاص بنا بإنشاء تكوين جديد لـ Kubernetes ، يقوم بتمريره ليتم
تطبيقه على نظام المجموعة باستخدام
kubectl apply Helm أو
kubectl apply . بعد ذلك ، يحدث دمج N-way الموصوف بالفعل ، حيث يوافق Kubernetes API على نظام CI ، ويستجيب الأخير لمستخدمه.
ومع ذلك ، هناك مشكلة كبيرة: بعد كل شيء ،
لا يعني التطبيق الناجح بدء التشغيل بنجاح . إذا أدركت Kubernetes التغييرات التي يجب تطبيقها ، فطبقها - لا نزال لا نعرف ماهية النتيجة. على سبيل المثال ، قد يكون تحديث القرون وإعادة تشغيلها في الواجهة الأمامية ناجحًا ، ولكن ليس في الواجهة الخلفية ، وسوف نحصل على إصدارات مختلفة من صور التطبيق الجاري تشغيلها.
للقيام بكل ما هو صواب ، ينشأ رابط إضافي في هذا المخطط - متتبع خاص سيتلقى معلومات الحالة من Kubernetes API ونقله لمزيد من التحليل للحالة الحقيقية للأشياء. أنشأنا مكتبة مفتوحة المصدر على Go -
kubedog (انظر إعلانها هنا ) - والتي تحل هذه المشكلة ومضمنة في werf.
يتم تكوين سلوك هذا المتعقب على مستوى werf باستخدام التعليقات التوضيحية التي يتم وضعها على عمليات النشر أو StatefulSets. الشرح الرئيسي ،
fail-mode ، يفهم المعاني التالية:
IgnoreAndContinueDeployProcess - تجاهل مشكلات IgnoreAndContinueDeployProcess لهذا المكون ومواصلة النشر ؛FailWholeDeployProcessImmediately - خطأ في هذا المكون توقف عملية النشر؛HopeUntilEndOfDeployProcess - نأمل أن يعمل هذا المكون بنهاية النشر.
على سبيل المثال ، مزيج من الموارد وقيم التعليق التوضيحي في
fail-mode :
عند النشر لأول مرة ، قد لا تكون قاعدة البيانات (MongoDB) جاهزة بعد - سوف تتعطل عمليات النشر. ولكن يمكنك الانتظار حتى اللحظة التي يبدأ فيها ، وسيظل النشر ساريًا.
هناك شروحان آخران لـ kubedog باللغة werf:
failures-allowed-per-replica - عدد القطرات المسموح بها لكل نسخة ؛show-logs-until - يضبط اللحظة التي يتم فيها تسجيل werf (في stdout) سجلات من جميع القرون التي يتم طرحها. بشكل افتراضي ، هذا هو PodIsReady (لتجاهل الرسائل التي لا نحتاج إليها عندما تبدأ حركة المرور في الوصول إلى EndOfDeploy ) ، ومع ذلك ، فإن القيم ControllerIsReady و EndOfDeploy أيضًا.
ماذا نريد من النشر؟
بالإضافة إلى النقطتين الموصوفتين بالفعل ، نود:
- لرؤية السجلات - والضرورية فقط ، ولكن ليس كل شيء ؛
- تتبع التقدم ، لأنه إذا كانت الوظيفة "صامتة" معلقة لعدة دقائق ، فمن المهم أن نفهم ما يحدث هناك ؛
- الاستعادة التلقائية في حالة حدوث خطأ ما (وبالتالي من الضروري معرفة الحالة الحقيقية للنشر). يجب أن تكون النسخة الذرية: إما أنها ستنتهي ، أو يعود كل شيء إلى حالته السابقة.
النتائج
كشركة ، بالنسبة لنا ، لتنفيذ جميع الفروق الدقيقة وصفها في مراحل مختلفة من التسليم (بناء ونشر ونشر) ، ونظام CI
والأداة المساعدة
werf كافية .
بدلاً من الاستنتاج:
بمساعدة werf ، أحرزنا تقدماً جيداً في حل عدد كبير من مشكلات مهندسي DevOps وسنكون سعداء إذا جرب المجتمع الأوسع هذه الأداة على الأقل في الممارسة العملية. سيكون تحقيق نتيجة جيدة معًا أسهل.
أشرطة الفيديو والشرائح
فيديو من الأداء (حوالي 47 دقيقة):
عرض التقرير:
PS
تقارير Kubernetes الأخرى على مدونتنا: