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

مقالة
05/11/2023

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

إشعار

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

إشعار

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

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

كمبيوتر تطوير يعمل:
- Visual Studio 2015 أو Visual Studio 2019.
- Service Fabric SDK والأدوات.
- 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. Docker Hub أو You have reached your pull rate limit. المصادقة عليها لمنع هذه الأخطاء. راجع إدارة المحتوى العام باستخدام 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"؛. يجب أن ترى العنوان "Hello World!" ظاهراً في المتصفح .

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

docker stop my-web-site

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

docker rm my-web-site

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

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

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

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

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"، الصورة التي دفعتها إلى مستودع الحاويات.
امنح خدمتك اسمًا، ثم انقر فوق موافق.

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

تحتاج الخدمة المعبأة في حاويات إلى نقطة نهاية للاتصال. أضف 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 إضافية مع قيم الخاصية القابلة للتطبيق.

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

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

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

يدعم 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>

تكوين عامل المرسى HEALTHCHECK

بدءا من الإصدار 6.1 ، يقوم تصميم الخدمة بشكل تلقائي بدمج أحداث HEALTHCHECK الخاصة بعامل الرصيف في تقرير سلامة النظام الخاص به. وهذا يعني أنه إذا تم تمكين HEALTHCHECK في الحاوية الخاصة بك، يقوم تصميم الخدمة بالإبلاغ عن الحالة الصحية كلما تغيرت الحالة الصحية للحاوية كما أبلغ عنها Docker. يظهر تقرير " موافق " في "مستكشف تصميم الخدمة" عندما تكون حالة الصحةبصحة جيدة ويظهر تحذير عندما يكون حالة الصحةغير غير جيدة.

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

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

لقطة شاشة تعرض تفاصيل حزمة الخدمة المُوزعة 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 خطأ .

إذا تم تعيين 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/ نشر التطبيق وتابعه. يتم نشر التطبيق ولكنه في حالة خطأ حتى يتم تنزيل الصورة على عقد نظام المجموعة (والتي قد تستغرق بعض الوقت، اعتمادا على حجم الصورة): خطأ

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

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

تنظيف

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

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

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 Container Version Compatibility.

ضع في اعتبارك توافق نظام التشغيل المضيف ونظام تشغيل الحاوية عند إنشاء الحاويات ونشرها في مجموعة 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.

مثال كامل على تطبيق تصميم الخدمة وبيانات الخدمة

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

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 ثوان. نظرا لأن هذا التكوين ديناميكي، فإن التكوين يقوم فقط بالترقية على نظام المجموعة عن طريق تحديث المهلة.

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

يمكنك تكوين مجموعة تصميم الخدمة لإزالة صور الحاوية غير المستخدمة من العقدة. يسمح هذا التكوين بإعادة التقاط مساحة القرص في حالة وجود عدد كبير جدًا من صور الحاوية على العقدة. لتمكين هذه الميزة، قم بتحديث قسم 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 من وقت تشغيل تصميم الخدمة والإصدارات الأكبر، يمكنك بدء تشغيل برنامج Docker الخفي باستخدام وسيطات مخصصة. عند تحديد وسيطات مخصصة، لا يقوم تصميم الخدمة بتمرير أي وسيطة أخرى إلى محرك 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.

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

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

مشاركة عبر

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

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

تعريف حاوية Docker

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

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

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

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

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

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

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

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

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

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

تكوين عامل المرسى HEALTHCHECK

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

تنظيف

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

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

مثال كامل على تطبيق تصميم الخدمة وبيانات الخدمة

ServiceManifest.xml

ApplicationManifest.xml

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

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

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

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

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

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

ApplicationManifest.xml

ServiceManifest.xml

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

الموارد الإضافية

مشاركة عبر

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

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

تعريف حاوية Docker

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

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

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

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

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

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

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

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

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

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

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

تكوين عامل المرسى HEALTHCHECK

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

تنظيف

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

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

مثال كامل على تطبيق تصميم الخدمة وبيانات الخدمة

ServiceManifest.xml

ApplicationManifest.xml

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

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

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

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

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

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

ApplicationManifest.xml

ServiceManifest.xml

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

الموارد الإضافية