مشاركة عبر

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

  • مقالة

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

إشعار

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

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

تعريف حاوية 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-slim

# 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 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 الذي يقوم بإرجاع "مرحبًا بالعالم!". في نفس الدليل، قم بإنشاء الملف 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 وتحويل الصورة برمجيًا

بعد ذلك سنقوم بإنشاء الصورة التي تدير تطبيق الويب الخاص بك. عند سحب الصور العامة من Docker (كما هو الحال python:2.7-slim في 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              86838648aab6        2 minutes ago       194 MB

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

تحقق من تشغيل التطبيق الحاوية محليًا قبل دفعه إلى سجل الحاويات:

تشغيل التطبيق تعيين منفذ الكمبيوتر 4000 إلى المنفذ المكشوف الحاوية 80:

docker run -d -p 4000:80 --name my-web-site helloworldapp

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

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

Hello World!

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

docker stop my-web-site

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

docker rm my-web-site

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

بعد التحقق من أن التطبيق يعمل في Docker، دفع الصورة إلى التسجيل الخاص بك في Azure حاوية التسجيل.

تشغيل 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

حزم صورة Docker باستخدام Yeoman

يتضمن Sdk النسيج خدمة لينكس مولد يومان الذي يجعل من السهل إنشاء التطبيق الخاص بك وإضافة صورة حاوية. دعونا نستخدم يومان لإنشاء تطبيق مع حاوية دوكر واحدة تسمى SimpleContainerApp.

لإنشاء تطبيق حاوية Service Fabric، افتح نافذة طرفية وقم بتشغيل yo azuresfcontainer.

اسم التطبيق الخاص بك (على سبيل المثال، mycontainer ) واسم خدمة التطبيق (على سبيل المثال، myservice ).

للحصول على اسم الصورة، قم بتوفير URL لصورة الحاوية في سجل حاوية (على سبيل المثال، "myregistry.azurecr.io/samples/helloworldapp").

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

حدد عدد مثيلات بـ 1.

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

Service Fabric Yeoman generator for containers

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

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

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

مع الإصدار 6.3 وقت التشغيل، يتم دعم عزل VM لحاويات لينكس، وبالتالي دعم وضعي عزل للحاويات: عملية وHyper-V. مع موضع العزل Hyper-V، يتم عزل kernels بين كل حاوية ومضيف الحاوية. تنفيذ العزل Hyper-V باستخدام حاويات واضحة. تحديد وضع العزل لمجموعات لينكس في ServicePackageContainerPolicy العنصر في ملف بيان التطبيق. الأوضاع الخاصة بالعزل التي يمكن تحديدها هي process، hypervو default. الوضع الافتراضي هو وضع عزل العملية. يوضح المقتطف التالي كيفية تحديد وضع العزل في ملف بيان التطبيق.

<ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="MyServicePkg" ServiceManifestVersion="1.0.0"/>
      <Policies>
        <ServicePackageContainerPolicy Hostname="votefront" Isolation="hyperv">
          <PortBinding ContainerPort="80" EndpointRef="myServiceTypeEndpoint"/>
        </ServicePackageContainerPolicy>
    </Policies>
  </ServiceManifestImport>

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

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

<ServiceManifestImport>
  <ServiceManifestRef ServiceManifestName="MyServicePKg" 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 المستخدم أثناء عملية إنشاء صورة الحاوية.

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 خطأ .

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

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

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

قم بنشر التطبيق

بمجرد إنشاء التطبيق، يمكنك استخدامه على الكتلة المحلية باستخدام تصميم الخدمة الخاصة بـ CLI.

قم بالاتصال بمجموعة "تصميم الخدمة" المحلية.

sfctl cluster select --endpoint http://localhost:19080

استخدم البرنامج النصي الخاص بتثبيت المتوفر في الدليل https://github.com/Azure-Samples/service-fabric-containers/ لنسخ حزمة التطبيق إلى مخزن صور المجموعة، وتسجيل نوع التطبيق، وإنشاء مثيل التطبيق.

./install.sh

فتح متصفح وانتقل إلى مستكشف تصميم الخدمة على (استبدل المضيف المحلي بعنوان IP الخاص بالجهاز الظاهري إذا كنت تستخدم Vagrant على http://localhost:19080/Explorer نظام التشغيل Mac OS X). قم بتوسيع عقدة التطبيقات ولاحظ أن هناك الآن إدخال خاص لنوع التطبيق وآخر للمثيل الأول من هذا النوع.

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

Hello World!

تنظيف

استخدم البرنامج المتعلق بإلغاء التثبيت النصي الموفر في القالب لحذف مثيل التطبيق من مجموعة التطوير المحلي وإلغاء تسجيل نوع التطبيق.

./uninstall.sh

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

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

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

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

ServiceManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="myservicePkg"
                 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="myserviceType" 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 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="VariableName" Value="VariableValue"/>
      -->
    </EnvironmentVariables>
    
  </CodePackage>

  <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="myServiceTypeEndpoint" UriScheme="http" Port="4000" Protocol="http"/>
    </Endpoints>
  </Resources>
</ServiceManifest>

ApplicationManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest ApplicationTypeName="mycontainerType"
                     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">
  <!-- 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="myservicePkg" ServiceManifestVersion="1.0.0" />
    <ConfigOverrides />
    <Policies>
      <ContainerHostPolicies CodePackageRef="Code">
        <RepositoryCredentials AccountName="myregistry" Password="=P==/==/=8=/=+u4lyOB=+=nWzEeRfF=" PasswordEncrypted="false"/>
        <PortBinding ContainerPort="80" EndpointRef="myServiceTypeEndpoint"/>
      </ContainerHostPolicies>
    </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="myservice">
      <!-- On a local development cluster, set InstanceCount to 1. On a multi-node production 
      cluster, set InstanceCount to -1 for the container service to run on every node in 
      the cluster.
      -->
      <StatelessService ServiceTypeName="myserviceType" InstanceCount="1">
        <SingletonPartition />
      </StatelessService>
    </Service>
  </DefaultServices>
</ApplicationManifest>

إضافة المزيد من الخدمات إلى تطبيق حالي

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

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

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

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

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

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

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

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

{
        "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 المعلمة.

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

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

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

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

للمساعدة في تشخيص حالات فشل بدء تشغيل الحاويات، يدعم تصميم الخدمة (الإصدار 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 daemon يستمع إلى أنبوب الاسم الافتراضي على Windows (أو مقبس مجال unix على Linux) لتصميم الخدمة للاتصال بالبرنامج الخفي. تحديد الوسيطات المخصصة الخاصة ببيان نظام المجموعة ضمن قسم الاستضافة ضمن ContainerServiceArguments. يظهر مثال في القصاصة البرمجية التالية:

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

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