قم بإنشاء أول تطبيق حاوية Service Fabric على نظام Windows

مقالة
05/17/2022
قراءة خلال 19 دقائق

لا يتطلب تشغيل تطبيق موجود في حاوية Windows على مجموعة Service Fabric أي تغييرات على التطبيق الخاص بك. ترشدك هذه المقالة خلال إنشاء صورة Docker تحتوي على تطبيق ويب Python Flask ونشرها في مجموعة Azure Service Fabric. ستشارك أيضًا التطبيق المعبأ في حاويات من خلال Azure Container Registry. تفترض هذه المقالة فهم أساسي Docker. يمكنك التعرف على Docker من خلال قراءة نظرة عامة على Docker.

ملاحظة

تنطبق هذه المقالة على بيئة تطوير Windows. يجب تشغيل وقت تشغيل مجموعة Service Fabric ووقت تشغيل Docker على نفس نظام التشغيل. لا يمكنك تشغيل حاويات Windows على نظام مجموعة Linux.

ملاحظة

تستخدم هذه المقالة الوحدة النمطية Azure Az PowerShell، وهي الوحدة النمطية PowerShell الموصى بها للتفاعل مع Azure. لبدء استخدام الوحدة النمطية Az PowerShell، راجع تثبيت Azure PowerShell. لمعرفة كيفية الترحيل إلى الوحدة النمطية Az PowerShell، راجع ترحيل Azure PowerShell من AzureRM إلى Az.

المتطلبات الأساسية

كمبيوتر تطوير يعمل:
- Visual Studio 2015 أو Visual Studio 2019.
- مجموعة أدوات تطوير البرامج (SDK) والأدوات الخاصة بـ Service Fabric .
- Docker لنظام التشغيل Windows. احصل على Docker CE لنظام التشغيل Windows (مستقر). بعد تثبيت Docker وبدء تشغيله، انقر بزر الماوس الأيمن على أيقونة العلبة وحدد Switch to Windows containers. هذه الخطوة مطلوبة لتشغيل صور Docker على Windows.
مجموعة Windows تحتوي على ثلاث عقد أو أكثر تعمل على خادم Windows مع حاويات.

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

لتحديد إصدار خادم Windows مع الحاويات التي تحتاجها لمجموعتك، قم بتشغيل ver الأمر من موجه أوامر Windows على جهاز التطوير. ارجع إلى نظام تشغيل حاوية الخادم Windows وتوافق نظام التشغيل المضيف قبل إنشاء مجموعة.
تسجيل في Azure Container Registry - إنشاء تسجيل حاوية في اشتراك Azure.

ملاحظة

يتم دعم نشر الحاويات إلى مجموعة Service Fabric تعمل على Windows 10. راجع هذه المقالة للحصول على معلومات حول كيفية تكوين Windows 10 لتشغيل حاويات Windows.

ملاحظة

تدعم إصدارات Service Fabric 6.2 والإصدارات الأحدث نشر الحاويات إلى مجموعات تعمل على الإصدار 1709 من Windows Server.

تعريف حاوية Docker

أنشئ صورة استنادًا إلى صورة Python الموجودة على Docker Hub.

حدد حاوية Docker الخاصة بك في Dockerfile. يتكون Dockerfile من تعليمات لإعداد البيئة داخل الحاوية الخاصة بك، وتحميل التطبيق الذي تريد تشغيله، وتعيين المنافذ. Dockerfile هو الإدخال إلى docker build الأمر، والذي يقوم بإنشاء الصورة.

إنشاء دليل فارغ وإنشاء ملف Dockerfile (بدون امتداد ملف). أضف ما يلي إلى Dockerfile واحفظ التغييرات:

# Use an official Python runtime as a base image
FROM python:2.7-windowsservercore

# Set the working directory to /app
WORKDIR /app

# Copy the current directory contents into the container at /app
ADD . /app

# Install any needed packages specified in requirements.txt
RUN pip install -r requirements.txt

# Make port 80 available to the world outside this container
EXPOSE 80

# Define environment variable
ENV NAME World

# Run app.py when the container launches
CMD ["python", "app.py"]

يرجى الرجوع إلى مرجع Dockerfile لمزيد من المعلومات.

إنشاء تطبيق ويب أساسي

إنشاء تطبيق ويب Flask يستمع إلى المنفذ 80 الذي يعود Hello World!. في نفس الدليل، قم بإنشاء الملف requirements.txt. أضف ما يلي واحفظ التغييرات:

Flask

قم أيضًا بإنشاء ملف app.py وأضف المقتطف التالي:

from flask import Flask

app = Flask(__name__)


@app.route("/")
def hello():

    return 'Hello World!'


if __name__ == "__main__":
    app.run(host='0.0.0.0', port=80)

بعد ذلك سنقوم بإنشاء الصورة التي تقوم بتشغيل تطبيق الويب الخاص بك. عند سحب الصور العامة من Docker (كما هو الحال python:2.7-windowsservercore في Dockerfile)، من أفضل الممارسات للمصادقة باستخدام حسابك في Docker Hub بدلًا من تقديم طلب سحب مجهول الهوية.

ملاحظة

عند تقديم طلبات سحب مجهولة متكررة، قد ترى أخطاء Docker مشابهة لـ ⁧ERROR: toomanyrequests: Too Many Requests.⁩ أو ⁧You have reached your pull rate limit.⁩ المصادقة على Docker Hub لمنع هذه الأخطاء. راجع إدارة المحتوى العام باستخدام Azure Container Registry للحصول على مزيد من المعلومات.

افتح نافذة PowerShell وانتقل إلى الدليل الذي يحتوي على Dockerfile. ثم قم بتشغيل الأوامر التالية:

docker login
docker build -t helloworldapp .

يقوم هذا الأمر بإنشاء الصورة الجديدة باستخدام الإرشادات الموجودة في Dockerfile، وتسمية (-t وضع علامات) على الصورة helloworldapp. لإنشاء صورة حاوية، يتم تنزيل الصورة الأساسية أولًا من Docker Hub ويضاف التطبيق إليها.

بمجرد اكتمال أمر الإنشاء، قم بتشغيل docker images الأمر للاطلاع على معلومات حول الصورة الجديدة:

$ docker images

REPOSITORY                    TAG                 IMAGE ID            CREATED             SIZE
helloworldapp                 latest              8ce25f5d6a79        2 minutes ago       10.4 GB

تشغيل التطبيق محلياً

تحقق من صورتك محليًا قبل دفعها إلى سجل الحاوية.

شغِّل التطبيق:

docker run -d --name my-web-site helloworldapp

اسم يعطي اسم إلى الحاوية قيد التشغيل (بدلًا من معرف الحاوية).

بمجرد بدء تشغيل الحاوية، ابحث عن عنوان IP الخاص بها بحيث يمكنك الاتصال بالحاوية قيد التشغيل من مستعرض:

docker inspect -f "{{ .NetworkSettings.Networks.nat.IPAddress }}" my-web-site

إذا لم يقم هذا الأمر بإرجاع أي شيء، فقم بتشغيل الأمر التالي وفحص عنصر NetworkSettings->Networks لعنوان IP:

docker inspect my-web-site

الاتصال بحاوية قيد التشغيل. افتح مستعرض ويب يشير إلى عنوان IP الذي تم إرجاعه، على سبيل المثال "http://172.31.194.61"؛. يجب أن ترى العنوان "مرحبًا بالعالم!" معروضًا في المتصفح.

لإيقاف الحاوية، قم بتشغيل:

docker stop my-web-site

احذف الحاوية من جهاز التطوير الخاص بك:

docker rm my-web-site

دفع الصورة إلى سجل الحاويات

بعد التحقق من تشغيل الحاوية على جهاز التطوير، ادفع الصورة إلى السجل الخاص بك في Azure Container Registry.

قم بتشغيل docker login لتسجيل الدخول إلى سجل الحاوية باستخدام بيانات اعتماد التسجيل الخاصة بك.

يقوم المثال التالي بتمرير المعرف وكلمة المرور لكيان خدمة Microsoft Azure Active Directory. على سبيل المثال، ربما تكون قد قمت بتعيين مدير خدمة إلى السجل الخاص بك لسيناريو الأتمتة. أو يمكنك تسجيل الدخول باستخدام اسم المستخدم وكلمة المرور الخاصين بالتسجيل.

docker login myregistry.azurecr.io -u xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -p myPassword

ينشئ الأمر التالي علامة أو اسمًا مستعارًا للصورة، مع مسار مؤهل بالكامل إلى السجل الخاص بك. يضع هذا المثال الصورة في samples مساحة الاسم لتجنب الفوضى في أصل التسجيل.

docker tag helloworldapp myregistry.azurecr.io/samples/helloworldapp

ادفع الصورة إلى سجل الحاويات:

docker push myregistry.azurecr.io/samples/helloworldapp

إنشاء خدمة حاوية في Visual Studio

توفر Service Fabric SDK وأدواتها قالب خدمة لمساعدتك على إنشاء تطبيق تم نقله إلى حاويات.

بدء Visual Studio. حدد "File">"New">"Project" .
حدد تطبيق Service Fabric، وأطلق عليه اسم "MyFirstContainer"، ثم انقر فوق OK.
حدد Container من قائمة قوالب الخدمة.
في Image Name، أدخل "myregistry.azurecr.io/samples/helloworldapp"، الصورة التي دفعتها إلى مستودع الحاويات.
امنح خدمتك اسمًا، ثم انقر فوق OK.

تكوين الاتصال

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

<Resources>
  <Endpoints>
    <Endpoint Name="Guest1TypeEndpoint" UriScheme="http" Port="8081" Protocol="http"/>
  </Endpoints>
</Resources>

ملاحظة

يمكن إضافة نقاط نهاية إضافية لخدمة عن طريق تعريف عناصر EndPoint إضافية مع قيم الخاصية القابلة للتطبيق. يمكن لكل منفذ الإعلان عن قيمة بروتوكول واحد فقط.

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

تستمع الخدمة على منفذ معين (8081 في هذا المثال). عند نشر التطبيق في نظام مجموعة في Azure يتم تشغيل كل من نظام المجموعة والتطبيق خلف موازن تحميل Azure. يجب أن يكون منفذ التطبيق مفتوحًا في Azure load balancer حتى تتمكن نسبة استخدام الشبكة الواردة من الوصول إلى الخدمة. يمكنك فتح هذا المنفذ في Azure load balancer باستخدام برنامج نصي PowerShell أو في مدخل Azure.

القدرة على تكوين وتعيين متغيرات البيئة

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

يعرض مقتطف XML بيان الخدمة التالي مثالاً على كيفية تحديد متغيرات البيئة لحزمة تعليمات برمجية:

<CodePackage Name="Code" Version="1.0.0">
  ...
  <EnvironmentVariables>
    <EnvironmentVariable Name="HttpGatewayPort" Value=""/>    
  </EnvironmentVariables>
</CodePackage>

يمكن تجاوز متغيرات البيئة هذه في بيان التطبيق:

<ServiceManifestImport>
  <ServiceManifestRef ServiceManifestName="Guest1Pkg" ServiceManifestVersion="1.0.0" />
  <EnvironmentOverrides CodePackageRef="FrontendService.Code">
    <EnvironmentVariable Name="HttpGatewayPort" Value="19080"/>
  </EnvironmentOverrides>
  ...
</ServiceManifestImport>

تكوين تعيين الحاوية من منفذ إلى مضيف واكتشاف حاوية إلى حاوية

تكوين منفذ مضيف يستخدم للاتصال بالحاوية. يقوم ربط المنفذ بتعيين الميناء الذي تستمع إليه الخدمة داخل الحاوية إلى ميناء على المضيف. إضافة PortBinding عنصر في ContainerHostPolicies عنصر الملف ApplicationManifest.xml. بالنسبة لهذه المقالة، ContainerPort هو 80 (تعرض الحاوية المنفذ 80، كما هو محدد في Dockerfile) EndpointRef وهي "Guest1TypeEndpoint" (نقطة النهاية المعرفة مسبقًا في بيان الخدمة). وهكذا، يتم تعيين الطلبات الواردة إلى الخدمة على المنفذ 8081 إلى المنفذ 80 على الحاوية.

<ServiceManifestImport>
    ...
    <Policies>
        <ContainerHostPolicies CodePackageRef="Code">
            <PortBinding ContainerPort="80" EndpointRef="Guest1TypeEndpoint"/>
        </ContainerHostPolicies>
    </Policies>
    ...
</ServiceManifestImport>

ملاحظة

يمكن إضافة PortBindings إضافية لخدمة بواسطة تعريف عناصر PortBinding إضافية مع قيم الخاصية القابلة للتطبيق.

تكوين مصادقة مستودع الحاوية

راجع Container Repository Authenticationلمعرفة كيفية تكوين أنواع مختلفة من المصادقة لتحميل صورة الحاوية.

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

يدعم Windows وضعي عزل للحاويات: المعالجة و Hyper-V. مع وضع عزل العملية، تشترك كافة الحاويات التي تعمل على نفس الجهاز المضيف kernel مع المضيف. مع وضع العزل Hyper-V، يتم عزل kernels بين كل حاوية Hyper-V ومضيف الحاوية. يتم تحديد وضع العزل في ContainerHostPolicies العنصر الموجود في ملف بيان التطبيق. أوضاع العزل التي يمكن تحديدها هي process، hypervو default. الافتراضي هو وضع عزل العملية على مضيفات خادم Windows. في Windows 10 المضيفين، يتم دعم وضع عزل Hyper-V فقط، وبالتالي يتم تشغيل الحاوية في وضع عزل Hyper-V بغض النظر عن إعداد وضع العزل الخاص بها. يوضح المقتطف التالي كيفية تحديد وضع العزل في ملف بيان التطبيق.

<ContainerHostPolicies CodePackageRef="Code" Isolation="hyperv">

ملاحظة

يتوفر وضع عزل hyperv على وحدات SKU Azure Ev3 و Dv3 التي تحتوي على دعم افتراضي متداخل.

تكوين إدارة الموارد

تقيد إدارة الموارد الموارد التي يمكن أن تستخدمها الحاوية على المضيف. يتم استخدام ResourceGovernancePolicy العنصر المحدد في بيان التطبيق للإعلان عن حدود الموارد لحزمة التعليمات البرمجية للخدمة. يمكن تعيين حدود الموارد للموارد التالية: الذاكرة، MemorySwap، CpuShares (CPU الوزن النسبي)، MemoryReservationInMB، BlkioWeight (الوزن النسبي BlockIO). في هذا المثال، تحصل حزمة الخدمة Guest1Pkg على نواة واحدة على عقد الكتلة حيث يتم وضعها. حدود الذاكرة مطلقة، لذا فإن حزمة الكود تقتصر على 1024 ميجابايت من الذاكرة (وحجز ضمان بسيط للذاكرة نفسها). حزم التعليمات البرمجية (حاويات أو عمليات) غير قادرة على تخصيص ذاكرة أكثر من هذا الحد، ومحاولة القيام بذلك يؤدي إلى استثناء نفاد الذاكرة. لتنفيذ الحد من الموارد للعمل، يجب أن يكون لكافة حزم التعليمات البرمجية ضمن حزمة خدمة حدود الذاكرة المحددة.

<ServiceManifestImport>
  <ServiceManifestRef ServiceManifestName="Guest1Pkg" ServiceManifestVersion="1.0.0" />
  <Policies>
    <ServicePackageResourceGovernancePolicy CpuCores="1"/>
    <ResourceGovernancePolicy CodePackageRef="Code" MemoryInMB="1024"  />
  </Policies>
</ServiceManifestImport>

تكوين Docker HEALTHCHECK

بدءًا من الإصدار 6.1، يقوم Service Fabric تلقائيًا بدمج أحداث docker HEALTHCHECK في تقرير سلامة النظام الخاص به. وهذا يعني أنه إذا تم تمكين HEALTHCHECK في الحاوية الخاصة بك، فستقوم Service Fabric بالإبلاغ عن الحالة الصحية كلما تغيرت الحالة الصحية للحاوية كما أبلغ عنها Docker. سيظهر تقرير OK في Service Fabric Explorer عندما يكون health_status بصحة جيدة وسيظهر WARNING عندما يكون health_statusغير صحي.

بدءًا من أحدث إصدار تحديث v6.4، لديك الخيار لتحديد أن تقييمات docker HEALTHCHECK يجب أن يتم الإعلام عنها كخطأ. إذا تم تمكين هذا الخيار، فسيظهر تقرير OK عندما يكون health_statusبصحة جيدة وسيظهر ERROR عندما يكون health_statusغير صحي.

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

Screenshot shows details of the Deployed Service Package NodeServicePackage.

HealthCheckUnhealthyApp

HealthCheckUnhealthyDsp

يمكنك تكوين سلوك HEALTHCHECK لكل حاوية عن طريق تحديد خيارات HealthConfig كجزء من ContainerHostPolicies في ApplicationManifest.

<ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="ContainerServicePkg" ServiceManifestVersion="2.0.0" />
    <Policies>
      <ContainerHostPolicies CodePackageRef="Code">
        <HealthConfig IncludeDockerHealthStatusInSystemHealthReport="true"
		      RestartContainerOnUnhealthyDockerHealthStatus="false" 
		      TreatContainerUnhealthyStatusAsError="false" />
      </ContainerHostPolicies>
    </Policies>
</ServiceManifestImport>

بشكل افتراضي، يتم تعيين IncludeDockerHealthStatusInSystemHealthReport إلى true، ويتم تعيين RestartContainerOnUnhealthyDockerHealthStatus إلى false، ويتم تعيين TreatContainerUnhealthyStatusAsError إلى false.

إذا تم تعيين RestartContainerOnUnhealthyDockerHealthStatus إلى true، حاوية يتم الإبلاغ عنها مرارًا وتكرارًا أنها غير صحية يتم إعادة تشغيلها (ربما على العقد الأخرى).

إذا تم تعيين TreatContainerUnhealthyStatusAsError إلى true، فستظهر تقارير حالة ERROR عندما يكون health_status الحاوية غير صحي.

إذا كنت ترغب في تعطيل تكامل HEALTHCHECK لمجموعة Service Fabric بأكملها، فستحتاج إلى تعيين EnableDockerHealthCheckIntegration إلى false.

نشر تطبيق الحاوية

احفظ جميع التغييرات الخاصة بك وأنشئ التطبيق. لنشر التطبيق الخاص بك، انقر بزر الماوس الأيمن على MyFirstContainer في مستكشف الحلول وحدد Publish.

في Connection Endpoint، أدخل نقطة نهاية إدارة الكتلة. على سبيل المثال، ⁧containercluster.westus2.cloudapp.azure.com:19000⁩. يمكنك العثور على نقطة نهاية اتصال العميل في علامة التبويب نظرة عامة لمجموعتك في مدخل Azure.

انقر على نشر.

Service Fabric Explorer هو أداة على شبكة الإنترنت لفحص وإدارة التطبيقات والعقد في كتلة Service Fabric. افتح مستعرضًا وانتقل إلى http://containercluster.westus2.cloudapp.azure.com:19080/Explorer/ نشر التطبيق وتابعه. يتم نشر التطبيق ولكنه في حالة خطأ حتى يتم تنزيل الصورة على عقد الكتلة (والتي قد تستغرق بعض الوقت، اعتمادًا على حجم الصورة): Error

يكون التطبيق جاهزًا عندما يكون في Ready حالة: Ready

افتح مستعرض ويب وانتقل إلى http://containercluster.westus2.cloudapp.azure.com:8081 . يجب أن ترى العنوان "مرحبًا بالعالم!" معروضًا في المتصفح.

التنطيف

يمكنك الاستمرار في تحمل المصاريف أثناء تشغيل الكتلة، خذ بعين الاعتبار حذف نظام المجموعة الخاص بك.

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

docker rmi helloworldapp
docker rmi myregistry.azurecr.io/samples/helloworldapp

نظام تشغيل حاوية Windows Server وتوافق نظام التشغيل المضيف

حاويات Windows Server غير متوافقة عبر جميع إصدارات نظام التشغيل المضيف. على سبيل المثال:

لا تعمل حاويات Windows Server التي تم إنشاؤها باستخدام الإصدار 1709 من Windows Server على مضيف يعمل بالإصدار 2016 Windows Server.
تعمل حاويات Windows Server التي تم إنشاؤها باستخدام Windows Server 2016 في وضع عزل Hyper-V فقط على مضيف يعمل بالإصدار 1709 Windows Server.
باستخدام حاويات Windows Server التي تم إنشاؤها باستخدام Windows Server 2016، قد يكون من الضروري التأكد من أن مراجعة نظام تشغيل الحاوية ونظام التشغيل المضيف هي نفسها عند التشغيل في وضع عزل العملية على مضيف يعمل بنظام التشغيل Windows Server 2016.

لمعرفة المزيد، راجع التوافق مع إصدار حاوية Windows.

ضع في اعتبارك توافق نظام التشغيل المضيف ونظام تشغيل الحاوية عند إنشاء الحاويات ونشرها في مجموعة Service Fabric الخاصة بك. على سبيل المثال:

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

نوصي بالممارسات التالية للتأكد من نشر الحاويات بشكل صحيح على مجموعة Service Fabric الخاصة بك:

استخدم وضع علامات على الصور الصريحة مع صور Docker لتحديد إصدار نظام التشغيل Windows Server الذي تم إنشاء حاوية منه.
استخدم وضع علامات نظام التشغيل في ملف بيان التطبيق للتأكد من أن التطبيق الخاص بك متوافق عبر إصدارات وترقيات Windows Server المختلفة.

ملاحظة

باستخدام Service Fabric الإصدار 6.2 والإصدارات الأحدث، يمكنك نشر حاويات استنادًا إلى Windows Server 2016 محليًا على مضيف Windows 10. في Windows 10، يتم تشغيل الحاويات في وضع عزل Hyper-V، بغض النظر عن وضع العزل المعين في بيان التطبيق. لمعرفة المزيد، راجع تكوين وضع العزل.

حدد نظام التشغيل لإنشاء صور حاوية محددة

قد لا تكون حاويات Windows Server متوافقة عبر إصدارات مختلفة من نظام التشغيل. على سبيل المثال، لا تعمل حاويات Windows Server التي تم إنشاؤها باستخدام Windows Server 2016 على الإصدار 1709 Windows Server في وضع عزل العملية. وبالتالي، إذا تم تحديث عقد نظام المجموعة إلى أحدث إصدار، قد تفشل خدمات الحاوية التي تم إنشاؤها باستخدام الإصدارات السابقة من نظام التشغيل. للتحايل على هذا مع الإصدار 6.1 من وقت التشغيل وأحدث، خدمة النسيج يدعم تحديد صور نظام التشغيل متعددة لكل حاوية ووضع علامات عليها مع إصدارات بناء نظام التشغيل في بيان التطبيق. يمكنك الحصول على إصدار الإصدار من نظام التشغيل عن طريق التشغيل winver في موجه أوامر Windows. قم بتحديث بيانات التطبيق وتحديد تجاوزات الصور لكل إصدار من نظام التشغيل قبل تحديث نظام التشغيل على العقد. يوضح المقتطف التالي كيفية تحديد صور حاوية متعددة في بيان التطبيق، ApplicationManifest.xml:

      <ContainerHostPolicies> 
         <ImageOverrides> 
	       <Image Name="myregistry.azurecr.io/samples/helloworldappDefault" /> 
               <Image Name="myregistry.azurecr.io/samples/helloworldapp1701" Os="14393" /> 
               <Image Name="myregistry.azurecr.io/samples/helloworldapp1709" Os="16299" /> 
         </ImageOverrides> 
      </ContainerHostPolicies>

إصدار البناء لـ Windows Server 2016 هو 14393 وإصدار البناء لـ Windows Server الإصدار 1709 هو 16299. يستمر بيان الخدمة في تحديد صورة واحدة فقط لكل خدمة حاوية كما هو موضح فيما يلي:

<ContainerHost>
    <ImageName>myregistry.azurecr.io/samples/helloworldapp</ImageName> 
</ContainerHost>

ملاحظة

تتوفر ميزات وضع العلامات على إصدار نظام التشغيل فقط لـ Service Fabric على Windows

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

ستعمل صورة الحاوية غير المعلمة كتجاوز للصورة المتوفرة في ServiceManifest. لذا فإن الصورة "myregistry.azurecr.io/samples/helloworldappDefault" ستتجاوز ImageName "myregistry.azurecr.io/samples/helloworldapp" في ServiceManifest.

أكمل تطبيق Service Fabric وبيانات الخدمة

فيما يلي بيانات الخدمة والتطبيق الكاملة المستخدمة في هذه المقالة.

ServiceManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="Guest1Pkg"
                 Version="1.0.0"
                 xmlns="http://schemas.microsoft.com/2011/01/fabric"
                 xmlns:xsd="https://www.w3.org/2001/XMLSchema"
                 xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
  <ServiceTypes>
    <!-- This is the name of your ServiceType.
         The UseImplicitHost attribute indicates this is a guest service. -->
    <StatelessServiceType ServiceTypeName="Guest1Type" UseImplicitHost="true" />
  </ServiceTypes>

  <!-- Code package is your service executable. -->
  <CodePackage Name="Code" Version="1.0.0">
    <EntryPoint>
      <!-- Follow this link for more information about deploying Windows containers to Service Fabric: https://aka.ms/sfguestcontainers -->
      <ContainerHost>
        <ImageName>myregistry.azurecr.io/samples/helloworldapp</ImageName>
        <!-- Pass comma delimited commands to your container: dotnet, myproc.dll, 5" -->
        <!--Commands> dotnet, myproc.dll, 5 </Commands-->
        <Commands></Commands>
      </ContainerHost>
    </EntryPoint>
    <!-- Pass environment variables to your container: -->    
    <EnvironmentVariables>
      <EnvironmentVariable Name="HttpGatewayPort" Value=""/>
      <EnvironmentVariable Name="BackendServiceName" Value=""/>
    </EnvironmentVariables>

  </CodePackage>

  <!-- Config package is the contents of the Config directory under PackageRoot that contains an
       independently-updateable and versioned set of custom configuration settings for your service. -->
  <ConfigPackage Name="Config" Version="1.0.0" />

  <Resources>
    <Endpoints>
      <!-- This endpoint is used by the communication listener to obtain the port on which to
           listen. Please note that if your service is partitioned, this port is shared with
           replicas of different partitions that are placed in your code. -->
      <Endpoint Name="Guest1TypeEndpoint" UriScheme="http" Port="8081" Protocol="http"/>
    </Endpoints>
  </Resources>
</ServiceManifest>

ApplicationManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest ApplicationTypeName="MyFirstContainerType"
                     ApplicationTypeVersion="1.0.0"
                     xmlns="http://schemas.microsoft.com/2011/01/fabric"
                     xmlns:xsd="https://www.w3.org/2001/XMLSchema"
                     xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
  <Parameters>
    <Parameter Name="Guest1_InstanceCount" DefaultValue="-1" />
  </Parameters>
  <!-- Import the ServiceManifest from the ServicePackage. The ServiceManifestName and ServiceManifestVersion
       should match the Name and Version attributes of the ServiceManifest element defined in the
       ServiceManifest.xml file. -->
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="Guest1Pkg" ServiceManifestVersion="1.0.0" />
    <EnvironmentOverrides CodePackageRef="FrontendService.Code">
      <EnvironmentVariable Name="HttpGatewayPort" Value="19080"/>
    </EnvironmentOverrides>
    <ConfigOverrides />
    <Policies>
      <ContainerHostPolicies CodePackageRef="Code">
        <RepositoryCredentials AccountName="myregistry" Password="MIIB6QYJKoZIhvcNAQcDoIIB2jCCAdYCAQAxggFRMIIBTQIBADA1MCExHzAdBgNVBAMMFnJ5YW53aWRhdGFlbmNpcGhlcm1lbnQCEFfyjOX/17S6RIoSjA6UZ1QwDQYJKoZIhvcNAQEHMAAEg
gEAS7oqxvoz8i6+8zULhDzFpBpOTLU+c2mhBdqXpkLwVfcmWUNA82rEWG57Vl1jZXe7J9BkW9ly4xhU8BbARkZHLEuKqg0saTrTHsMBQ6KMQDotSdU8m8Y2BR5Y100wRjvVx3y5+iNYuy/JmM
gSrNyyMQ/45HfMuVb5B4rwnuP8PAkXNT9VLbPeqAfxsMkYg+vGCDEtd8m+bX/7Xgp/kfwxymOuUCrq/YmSwe9QTG3pBri7Hq1K3zEpX4FH/7W2Zb4o3fBAQ+FuxH4nFjFNoYG29inL0bKEcTX
yNZNKrvhdM3n1Uk/8W2Hr62FQ33HgeFR1yxQjLsUu800PrYcR5tLfyTB8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBybgM5NUV8BeetUbMR8mJhgFBrVSUsnp9B8RyebmtgU36dZiSObDsI
NtTvlzhk11LIlae/5kjPv95r3lw6DHmV4kXLwiCNlcWPYIWBGIuspwyG+28EWSrHmN7Dt2WqEWqeNQ==" PasswordEncrypted="true"/>
        <PortBinding ContainerPort="80" EndpointRef="Guest1TypeEndpoint"/>
      </ContainerHostPolicies>
      <ServicePackageResourceGovernancePolicy CpuCores="1"/>
      <ResourceGovernancePolicy CodePackageRef="Code" MemoryInMB="1024"  />
    </Policies>
  </ServiceManifestImport>
  <DefaultServices>
    <!-- The section below creates instances of service types, when an instance of this
         application type is created. You can also create one or more instances of service type using the
         ServiceFabric PowerShell module.

         The attribute ServiceTypeName below must match the name defined in the imported ServiceManifest.xml file. -->
    <Service Name="Guest1">
      <StatelessService ServiceTypeName="Guest1Type" InstanceCount="[Guest1_InstanceCount]">
        <SingletonPartition />
      </StatelessService>
    </Service>
  </DefaultServices>
</ApplicationManifest>

تكوين الفاصل الزمني قبل إنهاء الحاوية بالقوة

يمكنك تكوين فاصل زمني لوقت التشغيل للانتظار قبل إزالة الحاوية بعد بدء حذف الخدمة (أو الانتقال إلى عقدة أخرى). يؤدي تكوين الفاصل الزمني إلى إرسال docker stop <time in seconds> الأمر إلى الحاوية. لمزيد من التفاصيل، راجع إيقاف docker. يتم تحديد الفاصل الزمني للانتظار ضمن Hosting القسم. يمكن Hosting إضافة القسم في نظام المجموعة أو في وقت لاحق في ترقية التكوين. يوضح مقتطف بيان نظام المجموعة التالي كيفية تعيين الفاصل الزمني للانتظار:

"fabricSettings": [
	...,
	{
        "name": "Hosting",
        "parameters": [
          {
                "name": "ContainerDeactivationTimeout",
                "value" : "10"
          },
	      ...
        ]
	}
]

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

تكوين وقت التشغيل لإزالة صور الحاويات غير المستخدمة

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

"fabricSettings": [
	...,
	{
        "name": "Hosting",
        "parameters": [
          {
                "name": "PruneContainerImages",
                "value": "True"
          },
          {
                "name": "ContainerImagesToSkip",
                "value": "mcr.microsoft.com/windows/servercore|mcr.microsoft.com/windows/nanoserver|mcr.microsoft.com/dotnet/framework/aspnet|..."
          }
          ...
          }
        ]
	} 
]

بالنسبة للصور التي لا ينبغي حذفها، يمكنك تحديدها ضمن ContainerImagesToSkip المعلمة.

تكوين وقت تنزيل صورة الحاوية

يخصص وقت تشغيل Service Fabric 20 دقيقة لتنزيل صور الحاويات واستخراجها، والتي تعمل مع غالبية صور الحاويات. بالنسبة للصور الكبيرة، أو عندما يكون اتصال الشبكة بطيئًا، قد يكون من الضروري زيادة وقت الانتظار قبل إجهاض تنزيل الصورة واستخراجها. يتم تعيين هذه المهلة باستخدام السمة ContainerImageDownloadTimeout في قسم Hosting من بيان المجموعة كما هو موضح في المقتطف التالي:

"fabricSettings": [
	...,
	{
        "name": "Hosting",
        "parameters": [
          {
              "name": "ContainerImageDownloadTimeout",
              "value": "1200"
          }
        ]
	}
]

تعيين سياسة الاحتفاظ بالحاويات

للمساعدة في تشخيص حالات فشل بدء تشغيل الحاويات، يدعم Service Fabric (الإصدار 6.1 أو أعلى) الاحتفاظ بالحاويات التي تم إنهاؤها أو تعذر بدء تشغيلها. يمكن تعيين هذه السياسة في ملف ApplicationManifest.xml كما هو موضح في القصاصة البرمجية التالية:

 <ContainerHostPolicies CodePackageRef="NodeService.Code" Isolation="process" ContainersRetentionCount="2"  RunInteractive="true">

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

بدء تشغيل برنامج Docker الخفي باستخدام وسيطات مخصصة

باستخدام الإصدار 6.2 من وقت تشغيل Service Fabric والإصدارات الأكبر، يمكنك بدء تشغيل برنامج Docker الخفي باستخدام وسيطات مخصصة. عند تحديد وسيطات مخصصة، لا يقوم Service Fabric بتمرير أي وسيطة أخرى إلى محرك docker باستثناء --pidfile الوسيطة. وبالتالي، --pidfile لا ينبغي تمريرها كوسيطة. بالإضافة إلى ذلك، يجب أن تستمر الوسيطة في جعل برنامج docker الخفي يستمع إلى مسار الاسم الافتراضي على Windows (أو مقبس مجال unix على Linux) لـ Service Fabric للاتصال ب Daemon. يتم تمرير الوسيطات المخصصة في بيان الكتلة ضمن قسم Hosting ضمن ContainerServiceArguments كما هو موضح في المقتطف التالي:

"fabricSettings": [
	...,
	{ 
        "name": "Hosting", 
        "parameters": [ 
          { 
            "name": "ContainerServiceArguments", 
            "value": "-H localhost:1234 -H unix:///var/run/docker.sock" 
          } 
        ] 
	} 
]

تجاوز نقطة الدخول

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

فيما يلي مثال على كيفية تجاوز نقطة دخول الحاوية:

ApplicationManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest ApplicationTypeName="MyFirstContainerType"
                     ApplicationTypeVersion="1.0.0"
                     xmlns="http://schemas.microsoft.com/2011/01/fabric"
                     xmlns:xsd="https://www.w3.org/2001/XMLSchema"
                     xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
  <Parameters>
    <Parameter Name="ImageName" DefaultValue="myregistry.azurecr.io/samples/helloworldapp" />
    <Parameter Name="Commands" DefaultValue="commandsOverride" />
    <Parameter Name="FromSource" DefaultValue="sourceOverride" />
    <Parameter Name="EntryPoint" DefaultValue="entryPointOverride" />
  </Parameters>
  <!-- Import the ServiceManifest from the ServicePackage. The ServiceManifestName and ServiceManifestVersion
       should match the Name and Version attributes of the ServiceManifest element defined in the
       ServiceManifest.xml file. -->
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="Guest1Pkg" ServiceManifestVersion="1.0.0" />
    <ConfigOverrides />
    <Policies>
      <CodePackagePolicy CodePackageRef="Code">
        <EntryPointOverride>
         <ContainerHostOverride>
            <ImageOverrides>
              <Image Name="[ImageName]" />
            </ImageOverrides>
            <Commands>[Commands]</Commands>
            <FromSource>[Source]</FromSource>
            <EntryPoint>[EntryPoint]</EntryPoint>
          </ContainerHostOverride>
        </EntryPointOverride>
      </CodePackagePolicy>
    </Policies>
  </ServiceManifestImport>
</ApplicationManifest>

ServiceManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="Guest1Pkg"
                 Version="1.0.0"
                 xmlns="http://schemas.microsoft.com/2011/01/fabric"
                 xmlns:xsd="https://www.w3.org/2001/XMLSchema"
                 xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
  <ServiceTypes>
    <!-- This is the name of your ServiceType.
         The UseImplicitHost attribute indicates this is a guest service. -->
    <StatelessServiceType ServiceTypeName="Guest1Type" UseImplicitHost="true" />
  </ServiceTypes>

  <!-- Code package is your service executable. -->
  <CodePackage Name="Code" Version="1.0.0">
    <EntryPoint>
      <!-- Follow this link for more information about deploying Windows containers to Service Fabric: https://aka.ms/sfguestcontainers -->
      <ContainerHost>
        <ImageName>default imagename</ImageName>
        <Commands>default cmd</Commands>
        <EntryPoint>default entrypoint</EntryPoint>
        <FromSource>default source</FromSource>
      </ContainerHost>
    </EntryPoint>
  </CodePackage>

  <ConfigPackage Name="Config" Version="1.0.0" />
</ServiceManifest>

بعد تحديد التجاوزات في بيان التطبيق، سيتم بدء تشغيل الحاوية التي تحمل اسم الصورة myregistry.azurecr.io/samples/helloworldapp وأوامر commandsOverride ومصدر sourceOverride وإدخال نقطة دخول entryPointOverride.

وبالمثل، فيما يلي مثال على كيفية تجاوز ExeHost:

<?xml version="1.0" encoding="utf-8"?>
<Policies>
  <CodePackagePolicy CodePackageRef="Code">
    <EntryPointOverride>
      <ExeHostOverride>
        <Program>[Program]</Program>
        <Arguments>[Entry]</Arguments>
      </ExeHostOverride>
    </EntryPointOverride>
  </CodePackagePolicy>
</Policies>

ملاحظة

تجاوز نقطة الإدخال غير معتمد لـ SetupEntryPoint.

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

تعرف على المزيد حول تشغيل الحاويات على Service Fabric.
اقرأ نشر تطبيق .NET في برنامج تعليمي للحاوية.
تعرف على دورة حياة تطبيق Service Fabric.
تحقق من عينات التعليمات البرمجية لحاوية Service Fabric على GitHub.

قم بإنشاء أول تطبيق حاوية Service Fabric على نظام Windows

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

المتطلبات الأساسية

تعريف حاوية Docker

إنشاء تطبيق ويب أساسي

تسجيل الدخول إلى Docker وتحويل الصورة برمجيًا

تشغيل التطبيق محلياً

دفع الصورة إلى سجل الحاويات

إنشاء خدمة حاوية في Visual Studio

تكوين الاتصال

القدرة على تكوين وتعيين متغيرات البيئة

تكوين تعيين الحاوية من منفذ إلى مضيف واكتشاف حاوية إلى حاوية

تكوين مصادقة مستودع الحاوية

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

تكوين إدارة الموارد

تكوين Docker HEALTHCHECK

نشر تطبيق الحاوية

التنطيف

نظام تشغيل حاوية Windows Server وتوافق نظام التشغيل المضيف

حدد نظام التشغيل لإنشاء صور حاوية محددة

أكمل تطبيق Service Fabric وبيانات الخدمة

ServiceManifest.xml

ApplicationManifest.xml

تكوين الفاصل الزمني قبل إنهاء الحاوية بالقوة

تكوين وقت التشغيل لإزالة صور الحاويات غير المستخدمة

تكوين وقت تنزيل صورة الحاوية

تعيين سياسة الاحتفاظ بالحاويات

بدء تشغيل برنامج Docker الخفي باستخدام وسيطات مخصصة

تجاوز نقطة الدخول

ApplicationManifest.xml

ServiceManifest.xml

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