تحرير

Share via

CI/CD لتطبيقات AKS باستخدام GitHub Actions وGitFlow

Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Monitor
Azure Pipelines

GitOps هو نموذج تشغيل للتطبيقات السحابية الأصلية التي تخزن التعليمات البرمجية للتطبيق والبنية الأساسية التعريفية في Git لاستخدامها كمصدر للحقيقة للتسليم المستمر التلقائي. باستخدام GitOps، يمكنك وصف الحالة المطلوبة لنظامك بأكمله في مستودع git، وينشره عامل تشغيل GitOps في بيئتك، والتي غالبا ما تكون مجموعة Kubernetes. لمزيد من المعلومات حول GitOps ل Kubernetes على Azure، تفضل بزيارة GitOps لخدمة Azure Kubernetes Service أو CI/CD وGitOps مع Kubernetes الممكنة في Azure Arc.

ينطبق السيناريو المثال في هذه المقالة على الشركات التي تريد تحديث تطوير التطبيقات من طرف إلى طرف باستخدام الحاويات والتكامل المستمر (CI) للبناء وGitOps للتوزيع المستمر (CD). في هذا السيناريو، يتم استخدام تطبيق Flask كمثال. يتكون تطبيق الويب هذا من واجهة أمامية مكتوبة باستخدام Python وإطار عمل Flask.

البنية

تستكشف الخيارات التالية نهج CI/CD المستندة إلى الدفع والسحب.

الخيار 1: CI/CD المستند إلى الدفع

Diagram of the push-based architecture with GitHub Actions.

البنية المستندة إلى الدفع مع إجراءات GitHub ل CI وCD.

قم بتنزيل ملف Visio لهذه البنية.

تدفق البيانات

يغطي هذا السيناريو البنية الأساسية لبرنامج ربط العمليات التجارية DevOps المستندة إلى الدفع لتطبيق ويب من طبقتين، مع مكون ويب أمامي وواجهة خلفية تستخدم Redis. يستخدم هذا المسار إجراءات GitHub للبناء والنشر. البيانات تتدفق عبر السيناريو كما يلي:

  1. تم تطوير التعليمات البرمجية للتطبيق.
  2. تلتزم التعليمات البرمجية للتطبيق بمستودع GitHub git.
  3. تنشئ GitHub Actions صورة حاوية من التعليمات البرمجية للتطبيق وتدفع صورة الحاوية إلى Azure Container Registry.
  4. تقوم مهمة GitHub Actions بنشر التطبيق أو دفعه، كما هو موضح في ملفات البيان، إلى نظام مجموعة Azure Kubernetes Service (AKS) باستخدام kubectl أو إجراء التوزيع إلى نظام مجموعة Kubernetes.

الخيار 2: سحب CI/CD (GitOps)

Diagram of the pull-based architecture with GitHub Actions and Argo CD.

بنية مستندة إلى السحب مع GitHub Actions ل CI و Argo CD للقرص المضغوط.

قم بتنزيل ملف Visio لهذه البنية.

تدفق البيانات

يغطي هذا السيناريو مسار DevOps المستند إلى السحب لتطبيق ويب من طبقتين، مع مكون ويب أمامي وواجهة خلفية تستخدم Redis. يستخدم هذا المسار إجراءات GitHub للبناء. للنشر، يستخدم Argo CD كعامل تشغيل GitOps لسحب/مزامنة التطبيق. البيانات تتدفق عبر السيناريو كما يلي:

  1. تم تطوير التعليمات البرمجية للتطبيق.
  2. تلتزم التعليمات البرمجية للتطبيق بمستودع GitHub.
  3. تنشئ GitHub Actions صورة حاوية من التعليمات البرمجية للتطبيق وتدفع صورة الحاوية إلى Azure Container Registry.
  4. تقوم إجراءات GitHub بتحديث ملف نشر بيان Kubernetes مع إصدار الصورة الحالي استنادا إلى رقم إصدار صورة الحاوية في سجل حاويات Azure.
  5. يتزامن Argo CD مع مستودع Git أو يسحب منه.
  6. ينشر Argo CD التطبيق إلى نظام مجموعة AKS.

المكونات

  • GitHub Actions هو حل أتمتة يمكن أن يتكامل مع خدمات Azure للتكامل المستمر (CI). في هذا السيناريو، تنسق GitHub Actions إنشاء صور حاوية جديدة استنادا إلى الالتزامات بالتحكم في المصدر، وتدفع هذه الصور إلى Azure Container Registry، ثم تحدث ملفات بيان Kubernetes في مستودع GitHub.
  • Azure Kubernetes Service (AKS) هي منصة Kubernetes مدارة تتيح لك نشر التطبيقات المعبأة في حاويات وإدارتها دون خبرة في تنسيق الحاوية. بصفتها خدمة مستضافة من Kubernetes، فقد تتولى Azure المهام الحرجة، مثل مراقبة الصحة وصيانتها.
  • يخزن Azure Container Registry صور الحاوية التي تستخدمها مجموعة AKS ويديرها. تُخزن الصور بشكل آمن، ويمكن نسخها نسخًا متماثلًا إلى مناطق أخرى بواسطة نظام Azure الأساسي لتسريع أوقات التوزيع.
  • GitHub هو نظام تحكم بالمصادر يستند إلى الويب يعمل على Git ويستخدمه المطورون لتخزين التعليمات البرمجية للتطبيق وإصدارها. في هذا السيناريو، يتم استخدام GitHub لتخزين التعليمات البرمجية المصدر في مستودع Git، ثم يتم استخدام إجراءات GitHub لتنفيذ إنشاء ودفع صورة الحاوية إلى Azure Container Registry في النهج المستند إلى الدفع.
  • Argo CD هو عامل تشغيل GitOps مفتوح المصدر يتكامل مع GitHub وAKS. يدعم Argo CD النشر المستمر (CD). كان يمكن استخدام Flux لهذا الغرض، ولكن يعرض Argo CD كيف يمكن لفريق التطبيق اختيار أداة منفصلة لمخاوف دورة حياة التطبيق المحددة الخاصة بهم، مقارنة باستخدام نفس الأداة التي يستخدمها مشغلو نظام المجموعة لإدارة نظام المجموعة.
  • تساعدك خدمةAzure Monitor على تعقب الأداء والحفاظ على الأمان وتحديد الاتجاهات. يمكن استخدام المقاييس التي تم الحصول عليها بواسطة Azure Monitor بواسطة موارد وأدوات أخرى، مثل Grafana.

البدائل

  • تساعدك Azure Pipelines على تنفيذ CI/DC واختبار البنية الأساسية لبرنامج ربط العمليات التجارية لأي تطبيق.
  • Jenkins هو خادم أتمتة مفتوح المصدر يمكنه التكامل مع خدمات Azure ل CI/CD.
  • يمكن استخدام Flux كعامل تشغيل GitOps. يمكنه تنفيذ نفس المهام مثل Argo CD ويعمل بنفس الطريقة مع AKS.

تفاصيل السيناريو

في هذا السيناريو، يستخدم الإنشاء التلقائي لتطبيقك ونشره العديد من التقنيات. يتم تطوير التعليمات البرمجية في VS Code وتخزينها في مستودع GitHub. يتم استخدام إجراءات GitHub لإنشاء التطبيق كحاوية، ثم دفع صورة الحاوية إلى Azure Container Registry. تستخدم إجراءات GitHub لتحديث ملف نشر بيان Kubernetes الضروري، المخزن أيضا في مستودع Git، بينما يلتقط مشغل GitOps Argo CD ملفات بيان Kubernetes من هناك وينشر التطبيق إلى نظام مجموعة AKS.

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

باستخدام خدمات Azure وGitHub مثل AKS و Container Registry وGitHub وGitHub Actions، يمكن للشركات استخدام أحدث تقنيات وأدوات تطوير التطبيقات لتبسيط عملية تنفيذ قابلية الوصول العالية. أيضا، باستخدام تقنيات مفتوحة المصدر، مثل Flux أو Argo CD ل GitOps، تبسط الشركات النشر وتفرض الحالة المطلوبة للتطبيقات.

حالات الاستخدام المحتملة

وتشمل حالات الاستخدام الأخرى ذات الصلة ما يلي:

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

خيارات CI/CD

يعرض هذا المستند استخدام GitOps لنهج حديث للتعامل مع النشر المستمر في البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD. ومع ذلك، فإن كل مؤسسة مختلفة. عند توزيع التطبيقات على مجموعات Kubernetes من خلال مسارات التسليم التلقائية، من المهم فهم الطرق المختلفة التي يمكن القيام بها.

الخياران الأكثر شيوعا ل CI/CD لنشر تطبيق إلى نظام مجموعة AKS هما قائمان على الدفع والسحب. يستخدم خيار الدفع إجراءات GitHub للتوزيع المستمر ويستخدم خيار السحب GitOps للتوزيع المستمر.

الخيار 1: البنية المستندة إلى الدفع مع إجراءات GitHub ل CI وCD

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

أسباب استخدام نهج قائم على الدفع:

  • المرونة: تعمل معظم عوامل تشغيل GitOps حاليا فقط في Kubernetes. إذا كانت مؤسستك تريد نشر التطبيقات إلى أي شيء آخر غير Kubernetes، فستحتاج إلى دفع التطبيق إلى تلك البيئة عبر أدوات CI/CD أخرى مثل GitHub Actions.

  • الكفاءة: يعد النهج الموحد لنشر تطبيقاتك الأصلية والتقليدية على السحابة أكثر كفاءة. حاليا، GitOps هو الأنسب للتطبيقات الأصلية على السحابة التي تعمل على Kubernetes.

  • البساطة: CI/CD المستند إلى الدفع معروف جيدا بين أوسع مجموعة من المهندسين في العديد من المؤسسات. قد يكون النهج القائم على الدفع أبسط من مزيج من نهج CI/CD المستندة إلى الدفع والمستندة إلى السحب.

  • البنية: قد لا تكون بنية المستودع الحالية المستخدمة لتطبيقك مناسبة تماما ل GitOps، ما يعني أنه سيكون من الضروري التخطيط وإعادة الهيكلة بشكل كبير لتناسب GitOps.

الخيار 2: بنية مستندة إلى السحب مع إجراءات GitHub ل CI وGitOps عامل تشغيل Argo CD للقرص المضغوط

يركز هذا النهج على تطبيق أي تغييرات من داخل مجموعة Kubernetes. يتضمن نظام مجموعة Kubernetes عامل تشغيل يفحص مستودع git للحالة المطلوبة للمجموعة، ويلتقط ويطبق أي تغييرات تحتاج إلى إجراء. في هذا النموذج، لا يوجد عميل خارجي لديه بيانات اعتماد على مستوى المسؤول إلى مجموعة Kubernetes. نموذج السحب ليس جديدا ولكن لم يتم استخدامه على نطاق واسع من قبل أدوات CI/CD. في الآونة الأخيرة، مع إدخال GitOps، أصبح نموذج السحب يكتسب الاعتماد. تستخدم العديد من المؤسسات GitOps لتسهيل النشر المستمر في مسارات CD/CD الخاصة بها.

أسباب استخدام نهج قائم على السحب:

  • الاتساق: باستخدام GitOps، يقارن عامل التشغيل حالة مجموعات Kubernetes بالحالة المطلوبة للتكوين والتطبيقات في مستودع git. إذا كان هناك أي انحراف إلى التكوين أو التطبيقات، فإن عامل تشغيل GitOps يعيد مجموعة Kubernetes إلى الحالة المطلوبة تلقائيا.

  • الأمان: يسمح لك النهج القائم على السحب ل CI/CD باستخدام GitOps بتحويل بيانات اعتماد الأمان إلى مجموعة Kubernetes، ما يقلل من سطح الأمان والمخاطر عن طريق إزالة بيانات الاعتماد من تخزينها في أدوات CI الخارجية. ستتمكن أيضا من تقليل الاتصالات الواردة المسموح بها والحد من الوصول على مستوى المسؤول إلى مجموعات Kubernetes.

  • تعيين الإصدار: نظرا لأن GitOps يستخدم مستودع git كمصدر للحقيقة، فإن النشر المستمر الخاص بك يحتوي بطبيعته على قدرات تعيين الإصدار والتراجع والتدقيق.

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

  • السحابة الأصلية: يتم تحديث المزيد من التطبيقات أو إنشاؤها لتكون أصلية على السحابة. بالنسبة لأي مؤسسة لديها معظم تطبيقاتها قيد التشغيل في Kubernetes، فإن استخدام عامل تشغيل GitOps للتوزيع المستمر أبسط وأكثر كفاءة من النهج التقليدي القائم على الدفع ل CI/CD.

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

الموثوقيه

تضمن الموثوقية أن التطبيق الخاص بك يمكن أن يفي بالالتزامات التي تتعهد بها لعملائك. لمزيد من المعلومات، يرجى مراجعة نظرة عامة على ركيزة الموثوقية.

لمراقبة أداء التطبيق الخاص بك والإبلاغ عن المشكلات، يستخدم هذا السيناريو Azure Monitor. يتيح لك مراقبة واستكشاف مشكلات الأداء التي قد تتطلب تحديثات التعليمات البرمجية، والتي يمكن نشرها بعد ذلك باستخدام مسار CI/CD.

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

إشعار

لا تتناول هذه المقالة التوفر العالي لمسار CI/CD مباشرة. لمزيد من المعلومات، تفضل بزيارة قابلية الوصول العالية ل GitHub Actions و Argo CD التعريفي GitOps CD ل Kubernetes.

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

للحصول على إرشادات عامة حول تصميم سيناريوهات مرنة، راجع تصميم تطبيقات Azure الموثوقة.

الأمان

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

لفصل بيانات الاعتماد والأذونات، يستخدم هذا السيناريو كيان خدمة Microsoft Entra مخصصا. يتم تخزين بيانات الاعتماد الخاصة بكيان الخدمة هذا ككائن بيانات اعتماد آمن في GitHub، مثل GitHub Actions Secrets، بحيث لا يتم كشفها مباشرة ومرئية داخل البرامج النصية أو البنية الأساسية لبرنامج ربط العمليات التجارية للبناء.

للحصول على إرشادات عامة حول تأمين التطبيقات على مجموعات AKS، راجع مفاهيم الأمان للتطبيقات والمجموعات في AKS.

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

إشعار

لا تتناول هذه المقالة مباشرة كيفية تأمين البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD.

كفاءة الأداء

كفاءة الأداء هي قدرة حمل عملك على تغيير الحجم لتلبية المطالب التي يضعها المستخدمون عليها بطريقة فعالة. لمزيد من المعلومات، يرجى مراجعةأنماط كفاءة الأداء.

يتيح لك AKS قياس عدد عقد نظام المجموعة لتلبية متطلبات التطبيقات الخاصة بك. مع نمو التطبيق الخاص بك، يمكنك زيادة عدد عقد Kubernetes التي تشغل الخدمة الخاصة بك.

باستخدام GitHub Actions، يقوم موفر السحابة تلقائيا بتحجيم عدد المشغلين. إذا تم استخدام المشغلات المستضافة ذاتيا، فسيكون مضيف المشغل مسؤولا عن توسيع نطاقها حسب الحاجة.

للاطلاع على مواضيع قابلية التوسع الأخرى، راجع قائمة التحقق من كفاءة الأداء.

نشر هذا السيناريو

اتبع الخطوات الواردة في التنفيذ المرجعي ل AKS-baseline-automation لنشر السيناريو. قام مستودع التنفيذ المرجعي بتوجيه عمليات التوجيه لكل من سيناريو CI/CD المستند إلى الدفع وسيناريو CI/CD المستند إلى السحب (GitOps ).

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكتاب الرئيسيون:

مساهمون آخرون:

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

الخطوات التالية

استخدم هذا السيناريو Azure Container Registry وAKS لتخزين وتشغيل تطبيق قائم على الحاوية. يمكن أيضا استخدام Azure Container Apps أو Azure Container Instances لتشغيل التطبيقات المستندة إلى الحاوية، دون الحاجة إلى توفير أي مكونات تزامن. لمزيد من المعلومات، راجع نظرة عامة على مثيلات حاوية Azure ونظرة عامة على Azure Container Apps.

وثائق المنتج:

وحدات Microsoft Learn: