تطوير قوالب ARM لاتساق السحابة

مقالة
03/20/2024

هام

يتطلب استخدام ميزة Azure هذه من PowerShell ⁧AzureRM⁩ تثبيت الوحدة النمطية. هذه وحدة نمطية قديمة متوفرة فقط في إصدار ويندوز PowerShell 5.1 التي لم تعد تتلقى ميزات جديدة. الوحدات ⁧Az⁩و⁧AzureRM⁩ ليست⁧⁩متوافقة⁧⁩ عند تثبيتها لنفس إصدارات PowerShell. إذا كنت بحاجة إلى كلا الإصدارين:

⁧⁩قم بإلغاء تثبيت الوحدة النمطية Az⁧⁩ من جلسة عمل PowerShell 5.1.
⁧⁩قم بتثبيت الوحدة النمطيةAzureRM⁧⁩ في جلسة عمل PowerShell 5.1.
⁧⁩قم بتنزيل وتثبيت PowerShell Core 6.x أو أحدث⁧⁩.
⁧⁩قم بتثبيت الوحدة النمطية Az⁧⁩ فى جلسة عمل PowerShell 5.1.

من المزايا الرئيسية لـ Azure الاتساق. استثمارات التطوير لموقع واحد قابلة لإعادة الاستخدام في مكان آخر. يجعل قالب Azure Resource Manager (قالب ARM) عمليات التوزيع الخاصة بك متسقة وقابلة للتكرار عبر البيئات، بما في ذلك Azure العالمية وAzure السحابية وAzure Stack. لإعادة استخدام القوالب عبر السحابة، مع ذلك، تحتاج إلى التفكير في التبعيات الخاصة بالسحابة كما يوضح هذا الدليل.

تقدم Microsoft خدمات سحابية ذكية جاهزة للمؤسسات في العديد من المواقع، بما في ذلك:

منصة Azure العالمية مدعومة بشبكة متنامية من مراكز البيانات التي تديرها Microsoft في مناطق حول العالم.
السحب السيادية المعزولة مثل Azure Germany Azure Government وMicrosoft Azure المشغلة بواسطة 21Vianet. توفر السحابات السيادية نظاماً أساسياً متسقاً مع معظم الميزات الرائعة نفسها التي يمكن لعملاء Azure العالميين الوصول إليها.
Azure Stack، نظام أساسي سحابي مختلط يتيح لك تقديم خدمات Azure من مركز بيانات مؤسستك. يمكن للمؤسسات إعداد Azure Stack في مراكز البيانات الخاصة بها، أو استهلاك خدمات Azure من موفري الخدمة، وتشغيل Azure Stack في منشآتهم (المعروفة أحياناً بالمناطق المستضافة).

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

رسم تخطيطي لبيئات Azure المختلفة بما في ذلك Azure العالمية والسحب السيادية وAzure Stack.

يساعدك تناسق Azure العالمي والسحب السيادية والسحب المستضافة والسحابة في مركز البيانات على الاستفادة من Azure Resource Manager. يمكنك إعادة استخدام استثمارات التطوير الخاصة بك عبر هذه السحابة عند إعداد توزيع وتكوين الموارد المستندة إلى القوالب.

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

يصف الجزء المتبقي من هذا الدليل المجالات التي يجب مراعاتها عند التخطيط لتطوير قوالب ARM جديدة أو تحديثها لـ Azure Stack. بشكل عام، يجب أن تتضمن قائمة التحقق الخاصة بك العناصر التالية:

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

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

تأكد من عمل وظائف القالب

الصيغة الأساسية لقالب ARM هي JSON. تستخدم القوالب مجموعة شاملة من JSON، لتوسيع البنية باستخدام التعبيرات والوظائف. يتم تحديث معالج لغة القالب بشكل متكرر لدعم وظائف القالب الإضافية. للحصول على شرح مفصل لوظائف القالب المتاحة، راجع وظائف قالب ARM.

وظائف القالب الجديدة التي تم تقديمها إلى Azure Resource Manager ليست متاحة على الفور في السحابات السيادية أو Azure Stack. لتوزيع قالب بنجاح، يجب أن تكون جميع الوظائف المشار إليها في القالب متاحة في السحابة الهدف.

سيتم دائماً تقديم إمكانات Azure Resource Manager إلى Azure العالمي أولاً. يمكنك استخدام البرنامج النصي PowerShell التالي للتحقق مما إذا كانت وظائف القالب المقدمة حديثاً متوفرة أيضاً في Azure Stack:

اصنع نسخة من مستودع GitHub: https://github.com/marcvaneijk/arm-template-functions.
بمجرد أن تكون لديك نسخة محلية من المستودع، اتصل بـ Azure Resource Manager للوجهة باستخدام PowerShell.

قم باستيراد وحدة psm1 وقم بتنفيذ الأمر Test-AzureRmTemplateFunctions cmdlet:

# Import the module
Import-module <path to local clone>\AzTemplateFunctions.psm1

# Execute the Test-AzureRmTemplateFunctions cmdlet
Test-AzureRmTemplateFunctions -path <path to local clone>

يتوزيع البرنامج النصي عدة قوالب مصغرة، يحتوي كل منها على وظائف قالب فريدة فقط. يُبلغ ناتج البرنامج النصي عن وظائف القالب المدعومة وغير المتاحة.

العمل مع القطع الأثرية المرتبطة

يمكن أن يحتوي القالب على مراجع للعناصر المرتبطة ويحتوي على مورد توزيع يرتبط بقالب آخر. يتم استرداد القوالب المرتبطة (يشار إليها أيضاً باسم القالب المتداخل) بواسطة Resource Manager في وقت التشغيل. يمكن أن يحتوي القالب أيضاً على مراجع للقطع الأثرية لملحقات الجهاز الظاهري (VM). يتم استرداد هذه القطع الأثرية بواسطة ملحق VM الذي يعمل داخل الجهاز الظاهري لتكوين امتداد VM أثناء توزيع القالب.

تصف الأقسام التالية اعتبارات تناسق السحابة عند تطوير القوالب التي تتضمن عناصر خارجة عن قالب التوزيع الرئيسي.

استخدم القوالب المتداخلة عبر المناطق

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

يوضح التعليمة البرمجية التالي كيف تشير معلمة templateLink إلى قالب متداخل:

"resources": [
  {
     "type": "Microsoft.Resources/deployments",
     "apiVersion": "2020-10-01",
     "name": "linkedTemplate",
     "properties": {
       "mode": "incremental",
       "templateLink": {
          "uri":"https://mystorageaccount.blob.core.windows.net/AzureTemplates/vNet.json",
          "contentVersion":"1.0.0.0"
       }
     }
  }
]

يقوم Azure Resource Manager بتقييم القالب الرئيسي في وقت التشغيل واسترداد كل قالب متداخل وتقييمه. بعد استرداد جميع القوالب المتداخلة، يتم تسوية القالب، وبدء المعالجة الإضافية.

اجعل القوالب المرتبطة يمكن الوصول إليها عبر السحب

ضع في اعتبارك مكان وكيفية تخزين أي قوالب مرتبطة تستخدمها. في وقت التشغيل، يجلب Azure Resource Manager - وبالتالي يتطلب وصولاً مباشراً - إلى أي قوالب مرتبطة. من الممارسات الشائعة استخدام GitHub لتخزين القوالب المتداخلة. يمكن أن يحتوي مستودع GitHub على ملفات يمكن الوصول إليها بشكل عام من خلال عنوان URL. على الرغم من أن هذه التقنية تعمل بشكل جيد مع السحابة العامة والسحابات السيادية، إلا أن بيئة Azure Stack قد تكون موجودة على شبكة شركة أو في موقع بعيد غير متصل، دون أي وصول خارجي إلى الإنترنت. في هذه الحالات، قد يفشل Azure Resource Manager في استرداد القوالب المتداخلة.

أفضل ممارسة لعمليات التوزيع عبر السحابة هي تخزين القوالب المرتبطة في موقع يمكن الوصول إليه للسحابة المستهدفة. من الناحية المثالية، يتم الاحتفاظ بجميع أدوات التوزيع وتوزيعها من خط أنابيب التكامل / التطوير المستمر (CI / CD). بدلاً من ذلك، يمكنك تخزين القوالب المتداخلة في حاوية تخزين البيانات الثنائية الكبيرة، والتي يمكن لـ Azure Resource Manager استردادها منها.

نظراً لأن تخزين البيانات الثنائية الكبيرة (blob) على كل سحابة تستخدم اسم مجال مختلفاً مؤهلاً بالكامل (FQDN)، قم بتكوين القالب بموقع القوالب المرتبطة مع معلمتين. يمكن أن تقبل المعلمات إدخال المستخدم في وقت التوزيع. عادةً ما يتم تأليف القوالب ومشاركتها بواسطة عدة أشخاص، لذا فإن أفضل ممارسة هي استخدام اسم قياسي لهذه المعلمات. تساعد اصطلاحات التسمية في جعل القوالب أكثر قابلية لإعادة الاستخدام عبر المناطق والسحب والمؤلفين.

في التعليمات البرمجية التالية، يتم استخدام _artifactsLocation للإشارة إلى موقع واحد، يحتوي على جميع العناصر المتعلقة بالتوزيع. لاحظ أنه تم توفير قيمة افتراضية. في وقت التوزيع، إذا لم يتم تحديد قيمة إدخال لـ _artifactsLocation، يتم استخدام القيمة الافتراضية. يتم استخدام _artifactsLocationSasToken كإدخال لـ sasToken. يجب أن تكون القيمة الافتراضية سلسلة فارغة للسيناريوهات التي لا يتم فيها تأمين _artifactsLocation - على سبيل المثال، مستودع GitHub عام.

"parameters": {
  "_artifactsLocation": {
    "type": "string",
    "metadata": {
      "description": "The base URI where artifacts required by this template are located."
    },
    "defaultValue": "https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.compute/vm-custom-script-windows/"
  },
  "_artifactsLocationSasToken": {
    "type": "securestring",
    "metadata": {
      "description": "The sasToken required to access _artifactsLocation."
    },
    "defaultValue": ""
  }
}

في جميع أنحاء القالب، يتم إنشاء الروابط من خلال دمج URI الأساسي (من المعامل _artifactsLocation ) مع المسار النسبي للعناصر الصناعية و_artifactsLocationSasToken. يوضح التعليمة البرمجية التالي كيفية تحديد الرابط للقالب المتداخل باستخدام وظيفة قالب uri:

"resources": [
  {
    "type": "Microsoft.Resources/deployments",
    "apiVersion": "2020-10-01",
    "name": "shared",
    "properties": {
      "mode": "Incremental",
      "templateLink": {
        "uri": "[uri(parameters('_artifactsLocation'), concat('nested/vnet.json', parameters('_artifactsLocationSasToken')))]",
        "contentVersion": "1.0.0.0"
      }
    }
  }
]

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

استخدم _artifactsLocation بدلاً من روابط الترميز الثابت

إلى جانب استخدامه للقوالب المتداخلة، يتم استخدام عنوان URL في المعلمة _artifactsLocation كأساس لجميع العناصر ذات الصلة بقالب التوزيع. تتضمن بعض امتدادات VM ارتباطاً إلى برنامج نصي مخزن خارج القالب. بالنسبة لهذه الامتدادات، لا يجب ترميز الروابط بشكل ثابت. على سبيل المثال، قد ترتبط ملحقات Custom Script وPowerShell DSC ببرنامج نصي خارجي على GitHub كما هو موضح:

"properties": {
  "publisher": "Microsoft.Compute",
  "type": "CustomScriptExtension",
  "typeHandlerVersion": "1.9",
  "autoUpgradeMinorVersion": true,
  "settings": {
    "fileUris": [
      "https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-music-windows/scripts/configure-music-app.ps1"
    ]
  }
}

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

يسترد مدير الموارد القوالب المتداخلة في وقت التشغيل. بالنسبة لملحقات الأجهزة الظاهرية، يتم تنفيذ استرجاع أي عيوب خارجية بواسطة وكيل الجهاز الظاهري. إلى جانب البادئ المختلف لاسترداد الأداة، فإن الحل في تعريف القالب هو نفسه. استخدم المعلمة _artifactsLocation بقيمة افتراضية للمسار الأساسي حيث يتم تخزين جميع العناصر الأثرية (بما في ذلك البرامج النصية لملحق VM) والمعلمة _artifactsLocationSasToken لإدخال sasToken.

"parameters": {
  "_artifactsLocation": {
    "type": "string",
    "metadata": {
      "description": "The base URI where artifacts required by this template are located."
    },
    "defaultValue": "https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-music-windows/"
  },
  "_artifactsLocationSasToken": {
    "type": "securestring",
    "metadata": {
      "description": "The sasToken required to access _artifactsLocation."
    },
    "defaultValue": ""
  }
}

لإنشاء URI المطلق لقطعة أثرية، فإن الطريقة المفضلة هي استخدام وظيفة قالب uri، بدلاً من وظيفة قالب concat. من خلال استبدال الروابط المشفرة بالبرامج النصية في ملحق VM بوظيفة قالب uri، يتم تكوين هذه الوظيفة في القالب لاتساق السحابة.

"properties": {
  "publisher": "Microsoft.Compute",
  "type": "CustomScriptExtension",
  "typeHandlerVersion": "1.9",
  "autoUpgradeMinorVersion": true,
  "settings": {
    "fileUris": [
      "[uri(parameters('_artifactsLocation'), concat('scripts/configure-music-app.ps1', parameters('_artifactsLocationSasToken')))]"
    ]
  }
}

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

عامل في القدرات الإقليمية المختلفة

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

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

قالب يتوزيع ويكوّن الموارد. يتم توفير نوع المورد من قِبل مزود الموارد. على سبيل المثال، يوفر موفر مورد الحوسبة (Microsoft.Compute) أنواع موارد متعددة مثل VirtualMachines ومجموعات التوفر. يوفر كل موفر موارد واجهة برمجة تطبيقات لـ Azure Resource Manager محدد بواسطة عقد مشترك، ما يتيح تجربة تأليف متسقة وموحدة عبر جميع موفري الموارد. ومع ذلك، قد لا يكون موفر الموارد المتوفر في Azure العالمي متاحاً في السحابة السيادية أو منطقة Azure Stack.

رسم تخطيطي يوضح العلاقة بين موفري الموارد وأنواع الموارد وإصدارات واجهة برمجة التطبيقات.

للتحقق من موفري الموارد المتاحين في سحابة معينة، قم بتشغيل البرنامج النصي التالي في Azure CLI:

az provider list --query "[].{Provider:namespace, Status:registrationState}" --out table

يمكنك أيضاً استخدام أمر PowerShell cmdlet التالي لمعرفة موفري الموارد المتاحين:

Get-AzureRmResourceProvider -ListAvailable | Select-Object ProviderNamespace, RegistrationState

تحقق من إصدار جميع أنواع الموارد

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

قد لا تتوفر إصدارات API الجديدة المقدمة لأنواع الموارد الموجودة في Azure العالمية على الفور في جميع المناطق أو السحابات السيادية أو Azure Stack. لعرض قائمة بموفري الموارد وأنواع الموارد وإصدارات API المتوفرة للسحابة، يمكنك استخدام Resource Explorer في مدخل Microsoft Azure. ابحث عن Resource Explorer في قائمة All Services. قم بتوسيع عقدة Providers في Resource Explorer لإرجاع جميع موفري الموارد المتاحين وأنواع مواردهم وإصدارات API في تلك السحابة.

لسرد إصدار API المتاح لجميع أنواع الموارد في سحابة معينة في Azure CLI، قم بتشغيل البرنامج النصي التالي:

az provider list --query "[].{namespace:namespace, resourceType:resourceType[]}"

يمكنك أيضاً استخدام أمر PowerShell cmdlet التالي:

Get-AzureRmResourceProvider | select-object ProviderNamespace -ExpandProperty ResourceTypes | ft ProviderNamespace, ResourceTypeName, ApiVersions

الرجوع إلى مواقع الموارد مع المعلمة

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

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

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

تعرض دالة القالب [resourceGroup()] كائناً يحتوي على أزواج المفتاح / القيمة التالية:

{
  "id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}",
  "name": "{resourceGroupName}",
  "location": "{resourceGroupLocation}",
  "tags": {
  },
  "properties": {
    "provisioningState": "{status}"
  }
}

بالرجوع إلى مفتاح الموقع الخاص بالكائن في القيمة الافتراضية لمعلمة الإدخال، سيقوم Azure Resource Manager، في وقت التشغيل، باستبدال وظيفة القالب [resourceGroup().location] باسم موقع مجموعة الموارد التي تم توزيع القالب عليها.

"parameters": {
  "location": {
    "type": "string",
    "metadata": {
      "description": "Location the resources will be deployed to."
    },
    "defaultValue": "[resourceGroup().location]"
  }
},
"resources": [
  {
    "type": "Microsoft.Storage/storageAccounts",
    "apiVersion": "2015-06-15",
    "name": "storageaccount1",
    "location": "[parameters('location')]",
    ...

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

تتبع الإصدارات باستخدام ملفات تعريف API

قد يكون من الصعب للغاية تتبع جميع موفري الموارد المتاحين وإصدارات API ذات الصلة الموجودة في Azure Stack. على سبيل المثال، في وقت كتابة هذا التقرير، كان أحدث إصدار من واجهة برمجة التطبيقات لـ Microsoft.Compute / availableSets في Azure هو 2018-04-01، بينما إصدار واجهة برمجة التطبيقات المتوفر المشترك بين Azure وAzure Stack هو 2016-03-30. إصدار API الشائع لـ Microsoft.Storage/storageAccounts مشترك بين جميع مواقع Azure وAzure Stack هو 2016-01-01، بينما أحدث إصدار لواجهة برمجة التطبيقات في Azure هو 2018-02-01.

لهذا السبب، قدم Resource Manager مفهوم ملفات تعريف API إلى القوالب. دون ملفات تعريف API، يتم تكوين كل مورد في قالب باستخدام عنصر apiVersion الذي يصف إصدار API لهذا المورد المحدد.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "location": {
      "type": "string",
      "metadata": {
          "description": "Location the resources will be deployed to."
      },
      "defaultValue": "[resourceGroup().location]"
    }
  },
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2016-01-01",
      "name": "mystorageaccount",
      "location": "[parameters('location')]",
      "properties": {
        "accountType": "Standard_LRS"
      }
    },
    {
      "type": "Microsoft.Compute/availabilitySets",
      "apiVersion": "2016-03-30",
      "name": "myavailabilityset",
      "location": "[parameters('location')]",
      "properties": {
        "platformFaultDomainCount": 2,
        "platformUpdateDomainCount": 2
      }
    }
  ],
  "outputs": {}
}

يعمل إصدار ملف تعريف واجهة برمجة التطبيقات كاسم مستعار لإصدار واحد لواجهة برمجة التطبيقات لكل نوع مورد شائع في Azure وAzure Stack. بدلاً من تحديد إصدار API لكل مورد في قالب ما، فإنك تحدد فقط إصدار ملف تعريف واجهة برمجة التطبيقات في عنصر جذر جديد يسمى apiProfile وحذف عنصر apiVersion للموارد الفردية.

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "apiProfile": "2018–03-01-hybrid",
    "parameters": {
        "location": {
            "type": "string",
            "metadata": {
                "description": "Location the resources will be deployed to."
            },
            "defaultValue": "[resourceGroup().location]"
        }
    },
    "variables": {},
    "resources": [
        {
            "type": "Microsoft.Storage/storageAccounts",
            "name": "mystorageaccount",
            "location": "[parameters('location')]",
            "properties": {
                "accountType": "Standard_LRS"
            }
        },
        {
            "type": "Microsoft.Compute/availabilitySets",
            "name": "myavailabilityset",
            "location": "[parameters('location')]",
            "properties": {
                "platformFaultDomainCount": 2,
                "platformUpdateDomainCount": 2
            }
        }
    ],
    "outputs": {}
}

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

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

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "apiProfile": "2018–03-01-hybrid",
    "parameters": {
        "location": {
            "type": "string",
            "metadata": {
                "description": "Location the resources will be deployed to."
            },
            "defaultValue": "[resourceGroup().location]"
        }
    },
    "variables": {},
    "resources": [
        {
            "type": "Microsoft.Storage/storageAccounts",
            "apiVersion": "2016-01-01",
            "name": "mystorageaccount",
            "location": "[parameters('location')]",
            "properties": {
                "accountType": "Standard_LRS"
            }
        },
        {
            "type": "Microsoft.Compute/availabilitySets",
            "name": "myavailabilityset",
            "location": "[parameters('location')]",
            "properties": {
                "platformFaultDomainCount": 2,
                "platformUpdateDomainCount": 2
            }
        }
    ],
    "outputs": {}
}

تحقق من مراجع نقطة النهاية

يمكن أن تحتوي الموارد على مراجع لخدمات أخرى على النظام الأساسي. على سبيل المثال، يمكن أن يكون لعنوان IP العام اسم DNS عام مخصص له. تحتوي حلول السحابة العامة والسحب السيادية وحلول Azure Stack على مساحات أسماء نقاط نهاية مميزة خاصة بها. في معظم الحالات، يتطلب المورد بادئة فقط كإدخال في القالب. أثناء وقت التشغيل، يقوم Azure Resource Manager بإلحاق قيمة نقطة النهاية به. يجب تحديد بعض قيم نقطة النهاية بشكل صريح في القالب.

ملاحظة

لتطوير قوالب لاتساق السحابة، لا تقم بترميز مساحات أسماء نقاط النهاية.

المثالان التاليان هما مساحات أسماء نقاط النهاية الشائعة التي يجب تحديدها بشكل صريح عند إنشاء مورد:

حسابات التخزين (blob وqueue وtable وfile)
سلاسل الاتصال لقواعد البيانات وAzure Cache لـ Redis

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

حسابات التخزين (blob وqueue وtable وfile)
سلاسل الاتصال (MySql وSQLServer وSQLAzure وCustom وNotificationHub وServiceBus وEventHub وApiHub وDocDb وRedisCache وPostgreSQL)
Traffic Manager
اسم المجال تسمية عنوان IP العام
الخدمات السحابية

بشكل عام، تجنب نقاط النهاية المشفرة في قالب. أفضل ممارسة هي استخدام وظيفة القالب المرجعي لاسترداد نقاط النهاية ديناميكياً. على سبيل المثال، نقطة النهاية الأكثر شيوعاً في تشفيرها هي مساحة اسم نقطة النهاية لحسابات التخزين. يحتوي كل حساب تخزين على FQDN فريد يتم إنشاؤه عن طريق ربط اسم حساب التخزين بمساحة اسم نقطة النهاية. ينتج عن حساب تخزين blob المسمى mystorageaccount1 مجموعات FQDN مختلفة اعتماداً على السحابة:

mystorageaccount1.blob.core.windows.net عند إنشائه على سحابة Azure العالمية.
mystorageaccount1.blob.core.chinacloudapi.cn عند إنشائها في Azure المشغلة بواسطة سحابة 21Vianet.

تسترد وظيفة القالب المرجعي التالية مساحة اسم نقطة النهاية من موفر موارد التخزين:

"diskUri":"[concat(reference(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))).primaryEndpoints.blob, 'container/myosdisk.vhd')]"

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

الرجوع إلى الموارد الموجودة بواسطة معرف فريد

يمكنك أيضاً الإشارة إلى مورد موجود من نفس مجموعة الموارد أو مجموعة موارد أخرى، وضمن نفس الاشتراك أو اشتراك آخر، داخل نفس المستأجر في نفس السحابة. لاسترداد خصائص المورد، يجب عليك استخدام المعرف الفريد للمورد نفسه. تسترد دالة القالب resourceId المعرف الفريد لمورد مثل SQL Server كما توضح التعليمات البرمجية التالية:

"outputs": {
  "resourceId":{
    "type": "string",
    "value": "[resourceId('otherResourceGroup', 'Microsoft.Sql/servers', parameters('serverName'))]"
  }
}

يمكنك بعد ذلك استخدام الوظيفة resourceId داخل دالة القالب reference لاسترداد خصائص قاعدة البيانات. يحتوي كائن الإرجاع على الخاصية fullyQualifiedDomainName التي تحتوي على قيمة نقطة النهاية الكاملة. يتم استرداد هذه القيمة في وقت التشغيل وتوفر مساحة اسم نقطة النهاية الخاصة بالبيئة السحابية. لتحديد سلسلة الاتصال دون تشفير مساحة اسم نقطة النهاية، يمكنك الرجوع إلى خاصية كائن الإرجاع مباشرة في سلسلة الاتصال كما هو موضح:

"[concat('Server=tcp:', reference(resourceId('sql', 'Microsoft.Sql/servers', parameters('test')), '2015-05-01-preview').fullyQualifiedDomainName, ',1433;Initial Catalog=', parameters('database'),';User ID=', parameters('username'), ';Password=', parameters('pass'), ';Encrypt=True;')]"

ضع في اعتبارك خصائص الموارد

الموارد المحددة في بيئات Azure Stack لها خصائص فريدة يجب وضعها في الاعتبار في القالب الخاص بك.

تأكد من توفر صور VM

يوفر Azure مجموعة غنية من صور VM. يتم إنشاء هذه الصور وإعدادها للتوزيع بواسطة Microsoft وشركائها. تشكل الصور الأساس لـ VMs على المنصة. ومع ذلك، يجب أن يشير القالب المتوافق مع السحابة إلى المعلمات المتاحة فقط - على وجه الخصوص، الناشر، والعرض، وSKU لصور VM المتاحة لـ Azure العالمية، أو Azure السحابية السيادية، أو حل Azure Stack.

لاسترداد قائمة بصور VM المتوفرة في موقع ما، قم بتشغيل أمر Azure CLI التالي:

az vm image list -all

يمكنك استرداد نفس القائمة باستخدام Azure PowerShell cmdlet Get-AzureRmVMImagePublisher وتحديد الموقع الذي تريده باستخدام المعلمة -Location. على سبيل المثال:

Get-AzureRmVMImagePublisher -Location "West Europe" | Get-AzureRmVMImageOffer | Get-AzureRmVMImageSku | Get-AzureRmVMImage

يستغرق هذا الأمر دقيقتين لإرجاع جميع الصور المتاحة في منطقة غرب أوروبا من سحابة Azure العالمية.

إذا جعلت صور VM هذه متاحة لـ Azure Stack، فسيتم استهلاك كل مساحة التخزين المتاحة. لاستيعاب أصغر وحدة مقياس، يتيح لك Azure Stack تحديد الصور التي تريد إضافتها إلى بيئة ما.

يوضح نموذج التعليمة البرمجية التالي طريقة متسقة للإشارة إلى معلمات الناشر والعرض وSKU في قوالب ARM الخاصة بك:

"storageProfile": {
    "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "2016-Datacenter",
    "version": "latest"
    }
}

تحقق من أحجام VM المحلية

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

عندما تقدم Microsoft حجماً جديداً من VM له تبعيات معينة للأجهزة، فإن حجم الجهاز الظاهري عادة ما يكون متاحاً أولاً في مجموعة فرعية صغيرة من المناطق في سحابة Azure. في وقت لاحق، يتم توفيره للمناطق والسحب الأخرى. للتأكد من وجود حجم الجهاز الظاهري في كل سحابة تتوزيع إليها، يمكنك استرداد الأحجام المتوفرة باستخدام أمر Azure CLI التالي:

az vm list-sizes --location "West Europe"

بالنسبة إلى Azure PowerShell، استخدم:

Get-AzureRmVMSize -Location "West Europe"

للحصول على قائمة كاملة بالخدمات المتاحة، راجع المنتجات المتوفرة حسب المنطقة.

تحقق من استخدام أقراص Azure المُدارة في Azure Stack

تتعامل الأقراص المُدارة مع التخزين لمستأجر Azure. بدلاً من إنشاء حساب تخزين بشكل صريح وتحديد URI للقرص الثابت الظاهري (VHD)، يمكنك استخدام الأقراص المُدارة لتنفيذ هذه الإجراءات ضمنياً عند توزيع جهاز ظاهري. تعمل الأقراص المُدارة على تحسين الإتاحة عن طريق وضع جميع الأقراص من أجهزة VM في نفس التوافر المحدد في وحدات تخزين مختلفة. بالإضافة إلى ذلك، يمكن تحويل VHDs الحالية من التخزين القياسي إلى التخزين المتميز مع وقت تعطل أقل بشكل ملحوظ.

على الرغم من وجود الأقراص المُدارة في خريطة طريق Azure Stack، إلا أنها غير مدعومة حالياً. حتى يتم ذلك، يمكنك تطوير قوالب متوافقة مع السحابة لـ Azure Stack عن طريق تحديد VHDs بشكل صريح باستخدام عنصر vhd في القالب لمورد VM كما هو موضح:

"storageProfile": {
  "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "[parameters('windowsOSVersion')]",
    "version": "latest"
  },
  "osDisk": {
    "name": "osdisk",
    "vhd": {
      "uri": "[concat(reference(resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName')), '2015-06-15').primaryEndpoints.blob, 'vhds/osdisk.vhd')]"
    },
    "caching": "ReadWrite",
    "createOption": "FromImage"
  }
}

في المقابل، لتحديد تكوين قرص مُدار في قالب، قم بإزالة عنصر vhd من تكوين القرص.

"storageProfile": {
  "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "[parameters('windowsOSVersion')]",
    "version": "latest"
  },
  "osDisk": {
    "caching": "ReadWrite",
    "createOption": "FromImage"
  }
}

تطبق نفس التغييرات أيضاً أقراص البيانات.

تحقق من أن ملحقات الأجهزة الظاهرية متوفرة في Azure Stack

هناك اعتبار آخر لاتساق السحابة وهو استخدام ملحقات الجهاز الظاهري لتكوين الموارد داخل جهاز ظاهري. لا تتوفر جميع ملحقات الأجهزة الظاهرية في Azure Stack. يمكن للقالب تحديد الموارد المخصصة لامتداد VM، وإنشاء تبعيات وشروط داخل القالب.

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

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

تحقق من توفر ملحقات VM

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

لاسترداد قائمة بملحقات VM المتوفرة لمنطقة معينة (في هذا المثال، myLocation)، قم بتشغيل أمر Azure CLI التالي:

az vm extension image list --location myLocation

يمكنك أيضاً تنفيذ Azure PowerShell Get-AzureRmVmImagePublisher cmdlet واستخدام -Location لتحديد موقع صورة الجهاز الظاهري. على سبيل المثال:

Get-AzureRmVmImagePublisher -Location myLocation | Get-AzureRmVMExtensionImageType | Get-AzureRmVMExtensionImage | Select Type, Version

تأكد من توفر الإصدارات

نظراً لأن ملحقات VM هي موارد إدارة موارد من الطرف الأول، فلديها إصدارات API الخاصة بها. كما توضح التعليمات البرمجية التالية، فإن نوع ملحق VM هو مورد متداخل في موفر مورد Microsoft.Compute.

{
    "type": "Microsoft.Compute/virtualMachines/extensions",
    "apiVersion": "2015-06-15",
    "name": "myExtension",
    "location": "[parameters('location')]",
    ...

يجب أن يكون إصدار واجهة برمجة التطبيقات لمورد ملحق VM موجوداً في جميع المواقع التي تخطط لاستهدافها بالقالب الخاص بك. تعمل تبعية الموقع مثل توفر إصدار واجهة برمجة التطبيقات لموفر الموارد الذي تمت مناقشته مسبقاً في قسم "التحقق من إصدار جميع أنواع الموارد".

لاسترداد قائمة إصدارات API المتوفرة لمورد ملحق VM، استخدم الأمر cmdlet Get-AzureRmResourceProvider مع موفر مورد Microsoft.Compute كما هو موضح:

Get-AzureRmResourceProvider -ProviderNamespace "Microsoft.Compute" | Select-Object -ExpandProperty ResourceTypes | Select ResourceTypeName, Locations, ApiVersions | where {$_.ResourceTypeName -eq "virtualMachines/extensions"}

يمكنك أيضاً استخدام ملحقات VM في مجموعات مقياس الجهاز الافتراضي. تنطبق نفس شروط الموقع. لتطوير القالب الخاص بك من أجل تناسق السحابة، تأكد من توفر إصدارات API في جميع المواقع التي تخطط للتوزيع فيها. لاسترداد إصدارات واجهة برمجة التطبيقات لمورد ملحق VM لمجموعات المقاييس، استخدم نفس الأمر cmdlet كما كان من قِبل، ولكن حدد نوع المورد لمجموعات مقياس الجهاز الظاهري كما هو موضح:

Get-AzureRmResourceProvider -ProviderNamespace "Microsoft.Compute" | Select-Object -ExpandProperty ResourceTypes | Select ResourceTypeName, Locations, ApiVersions | where {$_.ResourceTypeName -eq "virtualMachineScaleSets/extensions"}

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

{
    "type": "extensions",
    "apiVersion": "2016-03-30",
    "name": "MyCustomScriptExtension",
    "location": "[parameters('location')]",
    "dependsOn": [
        "[concat('Microsoft.Compute/virtualMachines/myVM', copyindex())]"
    ],
    "properties": {
        "publisher": "Microsoft.Compute",
        "type": "CustomScriptExtension",
        "typeHandlerVersion": "1.7",
        ...

لاسترداد قائمة بالإصدارات المتوفرة لملحق جهاز ظاهري معين، استخدم الأمر cmdlet Get-AzureRmVMExtensionImage. يسترد المثال التالي الإصدارات المتوفرة لملحق PowerShell DSC (تكوين الحالة المطلوب) VM من myLocation:

Get-AzureRmVMExtensionImage -Location myLocation -PublisherName Microsoft.PowerShell -Type DSC | FT

للحصول على قائمة بالناشرين، استخدم الأمر Get-AzureRmVmImagePublisher. لطلب النوع، استخدم توصية Get-AzureRmVMExtensionImageType.

نصائح للاختبار والأتمتة

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

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

رسم تخطيطي يوضح اختبارات الوحدة المتوازية واختبارات التكامل في المعرف المحلي، والدمج في تدفق تطوير CI/CD مع اختبارات الوحدة واختبارات التكامل وتوزيع الاختبار والتوزيع النهائي.

ضع في اعتبارك النصائح التالية للاختبار والأتمتة:

لا تستخدم أدوات الاختبار. على سبيل المثال، يشتمل Visual Studio Code وVisual Studio على IntelliSense وميزات أخرى يمكن أن تساعدك في التحقق من صحة القوالب الخاصة بك.
لتحسين جودة التعليمة البرمجية أثناء التطوير على IDE المحلي، قم بإجراء تحليل ثابت للكود مع اختبارات الوحدة واختبارات التكامل.
للحصول على تجربة أفضل أثناء التطوير الأولي، يجب أن تحذر اختبارات الوحدة واختبارات التكامل فقط عند اكتشاف مشكلة والمضي قدماً في الاختبارات. بهذه الطريقة، يمكنك تحديد المشكلات التي يجب معالجتها وتحديد أولويات ترتيب التغييرات، والتي يشار إليها أيضاً باسم التوزيع المستند إلى الاختبار (TDD).
اعلم أنه يمكن إجراء بعض الاختبارات دون الاتصال بـ Azure Resource Manager. يتطلب البعض الآخر، مثل اختبار توزيع القالب، Azure Resource Manager لتنفيذ إجراءات معينة لا يمكن تنفيذها في وضع عدم الاتصال.
اختبار قالب التوزيع مقابل واجهة برمجة التطبيقات للتحقق من الصحة لا يساوي التوزيع الفعلي. أيضاً، حتى إذا قمت بتوزيع قالب من ملف محلي، فإن أي مراجع للقوالب المتداخلة في القالب يتم استردادها بواسطة Resource Manager مباشرة، ويتم استرداد القطع الأثرية المشار إليها بواسطة ملحقات VM بواسطة وكيل VM الذي يعمل داخل الجهاز الظاهري المنشور.

مشاركة عبر