مشاركة عبر

البرنامج التعليمي: تنفيذ CI/CD مع GitOps باستخدام مجموعات Kubernetes التي تمكن Azure Arc

  • مقالة

هام

يستخدم هذا البرنامج التعليمي GitOps مع Flux v1. يتوفر GitOps مع Flux v2 الآن لمجموعات Kubernetes وAzure Kubernetes Service (AKS) الممكنة في Azure Arc؛ انتقل إلى البرنامج التعليمي الذي يستخدم GitOps مع Flux v2. نوصي بالترحيل إلى Flux v2 في أقرب وقت ممكن.

سينتهي دعم موارد تكوين نظام المجموعة المستندة إلى Flux v1 التي تم إنشاؤها قبل 1 يناير 2024 في 24 مايو 2025. بدءا من 1 يناير 2024، لن تتمكن من إنشاء موارد تكوين نظام المجموعة الجديدة المستندة إلى Flux v1.

في هذا البرنامج التعليمي، عليك إعداد حل CI/CD باستخدام GitOps مع مجموعات Kubernetes الممكنة في Azure Arc. باستخدام نموذج تطبيق Azure Vote، عليك القيام بما يلي:

  • قم بإنشاء مجموعة Kubernetes المُمكّنة في Azure Arc
  • قم بتوصيل تطبيقك ومستودع GitOps إلى Azure Repos.
  • استورد تدفقات CI/CD.
  • قم بتوصيل Azure Container Registry (ACR) بـ Azure DevOps وKubernetes.
  • أنشئ مجموعات متغيرات البيئة.
  • نشر البيئات dev و stage .
  • اختبر بيئات التطبيق.

في حال لم يكن لديك اشتراك Azure، فأنشئ حساباً مجانيّاً قبل البدء.

Azure Cloud Shell

Azure يستضيف Azure Cloud Shell، بيئة تفاعلية يمكن استخدامها من خلال المستعرض. يمكنك استخدام Bash أو PowerShell مع Cloud Shell للعمل مع خدمات Azure. يمكنك استخدام أوامر Cloud Shell المثبتة مسبقًا لتشغيل التعليمات البرمجية في هذه المقالة دون الحاجة إلى تثبيت أي شيء على البيئة المحلية.

لبدء Azure Cloud Shell:

خيار مثال/ رابط
انقر فوق ⁧⁩جربه⁧⁩ في الزاوية العلوية اليسرى من التعليمة البرمجية أو كتلة الأمر. تحديد ⁧⁩جربه⁧⁩ لا يقوم بنسخ التعليمة البرمجية أو الأمر تلقائيًا إلى Cloud Shell. لقطة شاشة تعرض مثالاً على Try It for Azure Cloud Shell.
انتقل إلى ⁧⁩⁧ https://shell.azure.com⁩⁧⁩، أو حدد زر ⁩تشغيل Cloud Shell لفتح Cloud Shell في المتصفح لديك. زر لتشغيل Azure Cloud Shell.
حدد زر Cloud Shell على شريط القوائم في أعلى اليمين في مدخل Microsoft Azure. لقطة شاشة تعرض زر Cloud Shell في مدخل Microsoft Azure

لاستخدام Azure Cloud Shell:

  1. ابدأ تشغيل Cloud Shell.

  2. حدد الزر نسخ على كتلة التعليمات البرمجية (أو كتلة الأوامر) لنسخ التعليمات البرمجية أو الأمر.

  3. ألصق التعليمة البرمجية أو الأمر في جلسة Cloud Shell بتحديد Ctrl+Shift+Vعلى Windows وLunix، أو بتحديد Cmd+Shift+Vعلى macOS.

  4. حدد Enter لتشغيل التعليمات البرمجية أو الأمر.

قبل البدء

يفترض هذا البرنامج التعليمي معرفة Azure DevOps وAzure Repos والتدفقات وAzure CLI.

استيراد التطبيق ومستودع GitOps في Azure Repos

استيراد مستودع تطبيق وGitOps repo إلى Azure Repos. لهذا البرنامج التعليمي، استخدم المثال التالي على المستودع:

تعرف على المزيد حول استيراد مستودعات Git.

إشعار

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

الاتصال بمستودع GitOps

لنشر التطبيق بشكل مستمر، قم بتوصيل مستودع التطبيق بالمجموعة باستخدام GitOps. يحتوي مستودع GitOps ل arc-cicd-demo-gitops على الموارد الأساسية لتشغيل تطبيقك وتشغيله على نظام مجموعة arc-cicd-cluster.

يحتوي مستودع GitOps الأولي فقط على بيان ينشئ مساحات أسماء التطوير والمرحلة المقابلة لبيئات النشر.

سيتم إنشاء اتصال GitOps تلقائيًا:

  • قم بمزامنة البيانات في دليل البيان.
  • قم بتحديث حالة المجموعة.

سيقوم سير العمل CI/CD بتعبئة دليل البيان ببيانات إضافية لنشر التطبيق.

  1. إنشاء اتصال GitOps جديد إلى مستودع arc-cicd-demo-gitops الذي تم استيراده حديثا في Azure Repos.

    az k8s-configuration create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --resource-group myResourceGroup \
   --operator-instance-name cluster-config \
   --operator-namespace cluster-config \
   --repository-url https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
   --https-user <Azure Repos username> \
   --https-key <Azure Repos PAT token> \
   --scope cluster \
   --cluster-type connectedClusters \
   --operator-params='--git-readonly --git-path=arc-cicd-cluster/manifests'

  2. تأكد من أن Flux يستخدم arc-cicd-cluster/manifests الدليل فقط كمسار أساسي. قم بتعريف المسار باستخدام معلمة عامل التشغيل التالية:

    --git-path=arc-cicd-cluster/manifests

    إشعار

    إذا كنت تستخدم سلسلة اتصال HTTPS وكنت تواجه مشكلات في الاتصال، فتأكد من حذف بادئة اسم المستخدم في عنوان URL. على سبيل المثال، https://alice@dev.azure.com/contoso/project/_git/arc-cicd-demo-gitops يجب أن تكون قد alice@ تمت إزالتها. --https-user يحدد المستخدم بدلا من ذلك، على سبيل المثال --https-user alice.

  3. تحقق من حالة النشر في مدخل Azure.

    • إذا نجحت، فسترى كل من dev و stage مساحات الأسماء التي تم إنشاؤها في نظام المجموعة.

استيراد تدفقات CI/CD

الآن، بعد أن قمت بمزامنة اتصال GitOps، ستحتاج إلى استيراد تدفقات CI/CD التي تنشئ البيانات.

يحتوي مستودع التطبيق على مجلد يحتوي على .pipeline البنية الأساسية لبرنامج ربط العمليات التجارية التي ستستخدمها ل PRs وCI وCD. استيراد وإعادة تسمية التدفقات الثلاثة المتوفرة في نموذج المستودع:

اسم ملف التدفق ‏‏الوصف
.pipelines/az-vote-pr-pipeline.yaml مسار طلب السحب للتطبيق، المسمى arc-cicd-demo-src PR
.pipelines/az-vote-ci-pipeline.yaml مسار CI للتطبيق، المسمى arc-cicd-demo-src CI
.pipelines/az-vote-cd-pipeline.yaml مسار CD للتطبيق، المسمى arc-cicd-demo-src CD

اتصال بـ ACR

كل من تدفقاتك والمجموعة ستستخدم ACR لتخزين واسترداد صور Docker.

توصيل ACR بـ Azure DevOps

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

  1. في Azure DevOps، افتح صفحة اتصالات الخدمة من صفحة إعدادات المشروع. في TFS، افتح صفحة الخدمات من أيقونة الإعدادات في شريط القوائم العلوي.
  2. اختر + New service connection وحدد نوع اتصال الخدمة الذي تحتاجه.
  3. قم بتعبئة المعلمات الخاصة باتصال الخدمة. لهذا البرنامج التعليمي:
    • قم بتسمية اتصال الخدمة arc-demo-acr.
    • حدد myResourceGroup كمجموعة موارد.
  4. حدد منح إذن الوصول إلى كافة المسارات.
    • هذا الخيار يخول ملفات تدفق YAML لاتصالات الخدمة.
  5. اختر موافق لإنشاء الاتصال.

توصيل ACR بـ Kubernetes

قم بتمكين مجموعة Kubernetes الخاصة بك لسحب الصور من ACR الخاص بك. إذا كان خاصًا، فسيلزم المصادقة.

توصيل ACR بمجموعات AKS الموجودة

قم بدمج ACR الموجود بمجموعات AKS الموجودة باستخدام الأمر التالي:

az aks update -n arc-cicd-cluster -g myResourceGroup --attach-acr arc-demo-acr

إنشاء سر سحب صورة

لتوصيل مجموعات غير AKS ومجموعات محلية بـ ACR الخاص بك، أنشئ سرًا لسحب الصور. يستخدم Kubernetes أسرار سحب الصور لتخزين المعلومات اللازمة لمصادقة تسجيلك.

إنشاء سر سحب صورة باستخدام الأمر التالي kubectl . كرر ذلك لكل من dev مساحات الأسماء و stage .

kubectl create secret docker-registry <secret-name> \
    --namespace <namespace> \
    --docker-server=<container-registry-name>.azurecr.io \
    --docker-username=<service-principal-ID> \
    --docker-password=<service-principal-password>

لتجنب الاضطرار إلى تعيين imagePullSecret لكل جراب، ضع في اعتبارك إضافة imagePullSecret إلى حساب الخدمة في dev مساحات الأسماء و stage . راجع البرنامج التعليمي Kubernetes لمزيد من المعلومات.

إنشاء مجموعات متغيرات البيئة

مجموعة متغيرة المستودع للتطبيق

إنشاء مجموعة متغيرة تسمى az-vote-app-dev. قم بتعيين القيم التالية:

عامل القيمة‬
AZ_ACR_NAME (مثيل ACR الخاص بك، على سبيل المثال. azurearctest.azurecr.io)
AZURE_SUBSCRIPTION (اتصال خدمة Azure، والذي يجب أن يكون arc-demo-acr من وقت سابق في البرنامج التعليمي)
AZURE_VOTE_IMAGE_REPO المسار الكامل إلى مستودع تطبيق Azure Vote، على سبيل المثال azurearctest.azurecr.io/azvote
ENVIRONMENT_NAME Dev
MANIFESTS_BRANCH master
MANIFESTS_FOLDER azure-vote-manifests
MANIFESTS_REPO arc-cicd-demo-gitops
ORGANIZATION_NAME اسم مؤسسة Azure DevOps
PROJECT_NAME اسم مشروع GitOps في Azure DevOps
REPO_URL عنوان URL الكامل لمستودع GitOps
SRC_FOLDER azure-vote
TARGET_CLUSTER arc-cicd-cluster
TARGET_NAMESPACE dev

مجموعة متغيرات البيئة المرحلية

  1. استنساخ مجموعة متغيرات az-vote-app-dev.
  2. تغيير الاسم إلى az-vote-app-stage.
  3. تأكد من القيم التالية للمتغيرات المطابقة:
عامل القيمة‬
ENVIRONMENT_NAME مرحلة
TARGET_NAMESPACE stage

أنت الآن جاهز للتوزيع في البيئات dev و stage .

منح المزيد من الأذونات إلى خدمة البناء

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

  1. انتقل إلى Project settings من الصفحة الرئيسية لمشروع Azure DevOps.
  2. حدد Repositories.
  3. حدد <GitOps Repo Name>.
  4. حدد Security.
  5. بالنسبة إلى <Project Name> Build Service (<Organization Name>)، اسمح Contributeو Contribute to pull requestsو.Create branch

لمزيد من المعلومات، راجع:

نشر بيئة dev لأول مرة

مع إنشاء تدفقات CI وCD، قم بتشغيل تدفق CI لنشر التطبيق لأول مرة.

تدفق CI

في أثناء تشغيل تدفق CI الأولي، قد تحصل على خطأ تخويل مورد في قراءة اسم اتصال الخدمة.

  1. تحقق من أن المتغير الذي يتم الوصول إليه هو AZURE_SUBSCRIPTION.
  2. قم بتخويل الاستخدام.
  3. أعد تشغيل التدفق.

تدفق CI:

  • يضمن أن ينجح تغيير التطبيق في جميع عمليات التحقق من الجودة المؤتمتة للنشر.
  • هل أي تحقق إضافي من الصحة الذي تعذر إكماله في تدفق PR.
    • خاصة بـ GitOps، التدفق ينشر البيانات الاصطناعية أيضًا للالتزام الذي سيتم نشره بواسطة تدفق CD.
  • يتحقق من تغيير صورة Docker ودفع الصورة الجديدة.

تدفق CD

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

تشغيل تدفق CI الناجح يقوم بتشغيل تدفق CD لإكمال عملية النشر. سوف تنشر في كل بيئة بشكل تدريجي.

تلميح

إذا لم يتم تشغيل تدفق CD تلقائيًا:

  1. تحقق من تطابق الاسم مع مشغل الفرع في .pipelines/az-vote-cd-pipeline.yaml
    • يجب أن تكون arc-cicd-demo-src CI.
  2. أعد تشغيل تدفق CI.

بمجرد تغير القالب والبيان إلى مستودع GitOps، يقوم تدفق CD بإنشاء التزام ودفعه وإنشاء PR للموافقة عليه.

  1. افتح ارتباط PR المحدد في Create PR إخراج المهمة.

  2. تحقق من التغييرات بمستودع GitOps. يجب أن ترى:

    • تغييرات قالب Helm عالية المستوى.
    • يظهر Kubernetes منخفض المستوى الذي يظهر التغييرات الأساسية إلى الحالة المطلوبة. تدفق ينشر هذه البيانات.

  3. إذا كان كل شيء يبدو جيدًا، فوافق على واستكمل PR.

  4. بعد بضع دقائق، يقوم Flux بالتقاط التغيير ويبدأ النشر.

  5. أعد توجيه المنفذ محليا باستخدام kubectl وتأكد من أن التطبيق يعمل بشكل صحيح باستخدام:

    kubectl port-forward -n dev svc/azure-vote-front 8080:80

  6. اعرض تطبيق Azure Vote في المستعرض الخاص بك على http://localhost:8080/.

  7. قم بالتصويت لصالح مفضلاتك واستعد لإجراء بعض التغييرات على التطبيق.

قم بإعداد موافقات البيئة

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

إذا كشفت بيئة dev عن فاصل بعد النشر، فاحتفظ به من الانتقال إلى بيئات لاحقة باستخدام الموافقات البيئية.

  1. في مشروع Azure DevOps، انتقل إلى البيئة التي تحتاج إلى الحماية.
  2. انتقل إلى الموافقات والفحوصات للمورد.
  3. حدد إنشاء.
  4. قم بتوفير الموافقين ورسالة اختيارية.
  5. حدد إنشاء مرة أخرى لإكمال إضافة التحقق من الموافقة اليدوية.

لمزيد من التفاصيل، راجع البرنامج التعليمي تحديد الموافقة والتحقق .

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

إجراء تغيير في التطبيق

مع مجموعة الأساس هذه من القوالب والبيانات التي تمثل الحالة بالمجموعة، ستقوم بإجراء تغيير صغير على التطبيق.

  1. في arc-cicd-demo-src repo، قم بتحرير azure-vote/src/azure-vote-front/config_file.cfg الملف.

  2. نظرًا إلى أن "القطط مقابل الكلاب" لا يحصل على ما يكفي من الأصوات، فغيّرها إلى "علامات تبويب ومساحات" لزيادة عدد الأصوات.

  3. قم بإجراء التغيير في فرع جديد، ودفعه، وإنشاء طلب سحب.

    • هذا هو تدفق المطور النموذجي الذي سيبدأ دورة حياة CI/CD.

تدفق التحقق من صحة PR

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

يمكن للمخططين Dockerfile وHelm الخاصين بالتطبيق استخدام linting بطريقة مشابهة للتطبيق.

الأخطاء التي تم العثور عليها في أثناء نطاق linting من:

  • ملفات YAML المنسقة بشكل غير صحيح، إلى
  • أفضل الاقتراحات، مثل تعيين CPU وحدود الذاكرة تطبيقك.

إشعار

للحصول على أفضل تغطية من Helm linting في تطبيق حقيقي، ستحتاج إلى استبدال القيم المشابهة بشكل معقول بتلك المستخدمة في بيئة حقيقية.

تظهر الأخطاء التي تم العثور عليها في أثناء تنفيذ التدفق في قسم نتائج الاختبار بالتشغيل. من هنا، يُمكن أن ترى التالي:

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

بمجرد انتهاء تشغيل التدفق، تأكد من جودة التعليمات البرمجية للتطبيق والقالب الذي سيتم نشره. يمكنك الآن الموافقة على PR وإكمالها. سيتم تشغيل CI مرة أخرى، ويؤدي إلى تجديد القوالب والبيانات، قبل تشغيل تدفق CD.

تلميح

في بيئة حقيقية، لا تنسَ أن تضع نُهج الفروع لضمان اجتياز PR لفحوصات الجودة الخاصة بك. لمزيد من المعلومات، راجع مقالة تعيين نهج الفرع.

الموافقات على عملية CD

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

  1. الموافقة على النشر إلى dev البيئة.
  2. بمجرد تغير القالب والبيان إلى مستودع GitOps، يقوم تدفق CD بإنشاء التزام ودفعه وإنشاء PR للموافقة عليه.
  3. افتح الارتباط PR المحدد في المهمة.
  4. تحقق من التغييرات بمستودع GitOps. يجب أن ترى:
    • تغييرات قالب Helm عالية المستوى.
    • يظهر Kubernetes منخفض المستوى الذي يظهر التغييرات الأساسية إلى الحالة المطلوبة.
  5. إذا كان كل شيء يبدو جيدًا، فوافق على واستكمل PR.
  6. انتظر حتى يكتمل التوزيع.
  7. كاختبار دخان أساسي، انتقل إلى صفحة التطبيق وتحقق من أن تطبيق التصويت يعرض الآن علامات التبويب مقابل المسافات.
    • أعد توجيه المنفذ محليا باستخدام kubectl وتأكد من أن التطبيق يعمل بشكل صحيح باستخدام: kubectl port-forward -n dev svc/azure-vote-front 8080:80
    • اعرض تطبيق Azure Vote في المستعرض الخاص بك وتحقق http://localhost:8080/ من تغيير خيارات التصويت إلى علامات التبويب مقابل المسافات.
  8. كرر الخطوات من 1 إلى 7 للبيئة stage .

اكتمل نشرك الآن. يؤدي هذا إلى إنهاء سير عمل CI/CD.

تنظيف الموارد

إذا كنت لن تستمر في استخدام هذا التطبيق، فاحذف أي موارد بالخطوات التالية:

  1. احذف اتصال التكوين Azure Arc GitOps:

    az k8s-configuration delete \
--name cluster-config \
--cluster-name arc-cicd-cluster \
--resource-group myResourceGroup \
--cluster-type connectedClusters

  2. dev إزالة مساحة الاسم:

    • kubectl delete namespace dev

  3. stage إزالة مساحة الاسم:

    • kubectl delete namespace stage

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

في هذا البرنامج التعليمي، قمت بإعداد سير عمل CI/CD كامل يقوم بتنفيذ DevOps من تطوير التطبيقات من خلال النشر. تؤدي التغييرات التي يتم إدخالها على التطبيق تلقائيًا إلى تشغيل التحقق من الصحة والنشر، ويتم ربطها بالموافقات اليدوية.

تقدم إلى مقالتنا المفاهيمية لمعرفة المزيد عن GitOps والتكوينات باستخدام Kubernetes الممكنة في Azure Arc.

سير عمل CI/CD باستخدام GitOps - Kubernetes الممكنة في Azure Arc