مشاركة عبر

تخصصات CI/CD وGitOps مع Kubernetes الممكنة في Azure Arc

  • مقالة

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

يتيح لك تنفيذ GitOps ما يلي:

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

يستخدم GitOps على Kubernetes الممكن في Azure Arc ملحقا ينفذ Flux، وهي مجموعة أدوات مفتوحة المصدر شائعة. Flux هو عامل تشغيل يقوم بأتمتة عمليات توزيع تكوين GitOps في نظام المجموعة الخاص بك. يوفر Flux الدعم لمصادر الملفات الشائعة (مستودعات Git ومستودعات Helm والمستودعات) وأنواع القوالب (YAML وHelm وKustomize). يدعم Flux أيضا إدارة تبعية الإيجار المتعدد والتوزيع من بين ميزات أخرى.

بناء الأنظمة

توضح الرسومات التخطيطية التالية بنية مرجعية مفاهيمية تبرز توفير تثبيت ملحق نظام مجموعة Flux في نظام مجموعة، وعملية تكوين GitOps لمجموعة Kubernetes الممكنة في Azure Arc، وGitOps Flow.

عملية توفير ملحق نظام مجموعة Flux v2:

رسم تخطيطي يوضح تثبيت ملحق Flux.

عملية تكوين GitOps:

رسم تخطيطي يوضح كيفية تكوين GitOps.

يظهر تدفق GitOps تحديث تطبيق:

رسم تخطيطي يوضح سير عمل GitOps نموذجي.

اعتبارات التصميم

راجع اعتبارات التصميم التالية عند التخطيط لتنفيذ GitOps ل Kubernetes الممكنة في Azure Arc.

التكوين

ضع في اعتبارك الطبقات المختلفة للتكوين في مجموعة Kubernetes والمسؤوليات المتضمنة في توفيرها.

طبقات التكوين

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

المسؤوليات

  • مطورو التطبيقات مسؤولون عن دفع التعليمات البرمجية المصدر الخاصة بهم، وتشغيل البنيات، وإنشاء صور الحاوية.
  • يتحمل مشغلو التطبيقات مسؤولية الحفاظ على مستودعات التطبيقات والتكوينات ومتغيرات البيئة ومخططات helm الخاصة بالتطبيق وKustomizations وما إلى ذلك.
  • عوامل تشغيل نظام المجموعة مسؤولة عن إعداد أساس نظام المجموعة الخاص بك. عادة ما يهتمون بإعداد المكونات والنهج على مستوى المجموعة. يحتفظون بدليل أو أدلة Git repo تحتوي على أدوات البنية الأساسية الشائعة مثل مساحات الأسماء وحسابات الخدمة و RoleBindings و CRDs والنهج على مستوى نظام المجموعة ومكونات الدخول وما إلى ذلك.

بنية المستودع

ضع في اعتبارك المقايضات عند اختيار بنية مستودع Git. ستحدد البنية التي تختارها حالة نظام مجموعة Kubernetes، والتي تتضمن التطبيقات والمكونات على مستوى المجموعة. اعتمادا على المسؤوليات والشخصيات التي تحددها، من المهم مراعاة أي تعاون ضروري أو استقلالية الفريق المطلوبة لخيارات بنية المستودع المختلفة.

يمكنك استخدام أي استراتيجية تفريع تريدها لمستودعات التعليمات البرمجية الخاصة بك، حيث يتم استخدامها فقط بواسطة عملية التكامل المستمر (CI).

بالنسبة لمستودعات تكوين GitOps الخاصة بك، ضع في اعتبارك الاستراتيجيات التالية استنادا إلى احتياجات الأعمال والحجم والأدوات الخاصة بمؤسستك:

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

راجع المزيد من الطرق لهيكلة المستودع الخاص بك في دليل Flux.

تكوين التطبيق والنظام الأساسي

لدى مشغلي النظام الأساسي ومشغلي التطبيقات العديد من الخيارات لإدارة تكوين Kubernetes:

  • يمكن أن تعمل ملفات Kubernetes YAML الأولية التي تمثل مواصفات YAML لكل كائن Kubernetes API تقوم بنشره بشكل جيد للبيئات الفردية. العيب في استخدام ملفات YAML الأولية هو أن التخصيص يصبح صعبا عند البدء في دمج بيئات متعددة، حيث تحتاج بعد ذلك إلى تكرار ملفات YAML ولا توجد طريقة إعادة استخدام جيدة.
  • Helm هي أداة إدارة حزمة لعناصر Kubernetes. إنه خيار صالح يمكن لمشغلي نظام المجموعة استخدامه لتثبيت تطبيقات الجهات الخارجية الجاهزة. تأكد من عدم استخدام templating بشكل كبير جدا كأداة لإدارة التكوين للتطبيقات الداخلية، لأنه يمكن أن يصبح من المعقد إدارتها مع نمو القوالب الخاصة بك.
    • في حالة استخدام Helm، يتضمن Flux وحدة تحكم Helm تتيح لك إدارة إصدارات مخطط Helm بشكل تعريفي باستخدام بيانات Kubernetes. يمكنك إنشاء كائن HelmRelease لإدارة هذه العملية.
  • Kustomize هي أداة إدارة تكوين Kubernetes أصلية تقدم طريقة خالية من القالب لتخصيص تكوين التطبيق.
    • في حالة استخدام Kustomize، يتضمن Flux وحدة تحكم Kustomize متخصصة في تشغيل مسارات التسليم المستمر للبنية الأساسية وأحمال العمل المحددة مع بيانات Kubernetes وتجميعها باستخدام Kustomize. يمكنك إنشاء كائن Kustomization لإدارة هذه العملية.
  • باستخدام Kubernetes الممكن في Azure Arc، بدلا من الحاجة إلى إدارة دورة حياة المكونات ودعمها بنفسك، يمكنك استخدام قائمة بالملحقات المتوفرة التي تديرها Microsoft وتدعمها. تتم إدارة هذه الملحقات من خلال Azure Resource Manager. تحتوي بعض هذه الملحقات، مثل Azure Key Vault Secrets Provider، على بدائل مصدر مفتوح. تمنحك إدارة المكونات خارج عملية الملحق مزيدا من التحكم في المكونات، ولكنها تتطلب أيضا المزيد من النفقات العامة لإدارة الدعم ودورة الحياة.

تدفق التكامل المستمر والتسليم المستمر (CI/CD)

توفر الأقسام التالية اعتبارات لمسار التطبيق وعملية تحديث المكون.

مسار التطبيق

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

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

يوضح الرسم التخطيطي للعملية التالية عملية CI للتطبيق التقليدي المدمجة مع التغييرات التي تدعم GitOps.

رسم تخطيطي يوضح عملية GitOps القياسية.

عملية تحديث المكون على مستوى نظام المجموعة

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

عند تحديث التكوين الخاص بك، من المحتمل أن ترغب في التحقق من تطبيق التغييرات بنجاح على البيئة المطلوبة. يمكنك تعريف الإعلامات في Flux للتكامل مع أدوات CI/CD أو البريد الإلكتروني أو أدوات ChatOps وإرسال التنبيهات تلقائيا بشأن التغييرات الناجحة وفشل النشر. يمكنك أيضا العثور على معلومات حالة التوزيع في مدخل Microsoft Azure ومن خلال k8s-configuration CLI وARM API.

اعتبارات الأمان

راجع اعتبارات الأمان التالية عند التخطيط لتنفيذ GitOps ل Kubernetes الممكنة في Azure Arc.

مصادقة المستودع

  • يمكنك استخدام مستودع Git عام أو خاص مع GitOps، ولكن نظرا للطبيعة الحساسة لتكوينات Kubernetes، نوصي باستخدام مستودع خاص يتطلب المصادقة بواسطة مفتاح SSH أو مفتاح واجهة برمجة التطبيقات. تعمل GitOps أيضا مع مستودعات Git التي يمكن الوصول إليها فقط داخل شبكة خاصة طالما أن مجموعة Kubernetes الخاصة بك يمكنها الوصول إليها، ولكن هذا الإعداد يحد من قدرتك على استخدام موفري Git المستندين إلى السحابة مثل Azure Repos أو GitHub.
  • يوفر كل من بروتوكولات HTTPS وSSH اتصالا موثوقا وآمنا يمكنك استخدامه للاتصال بأداة التحكم بالمصادر. ومع ذلك، غالبا ما يكون إعداد HTTPS أسهل، ويستخدم منفذا نادرا ما يتطلب منك فتح المزيد من المنافذ في جدران الحماية الخاصة بك.

أمان المستودع والفرع

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

إدارة البيانات السرية

  • تجنب تخزين النص العادي أو البيانات السرية المرمزة base64 في مستودع Git الخاص بك. بدلا من ذلك، ضع في اعتبارك استخدام موفر بيانات سرية خارجية مثل Azure Key Vault. يسمح لك موفر Azure Key Vault لبرنامج تشغيل CSI لمخزن الأسرار بدمج مخزن مفاتيح Azure كمخزن أسرار مع نظام مجموعة Azure Kubernetes Service (AKS) باستخدام وحدة تخزين CSI. تتوفر هذه الخدمة من خلال ملحق Kubernetes الذي يدعم Azure Arc. HashiCorp Vault هو بديل موفر سري مدار من جهة خارجية.
  • هناك طريقة بديلة أخرى لإدارة الأسرار وهي استخدام أسرار Bitnami المختومة، والتي تعمل من مفهوم المفاتيح العامة والخاصة. يسمح هذا للمشغلين بتخزين سر مشفر أحادي الاتجاه باستخدام مفتاح عام في Git، والذي يمكن فك تشفيره فقط من خلال المفتاح الخاص، والذي تستخدمه وحدة تحكم SealedSecrets التي تعمل في نظام المجموعة الخاص بك.

توصيات التصميم

راجع توصيات التصميم التالية عند التخطيط لتنفيذ GitOps ل Kubernetes الممكنة في Azure Arc.

يحتوي الرسم التخطيطي التالي على بنية مرجعية توضح المسؤوليات والمستودعات والبنيات الأساسية لبرنامج ربط العمليات التجارية اللازمة لتنفيذ عملية GitOps باستخدام ملحق Kubernetes Flux الممكن في Azure Arc.

رسم تخطيطي يوضح تدفق مرجع GitOps.

المستودعات

يتم تضمين ثلاثة مستودعات Git في التصميم:

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

CI/CD وعملية تحديث التكوين

CI/CD وتحديثات صورة الحاوية

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

تحديثات تكوين التطبيق على مستوى نظام المجموعة

  • يحدد كل من مشغلي نظام المجموعة ومشغلي التطبيقات التكوين في مستودعات التكوين الخاصة بهم. لا يتطلب هؤلاء المستخدمون أدوات البنية الأساسية لبرنامج ربط العمليات التجارية لدفع التكوينات. بدلا من ذلك، يستخدمون عمليات تثبيت Git الأصلية وعمليات PR لتحديد تكوين ودفع التغييرات إلى فرع يمثل بيئة.
  • بالنسبة لتعريفات التكوين الجديدة، ابدأ بتعريف التكوين في بيئات أقل، مثل Dev، ثم الترقية إلى بيئات أعلى من خلال عمليات الدمج وطلبات السحب. تحديثات تكوين Cherry-pick الخاصة ببيئات معينة حسب الحاجة.

الملاحظات والتنبيه

  • قم بتكوين Flux Notifications للتنبيه عندما تكون تكوينات GitOps غير قادرة على المزامنة أو تقوم بطرح الأخطاء. يجب على مشغلي التطبيقات تكوين التنبيهات لتحديد وقت نجاح نشر التطبيق وصحته. يجب على مشغلي نظام المجموعة تكوين التنبيهات لتحديد وقت فشل تسوية المكونات على مستوى نظام المجموعة ومتى توجد مشكلات في المزامنة مع مستودع Git الخاص بك.
  • تنفيذ GitOps Connector لدمج الملاحظات من عامل Flux إلى أدوات CI/CD.

توصيات الأمان

  • راجع توصيات الحوكمة والأمان لمجموعات Kubernetes الممكنة في Azure Arc.
  • تجنب الوصول غير المرغوب فيه إلى أي تكوين نظام مجموعة باستخدام مستودع Git خاص مع المصادقة والتخويل الذي يمكنك استخدامه لتعريف أي مستودع تكوين.
  • الوصول إلى مستودع Git الخاص بك من خلال بروتوكول SSH ومفتاح SSH إذا كان موفر Git يدعمه. إذا كان SSH غير قابل للاستخدام بسبب قيود الاتصال الصادرة، أو إذا كان موفر Git لا يدعم مكتبات SSH المطلوبة، فاستخدم حساب خدمة مخصصا وقم بإقران مفتاح واجهة برمجة التطبيقات بهذا الحساب لاستخدام Flux. إذا كنت بحاجة إلى بديل ل SSH عند استخدام GitHub، يمكنك إنشاء رمز وصول شخصي للمصادقة.
  • تكوين نهج الفرع والأذونات التي تطابق مسؤوليات نظام المجموعة الخاص بك. تعيين الحد الأدنى لعدد المراجعين للموافقة على التغييرات.
  • تكوين البنية الأساسية لبرنامج ربط العمليات التجارية PR للتحقق من صحة تكوينات YAML وبناء الجملة وتوزيع مجموعة Kubernetes الاختبارية اختياريا. قم بإعداد نهج فرع يتطلب تشغيل هذا المسار بنجاح قبل قبول أي دمج.
  • تنفيذ الأسرار باستخدام موفر Key Vault Azure لبرنامج تشغيل CSI لمخزن الأسرار، والذي سيسمح بتكامل Key Vault Azure كمخزن أسرار مع مجموعة Kubernetes الممكنة في Azure Arc عبر وحدة تخزين CSI.
  • يدعم ملحق Flux مساحة الاسم والتكوينات التي تم تحديد نطاق نظام المجموعة لها. اختر نطاق مساحة الاسم عندما لا يجب أن يكون للتكوين حق الوصول خارج مساحة اسم واحدة.

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

لمزيد من المعلومات حول رحلة السحابة المختلطة ومتعددة السحابات، راجع المقالات التالية.