Share via

تصميم نهج Azure كمهام سير عمل لـ Code

  • مقالة

أثناء تقدمك في رحلتك باستخدام Cloud Governance، ستحتاج إلى التحول من إدارة كل تعيين نهج يدويا في مدخل Microsoft Azure أو من خلال حزم SDK المختلفة إلى شيء أكثر قابلية للإدارة والتكرار على نطاق المؤسسة. اثنان من النهج السائدة لإدارة النظم على نطاق واسع في السحابة هي:

  • البنية الأساسية كرمز: ممارسة معاملة المحتوى الذي يحدد بيئاتك، كل شيء من قوالب إدارة الموارد Azure (قوالب ARM) إلى تعريفات سياسة Azure إلى مخططات Azure، كشفرة مصدر.
  • DevOps اتحاد الأشخاص، والعمليات، والمنتجات لتمكين تقديم مستمر للقيمة لمستخدمينا النهائيين.

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

يجب أن تكون خطوة التحقق أيضا مكونا من مهام سير عمل التكامل المستمر أو التوزيع المستمر (CI/CD)، مثل نشر بيئة تطبيق أو بنية أساسية ظاهرية. من خلال جعل التحقق من صحة نهج Azure مكونا مبكرا من عملية الإنشاء والنشر، تكتشف فرق التطبيق والعمليات ما إذا كانت تغييراتها تتصرف كما هو متوقع قبل فوات الأوان وتحاول التوزيع في الإنتاج.

التعاريف والمعلومات الأساسية

قبل الدخول في تفاصيل Azure Policy كسير عمل التعليمات البرمجية، من المهم فهم بعض المفاهيم الأساسية، مثل كيفية تأليف تعريفات النهج وتعريفات المبادرة، وكيفية الاستفادة من الإعفاءات على تعيينات تلك التعريفات:

تتوافق أسماء الملفات مع أجزاء معينة من تعريفات النهج أو المبادرة وموارد النهج الأخرى:

تنسيق الملف محتويات الملف
policy.json تعريف النهج بأكمله
policyset.json تعريف المبادرة بالكامل
policy.parameters.json properties.parameters جزء تعريف النهج
policyset.parameters.json properties.parameters جزء تعريف المبادرة
policy.rules.json properties.policyRule جزء تعريف النهج
policyset.definitions.json properties.policyDefinitions جزء تعريف المبادرة
exemptionName.json استثناء النهج الذي يستهدف موردا أو نطاقا معينا

تتوفر أمثلة على تنسيقات الملفات هذه في Azure Policy GitHub Repo

نظرة عامة على سير العمل

سير العمل العام الموصى به من نهج Azure كرمز يشبه الرسم التخطيطي:

Diagram showing Azure Policy as Code workflow boxes from Create to Test to Deploy.

‏‫التحكم في المصدر

يمكن تصدير تعريفات النهج والمبادرة الحالية بطرق مختلفة مثل من خلال استعلامات PowerShell أو CLI أو Azure Resource Graph (ARG). يمكن أن تكون بيئة إدارة التحكم بالمصادر التي تختارها لتخزين هذه التعريفات أحد الخيارات العديدة، بما في ذلك GitHub أو Azure DevOps.

إنشاء التعريفات الخاصة بالنهج وتحديثها

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

.
|
|- policies/  ________________________ # Root folder for policy resources
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

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

إنشاء وتحديث تعريفات المبادرة

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

.
|
|- initiatives/ ______________________ # Root folder for initiatives
|  |- init1/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- init2/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

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

إشعار

يوصى باستخدام آلية توزيع مركزية مثل مهام سير العمل GitHub أو Azure Pipelines لنشر النهج. يساعد هذا على ضمان نشر موارد النهج التي تمت مراجعتها فقط في البيئة الخاصة بك واستخدام آلية نشر تدريجية ومركزية. يمكن تقييد الأذونات الكتابة إلى موارد النهج على الهوية المستخدمة في التوزيع.

اختبار التعريف المحدث والتحقق من صحته

بمجرد أن تأخذ الأتمتة نهجك أو تعريفات المبادرة التي تم إنشاؤها حديثا أو تحديثها، وبذلك يتم تحديث الكائن في Azure، فقد حان الوقت لاختبار التغييرات التي أجريت. يتعين بعد ذلك تعيين السياسة أو المبادرة (المبادرة) التي تشكل جزءا منها إلى الموارد في البيئة البعيدة عن الإنتاج. البيئة عادة ما تكون Dev.

إشعار

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

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

إشعار

على الرغم من أن وضع الإنفاذ مفيد، إلا أنه ليس بديلا لاختبار تعريف السياسة بدقة في ظل ظروف مختلفة. يتعين اختبار تعريف النهج مع PUTPATCH استدعاءات REST API والموارد المتوافقة وغير المتوافقة وحالات الحافة مثل خاصية مفقودة من المورد.

بعد نشر التعيين، استخدم Azure Policy SDK أو مهمة Azure Pipelines Security and Compliance Assessment أو استعلامات Azure Resource Graph (ARG) (راجع العينات) للحصول على بيانات التوافق للتعيين الجديد. يجب أن تحتوي البيئة المستخدمة لاختبار النهج والتعيينات على موارد مع حالات امتثال مختلفة. مثل اختبار وحدة جيد للتعليمات البرمجية، تريد اختبار تقييم الموارد كما هو متوقع مع عدم وجود إيجابيات خاطئة أو سلبيات خاطئة. إذا قمت باختبار التحقق من صحة فقط لما تتوقع، يكون هناك تأثير غير متوقع وغير معروف من النهج. لمزيد من المعلومات، راجع تقييم تأثير تعريف نهج Azure جديد.

تمكين مهام الإصلاح

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

الخطوة الأولى لمعالجة الموارد منح تعيين النهج تعيين الدور المحدد في تعريف النهج. يمنح تعيين الدور هوية النهج المدارة حقوقا كافية لإجراء التغييرات المطلوبة لجعل المورد متوافقا.

بمجرد أن يكون تعيين النهج الحقوق المناسبة، استخدم SDK نهج لبدء مهمة إصلاح مقابل مجموعة من الموارد التي تعرف أن تكون غير متوافقة. يتعين إكمال ثلاثة اختبارات مقابل هذه المهام المعالجة قبل المتابعة:

  • التحقق من اكتمال مهمة الإصلاح بنجاح
  • تشغيل تقييم النهج لمعرفة تحديث نتائج توافق النهج كما هو متوقع
  • شغل اختبار وحدة بيئة مقابل الموارد مباشرة للتحقق من صحة خصائصها التي تم تغييرها

يوفر اختبار كل من نتائج التقييم الخاصة بالنهج المحدثة والبيئة تأكيدا مباشرة على أن مهام المعالجة غيرت ما كان متوقعا وأن تعريف النهج شهد تغيير التوافق كما هو متوقع.

التحديث إلى التعيينات القسرية

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

عمليات التقييم المتكامل

سير العمل العام ل Azure Policy كرمز هو لتطوير ونشر السياسات والمبادرات في بيئة على نطاق واسع. ومع ذلك، يتعين أن يكون تقييم النهج جزءا من عملية توزيع أي سير عمل يقوم بنشر الموارد أو إنشائها في Azure، مثل نشر التطبيقات أو تشغيل قوالب ARM لإنشاء البنية الأساسية.

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

مراجعة

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

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