مشاركة عبر

توزيع DevOps لـ Azure Logic Apps للمستأجر الفردي

  • مقالة

ينطبق على: Azure Logic Apps (القياسي)

مع تزايد الاتجاه نحو تطبيقات السحابة الموزَّعة والأصلية، تتعامل المؤسسات مع المزيد من المكونات الموزعة عبر المزيد من البيئات. للحفاظ على التحكم والاتساق، يمكنك أتمتة بيئاتك وتوزيع المزيد من المكونات بشكل أسرع وأكثر ثقة باستخدام أدوات وعمليات DevOps.

توفر هذه المقالة مقدمة ونظرة عامة حول تجربة التكامل المستمر والتوزيع المستمر (CI/CD) الحالية للمستأجر الفردي Azure Logic Apps.

مستأجر واحد مقابل مستأجر متعدد

في تطبيقات Azure Logic Apps متعددة المستأجرين، يعتمد توزيع الموارد على قوالب Azure Resource Manager (قوالب ARM)، والتي تجمع وتتولى توفير الموارد لكل من التطبيقات المنطقية والبنية الأساسية. في تطبيقات أحادية المستأجر Azure Logic Apps يصبح التوزيع أسهل لأنه يمكنك فصل توفير الموارد بين التطبيقات والبنية الأساسية.

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

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

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

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

قدرات توزيع DevOps

ترث Azure Logic Apps للمستأجر الفردي العديد من الإمكانات والفوائد من النظام الأساسي Azure Functions والنظام البيئي Azure App Service. تتضمن هذه التحديثات نموذج توزيع جديداً بالكامل والمزيد من الطرق لاستخدام DevOps لسير عمل تطبيقك المنطقي.

التطوير والاختبار المحلي

عند استخدام Visual Studio Code مع ملحق Azure Logic Apps (قياسي)، يمكنك تطوير مهام سير عمل تطبيق منطقي يستند إلى مستأجر واحد وإنشاؤها وتشغيلها محلياً في بيئة التطوير الخاصة بك دون الحاجة إلى التوزيع إلى Azure. إذا كان السيناريو الخاص بك يتطلب حاويات، فيمكنك إنشاء وتوزيع من خلال تطبيقات منطقية تم تمكين Azure Arc.

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

مخاوف منفصلة

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

رسم تخطيطي مفاهيمي يوضح خطوط نشر منفصلة للتطبيقات والبنية الأساسية.

هيكل موارد تطبيق المنطق

في نموذج Azure Logic Apps متعدد المستأجرين، يمكن أن تتضمن بنية مورد تطبيق منطق الاستهلاك سير عمل واحد فقط. نظراً لهذه العلاقة الفردية، غالباً ما يتم النظر في كل من التطبيق المنطقي وسير العمل والإشارة إليه بشكل مترادف. ومع ذلك، في نموذج Azure Logic Apps أحادي المستأجر، يمكن أن تتضمن بنية مورد تطبيق المنطق القياسي مهام سير عمل متعددة. تعني علاقة رأس بأطراف أنه في نفس تطبيق المنطق، يمكن لمهام سير العمل مشاركة الموارد الأخرى وإعادة استخدامها. تقدم مهام سير العمل في نفس التطبيق المنطقي والمستأجر أداءً محسناً بسبب هذا الإيجار المشترك والقرب من بعضهما. تبدو بنية الموارد هذه وتعمل بشكل مشابه لـ Azure Functions حيث يمكن لتطبيق وظيفي استضافة العديد من الوظائف.

لمزيد من المعلومات وأفضل الممارسات حول تنظيم مهام سير العمل والأداء والتوسع في تطبيقك المنطقي، راجع إرشادات Azure Functions المشابهة التي يمكنك تطبيقها عموماً على Azure Logic Apps للمستأجر الفردي.

هيكل مشروع تطبيق المنطق

في Visual Studio Code، يحتوي مشروع التطبيق المنطقي على أحد الأنواع التالية:

  • تعتمد على حزمة الامتدادات (Node.js)، وهي النوع الافتراضي
  • NuGet قائم على الحزم (.NET)، والذي يمكنك تحويله من النوع الافتراضي

بناءً على هذه الأنواع، يتضمن المشروع الخاص بك مجلدات وملفات مختلفة قليلاً. يشمل المشروع المستند إلى NuGet مجلد .bin يحتوي على حزم وملفات مكتبة أخرى. لا يشمل المشروع المستند إلى الحزم مجلد .bin وملفات أخرى. تتطلب بعض السيناريوهات مشروعًا يستند إلى NuGet لتشغيل التطبيق الخاص بك، على سبيل المثال، عندما تريد تطوير عمليات مضمنة مخصصة وتشغيلها. للمزيد من المعلومات حول تحويل المشروع الخاص بك لاستخدام NuGet، راجع Enable built-connector authoring.

بالنسبة إلى المشروع الافتراضي المستند إلى الحزمة، يحتوي المشروع الخاص بك على بنية مجلد وملف مشابه للمثال التالي:

MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
  || Maps 
     ||| MapName1
     ||| ...
  || Schemas
     ||| SchemaName1
     ||| ...
| WorkflowName1
  || workflow.json
  || ...
| WorkflowName2
  || workflow.json
  || ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json

على مستوى جذر المشروع الخاص بك، يمكنك العثور على الملفات والمجلدات التالية مع عناصر أخرى:

الاسم مجلد أو ملف الوصف
.vscode المجلد يشتمل على ملفات الإعدادات المتعلقة بـ Visual Studio Code، مثل ملفات extensions.json و launch.json و settings.json و tasks.json.
البيانات الاصطناعية المجلد يشتمل على عناصر حساب التكامل التي تحددها وتستخدمها في مهام سير العمل التي تدعم سيناريوهات الأعمال التجارية (B2B). على سبيل المثال، تشتمل بنية المثال الخرائط والمخططات لعمليات تحويل XML والتحقق من الصحة.
< WorkflowName> المجلد لكل سير عمل، < يشتمل المجلد WorkflowName> ملف workflow.json، والذي يحتوي على تعريف JSON الأساسي لسير العمل هذا.
وقت تصميم سير العمل المجلد يشتمل على ملفات الإعدادات المتعلقة ببيئة التطوير.
.funcignore ملف يشتمل على معلومات تتعلق بـ Azure Functions Core Toolsالمثبتة.
connections.json ملف يشتمل على بيانات تعريفية ونقاط النهاية والمفاتيح لأي اتصالات مُدارة ووظائف Azure التي تستخدمها مهام سير العمل.

هام: لاستخدام اتصالات ووظائف متنوعة لكل بيئة، تأكد من تحديد معلمات ملف connections.json هذا وتحديث نقاط النهاية.
host.json ملف يحتوي على إعدادات وقيم التكوين الخاصة بوقت التشغيل، على سبيل المثال، الحدود الافتراضية لنظام Azure Logic Apps الأساسي للمستأجر الفردي، و Logic Apps، ومهام سير العمل، والمشغلات، والإجراءات. على مستوى جذر مشروع Logic Apps الخاص بك، يحتوي ملف بيانات التعريف host.json على إعدادات التكوين والقيم الافتراضية التي تستخدمها جميع مهام سير العمل في نفس تطبيق المنطق أثناء التشغيل، سواء محليا أو في Azure.

ملاحظة: عند إنشاء logic app الخاص بك، ينشئ Visual Studio Code ملف host.snapshot.*.json احتياطيا في حاوية التخزين الخاصة بك. في حالة قيامك بحذف logic app الخاص بك، فلن يتم حذف ملف النسخ الاحتياطي هذا. إذا أنشأت logic app آخر بنفس الاسم، فسينشئ ملف لقطة آخر. بإمكانك الحصول على ما يصل إلى 10 لقطات فقط لنفس logic app. في حالة تجاوزك لهذا الحد، فستحصل على الخطأ الموضح أدناه:

Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))

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

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

هام: يمكن أن يحتوي ملف local.settings.json على بيانات سرية، لذا تأكد من استبعاد هذا الملف أيضاً من التحكم في مصدر المشروع.

نشر الحاوية

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

للحصول على أمثلة تتضمن Azure DevOps، راجع CI/CD للحاويات.

إعدادات التطبيق والمعلمات

في Azure Logic Apps متعددة المستأجرين، تشكل قوالب ARM تحدياً عندما يتعين عليك الحفاظ على متغيرات البيئة للتطبيقات المنطقية عبر بيئات التطوير والاختبار والإنتاج المختلفة. يتم تعريف كل شيء في قالب ARM عند التوزيع. إذا كنت بحاجة إلى تغيير متغير واحد فقط، فعليك إعادة توزيع كل شيء.

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

الموصلات المدارة والعمليات المدمجة

يوفر النظام البيئي Azure Logic Apps المئات من الموصلات التي تديرها Microsoft والعمليات المضمنة كجزء من مجموعة متزايدة باستمرار والتي يمكنك استخدامها في Azure Logic Apps للمستأجر الفردي. تظل الطريقة التي تحافظ بها Microsoft على هذه الموصلات والعمليات المدمجة كما هي في Azure Logic Apps للمستأجر الفردي.

التحسين الأكثر أهمية هو أن خدمة المستأجر الفردي تجعل الموصلات المدارة الأكثر شيوعاً متاحة أيضاً كعمليات مضمنة. على سبيل المثال، يمكنك استخدام العمليات المُضمّنة لناقل خدمة Azure، ومراكز الأحداث، وSQL، وغيرها. وفي الوقت نفسه، لا تزال إصدارات الموصل المُدار متوفرة ومستمرة في العمل.

تسمى الاتصالات التي تقوم بإنشائها باستخدام العمليات المضمنة الاتصالات المضمنة، أو اتصالات مزود الخدمة. تعمل العمليات المُضمّنة واتصالاتها محلياً في نفس العملية التي تقوم بتشغيل مهام سير العمل. كلاهما مستضاف في وقت تشغيل Logic Apps المعاد تصميمه. في المقابل، يتم إنشاء الاتصالات المُدارة أو اتصالات API وتشغيلها بشكل منفصل كموارد Azure، والتي تقوم بتوزيعها باستخدام قوالب ARM. نتيجة لذلك، توفر العمليات المدمجة ووصلاتها أداءً أفضل نظراً لقربها من مهام سير عملك. يعمل هذا التصميم أيضاً بشكل جيد مع مسارات التوزيع لأن اتصالات موفّر الخدمة يتم تعبئتها في نفس البيانات الاصطناعية للبناء.

في Visual Studio Code، عند استخدام المصمم لتطوير مهام سير العمل أو إجراء تغييرات عليها، يقوم محرك Logic Apps تلقائياً بإنشاء أي بيانات تعريف ضرورية للاتصال في ملف links.json الخاص بالمشروع. تصف الأقسام التالية الأنواع الثلاثة من الاتصالات التي يمكنك إنشاؤها في مهام سير العمل. يحتوي كل نوع اتصال على بنية JSON مختلفة، وهو أمر مهم لفهمه لأن نقاط النهاية تتغير عند التنقل بين البيئات.

اتصالات مزود الخدمة

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

في مشروع التطبيق المنطقي الخاص بك، يحتوي كل سير عمل على ملف workflow.json يحتوي على تعريف JSON الأساسي لسير العمل. يشير تعريف سير العمل هذا بعد ذلك إلى سلاسل الاتصال الضرورية في ملف links.json الخاص بمشروعك.

يوضح المثال التالي كيفية ظهور اتصال ناقل خدمة Microsoft Azure لعملية ناقل خدمة مضمنة في ملف links.json الخاص بمشروعك:

"serviceProviderConnections": {
   "{service-bus-connection-name}": {
      "parameterValues": {
         "connectionString": "@appsetting('servicebus_connectionString')"
      },
      "serviceProvider": {
         "id": "/serviceProviders/serviceBus"
      },
      "displayName": "{service-bus-connection-name}"
   },
   <...>
}

الاتصالات المدارة

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

في Visual Studio Code، بينما تستمر في إنشاء سير العمل وتطويره باستخدام المصمم، يقوم محرك Logic Apps تلقائياً بإنشاء الموارد الضرورية في Azure للموصلات المدارة في سير عملك. يضيف المحرك موارد الاتصال هذه تلقائياً إلى مجموعة موارد Azure التي صممتها لاحتواء تطبيقك المنطقي.

يوضح المثال التالي كيفية ظهور اتصال API لموصل ناقل خدمة Microsoft Azure المُدار في ملف links.json الخاص بمشروعك:

"managedApiConnections": {
   "{service-bus-connection-name}": { 
      "api": {
         "id": "/subscriptions/{subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/servicebus"
      },
      "connection": { 
         "id": "/subscriptions/{subscription-ID}/resourcegroups/{resource-group-name}/providers/Microsoft.Web/connections/servicebus"
      }, 
      "connectionRuntimeUrl": "{connection-runtime-URL}",
      "authentication": { 
         "type": "Raw",
         "scheme": "Key",
         "parameter": "@appsetting('servicebus_1-connectionKey')"
      },
   },
   <...>
}

اتصالات Azure Functions

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

"functionConnections": {
   "{function-operation-name}": {
      "function": { 
         "id": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/sites/{function-app-name}/functions/{function-name}"
      },
      "triggerUrl": "{function-url}",
      "authentication": {
        "type": "QueryString",
         "name": "Code",
         "value": "@appsetting('azureFunctionOperation_functionAppKey')"
      }, 
      "displayName": "{functions-connection-display-name}"
   },
   <...>
}

المصادقة

في Azure Logic Apps ذات المستأجر الفردي، يكون نموذج الاستضافة لعمليات سير عمل التطبيق المنطقي مستأجراً منفرداً حيث تستفيد أحمال العمل لديك من مزيد من العزل مقارنة بنموذج المستأجرين المتعددين. بالإضافة إلى ذلك، فإن وقت تشغيل Azure Logic Apps للمستأجر الفردي قابل للنقل، ما يعني أنه يمكنك تشغيل مهام سير العمل في بيئات أخرى، على سبيل المثال، محلياً في Visual Studio Code. ومع ذلك، يتطلب هذا التصميم طريقة لتطبيقات المنطق لمصادقة هويتها حتى تتمكن من الوصول إلى النظام البيئي للموصل المُدار في Azure. تحتاج تطبيقاتك أيضاً إلى الأذونات الصحيحة لتشغيل العمليات عند استخدام الاتصالات المُدارة.

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

توفر الأقسام التالية مزيداً من المعلومات حول أنواع المصادقة التي يمكنك استخدامها لمصادقة الاتصالات المُدارة، بناءً على مكان تشغيل تطبيق المنطق. لكل اتصال مُدار، يحتوي ملف connect.json الخاص بمشروع تطبيق منطقك على عنصر authentication يحدد نوع المصادقة الذي يمكن أن يستخدمه تطبيقك المنطقي لمصادقة هذا الاتصال المُدار.

الهوية المُدارة

بالنسبة إلى التطبيق المنطقي الذي يتم استضافته وتشغيله في Azure، فإن الهوية المُدارة هي نوع المصادقة الافتراضي والموصى به لاستخدامه لمصادقة الاتصالات المُدارة التي تتم استضافتها وتشغيلها في Azure. في ملف links.json الخاص بمشروع تطبيق منطقك، يشتمل الاتصال المُدار على عنصر authentication يحدد ManagedServiceIdentity كنوع المصادقة:

"authentication": {
   "type": "ManagedServiceIdentity"
}

RAW

بالنسبة للتطبيقات المنطقية التي يتم تشغيلها في بيئة التطوير المحلية الخاصة بك باستخدام Visual Studio Code، يتم استخدام مفاتيح المصادقة الأوَّلية لمصادقة الاتصالات المدارة التي تتم استضافتها وتشغيلها في Azure. تم تصميم هذه المفاتيح للاستخدام في التطوير فقط، وليس للإنتاج، ولها صلاحية لمدة 7 أيام. في ملف links.json الخاص بمشروع تطبيق منطقك، يشتمل الاتصال المُدار على عنصر authentication يحدد معلومات المصادقة التالية:

"authentication": {
   "type": "Raw", 
   "scheme": "Key", 
   "parameter": "@appsetting('connectionKey')"
 }

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