Vytvoření první aplikace Service Fabric typu kontejner v systému Windows

Spuštění existující aplikace v kontejneru Windows v clusteru Service Fabric nevyžaduje žádné změny aplikace. Tento článek vás provede vytvořením image Dockeru obsahující webovou aplikaci Python Flask a nasazením do clusteru Azure Service Fabric. Kontejnerizovanou aplikaci budete také sdílet prostřednictvím služby Azure Container Registry. Tento článek předpokládá základní znalost Dockeru. Informace o Dockeru najdete v článku Docker Overview (Přehled Dockeru).

Poznámka

Tento článek se týká Windows vývojového prostředí. Modul Service Fabric clusteru a modul runtime Dockeru musí být spuštěné ve stejném operačním systému. V clusteru s Linuxem Windows spustit kontejnery.

Poznámka

Tento článek používá modul Azure Az PowerShell, což je doporučený modul PowerShellu pro interakci s Azure. Pokud chcete začít s modulem Az PowerShell, projděte si téma věnované instalaci Azure PowerShellu. Informace o tom, jak migrovat na modul Az PowerShell, najdete v tématu Migrace Azure PowerShellu z AzureRM na Az.

Požadavky

  • Vývojový počítač s:

    • Visual Studio 2015 nebo Visual Studio 2019.
    • Service Fabric SDK a nástroje.
    • Docker pro Windows. Získejte Docker CE pro Windows (stabilní verze). Po nainstalování a spuštění Dockeru klikněte pravým tlačítkem myši na ikonu na hlavním panelu a vyberte Switch to Windows containers (Přepnout na kontejnery Windows). Tento krok se vyžaduje pro spuštění imagí Dockeru založených na Windows.
  • Cluster Windows se třemi nebo více uzly běžící na Windows Server s kontejnery.

    Pro tento článek se verze (sestavení) Windows Server s kontejnery spuštěná na uzlech clusteru musí shodovat s verzí na vašem počítači pro vývoj. Je to proto, že na vývojovém počítači sestavíte image Dockeru a mezi verzemi operačního systému kontejneru a hostitelským operačním systémem, na kterém je nasazený, existují omezení kompatibility. Další informace najdete v tématu Windows Operační systém kontejneru serveru a kompatibilita operačního systému hostitele.

    Pokud chcete zjistit verzi Windows Server s kontejnery, kterou potřebujete pro svůj cluster, spusťte příkaz z příkazového řádku Windows na ver vývojovém počítači. Před vytvořením Windows si přečtěte informace o kompatibilitě operačního systému kontejneru a hostitelského operačníhosystému serveru.

  • Registr ve službě Azure Container Registry – Vytvořte registr kontejneru ve svém předplatném Azure.

Poznámka

Nasazení kontejnerů do clusteru Service Fabric spuštěném v Windows 10 se podporuje. V tomto článku najdete informace o tom, jak nakonfigurovat Windows 10 spouštění Windows kontejnerů.

Poznámka

Service Fabric verze 6.2 a novější podporují nasazování kontejnerů do clusterů běžících na Windows Serveru verze 1709.

Definice kontejneru Dockeru

Sestavte image založenou na imagi Pythonu, která se nachází na Docker Hubu.

Zadejte kontejner Dockeru v souboru Dockerfile. Soubor Dockerfile obsahuje pokyny k nastavení prostředí uvnitř kontejneru, načtení aplikace, kterou chcete spustit, a mapování portů. Soubor Dockerfile je vstupem příkazu docker build, který vytvoří image.

Vytvořte prázdný adresář a soubor Dockerfile (bez přípony souboru). Do souboru Dockerfile přidejte následující a uložte změny:

# 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"]

Další informace najdete v referenčních informacích k souboru Dockerfile.

Vytvoření základní webové aplikace

Vytvořte webovou aplikaci Flask, která naslouchá na portu 80 a vrací Hello World!. Ve stejném adresáři vytvořte soubor requirements.txt. Přidejte do něj následující a uložte změny:

Flask

Vytvořte také soubor app.py a přidejte do něj následující fragment kódu:

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)

Přihlaste se k Dockeru a sestavte image.

Dále vytvoříme image, na které běží vaše webová aplikace. Při vyžadování veřejných imagí z Dockeru (jako v našem souboru Dockerfile) je osvědčeným postupem ověřování pomocí vašeho účtu Docker Hub místo vytvoření anonymní žádosti o python:2.7-windowsservercore stažení.

Poznámka

Při provádění častých anonymních žádostí o přístup k žádostem o přístup se můžou zobrazit chyby Dockeru podobné Docker Hub ověřování, aby se ERROR: toomanyrequests: Too Many Requests. You have reached your pull rate limit. těmto chybám zabránilo. Další informace najdete v tématu Správa Azure Container Registry obsahu pomocí služby .

Otevřete okno PowerShellu a přejděte do adresáře, který obsahuje soubor Dockerfile. Potom spusťte následující příkazy:

docker login
docker build -t helloworldapp .

Tento příkaz sestaví novou image podle pokynů ve vašem souboru Dockerfile a pojmenuje ji (označení -t) helloworldapp. Pro sestavení image kontejneru se nejprve z Docker Hubu stáhne základní image, do které se přidá aplikace.

Po dokončení příkazu pro sestavení spusťte příkaz docker images a zobrazte informace o nové imagi:

$ docker images

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

Aplikaci spustíte místně.

Než image nahrajete do registru kontejneru, ověřte ji místně.

Spusťte aplikaci:

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

Parametr name udává název spuštěného kontejneru (namísto ID kontejneru).

Po spuštění kontejneru vyhledejte jeho IP adresu, abyste se ke spuštěnému kontejneru mohli připojit z prohlížeče:

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

Pokud tento příkaz nic nevrátí, spusťte následující příkaz a zkontrolujte IP adresu v elementu NetworkSettings -> Networks:

docker inspect my-web-site

Připojte se ke spuštěnému kontejneru. Otevřete webový prohlížeč a přejděte na vrácenou IP adresu, například http: / /172.31.194.61. V prohlížeči by se měl zobrazit nadpis „Hello World!“.

Pokud chcete kontejner zastavit, spusťte:

docker stop my-web-site

Odstraňte kontejner z vývojového počítače:

docker rm my-web-site

Nahrání image do registru kontejneru

Po ověření, že se kontejner spustí na vývojovém počítači, nahrajte image do vašeho registru ve službě Azure Container Service.

Spuštěním docker login se přihlaste ke svému registru kontejneru pomocí přihlašovacích údajů registru.

Následující příklad předá ID a heslo instančního objektu Azure Active Directory. Instanční objekt jste k registru mohli přiřadit například pro účely scénáře automatizace. Nebo se můžete přihlásit pomocí uživatelského jména a hesla registru.

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

Následující příkaz vytvoří značku, neboli alias, image s plně kvalifikovanou cestou k vašemu registru. Tento příklad umístí image do oboru názvů samples, aby se zabránilo nepořádku v kořenovém adresáři registru.

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

Nahrajte image do registru kontejneru:

docker push myregistry.azurecr.io/samples/helloworldapp

Vytvoření kontejnerizované služby v sadě Visual Studio

Sada Service Fabric SDK a nástroje poskytují šablonu služby, která vám pomůže s vytvořením kontejnerizované aplikace.

  1. Spusťte Visual Studio. Vyberte Soubor > Nový > Project.
  2. Vyberte Aplikace Service Fabric, pojmenujte ji MyFirstContainer a klikněte na OK.
  3. Ze seznamu šablon služeb vyberte Kontejner.
  4. Do pole Název image zadejte „myregistry.azurecr.io/samples/helloworldapp“, tedy image, kterou jste nahráli do úložiště kontejnerů.
  5. Zadejte název služby a klikněte na OK.

Konfigurace komunikace

Kontejnerizovaná služba potřebuje koncový bod pro komunikaci. Do souboru ServiceManifest.xml přidejte element Endpoint s protokolem, portem a typem. V tomto příkladu se používá pevný port 8081. Pokud port není zadaný, zvolí se v rozsahu portů aplikace náhodně.

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

Poznámka

Další koncové body pro službu je možné přidat deklarováním dalších elementů EndPoint s příslušnými hodnotami vlastností. Každý port může deklarovat pouze jednu hodnotu protokolu.

Když Service Fabric definuje koncový bod, publikuje ho ve službě pojmenování. Ostatní služby spuštěné v clusteru mohou tento kontejner vyhledat. Ke komunikaci mezi kontejnery můžete také využít reverzní proxy server. Komunikace se provede tak, že se reverznímu proxy serveru poskytne port pro naslouchání HTTP a název služeb, se kterými chcete komunikovat, jako proměnné prostředí.

Služba naslouchá na určitém portu (v tomto příkladu je to 8081). Když se aplikace nasadí do clusteru v Azure, běží cluster i aplikace na pozadí služby Azure Load Balancer. Port aplikace ve službě Azure Load Balancer musí být otevřený, aby příchozí přenosy měly ke službě přístup. Tento port můžete otevřít ve službě Azure Load Balancer pomocí skriptu PowerShellu nebo na webu Azure Portal.

Konfigurace a nastavení proměnných prostředí

Proměnné prostředí je možné zadat pro každý balíček kódu v manifestu služby. Tato funkce je dostupná pro všechny služby, bez ohledu na to, jestli jsou nasazené jako kontejnery, procesy nebo spustitelné soubory typu Host. Hodnoty proměnných prostředí můžete přepsat v manifestu aplikace, nebo je můžete zadat v průběhu nasazení jako parametry aplikace.

Následující fragment kódu XML manifestu služby ukazuje příklad toho, jak zadat proměnné prostředí pro balíček kódu:

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

Tyto proměnné prostředí je možné přepsat v manifestu aplikace:

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

Konfigurace mapování portu kontejneru na port hostitele a zjišťování mezi kontejnery

Nakonfigurujte port hostitele používaný ke komunikaci s kontejnerem. Vazba portu mapuje port, na kterém služba naslouchá uvnitř kontejneru, na port na hostiteli. Přidejte element PortBinding do ContainerHostPolicies v souboru ApplicationManifest.xml. Pro účely tohoto článku je ContainerPort nastaven na 80 (kontejner zpřístupňuje port 80, jak je uvedené v souboru Dockerfile) a EndpointRef je „Guest1TypeEndpoint“ (koncový bod dříve definovaný v manifestu služby). Příchozí požadavky na službu na portu 8081 se mapují na port 80 v kontejneru.

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

Poznámka

Další PortBindings pro službu lze přidat deklarováním dalších prvků PortBinding s použitelnými hodnotami vlastností.

Konfigurace ověřování úložiště kontejnerů

V tématu ověřování úložiště kontejnerůse dozvíte, jak nakonfigurovat různé typy ověřování pro stahování imagí kontejneru.

Konfigurace režimu izolace

Systém Windows podporuje pro kontejnery dva režimy izolace: procesy a Hyper-V. V režimu izolace procesů všechny kontejnery spuštěné na stejném hostitelském počítači sdílejí jádro s hostitelem. V režimu izolace Hyper-V se jádra pro jednotlivé kontejnery Hyper-V a hostitele kontejneru izolují. Režim izolace určuje element ContainerHostPolicies v souboru manifestu aplikace. Je možné zadat tyto režimy izolace: process, hyperv a default. výchozím nastavením je režim izolace procesu na hostitelích Windows serveru. u Windows 10 hostitelů je podporována pouze izolovaný režim technologie hyper-v, takže se kontejner spouští v režimu izolace technologie hyper-v bez ohledu na nastavení režimu izolace. Následující fragment kódu ukazuje, jakým způsobem je režim izolace určený v souboru manifestu aplikace.

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

Poznámka

Režim izolace hyperv je k dispozici ve skladových položkách Azure Ev3 a Dv3 s podporou vnořené virtualizace.

Konfigurace zásad správného řízení prostředků

Zásady správného řízení prostředků omezují prostředky, které kontejner může použít na hostiteli. Element ResourceGovernancePolicy, který je zadaný v manifestu aplikace, slouží k deklaraci omezení prostředků pro balíček kódu služby. Omezení prostředků je možné nastavit pro tyto prostředky: Memory, MemorySwap, CpuShares (relativní váha CPU), MemoryReservationInMB, BlkioWeight (relativní váha BlockIO). V tomto příkladu balíček služby Guest1Pkg získá jedno jádro na uzlech clusteru, kde je umístěný. Omezení paměti jsou absolutní, takže balíček kódu je omezený na 1024 MB paměti (a má tuto paměť softwarově vyhrazenou). Balíčky kódu (kontejnery a procesy) nejsou schopné přidělit víc paměti, než je toto omezení, a případný pokus o takové přidělení má za následek výjimku z důvodu nedostatku paměti. Aby vynucení omezení prostředků fungovala, musí být omezení paměti zadaná pro všechny balíčky kódu v rámci balíčku služby.

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

Konfigurace dockeru HEALTHCHECK

Počínaje v6.1 Service Fabric automaticky integruje události dockeru HEALTHCHECK do sestavy stavu systému. To znamená, že pokud váš kontejner má HEALTHCHECK povolený, Service Fabric oznámí stav vždy, když se změní stav kontejneru (nahlášený Dockerem). Pokud health_status je healthy, v Service Fabric Exploreru se zobrazí sestava stavu OK. Pokud health_status je unhealthy, zobrazí se UPOZORNĚNÍ.

Počínaje nejnovější verzí aktualizace v 6.4 máte možnost určit, že se mají tato hodnocení Docker HEALTHCHECK hlásit jako chyba. Pokud je tato možnost povolená, zobrazí se zpráva o stavu OK , když health_status je v pořádku a zobrazí se Chyba , když health_status není v pořádku.

Instrukce HEALTHCHECK ukazující na skutečnou kontrolu prováděnou pro monitorování stavu kontejneru musí být přítomna v souboru Dockerfile použitém při generování image kontejneru.

Snímek obrazovky zobrazuje podrobnosti o nasazeném balíčku služby NodeServicePackage.

HealthCheckUnhealthyApp

HealthCheckUnhealthyDsp

Chování HEALTHCHECK pro jednotlivé kontejnery můžete nakonfigurovat zadáním možností HealthConfig jako součásti ContainerHostPolicies v manifestu aplikace.

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

Ve výchozím nastavení je IncludeDockerHealthStatusInSystemHealthReport nastaveno na hodnotu true, hodnota RestartContainerOnUnhealthyDockerHealthStatus je nastavena na hodnotu false a vlastnost TreatContainerUnhealthyStatusAsError je nastavena na hodnotu false.

Pokud je pro RestartContainerOnUnhealthyDockerHealthStatus nastavená hodnota true, kontejner, který je opakovaně nahlášený ve špatném stavu, se restartuje (potenciálně na jiných uzlech).

Pokud je TreatContainerUnhealthyStatusAsError nastavené na true, zobrazí se chybové zprávy o stavu, když health_status kontejneru není v pořádku.

Pokud chcete zakázat integraci HEALTHCHECK pro celý cluster Service Fabric, musíte nastavit EnableDockerHealthCheckIntegration na false.

Nasazení aplikace typu kontejner

Uložte všechny provedené změny a sestavte aplikaci. Pokud chcete aplikaci publikovat, klikněte pravým tlačítkem na MyFirstContainer v Průzkumníku řešení a vyberte Publikovat.

Do pole Koncový bod připojení zadejte koncový bod správy pro příslušný cluster. Například, containercluster.westus2.cloudapp.azure.com:19000. Koncový bod připojení klienta najdete na kartě Přehled pro váš cluster na webu Azure Portal.

Klikněte na Publikovat.

Service Fabric Explorer je webový nástroj pro kontrolu a správu aplikací a uzlů v clusteru Service Fabric. Otevřete prohlížeč, přejděte na adresu http://containercluster.westus2.cloudapp.azure.com:19080/Explorer/ a postupujte podle pokynů k nasazení aplikace. Aplikace se nasadí, ale bude v chybovém stavu, dokud se image nestáhne na uzlech clusteru (což v závislosti na velikosti image může nějakou dobu trvat): Chyba

Aplikace je připravena, když je ve stavu Ready: Připraveno

Otevřete prohlížeč a přejděte na adresu http://containercluster.westus2.cloudapp.azure.com:8081. V prohlížeči by se měl zobrazit nadpis „Hello World!“.

Vyčištění

Za spuštěný cluster se vám stále účtují poplatky, proto zvažte odstranění clusteru.

Po nahrání image do registru kontejneru můžete odstranit místní image z vývojového počítače:

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

Windows Operační systém kontejneru serveru a kompatibilita s hostitelským operačním systémem

Windows Kontejnery serveru nejsou kompatibilní napříč všemi verzemi hostitelského operačního systému. Příklad:

  • Windows kontejnery serverů sestavené pomocí Windows serveru verze 1709 nefungují na hostiteli, na kterém běží Windows server verze 2016.
  • Windows kontejnery serveru vytvořené pomocí Windows Server 2016 fungují v režimu izolace technologie Hyper-V jenom na hostiteli, na kterém běží Windows Server verze 1709.
  • díky Windows kontejnerů serveru vytvořených pomocí Windows Server 2016 může být nutné zajistit, aby revize operačního systému kontejneru a hostitelského operačního systému byly stejné při spuštění v režimu izolace procesu na hostiteli se systémem Windows Server 2016.

další informace najdete v tématu kompatibilita verzí kontejneru Windows.

při sestavování a nasazování kontejnerů do clusteru Service Fabric zvažte kompatibilitu s hostitelským operačním systémem a vaším kontejnerovým operačním systémem. Příklad:

  • Ujistěte se, že jste nasadili kontejnery s operačním systémem kompatibilním s operačním systémem na uzlech clusteru.
  • Zajistěte, aby byl režim izolace zadaný pro vaši aplikaci kontejneru konzistentní s podporou pro kontejnerový operační systém na uzlu, na kterém je nasazený.
  • Vezměte v úvahu, jak může mít upgrade operačního systému na uzly nebo kontejnery clusteru vliv na jejich kompatibilitu.

doporučujeme, abyste se ujistili, že se kontejnery na Service Fabricovém clusteru správně nasazují v následujících postupech:

  • pomocí explicitního označování imagí s imagemi docker určete verzi Windowsho operačního systému, ze které je kontejner sestaven.
  • používejte označení operačního systému v souboru manifestu aplikace, abyste se ujistili, že je vaše aplikace kompatibilní napříč různými verzemi a upgrady serveru Windows.

Poznámka

u Service Fabric verze 6,2 a novější můžete kontejnery na základě Windows Server 2016 místně nasadit na Windows 10 hostitele. v Windows 10 kontejnery běží v režimu izolace technologie Hyper-V bez ohledu na režim izolace nastavený v manifestu aplikace. Další informace najdete v tématu Konfigurace režimu izolace.

Zadání imagí kontejneru pro konkrétní sestavení operačního systému

Windows Kontejnery serveru nemusí být kompatibilní napříč různými verzemi operačního systému. například Windows kontejnery serveru sestavené pomocí Windows Server 2016 nefungují na Windows serveru verze 1709 v režimu izolace procesu. Proto pokud jsou uzly clusteru aktualizovány na nejnovější verzi, služba kontejneru vytvořená pomocí předchozích verzí operačního systému může selhat. chcete-li obejít tento postup s verzí 6,1 modulu runtime a novějším, Service Fabric podporuje určení více imagí operačního systému na kontejner a jejich označení s verzemi sestavení operačního systému v manifestu aplikace. verzi buildu operačního systému můžete získat spuštěním winver příkazu na příkazovém řádku Windows. Nejprve aktualizujte manifesty aplikací a zadejte přepsání image pro jednotlivé verze operačního systému a teprve potom aktualizujte operační systém na uzlech. Následující fragment kódu ukazuje, jak v manifestu aplikace ApplicationManifest.xml zadat několik imagí kontejneru:

      <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> 

verze buildu pro Windows Server 2016 je 14393 a verze buildu pro Windows Server verze 1709 je 16299. Manifest služby i nadále určuje jenom jednu image pro každou službu kontejneru, jak ukazuje následující kód:

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

Poznámka

Funkce označování verze sestavení operačního systému jsou dostupné jenom pro Service Fabric ve Windows.

Pokud základním operačním systémem virtuálního počítače je sestavení 16299 (verze 1709), Service Fabric vybere image kontejneru, která odpovídá této verzi Windows Serveru. Pokud manifest aplikace obsahuje kromě označených imagí kontejneru také neoznačenou image, Service Fabric bude předpokládat, že tato neoznačená image funguje napříč verzemi. Image kontejnerů označujte explicitně, abyste se vyhnuli problémům během upgradování.

Neoznačená image kontejneru bude fungovat jako přepsání image kontejneru uvedené v souboru ServiceManifest. Takže image myregistry.azurecr.io/samples/helloworldappDefault přepíše název image myregistry.azurecr.io/samples/helloworldapp v souboru ServiceManifest.

Kompletní příklad manifestů služby a aplikace Service Fabric

Tady jsou kompletní manifesty aplikace a služby použité v tomto článku.

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>

Konfigurace časového intervalu před vynuceným ukončením kontejneru

Můžete nakonfigurovat časový interval, který určuje, jak dlouho modul runtime počká před odebráním kontejneru po zahájení odstraňování služby (nebo jejího přesunu do jiného uzlu). Konfigurací časového intervalu se do kontejneru odešle příkaz docker stop <time in seconds>. Další podrobnosti najdete v dokumentaci k příkazu docker stop. Časový interval pro čekání se zadává v části Hosting. HostingOddíl lze přidat při vytváření clusteru nebo později v upgradu konfigurace. Následující fragment manifestu clusteru ukazuje nastavení intervalu čekání:

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

Výchozí časový interval je nastavený na 10 sekund. Vzhledem k tomu, že je tato konfigurace dynamická, časový limit aktualizuje v clusteru upgrade pouze konfigurace.

Konfigurace modulu runtime pro odebrání nepoužívaných imagí kontejneru

Cluster Service Fabric můžete nakonfigurovat tak, aby z uzlu odebral nepoužívané image kontejneru. Tato konfigurace umožňuje znovu získat místo na disku v případě, že je na uzlu příliš mnoho imagí kontejneru. Chcete-li povolit tuto funkci, aktualizujte část hostování v manifestu clusteru, jak je znázorněno v následujícím fragmentu kódu:

"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|..."
          }
          ...
          }
        ]
    } 
]

Image, které se nesmí odstranit, můžete zadat v rámci parametru ContainerImagesToSkip.

Konfigurace doby stahování image kontejneru

Modul runtime Service Fabric pro stažení a extrakci imagí kontejneru přidělí 20 minut. Pro většinu imagí kontejnerů to stačí. U větších imagí nebo při pomalém síťovém připojení může být potřeba prodloužit čas, po který se čeká, než dojde ke zrušení stahování a extrakce imagí. Tento časový limit se nastavuje pomocí atributu ContainerImageDownloadTimeout v části Hosting manifestu clusteru, jak ukazuje následující fragment kódu:

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

Nastavení zásad uchovávání informací kontejneru

Jako pomoc s diagnostikou selhání spuštění kontejneru Service Fabric (verze 6.1 nebo vyšší) podporuje zachování kontejnerů, které se ukončily nebo které se nepovedlo spustit. Tuto zásadu je možné nastavit v souboru ApplicationManifest.xml, jak ukazuje následující fragment kódu:

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

Nastavení ContainersRetentionCount určuje počet kontejnerů, které se při svém selhání zachovají. Pokud je zadaná hodnota záporná, zachovají se všechny kontejnery, které selhaly. Když atribut ContainersRetentionCount není zadaný, nezachovají se žádné kontejnery. Atribut ContainersRetentionCount také podporuje parametry aplikace, takže uživatelé mohou zadat různé hodnoty pro testovací a produkční clustery. Při použití této funkce použijte omezení umístění, aby služba kontejneru cílila na konkrétní uzel. Zabrání se tak přesunu služby kontejneru na jiné uzly. Všechny kontejnery zachované pomocí této funkce je nutné ručně odebrat.

Spuštění démona Dockeru s vlastními argumenty

V modulu runtime Service Fabric verze 6.2 a novější můžete spustit démona Dockeru s vlastními argumenty. Pokud zadáte vlastní argumenty, Service Fabric do modulu Dockeru nepředá žádné další argumenty s výjimkou argumentu --pidfile. Proto by se --pidfile nemělo předávat jako argument. Kromě toho by tento argument měl umožnit, aby démon Dockeru i nadále naslouchal kanálu s výchozím názvem ve Windows (nebo unixovému soketu domény v Linuxu), aby se zajistila komunikace Service Fabric s démonem. Vlastní argumenty se předávají v manifestu clusteru v části Hosting v rámci části ContainerServiceArguments, jak ukazuje následující fragment kódu:

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

Přepsat parametr

S 8,2 verzí modulu runtime ServiceFabric lze přepsat parametr entryPoint pro balíček kódu hostitele kontejnerů a exe . To lze použít v případech, kdy všechny prvky manifestu zůstávají stejné, ale image kontejneru musí být změněna, a poté zřízení jiné verze typu aplikace již není vyžadováno nebo je nutné předávat různé argumenty na základě scénáře testu nebo výroby a vstupní bod zůstává stejný.

Následuje příklad, jak přepsat vstupní bod kontejneru:

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>

Po zadání přepsání v manifestu aplikace se spustí kontejner s názvem Image myregistry.azurecr.io/samples/helloworldapp, Command commandsOverride, source sourceOverride a entryPoint entryPointOverride.

Podobně níže je uveden příklad, jak přepsat ExeHost:

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

Poznámka

Přepsání vstupního bodu není pro SetupEntryPoint podporováno.

Další kroky