Skapa din första Service Fabric-containerapp i Windows
Du behöver inga göra några ändringar i din app för att köra en befintlig app i en Windows-container i ett Service Fabric-kluster. Den här artikeln beskriver hur du skapar en Docker-avbildning som innehåller ett Python Flask-webbprogram och distribuerar den till ett Azure Service Fabric-kluster. Du kan också dela programmet via Azure Container-registret. Den här artikeln förutsätter att du har grundläggande kunskaper om Docker. Mer information om Docker finns i Docker Overview (Översikt över Docker).
Kommentar
Den här artikeln gäller för en Windows-utvecklingsmiljö. Service Fabric-klusterkörningen och Docker-körningen måste köras på samma operativsystem. Du kan inte köra Windows-containrar på ett Linux-kluster.
Kommentar
Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Se Installera Azure PowerShell för att komma igång. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.
Förutsättningar
En utvecklingsdator som kör:
- Visual Studio 2015 eller Visual Studio 2019.
- Service Fabric SDK och verktyg.
- Docker för Windows. Hämta Docker CE för Windows (stabil). Efter installationen startar du Docker, högerklickar på ikonen för fack och väljer Switch to Windows containers (Växla till Windows-behållare). Detta steg krävs för att köra Docker-avbildningar baserade på Windows.
Ett Windows-kluster med tre eller fler noder som körs på Windows Server med containrar.
För den här artikeln måste versionen (versionen) av Windows Server med containrar som körs på klusternoderna matcha den på utvecklingsdatorn. Det beror på att du skapar docker-avbildningen på utvecklingsdatorn och det finns kompatibilitetsbegränsningar mellan versioner av containeroperativsystemet och värdoperativsystemet som det distribueras på. Mer information finns i Windows Server-container-OS och kompatibilitet för värdoperativsystem.
För att fastställa vilken version av Windows Server med containrar du behöver för klustret kör
verdu kommandot från en Windows-kommandotolk på utvecklingsdatorn. Se kompatibiliteten för Windows Server-containern och värdoperativsystemet innan du skapar ett kluster.Ett register i Azure Container Registry – Skapa ett behållarregister i din Azure-prenumeration.
Kommentar
Det finns stöd för att distribuera containrar till ett Service Fabric-kluster som körs på Windows 10. I den här artikeln finns information om hur du konfigurerar Windows 10 för att köra Windows-containrar.
Kommentar
Service Fabric version 6.2 och senare stöder distribution av containrar till kluster som körs på Windows Server version 1709.
Definiera Dockercontainer
Skapa en avbildning baserat på Python-avbildningen på Docker Hub.
Ange Docker-containern i en Dockerfile. Dockerfile innehåller instruktioner för att konfigurera miljön i din container, läsa in programmet du vill köra och mappa portar. Dockerfile är indata för kommandot docker build som skapar avbildningen.
Skapa en tom katalog och skapa filen Dockerfile (utan filtillägget). Lägg till följande i Dockerfile och spara dina ändringar:
# 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"]
Läs Dockerfile-referensen för mer information.
Skapa en grundläggande webbapp
Skapa en Flask-webbapplikation som lyssnar på port 80 och returnerar Hello World!. Skapa filen requirements.txt i samma katalog. Lägg till följande och spara dina ändringar:
Flask
Skapa även filen app.py och lägg till följande kodavsnitt:
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)
Logga in på Docker och skapa avbildningen
Nu ska vi skapa avbildningen som kör webbprogrammet. När du hämtar offentliga avbildningar från Docker (som python:2.7-windowsservercore i vår Dockerfile) är det bästa praxis att autentisera med ditt Docker Hub-konto i stället för att göra en anonym pull-begäran.
Kommentar
När du gör frekventa anonyma pull-begäranden kan du se Docker-fel som liknar ERROR: toomanyrequests: Too Many Requests. eller You have reached your pull rate limit. autentisera till Docker Hub för att förhindra dessa fel. Mer information finns i Hantera offentligt innehåll med Azure Container Registry .
Öppna ett PowerShell-fönster och navigera till den katalog som innehåller din Dockerfile. Kör sedan följande kommandon:
docker login
docker build -t helloworldapp .
Med det här kommandot skapas den nya avbildningen med hjälp av instruktionerna i din Dockerfile och avbildningen får namnet helloworldapp. Om du vill skapa en containeravbildning börjar du med att ladda ned basavbildningen från den Docker-hubb som programmet ska läggas till i.
När build-kommandot har slutförts kör du docker images-kommandot för att se information om den nya avbildningen:
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
helloworldapp latest 8ce25f5d6a79 2 minutes ago 10.4 GB
Köra appen lokalt
Kontrollera avbildningen lokalt innan du överför den till containerregistret.
Kör programmet:
docker run -d --name my-web-site helloworldapp
name namnger den container som körs (i stället för container-ID:t).
När containern har startat letar du reda på dess IP-adress så att du kan ansluta till den container som körs via en webbläsare:
docker inspect -f "{{ .NetworkSettings.Networks.nat.IPAddress }}" my-web-site
Om kommandot inte returnerar något kör du följande kommando och kontrollerar elementet Network Inställningar-Networks> för IP-adressen:
docker inspect my-web-site
Anslut till den container som körs. Öppna en webbläsare som pekar på ip-adressen som returneras, till exempel "http://172.31.194.61". Du bör se rubriken "Hello World!" i webbläsaren.
Om du vill stoppa containern kör du:
docker stop my-web-site
Ta bort containern från utvecklingsdatorn:
docker rm my-web-site
Överför avbildningen till containerregistret
När du har kontrollerat att behållaren körs på utvecklingsdatorn överför du avbildningen till registret i Azure Container Registry.
Kör docker login för att logga in på containerregistret med dina registerautentiseringsuppgifter.
I följande exempel skickas ID och lösenord för ett Microsoft Entra-tjänstens huvudnamn. Du kanske till exempel har tilldelat ett tjänstobjekt till registret för ett automatiseringsscenario. Eller så kan du logga in med ditt registeranvändarnamn och lösenord.
docker login myregistry.azurecr.io -u xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -p myPassword
Följande kommando skapar en tagg, eller ett alias, för avbildningen, med en fullständigt kvalificerad sökväg till registret. I det här exemplet placeras avbildningen i samples-namnområdet för att undvika oreda i registrets rot.
docker tag helloworldapp myregistry.azurecr.io/samples/helloworldapp
Överför avbildningen till containerregistret:
docker push myregistry.azurecr.io/samples/helloworldapp
Skapa containertjänsten i Visual Studio
SDK:en och verktygen för Service Fabric innehåller en tjänstmall som hjälper dig att skapa ett containerprogram.
- Starta Visual Studio. Välj Arkiv>Nytt>Projekt.
- Välj Service Fabric-programmet, ge det namnet "MyFirstContainer" och klicka på OK.
- Välj Container i listan med tjänstmallar.
- I Avbildningsnamn skriver du "myregistry.azurecr.io/samples/helloworldapp" (den avbildning som du skickade till lagringsplatsen för containern).
- Namnge tjänsten och klicka på OK.
Konfigurera kommunikation
Containertjänsten behöver en slutpunkt för kommunikation. Lägg till ett Endpoint-element med protokollet, porten och typen i filen ServiceManifest.xml. I det här exemplet används en fast port, 8081. Om ingen port har angetts väljs en port slumpmässigt från portintervallet för programmet.
<Resources>
<Endpoints>
<Endpoint Name="Guest1TypeEndpoint" UriScheme="http" Port="8081" Protocol="http"/>
</Endpoints>
</Resources>
Kommentar
Ytterligare slutpunkter för en tjänst kan läggas till genom att deklarera ytterligare EndPoint-element med tillämpliga egenskapsvärden. Varje port kan bara deklarera ett protokollvärde.
Genom att definiera en slutpunkt publicerar Service Fabric slutpunkten i namngivningstjänsten. Andra tjänster som körs i klustret kan lösa den här containern. Du kan också utföra kommunikation mellan containrar med hjälp av den omvända proxyn. Du utför kommunikation genom att tillhandahålla HTTP-lyssningsporten för den omvända proxyn och namnet på de tjänster som du vill kommunicera med som miljövariabler.
Tjänsten lyssnar på en specifik port (8081 i det här exemplet). När programmet distribueras till ett kluster i Azure, körs både klustret och programmet bakom en Azure-lastbalanserare. Programporten måste vara öppen i Azure-lastbalanseraren så att inkommande trafik kan nå tjänsten. Du kan öppna den här porten i Azures lastbalanserare med hjälp av ett PowerShell-skript eller på Azure Portal.
Konfigurera och ange miljövariabler
Miljövariabler kan anges för varje kodpaketet i tjänstmanifestet. Den här funktionen är tillgänglig för alla tjänster oavsett om de har distribueras som containrar eller processer, eller körbara gäster. Du kan åsidosätta värden för miljövariabler i applikationsmanifestet eller ange dem under distributionen som programparametrar.
Följande XML-kodfragment i tjänstmanifestet visar ett exempel på hur du anger miljövariabler för ett kodpaket:
<CodePackage Name="Code" Version="1.0.0">
...
<EnvironmentVariables>
<EnvironmentVariable Name="HttpGatewayPort" Value=""/>
</EnvironmentVariables>
</CodePackage>
Dessa miljövariabler kan åsidosättas i applikationsmanifestet:
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="Guest1Pkg" ServiceManifestVersion="1.0.0" />
<EnvironmentOverrides CodePackageRef="FrontendService.Code">
<EnvironmentVariable Name="HttpGatewayPort" Value="19080"/>
</EnvironmentOverrides>
...
</ServiceManifestImport>
Konfigurera mappning mellan containerport och värdport och identifiering mellan containrar
Konfigurera en värdport som används för att kommunicera med containern. Portbindningen mappar porten där tjänsten lyssnar inuti containern till en port på värden. Lägg till ett PortBinding-element i ContainerHostPolicies-elementet i filen ApplicationManifest.xml. I den här artikeln är ContainerPort 80 (containern exponerar port 80, som anges i Dockerfile) och EndpointRef är ”Guest1TypeEndpoint” (slutpunkten som tidigare definierats i tjänstmanifestet). Inkommande begäranden till tjänsten på port 8081 mappas till port 80 på containern.
<ServiceManifestImport>
...
<Policies>
<ContainerHostPolicies CodePackageRef="Code">
<PortBinding ContainerPort="80" EndpointRef="Guest1TypeEndpoint"/>
</ContainerHostPolicies>
</Policies>
...
</ServiceManifestImport>
Kommentar
Ytterligare PortBindings för en tjänst kan läggas till genom att deklarera ytterligare PortBinding-element med tillämpliga egenskapsvärden.
Konfigurera autentisering av containerlagringsplats
Se Autentiseringav containerlagringsplats för att lära dig hur du konfigurerar olika typer av autentisering för nedladdning av containeravbildningar.
Konfigurera isoleringsläge
Windows stöder två isoleringslägen för containrar: process och Hyper-V. Om processisoleringsläget används delar alla containrar som körs på samma värddator kärna med värden. Om Hyper-V-isoleringsläget används isoleras kärnorna mellan varje Hyper-V-container och containervärden. Isoleringsläget anges i ContainerHostPolicies-elementet i applikationsmanifestfilen. Isoleringslägena som kan anges är process, hyperv och default. Standardinställningen är läget för processisolering på Windows Server-värdar. På Windows 10-värdar stöds endast Hyper-V-isoleringsläge, så containern körs i Hyper-V-isoleringsläge oavsett inställning för isoleringsläge. Följande kodfragment visar hur isoleringsläget har angetts i applikationsmanifestfilen.
<ContainerHostPolicies CodePackageRef="Code" Isolation="hyperv">
Kommentar
Hyper-V-isoleringsläget är tillgängligt på Ev3 och Dv3 Azure SKU:er som har stöd för kapslad virtualisering.
Konfigurera resursstyrning
Med resursstyrning begränsas resurserna som containern kan använda på värddatorn. ResourceGovernancePolicy-elementet som anges i applikationsmanifestet, används för att deklarera resursgränser för ett tjänstkodpaket. Resursgränser kan anges för följande resurser: Memory, MemorySwap, CpuShares (relativ processorvikt), MemoryReservationInMB, BlkioWeight (relativ BlockIO-vikt). I det här exemplet hämtar tjänstpaketet Guest1Pkg en kärna på klusternoderna där det är placerat. Minnesgränser är absoluta, så kodpaketet är begränsat till 1024 MB minne (med samma reservation). Kodpaket (containrar eller processer) kan inte tilldela mer minne än den här gränsen, och försök att göra detta leder till undantag utanför minnet. För att tvingande resursbegränsning ska fungera bör minnesbegränsningar ha angetts för alla kodpaket inom ett tjänstpaket.
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="Guest1Pkg" ServiceManifestVersion="1.0.0" />
<Policies>
<ServicePackageResourceGovernancePolicy CpuCores="1"/>
<ResourceGovernancePolicy CodePackageRef="Code" MemoryInMB="1024" />
</Policies>
</ServiceManifestImport>
Konfigurera Docker HEALTHCHECK
Från och med v6.1 integrerar Service Fabric händelser för Docker HEALTHCHECK automatiskt i systemets hälsorapport. Det innebär att om containern har HEALTHCHECK aktiverad kommer Service Fabric att rapportera hälsa varje gång containerns hälsostatus förändras enligt rapporten från Docker. En hälsorapport som är OK visas i Service Fabric Explorer när health_status är healthy och WARNING visas när health_status är unhealthy.
Från och med den senaste uppdateringsversionen av v6.4 har du möjlighet att ange att Docker HEALTHCHECK-utvärderingar ska rapporteras som ett fel. Om det här alternativet är aktiverat visas en OK-hälsorapport när health_status är felfri och FEL visas när health_status inte är felfri.
Instruktionen för HEALTHCHECK som pekar mot den faktiska kontroll som utförs för att övervaka containerns hälsa måste finnas i den Dockerfile som används när containeravbildningen skapas.
Du kan konfigurera HEALTHCHECK-beteendet för varje behållare genom att ange alternativen för HealthConfig som en del av ContainerHostPolicies i ApplicationManifest.
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="ContainerServicePkg" ServiceManifestVersion="2.0.0" />
<Policies>
<ContainerHostPolicies CodePackageRef="Code">
<HealthConfig IncludeDockerHealthStatusInSystemHealthReport="true"
RestartContainerOnUnhealthyDockerHealthStatus="false"
TreatContainerUnhealthyStatusAsError="false" />
</ContainerHostPolicies>
</Policies>
</ServiceManifestImport>
Som standard är IncludeDockerHealthStatusInSystemHealthReport inställt på sant, RestartContainerOnUnhealthyDockerHealthStatus är inställt på false och TreatContainerUnhealthyStatusAsError är inställt på false.
Om RestartContainerOnUnhealthyDockerHealthStatus är inställt på true kommer en behållare som upprepade gånger rapporteras som ej felfri att startas om (eventuellt på andra noder).
Om TreatContainerUnhealthyStatusAsError är inställt på true visas felhälsorapporter när containerns health_status inte är felfri.
Om du vill inaktivera integrering av HEALTHCHECK för hela Service Fabric-klustret måste du ställa in EnableDockerHealthCheckIntegration på false.
Distribuera containerappen
Spara alla dina ändringar och skapa programmet. Om du vill publicera appen högerklickar du på MyFirstContainer i Solution Explorer och väljer Publish (Publicera).
I anslutningsslutpunkten anger du hanteringsslutpunkten för klustret. Till exempel containercluster.westus2.cloudapp.azure.com:19000. Slutpunkten för klientanslutningen finns på översiktsfliken för ditt kluster i Azure Portal.
Klicka på Publicera.
Service Fabric Explorer är ett webbaserat verktyg för att granska och hantera appar och noder i ett Service Fabric-kluster. Öppna en webbläsare och gå till http://containercluster.westus2.cloudapp.azure.com:19080/Explorer/ och följ appdistributionen. Programmet distribueras men är i ett feltillstånd tills avbildningen laddas ned på klusternoderna (vilket kan ta lite tid, beroende på bildstorleken): 
Programmet är klart när det är i Ready tillstånd: 
Öppna en webbläsare och navigera till http://containercluster.westus2.cloudapp.azure.com:8081. Du bör se rubriken "Hello World!" i webbläsaren.
Rensa
Det kostar pengar så länge klustret körs. Fundera på om du vill ta bort klustret.
När du har överfört avbildningen till containerregistret kan du ta bort den lokala avbildningen från utvecklingsdatorn:
docker rmi helloworldapp
docker rmi myregistry.azurecr.io/samples/helloworldapp
Kompatibilitet för Windows Server-containeroperativsystem och värdoperativsystem
Windows Server-containrar är inte kompatibla i alla versioner av ett värdoperativsystem. Till exempel:
- Windows Server-containrar som skapats med Windows Server version 1709 fungerar inte på en värd som kör Windows Server version 2016.
- Windows Server-containrar som skapats med Windows Server 2016 fungerar endast i Hyper-V-isoleringsläge på en värd som kör Windows Server version 1709.
- Med Windows Server-containrar som skapats med Windows Server 2016 kan det vara nödvändigt att se till att revisionen av containeroperativsystemet och värdoperativsystemet är desamma när du kör i processisoleringsläge på en värd som kör Windows Server 2016.
Mer information finns i Windows Container Version Compatibility (Windows Container Version Compatibility).
Överväg kompatibiliteten för värdoperativsystemet och ditt containeroperativsystem när du skapar och distribuerar containrar till Service Fabric-klustret. Till exempel:
- Se till att du distribuerar containrar med ett operativsystem som är kompatibelt med operativsystemet på klusternoderna.
- Kontrollera att det isoleringsläge som angetts för ditt containerprogram är konsekvent med stöd för containeroperativsystemet på noden där det distribueras.
- Fundera på hur operativsystemuppgraderingar till klusternoder eller containrar kan påverka deras kompatibilitet.
Vi rekommenderar följande metoder för att se till att containrar distribueras korrekt i Service Fabric-klustret:
- Använd explicit bildtaggning med dina Docker-avbildningar för att ange vilken version av Windows Server OS som en container har skapats från.
- Använd OS-taggning i programmanifestfilen för att se till att programmet är kompatibelt mellan olika Windows Server-versioner och -uppgraderingar.
Kommentar
Med Service Fabric version 6.2 och senare kan du distribuera containrar baserat på Windows Server 2016 lokalt på en Windows 10-värd. I Windows 10 körs containrar i Hyper-V-isoleringsläge, oavsett vilket isoleringsläge som anges i programmanifestet. Mer information finns i Konfigurera isoleringsläge.
Ange specifika containeravbildningar för operativsystemet
Windows Server-containrar kanske inte är kompatibla i olika versioner av operativsystemet. Windows Server-containrar som skapats med Windows Server 2016 fungerar till exempel inte på Windows Server version 1709 i processisoleringsläge. Om klusternoderna därför uppdateras till den senaste versionen kan containertjänster som skapats med de tidigare versionerna av operativsystemet misslyckas. För att kringgå detta med version 6.1 av körningen och senare stöder Service Fabric att ange flera OS-avbildningar per container och tagga dem med versionsversionerna av operativsystemet i programmanifestet. Du kan hämta versionsversionen av operativsystemet genom att köra winver i en Windows-kommandotolk. Uppdatera applikationsmanifesten och ange åsidosättningar av avbildning per operativsystemsversion innan du uppdaterar operativsystemet på noderna. Följande kodavsnitt visar hur du kan ange flera containeravbildningar i applikationsmanifestet, 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>
Versionsversionen för Windows Server 2016 är 14393 och versionsversionen för Windows Server version 1709 är 16299. Tjänstmanifestet fortsätter att ange endast en avbildning per containertjänst, vilket följande visar:
<ContainerHost>
<ImageName>myregistry.azurecr.io/samples/helloworldapp</ImageName>
</ContainerHost>
Kommentar
Taggningsfunktioner för operativsystemsversionen är endast tillgängliga för Service Fabric på Windows
Om det underliggande operativsystemet på den virtuella datorn är version 16299 (version 1709) väljer Service Fabric den containeravbildning som motsvarar den Windows Server-versionen. Om en ej taggad containeravbildning också anges tillsammans med taggade containeravbildningar i applikationsmanifestet kommer Service Fabric att hantera den ej taggade avbildningen som en avbildning som fungerar för olika versioner. Tagga containeravbildningen explicit för att undvika problem under uppgraderingar.
Containeravbildningen utan taggar kommer att fungera som en åsidosättning av den som anges i ServiceManifest. Det innebär att avbildningen ”myregistry.azurecr.io/samples/helloworldappDefault” åsidosätter avbildningen ”myregistry.azurecr.io/samples/helloworldapp” i ServiceManifest.
Komplett exempel på Service Fabric-app och tjänstmanifest
Här är de fullständiga tjänst- och appmanifesten som används i den här artikeln.
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>
Ställ in tidsintervall innan containern tvångsavslutas
Du kan ställa in ett tidsintervall för hur lång exekveringstid som ska gå innan containern tas bort när borttagning av tjänsten (eller flytt till en annan nod) har påbörjats. När du ställer in ett tidsintervall skickas kommandot docker stop <time in seconds> till containern. Mer information finns i docker stop. Tidsintervallet anges i avsnittet Hosting. Avsnittet Hosting kan läggas till när klustret skapas eller senare i en konfigurationsuppgradering. I följande klustermanifestutdrag visas hur du ställer in väntetidsintervallet:
"fabricSettings": [
...,
{
"name": "Hosting",
"parameters": [
{
"name": "ContainerDeactivationTimeout",
"value" : "10"
},
...
]
}
]
Standardtidsintervallet är inställt på 10 sekunder. Eftersom inställningen är dynamisk uppdateras tidsgränsen med en konfigurationsuppdatering på klustret.
Ställ in exekveringstid för att ta bort containeravbildningar som inte används
Du kan ställa in Service Fabric-klustret på att ta bort oanvända containeravbildningar från noden. Med den här inställningen kan du få tillbaka diskutrymme om det finns för många containeravbildningar på noden. Om du vill aktivera den här funktionen uppdaterar du avsnittet Värd i klustermanifestet enligt följande kodfragment:
"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|..."
}
...
}
]
}
]
Avbildningar som inte ska raderas kan du ange under parametern ContainerImagesToSkip.
Konfigurera nedladdningstid för containeravbildning
Service Fabric-körningen tilldelar 20 minuter för att ladda ned och extrahera containeravbildningar, vilket fungerar för de flesta containeravbildningar. För stora avbildningar, eller om nätverksanslutningen är långsam, kan det vara nödvändigt att öka den tid körningen väntar innan nedladdning och extrahering av avbildningen avbryts. Den här timeouten anges med attributet ContainerImageDownloadTimeout i avsnittet Hosting i klustermanifestet, på det sätt som visas i följande kodavsnitt:
"fabricSettings": [
...,
{
"name": "Hosting",
"parameters": [
{
"name": "ContainerImageDownloadTimeout",
"value": "1200"
}
]
}
]
Ange bevarandeprincip för container
Service Fabric (version 6.1 eller senare) har stöd för bevarande av containrar som har avslutats eller inte kunde starta, vilket underlättar diagnostisering av startfel. Den här principen kan anges i filen ApplicationManifest.xml, vilket visas i följande kodavsnitt:
<ContainerHostPolicies CodePackageRef="NodeService.Code" Isolation="process" ContainersRetentionCount="2" RunInteractive="true">
Inställningen ContainersRetentionCount anger antalet behållare som ska bevaras när de får fel. Om ett negativt värde anges kommer alla containrar med fel att bevaras. Om attributet ContainersRetentionCount inte anges kommer inga behållare att bevaras. Attributet ContainersRetentionCount har även stöd för programparametrar, så att användarna kan ange olika värden för test- och produktionskluster. Använd placeringsbegränsningar för att rikta in containertjänsten på en viss nod när den här funktionen används för att förhindra att containertjänsten flyttas till andra noder. Alla containrar som bevaras med den här funktionen måste tas bort manuellt.
Starta Docker-daemon med anpassade argument
Du kan starta Docker-daemon med anpassade argument med version 6.2 eller högre av Service Fabric runtime. Om du inte anger anpassade argument, skickar inte Service Fabric några andra argument till docker-motorn, förutom argumentet --pidfile. Därför får inte --pidfile skickas som ett argument. Dessutom ska argumentet fortsätta att få docker-daemonen att lyssna på pipen med standardnamnet på Windows (eller unix-domänsocket på Linux) för att Service Fabric ska kunna kommunicera med daemon. De anpassade argumenten skickas i klustermanifestet under värdavsnittet i ContainerServiceArguments enligt följande kodavsnitt:
"fabricSettings": [
...,
{
"name": "Hosting",
"parameters": [
{
"name": "ContainerServiceArguments",
"value": "-H localhost:1234 -H unix:///var/run/docker.sock"
}
]
}
]
Åsidosättning av EntryPoint
Med 8.2-versionen av ServiceFabric Runtime kan startpunkten för container - och exe-värdkodpaketet åsidosättas. Detta kan användas i fall där alla manifestelement förblir desamma men containeravbildningen måste ändras, sedan krävs det inte längre att etablera en annan apptypversion, eller att olika argument måste skickas baserat på test- eller prod-scenariot och startpunkten förblir densamma.
Följande är ett exempel på hur du åsidosätter containerinmatningspunkten:
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>
När åsidosättningarna i programmanifestet har angetts startas containern med avbildningsnamnet myregistry.azurecr.io/samples/helloworldapp, kommandokommandonaOverride, källkällanOverride och entryPoint entryPointOverride.
På samma sätt är nedan ett exempel på hur du åsidosätter ExeHost:
<?xml version="1.0" encoding="utf-8"?>
<Policies>
<CodePackagePolicy CodePackageRef="Code">
<EntryPointOverride>
<ExeHostOverride>
<Program>[Program]</Program>
<Arguments>[Entry]</Arguments>
</ExeHostOverride>
</EntryPointOverride>
</CodePackagePolicy>
</Policies>
Kommentar
Åsidosättning av startpunkt stöds inte för SetupEntryPoint.
Nästa steg
- Mer information om hur du kör containrar i Service Fabric.
- Läs kursen Distribuera ett .NET-program i en container.
- Läs om Service Fabric-applivscykeln.
- Se kodexempel för Service Fabric-container på GitHub.