تعديل تعريفات نهج Azure لتأثير التعديل

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

هناك بعض الفروق الدقيقة في سلوك التعديل لخصائص المورد. تعرف على المزيد حول السيناريوهات عند تخطي التعديل.

يمكن أن يكون لقاعدة واحدة modify أي عدد من العمليات. العمليات المدعومة هي:

إضافة علامات الموارد أو استبدالها أو إزالتها. يمكن إزالة العلامات فقط. بالنسبة للعلامات، يجب تعيين وضع تعديل النهج إلى indexed ما لم يكن المورد الهدف مجموعة موارد.
إضافة أو استبدال قيمة نوع الهوية المدارة (identity.type) للأجهزة الظاهرية ومجموعات مقياس الجهاز الظاهري. يمكنك فقط تعديل للأجهزة الظاهرية identity.type أو مجموعات مقياس الجهاز الظاهري.
إضافة قيم أسماء مستعارة معينة أو استبدالها .
- استخدم Get-AzPolicyAlias | Select-Object -ExpandProperty 'Aliases' | Where-Object { $_.DefaultMetadata.Attributes -eq 'Modifiable' } في Azure PowerShell 4.6.0 أو أعلى للحصول على قائمة الأسماء المستعارة التي يمكن استخدامها مع modify.

Important

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

تعديل التقييم

يُقيم Modify قبل معالجة الطلب من قبل موفر الموارد أثناء إنشاء مورد أو تحديثه. modify يتم تطبيق العمليات على محتوى الطلب عند if استيفاء شرط قاعدة النهج. يمكن لكل modify عملية تحديد شرط يحدد وقت تطبيقها.

عند تحديد اسم مستعار، يتم إجراء المزيد من عمليات التحقق للتأكد من أن modify العملية لا تغير محتوى الطلب بطريقة تتسبب في رفض موفر المورد له:

تم وضع علامة على الخاصية التي يعينها الاسم المستعار على أنها قابلة للتعديل في إصدار واجهة برمجة التطبيقات للطلب.
يتطابق نوع الرمز المميز في modify العملية مع نوع الرمز المميز المتوقع للخاصية في إصدار واجهة برمجة التطبيقات للطلب.

إذا فشل أي من هذه الفحوصات، يعود تقييم النهج إلى المحدد conflictEffect.

Important

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

تم تخطي التعديل

هناك بعض الحالات التي يتم فيها تخطي عمليات التعديل أثناء التقييم:

الموارد الموجودة: عند تشغيل تعريف نهج يستخدم modify التأثير كجزء من دورة تقييم، فإنه لا يقوم بإجراء تغييرات على الموارد الموجودة بالفعل. بدلا من ذلك، فإنه يضع علامة على أي مورد يفي if بالشرط على أنه غير متوافق، بحيث يمكن معالجته من خلال مهمة معالجة.
غير قابل للتطبيق: عند تقييم حالة عملية في operations الصفيف إلى خطأ، يتم تخطي هذه العملية المعينة.
الخاصية غير قابلة للتعديل: إذا لم يكن الاسم المستعار المحدد لعملية قابلا للتعديل في إصدار واجهة برمجة التطبيقات للطلب، فإن التقييم يستخدم تأثير التعارض. إذا تم تعيين تأثير التعارض على الرفض، يتم حظر الطلب. إذا تم تعيين تأثير التعارض للتدقيق، يسمح بالطلب من خلال ولكن modify يتم تخطي العملية.
الخاصية غير موجودة: إذا لم تكن الخاصية موجودة في حمولة المورد للطلب، فقد يتم تخطي التعديل. في بعض الحالات، تكون الخصائص القابلة للتعديل متداخلة داخل خصائص أخرى ونمتلك اسما مستعارا مثل Microsoft.Storage/storageAccounts/blobServices/deleteRetentionPolicy.enabled. إذا لم تكن الخاصية "الأصل"، في هذه الحالة deleteRetentionPolicy، موجودة في الطلب، يتم تخطي التعديل لأنه يفترض حذف هذه الخاصية عن قصد. للحصول على مثال عملي، انتقل إلى القسم مثال على الخاصية غير موجودة.
عملية الهوية غير VM أو VMSS: عندما تحاول عملية تعديل إضافة أو استبدال identity.type الحقل على مورد آخر غير الجهاز الظاهري أو مجموعة مقياس الجهاز الظاهري، يتم تخطي تقييم النهج تماما حتى لا يتم إجراء التعديل. في هذه الحالة، يعتبر المورد غير قابل للتطبيق على النهج.

مثال على الخاصية غير موجودة

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

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

ومع ذلك، إذا قمت بتطبيق نهج يعدل الخصائص على جهاز ظاهري، فإن التعديل يعتمد على حمولة المورد. إذا حاولت تعديل الخصائص غير المضمنة في حمولة التحديث، فلن يتم التعديل. على سبيل المثال، يمكن أن يحدث هذا عند تصحيح assessmentMode خاصية الجهاز الظاهري (الاسم المستعار Microsoft.Compute/virtualMachines/osProfile.windowsConfiguration.patchSettings.assessmentMode). الخاصية "متداخلة"، لذلك إذا لم يتم تضمين خصائصها الأصلية في الطلب، افتراض أن هذا الإغفال مقصود ويتم تخطي التعديل. لكي يتم التعديل، يجب أن تحتوي حمولة المورد على هذا السياق.

تعديل الخصائص

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

roleDefinitionIds (مطلوب)
- يجب أن تتضمن هذه الخاصية صفيفًا من السلاسل التي تطابق معرف دور التحكم في الوصول المستند إلى الدور الذي يمكن الوصول إليه بواسطة الاشتراك. لمزيد من المعلومات، راجع المعالجة - تكوين تعريف النهج.
- يجب أن يتضمن الدور المحدد جميع العمليات الممنوحة لدور المساهم/المساهم في العلامة .
conflictEffect (اختياري)
- تحديد تعريف النهج الذي "يفوز" إذا كان أكثر من تعريف نهج واحد يعدل نفس الخاصية أو عندما modify لا تعمل العملية على الاسم المستعار المحدد.
  - بالنسبة للموارد الجديدة أو المحدثة، يكون لتعريف النهج مع deny الأسبقية. تتخطى تعريفات النهج مع التدقيق كل operations. إذا تم رفض أكثر من تعريف نهج واحد، يتم رفض الطلب كتعارض. إذا كانت جميع تعريفات النهج لها تدقيق، فلن تتم معالجة أي من operations تعريفات النهج المتعارضة.
  - بالنسبة للموارد الموجودة، إذا كان هناك أكثر من تعريف نهج واحد له تأثير الرفض، تكون حالة التوافق تعارض. إذا كان هناك تعريف نهج واحد أو أقل له تأثير الرفض، فإن كل تعيين يرجع حالة توافق غير متوافقة.
- القيم المتوفرة: audit،و deny، وdisabled.
- القيمة الافتراضية هي deny.
operations (مطلوب)
- صفيف من جميع عمليات العلامات التي سيتم إكمالها على الموارد المطابقة.
- Properties:
  - operation (مطلوب)
    - يحدد الإجراء الذي ينبغي اتخاذه على مورد مطابق. الخيارات هي: addOrReplaceو Addو.Remove
    - Addيتصرف بشكل مشابه لتأثير الإلحاق.
    - Remove معتمد فقط لعلامات الموارد.
  - field (مطلوب)
    - العلامة المراد إضافتها أو استبدالها أو إزالتها. يجب أن تلتزم أسماء العلامات بنفس اصطلاح التسمية لحقول أخرى.
  - value (اختياري)
    - القيمة التي ينبغي تعيين العلامة عليها.
    - هذه الخاصية مطلوبة إذا كانت operation addOrReplace أو Add.
  - condition (اختياري)
    - سلسلة تحتوي على تعبير لغة Azure Policy مع دالات النهج التي تقيم إلى صواب أو خطأ.
    - لا يدعم دالات النهج التالية: field() وresourceGroup() وsubscription().

تعديل العمليات

operations يجعل صفيف الخاصية من الممكن تغيير العديد من العلامات بطرق مختلفة عن تعريف نهج واحد. تتكون كل عملية من operationخصائص fieldو و value . operation تحدد مهمة المعالجة ما تفعله بالعلامات، field وتحدد العلامة التي تم تغييرها، وتحدد value الإعداد الجديد لتلك العلامة. يقوم المثال التالي بإجراء تغييرات العلامة التالية:

تعيين العلامة environment إلى "اختبار" حتى إذا كانت موجودة بالفعل بقيمة مختلفة.
إزالة العلامة TempResource.
تعيين العلامة Dept إلى معلمة النهج DeptName المكونة في تعيين النهج.

"details": {
  ...
  "operations": [
    {
      "operation": "addOrReplace",
      "field": "tags['environment']",
      "value": "Test"
    },
    {
      "operation": "Remove",
      "field": "tags['TempResource']",
    },
    {
      "operation": "addOrReplace",
      "field": "tags['Dept']",
      "value": "[parameters('DeptName')]"
    }
  ]
}

تحتوي operation الخاصية على الخيارات التالية:

Operation	Description
`addOrReplace`	تضيف الخاصية أو العلامة والقيمة المعرفة إلى المورد، حتى إن كانت الخاصية أو العلامة موجودة بالفعل بقيمة مختلفة.
`add`	تضيف الخاصية أو العلامة والقيمة المعرفة إلى المورد.
`remove`	إزالة العلامة المعرفة من المورد. معتمد فقط للعلامات.

تعديل الأمثلة

مثال 1: إضافة العلامة environment واستبدال علامات environment الموجودة بـ"Test":

"then": {
  "effect": "modify",
  "details": {
    "roleDefinitionIds": [
      "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
    ],
    "operations": [
      {
        "operation": "addOrReplace",
        "field": "tags['environment']",
        "value": "Test"
      }
    ]
  }
}

مثال 2: إزالة العلامة env وإضافة العلامة environment أو استبدال علامات environment الموجودة بقيمة معلمة:

"then": {
  "effect": "modify",
  "details": {
    "roleDefinitionIds": [
      "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
    ],
    "conflictEffect": "deny",
    "operations": [
      {
        "operation": "Remove",
        "field": "tags['env']"
      },
      {
        "operation": "addOrReplace",
        "field": "tags['environment']",
        "value": "[parameters('tagValue')]"
      }
    ]
  }
}

مثال 3: تأكد من أن حساب التخزين لا يسمح بالوصول العام للكائنات الثنائية كبيرة الحجم، modify يتم تطبيق العملية فقط عند تقييم الطلبات بإصدار API أكبر أو يساوي 2019-04-01:

"then": {
  "effect": "modify",
  "details": {
    "roleDefinitionIds": [
      "/providers/microsoft.authorization/roleDefinitions/17d1049b-9a84-46fb-8f53-869881c3d3ab"
    ],
    "conflictEffect": "audit",
    "operations": [
      {
        "condition": "[greaterOrEquals(requestContext().apiVersion, '2019-04-01')]",
        "operation": "addOrReplace",
        "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
        "value": false
      }
    ]
  }
}

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

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

الملاحظات

هل كانت هذه الصفحة مفيدة؟

Last updated on 2025-03-04