السابق

التالي

إنشاء مثيلات مورد متعددة باستخدام عنصر النسخ

مكتمل

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

ضع في اعتبارك الأسئلة والنقاط التالية عندما تفكر في إنشاء العديد من المثيلات، والتكرار فوق الثوابت:

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

إنشاء مثيلات متعددة

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

عنصر النسخ هو جزء من JSON يمكنك استخدامه في العديد من أنواع البُنى؛ مثل الموارد، الخصائص، المتغيرات، والمخرجات. يتكون بناء الجملة لعنصر النسخ من نسخةرئيسية، وصفيف باعتباره قيمة. على سبيل المثال: "copy": [].

يأخذ الصفيف عددًا من العناصر، وكل عنصر هو كائن {} يتكون من مجموعة من الخصائص. تعتمد هذه الخصائص على نوع البنية المُستخدمة به. عمومًا، إن جميع بُنى العنصر copy لها خاصية واحدة مشتركة: count. تحدد هذه الخاصية عدد المثيلات التي تريدها لنوع معين من البنية. تسمح معظم البُنى أيضًا بخاصية name تمنحك مرجعًا يمكنك الرجوع إليه في أجزاء أخرى من تعليماتك البرمجية. الخصائص الأخرى المستخدمة خاصة ببنية معينة.

ما الذي تختاره

قد تسأل: "إذا كان بإمكاني استخدام العنصر copy في العديد من أنواع البُنى، فأي نوع يجب أن أختار ومتى، وهل يمكنني استخدام أكثر من نوع واحد في قالب؟"

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

يمكنك استخدام العنصر copy في العديد من الأماكن في قالبك. يمكنك استخدام عنصر copy لإنشاء العديد من الموارد، وكذلك لإنشاء العديد من المتغيرات المشابهة داخل القالب نفسه.

كيف يعمل

copyيعمل العنصر من خلال copy كشفك الذي يجري تقييمه واستبداله. الاستبدال هو نتيجة لما تحدده في copy الكشف المتكرر عدة مرات حسب إرشاداتك في copy الحقل.

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

"copy": [
  {
    "name": "dataDisks",
    "count": 2,
    "input": {
      "diskSizeGB": 1023,
      "lun": "[copyIndex('dataDisks')]",
      "createOption": "Empty"
    }
  }
]

لاحظ الإدخال count: 2. القيمة 2 تُعني أنك تريد توسيع التعبير أعلاه ليشمل إدخالين. التالي هو النتيجة:

"dataDisks": [
{
  "lun": 0,
  "createOption": "Empty",
  "diskSizeGB": 1023
},
{
  "lun": 1,
  "createOption": "Empty",
  "diskSizeGB": 1023
}

يمكنك أن ترى أن قيمة name الخاصية أصبحت اسم الخاصية، وأصبحت محتويات الخاصية input جزءًا من JSON المتكرر.

إشعار

يختلف تعبير النسخ ومُخرج حسب نوع التعبير المستخدم. يعطي المثال السابق فكرة جيدة عما يحدث عندما يتحول التعبير إلى سلسلة من العبارات المتكررة.

هناك حدود لمقدار ما يمكن نسخه. حاليًا الحد الأقصى هو 800 إدخال.

هام

لمزيد من المعلومات عن القيود الدقيقة، راجع تكرار الموارد في قوالب ARM.

التحكم في التكرار

هناك وظائف المساعد التي تساعدك على الرجوع إلى فهارس معينة في الصفيف. تُرجع الدالة copyIndex() الفهرس الحالي. على سبيل المثال، بالنسبة للإدخال الثالث المتكرر، يتم من خلال copyIndex() إرجاع القيمة 2. يبدو بناء الجملة copyIndex() كما يلي:

copyIndex(loopName, offset)

تحتوي الدالة copyIndex() على معلمتين إدخال مختلفتين، loopName وoffset. تكون المعلمة offset اختيارية دومًا وتُستخدم لإزاحتك الفهرس الحالي. كل ما تضيفه باعتباره القيمة offset، يُضاف إلى الفهرس الحالي. في حالة إرجاع الفهرس الحالي 2، وأنت تحدد 1 باعتباره الإزاحة، يتم من خلال الدالة copyIndex() إرجاع 3.

تكون المعلمة loopName اختيارية أو إلزامية، وذلك وفقًا للمكان الذي يجري استخدامها فيه. إنها إلزامية إذا ما اُستخدِمت داخل بنية properties، واختيارية إذا ما اُستخدمت في صفيف resources. إليك مثال تكون فيه إلزامية:

"properties": {
    "storageProfile": {
      "copy": [
        {
          "name": "dataDisks",
          "count": "[parameters('numberOfDataDisks')]",
          "input": {
            "diskSizeGB": 1023,
            "lun": "[copyIndex('dataDisks')]",
            "createOption": "Empty"
          }
        }
      ]
    }
}

لاحظ كيف يُستخدم العنصر copy داخل بنية properties، ويتضمن copyIndex() على loopName المُحدد باعتباره copyIndex('dataDisks').

الآن إليك مثال تكون فيه loopName غير إلزامية:

{
  "type": "Microsoft.Network/virtualNetworks",
  "apiVersion": "2018-04-01",
  "name": "[concat(parameters('vnetname'), copyIndex())]",
}

تُظهر مورد يجري الإعلان عنه، ويُستدعى copyIndex() دون معلمات، لأنه يجري استخدامه في سياق مورد.

تكوين التوزيع

عندما تستخدم العنصر copy للموارد، ينتهي بك الأمر إلى إنشاء العديد من الموارد المشابهة.

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

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

أوضاع التوزيع وcopy

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

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

التبعيات

في سياق العنصر copy، تحتاج إلى إخبار المورد بالتبعية ما القسم الذي ينتظره. يمكنك تحقيق هذه التبعية من خلال الإشارة إليها بالاسم، باستخدام JSON التالية:

"resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2019-04-01",
      "name": "[concat(copyIndex(),'storage', uniqueString(resourceGroup().id))]",
      "location": "[resourceGroup().location]",
      "sku": {
        "name": "Standard_LRS"
      },
      "kind": "Storage",
      "copy": {
        "name": "storagecopy",
        "count": 3
      },
      "properties": {}
    },
    {
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2015-06-15",
      "name": "[concat('VM', uniqueString(resourceGroup().id))]",
      "dependsOn": ["storagecopy"],
    }
  ]

لاحظ أن العنصر copy يضم الخاصية name بالقيمة storagecopy. المورد التابع، حساب تخزين، ينتظر انتهاء عملية تشغيل العنصر copy. يُعبر عن ذلك من خلال "dependsOn": ["storagecopy"].

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

متابعة