السابق

التالي

التحكم في ترتيب التوزيع عن طريق تحديد التبعيات

مكتمل

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

فيما يلي بعض الجوانب التي يجب أخذها بعين الاعتبار:

• يجب أن يُوجَد شيءٌ ما قبل توزيع شيء آخر.

  على سبيل المثال، لنفترض أنك بحاجة إلى مخزن رئيسي في Azure Key Vault لإحضار البيانات السرية التي تحتاج إلى تحميلها في جهاز ظاهري. على سبيل المثال، لنفترض أنك بحاجة إلى مخزن مفاتيح في Azure Key Vault لجلب الأسرار التي تحتاج إلى تحميلها في جهاز ظاهري. ومع ذلك، يجب توزيع المخزن الرئيسي قبل بياناته السرية. لذلك، فإن البيانات السرية تعتمد على المخزن الرئيسي المقرر وجوده. يتم توزيع المخزن الرئيسي والبيانات السرية على نحوٍ متسلسل، واحدًا تلو الآخر؛ بدءًا من المخزن الرئيسي، بسبب التبعية.

• هل يمكنني الاعتماد على كيف تسير الأمور في Azure Resource Manager؟

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

  إشعار

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

• يمكنك إدخال الموارد ضمن مورد آخر.

  في قوالب Azure Resource Manager، يمكنك دمج الموارد في مورد آخر. من خلال تداخل الموارد، يمكنك تحديد علاقة بين الموارد المتداخلة والمورد الأصل.

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

تخيل أنك تريد التأكد من أن المورد قد نُشِر (على سبيل المثال، حساب تخزين) قبل المورد الذي يتطلبه. كيف يمكنك التحقق من وجود حساب التخزين التابع؟

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

تُوجد مثل هذه البنية في قوالب Resource Manager، تسمى dependsOn. يؤدي استخدام هذه البنية إلى انتظار الموارد حتى انتهاء توزيع المورد المشار إليه.

ما الذي يعتمد على البنية؟

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

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

يوضح المثال التالي كيف يمكنك التعبير عن مثل هذه التبعية في JSON داخل نموذج ARM خاصتك:

"resources": [
  {
    "name": "<name of resource that needs to exist first>"
  },
  {
    "name": "someResource",
    "dependsOn": [
      "<name of resource that needs to exist first>"
    ]
  }
]

في هذا المثال، تستخدم اسم المورد لتحديد المورد الذي تعتمد عليه. ومع ذلك، قد تكون العديد من الموارد بالاسم نفسه. للتأكد من أن هذه المقارنة تفعل ما تريد، يمكنك بدلًا من ذلك استخدام البنية resourceId() للحصول على معرف المورد المميز:

"dependsOn": [
  "resourceId('Microsoft.Network/loadBalancers', variables('nameOfLoadBalancer')))"
]

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

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

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

تبدو التعليمات البرمجية النموذجية لعلاقة بين الأصل والتابع في قالب كما يلي:

"resources": [
  {
    "name": "parent-resource",
    "resources": [{
      "name": "child-resource"
    }]
  }
]

لا تُنشئ تبعية الأصل-التابع هذه تلقائيًا تبعية حيث يتم فيها توزيع الأصل فيها التابع. تحتاج إلى جعل التبعية صريحة.

لذلك عند التعبير عن مثل هذه العلاقة، تأكد من إضافة بنية dependsOn، مثل ما يلي:

"resources": [
  {
    "name": "parent-resource",
    "resources": [{
      "dependsOn": ["parent-resource"],
      "name": "child resource"
    }]
  }
]

متابعة