عيّن اسمًا ونوعًا لمصادر فرعية في Bicep

  • مقالة

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

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

تعرض هذه المقالة طرقًا مختلفة يمكنك من خلالها إعلان مورد تابع.

موارد التدريب

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

اسم ونوع النمط

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

يستخدم الاسم الكامل للمورد الفرعي النمط:

{parent-resource-name}/{child-resource-name}

إذا كان لديك أكثر من مستويين في التسلسل الهرمي، فاستمر في تكرار الأسماء الأصلية:

{parent-resource-name}/{child-level1-resource-name}/{child-level2-resource-name}

يستخدم النوع الكامل للمورد الفرعي النمط:

{resource-provider-namespace}/{parent-resource-type}/{child-resource-type}

إذا كان لديك أكثر من مستويين في التسلسل الهرمي، فاستمر في تكرار أنواع الموارد الأصلية:

{resource-provider-namespace}/{parent-resource-type}/{child-level1-resource-type}/{child-level2-resource-type}

إذا عدت المقاطع بين / حرفًا، فسيكون عدد المقاطع في النوع دائمًا أكثر من عدد المقاطع في الاسم.

ضمن المورد الأصل

يوضح المثال التالي المورد الفرعي المتضمن في خاصية الموارد للمورد الأصلي.

resource <parent-resource-symbolic-name> '<resource-type>@<api-version>' = {
  <parent-resource-properties>

  resource <child-resource-symbolic-name> '<child-resource-type>' = {
    <child-resource-properties>
  }
}

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

عند التحديد ضمن نوع المورد الأصل، يمكنك تنسيق قيم النوع والاسم كقطعة واحدة بدون خطوط مائلة. يوضح المثال التالي حساب تخزين مع مورد تابع لخدمة الملفات، ولخدمة الملفات مورد تابع لمشاركة الملف. تم تعيين اسم خدمة الملف على default ونوعها مضبوط على fileServices. تم تعيين اسم مشاركة الملف exampleshare وتعيين نوعه على shares.

resource storage 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: 'examplestorage'
  location: resourceGroup().location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }

  resource service 'fileServices' = {
    name: 'default'

    resource share 'shares' = {
      name: 'exampleshare'
    }
  }
}

أنواع الموارد الكاملة لا تزال Microsoft.Storage/storageAccounts/fileServices و Microsoft.Storage/storageAccounts/fileServices/shares. أنت لا تقدم Microsoft.Storage/storageAccounts/ لأنه مفترض من نوع وإصدار المورد الأصلي. قد يعلن المورد المتداخل بشكل اختياري عن إصدار API باستخدام بناء الجملة <segment>@<version>. إذا أغفل المورد المتداخل إصدار API، فسيتم استخدام إصدار API للمورد الأصل. إذا كان المورد المتداخل يحدد إصدار API، فسيتم استخدام إصدار API المحدد.

يتم تعيين أسماء الموارد الفرعية على default و exampleshare لكن الأسماء الكاملة تتضمن الأسماء الرئيسية. أنت لا تقدم examplestorage أو default لأنهما مفترضان من المورد الأصلي.

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

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

output childAddressPrefix string = VNet1::VNet1_Subnet1.properties.addressPrefix

خارج المورد الأصل

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

resource <parent-resource-symbolic-name> '<resource-type>@<api-version>' = {
  name: 'myParent'
  <parent-resource-properties>
}

resource <child-resource-symbolic-name> '<child-resource-type>@<api-version>' = {
  parent: <parent-resource-symbolic-name>
  name: 'myChild'
  <child-resource-properties>
}

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

يوضح المثال التالي حساب التخزين وخدمة الملفات ومشاركة الملفات التي تم تعريفها جميعًا على مستوى الجذر.

resource storage 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: 'examplestorage'
  location: resourceGroup().location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
}

resource service 'Microsoft.Storage/storageAccounts/fileServices@2022-09-01' = {
  name: 'default'
  parent: storage
}

resource share 'Microsoft.Storage/storageAccounts/fileServices/shares@2022-09-01' = {
  name: 'exampleshare'
  parent: service
}

تعمل الإشارة إلى الاسم الرمزي للمورد الفرعي بنفس طريقة الإشارة إلى الأصل.

اسم المورد الكامل خارج الأصل

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

resource storage 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: 'examplestorage'
  location: resourceGroup().location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
}

resource service 'Microsoft.Storage/storageAccounts/fileServices@2022-09-01' = {
  name: 'examplestorage/default'
  dependsOn: [
    storage
  ]
}

resource share 'Microsoft.Storage/storageAccounts/fileServices/shares@2022-09-01' = {
  name: 'examplestorage/default/exampleshare'
  dependsOn: [
    service
  ]
}

هام

تعيين اسم المورد الكامل ونوعه ليس هو الأسلوب الموصى به. إنه ليس آمنًا من النوع مثل استخدام أحد الأساليب الأخرى. لمزيد من المعلومات، راجع قاعدة Linter: استخدام الخاصية الأصل.

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