البرنامج التعليمي: تنفيذ CI/CD باستخدام GitOps (Flux v2)

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

  • إنشاء مجموعة Kubernetes أو AKS ممكنة في Azure Arc.
  • قم بتوصيل التطبيق الخاص بك ومستودعات GitOps ب Azure Repos أو GitHub.
  • تنفيذ تدفق CI/CD إما باستخدام Azure Pipelines أو GitHub.
  • قم بتوصيل Azure Container Registry ب 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 Container Registry ب Kubernetes

تمكين مجموعة Kubernetes الخاصة بك لسحب الصور من Azure Container Registry. إذا كانت خاصة، فإن المصادقة مطلوبة.

توصيل Azure Container Registry بمجموعات AKS الموجودة

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

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

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

لتوصيل غير AKS والمجموعات المحلية ب Azure Container Registry، قم بإنشاء سر سحب صورة. يستخدم 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.

اعتمادا على منسق CI/CD الذي تفضله، يمكنك متابعة الإرشادات إما ل Azure DevOps أو ل GitHub.

تنفيذ CI/CD باستخدام Azure DevOps

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

تأكد من إكمال الخطوات التالية أولا:

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

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

  • مستودع تطبيق arc-cicd-demo-src

    • عنوان URL: https://github.com/Azure/arc-cicd-demo-src
    • يحتوي على مثال تطبيق Azure Vote الذي ستقوم بنشره باستخدام GitOps.
    • استيراد المستودع باسم arc-cicd-demo-src
  • مستودع arc-cicd-demo-gitops GitOps

تعرف على المزيد حول استيراد مستودعات 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 flux create \
       --name cluster-config \
       --cluster-name arc-cicd-cluster \
       --namespace flux-system \
       --resource-group myResourceGroup \
       -u 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 \
       --branch master \
       --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests
    

    تلميح

    بالنسبة إلى نظام مجموعة AKS (بدلا من نظام مجموعة ممكن بواسطة Arc)، استخدم -cluster-type managedClusters.

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

    • إذا نجحت، فسترى كل من dev و stage مساحات الأسماء التي تم إنشاؤها في نظام المجموعة.
    • يمكنك أيضا تأكيد أنه في صفحة مدخل Microsoft Azure في نظام المجموعة، يتم إنشاء تكوين cluster-config في علامة التبويب fGitOps .

استيراد تدفقات 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

توصيل Azure Container Registry ب Azure DevOps

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

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

تكوين اتصال خدمة PR

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

  1. في Azure DevOps، افتح صفحة اتصالات الخدمة من صفحة إعدادات المشروع. في TFS، افتح صفحة الخدمات من أيقونة الإعدادات في شريط القوائم العلوي.
  2. اختر + New service connection وحدد Generic type.
  3. قم بتعبئة المعلمات الخاصة باتصال الخدمة. لهذا البرنامج التعليمي:
    • عنوان URL للخادم https://dev.azure.com/<Your organization>/<Your project>/_apis/git/repositories/arc-cicd-demo-gitops
    • اترك اسم المستخدم وكلمة المرور فارغين.
    • قم بتسمية اتصال الخدمة azdo-pr-connection.
  4. حدد منح إذن الوصول إلى كافة المسارات.
    • هذا الخيار يخول ملفات تدفق YAML لاتصالات الخدمة.
  5. اختر موافق لإنشاء الاتصال.

تثبيت موصل GitOps

  1. إضافة مستودع GitOps Connector إلى مستودعات Helm:

       helm repo add gitops-connector https://azure.github.io/gitops-connector/
    
  2. تثبيت الموصل إلى نظام المجموعة:

       helm upgrade -i gitops-connector gitops-connector/gitops-connector \
          --namespace flux-system \
          --set gitRepositoryType=AZDO \
          --set ciCdOrchestratorType=AZDO \
          --set gitOpsOperatorType=FLUX \
          --set azdoGitOpsRepoName=arc-cicd-demo-gitops \
          --set azdoOrgUrl=https://dev.azure.com/<Your organization>/<Your project> \
          --set gitOpsAppURL=https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
          --set orchestratorPAT=<Azure Repos PAT token>
    

    إشعار

    Azure Repos PAT token يجب أن يكون لديك Build: Read & execute وأذونات Code: Full .

  3. تكوين Flux لإرسال إعلامات إلى موصل GitOps:

    cat <<EOF | kubectl apply -f -
    apiVersion: notification.toolkit.fluxcd.io/v1beta1
    kind: Alert
    metadata:
      name: gitops-connector
      namespace: flux-system
    spec:
      eventSeverity: info
      eventSources:
      - kind: GitRepository
        name: cluster-config
      - kind: Kustomization
        name: cluster-config-cluster-config 
      providerRef:
        name: gitops-connector
    ---
    apiVersion: notification.toolkit.fluxcd.io/v1beta1
    kind: Provider
    metadata:
      name: gitops-connector
      namespace: flux-system
    spec:
      type: generic
      address: http://gitops-connector:8080/gitopsphase
    EOF
    

للحصول على تفاصيل حول التثبيت، راجع مستودع GitOps Connector .

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

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

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

عامل القيمة‬
AZURE_SUBSCRIPTION (اتصال خدمة Azure، والذي يجب أن يكون arc-demo-acr من وقت سابق في البرنامج التعليمي)
AZ_ACR_NAME اسم Azure ACR، على سبيل المثال arc-demo-acr
ENVIRONMENT_NAME Dev
MANIFESTS_BRANCH master
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
VOTE_APP_TITLE تطبيق التصويت
AKS_RESOURCE_GROUP مجموعة موارد AKS. مطلوب للاختبار التلقائي.
AKS_NAME اسم AKS. مطلوب للاختبار التلقائي.

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

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

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

إنشاء بيئات

في مشروع Azure DevOps الخاص بك، أنشئ Dev وبيئات Stage . للحصول على التفاصيل، راجع إنشاء بيئة واستهدافها.

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

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

  1. انتقل إلى Project settings من الصفحة الرئيسية لمشروع Azure DevOps.
  2. حدد Repos/Repositories.
  3. حدد Security.
  4. <Project Name> Build Service (<Organization Name>) ل و ل Project Collection Build Service (<Organization Name>) (اكتب في حقل البحث، إذا لم يظهر)، اسمح ContributeContribute to pull requestsو و.Create branch
  5. انتقل إلى Pipelines/Settings
  6. خيار إيقاف Protect access to repositories in YAML pipelines التشغيل

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

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

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

تدفق CI

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

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

تدفق CI:

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

تدفق CD

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

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

تلميح

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

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

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

  1. ابحث عن PR الذي تم إنشاؤه بواسطة البنية الأساسية لبرنامج ربط العمليات التجارية إلى مستودع GitOps.

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

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

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

  5. راقب حالة Git Commit في علامة التبويب Commit history. بمجرد أن يكون ، succeededيبدأ مسار CD الاختبار التلقائي.

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

    kubectl port-forward -n dev svc/azure-vote-front 8080:80
    
  7. اعرض تطبيق Azure Vote في المستعرض الخاص بك على http://localhost:8080/.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

إشعار

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

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

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

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

تلميح

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

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

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

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

اكتمل النشر الآن.

للحصول على نظرة عامة مفصلة على جميع الخطوات والتقنيات التي تم تنفيذها في مهام سير عمل CI/CD المستخدمة في هذا البرنامج التعليمي، راجع الرسم التخطيطي لتدفق Azure DevOps GitOps.

تنفيذ CI/CD باستخدام GitHub

يفترض هذا البرنامج التعليمي الإلمام ب GitHub وGitHub Actions.

تطبيق التشعب ومستودعات GitOps

نسخ مستودع تطبيق ومستودع GitOps. في هذا البرنامج التعليمي، استخدم المثال التالي للمستودعات:

توصيل مستودع GitOps

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

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

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

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

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

  1. إنشاء اتصال GitOps جديد بمستودع arc-cicd-demo-gitops المتشعب حديثا في GitHub.

    az k8s-configuration flux create \
       --name cluster-config \
       --cluster-name arc-cicd-cluster \
       --namespace cluster-config \
       --resource-group myResourceGroup \
       -u  https://github.com/<Your organization>/arc-cicd-demo-gitops.git \
       --https-user <Azure Repos username> \
       --https-key <Azure Repos PAT token> \
       --scope cluster \
       --cluster-type connectedClusters \
       --branch master \
       --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests
    
  2. تحقق من حالة النشر في مدخل Azure.

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

تثبيت موصل GitOps

  1. إضافة مستودع GitOps Connector إلى مستودعات Helm:

       helm repo add gitops-connector https://azure.github.io/gitops-connector/
    
  2. تثبيت الموصل إلى نظام المجموعة:

       helm upgrade -i gitops-connector gitops-connector/gitops-connector \
          --namespace flux-system \
          --set gitRepositoryType=GITHUB \
          --set ciCdOrchestratorType=GITHUB \
          --set gitOpsOperatorType=FLUX \
          --set gitHubGitOpsRepoName=arc-cicd-demo-src \
          --set gitHubGitOpsManifestsRepoName=arc-cicd-demo-gitops \
          --set gitHubOrgUrl=https://api.github.com/repos/<Your organization> \
          --set gitOpsAppURL=https://github.com/<Your organization>/arc-cicd-demo-gitops/commit \
          --set orchestratorPAT=<GitHub PAT token>
    
  3. تكوين Flux لإرسال إعلامات إلى موصل GitOps:

    cat <<EOF | kubectl apply -f -
    apiVersion: notification.toolkit.fluxcd.io/v1beta1
    kind: Alert
    metadata:
      name: gitops-connector
      namespace: flux-system
    spec:
      eventSeverity: info
      eventSources:
      - kind: GitRepository
        name: cluster-config
      - kind: Kustomization
        name: cluster-config-cluster-config
      providerRef:
        name: gitops-connector
    ---
    apiVersion: notification.toolkit.fluxcd.io/v1beta1
    kind: Provider
    metadata:
      name: gitops-connector
      namespace: flux-system
    spec:
      type: generic
      address: http://gitops-connector:8080/gitopsphase
    EOF
    

للحصول على تفاصيل حول التثبيت، راجع مستودع GitOps Connector .

إنشاء بيانات سرية في GitHub

إنشاء أسرار مستودع GitHub

سر القيمة‬
AZURE_CREDENTIALS بيانات اعتماد Azure بالتنسيق التالي {"clientId":"GUID","clientSecret":"GUID","subscriptionId":"GUID","tenantId":"GUID"}
AZ_ACR_NAME اسم Azure ACR، على سبيل المثال arc-demo-acr
MANIFESTS_BRANCH master
MANIFESTS_FOLDER arc-cicd-cluster
MANIFESTS_REPO https://github.com/your-organization/arc-cicd-demo-gitops
VOTE_APP_TITLE تطبيق التصويت
AKS_RESOURCE_GROUP مجموعة موارد AKS. مطلوب للاختبار التلقائي.
AKS_NAME اسم AKS. مطلوب للاختبار التلقائي.
بات رمز GitHub PAT المميز مع إذن PR إلى مستودع GitOps

إنشاء أسرار بيئة GitHub

  1. إنشاء az-vote-app-dev بيئة مع الأسرار التالية:
سر القيمة‬
ENVIRONMENT_NAME Dev
TARGET_NAMESPACE dev
  1. إنشاء az-vote-app-stage بيئة مع الأسرار التالية:
سر القيمة‬
ENVIRONMENT_NAME مرحلة
TARGET_NAMESPACE stage

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

سير عمل CI/CD Dev

لبدء سير عمل CI/CD Dev، قم بتغيير التعليمات البرمجية المصدر. في مستودع التطبيق، قم بتحديث القيم في .azure-vote/src/azure-vote-front/config_file.cfg الملف ودفع التغييرات إلى المستودع.

سير عمل CI/CD Dev:

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

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

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

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

  5. راقب حالة Git Commit في علامة التبويب Commit history. بمجرد أن يكون ، succeededCD Stage سيبدأ سير العمل.

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

    kubectl port-forward -n dev svc/azure-vote-front 8080:80
    
  7. اعرض تطبيق Azure Vote في المستعرض الخاص بك على http://localhost:8080/.

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

سير عمل مرحلة CD

يبدأ سير عمل مرحلة CD تلقائيا بمجرد أن ينشر Flux التطبيق بنجاح إلى بيئة التطوير ويعلم إجراءات GitHub عبر GitOps Connector.

سير عمل مرحلة CD:

  • تشغيل اختبارات دخان التطبيق مقابل بيئة التطوير
  • نشر التطبيق إلى بيئة المرحلة.
    • إنشاء بيانات إلى مستودع GitOps
    • إنشاء طلب السحب إلى مستودع GitOps للموافقة عليه

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

للحصول على نظرة عامة مفصلة على جميع الخطوات والتقنيات التي تم تنفيذها في مهام سير عمل CI/CD المستخدمة في هذا البرنامج التعليمي، راجع الرسم التخطيطي GitHub GitOps Flow.

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

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

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

    az k8s-configuration flux delete \
          --name cluster-config \
          --cluster-name arc-cicd-cluster \
          --resource-group myResourceGroup \
          -t connectedClusters --yes
    
  2. حذف موصل GitOps:

    helm uninstall gitops-connector -n flux-system
    kubectl delete alerts.notification.toolkit.fluxcd.io gitops-connector -n flux-system
    kubectl delete providers.notification.toolkit.fluxcd.io  gitops-connector -n flux-system
    

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

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

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