تحرير

إنشاء مسار CI/CD للخدمات المصغرة على Kubernetes باستخدام Azure DevOps وHelm

Azure Kubernetes Service (AKS)
Azure Container Registry
Azure DevOps

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

توضح هذه المقالة مثالاً للبنية الأساسية لبرنامج ربط العمليات التجارية التكامل المستمر/ التسليم المستمر لتوزيع الخدمات المصغرة إلىAzure Kubernetes Service (AKS). يختلف كل فريق ومشروع عن الآخر، لذلك لا تأخذ هذه المقالة كمجموعة من القواعد الصارمة والسريعة. بدلاً من ذلك، من المفترض أن تكون نقطة انطلاق لتصميم عملية التكامل المستمر/ التسليم المستمر الخاصة بك.

يمكن تلخيص أهداف البنية الأساسية لبرنامج ربط العمليات التجارية للتكامل المستمر/ التسليم المستمر للخدمات الصغيرة المستضافة في Kubernetes على النحو التالي:

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

لمزيد من المعلومات الأساسية، راجع CI/CD for microservices architectures.

الافتراضات

لأغراض هذا المثال، إليك بعض الافتراضات حول فريق التطوير وقاعدة التعليمة البرمجية:

  • مستودع التعليمة البرمجية هو monorepo، مع مجلدات منظمة بواسطة الخدمات المصغرة.
  • تعتمد إستراتيجية تفرّع الفريق على التطوير المستند إلى الجذع.
  • يستخدم الفريق فروع الإصدار لإدارة الإصدارات. يتم إنشاء إصدارات منفصلة لكل خدمة مصغرة.
  • تستخدم عملية التكامل المستمر/ التسليم المستمر Azure Pipelines لإنشاء الخدمات المصغرة واختبارها وتوزيعها إلى AKS.
  • يتم تخزين صور الحاوية لكل خدمة مصغرة في Azure Container Registry.
  • يستخدم الفريق مخططات Helm لتجميع كل خدمة مصغرة.
  • يتم استخدام نموذج نشر الدفع، حيث تقوم Azure Pipelines والوكلاء المرتبطون بإجراء عمليات التوزيع عن طريق الاتصال مباشرة بمجموعة AKS.

تدفع هذه الافتراضات العديد من التفاصيل المحددة للبنية الأساسية لبرنامج ربط العمليات التجارية للتكامل المستمر/ التسليم المستمر. ومع ذلك، فإن النهج الأساسي الموصوف هنا يتم تكييفه للعمليات والأدوات والخدمات الأخرى، مثل Jenkins أو Docker Hub.

البدائل

فيما يلي البدائل الشائعة التي قد يستخدمها العملاء عند اختيار استراتيجية CI/CD مع Azure Kubernetes Service:

  • كبديل لاستخدام Helm كأداة لإدارة الحزم ونشرها، Kustomize هي أداة إدارة تكوين أصلية Kubernetes تقدم طريقة خالية من القالب لتخصيص تكوين التطبيق وتحديد معلماته.
  • كبديل لاستخدام Azure DevOps لمستودعات Git وخطوط الأنابيب، يمكن استخدام مستودعات GitHub لمستودعات Git الخاصة والعامة، ويمكن استخدام إجراءات GitHub لمسارات CI/CD.
  • كبديل لاستخدام نموذج نشر الدفع، يمكن إدارة تكوين Kubernetes على نطاق واسع باستخدام GitOps (نموذج نشر السحب)، حيث يقوم عامل تشغيل Kubernetes داخل المجموعة بمزامنة حالة نظام المجموعة، استنادا إلى التكوين المخزن في مستودع Git.

بنيات التحقق من الصحة

افترض أن مطورًا يعمل على خدمة مصغرة تسمى خدمة التسليم. أثناء تطوير ميزة جديدة، يتحقق المطور من التعليمة البرمجية في فرع الميزة. حسب الاصطلاح، يتم تسمية فروع الميزات feature/*.

CI/CD workflow

يتضمن ملف تعريف الإنشاء مشغلًا يقوم بالتصفية حسب اسم الفرع ومسار المصدر:

trigger:
  batch: true
  branches:
    include:
    # for new release to production: release flow strategy
    - release/delivery/v*
    - refs/release/delivery/v*
    - master
    - feature/delivery/*
    - topic/delivery/*
  paths:
    include:
    - /src/shipping/delivery/

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

  1. أنشأ التعليمة البرمجية.
  2. قم بتشغيل اختبارات الوحدة.

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

  1. أنشأ التعليمة البرمجية.
  2. قم بتشغيل اختبارات الوحدة.
  3. قم بإنشاء صورة حاوية وقت التشغيل.
  4. قم بإجراء عمليات فحص الثغرة الأمنية على الصورة.

Diagram showing ci-delivery-full in the Build pipeline.

إشعار

في Azure DevOps Repos، يمكنك تحديد النُهج لحماية الفروع. على سبيل المثال، قد يتطلب النهج إنشاء تكامل مستمر ناجحًا بالإضافة إلى تسجيل الخروج من أحد الموافقين من أجل الدمج في الشكل الرئيسي.

إنشاء التكامل المستمر الكامل/ التسليم المستمر

في مرحلة ما، يكون الفريق جاهزًا لتوزيع إصدار جديد من خدمة التسليم. يقوم مدير الإصدار بإنشاء فرع من الفرع الرئيسي بنمط التسمية هذا: release/<microservice name>/<semver>. على سبيل المثال، release/delivery/v1.0.2

Diagram showing ci-delivery-full in the Build pipeline and cd-delivery in the Release pipeline.

يؤدي إنشاء هذا الفرع إلى إنشاء التكامل المستمر الكامل الذي يعمل على تشغيل جميع الخطوات السابقة بالإضافة إلى:

  1. دفع الصورة إلى Azure Container Registry. يتم تمييز الصورة برقم الإصدار المأخوذ من اسم الفرع.
  2. قم بتشغيل helm package لحزم المخطط البياني Helm للخدمة. تم تمييز المخطط البياني أيضًا برقم إصدار.
  3. ادفع حزمة Helm إلى Container Registry.

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

  1. قم بتوزيع مخطط Helm في بيئة تأكيد الجودة.
  2. يقبل المُوافق قبل أن تنتقل الحزمة إلى التشغيل. راجع Release deployment control using approvals.
  3. أعد وضع علامة على صورة Docker لمساحة اسم التشغيل فيAzure Container Registry. على سبيل المثال، إذا كانت العلامة الحالية هي myrepo.azurecr.io/delivery:v1.0.2، فإن علامة التشغيل هي myrepo.azurecr.io/prod/delivery:v1.0.2.
  4. قم بتوزيع مخطط Helm في بيئة التشغيل.

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

عزل البيئات

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

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

عملية الإنشاء

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

باستخدام عمليات إنشاء متعددة المراحل في Docker، يمكنك تحديد بيئة الإنشاء وصورة وقت التشغيل في ملف Dockerfile واحد. على سبيل المثال، إليك Dockerfile الذي ينشئ تطبيق.Microsoft NET:

FROM mcr.microsoft.com/dotnet/core/runtime:3.1 AS base
WORKDIR /app

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src/Fabrikam.Workflow.Service

COPY Fabrikam.Workflow.Service/Fabrikam.Workflow.Service.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.csproj

COPY Fabrikam.Workflow.Service/. .
RUN dotnet build Fabrikam.Workflow.Service.csproj -c release -o /app --no-restore

FROM build AS testrunner
WORKDIR /src/tests

COPY Fabrikam.Workflow.Service.Tests/*.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.Tests.csproj

COPY Fabrikam.Workflow.Service.Tests/. .
ENTRYPOINT ["dotnet", "test", "--logger:trx"]

FROM build AS publish
RUN dotnet publish Fabrikam.Workflow.Service.csproj -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "Fabrikam.Workflow.Service.dll"]

يحدد Dockerfile هذا عدة مراحل إنشاء. لاحظ أن المرحلة المسماة base تستخدم وقت تشغيل .Microsoft .NET، بينما تستخدم المرحلة المسماة build .NET SDK بالكامل. تستخدم المرحلة build لإنشاء مشروع .Microsoft .NET. ولكن تم إنشاء حاوية وقت التشغيل النهائية من base، والتي تحتوي على وقت التشغيل فقط وهي أصغر بكثير من صورة SDK الكاملة.

إنشاء مشغل اختبار

من الممارسات الجيدة الأخرى إجراء اختبارات الوحدة في الحاوية. على سبيل المثال، فيما يلي جزء من ملف Docker الذي ينشئ مشغل اختبار:

FROM build AS testrunner
WORKDIR /src/tests

COPY Fabrikam.Workflow.Service.Tests/*.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.Tests.csproj

COPY Fabrikam.Workflow.Service.Tests/. .
ENTRYPOINT ["dotnet", "test", "--logger:trx"]

يمكن للمطور استخدام ملف Docker هذا لإجراء الاختبارات محليًا:

docker build . -t delivery-test:1 --target=testrunner
docker run delivery-test:1

يجب أن يقوم البنية الأساسية لبرنامج ربط العمليات التجارية للتكامل المستمر أيضًا بإجراء الاختبارات كجزء من خطوة التحقق من الإنشاء.

لاحظ أن هذا الملف يستخدم أمر Docker ENTRYPOINT لإجراء الاختبارات، وليس أمر Docker RUN.

  • إذا كنت تستخدم الأمر RUN، فسيتم تشغيل الاختبارات في كل مرة تنشئ فيها الصورة. باستخدام ENTRYPOINT، يتم الاشتراك في الاختبارات. يتم تشغيلها فقط عندما تستهدف بشكل صريح المرحلة testrunner.
  • لا يؤدي الاختبار الفاشل إلى فشل أمر Docker build. بهذه الطريقة، يمكنك التمييز بين حالات فشل إنشاء الحاوية عن فشل الاختبار.
  • يمكن حفظ نتائج الاختبار في وحدة تخزين محمَّلة.

أفضل ممارسات الحاويات

فيما يلي بعض أفضل الممارسات الأخرى التي يجب مراعاتها بالنسبة للحاويات:

  • حدد الإصلاحات على مستوى المؤسسة لعلامات الحاوية وتعيين الإصدار واصلاحات التسمية للموارد التي تم توزيعها في نظام المجموعة (pods والخدمات وما إلى ذلك). يمكن أن يسهل ذلك تشخيص مشاكل التوزيع.

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

  • قم بالتوزيع الدائم لعلامات إصدار حاوية محددة، وليس latest.

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

  • اتبع مبدأ الامتياز الأقل عن طريق تشغيل الحاويات كمستخدم غير متميز. في Kubernetes، يمكنك إنشاء نهج أمان pod تمنع تشغيل الحاويات كـ جذر.

مخططات Helm

ضع في اعتبارك استخدام Helm لإدارة خدمات الإنشاء وتوزيعها. فيما يلي بعض ميزات Helm التي تساعد في التكامل المستمر/ التسليم المستمر:

  • غالبًا ما يتم تحديد خدمة صغيرة واحدة بواسطة عناصر Kubernetes متعددة. يسمح Helm بتجميع هذه العناصر في مخطط Helm واحد.
  • يمكن توزيع المخطط باستخدام أمر Helm واحد بدلاً من سلسلة من أوامر kubectl.
  • تم إصدار المخططات بشكل صريح. استخدم Helm لإصدار إصدار وعرض الإصدارات والعودة إلى الإصدار السابق. تتبع التحديثات والمراجعات، باستخدام الإصدارات الدلالية، إلى جانب القدرة على العودة إلى الحالة السابقة للإصدار السابق.
  • تستخدم مخططات Helm القوالب لتجنب تكرار المعلومات، مثل التسميات والمحددات، عبر العديد من الملفات.
  • يمكن أن يدير Helm التبعيات بين المخططات.
  • يمكن تخزين المخططات في مستودع Helm، مثلAzure Container Registry، وتكاملها في البنية الأساسية لبرنامج ربط العمليات التجارية للإنشاء.

لمزيد من المعلومات حول استخدام Container Registry كمستودع Helm، راجع Use Azure Container Registry as a Helm repository for your application charts.

قد تتضمن خدمة صغيرة واحدة عدة ملفات تكوين Kubernetes. يمكن أن يعني تحديث الخدمة لمس كل هذه الملفات لتحديث المحددات والتسميات وعلامات الصور. يتعامل Helm مع هذه الحزمة على أنها حزمة واحدة تسمى مخططًا ويسمح لك بتحديث ملفات YAML بسهولة باستخدام المتغيرات. يستخدم Helm لغة نموذج (بناءً على قوالب Go) للسماح لك بكتابة ملفات تكوين YAML ذات المعلمات.

على سبيل المثال، هذا جزء من ملف YAML يحدد عملية التوزيع:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "package.fullname" . | replace "." "" }}
  labels:
    app.kubernetes.io/name: {{ include "package.name" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
  annotations:
    kubernetes.io/change-cause: {{ .Values.reason }}

...

  spec:
      containers:
      - name: &package-container_name fabrikam-package
        image: {{ .Values.dockerregistry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        env:
        - name: LOG_LEVEL
          value: {{ .Values.log.level }}

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

helm install $HELM_CHARTS/package/ \
     --set image.tag=0.1.0 \
     --set image.repository=package \
     --set dockerregistry=$ACR_SERVER \
     --namespace backend \
     --name package-v0.1.0

على الرغم من أن البنية الأساسية لبرنامج ربط العمليات التجارية للتكامل المستمر/ التسليم المستمر الخاصة بك يمكنها تثبيت مخطط مباشرة على Kubernetes، فإننا نوصي بإنشاء أرشيف مخطط (ملف .tgz) ودفع المخطط إلى مستودع Helm مثل Azure Container Registry. لمزيد من المعلومات، راجع Package Docker-based apps in Helm charts in Azure Pipelines.

مراجعات

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

helm install <package-chart-name> --version <desiredVersion>

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "delivery.fullname" . | replace "." "" }}
  labels:
     ...
  annotations:
    kubernetes.io/change-cause: {{ .Values.reason }}

يتيح لك هذا عرض حقل سبب التغيير لكل مراجعة، باستخدام الأمر kubectl rollout history. في المثال السابق، تم تقديم سبب التغيير كمعلمة مخطط Helm.

kubectl rollout history deployments/delivery-v010 -n backend

deployment.extensions/delivery-v010
REVISION  CHANGE-CAUSE
1         Initial deployment

يمكنك أيضًا استخدام الأمر helm list لعرض محفوظات المراجعة:

helm list

NAME            REVISION    UPDATED                     STATUS        CHART            APP VERSION     NAMESPACE
delivery-v0.1.0 1           Sun Apr  7 00:25:30 2020    DEPLOYED      delivery-v0.1.0  v0.1.0          backend

Azure DevOps Pipeline

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

استنادًا إلى تدفق التكامل المستمر الموضح سابقًا في هذه المقالة، قد تتكون البنية الأساسية لبرنامج ربط العمليات التجارية للإنشاء من المهام التالية:

  1. قم بإنشاء حاوية مشغل الاختبار.

    - task: Docker@1
  inputs:
    azureSubscriptionEndpoint: $(AzureSubscription)
    azureContainerRegistry: $(AzureContainerRegistry)
    arguments: '--pull --target testrunner'
    dockerFile: $(System.DefaultWorkingDirectory)/$(dockerFileName)
    imageName: '$(imageName)-test'

  2. قم بإجراء الاختبارات، من خلال استدعاء تشغيل docker مقابل حاوية مشغل الاختبار.

    - task: Docker@1
  inputs:
    azureSubscriptionEndpoint: $(AzureSubscription)
    azureContainerRegistry: $(AzureContainerRegistry)
    command: 'run'
    containerName: testrunner
    volumes: '$(System.DefaultWorkingDirectory)/TestResults:/app/tests/TestResults'
    imageName: '$(imageName)-test'
    runInBackground: false

  3. قم بتوزيع نتائج الاختبار. راجع Build an image.

    - task: PublishTestResults@2
  inputs:
    testResultsFormat: 'VSTest'
    testResultsFiles: 'TestResults/*.trx'
    searchFolder: '$(System.DefaultWorkingDirectory)'
    publishRunAttachments: true

  4. قم بإنشاء حاوية وقت التشغيل.

    - task: Docker@1
  inputs:
    azureSubscriptionEndpoint: $(AzureSubscription)
    azureContainerRegistry: $(AzureContainerRegistry)
    dockerFile: $(System.DefaultWorkingDirectory)/$(dockerFileName)
    includeLatestTag: false
    imageName: '$(imageName)'

  5. ادفع صورة الحاوية إلى Azure Container Registry (أو سجل حاوية آخر).

    - task: Docker@1
  inputs:
    azureSubscriptionEndpoint: $(AzureSubscription)
    azureContainerRegistry: $(AzureContainerRegistry)
    command: 'Push an image'
    imageName: '$(imageName)'
    includeSourceTags: false

  6. قم بتعبئة مخطط Helm.

    - task: HelmDeploy@0
  inputs:
    command: package
    chartPath: $(chartPath)
    chartVersion: $(Build.SourceBranchName)
    arguments: '--app-version $(Build.SourceBranchName)'

  7. ادفع حزمة Helm إلى Azure Container Registry (أو مستودع Helm آخر).

    task: AzureCLI@1
  inputs:
    azureSubscription: $(AzureSubscription)
    scriptLocation: inlineScript
    inlineScript: |
    az acr helm push $(System.ArtifactsDirectory)/$(repositoryName)-$(Build.SourceBranchName).tgz --name $(AzureContainerRegistry);

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

  • انشر مخطط Helm إلى بيئات التطوير/QA/التقسيم المرحلي. Helm upgrade يمكن استخدام الأمر مع العلامة --install لدعم التثبيت الأول والترقيات اللاحقة.
  • انتظر حتى يوافق الموافق على التوزيع أو يرفضه.
  • إعادة وضع علامة على صورة الحاوية للإصدار
  • ادفع علامة الإصدار إلى سجل الحاوية.
  • نشر مخطط Helm في مجموعة الإنتاج.

لمزيد من المعلومات حول إنشاء البنية الأساسية لبرنامج ربط العمليات التجارية للإصدار، راجع Release pipelines, draft releases, and release options.

يوضح الرسم التخطيطي التالي العملية الشاملة للتكامل المستمر/ التسليم الموضحة في هذه المقالة:

CD/CD pipeline

المساهمون

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

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

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

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