حزم ملف قابل للتنفيذ موجود إلى "تصميم الخدمة" وتوزيعه

عند تعبئة ملف قابل للتنفيذ موجود كملف ضيف قابل للتنفيذ، يمكنك اختيار إما استخدام قالب مشروع Visual Studio أو إنشاء حزمة التطبيق يدويًا. باستخدام Visual Studio، يُنشئ قالب المشروع الجديد بنية حزمة التطبيق وملفات البيانات لك.

تلميح

أسهل طريقة لحزم Windows موجود قابل للتنفيذ في خدمة هي استخدام Visual Studio وLinux لاستخدام Yeoman

استخدام Visual Studio لحزم ملف قابل للتنفيذ موجود وتوزيعه

يوفر Visual Studio قالب خدمة "تصميم الخدمة" لمساعدتك في توزيع ملف ضيف قابل للتنفيذ إلى نظام مجموعة "تصميم الخدمة".

1. اختر ملف>مشروع جديد، وأنشئ تطبيق "تصميم الخدمة".
2. اختر ملف ضيف قابل للتنفيذ كقالب خدمة.
3. انقر فوق استعراض لتحديد المجلد الذي يحتوي على الملف القابل للتنفيذ واملأ بقية المعلمات لإنشاء الخدمة.
   • سلوك حزمة التعليمات البرمجية. يمكن تعيينه لنسخ كل محتوى المجلد إلى "مشروع Visual Studio"، وهو أمر مفيد إذا لم يتغير الملف القابل للتنفيذ. إذا كنت تتوقع تغيير الملف القابل للتنفيذ وتريد القدرة على انتقاء إصدارات جديدة ديناميكيًا، فيمكنك اختيار الربط بالمجلد بدلًا من ذلك. يمكنك استخدام المجلدات المرتبطة عند إنشاء مشروع التطبيق في Visual Studio. يرتبط هذا بموقع المصدر من داخل المشروع، ما يتيح لك تحديث ملف الضيف القابل للتنفيذ في وجهته المصدر. تصبح هذه التحديثات جزءًا من حزمة التطبيقات قيد الإنشاء.
   • البرنامج يُحدد الملف القابل للتنفيذ الذي يجب تشغيله لبدء تشغيل الخدمة.
   • الوسيطات تُحدد الوسيطات التي يجب تمريرها إلى الملف القابل للتنفيذ. يمكن أن تكون قائمة بالمعلمات مع الوسيطات.
   • مجلد العمل يُحدد دليل العمل للعملية التي سيتم بدء تشغيلها. يمكنك تحديد ثلاث قيم:
     • CodeBase يحدد أنه سيتم تعيين الدليل المشغَّل إلى دليل التعليمات البرمجية في حزمة التطبيق (الدليلCode الموضح في بنية الملف السابقة).
     • CodePackage يحدد أنه سيتم تعيين الدليل المشغَّل إلى جذر حزمة التطبيق (GuestService1Pkg الموضح في بنية الملف السابقة).
     • Work يحدد وضع الملفات في دليل فرعي يسمى "العمل".
4. امنح خدمتك اسمًا، ثم انقر فوق موافق.
5. إذا كانت خدمتك بحاجة إلى نقطة نهاية للاتصال، فيمكنك الآن إضافة البروتوكول والمنفذ والنوع إلى ملف ServiceManifest.xml. على سبيل المثال: <Endpoint Name="NodeAppTypeEndpoint" Protocol="http" Port="3000" UriScheme="http" PathSuffix="myapp/" Type="Input" />.
6. يمكنك الآن استخدام الحزمة ونشر الإجراء ضد نظام مجموعة محلي عن طريق تصحيح أخطاء الحل في Visual Studio. عندما تكون جاهزًا، يمكنك نشر التطبيق إلى نظام مجموعة بعيد أو إيداع الحل للتحكم بالمصادر.
7. اقرأ التحقق من التطبيق قيد التشغيل لمعرفة كيفية عرض خدمة ملف الضيف القابل للتنفيذ التي تعمل في "مستكشف تصميم الخدمة".

للحصول على مثال تفصيلي، راجع إنشاء أول تطبيق ملف الضيف القابل للتنفيذ باستخدام Visual Studio.

تعبئة عِدة ملفات تنفيذية باستخدام Visual Studio

يمكنك استخدام Visual Studio لإنتاج حزمة تطبيقات تحتوي على عِدة ملفات ضيف قابلة للتنفيذ. بعد إضافة أول ملف ضيف قابل للتنفيذ، انقر بزر الماوس الأيمن فوق "مشروع التطبيق" وحدد Add->New Service Fabric service لإضافة مشروع ملف الضيف القابل للتنفيذ الثاني إلى الحل.

ملاحظة

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

استخدام Yeoman لحزم ملف تنفيذي موجود على Linux وتوزيعه

الإجراء الخاص بإنشاء ملف ضيف قابل للتنفيذ على Linux وتوزيعه هو نفسه توزيع تطبيق C# أو Java.

1. في terminal، اكتب yo azuresfguest.
2. قم بتسمية تطبيقك.
3. قم بتسمية خدمتك وقّدم التفاصيل بما في ذلك مسار الملف القابل للتنفيذ والمعلمات التي يجب استدعاؤه بها.

يُنشئ Yeoman حزمة تطبيق تحتوي على التطبيق المناسب وملفات البيانات إلى جانب تثبيت البرامج النصية وإلغاء تثبيتها.

تعبئة عِدة ملفات تنفيذية باستخدام Yeoman على Linux

لإضافة خدمة أخرى إلى تطبيق تم إنشاؤه مسبقًا باستخدام yo، نفّذ الخطوات التالية:

1. تغيير الدليل إلى جذر خاص بالتطبيق الموجود. على سبيل المثال، cd ~/YeomanSamples/MyApplication، إذا كان MyApplication هو التطبيق الذي أنشأه Yeoman.
2. شغّل yo azuresfguest:AddService وقدّم التفاصيل اللازمة.

حزم ملف قابل للتنفيذ موجود وتوزيعه يدويًا

تعتمد عملية تعبئة ملف ضيف قابل للتنفيذ يدويًا على الخطوات العامة التالية:

1. إنشاء بنية دليل الحزمة.
2. أضف التعليمات البرمجية للتطبيق وملفات التكوين.
3. تحرير ملف بيان الخدمة.
4. تحرير ملف بيان التطبيق.

إنشاء بنية دليل الحزمة

يمكنك البدء بإنشاء بنية الدليل، كما هو موضح في حزمة تطبيق Azure Service Fabric.

أضف التعليمات البرمجية للتطبيق وملفات التكوين

بعد إنشاء بنية الدليل، يمكنك إضافة ملفات التعليمات البرمجية وملفات التكوين الخاصة بالتطبيق ضمن أدلة التعليمات البرمجية والتكوين. يمكنك أيضًا إنشاء أدلة أو دلائل فرعية إضافية ضمن أدلة التعليمات البرمجية أو التكوين.

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

ملاحظة

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

تحرير ملف بيان الخدمة

الخطوة التالية هي تحرير ملف بيان الخدمة لتضمين المعلومات التالية:

• اسم نوع الخدمة. هذا هو المعرّف الذي يستخدمه "تصميم الخدمة" لتحديد خدمة.
• الأمر المطلوب استخدامه لتشغيل التطبيق (ExeHost).
• أي برنامج نصي يحتاج إلى تشغيل لإعداد التطبيق (SetupEntrypoint).

فيما يلي مثال على ملف ServiceManifest.xml:

<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" Name="NodeApp" Version="1.0.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
   <ServiceTypes>
      <StatelessServiceType ServiceTypeName="NodeApp" UseImplicitHost="true"/>
   </ServiceTypes>
   <CodePackage Name="code" Version="1.0.0.0">
      <SetupEntryPoint>
         <ExeHost>
             <Program>scripts\launchConfig.cmd</Program>
         </ExeHost>
      </SetupEntryPoint>
      <EntryPoint>
         <ExeHost>
            <Program>node.exe</Program>
            <Arguments>bin/www</Arguments>
            <WorkingFolder>CodePackage</WorkingFolder>
         </ExeHost>
      </EntryPoint>
   </CodePackage>
   <Resources>
      <Endpoints>
         <Endpoint Name="NodeAppTypeEndpoint" Protocol="http" Port="3000" Type="Input" />
      </Endpoints>
   </Resources>
</ServiceManifest>

تنتقل الأقسام التالية إلى الأجزاء المختلفة من الملف التي تحتاج إلى تحديثها.

تحديث أنواع الخدمات

<ServiceTypes>
  <StatelessServiceType ServiceTypeName="NodeApp" UseImplicitHost="true" />
</ServiceTypes>

• يمكنك اختيار أي اسم تريده لـ ServiceTypeName. تُستخدم القيمة في الملف ApplicationManifest.xml لتحديد الخدمة.
• حدد UseImplicitHost="true". تخبر هذه السمة "تصميم الخدمة" أن الخدمة تستند إلى تطبيق قائم بذاته، لذلك كل ما يحتاجه "تصميم الخدمة" هو تشغيله كعملية ومراقبة سلامته.

تحديث CodePackage

يحدد عنصر CodePackage موقع (وإصدار) التعليمات البرمجية للخدمة.

<CodePackage Name="Code" Version="1.0.0.0">

يُستخدم العنصر Name لتحديد اسم الدليل في حزمة التطبيق التي تحتوي على التعليمات البرمجية للخدمة. CodePackage لديه أيضًا السمة version. يمكن استخدام هذا لتحديد إصدار التعليمة البرمجية، ويمكن أيضًا استخدامه لترقية التعليمات البرمجية للخدمة باستخدام بنية إدارة دورة حياة التطبيق في "تصميم الخدمة".

اختياري: تحديث SetupEntrypoint

<SetupEntryPoint>
   <ExeHost>
       <Program>scripts\launchConfig.cmd</Program>
   </ExeHost>
</SetupEntryPoint>

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

يوجد SetupEntryPoint واحد فقط، لذلك يجب تجميع البرامج النصية للإعداد في ملف دُفعة واحد إذا تطلب إعداد التطبيق برامج نصية متعددة. يمكن لـ SetupEntryPoint تنفيذ أي نوع من الملفات: الملفات القابلة للتنفيذ والملفات الدُفعية وPowerShell cmdlets. لمزيد من التفاصيل، راجع تكوين SetupEntryPoint.

في المثال السابق، يُشغل SetupEntryPoint ملف دُفعة يسمى LaunchConfig.cmd الموجود في الدليل الفرعي scripts لدليل التعليمات البرمجية (بافتراض تعيين عنصر WorkingFolder إلى CodeBase).

تحديث نقطة إدخال

<EntryPoint>
  <ExeHost>
    <Program>node.exe</Program>
    <Arguments>bin/www</Arguments>
    <WorkingFolder>CodeBase</WorkingFolder>
  </ExeHost>
</EntryPoint>

يُستخدم العنصر EntryPoint الموجود في ملف بيان الخدمة لتحديد كيفية تشغيل الخدمة.

العنصر ExeHost يحدد الملف القابل للتنفيذ (والوسيطات) التي يجب استخدامها لتشغيل الخدمة. يمكنك أن تختار إضافة السمة IsExternalExecutable="true" إلى ExeHost للإشارة إلى أن البرنامج قابل للتنفيذ الخارجي خارج حزمة التعليمات البرمجية. على سبيل المثال، ⁧<ExeHost IsExternalExecutable="true">⁩.

• Program يحدد اسم الملف القابل للتنفيذ الذي يجب أن يبدأ تشغيل الخدمة.
• Arguments تُحدد الوسيطات التي يجب تمريرها إلى الملف القابل للتنفيذ. يمكن أن تكون قائمة بالمعلمات مع الوسيطات.
• WorkingFolder يُحدد الدليل المشغَّل للعملية التي ستبدأ. يمكنك تحديد ثلاث قيم:
  • CodeBase يحدد أنه سيتم تعيين الدليل المشغَّل إلى دليل التعليمات البرمجية في حزمة التطبيق (الدليلCode في بنية الملف السابقة).
  • CodePackage يحدد أنه سيتم تعيين الدليل المشغَّل إلى جذر حزمة التطبيق (GuestService1Pkg في بنية الملف السابقة).
    • Work يحدد وضع الملفات في دليل فرعي يسمى "العمل".

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

تحديث نقاط النهاية والتسجيل في "خدمة التسمية" للاتصال

<Endpoints>
   <Endpoint Name="NodeAppTypeEndpoint" Protocol="http" Port="3000" Type="Input" />
</Endpoints>

في المثال السابق، يحدد العنصر Endpoint نقاط النهاية التي يمكن للتطبيق الانصات إليها. في هذا المثال، ينصت تطبيق Node.js على http على المنفذ 3000.

علاوة على ذلك، يمكنك أن تطلب من "تصميم الخدمة" نشر نقطة النهاية هذه إلى "خدمة التسمية" حتى تتمكن الخدمات الأخرى من اكتشاف عنوان نقطة النهاية لهذه الخدمة. يتيح لك ذلك أن تكون قادرًا على التواصل بين الخدمات التي هي ملفات ضيف قابلة للتنفيذ. عنوان نقطة النهاية المنشور هو من النموذج UriScheme://IPAddressOrFQDN:Port/PathSuffix. UriScheme وPathSuffix هما سمات اختيارية. IPAddressOrFQDN هو عنوان IP أو اسم مجال مؤهل بالكامل للعقدة التي يُوضع هذا الملف القابل للتنفيذ عليها، ويُحسب لك.

في المثال التالي، بمجرد توزيع الخدمة، في "مستكشف تصميم الخدمة"، ترى نقطة نهاية مشابهة لـ http://10.1.4.92:3000/myapp/ منشورة لمثيل الخدمة. أو إذا كان هذا جهازًا محليًا، فسترى http://localhost:3000/myapp/.

<Endpoints>
   <Endpoint Name="NodeAppTypeEndpoint" Protocol="http" Port="3000"  UriScheme="http" PathSuffix="myapp/" Type="Input" />
</Endpoints>

يمكنك استخدام هذه العناوين مع وكيل عكسي للتواصل بين الخدمات.

تحرير ملف بيان التطبيق

بمجرد تكوين الملف Servicemanifest.xml، تحتاج إلى إجراء بعض التغييرات على الملف ApplicationManifest.xml للتأكد من استخدام نوع الخدمة والاسم الصحيحين.

<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" ApplicationTypeName="NodeAppType" ApplicationTypeVersion="1.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
   <ServiceManifestImport>
      <ServiceManifestRef ServiceManifestName="NodeApp" ServiceManifestVersion="1.0.0.0" />
   </ServiceManifestImport>
</ApplicationManifest>

ServiceManifestImport

في العنصر ServiceManifestImport، يمكنك تحديد خدمة واحدة أو أكثر تريد تضمينها في التطبيق. يُشار إلى الخدمات باستخدام ServiceManifestName، والذي يحدد اسم الدليل حيث يوجد الملف ServiceManifest.xml.

<ServiceManifestImport>
  <ServiceManifestRef ServiceManifestName="NodeApp" ServiceManifestVersion="1.0.0.0" />
</ServiceManifestImport>

إعداد التسجيل

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

تحذير

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

<EntryPoint>
  <ExeHost>
    <Program>node.exe</Program>
    <Arguments>bin/www</Arguments>
    <WorkingFolder>CodeBase</WorkingFolder>
    <ConsoleRedirection FileRetentionCount="5" FileMaxSizeInKb="2048"/>
  </ExeHost>
</EntryPoint>

ConsoleRedirection يمكن استخدامها لإعادة توجيه ناتج وحدة التحكم (كل من stdout و stderr) إلى الدليل المشغَّل. يوفر هذا القدرة على التحقق من عدم وجود أخطاء أثناء إعداد أو تنفيذ التطبيق في نظام مجموعة "تصميم الخدمة".

FileRetentionCount يحدد عدد الملفات المحفوظة في دليل العمل. تعني القيمة 5، على سبيل المثال، أن ملفات السجل لعمليات التنفيذ الخمس السابقة تُخزّن في الدليل المشغَّل.

FileMaxSizeInKb يحدد الحد الأقصى لحجم ملفات السجل.

تُحفظ ملفات السجل في أحد أدلة عمل الخدمة. لتحديد مكان وجود الملفات، استخدم "مستكشف تصميم الخدمة" لتحديد العقدة التي تشتغل الخدمة عليها ودليل العمل المُستخدم. سنتناول هذه العملية لاحقًا في هذه المقالة.

توزيع

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

Connect-ServiceFabricCluster localhost:19000

Write-Host 'Copying application package...'
Copy-ServiceFabricApplicationPackage -ApplicationPackagePath 'C:\Dev\MultipleApplications' -ImageStoreConnectionString 'file:C:\SfDevCluster\Data\ImageStoreShare' -ApplicationPackagePathInImageStore 'nodeapp'

Write-Host 'Registering application type...'
Register-ServiceFabricApplicationType -ApplicationPathInImageStore 'nodeapp'

New-ServiceFabricApplication -ApplicationName 'fabric:/nodeapp' -ApplicationTypeName 'NodeAppType' -ApplicationTypeVersion 1.0

New-ServiceFabricService -ApplicationName 'fabric:/nodeapp' -ServiceName 'fabric:/nodeapp/nodeappservice' -ServiceTypeName 'NodeApp' -Stateless -PartitionSchemeSingleton -InstanceCount 1

تلميح

اضغط الحزمة قبل النسخ إلى مخزن الصور إذا كانت الحزمة كبيرة أو تحتوي على العديد من الملفات. اقرأ المزيد ⁧⁩هنا⁧⁩.

يمكن توزيع خدمة "تصميم الخدمة" في "تكوينات" مختلفة. على سبيل المثال، يمكن توزيعها كمثيلات مفردة أو متعددة، أو يمكن توزيعها بحيث يُوجد مثيل واحد للخدمة على كل عقدة من نظام مجموعة "تصميم الخدمة".

تُستخدم المعلمة InstanceCount الخاصة بـ New-ServiceFabricService cmdlet لتحديد عدد مثيلات الخدمة التي يجب تشغيلها في نظام مجموعة "تصميم الخدمة". يمكنك تعيين القيمة InstanceCount استنادًا إلى نوع التطبيق الذي تُوزعه. السيناريوهان الأكثر شيوعًا هما:

• InstanceCount = "1". في هذه الحالة، يُوزع مثيل واحد فقط من الخدمة في نظام المجموعة. يحدد جدولة "تصميم الخدمة" العقدة التي ستُوزع الخدمة عليها.
• InstanceCount ="-1". في هذه الحالة، يتم توزيع مثيل واحد من الخدمة على كل عقدة في نظام مجموعة "تصميم الخدمة". النتيجة هي وجود مثيل واحد (وواحد فقط) من الخدمة لكل عقدة في المجموعة.

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

تحقق من أن التطبيق قيد التشغيل

في "مستكشف تصميم الخدمة"، حدد العقدة حيث تشتغل الخدمة. في هذا المثال، يعمل على Node1:

إذا انتقلت إلى العقدة واستعرضت التطبيق، فسترى معلومات العقدة الأساسية بما في ذلك موقعها على القرص.

إذا قمت بالاستعراض للوصول إلى الدليل باستخدام "مستكشف الخادم"، يمكنك العثور على الدليل المشغَّل ومجلد سجل الخدمة، كما هو موضح في لقطة الشاشة التالية:

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

لقد تعلمت في هذه المقالة كيفية حزم ملف ضيف قابل للتنفيذ وتوزيعه في "تصميم الخدمة". راجع المقالات التالية للحصول على المعلومات والمهام ذات الصلة.

• عينة لتعبئة ملف ضيف قابل للتنفيذ وتوزيعه، بما في ذلك ارتباط إلى الإصدار التجريبي لأداة التعبئة والتغليف
• عينة من ملفين ضيف قابل للتنفيذ (C# و nodejs) يتواصلان عبر خدمة "التسمية" باستخدام REST
• أنشئ أول تطبيق "تصميم الخدمة" باستخدام Visual Studio