التحسين - واصل التحسّن

نظرة عامة على الوحدة

• إجراء مراجعات رشيقة (Agile retrospectives) لتحليل مجالات التحسين.
• تحسين أداء الشيفرة وتأمين سلسلة توريد البرمجيات.
• تنفيذ معمارية متعدّدة البيئات مع نظام تجميع السجلات لتحقيق القابلية للملاحظة.
• إعداد أتمتة الإصدار من البداية إلى النهاية واستكشاف النشر المستمر عبر GitOps وArgo CD.
• تنفيذ المشروع العملي التدريجي، HiveBox المرحلة 6.

6.1 التخطيط - المراجعة الرشيقة

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• بحكم تصميمه، صُمّم أجايل ليكون تكراريًّا. لذا من الضروري مراجعة ما سار على نحو جيد وما يمكن تحسينه.
• هنا تأتي المراجعة (Retrospective، وتُختصر أحيانًا بـ retro) بعد كل تكرار (أو بضعة تكرارات) للتعلّم من الماضي وتحسين المستقبل.
• يمكن القول إنّ «عقلية التحسّن المستمر» هي العامل الأهم في نجاح المراجعة. لا تذعر عند حدوث الأخطاء؛ بل اهدف فقط إلى تحسين عملياتك وسير عملك وأدواتك وتواصلك في كل تكرار.
• جانب مهم آخر هو أن تكون المراجعة بلا لوم. ينبغي أن تكون المراجعة مساحة آمنة للجميع، وينبغي أن يدور النقاش حول الأنظمة والأدوات والعمليات بدلًا من لوم الأفراد.
• من المهم أيضًا أن تكون مدفوعًا بالبيانات عبر استخدام المقاييس والأرقام بدلًا من مجرّد التخمين. إذا كانت هناك مشكلتان ينبغي معالجتهما لاحقًا، فينبغي أن تستند الأولوية إلى عوامل مثل عدد العملاء الذين سيستفيدون منها والوقت اللازم لإصلاحها مقارنةً بأثرها.
• في نهاية المراجعة، ينبغي أن تكون هناك نتائج قابلة للتنفيذ؛ فبدون التوصل إلى تحسينات محدّدة، تكون المراجعة كلها بلا قيمة! وأخيرًا، تذكّر أنّ المراجعة لا تتعلّق بالأمور السيئة فقط؛ بل هي أيضًا وقت للاحتفال بالنجاحات والإشادة بالإنجازات والسلوكات الإيجابية.

المصادر

• Sprint Retrospective: How to Hold an Effective Meeting - Atlassian

6.2 البرمجة - تحسين الأداء

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• بصراحة، في معظم الأحيان لا يحتاج مهندسو DevOps إلى كتابة شيفرة فائقة التحسين. ينبغي أن تكون الشيفرة عالية الجودة، لكننا في الغالب لا نحتاج إلى استنفاد كل جزء منها، لذا لن نتعمّق في «ترميز Big O» هنا. في المقابل، الشيفرة غير الفعّالة غير مرغوبة، لذا عليك تعلّم أساسيات تحسين الأداء.
• أولًا وقبل كل شيء، تجنّب التحسين المبكّر (Premature Optimization)! فتحسين الشيفرة مبكرًا جدًّا يؤدّي عادةً إلى حلول معقّدة غير ضرورية وإهدار الكثير من الوقت دون عائد جيد. ركّز أولًا على حالات الاستخدام الحرجة فقط، ثم حسّن بناءً على مشكلات الأداء الفعلية كلما تقدّمت.
• إذا عرفت من البداية أنك تحتاج إلى حل عالي الأداء، فابدأ بلغة برمجة أو إطار عمل معروف بذلك. ستوفّر جهدًا كبيرًا إن اخترت الأداة الصحيحة مبكرًا. واتّبع أيضًا أفضل ممارسات اللغة المختارة لتحسين الأداء.
• من الطرق البسيطة لتحسين أداء الشيفرة التخزين المؤقّت (Caching). استخدمه كلما أمكن على جميع المستويات، مثل التخزين المؤقّت لقاعدة البيانات، والتخزين المؤقّت في الذاكرة عبر Valkey أو Memcached كطبقة تخزين مؤقّت، وحتى التخزين المؤقّت لـ DNS الذي قد يوفّر عليك الكثير من الطلبات غير الضرورية (وقد يكون التخزين المؤقّت الخارجي مفيدًا أيضًا، مثل استخدام شبكة توصيل المحتوى «CDN» لتخزين المحتوى الساكن مؤقّتًا).
• وباتّباع مفهوم التخزين المؤقّت نفسه، حاول تقليل نداءات واجهات البرمجة الخارجية. فأسرع طلب هو الطلب الذي لم يُرسل أبدًا!
• تجنّب العمليات المملّة مثل نداء دالة بشكل متكرّر بينما يمكن نداؤها مرة واحدة خارج الحلقة. وكقاعدة عامة، ينبغي أن يكون أي شيفرة لا تتغيّر بين التكرارات خارج الحلقة.
• أخيرًا، إن احتجت إلى التعمّق أكثر وتحسين شيفرتك (مجددًا، إن لزم الأمر)، فإنّ أدوات التحليل (Profiling) هي أفضل صديق لك.

المصادر

• Optimizing Performance: Tips for Speeding Up Your Applications - SkillReactor
• Programming Optimization - Codecademy

6.3 التكامل المستمر - أمن سلسلة توريد البرمجيات

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• كما ذُكر في بداية خارطة الطريق هذه، فإنّ الأمان مدمج في كل قسم ولا يُعامَل كموضوع منفصل. ومع ذلك، فإنّ أمن سلسلة توريد البرمجيات من أكبر التهديدات للبرمجيات الحديثة. لذا من المهم تناوله بمزيد من التفصيل، خاصةً من منظور الأمان المستمر.

• يشير أمن سلسلة توريد البرمجيات (Software Supply Chain Security) إلى المخاطر والثغرات التي تُدخَل عبر البرمجيات الخارجية والاعتماديات والأدوات والعمليات المتضمّنة في تطوير البرمجيات وبنائها ونشرها وصيانتها.

• إنّ تطبيق ممارسات أمان سليمة في كل خطوة من خطوات إنتاج البرمجيات ودورة حياة تطوير البرمجيات (SDLC) يقلّل من خطر الثغرات والاختراق.

• فيما يلي أهم الممارسات التي يمكن تضمينها في خطوط أنابيب التكامل المستمر:

  • بدءًا من التطوير، ينبغي توقيع كل التزام Git حتى يتمكّن الآخرون من التأكّد من أنّ التغييرات تأتي من مصدر موثوق.
  • افحص الشيفرة بحثًا عن الأسرار والبيانات الحسّاسة لضمان عدم تخزين أيّ شيء عن طريق الخطأ في مستودع Git.
  • أعدّ أداة SBOM للإبلاغ عن جميع المكوّنات والمكتبات والاعتماديات المستخدمة في برمجيتك.
  • حافظ على تحديث اعتماديات الشيفرة باستخدام أدوات مثل Dependabot.
  • استخدم دائمًا إصدارات غير قابلة للتغيير، مثل تثبيت commit hash بدلًا من الإصدارات القابلة للتغيير مثل tags. (ستتولّى أدوات الاعتماديات مثل Dependabot عملية التحديث).
  • شغّل اختبار أمن التطبيقات الساكن (Static Application Security Testing — SAST) على شيفرتك باستخدام أدوات مثل SonarQube.
  • افحص Dockerfile وصورة الحاوية باستخدام Grype أو Docker Scout.
  • حالما تبني صورة الحاوية وتفحصها، وقّعها باستخدام Cosign لضمان ألّا يستطيع أحد التلاعب بها.
  • قبل الإصدار والنشر، افحص البنية التحتية كشيفرة (IaC) مثل ملفات Terraform وبيانات Kubernetes الوصفية باستخدام Terrascan (واستخدم أيضًا أدوات فحص ملفات K8s مثل KubeLinter).

• هناك ممارسات وأدوات أخرى كثيرة، لكن ما ذُكر يُعدّ الحدّ الأدنى. عمومًا، تبنَّ أمن الإزاحة إلى اليسار (Shift Left Security) بحيث تشغّل فحوصات الأمان مبكرًا في عملية التطوير لاكتشاف الثغرات في أقرب وقت ممكن.

• أخيرًا، احرص دائمًا على أن يكون جميع أعضاء الفريق على دراية بأفضل ممارسات الأمان؛ فعادةً ما يكون العامل البشري هو الحلقة الأضعف في سلسلة الأمان!

المصادر

• What is software supply chain security? - Red Hat
• The Complete Guide to Software Supply Chain Security - FOSSA

6.4 البنية التحتية - معمارية متعدّدة البيئات

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• ما لم تختبر في بيئة الإنتاج (وهو أمر سيئ حقًّا)، فإنّ واحدة من المهام الشائعة لمهندس DevOps هي بناء بيئات متعدّدة لحلك. وعادةً ما تكون بين 2 و4 بيئات مثل التطوير والاختبار والتهيئة (staging) والإنتاج.

• بدءًا من إدارة المصدر، توجد للشيفرة أنماط كثيرة لإدارة معمارية متعدّدة البيئات. والنمط الشهير (لكنه يُعدّ الآن قديمًا) هو Gitflow، والآن التطوير القائم على الجذع (Trunk-based development)، حيث يكون لديك فرع واحد طويل الأجل (main) وفروع ميزات قصيرة الأجل كثيرة. من المهم أن تقرّر أيّ نموذج تفريع ستستخدمه لأنّه سيؤثّر في كيفية بنائك للمعمارية متعدّدة البيئات.

• بالنسبة لشيفرة البنية التحتية، تجنّب التفريع واستخدم بنية مسطّحة حيث تُمثَّل جميع البيئات كأدلّة بدلًا من فروع.

• بعد ذلك، عليك التفكير في عزل البيئات. من الناحية المثالية، ينبغي أن تكون البيئات معزولة تمامًا، لكنها قد لا تكون كذلك لأسباب كثيرة! على سبيل المثال، ترغب شركات ناشئة كثيرة في التحرّك بسرعة وتفتقر إلى الموارد البشرية لفعل ذلك بشكل صحيح أو حتى لتوفير التكاليف.

• التوازن بين العزل والتكلفة جوهري. فمستويات العزل الأعلى تعني تكاليف أعلى، لذا عليك مراجعة جميع الخيارات واتّخاذ قرار مدروس قبل الانتقال إلى العزل الكامل. وإلا فقد تحرق ميزانيتك بسهولة دون عائد كبير على الاستثمار.

• أهم نصيحة هنا: عندما تقرّر إنشاء معمارية متعدّدة البيئات، احرص على إنشاء أساس مشترك وتوسيعه. لا تستخدم بيئة واحدة، خاصةً بيئة الإنتاج، كأساس.

• وأيضًا، حالما تقرّر المضي في تبنّي البيئات المتعدّدة، ستحتاج حتمًا إلى تبنّي البنية التحتية كشيفرة (IaC)؛ وإلا سيكون من الصعب إدارتها. وينطبق ذلك على Terraform وKubernetes.

• حاول دائمًا تقليل انحراف البيئات (Environment Drift)، أي ينبغي أن تكون جميع البيئات أقرب ما يمكن إلى بعضها. وقد حسّنت ثورة الحاويات ذلك كثيرًا، إذ يمكنك تشغيل البرمجيات نفسها بسهولة، لكنّ البنية التحتية ليست مجرّد حاويات.

• بالطبع ستكون هناك فروق بين البيئات، لكنّ أهمّ اثنتين هما التهيئة (staging) والإنتاج. ينبغي أن تكون بيئة التهيئة نسخة مصغّرة من بيئة الإنتاج حتى تتمكّن من اكتشاف أيّ أخطاء مبكرًا قبل عملائك.

• مراقبة البيئات المتعدّدة وقابليتها للملاحظة أمر لا بدّ منه، ليس للسجلات والمقاييس فحسب بل للتكاليف والنفقات أيضًا.

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

المصادر

• Comparing Git workflows: What you should know - Atlassian
• How to Manage Multiple Terraform Environments Efficiently - Spacelift
• Multi-tenancy - Kubernetes

6.5 الحاويات - مشغّلات Kubernetes

الجمهور

الجمهور المستهدف: أدوار DevOps

ما تحتاج إلى معرفته

• كما ذُكر في الوحدات السابقة، يُعدّ Kubernetes من أفضل الاختراعات التقنية في العقد الأخير، إذ أعاد تشكيل المشهد التقني بأكمله. قبل Kubernetes، كانت عمليات البنية التحتية غير موحّدة وشهدت إعادة اختراع كثيرة للعجلة.
• يأتي Kubernetes بمجموعة من الأوليات المدمجة مثل Pod وDeployment وConfigMap، والأهم من ذلك StatefulSet. ومع ذلك، فإنّ دعم Kubernetes للحالة (Stateful) عام، لذا يصعب تشغيل التطبيقات التي تحتفظ بحالة والتطبيقات المعقّدة مثل قواعد البيانات والأنظمة الموزّعة دون عمل إضافي كثير.
• لكن أحد الجوانب الرائعة في Kubernetes هو قابلية التوسّع. فبحكم تصميمه، يمكنك إدخال منطق جديد إلى Kubernetes للتعامل مع أحمال عمل محدّدة تحتفظ بحالة؛ على سبيل المثال، يمكنك أن يكون لديك نوع (kind) جديد للتعامل مع PostgreSQL، ليس في الإعداد فقط بل في عمليات اليوم الثاني (day-2) مثل النسخ الاحتياطي والترقية. ويُسمّى نمط التوسّع هذا Operator (المشغّل).
• إذن، ما هي مشغّلات Kubernetes في النهاية؟ ولماذا نحتاج إليها؟

  المشغّلات هي امتدادات برمجية لـ Kubernetes تستخدم موارد مخصّصة لإدارة التطبيقات ومكوّناتها. وهدف المشغّل هو تجسيد المعرفة المجالية في البرمجيات بما يساعد على تبسيط إدارة التطبيقات المعقّدة على Kubernetes.

• وبالتالي، فإنّ المشغّل هو ببساطة وحدة تحكّم (controller) تراقب أحداث مورد مخصّص (custom resource) في واجهة Kubernetes البرمجية وتتّخذ إجراءات بناءً على منطق المشغّل.

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

• يُعرَّف هذا المنطق في Kubernetes عبر تعريفات الموارد المخصّصة (Custom Resource Definitions — CRDs) التي توسّع واجهة Kubernetes البرمجية لتضمين أنواع موارد جديدة يمكن للمشغّل إدارتها. ويمكنك سرد الـ CRDs في عنقودك بتشغيل kubectl get customresourcedefinitions.
• ليست كل المشغّلات متشابهة! فقد تكون لها مستويات قدرة مختلفة. وهناك خمسة مستويات لنضج المشغّل:
  • التثبيت الأساسي: يتعامل مع التثبيت.
  • الترقيات السلسة: يدير ترقيات التطبيق.
  • دورة الحياة الكاملة: ينفّذ التوسّع التلقائي والنسخ الاحتياطي وغيرها.
  • الرؤى العميقة: يوفّر المراقبة والتنبيهات.
  • الطيار الآلي: إدارة مؤتمتة بالكامل.
• من المصادر الجيدة لمزيد من المشغّلات OperatorHub.io؛ فهو يضم أكثر من 350 مشغّلًا.
• ستستخدم غالبًا مشغّلًا موجودًا. ولست بحاجة إلى تطوير مشغّل بنفسك. ومن المشغّلات الشائعة Prometheus وExternalDNS وCert-Manager.
• أخيرًا، لا تحتاج في البداية إلى معرفة كثير عن التفاصيل الداخلية لمشغّلات Kubernetes، لكن ينبغي بالتأكيد أن يكون لديك فهم جيد لهذا المفهوم لأنها ستعمل في عنقودك.

المصادر

• What is an Operator? - OperatorHub
• How to explain Kubernetes Operators in plain English - The Enterprisers Project
• Operator pattern - Kubernetes Docs
• Operator Capability Levels - Operator SDK

6.6 التسليم المستمر - أتمتة الإصدار من البداية إلى النهاية

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• قبل الغوص في النشر المستمر، نحتاج إلى إلقاء نظرة على أتمتة الإصدار من البداية إلى النهاية في التسليم المستمر، وهي عملية إنتاج منتجات جاهزة للنشر.
• في الواقع، هناك أنواع كثيرة للإصدار، لكن يمكن حصرها في نوعين: الإصدار المُرقَّم (Versioned release) والإصدار المتدحرج (Rolling release).
• في الإصدار المُرقَّم، تُصدر مُخرَجًا بإصدار محدّد مثل 1.0.0. وتُعدّ الإصدارة الدلالية (Semantic Versioning) من أشهر أنماط الإصدار، لكنها ليست الوحيدة. وينبغي أن يرقّي المستخدمون عن قصد إلى الإصدار الجديد إن احتاجوا إلى أحدث التحديثات. وهذا النوع شائع في شيفرة التطبيقات، خاصةً إن كان لديك مستهلكون خارجيون.
• في الإصدارات المتدحرجة، تُصدر مُخرَجًا بعلامة مثل تجزئة Git أو حتى اسم فرع، يعمل كمَرجع أو مؤشّر فقط. وسيحصل المستخدمون دائمًا على أحدث التحديثات في أيّ وقت. وهذا النوع شائع في البنية التحتية كشيفرة، خاصةً للاستخدام الداخلي.
• من الصعب القول إنّ أحدهما أفضل من الآخر؛ فلكل منهما مزايا وعيوب وحالات استخدام موصى بها.
• في كلا النمطين، هناك بضعة أمور عليك تذكّرها:
  • جودة الإصدار هي نفسها جودة خط أنابيب التكامل المستمر. اتّبع أفضل ممارسات التكامل المستمر وأضف جميع بوابات الجودة القياسية.
  • ينبغي أن يتمّ كل شيء في إدارة الإصدارات. فلا ينبغي أن يحدث أيّ سحر خارج مستودع Git.
  • تأكّد من وجود المُخرَج في بيئة واحدة على الأقل للمستهلكين قبل أن يُطلق.
  • تعلّم استراتيجيات التراجع (Rollback) والتقدّم (Rollforward) للتعامل مع الإصدارات الفاشلة.
  • ولّد سجلّ التغييرات (changelog) أو ملاحظات الإصدار بناءً على التزامات Git. والالتزامات التقليدية (Conventional Commits) شهيرة في التطبيقات، وأبقِ سجلّ تغييرات (Keep a Changelog) شائع في البنية التحتية كشيفرة. وهناك أدوات كثيرة لأتمتة هذه الخطوة بغضّ النظر عن عُرف التزام Git الذي تستخدمه (مثل git-cliff).
  • أتمت مهام الإصدار وترقيات الإصدار باستخدام أدوات مثل release-please وrelease-it.
  • للأمان، وقّع المُخرَجات باستخدام Sigstore/Cosign عبر التوقيع بلا مفاتيح (keyless signing) السهل.
  • حاول دائمًا استخدام صيغة مُخرَج حديثة مثل OCI (حيث تُخزَّن جميع المُخرَجات بصيغة صورة حاوية)، خاصةً في البنية التحتية كشيفرة مثل مخططات Helm ووحدات Terraform. وهناك أدوات كثيرة لذلك، مثل ORAS.

المصادر

• Continuous integration vs. delivery vs. deployment - Atlassian
• Building an Efficient Release Management Process - Split
• Helm chart keyless signing with Sigstore/Cosign - Ahmed AbouZaid

6.7 النشر المستمر - مقدّمة وحلول في السوق

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• بعبارة بسيطة، النشر المستمر (Continuous Deployment) ممارسة جزء من خط أنابيب CI/CD يُنشر فيه مُخرَج الشيفرة بانتظام إلى بيئات مختلفة تلقائيًّا أو شبه تلقائي.

• لا تخلط بين النشر المستمر والتسليم المستمر؛ فقد غُطّي جزء التسليم في الأقسام/الوحدات السابقة.

• الهدف الرئيسي للنشر المستمر (CD) هو تقصير دورات النشر إلى الإنتاج والنشر بثقة.

• بصراحة، ولأنّ النشر المستمر هو آخر خطوة في خط الأنابيب، فإنّ شركات كثيرة لا تملك نشرًا مستمرًّا مؤتمتًا بنسبة 100%. ولأسباب كثيرة، يُفضَّل إجراء خطوة يدوية واحدة على الأقل بموافقة بشرية، خاصةً قبل النشر إلى بيئة الإنتاج. واستهداف خط نشر مستمر مؤتمت بنسبة 90% أكثر من كافٍ في معظم الحالات.

• من الممارسات الشائعة (وليست بالضرورة جيدة) في السوق استخدام أدوات التكامل المستمر للنشر المستمر، مثل GitHub Actions وJenkins. ومع ذلك، فإنّ المقاربة الأفضل عادةً هي استخدام أداة مخصّصة للنشر المستمر.

• هناك نموذجان شائعان للنشر المستمر: نموذج الدفع (Push Model) ونموذج السحب (Pull Model). في نمط الدفع، يحصل نظام النشر المستمر على مُخرَجات الشيفرة ويدفع التحديث إلى البيئة الهدف (مثل خوادم الإنتاج أو عناقيد Kubernetes). أما في نمط السحب، فيعمل نظام النشر المستمر داخل البيئة الهدف ويكتشف التغييرات في مُخرَجات الشيفرة وينشر التحديثات في تلك البيئة (وهذا النمط أكثر شيوعًا في منظومة Kubernetes).

• هناك أنواع كثيرة للنشر المستمر، مثل النشر المتدحرج (Rolling) والأزرق-الأخضر (Blue-Green) والكناري (Canary).

• توجد أنظمة نشر مستمر مختلفة مثل Argo CD وFlux CD وغيرها.

• من الأفضل استخدام نظام نشر مستمر أصلي للسحابة (Cloud-Native)، لكن عمومًا لا يهمّ النظام ما دمت تفهم مبادئ النشر المستمر وممارساته.

المصادر

• Continuous integration vs. delivery vs. deployment - Atlassian
• Continuous Delivery vs Continuous Deployment: Core Differences - BrowserStack

6.8 النشر المستمر - أساسيات GitOps وArgo CD

الجمهور

الجمهور المستهدف: أدوار DevOps

ما تحتاج إلى معرفته

• مع نموّ شعبية CI/CD وتحوّله إلى معيار صناعي، ظهرت حلول نشر مستمر أكثر تخصّصًا (مثل Argo CD)، واستُحدثت ممارسات حديثة (مثل GitOps).
• لنبدأ بـ GitOps:
  • إنه مقاربة حديثة لإدارة البنية التحتية ونشر التطبيقات بطريقة تصريحية. وهي ممارسة مهمة في النشر المستمر.
  • يستخدم Git كـ مصدر حقيقة وحيد (Single Source of Truth). فلا ينبغي إجراء أيّ عمل يدوي غير متتبَّع خارج Git، وينبغي تتبّع جميع التغييرات عبر Git.
  • يعتمد أساسًا على النمط التصريحي (Declarative Style) للبنية التحتية كشيفرة، حيث تُوصَف التهيئات باعتبارها الحالة المرغوبة، وتتولّى بعض الأنظمة (مثل Kubernetes) جعل الحالة الفعلية مطابقة لتلك الحالة المرغوبة. ولا يزال النمط الأمرِي (Imperative Style) قابلاً للاستخدام في بعض الحالات، لكنه غير موصى به.
  • تراقب أدوات GitOps مثل Argo CD مستودع Git باستمرار وتكتشف أيّ انحراف، ويحاول النظام مواءمة الحالة مع الحالة المرغوبة.
• وننتقل إلى Argo CD:
  • إنه من الأدوات التي تستخدم مقاربة GitOps لتطبيق النشر المستمر.
  • إنه أصلي لـ Kubernetes (يعمل على Kubernetes فقط) ويستخدم نموذج السحب لتطبيق التغييرات.
  • يمكنك استخدام Argo CD لنشر مخطط Helm أو مورد Kustomize أو بيانات Kubernetes الوصفية العادية (اقرأ المزيد عن إدارة تهيئة Kubernetes).
  • وكمعظم أدوات GitOps (إن لم يكن كلها)، يستخدم في جوهره نمطًا تصريحيًّا لنشر أيّ برمجية على Kubernetes عبر كائن Application في Argo CD.
  • ورغم أنّه يُوصى باستخدام البيانات الوصفية التصريحية للتفاعل مع Argo CD، فلا يزال من الممكن استخدام واجهته. وبالطبع، فإنّ إجراء أيّ تغييرات على الطائر من هناك مخالف لمقاربة GitOps (تجنّب فعل ذلك حقًّا).
  • لدى Argo CD إضافات مفيدة كثيرة، ويمكنك حتى كتابة إضافتك الخاصة من نص برمجي بسيط أو شيفرة متقدّمة أو حتى أداة نشرك. لكن قبل كتابة واحدة، تأكّد من أنها غير موجودة بالفعل.

المصادر

• GitOps Continuous Deployment for cloud native applications - GitOps.tech
• Argo CD Best Practices - Argo CD Docs

الاختبار

التطبيق العملي

اتبع التعليمات في المرحلة 6 من مشروع HiveBox.

أسئلة المقابلات

راجع أسئلة المقابلات المتعلّقة بـ الوحدة 6.