بناء أنابيب Azure DevOps الحقيقية لقوالب ARM – techsyncer

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

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

بحلول نهاية هذا المشروع ، ستحصل على سلسلة Azure تعمل بشكل كامل. من مسودة واحدة في مستودع GitHub ، ستقوم بما يلي:

إنشاء مجموعة موارد Azure مؤقتة
توفير Azure VM عبر قالب ARM
إعداد قالب ARM المذكور في سلسلة CI/CD
عند أي تغيير في القالب ، قم ببدء اختبار التحقق من الصحة
نشر قالب ARM إلى Azure
اختبار البنية التحتية المنشأة
تفكيك جميع موارد Azure

لنقم بالانتقال مباشرةً إلى المشروع!

نظرة عامة على المشروع

سيتم تقسيم هذا المشروع إلى ستة أقسام رئيسية. هم:

إعداد موارد Azure

في هذا القسم ، ستتعلم كيفية إعداد جميع الموارد الأساسية في Azure. هنا ستقوم بما يلي:

إنشاء كيان خدمة Azure لمهام مختلفة في الخط الزمني
إعداد “Azure Key Vault” مع الأسرار التي يستخدمها الخط الزمني
تعيين سياسات وصول مناسبة لنشر ARM واستخدام الخط الزمني

إعداد Azure DevOps

بمجرد إعداد جميع موارد Azure الخاصة بك، حان الوقت لإعداد Azure DevOps للخط الزمني الخاص بك. في هذا القسم، ستقوم بما يلي:

تثبيت مهمة بناء “Pester Test Runner” في منظمة Azure DevOps الخاصة بك
إنشاء اتصالات الخدمة لتوفير الوصول المطلوب إلى الموارد في Azure DevOps
إنشاء مجموعة متغيرات “Azure DevOps” تربط “Key Vault” للوصول إلى أسرار “Azure Key Vault”

نظرة عامة على البرنامج النصي/القالب

هناك العديد من القطع التي تأتي مع هذا المشروع بما في ذلك قالب ARM لبناء الخادم واختبارات Pester. في هذا القسم ، سنغطي بإيجاز ما يقوم القالب بتوفيره وما الذي يختبره بالضبط Pester في الخط الزمني.

إنشاء خط الإنتاج

في هذا القسم يبدأ المرح الحقيقي. ستبدأ في إعداد الخط الزمني الفعلي. هنا ستتعلم كيفية إعداد هذه الأوركسترا بأكملها عبر ملف YAML واحد.

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

عرض خط الإنتاج

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

التنظيف

وأخيراً ، نظرًا لأن هذا مجرد عرض توضيحي ، ستحصل على وصول إلى نص يتم استخدامه لتفكيك كل شيء تم بناؤه خلال البرنامج التعليمي.

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

إذا كنت ترغب في الحصول على نص يحتوي على جميع أوامر Azure CLI المستخدمة لبناء هذا الخط الزمني ، يمكنك العثور عليه في مستودع GitHub ServerAutomationDemo باسم demo.ps1.

المتطلبات المسبقة

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

منظمة Azure DevOps – تحقق من دليل Microsoft QuickStart للحصول على تعليمات حول كيفية القيام بذلك. في هذه المقالة ، ستعمل مع مشروع يسمى ServerAutomationDemo.
A GitHub repo – In this article, you’ll be learning from a GitHub repo called ServerAutomationDemo. Sorry, we’re not using Azure repos in this article.
A GitHub personal access token – Be sure to create the token with the permissions of admin:repo_hook, all repo and all user options.

ARM deployments allowed to access the key vault

Cloud Shell أو PowerShell 6+ إذا كنت تعمل محليًا – قد تعمل الأمثلة في Windows PowerShell ولكنها لم تتم اختبارها. ستتم تنفيذ جميع الأمثلة محليًا عبر وحدة تحكم PowerShell ولكن Cloud Shell ستعمل بنفس القدر. ستقوم بتطبيق عملية البناء تلقائيًا.
تثبيت Azure CLI (إذا كنت تعمل محليًا) – ستتعلم كيفية تنفيذ المهام في هذه المقالة باستخدام Azure CLI. ومع ذلك ، يمكن أيضًا تنفيذ نفس الإجراءات عبر بوابة Azure أو PowerShell أو Azure SDK.

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

قبل أن تبدأ

ستقوم بعمل الكثير من التكوين في هذا البرنامج التعليمي. قبل أن تبدأ ، يرجى التأكد من توفر العناصر التالية بجانبك.

اسم الاشتراك في Azure الذي سيتم نشر الموارد فيه – ستستخدم الأمثلة Adam the Automator.
هوية الاشتراك
معرّف مستأجر Azure AD
اسم منظمة DevOps – ستستخدم الأمثلة adbertram.
المنطقة التي تضع فيها الموارد – ستستخدم الأمثلة eastus.
اسم مجموعة موارد Azure لوضع الأداة المؤقتة لمفتاح الخزنة – ستستخدم الأمثلة ServerAutomationDemo.
A password to assign to the local administrator account on a deployed VM – the examples will use “I like azure.”.
عنوان URL لمستودع GitHub – ستستخدم الأمثلة https://github.com/adbertram/ServerAutomationDemo.

تسجيل الدخول باستخدام Azure CLI

كن مستعدًا للعمل مع Azure CLI بشكل كبير في المقالة. أحب أوامر Azure PowerShell ولكن Azure CLI حاليًا قادرة على القيام بمهام DevOps أكثر.

مهمتك الأولى هي الوصول إلى وحدة التحكم PowerShell 6+ . بمجرد الوصول إلى وحدة التحكم ، قم بتسجيل الدخول إلى Azure باستخدام الأمر az login. سيفتح هذا الأمر نافذة المتصفح وسيطلب منك حسابك.

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

az login
az account set --subscription 'Adam the Automator'

إعداد موارد Azure

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

تثبيت تمديد Azure CLI DevOps

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

لحسن الحظ ، يتم تثبيت التمديد في سطر واحد كما هو موضح أدناه.

az extension add --name azure-devops

بمجرد تثبيت التمديد ، قم بتعيين المنظمة الخاصة بك كافتراضية لمنع تحديدها مرارًا وتكرارًا.

az devops configure --defaults organization=https://dev.azure.com/adbertram

إنشاء مجموعة الموارد

على الرغم من أن الخط الأنابيب سيقوم بإنشاء مجموعة موارد مؤقتة ، يجب أيضًا إنشاء واحدة لأي موارد يتم إنشاؤها في هذا العرض التوضيحي. على وجه التحديد ، ستقوم بإنشاء مجموعة موارد Azure Key Vault في هذه المجموعة.

az group create --location "eastus" --name "ServerAutomationDemo"

إنشاء الممثل الخدمي لـ Azure

المهمة التالية هي إنشاء خدمة رئيسية في Azure. ستحتاج إلى خدمة رئيسية في Azure للمصادقة على Azure Key Vault. ستستخدم هذه الخدمة الرئيسية أيضًا للمصادقة على اتصال الخدمة. قم بإنشاء الخدمة الرئيسية لكل من Key Vault ونشر ARM النهائي كما هو موضح أدناه.

$spIdUri = "http://ServerAutomationDemo"
$sp = az ad sp create-for-rbac --name $spIdUri | ConvertFrom-Json

في هذه النقطة ، سيكون من الجيد حفظ قيمة $sp.appId في مكان ما. عندما تصل إلى بناء الأنابيب لاحقًا ، ستحتاج إلى هذا القيمة!

ستلاحظ بعض أوامر PowerShell في الأمثلة مثل ConvertFrom-Json. نظرًا لأن Azure CLI يعيد فقط سلاسل JSON ، من الأسهل الإشارة إلى الخصائص إذا تم تحويلها إلى كائن PowerShell.

بناء Key Vault

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

لإنشاء Key Vault ، استخدم الأمر az keyvault create على النحو الموضح أدناه. يقوم هذا الأمر بإنشاء Key Vault في مجموعة الموارد التي تم إنشاؤها مسبقًا. لاحظ أيضًا تفعيل التبديل enabled-for-template-deployment. يقوم هذا بتغيير سياسة وصول Key Vault للسماح لنشر ARM المستقبلي بالوصول إلى Key Vault.

az keyvault create --location $region --name "ServerAutomationDemo-KV" --resource-group "ServerAutomationDemo" --enabled-for-template-deployment true

إنشاء أسرار Key Vault

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

az keyvault secret set --name "ServerAutomationDemo-AppPw" --value $sp.password --vault-name "ServerAutomationDemo-KV"
az keyvault secret set --name StandardVmAdminPassword --value "I like azure." --vault-name "ServerAutomationDemo-KV"

يرجى ملاحظة أنك تستخدم متغيرات PowerShell المعرفة مسبقًا في هذا المثال. هنا تقوم بتوفير كلمة مرور المسؤول الخدمة ($sp.password) التي تم الحصول عليها سابقًا.

السماح لخط الأنابيب بالوصول إلى مستودع المفاتيح

في الخطوة التالية ، يحتاج خط الأنابيب إلى إذن للوصول إلى مستودع المفاتيح. قم بتخفيف سياسة وصول مستودع المفاتيح قليلاً. قم بتوفير المشروع الخدمة الرئيسية التي تم إنشاؤها بأذونات get و list لإدارة أسرار مستودع المفاتيح.

az keyvault set-policy --name "ServerAutomationDemo-KV" --spn $spIdUri --secret-permissions get list

إعداد Azure DevOps

لقد قمت الآن بإعداد جميع استعدادات موارد Azure. حان الوقت للقيام ببعض الأعمال التحضيرية في Azure DevOps.

تثبيت امتداد Pester

أول مهمة للقيام بها هي تثبيت امتداد PesterRunner في Azure DevOps. سيقوم خط الأنابيب بتشغيل مجموعتين من اختبارات Pester للتحقق من نجاح نشر VM ARM. أحد أسهل الطرق لتشغيل اختبارات Pester هو باستخدام امتداد PesterRunner.

قم بتثبيت الامتداد باستخدام الأمر أدناه.

az devops extension install --extension-id PesterRunner --publisher-id Pester

إنشاء مشروع Azure DevOps

حان الوقت لإنشاء المشروع الذي سيتم إنشاء خط الأنابيب فيه. إن إنشاء خط أنابيب Azure DevOps أمر سهل باستخدام Azure CLI. قم بتشغيل الأوامر أدناه لإنشاء المشروع وتعيين المشروع كافتراضي.

az devops project create --name "ServerAutomationDemo"
az devops configure --defaults project=ServerAutomationDemo

إنشاء اتصالات الخدمة

يحتاج خط الأنابيب الخاص بك إلى المصادقة على خدمتين – ARM ومستودع GitHub الخاص بك. للقيام بذلك ، يجب إنشاء اتصالي خدمة.

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

تأكد من ملء معرف الاشتراك الخاص بك ومعرف المستأجر واستبدال اسم الاشتراك أدناه.

## قم بتشغيل $sp.password وانسخها إلى الحافظة
$sp.Password

## إنشاء نقطة النهاية الخدمية
az devops service-endpoint azurerm create --azure-rm-service-principal-id $sp.appId --azure-rm-subscription-id "YOURSUBSCRIPTIONIDHERE" --azure-rm-subscription-name 'Adam the Automator' --azure-rm-tenant-id $tenantId --name 'ARM'

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

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

$gitHubServiceEndpoint = az devops service-endpoint github create --github-url 'https://github.com/adbertram/ServerAutomationDemo' --name 'GitHub' | ConvertFrom-Json

## الصق رمز GitHub عند المطلوب

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

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

أولاً ، قم بإنشاء مجموعة المتغيرات كما هو موضح أدناه.

az pipelines variable-group create --name "ServerAutomationDemo" --authorize true --variables foo=bar

لاحظ المتغير foo=bar؟ هذا لا يستخدم ولكن متغير واحد مطلوب لإنشاء مجموعة المتغيرات.

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

في هذه النقطة ، ستضطر للانتقال إلى بوابة Azure DevOps. في وقت كتابة هذا ، ليس هناك طريقة لربط مستودع المفاتيح بمجموعة متغيرات باستخدام Azure CLI.

انتقل إلى مشروع Azure DevOps وانقر فوق المكتبة. سترى بعد ذلك مجموعة المتغيرات ServerAutomationDemo كما هو موضح أدناه. انقر فوق مجموعة المتغيرات ServerAutomationDemo.

بمجرد دخولك إلى مجموعة المتغيرات ، انقر فوق ربط الأسرار من مستودع مفاتيح Azure كمتغيرات. بمجرد القيام بذلك ، ستتلقى تحذيرًا بأنك ستقوم بمسح جميع المتغيرات وانقر على تأكيد. سترى كيفية القيام بذلك أدناه. هذا الإجراء عادي حيث كان المتغير foo مؤقتًا طوال الوقت.

بمجرد التأكيد ، حدد اتصال الخدمة ARM ومستودع المفاتيح ServerAutomationDemo-KV الذي تم إنشاؤه سابقًا كما هو موضح أدناه. انقر على إضافة.

تحقق الآن من كل من الأسرار التي تم إنشاؤها سابقًا كما هو موضح أدناه وانقر على موافق و حفظ لحفظ التغييرات.

Selecting keyvault secrets for the pipeline to use

نظرة عامة على ملفات المشروع

إذا وصلتم إلى هنا، فألف مبروك! أنت الآن جاهز للبدء في بناء الأنبوبة. ولكن انتظر… هناك المزيد!

لجعل بناء أنبوبة Azure أكثر واقعية، يقوم هذا البرنامج التعليمي ببناء أنبوبة مكتملة تتضمن اختبارات “وحدة” و”قبول”. هذا يجعل البرنامج التعليمي أكثر إثارة للاهتمام ولكنه يتطلب أيضًا بعض التوضيح الإضافي حول ما يحدث.

في مستودع GitHub لهذا البرنامج التعليمي، ستجد بعض الملفات كما هو موضح أدناه. الآن سيكون وقتًا مناسبًا لإما استنساخ هذا المستودع أو بناء نسخة خاصة بك من الصفحات.

azure-pipelines.yml – أنبوبة YAML النهائية
connect-azure.ps1 – نص PowerShell للمصادقة على اشتراك Azure
server.infrastructure.tests.ps1 – اختبار Pester بسيط للتحقق من أن تكوين VM جيد
server.json – قالب Azure ARM لتوفير VM
server.parameters.json – قالب معلمات Azure ARM يوفر للقالب ARM قيم المعلمة.

تأكد من استبدال معرف الاشتراك الخاص بك واسم حاوية المفاتيح لـ IT في ملف server.parameters.json.

server.templates.tests.ps1 – اختبارات “وحدة” Pester للتحقق من صحة قالب ARM

سترى كيفية تكامل كل هذه الملفات في الأنبوبة في وقت قريب.

إنشاء خط الأنابيب

بفرض أنك قمت بنسخ مستودع GitHub الخاص بي أو قمت بإعداد واحد بنفسك، حان الوقت لإنشاء خط الأنابيب! للقيام بذلك، قم بتشغيل الأمر az pipelines create. ينشئ الأمر أدناه خط أنابيب يسمى ServerAutomationDemo باستخدام مستودع GitHub المحدد كمشغل له. سينظر إلى فرع master وسيستخدم اتصال الخدمة الذي تم إنشاؤه سابقًا.

az pipelines create --name "ServerAutomationDemo" --repository "https://github.com/adbertram/ServerAutomationDemo" --branch master --service-connection $gitHubServiceEndpoint.id --skip-run

يعتمد ما إذا كان لديك ملف azure-pipelines.yml في مستودع GitHub الخاص بك أو لا على تلقي ملاحظات مماثلة لما يلي. على أي حال، ستكون واجهة السطر الخاصة بك مشابهة. تأكد من أن لديك رمز الوصول الشخصي الخاص بك لـ GitHub جاهزاً!

Creating the Azure DevOps pipeline with the Azure CLI

مراجعة خط الأنابيب بتنسيق YAML

في هذه النقطة، خط الأنابيب الخاص بك جاهز للتشغيل ولكن من المهم أولاً فهم خط الأنابيب بتنسيق YAML. تفحص الملف azure-pipelines.yml. هذا الملف هو خط الأنابيب عند استخدام ميزة خط الأنابيب YAML متعدد المراحل.

دعنا نقسم المكونات المختلفة التي يتكون منها خط الأنابيب بتنسيق YAML هذا.

المشغل

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

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

trigger:
  branches:
    include:
      - master
  paths:
    include:
      - server.json
      - server.parameters.json

البركة

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

pool:
  vmImage: "ubuntu-latest"

المتغيرات

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

لاحظ أيضًا عنصر group. يشير هذا العنصر إلى مجموعة المتغيرات التي قمت بإنشائها سابقًا. تأكد من استبدال subscription_id و tenant_id في هذا الوقت.

تذكر في قسم إنشاء المبدأ الخدمي في Azure تم تذكيرك بحفظ قيمة $sp.appId في مكان ما؟ هذا هو المكان الذي ستحتاج إليه. قم بتعيين قيمة تطبيق المبدأ الخدمي تلك إلى application_id كما هو موضح أدناه.

variables:
    - group: ServerAutomationDemo
    - name: azure_resource_group_name
      value: "ServerProvisionTesting-$(Build.BuildId)"
    - name: subscription_id
      value: "XXXXXXXXXXXXX"
    - name: application_id
      value: "XXXXXXXXXXXXX"
    - name: tenant_id
      value: "XXXXXXXXXXXX"

لاحظ قيمة المتغير azure_resource_group_name. داخل هذه القيمة ستجد $(Build.BuildId). هذا متغير نظام يمثل معرّف البناء للوظيفة الحالية. في هذا السياق، يتم استخدامه لضمان أن مجموعة الموارد المؤقتة التي تم إنشاؤها فريدة.

مهام التحضير باستخدام PowerShell

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

تقوم المهمة الأولى بتنفيذ سيناريو يسمى connect-azure.ps1 الموجود في مستودع GitHub. هذه المهمة تقوم بالمصادقة على الاشتراك في Azure لتنفيذ الأوامر التالية باستخدام PowerShell لـ Azure.

تتصل مهمة اتصال PowerShell بـ Azure بالسيناريو وتمرر قيمة سر الخزنة الرئيسية (ServerAutomationDemo-AppPw) ومتغيرات سلسلة النقل subscription_id و application_id و tenant_id.

تقوم المهمة الثانية بتنفيذ رمز PowerShell مضمن، مما يعني أن السيناريو غير موجود بالفعل. بدلاً من ذلك، يتم تعريف رمز PowerShell في نص سلسلة YAML باستخدام قيمة متغير السلسلة azure_resource_group_name.

- task: PowerShell@2
  inputs:
    filePath: "connect-azure.ps1"
    arguments: '-ServicePrincipalPassword "$(ServerAutomationDemo-AppPw)" -SubscriptionId $(subscription_id) -ApplicationId $(application_id) -TenantId $(tenant_id)'
- task: PowerShell@2
  inputs:
    targetType: "inline"
    script: New-AzResourceGroup -Name $(azure_resource_group_name) -Location eastus -Force

اختبار قالب Pester

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

نظرًا لأن هذه الأنبوبة المثالية تعتمد على نشر جهاز افتراضي من نوع ARM واحد، فإن “وحدات” الاختبار الأولى ستكون لاختبار صحة قالب JSON. في ملف server.templates.tests.ps1 يمكنك إضافة العديد من الاختبارات المختلفة على نفس ملف قالب ARM كما تريد.

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

مهمة PesterRunner ترسل نتائج الاختبار إلى ملف XML الذي سيتم قراءته في وقت لاحق في الأنبوبة.

- task: Pester@0
  inputs:
    scriptFolder: "@{Path='$(System.DefaultWorkingDirectory)/server.template.tests.ps1'; Parameters=@{ResourceGroupName='$(azure_resource_group_name)'}}"
    resultsFile: "$(System.DefaultWorkingDirectory)/server.template.tests.XML"
    usePSCore: true
    run32Bit: False

نشر جهاز افتراضي من نوع ARM

لقد وصلنا الآن إلى عملية نشر ARM. نظرًا لأن الأنبوبة بأكملها تعتمد على القدرة على نشر جهاز افتراضي، فإن هذه المهمة مهمة! تقوم هذه المهمة بنشر قالب ARM وتوفير جميع السمات المطلوبة لجعل ذلك يحدث.

يرجى ملاحظة السمة deploymentOutputs: arm_output. في الخطوة التالية، يحتاج المهمة إلى الاتصال بجهاز الكمبيوتر الافتراضي الذي تم نشره. طريقة رائعة للحصول على اسم DNS أو عنوان IP لهذا الجهاز الافتراضي هي عبر إرجاعه عبر عملية النشر ARM. تُنشئ خيارات deploymentOutputs متغير أنبوبة يمكن الرجوع إليه في مهام أخرى.

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    deploymentScope: "Resource Group"
    azureResourceManagerConnection: "ARM"
    subscriptionId: "1427e7fb-a488-4ec5-be44-30ac10ca2e95"
    action: "Create Or Update Resource Group"
    resourceGroupName: $(azure_resource_group_name)
    location: "East US"
    templateLocation: "Linked artifact"
    csmFile: "server.json"
    csmParametersFile: "server.parameters.json"
    deploymentMode: "Incremental"
    deploymentOutputs: "arm_output"

اختبار “القبول” باستخدام Pester

بمجرد نشر الجهاز الافتراضي، يجب التأكد من أنه تم نشره بشكل صحيح باستخدام اختبار “التكامل” أو “القبول”. تقوم مهمة PesterRunner هذه بتنشيط Pester وتشغيل مجموعة أخرى من الاختبارات المتعلقة بالبنية التحتية للتأكد من نجاح نشر الجهاز الافتراضي.

لاحظ أننا نمر بقيمة إخراج نشر ARM من خلال معلمة ArmDeploymentJsonOutput. يحتوي ملف سكريبت اختبار Pester على معلمة محددة تأخذ القيمة وتقرأ اسم المضيف DNS للجهاز الظاهري.

 - task: Pester@0
    inputs:
      scriptFolder: "@{Path='$(System.DefaultWorkingDirectory)/server.infrastructure.tests.ps1'; Parameters=@{ArmDeploymentJsonOutput='$(arm_output)'}}"
      resultsFile: "$(System.DefaultWorkingDirectory)/server.infrastructure.tests.XML"
      usePSCore: true
      run32Bit: False

يمكنك أن ترى أدناه ما يشبه السكريبت البرمجي server.infrastructure.tests.ps1 .لاحظ أنه يقرأ اسم المضيف DNS للجهاز الظاهري ثم يقوم بتشغيل فحص بسيط للمنفذ المفتوح.

$ArmDeploymentOutput = $ArmDeploymentJsonOutput | convertfrom-json

## تشغيل الاختبارات
describe 'Network Connnectivity' {
    it 'the VM has RDP/3389 open' {
        Test-Connection -TCPPort 3389 -TargetName $ArmDeploymentOutput.hostname.value -Quiet | should -Be $true
    }
}

تنظيف الاختبارات “قبول”

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

- task: PowerShell@2
  inputs:
    targetType: "inline"
    script: Get-AzResourceGroup -Name $(azure_resource_group_name) | Remove-AzResourceGroup -Force

نشر اختبار Pester

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

- task: PublishTestResults@2
  inputs:
    testResultsFormat: "NUnit"
    testResultsFiles: "$(System.DefaultWorkingDirectory)/server.infrastructure.tests.XML"
    failTaskOnFailedTests: true

- task: PublishTestResults@2
  inputs:
    testResultsFormat: "NUnit"
    testResultsFiles: "$(System.DefaultWorkingDirectory)/server.template.tests.XML"
    failTaskOnFailedTests: true

استخدام أنابيب Azure DevOps

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

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

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

تنظيف

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

أدناه ستجد بعض الأوامر لتنظيف كل شيء تم بناؤه في هذه المقالة. يزيل هذا الكود الممثل الخدمة ، تطبيق Azure AD ، مجموعة الموارد وكل شيء فيها ومشروع Azure DevOps.

$spId = ((az ad sp list --all | ConvertFrom-Json) | ? { '<https://ServerAutomationDemo>' -in $_.serviceprincipalnames }).objectId
az ad sp delete --id $spId

## قم بإزالة مجموعة الموارد
az group delete --name "ServerAutomationDemo" --yes --no-wait

## قم بإزالة المشروع
$projectId = ((az devops project list | convertfrom-json).value | where { $_.name -eq 'ServerAutomationDemo' }).id
az devops project delete --id $projectId --yes

ملخص

كان هذا البرنامج التعليمي يهدف إلى إعطائك نظرة على بناء خط أنابيب تلقائي حقيقي للبنية التحتية لـ Azure DevOps. على الرغم من أن هناك العديد من الطرق الأخرى لبناء أنابيب مثل هذه ، إلا أن المهارات التي تعلمتها في هذا البرنامج التعليمي يجب أن تساعدك في العديد من التكوينات المختلفة.

الآن ابدأ في القيام بالمزيد من التلقائي!