أضِف منطقًا شرطيًا إلى قوالب ARM خاصتك

مكتمل

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

تصور المواقف التالية:

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

تمثل كلتا الحالتين أعلاه سيناريوهات يجري فيها تطبيق المنطق الشرطي. المنطق إما في نظام Resource Manager نفسه، أو أنه شيء تحتاج إلى التعبير عنه صراحةً.

التوزيع الشرطي

تتيح لك البنية condition التعبير عما إذا كنت تريد توزيع شيئًا ما أم لا. إنها خاصية، بقيمة إما true أو false، ترفقها بعنصر مورد. ستجد عادةً بنية condition تبدو وكأنها JSON التالية في قالبك:

"resources" : [
  {
    "condition": "[parameters('shouldDeploy')]"
  }
]

في JSON أعلاه، تُضاف خاصية condition إلى مورد. ستُقيم قيمة الخاصية لتكون قيمة المعلمة shouldDeploy.

التقييم

هناك طريقتان يمكن من خلالهما تقييم البنية condition. قد تؤثر معرفة هاتين الطريقتين على كيفية اختيارك للتعبير عن منطقك الشرطي. الطريقتان المختلفتان هما:

  • القيمة هي إما صواب/خطأ. على سبيل المثال، خُذ بعين الاعتبار البنية التالية:

    "condition": "[parameters('deployAccount')]"
    

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

  • هناك تعبير يُقيم إلى صواب/ خطأ. هنا، بدلًا من تعيين قيمة صواب/خطأ دقيقة للبنية condition، يمكنك استخدام دالة القالب المضمنة equals(arg1, arg2). يجب أن تكون arg1 مساوية لـ arg2 ليتم تقييمها إلى صواب. يمكن الآن التعبير عن بنيتك conditionعلى النحو التالي:

    "condition": "[equals(parameters('newOrExisting'),'new')]"
    

    باستخدام الدالة equals()، فالقيمة التي تمررها إلى معلمة بحاجة إلى أن تكون true أو false. يجب أن يطابق الوسيطة الثانية في الدالة equals(). في مثال JSON السابق، يجب أن تتطابق قيمة المعلمة newOrExisting مع السلسلة new ليتم تقييم الدالة إلى true.