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

• Windows
• Linux

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 jejím 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á vývojového prostředí Windows. Modul runtime clusteru Service Fabric a modul runtime Dockeru musí běžet ve stejném operačním systému. Kontejnery Windows nemůžete spouštět v clusteru s Linuxem.

Poznámka:

Při práci s Azure doporučujeme používat modul Azure Az PowerShellu. Začněte tím, že si projdete téma Instalace Azure PowerShellu. Informace o tom, jak migrovat na modul Az PowerShell, najdete v tématu Migrace Azure PowerShellu z AzureRM na Az.

Předpoklady

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

  • Visual Studio 2015 nebo Visual Studio 2019
  • Sada 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 s Windows se třemi nebo více uzly běžícími na Windows Serveru s kontejnery.

  V tomto článku musí verze (build) Windows Serveru s kontejnery spuštěnými na uzlech clusteru odpovídat verzi (buildu) Windows Serveru na vývojovém počítači. Důvodem je to, ž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 OS kontejneru Windows Serveru a kompatibilitě hostitelského operačního systému.

  Pokud chcete určit verzi Windows Serveru s kontejnery, které potřebujete pro váš cluster, spusťte ver příkaz z příkazového řádku Windows na vývojovém počítači. Před vytvořením clusteru si projděte kompatibilitu operačního systému kontejneru Windows Serveru a hostitelského operačního systému.

• 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 běžícího ve Windows 10 se podporuje. Informace o konfiguraci Windows 10 pro spouštění kontejnerů Windows najdete v tomto článku .

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 načítání veřejných imagí z Dockeru (jako python:2.7-windowsservercore v našem souboru Dockerfile) je osvědčeným postupem ověření u vašeho účtu Docker Hubu místo vytvoření anonymní žádosti o přijetí změn.

Poznámka:

Při provádění častých anonymních žádostíoch ERROR: toomanyrequests: Too Many Requests.You have reached your pull rate limit. Další informace najdete v tématu Správa veřejného obsahu ve službě Azure Container Registry .

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 prvek Network Nastavení-Networks> pro IP adresu:

docker inspect my-web-site

Připojte se ke spuštěnému kontejneru. Otevřete webový prohlížeč odkazující 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.

Spusťte docker login přihlášení k registru kontejneru pomocí přihlašovacích údajů registru.

Následující příklad předá ID a heslo instančního objektu Microsoft Entra. 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ý>Projekt.
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 deklarací dalších prvků koncového bodu 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ší portBindingy pro službu lze přidat deklarováním dalších elementů PortBinding s příslušnými hodnotami vlastností.

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

Informace o konfiguraci různých typů ověřování pro stahování imagí kontejneru najdete v tématu Ověřováníúložiště kontejnerů.

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í nastavení je režim izolace procesů na hostitelích s Windows Serverem. Na hostitelích s Windows 10 se podporuje pouze režim izolace Technologie Hyper-V, takže kontejner běží v režimu izolace Hyper-V bez ohledu na jeho 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Í.

Od nejnovější verze aktualizace verze 6.4 máte možnost určit, že vyhodnocení docker HEALTHCHECK by se měla hlásit jako chyba. Pokud je tato možnost povolená, zobrazí se zpráva o stavu OK, když je health_statusv pořádku a když health_status není v pořádku, zobrazí se chyba.

Pokyn HEALTHCHECK odkazující na aktuální kontrolu, která se provede pro monitorování stavu kontejneru, musí být uvedený v souboru Dockerfile použitém při generování image kontejneru.

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í IncludeDockerHealthStatusInSystemHealthReport je nastavena na hodnotu true, RestartContainerOnUnhealthStatus Je nastavena na false a TreatContainerUnhealthyStatusAsError je nastavena na 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 hodnotu true, zobrazí se zprávy o stavu CHYBY, 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 je v chybovém stavu, dokud se image nestáhnou na uzlech clusteru (což může nějakou dobu trvat v závislosti na velikosti image):

Aplikace je připravená, když je ve Ready stavu:

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

Kompatibilita operačního systému kontejneru Windows Serveru a hostitelského operačního systému

Kontejnery Windows Serveru nejsou kompatibilní ve všech verzích hostitelského operačního systému. Příklad:

• Kontejnery Windows Serveru vytvořené pomocí Windows Serveru verze 1709 nefungují na hostiteli s Windows Serverem verze 2016.
• Kontejnery Windows Serveru vytvořené pomocí Windows Serveru 2016 fungují v režimu izolace Hyper-V pouze na hostiteli s Windows Serverem verze 1709.
• S kontejnery Windows Serveru sestavenými pomocí Windows Serveru 2016 může být nutné zajistit, aby revize operačního systému kontejneru a hostitelského operačního systému byla stejná při spuštění v režimu izolace procesů na hostiteli s Windows Serverem 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 hostitelského operačního systému a operačního systému kontejneru. Příklad:

• Ujistěte se, že nasazujete kontejnery s operačním systémem kompatibilním s operačním systémem na uzlech clusteru.
• Ujistěte se, že režim izolace zadaný pro vaši aplikaci kontejneru je konzistentní s podporou operačního systému kontejneru na uzlu, na kterém se nasazuje.
• Zvažte, jak může upgrade operačního systému na uzly clusteru nebo kontejnery ovlivnit jejich kompatibilitu.

Doporučujeme následující postupy, abyste měli jistotu, že jsou kontejnery správně nasazené v clusteru Service Fabric:

• Pomocí explicitního označování imagí pomocí imagí Dockeru určete verzi operačního systému Windows Server, ze které je kontejner sestavený.
• Pomocí označování operačního systému v souboru manifestu aplikace se ujistěte, že je vaše aplikace kompatibilní napříč různými verzemi a upgrady Windows Serveru.

Poznámka:

S Service Fabric verze 6.2 a novějšími můžete nasazovat kontejnery založené na Windows Serveru 2016 místně na hostiteli s Windows 10. Ve Windows 10 běží kontejnery v režimu izolace 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

Kontejnery Windows Serveru nemusí být kompatibilní v různých verzích operačního systému. Například kontejnery Windows Serveru vytvořené pomocí Windows Serveru 2016 nefungují ve Windows Serveru verze 1709 v režimu izolace procesů. Proto pokud jsou uzly clusteru aktualizovány na nejnovější verzi, kontejnerové služby vytvořené pomocí starších verzí operačního systému nemusí selhat. Aby bylo možné tento postup obejít s modulem runtime verze 6.1 a novějším, Service Fabric podporuje zadávání více imagí operačního systému na kontejner a jejich označování pomocí verzí 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 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. Oddíl Hosting je možné 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. Pokud chcete tuto funkci povolit, 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řepsání vstupního bodu

S verzí 8.2 modulu Runtime ServiceFabric je možné přepsat vstupní bod pro balíček kódu kontejneru a exe. To se dá použít v případech, kdy všechny prvky manifestu zůstanou stejné, ale je potřeba změnit image kontejneru, pak už není potřeba zřídit jinou verzi typu aplikace nebo je potřeba předat různé argumenty na základě testovacího nebo prodového scénáře a vstupní bod zůstane stejný.

Následuje příklad přepsání vstupního bodu 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 kontejner s názvem image myregistry.azurecr.io/samples/helloworldapp, příkazy commandOverride, source sourceOverride a entryPoint EntryPointOverride se spustí.

Podobně níže je 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í podporováno pro SetupEntryPoint.

Další kroky

• Další informace o spouštění kontejnerů v Service Fabric.
• Přečtěte si kurz Nasazení aplikace .NET v kontejneru.
• Informace o životním cyklu aplikace Service Fabric.
• Prohlédněte si ukázky kódu kontejneru Service Fabric na GitHubu.