Uw eerste Service Fabric-containertoepassing maken in Windows
Er zijn geen wijzigingen in uw toepassing vereist om een bestaande toepassing in een Windows-container uit te voeren in een Service Fabric-cluster. Dit artikel helpt u bij het maken van een Docker-installatiekopie met een Python Flask-webtoepassing en het implementeren ervan in een Azure Service Fabric-cluster. U gaat uw containertoepassing ook delen via Azure Container Registry. In dit artikel wordt ervan uitgegaan dat u de basisbeginselen kent van Docker. Meer informatie over Docker kunt u lezen in het Docker-overzicht.
Notitie
Dit artikel is van toepassing op een Windows-ontwikkelomgeving. De Service Fabric-clusterruntime en de Docker-runtime moeten worden uitgevoerd op hetzelfde besturingssysteem. U kunt Geen Windows-containers uitvoeren op een Linux-cluster.
Notitie
Het wordt aanbevolen de Azure Az PowerShell-module te gebruiken om te communiceren met Azure. Zie Azure PowerShell installeren om aan de slag te gaan. Raadpleeg Azure PowerShell migreren van AzureRM naar Az om te leren hoe u naar de Azure PowerShell-module migreert.
Vereisten
Een ontwikkelcomputer waarop wordt uitgevoerd:
- Visual Studio 2015 of Visual Studio 2019.
- Service Fabric SDK en hulpprogramma's.
- Docker voor Windows. Download Docker CE voor Windows (stabiel). Nadat u Docker hebt geïnstalleerd en gestart, klikt u met de rechtermuisknop op het systeemvakpictogram en selecteert u Overschakelen naar Windows-containers. Deze stap is vereist voor het uitvoeren van Docker-installatiekopieën onder Windows.
Een Windows-cluster met drie of meer knooppunten die worden uitgevoerd op Windows Server met containers.
Voor dit artikel moet de versie (build) van Windows Server met containers die op uw clusterknooppunten worden uitgevoerd, overeenkomen met die op uw ontwikkelcomputer. Dit komt doordat u de Docker-installatiekopie op uw ontwikkelcomputer bouwt en er compatibiliteitsbeperkingen zijn tussen versies van het container-besturingssysteem en het host-besturingssysteem waarop deze is geïmplementeerd. Zie windows Server-container os en host os compatibiliteit voor meer informatie.
Als u de versie van Windows Server met containers wilt bepalen die u nodig hebt voor uw cluster, voert u de
veropdracht uit vanaf een Windows-opdrachtprompt op uw ontwikkelcomputer. Raadpleeg windows Server-containerbesturingssystemen en hostbesturingssystemencompatibiliteit voordat u een cluster maakt.Een register in Azure Container Registry - Een containerregister maken in uw Azure-abonnement.
Notitie
Het implementeren van containers in een Service Fabric-cluster dat wordt uitgevoerd in Windows 10, wordt ondersteund. Zie dit artikel voor informatie over het configureren van Windows 10 voor het uitvoeren van Windows-containers.
Notitie
Service Fabric-versies 6.2 en hoger ondersteunen het implementeren van containers naar clusters met Windows Server versie 1709.
De Docker-container definiëren
Bouw een installatiekopie op basis van de Python-installatiekopie die zich in de Docker-hub bevindt.
Geef uw Docker-container in een Dockerfile op. Het bestand Dockerfile bestaat uit instructies voor het instellen van de omgeving in de container, het laden van de toepassing die u wilt uitvoeren en het toewijzen van poorten. Het Dockerfile is de invoer van de opdracht docker build waarmee de installatiekopie wordt gemaakt.
Maak een lege map en maak het bestand Dockerfile (zonder extensie). Voeg het volgende toe aan het bestand Dockerfile en sla de wijzigingen op:
# 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"]
Lees het Dockerfile-referentiemateriaal voor meer informatie.
Een algemene webtoepassing maken
Maak een Flask-webtoepassing die luistert op poort 80 en Hello World! retourneert. Maak in dezelfde map het bestand requirements.txt. Voeg het volgende toe en sla de wijzigingen op:
Flask
Maak ook het bestand app.py en voeg het volgende codefragment toe:
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)
Meld u aan bij Docker en bouw de installatiekopieën
Vervolgens maken we de installatiekopieën waarmee uw webtoepassing wordt uitgevoerd. Bij het ophalen van openbare installatiekopieën uit Docker (zoals python:2.7-windowsservercore in onze Dockerfile), is het een best practice om te verifiëren met uw Docker Hub-account in plaats van een anonieme pull-aanvraag te doen.
Notitie
Wanneer u frequente anonieme pull-aanvragen maakt, ziet u mogelijk Docker-fouten die vergelijkbaar zijn met ERROR: toomanyrequests: Too Many Requests. of You have reached your pull rate limit. verifiëren bij Docker Hub om deze fouten te voorkomen. Zie Openbare inhoud beheren met Azure Container Registry voor meer informatie.
Open een PowerShell-venster en navigeer naar de map met het bestand Dockerfile. Voer vervolgens de volgende opdrachten uit:
docker login
docker build -t helloworldapp .
Met deze opdracht wordt de nieuwe installatiekopie gebouwd met behulp van de instructies in het Dockerfile, en krijgt de installatiekopie de naam (-t tagging) helloworldapp. Voor het bouwen van een containerinstallatiekopie, wordt eerst de basisinstallatiekopie gedownload vanaf Docker Hub, waaraan de toepassing wordt toegevoegd.
Nadat de buildopdracht is voltooid, voert u de opdracht docker images uit om de gegevens van de nieuwe installatiekopie te bekijken:
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
helloworldapp latest 8ce25f5d6a79 2 minutes ago 10.4 GB
De toepassing lokaal uitvoeren
Controleer de installatiekopie eerst lokaal voordat u deze naar het containerregister pusht.
Voer de toepassing uit:
docker run -d --name my-web-site helloworldapp
Bij naam kunt de actieve container een naam geven (in plaats van de container-id).
Zodra de container is gestart, zoekt u het bijbehorende IP-adres zodat u vanuit een browser verbinding kunt maken met de actieve container:
docker inspect -f "{{ .NetworkSettings.Networks.nat.IPAddress }}" my-web-site
Als deze opdracht niets retourneert, voert u de volgende opdracht uit en inspecteert u het element Network Instellingen-Networks voor het IP-adres>:
docker inspect my-web-site
Maak verbinding met de actieve container. Open een webbrowser die verwijst naar het GERETOURNEERDe IP-adres, bijvoorbeeld 'http://172.31.194.61". U ziet nu de kop 'Hallo wereld!' in de browser.
Als u de container wilt stoppen, voert u dit uit:
docker stop my-web-site
De container verwijderen van de ontwikkelcomputer:
docker rm my-web-site
De installatiekopie naar het containerregister pushen
Nadat u hebt gecontroleerd of de container actief is op de ontwikkelcomputer, pusht u de installatiekopie naar het register in Azure Container Registry.
Voer docker login deze opdracht uit om u aan te melden bij uw containerregister met uw registerreferenties.
In het volgende voorbeeld wordt de id en het wachtwoord van een Microsoft Entra-service-principal doorgegeven. U hebt bijvoorbeeld een service-principal aan uw register toegewezen voor een automatiseringsscenario. U kunt zich ook aanmelden met uw gebruikersnaam en wachtwoord voor het register.
docker login myregistry.azurecr.io -u xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -p myPassword
Met de volgende opdracht maakt u een tag (of alias) van de installatiekopie met een volledig gekwalificeerd pad naar uw register. In dit voorbeeld wordt de installatiekopie in de naamruimte samples geplaatst om overbodige items in de hoofdmap van het register te voorkomen.
docker tag helloworldapp myregistry.azurecr.io/samples/helloworldapp
De installatiekopie naar het containerregister pushen:
docker push myregistry.azurecr.io/samples/helloworldapp
De beperkte service maken in Visual Studio
De Service Fabric SDK en hulpprogramma's bieden een servicesjabloon waarmee u een containertoepassing kunt maken.
- Start Visual Studio. Selecteer Bestand>Nieuw>Project.
- Selecteer Service Fabric-toepassing, geef deze de naam MyFirstContainer en klik op OK.
- Selecteer Container in de lijst met servicesjablonen.
- Voer bij Naam van installatiekopie het volgende in: myregistry.azurecr.io/samples/helloworldapp. Dit is de installatiekopie die u naar uw containeropslagplaats hebt gepusht.
- Geef de service een naam en klik op OK.
Communicatie configureren
De containerservice heeft een eindpunt voor communicatie nodig. Voeg een Endpoint-element met het protocol, de poort en het type toe aan het bestand ServiceManifest.xml. In dit voorbeeld wordt een ingestelde poort 8081 gebruikt. Als er geen poort is opgegeven, wordt een willekeurige poort uit het poortbereik van de toepassing gekozen.
<Resources>
<Endpoints>
<Endpoint Name="Guest1TypeEndpoint" UriScheme="http" Port="8081" Protocol="http"/>
</Endpoints>
</Resources>
Notitie
Aanvullende eindpunten voor een service kunnen worden toegevoegd door extra EndPoint-elementen met toepasselijke eigenschapswaarden te declareren. Elke poort kan slechts één protocolwaarde declareren.
Als u een eindpunt opgeeft, publiceert Service Fabric het eindpunt naar de Naming-service. Andere services die in dit cluster worden uitgevoerd, kunnen deze container dan omzetten. U kunt ook communicatie van container naar container laten plaatsvinden met behulp van een omgekeerde proxy. Communicatie wordt uitgevoerd door de omgekeerde proxy de HTTP-poort voor luisteren en de naam van de services waarmee u wilt communiceren door te geven als omgevingsvariabelen.
De service luistert op een specifieke poort (8081 in dit voorbeeld). Wanneer de toepassing in een cluster in Azure wordt geïmplementeerd, worden zowel het cluster als de toepassing achter een load balancer van Azure uitgevoerd. De poort van de toepassing moet open zijn in de load balancer van Azure zodat binnenkomend verkeer de service kan bereiken. U kunt deze poort openen in de load balancer van Azure met een PowerShell-script of in Azure Portal.
Omgevingsvariabelen configureren en instellen
Er kunnen omgevingsvariabelen worden opgegeven voor ieder codepakket in het servicemanifest. Deze functie is beschikbaar voor alle services, ongeacht of ze zijn geïmplementeerd als containers, processen of uitvoerbare gastbestanden. U kunt waarden van omgevingsvariabelen overschrijven in het toepassingsmanifest of ze opgeven als toepassingsparameters tijdens de implementatie.
Het volgende XML-fragment voor het servicemanifest toont een voorbeeld van het opgeven van omgevingsvariabelen voor een codepakket:
<CodePackage Name="Code" Version="1.0.0">
...
<EnvironmentVariables>
<EnvironmentVariable Name="HttpGatewayPort" Value=""/>
</EnvironmentVariables>
</CodePackage>
Deze omgevingsvariabelen kunnen worden overschreven in het toepassingsmanifest:
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="Guest1Pkg" ServiceManifestVersion="1.0.0" />
<EnvironmentOverrides CodePackageRef="FrontendService.Code">
<EnvironmentVariable Name="HttpGatewayPort" Value="19080"/>
</EnvironmentOverrides>
...
</ServiceManifestImport>
Poort-naar-host-toewijzing voor containers en container-naar-container-detectie configureren
Configureer een hostpoort voor communicatie met de container. De poortbinding wijst de poort toe waarop de service binnen de container luistert naar een poort op de host. Voeg een element PortBinding toe aan het element ContainerHostPolicies van het bestand ApplicationManifest.xml. Voor dit artikel geldt: ContainerPort is 80 (de container gebruikt poort 80, zoals opgegeven in het bestand Dockerfile) en EndpointRef is 'Guest1TypeEndpoint' (het eindpunt dat eerder is gedefinieerd in het servicemanifest). Binnenkomende aanvragen naar de service op poort 8081 worden toegewezen aan poort 80 in de container.
<ServiceManifestImport>
...
<Policies>
<ContainerHostPolicies CodePackageRef="Code">
<PortBinding ContainerPort="80" EndpointRef="Guest1TypeEndpoint"/>
</ContainerHostPolicies>
</Policies>
...
</ServiceManifestImport>
Notitie
Aanvullende PortBindings voor een service kunnen worden toegevoegd door extra PortBinding-elementen met toepasselijke eigenschapswaarden te declareren.
Verificatie van containeropslagplaats configureren
Zie Verificatievan containeropslagplaats voor meer informatie over het configureren van verschillende typen verificatie voor het downloaden van containerinstallatiekopieën.
Isolatiemodus configureren
Windows ondersteunt twee isolatiemodi voor containers: proces en Hyper-V. Met de procesisolatiemodus delen alle containers die worden uitgevoerd op dezelfde hostcomputer de kernel met de host. Met de Hyper-V-isolatiemodus hebben de kernels een scheiding tussen elke Hyper-V-container en de containerhost. De isolatiemodus is in het manifestbestand van de toepassing opgegeven in het element ContainerHostPolicies. De isolatiemodi die kunnen worden opgegeven zijn process, hyperv en default. De standaardinstelling is de procesisolatiemodus op Windows Server-hosts. Op Windows 10-hosts wordt alleen de Hyper-V-isolatiemodus ondersteund, zodat de container wordt uitgevoerd in de Hyper-V-isolatiemodus, ongeacht de instelling van de isolatiemodus. Het volgende codefragment toont hoe de isolatiemodus wordt opgegeven in het manifestbestand van de toepassing.
<ContainerHostPolicies CodePackageRef="Code" Isolation="hyperv">
Notitie
De hyperv-isolatiemodus is beschikbaar in de Azure-SKU's Ev3 en Dv3 aangezien die ondersteuning voor geneste virtualisatie bieden.
Resourcebeheer configureren
Resourcebeheer beperkt de resources die de container op de host kan gebruiken. Het element ResourceGovernancePolicy, dat is opgegeven in het toepassingsmanifest, wordt gebruikt om resourcebeperkingen te declareren voor een servicecodepakket. Er kunnen resourcebeperkingen worden ingesteld voor de volgende resources: geheugen, MemorySwap, CpuShares (relatief CPU-gewicht), MemoryReservationInMB, BlkioWeight (relatief BlockIO-gewicht). In dit voorbeeld krijgt het servicepakket Guest1Pkg één kern op de clusterknooppunten waar het wordt geplaatst. Geheugenlimieten zijn absoluut, dus het codepakket wordt beperkt tot 1024 MB aan geheugen (en een gegarandeerde flexibele reservering hierop). Codepakketten (containers of processen) kunnen niet meer geheugen toewijzen dan deze limiet. Een poging dit toch te doen, leidt tot een Onvoldoende geheugen-uitzondering. Voor een effectieve handhaving van resourcebeperkingen moeten voor alle pakketten binnen een servicepakket geheugenlimieten zijn opgegeven.
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="Guest1Pkg" ServiceManifestVersion="1.0.0" />
<Policies>
<ServicePackageResourceGovernancePolicy CpuCores="1"/>
<ResourceGovernancePolicy CodePackageRef="Code" MemoryInMB="1024" />
</Policies>
</ServiceManifestImport>
Docker-STATUSCONTROLE configureren
Vanaf versie 6.1 integreert Service Fabric automatisch Docker-STATUSCONTROLE-gebeurtenissen in het systeemstatusrapport. Dit betekent dat als voor uw container STATUSCONTROLE is ingeschakeld, Service Fabric de status van de container rapporteert wanneer Docker aangeeft dat deze is gewijzigd. In Service Fabric Explorer wordt de status OK weergegeven wanneer health_statushealthy is en WAARSCHUWING wanneer health_statusunhealthy is.
Vanaf de nieuwste vernieuwingsrelease van v6.4 kunt u opgeven dat docker HEALTHCHECK-evaluaties als een fout moeten worden gerapporteerd. Als deze optie is ingeschakeld, wordt er een OK-statusrapport weergegeven wanneer health_status in orde is en FOUT wordt weergegeven wanneer health_status niet in orde is.
De instructie STATUSCONTROLE, die verwijst naar de feitelijke controle die wordt uitgevoerd voor het bewaken van de containerstatus, moet aanwezig zijn in de Dockerfile die wordt gebruikt tijdens het genereren van de containerinstallatiekopie.
U kunt het gedrag van de STATUSCONTROLE voor elke container configureren door HealthConfig-opties op te geven als onderdeel van ContainerHostPolicies in ApplicationManifest.
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="ContainerServicePkg" ServiceManifestVersion="2.0.0" />
<Policies>
<ContainerHostPolicies CodePackageRef="Code">
<HealthConfig IncludeDockerHealthStatusInSystemHealthReport="true"
RestartContainerOnUnhealthyDockerHealthStatus="false"
TreatContainerUnhealthyStatusAsError="false" />
</ContainerHostPolicies>
</Policies>
</ServiceManifestImport>
IncludeDockerHealthStatusInSystemHealthReport is standaard ingesteld op true, RestartContainerOnUnhealthyDockerHealthStatus is ingesteld op false en TreatContainerUnhealthyStatusAsError is ingesteld op false.
Als RestartContainerOnUnhealthyDockerHealthStatus is ingesteld op true, wordt een herhaaldelijk niet goed werkende container opnieuw opgestart (mogelijk op andere knooppunten).
Als TreatContainerUnhealthyStatusAsError is ingesteld op true, worden foutstatusrapporten weergegeven wanneer de health_status van de container niet in orde is.
Als u de STATUSCONTROLE-integratie voor het hele Service Fabric-cluster wilt uitschakelen, stelt u EnableDockerHealthCheckIntegration in op false.
De containertoepassing implementeren
Sla al uw wijzigingen op en bouw de toepassing. Klik in Solution Explorer met de rechtermuisknop op MyFirstContainer en selecteer Publish om uw toepassing te publiceren.
Voer bij Verbindingseindpunt het beheereindpunt voor het cluster in. Bijvoorbeeld containercluster.westus2.cloudapp.azure.com:19000. U vindt het eindpunt voor de clientverbinding op het tabblad Overzicht voor het cluster in Azure Portal.
Klik op Publiceren.
Service Fabric Explorer is een webhulpprogramma voor het inspecteren en beheren van toepassingen en knooppunten in een Service Fabric-cluster. Open een browser, ga naar http://containercluster.westus2.cloudapp.azure.com:19080/Explorer/ en volg de implementatie van de toepassing. De toepassing wordt geïmplementeerd, maar heeft een foutstatus totdat de installatiekopieën worden gedownload op de clusterknooppunten (wat enige tijd kan duren, afhankelijk van de grootte van de installatiekopieën): 
De toepassing is gereed wanneer deze de status heeft Ready : 
Open een browser en ga naar http://containercluster.westus2.cloudapp.azure.com:8081. U ziet nu de kop 'Hallo wereld!' in de browser.
Opschonen
Zolang het cluster actief is, worden er kosten in rekening gebracht. Overweeg daarom het cluster te verwijderen.
Nadat u de installatiekopie naar het containerregister hebt gepusht, kunt u de lokale installatiekopie op de ontwikkelcomputer verwijderen:
docker rmi helloworldapp
docker rmi myregistry.azurecr.io/samples/helloworldapp
Compatibiliteit van windows Server-containerbesturingssystemen en hostbesturingssystemen
Windows Server-containers zijn niet compatibel in alle versies van een host-besturingssysteem. Bijvoorbeeld:
- Windows Server-containers die zijn gebouwd met Windows Server versie 1709 werken niet op een host met Windows Server versie 2016.
- Windows Server-containers die zijn gebouwd met Windows Server 2016 werken alleen in de isolatiemodus van Hyper-V op een host met Windows Server versie 1709.
- Met Windows Server-containers die zijn gebouwd met Windows Server 2016, is het mogelijk nodig om ervoor te zorgen dat de revisie van het container-besturingssysteem en het host-besturingssysteem hetzelfde zijn wanneer het wordt uitgevoerd in de procesisolatiemodus op een host met Windows Server 2016.
Zie Compatibiliteit met Windows-containerversies voor meer informatie.
Houd rekening met de compatibiliteit van het host-besturingssysteem en het container-besturingssysteem bij het bouwen en implementeren van containers in uw Service Fabric-cluster. Bijvoorbeeld:
- Zorg ervoor dat u containers implementeert met een besturingssysteem dat compatibel is met het besturingssysteem op uw clusterknooppunten.
- Zorg ervoor dat de isolatiemodus die is opgegeven voor uw containertoepassing consistent is met ondersteuning voor het containerbesturingssysteem op het knooppunt waarop deze wordt geïmplementeerd.
- Overweeg hoe upgrades van het besturingssysteem naar uw clusterknooppunten of containers van invloed kunnen zijn op hun compatibiliteit.
We raden de volgende procedures aan om ervoor te zorgen dat containers correct zijn geïmplementeerd in uw Service Fabric-cluster:
- Gebruik expliciete installatiekopietags met uw Docker-installatiekopieën om de versie van het Windows Server-besturingssysteem op te geven waaruit een container is gebouwd.
- Gebruik besturingssysteemtags in het manifestbestand van uw toepassing om ervoor te zorgen dat uw toepassing compatibel is met verschillende Versies en upgrades van Windows Server.
Notitie
Met Service Fabric versie 6.2 en hoger kunt u containers implementeren op basis van Windows Server 2016 lokaal op een Windows 10-host. In Windows 10 worden containers uitgevoerd in de Hyper-V-isolatiemodus, ongeacht de isolatiemodus die is ingesteld in het toepassingsmanifest. Zie Isolatiemodus configureren voor meer informatie.
Containerinstallatiekopieën opgeven die specifiek zijn voor de build van het besturingssysteem
Windows Server-containers zijn mogelijk niet compatibel in verschillende versies van het besturingssysteem. Windows Server-containers die zijn gebouwd met Windows Server 2016 werken bijvoorbeeld niet in windows Server versie 1709 in procesisolatiemodus. Als clusterknooppunten daarom worden bijgewerkt naar de nieuwste versie, kunnen containerservices die zijn gebouwd met de eerdere versies van het besturingssysteem mislukken. Om dit te omzeilen met versie 6.1 van de runtime en hoger, ondersteunt Service Fabric het opgeven van meerdere installatiekopieën van het besturingssysteem per container en het taggen ervan met de buildversies van het besturingssysteem in het toepassingsmanifest. U kunt de buildversie van het besturingssysteem ophalen door deze uit te voeren winver via een Windows-opdrachtprompt. Werk eerst per besturingssysteemversie de toepassingsmanifesten bij en geef het gebruik van specifieke installatiekopieën op, en werk daarna het besturingssysteem op de knooppunten bij. Het volgende fragment toont hoe u meerdere containerinstallatiekopieën opgeeft in het toepassingsmanifest 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>
De buildversie voor Windows Server 2016 is 14393 en de buildversie voor Windows Server versie 1709 is 16299. Het servicemanifest blijft slechts één installatiekopie per containerservice opgeven, zoals u hier ziet:
<ContainerHost>
<ImageName>myregistry.azurecr.io/samples/helloworldapp</ImageName>
</ContainerHost>
Notitie
De tagfunctionaliteit voor de build-versie van het besturingssysteem is alleen beschikbaar voor Service Fabric in Windows
Als het onderliggende besturingssysteem op de VM build 16299 (versie 1709) is, kiest Service Fabric de containerinstallatiekopie die overeenkomt met die versie van Windows Server. Als in het toepassingsmanifest een containerinstallatiekopie zonder tag wordt opgegeven samen met een containerinstallatiekopie met tag, behandelt Service Fabric de installatiekopie zonder tag als installatiekopie die in meerdere versies werkt. Voorzie de containerinstallatiekopieën expliciet van tags om problemen tijdens de upgraden te voorkomen.
De containerinstallatiekopie zonder tag werkt als overschrijving van de installatiekopie in het bestand ServiceManifest.xml. Met de installatiekopie "myregistry.azurecr.io/samples/helloworldappDefault" wordt dus ImageName "myregistry.azurecr.io/samples/helloworldapp" in het bestand ServiceManifest.xml overschreven.
Volledig voorbeeld van de manifesten voor de Fabric Service-toepassing en -service
Dit zijn de volledige manifesten voor de service en toepassing die in dit artikel worden gebruikt.
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>
Tijdsinterval configureren voor geforceerd beëindigen van container
U kunt een tijdsinterval configureren, zodat de runtime die tijd wacht voordat de container wordt verwijderd nadat het verwijderen van een service (of het verplaatsen naar een ander knooppunt) is gestart. Als u een tijdsinterval configureert, wordt de docker stop <time in seconds> opdracht verzonden naar de container. Zie docker stop voor meer informatie. Het tijdsinterval dat moet worden gewacht, kunt u opgeven in de sectie Hosting. De Hosting sectie kan worden toegevoegd bij het maken van een cluster of later in een configuratie-upgrade. Het volgende fragment van een clustermanifest laat zien hoe u het wachtinterval instelt:
"fabricSettings": [
...,
{
"name": "Hosting",
"parameters": [
{
"name": "ContainerDeactivationTimeout",
"value" : "10"
},
...
]
}
]
Het standaardtijdsinterval is 10 seconden. Aangezien deze configuratie dynamisch is, wordt de time-out bijgewerkt bij een configuratie-upgrade van het cluster.
De runtime configureren voor het verwijderen van ongebruikte containerinstallatiekopieën
U kunt het Service Fabric-cluster configureren voor het verwijderen van ongebruikte containerinstallatiekopieën van het knooppunt. Met deze configuratie kunt u schijfruimte vrijmaken als er te veel containerinstallatiekopieën aanwezig zijn op het knooppunt. Als u deze functie wilt inschakelen, werkt u de sectie Hosting in het clustermanifest bij, zoals wordt weergegeven in het volgende fragment:
"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|..."
}
...
}
]
}
]
De installatiekopieën die niet moeten worden verwijderd, kunt u opgeven met de parameter ContainerImagesToSkip.
Downloadtijd van de containerinstallatiekopie configureren
De Service Fabric-runtime wijst 20 minuten toe om containerinstallatiekopieën te downloaden en uit te pakken. Voor de meeste containerinstallatiekopieën is dat voldoende. Voor grote kopieën, of als de netwerkverbinding langzaam is, kan het echter nodig zijn om de toegewezen tijd te verlengen, zodat het downloaden en uitpakken van de installatiekopie niet voortijdig wordt afgebroken. Deze time-out wordt ingesteld met het kenmerk ContainerImageDownloadTimeout in de sectie Hosting van het clustermanifest, zoals u in het volgende fragment ziet:
"fabricSettings": [
...,
{
"name": "Hosting",
"parameters": [
{
"name": "ContainerImageDownloadTimeout",
"value": "1200"
}
]
}
]
Bewaarbeleid voor containers instellen
Om gemakkelijker opstartfouten bij containers te analyseren, ondersteunt Service Fabric (versie 6.1 of hoger) het bewaren van containers die zijn gestopt of niet kunnen opstartten. Dit beleid kan worden ingesteld in het bestand ApplicationManifest.xml, zoals u in het volgende fragment ziet:
<ContainerHostPolicies CodePackageRef="NodeService.Code" Isolation="process" ContainersRetentionCount="2" RunInteractive="true">
De instelling ContainersRetentionCount geeft aan hoeveel containers er moeten worden bewaard wanneer ze fouten genereren. Als er een negatieve waarde wordt opgegeven, worden alle niet goed werkende containers bewaard. Wanneer er bij het kenmerk ContainersRetentionCount niets is opgegeven, worden er geen containers bewaard. Het kenmerk ContainersRetentionCount ondersteunt ook toepassingsparameters, zodat gebruikers verschillende waarden kunnen opgeven voor test- en productieclusters. Bij het gebruik van deze functies dient u plaatsingsbeperkingen in te stellen om de containerservice op een bepaald knooppunt te richten. Zo voorkomt u dat de containerservice naar een ander knooppunt wordt verplaatst. Containers die met behulp van deze functie zijn bewaard, moeten handmatig worden verwijderd.
De Docker-daemon met aangepaste argumenten starten
Met versie 6.2 of hoger van de Service Fabric-runtime kunt u de Docker-daemon met aangepaste argumenten starten. Wanneer er aangepaste argumenten zijn opgegeven, geeft Service Fabric geen andere argumenten aan de docker-engine door, behalve het argument --pidfile. Daarom moet --pidfile niet als een argument worden doorgegeven. Bovendien moet het argument de docker-daemon nog steeds laten luisteren op de standaard benoemde pipe voor Windows (of unix-domeinsocket voor Linux) zodat Service Fabric met de daemon kan communiceren. De aangepaste argumenten worden doorgegeven in het clustermanifest onder de sectie Hosting onder ContainerServiceArguments, zoals weergegeven in het volgende fragment:
"fabricSettings": [
...,
{
"name": "Hosting",
"parameters": [
{
"name": "ContainerServiceArguments",
"value": "-H localhost:1234 -H unix:///var/run/docker.sock"
}
]
}
]
EntryPoint-onderdrukking
Met 8.2-versie van ServiceFabric Runtime kan het invoerpunt voor container - en exe-hostcodepakket worden overschreven. Dit kan worden gebruikt in gevallen waarin alle manifestelementen hetzelfde blijven, maar de containerinstallatiekopie moet worden gewijzigd, het inrichten van een andere versie van het app-type is niet meer vereist of verschillende argumenten moeten worden doorgegeven op basis van test- of prod-scenario en het toegangspunt blijft hetzelfde.
Hieronder volgt een voorbeeld van het overschrijven van containerinvoerpunt:
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>
Nadat de onderdrukkingen in het toepassingsmanifest zijn opgegeven, wordt de container met de naam van de installatiekopieën myregistry.azurecr.io/samples/helloworldapp, opdrachtopdrachtenOverride, bronbronOverride en entryPoint entryPointOverride gestart.
Hieronder ziet u ook een voorbeeld van het overschrijven van de ExeHost:
<?xml version="1.0" encoding="utf-8"?>
<Policies>
<CodePackagePolicy CodePackageRef="Code">
<EntryPointOverride>
<ExeHostOverride>
<Program>[Program]</Program>
<Arguments>[Entry]</Arguments>
</ExeHostOverride>
</EntryPointOverride>
</CodePackagePolicy>
</Policies>
Notitie
Het overschrijven van toegangspunten wordt niet ondersteund voor SetupEntryPoint.
Volgende stappen
- Meer informatie over het uitvoeren van containers in Service Fabric.
- Lees de zelfstudie Een .NET-toepassing implementeren in een container.
- Meer informatie over de levenscyclus van de Service Fabric-toepassing.
- Bekijk voorbeelden van Service Fabric-containercode op GitHub.