تعريف الموارد التابعة

  • 5 دقائق

من المنطقي توزيع بعض الموارد فقط في سياق أصولها. وتعرف باسم الموارد التابعة. هناك العديد من أنواع الموارد التابعة في Azure. وفيما يلي بعض الأمثلة على ذلك:

الاسم نوع المورد
الشبكات الفرعية للشبكة الظاهرية Microsoft.Network/virtualNetworks/subnets
تكوين App Service Microsoft.Web/sites/config
قواعد بيانات SQL Microsoft.Sql/servers/databases
ملحقات الجهاز الظاهري Microsoft.Compute/virtualMachines/extensions
حاويات الكائنات الثنائية كبيرة الحجم لمواقع التخزين Microsoft.Storage/storageAccounts/blobServices/containers
حاويات Azure Cosmos DB Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers

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

تحتوي أنواع الموارد التابعة على أسماء أطول مع أجزاء متعددة لها. تحتوي حاوية تخزين البيانات الثنائية كبيرة الحجم على اسم النوع المؤهل بالكامل هذا: Microsoft.Storage/storageAccounts/blobServices/containers. يشتمل معرف المورد لحاوية تخزين البيانات الثنائية كبيرة الحجم على اسم حساب التخزين الذي يحتوي على الحاوية واسم الحاوية.

ملاحظة

قد يكون لبعض الموارد التابعة نفس أسماء أنواع الموارد الفرعية الأخرى من الموارد الأصل المختلفة. على سبيل المثال، containers هو نوع تابع من كل من حسابات التخزين وقواعد بيانات Azure Cosmos DB. وهي تحمل الأسماء نفسها، ولكنها تمثل موارد مختلفة، وأسماء الأنواع المؤهلة الخاصة بها مختلفة بالكامل.

كيف يتم تحديد الموارد التابعة؟

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

تلميح

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

الموارد المتداخلة

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

resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }

  resource installCustomScriptExtension 'extensions' = {
    name: 'InstallCustomScript'
    location: location
    properties: {
      // ...
    }
  }
}

لاحظ أن المورد المتداخل لديه نوع مورد أبسط من المعتاد. على الرغم من أن اسم النوع المؤهل بالكامل هو Microsoft.Compute/virtualMachines/extensions، يرث المورد المتداخل نوع المورد الأصل تلقائيا، لذا تحتاج إلى تحديد نوع المورد التابع فقط، extensions.

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

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

output childResourceId string = vm::installCustomScriptExtension.id

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

خاصية الأصل

يتمثل النهج الثاني في إعلان المورد التابع دون أي تداخل، ثم إخبار Bicep عن العلاقة بين المورد الأصل والتابع باستخدام الخاصية parent:

resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2020-06-01' = {
  parent: vm
  name: 'InstallCustomScript'
  location: location
  properties: {
    // ...
  }
}

لاحظ أن المورد التابع يستخدم الخاصية parent للإشارة إلى الاسم الرمزي للأصل الخاص به.

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

للإشارة إلى مورد تابع تم الإعلان عنه بخاصية parent، يمكنك استخدام اسمه الرمزي كما تفعل مع مورد أصل عادي:

output childResourceId string = installCustomScriptExtension.id

إنشاء اسم المورد

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

resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2020-06-01' = {
  name: '${vm.name}/InstallCustomScript'
  location: location
  properties: {
    // ...
  }
}

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

لحل هذه المشكلة، يمكنك يدويًا إخبار Bicep عن التبعية باستخدام الكلمة الأساسية dependsOn، كما هو موضح هنا:

resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2020-06-01' = {
  name: '${vmName}/InstallCustomScript'
  dependsOn: [
    vm
  ]
  //...
}

تلميح

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

معرفات الموارد التابعة

يمكنك بدء إنشاء معرف مورد تابع عن طريق تضمين معرف المورد الأصل الخاص به ثم إلحاق نوع المورد التابع واسمه. على سبيل المثال، دعونا نأخذ بعين الاعتبار حساب Azure Cosmos DB يسمى toyrnd. يعرض موفر موارد Azure Cosmos DB نوعًا يسمى databaseAccounts، وهو المورد الأصل الذي تقوم بتوزيعه:

/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyDevelopment/providers/Microsoft.DocumentDB/databaseAccounts/toyrnd

وفيما يلي تصوير مرئي لنفس معرف المورد:

Resource ID for an Azure Cosmos DB account, split with the key-value pair on a separate line.

إذا أضفنا قاعدة بيانات إلى هذا الحساب، فسنستخدم نوع المورد التابع sqlDatabases. دعونا نضيف قاعدة بيانات باسم FlightTests إلى حسابنا في Azure Cosmos DB، ونلقي نظرة على معرف المورد التابع:

/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyDevelopment/providers/Microsoft.DocumentDB/databaseAccounts/toyrnd/sqlDatabases/FlightTests

فيما يلي تمثيل مرئي على ذلك:

Child resource ID for an Azure Cosmos DB database, split with the key-value pair on a separate line.

يمكن أن تكون لديك مستويات متعددة من الموارد التابعة. فيما يلي مثال على معرف مورد يعرض حساب تخزين مع مستويين من الموارد التابعة:

/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyDevelopment/providers/Microsoft.Storage/storageAccounts/secrettoys/blobServices/default/containers/glitterspecs

فيما يلي تمثيل مرئي لمعرف المورد نفسه:

Child resource ID for a storage account with blob container, split with the key-value pair on a separate line.

يحتوي معرف المورد هذا على عدة مكونات له:

  • كل ما يصل إلى secrettoys يعد معرف المورد الأصل.

  • blobServices يشير إلى أن المورد موجود ضمن نوع مورد تابع يسمى blobServices.

    ملاحظة

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

  • default هو اسم المورد التابع blobServices.

    ملاحظة

    في بعض الأحيان، يُسمح فقط بمثيل واحد من مورد تابع. يسمى هذا النوع من المثيل قاعدة بيانات أحادية، وغالبًا ما يتم منحه الاسم default.

  • containers يشير إلى أن المورد موجود ضمن نوع مورد تابع يسمى containers.

  • glitterspecs هو اسم حاوية الكائنات الثنائية كبيرة الحجم.

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