تحرير

مشاركة عبر

GitOps لخدمة Azure Kubernetes

Azure Kubernetes Service (AKS)
GitHub

GitOps هي مجموعة من المبادئ لتشغيل وإدارة نظام البرامج. توضح هذه المقالة تقنيات استخدام مبادئ GitOps لتشغيل وإدارة نظام مجموعة Azure Kubernetes Services (AKS).

Flux و Argo CD وOPA Gatekeeper وKubernetes وشعارات git هي علامات تجارية لشركاتها المعنية. ولا ينطوي استخدام هذه العلامات على أية مصادقة.

بناء الأنظمة

اثنان من عوامل تشغيل GitOps التي يمكنك استخدامها مع AKS هما Flux و Argo CD. كلاهما مشروعان متخرجان من Cloud Native Computing Foundation (CNCF) ويستخدمان على نطاق واسع. تعرض السيناريوهات التالية طرقا لاستخدامها.

السيناريو 1: GitOps مع Flux وAKS

رسم تخطيطي ل GitOps مع Flux v2 وGitHub وAKS.

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

تدفق البيانات للسيناريو 1

Flux هو امتداد نظام مجموعة أصلي إلى AKS. توفر ملحقات نظام المجموعة نظاما أساسيا لتثبيت الحلول وإدارتها على نظام مجموعة AKS. يمكنك استخدام مدخل Azure أو Azure CLI أو البنية الأساسية كنصوص برمجية (IaC)، مثل Terraform أو برامج Bicep النصية، لتمكين Flux كملحق ل AKS. يمكنك أيضا استخدام نهج Azure لتطبيق تكوينات Flux v2 على نطاق واسع على مجموعات AKS. لمزيد من المعلومات، راجع نشر التطبيقات باستمرار على نطاق واسع باستخدام تكوينات Flux v2 ونهج Azure.

يمكن ل Flux نشر بيانات Kubernetes ومخططات Helm وملفات Kustomization إلى AKS. Flux هي عملية تستند إلى الاستقصاء، لذلك يمكنها اكتشاف تغييرات التكوين وسحبها وتسويةها دون تعريض نقاط نهاية نظام المجموعة لوكلاء البناء.

في هذا السيناريو، يمكن لمسؤولي Kubernetes تغيير كائنات تكوين Kubernetes، مثل الأسرار والتكوين الخرائط، وتثبيت التغييرات مباشرة إلى مستودع GitHub.

تدفق البيانات لهذا السيناريو هو:

  1. يلتزم المطور بتغييرات التكوين إلى مستودع GitHub.
  2. يكتشف Flux انحراف التكوين في مستودع Git، ويسحب تغييرات التكوين.
  3. يقوم Flux بتسوية الحالة في مجموعة Kubernetes.

بدائل للسيناريو 1

  • يمكنك استخدام Flux مع مستودعات Git الأخرى مثل Azure DevOps وGitLab وBitBucket.
  • بدلا من مستودعات Git، تحدد Flux Bucket API مصدرا لإنتاج أداة للكائنات من حلول التخزين مثل مستودعات Amazon S3 وGoogle Cloud Storage. يمكنك أيضا استخدام حل يحتوي على واجهة برمجة تطبيقات متوافقة مع S3. مثالان هما Minio و Alibaba Cloud OSS، ولكن هناك آخرون.
  • يمكنك أيضا تكوين Flux مقابل حاوية Azure Blob Storage كمصدر لإنتاج البيانات الاصطناعية. لمزيد من المعلومات، راجع تكوينات GitOps Flux v2 مع AKS وKubernetes التي تدعم Azure Arc.

السيناريو 2: استخدام GitOps مع Flux وGitHub وAKS لتنفيذ CI/CD

رسم تخطيطي لتنفيذ CI/CD باستخدام GitOps مع Flux وGitHub وAKS.

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

تدفق البيانات للسيناريو 2

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

  1. يتم تطوير التعليمات البرمجية للتطبيق باستخدام IDE مثل Visual Studio Code.
  2. تلتزم التعليمات البرمجية للتطبيق بمستودع GitHub.
  3. تنشئ GitHub Actions صورة حاوية من التعليمات البرمجية للتطبيق وتدفع صورة الحاوية إلى Azure Container Registry.
  4. تقوم إجراءات GitHub بتحديث ملف نشر بيان Kubernetes بإصدار الصورة الحالي الذي يستند إلى رقم إصدار صورة الحاوية في Azure Container Registry.
  5. يكتشف عامل تشغيل Flux انحراف التكوين في مستودع Git ويسحب تغييرات التكوين.
  6. يستخدم Flux ملفات البيان لنشر التطبيق إلى نظام مجموعة AKS.

السيناريو 3: GitOps مع Argo CD ومستودع GitHub وAKS

رسم تخطيطي ل GitOps مع Argo CD وGitHub وAKS.

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

تدفق البيانات للسيناريو 3

في هذا السيناريو، يمكن لمسؤول Kubernetes تغيير كائنات تكوين Kubernetes، مثل الأسرار والتكوين الخرائط، وتثبيت التغييرات مباشرة إلى مستودع GitHub.

تدفق البيانات لهذا السيناريو هو:

  1. يقوم مسؤول Kubernetes بإجراء تغييرات التكوين في ملفات YAML ويلتزم بالتغييرات في مستودع GitHub.
  2. يسحب Argo CD التغييرات من مستودع Git.
  3. يقوم Argo CD بتسوية تغييرات التكوين إلى نظام مجموعة AKS.

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

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

بشكل افتراضي، لا يتم عرض واجهة مستخدم Argo CD وخادم API. للوصول إليها، نوصي بإنشاء وحدة تحكم دخول تحتوي على عنوان IP داخلي. أو يمكنك استخدام موازن تحميل داخلي لعرضها.

بدائل للسيناريو 3

يمكن أن يعمل أي مستودع متوافق مع Git، بما في ذلك Azure DevOps، كمستودع مصدر التكوين.

السيناريو 4: استخدام GitOps مع Argo CD وGitHub Actions وAKS لتنفيذ CI/CD

رسم تخطيطي لتنفيذ CI/CD باستخدام GitOps مع Argo CD وGitHub وAKS.

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

تدفق البيانات للسيناريو 4

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

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

بدائل للسيناريو 4

يمكن أن يعمل أي مستودع متوافق مع Git، بما في ذلك Azure DevOps، كمستودع مصدر التكوين.

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

GitOps هي مجموعة من المبادئ لتشغيل وإدارة نظام البرامج.

  • ويستخدم التحكم بالمصادر كمصدر واحد للحقيقة للنظام.
  • وهو يطبق ممارسات التطوير مثل التحكم في الإصدار والتعاون والامتثال والتكامل المستمر/النشر المستمر (CI/CD) على أتمتة البنية الأساسية.
  • يمكنك تطبيقه على أي نظام برامج.

غالبا ما يستخدم GitOps لإدارة مجموعة Kubernetes وتسليم التطبيق. توضح هذه المقالة بعض الخيارات الشائعة لاستخدام GitOps مع نظام مجموعة AKS.

وفقا لمبادئ GitOps، يجب أن تكون الحالة المطلوبة لنظام GitOps المدار:

  1. تعريفي: يجب أن يتم التعبير عن الحالة المرغوبة للنظام الذي يديره GitOps بشكل تعريفي. عادة ما يتم تخزين الإعلان في مستودع Git.
  2. إصدار وغير قابل للتغيير: يتم تخزين الحالة المطلوبة بطريقة تفرض عدم قابلية التغيير وتعيين الإصدار، وتحتفظ بمحفوظات إصدار كاملة.
  3. سحب تلقائيا: يسحب وكلاء البرامج تلقائيا إعلانات الحالة المطلوبة من المصدر.
  4. التوفيق المستمر: يراقب وكلاء البرامج باستمرار حالة النظام الفعلية ويحاولون تطبيق الحالة المطلوبة.

في GitOps، تستخدم البنية الأساسية كتعليق برمجي (IaC) التعليمات البرمجية للإعلان عن الحالة المطلوبة لمكونات البنية الأساسية مثل الأجهزة الظاهرية (VMs) والشبكات وجدران الحماية. هذه التعليمة البرمجية هي الإصدار الذي يتم التحكم فيه وقابل للتدقيق.

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

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

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

GitOps كمصدر واحد للحقيقة

يوفر GitOps تناسقا وتوحيدا لحالة نظام المجموعة، ويمكن أن يساعد في تحسين الأمان. يمكنك أيضا استخدام GitOps لضمان حالة متناسقة عبر مجموعات متعددة. على سبيل المثال، يمكن لتطبيق GitOps نفس التكوين عبر مجموعات التعافي من الكوارث الأساسية (DR)، أو عبر مجموعة من المجموعات.

إذا كنت تريد فرض أن GitOps فقط يمكنه تغيير حالة نظام المجموعة، يمكنك تقييد الوصول المباشر إلى نظام المجموعة. هناك طرق مختلفة للقيام بذلك، بما في ذلك التحكم في الوصول استنادا إلى الدور (RBAC) في Azure ووحدات التحكم في القبول والأدوات الأخرى.

استخدام GitOps للتكوين الأولي ل bootstrap

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

يمكنك تمكين Flux كملحق يتم تطبيقه عند إنشاء نظام مجموعة AKS. يمكن ل Flux بعد ذلك تمهيد تكوين الأساس إلى نظام المجموعة. تقترح بنية الأساس لمجموعة AKS استخدام GitOps للتمهيد. إذا كنت تستخدم ملحق Flux، يمكنك تمهيد تشغيل أنظمة المجموعات قريبا جدا بعد النشر.

أدوات GitOps ووظائفه الإضافية الأخرى

يمكنك توسيع السيناريوهات الموضحة إلى أدوات GitOps الأخرى. Jenkins X هي أداة GitOps أخرى توفر إرشادات للتكامل مع Azure. يمكنك استخدام أدوات التسليم التدريجي مثل Flagger للتحول التدريجي لأحمال عمل الإنتاج التي يتم نشرها من خلال GitOps.

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

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

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

الاعتبارات

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

الموثوقيه

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

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

الأمان

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

باستخدام نهج GitOps، لا يصل المطورون أو المسؤولون الفرديون مباشرة إلى مجموعات Kubernetes لتطبيق التغييرات أو التحديثات. بدلا من ذلك، يدفع المستخدمون التغييرات إلى مستودع Git ويقرأ عامل تشغيل GitOps (Flux أو Argo CD) التغييرات ويطبقها على نظام المجموعة. يتبع هذا الأسلوب أفضل ممارسة أمان أقل امتيازًا من خلال عدم منح فرق DevOps أذونات الكتابة إلى واجهة برمجة تطبيقات Kubernetes. في سيناريوهات التشخيص أو استكشاف الأخطاء وإصلاحها، يمكنك منح أذونات نظام المجموعة لفترة محدودة على أساس كل حالة على حدة.

بصرف النظر عن مهمة إعداد أذونات المستودع، ضع في اعتبارك تنفيذ تدابير الأمان التالية في مستودعات Git التي تتم مزامنتها مع مجموعات AKS:

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

تحسين التكلفة

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

  • على المستوى المجاني، تقدم AKS إدارة مجانية للمجموعة. تقتصر التكاليف على موارد الحوسبة والتخزين والشبكات التي تستخدمها AKS لاستضافة العقد.
  • يقدم GitHub خدمة مجانية، ولكن لاستخدام ميزات متقدمة متعلقة بالأمان مثل مالكي التعليمات البرمجية أو المراجعين المطلوبين، تحتاج إلى خطة الفريق. لمزيد من المعلومات، راجع صفحة أسعار GitHub.
  • يوفر Azure DevOps مستوى مجانيا يمكنك استخدامه لبعض السيناريوهات.
  • استخدم حاسبة تسعير Azure لتقدير التكاليف.

التميز التشغيلي

يغطي التميز التشغيلي عمليات التشغيل التي تحافظ على تشغيل التطبيق في الإنتاج. لمزيد من المعلومات، يرجى مراجعةنظرة عامة على ركيزة التميز التشغيلي.

يمكن أن تزيد GitOps من إنتاجية DevOps. واحدة من أكثر الميزات فائدة هي القدرة على التراجع بسرعة عن التغييرات التي تعمل بشكل غير متوقع، فقط عن طريق تنفيذ عمليات Git. لا يزال الرسم البياني للالتزام يحتوي على جميع التثبيتات، بحيث يمكن أن يساعد في تحليل ما بعد الوفاة.

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

نشر سيناريو

توفر القائمة التالية مراجع للحصول على معلومات حول نشر السيناريوهات الخمسة:

المساهمون

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

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

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

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