Az első Service Fabric-tárolóalkalmazás létrehozása Windows rendszeren

• Windows
• Linux

A meglévő alkalmazások Service Fabric-fürtökön lévő Windows-tárolókban való futtatásához nem szükséges módosítania az alkalmazást. Ez a cikk bemutatja, hogyan hozhat létre egy Python Flask-webalkalmazást tartalmazó Docker-rendszerképet, és üzembe helyezheti azt egy Azure Service Fabric-fürtben. Emellett meg is fogja osztani a tárolóalapú alkalmazást az Azure Container Registry használatával. A cikk feltételezi, hogy rendelkezik a Docker használatára vonatkozó alapvető ismeretekkel. A Docker megismeréséhez olvassa el a Docker áttekintő ismertetését.

Megjegyzés:

Ez a cikk windowsos fejlesztési környezetekre vonatkozik. A Service Fabric-fürt futtatókörnyezetének és a Docker-futtatókörnyezetnek ugyanazon az operációs rendszeren kell futnia. Windows-tárolók linuxos fürtön nem futtathatók.

Megjegyzés:

We recommend that you use the Azure Az PowerShell module to interact with Azure. See Install Azure PowerShell to get started. To learn how to migrate to the Az PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.

Előfeltételek

• Egy fejlesztői számítógép, amelyen a következők futnak:

  • Visual Studio 2015 vagy Visual Studio 2019.
  • Service Fabric SDK és -eszközök.
  • Windows rendszerhez készült Docker. A Docker CE for Windows (stable) letöltése. Miután telepítette és elindította a Dockert, kattintson a jobb gombbal a tálca ikonjára, és válassza a Switch to Windows containers (Váltás Windows-tárolókra) lehetőséget. Ez a lépés szükséges ahhoz, hogy Windows-alapú Docker-rendszerképeket tudjon futtatni.

• Windows-fürt, amelyen három vagy több csomópont fut a Windows Serveren tárolókkal.

  Ebben a cikkben a Windows Server fürtcsomópontokon futó tárolókkal rendelkező verziójának (buildjének) meg kell egyeznie a fejlesztői gépen lévővel. Ennek az az oka, hogy a docker-rendszerképet a fejlesztői gépen hozza létre, és kompatibilitási korlátozások vannak a tároló operációs rendszerének és az üzembe helyezett gazdagép operációs rendszerének verziói között. További információ: Windows Server tároló operációs rendszere és a gazdagép operációs rendszerének kompatibilitása.

  A windowsos kiszolgáló fürthöz szükséges verziójának meghatározásához futtassa a parancsot egy ver Windows parancssorból a fejlesztői gépen. Fürt létrehozása előtt tekintse meg a Windows Server tároló operációs rendszerét és a gazdagép operációs rendszerének kompatibilitását.

• Egy Azure Container Registry-beállításjegyzék – ehhez hozzon létre egy tároló-beállításjegyzéket Azure-előfizetésében.

Megjegyzés:

A tárolók windows 10-en futó Service Fabric-fürtön való üzembe helyezése támogatott. Ebből a cikkből megtudhatja, hogyan konfigurálhatja a Windows 10-et Windows-tárolók futtatására.

Megjegyzés:

A Service Fabric 6.2-es és újabb verziói támogatják a tárolók központi telepítését a Windows Server 1709-es verzióján futó fürtökön.

A Docker-tároló definiálása

Állítson össze egy rendszerképet a Docker Hubban található Python-rendszerkép alapján.

Adja meg a Docker-tárolót egy Docker-fájlban. A Docker-fájl a környezet tárolón belüli beállítására, a futtatni kívánt alkalmazás betöltésére és a portok hozzárendelésére vonatkozó utasításokat tartalmazza. A Docker-fájl a docker build parancs bemenete, amely a rendszerképet létrehozza.

Hozzon létre egy üres könyvtárat és a Docker-fájlt (fájlkiterjesztés nélkül). Adja hozzá a következőket a Docker-fájlhoz, és mentse a módosításokat:

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

További információkért olvassa el a Docker-fájlra vonatkozó referenciákat.

Alapszintű webalkalmazás létrehozása

Hozzon létre egy olyan Flask-webalkalmazást, amely a 80-as portot figyeli, és a Hello World! szöveget adja vissza. Ugyanebben a könyvtárban hozza létre a requirements.txt fájlt. Adja hozzá a következőket, és mentse a módosításokat:

Flask

Hozza létre az app.py fájlt, és adja hozzá a következő kódrészletet:

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)

Jelentkezzen be a Dockerbe, és hozza létre a rendszerképet

Ezután létrehozzuk a webalkalmazást futtató lemezképet. Amikor nyilvános képeket kér le a Dockerből (például python:2.7-windowsservercore a Dockerfile-ban), ajánlott a Docker Hub-fiókkal hitelesíteni a névtelen lekéréses kérések helyett.

Megjegyzés:

Gyakori névtelen lekéréses kérelmek esetén a Docker Hubhoz ERROR: toomanyrequests: Too Many Requests. hasonló vagy You have reached your pull rate limit. hitelesítéssel kapcsolatos Docker-hibák jelenhetnek meg a hibák elkerülése érdekében. További információ: Nyilvános tartalom kezelése az Azure Container Registry használatával.

Nyisson meg egy PowerShell-ablakot, és lépjen a Docker-fájlt tartalmazó könyvtárra. Ezután futtassa le a következő parancsokat:

docker login
docker build -t helloworldapp .

Ez a parancs létrehozza az új rendszerképet a Docker-fájlban foglalt utasítások alapján, és a helloworldapp nevet adja a rendszerképnek (-t címkézéssel). A tárolórendszerkép létrehozásához először az alaprendszerképet kell letöltenie a Docker Hubról, és ahhoz kell hozzáadnia az alkalmazást.

Miután az összeállító parancs lefutott, futtassa a docker images parancsot az új rendszerkép információinak megtekintéséhez:

$ docker images

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

Az alkalmazás helyi futtatása

Ellenőrizze helyben a rendszerkép működését, mielőtt leküldené azt a tároló-beállításjegyzékbe.

Futtassa az alkalmazást:

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

A name nevet ad a futtató tárolónak (a tárolóazonosító helyett).

Miután a tároló elindult, keresse meg az IP-címét, hogy böngészőből is el tudja érni a futó tárolót:

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

Ha a parancs nem ad vissza semmit, futtassa a következő parancsot, és vizsgálja meg a Network Gépház-Networks elemet az IP-címhez>:

docker inspect my-web-site

Csatlakozzon a futó tárolóhoz. Nyisson meg egy webböngészőt, amely a visszaadott IP-címre mutat, például "http://172.31.194.61". A böngészőben a ""Helló világ!" alkalmazás!" fejlécnek kell megjelennie.

A tároló leállításához futtassa a következő parancsot:

docker stop my-web-site

Törölje a tárolót a fejlesztői gépről:

docker rm my-web-site

A rendszerkép leküldése a tároló-beállításjegyzékbe

Miután ellenőrizte, hogy a tároló fut-e a fejlesztői gépen, küldje le a rendszerképet a beállításjegyzékébe az Azure Container Registryben.

Futtassa docker login a tárolóregisztrációs adatbázisba való bejelentkezést a beállításjegyzék hitelesítő adataival.

Az alábbi példa egy Microsoft Entra szolgáltatásnév azonosítóját és jelszavát adja át. Például lehet, hogy hozzárendelt egy egyszerű szolgáltatást a beállításjegyzékhez egy automatizálási forgatókönyvhöz. Vagy bejelentkezhet a beállításjegyzékbeli felhasználónévvel és jelszóval.

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

A következő parancs létrehoz egy címkét vagy aliast a rendszerképről a beállításjegyzékre mutató teljes elérési úttal. Az alábbi példa a rendszerképet a samples névtérben helyezi el, hogy ne legyen zsúfolt a beállításjegyzék gyökere.

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

Küldje le a rendszerképet tároló-beállításjegyzékbe:

docker push myregistry.azurecr.io/samples/helloworldapp

A tárolóalapú szolgáltatás létrehozása a Visual Studióban

A Service Fabric SDK és -eszközök egy szolgáltatássablont biztosítanak, amellyel tárolóalapú alkalmazást hozhat létre.

1. Indítsa el a Visual Studiót. Válassza a File (Fájl)>New (Új)>Project (Projekt) lehetőséget.
2. Válassza a Service Fabric application (Service Fabric-alkalmazás) lehetőséget, nevezze el „MyFirstContainer” néven, és kattintson az OK gombra.
3. Az szolgáltatássablonok listájában válassza a Tároló elemet.
4. Az Image Name (Rendszerkép neve) mezőben adja meg a „myregistry.azurecr.io/samples/helloworldapp” rendszerképet, amelyet leküldött a tároló-beállításjegyzékbe.
5. Nevezze el a szolgáltatást, és kattintson az OK gombra.

A kommunikáció konfigurálása

A tárolóalapú szolgáltatáshoz szükség van egy kommunikációs végpontra. Adja hozzá a protokollt, a portot és a típust tartalmazó Endpoint elemet a servicemanifest.xml fájlhoz. Ez a példa egy rögzített 8081-es portot használ erre a célra. Ha nincs megadva port, a rendszer egy véletlenszerű portot választ az alkalmazás porttartományából.

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

Megjegyzés:

A szolgáltatás további végpontjai további EndPoint-elemek deklarálásával vehetők fel a megfelelő tulajdonságértékekkel. Minden port csak egy protokollértéket deklarálhat.

Egy végpont megadásával a Service Fabric közzéteszi a végpontot az elnevezési szolgáltatásban. A fürtben futó más szolgáltatások feloldhatják ezt a tárolót. Tárolók közötti kommunikációt is folytathat a fordított proxyval. A kommunikációhoz környezeti változókként adja meg a fordított proxy HTTP-figyelő portját és azon szolgáltatások nevét, amelyekkel kommunikálni kíván.

A szolgáltatás egy adott portot figyel (ebben a példában a 8081-est). Az alkalmazások Azure-beli fürtön való üzembe helyezésekor a fürt és az alkalmazás is Azure-terheléselosztó mögött fut. Az alkalmazásportnak nyitva kell lennie Azure Load Balancerben, hogy a bejövő forgalom elérhesse a szolgáltatást. Ezt a portot egy PowerShell-szkripttel vagy az Azure Portalon nyithatja meg az Azure Load Balancerben.

Környezeti változók konfigurálása és beállítása

A szolgáltatásjegyzékben minden kódcsomaghoz megadhatók környezeti változók. Ez a funkció az összes szolgáltatáshoz elérhető attól függetlenül, hogy tárolókként, folyamatokként vagy vendég futtatható fájlokként vannak-e üzembe helyezve. A környezeti változó értékeit felülbírálhatja az alkalmazásjegyzékben, vagy az üzembe helyezés alatt megadhatja őket alkalmazásparaméterekként.

A következő szolgáltatásjegyzékbeli XML-kódrészlet arra mutat be egy példát, hogyan adhat meg környezeti változókat egy kódcsomaghoz:

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

Ezek a környezeti változók bírálhatók felül az alkalmazásjegyzékben:

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

Tárolóport–gazdagépport hozzárendelés és tároló–tároló felderítés konfigurálása

Konfiguráljon egy gazdagépportot a tárolóval való kommunikációhoz. A portkötés a gazdagép egyik portjához rendeli hozzá a szolgáltatás által figyelt tárolóportot. Adjon hozzá egy PortBinding elemet az ApplicationManifest.xml fájl ContainerHostPolicies eleméhez. Ebben a cikkben a ContainerPort értéke 80 (a tároló a 80-as portot használja a Docker-fájlban foglalt beállítások szerint), az EndpointRef pedig „Guest1TypeEndpoint” (a szolgáltatásjegyzékben korábban definiált végpont). A szolgáltatáshoz a 8081-es porton beérkező kérések a tárolón a 80-as portra vannak leképezve.

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

Megjegyzés:

A szolgáltatáshoz további PortBinding-elemeket is hozzáadhat, ha további PortBinding-elemeket deklarál a vonatkozó tulajdonságértékekkel.

Tárolóadattár-hitelesítés konfigurálása

A tárolólemezképek letöltéséhez tekintse meg a tárolóadattár-hitelesítéstismertető témakört, amelyből megtudhatja, hogyan konfigurálhat különböző típusú hitelesítést a tárolólemezképek letöltéséhez.

Az elkülönítési mód konfigurálása

A Windows a tárolók két elkülönítési módját támogatja: a folyamatalapú és a Hyper-V módot. Folyamatelkülönítési módban az ugyanazon a gazdagépen futó összes tároló ugyanazt a kernelt használja, mint a gazdagép. Hyper-V elkülönítési módban az egyes Hyper-V tárolók és a tároló gazdagép kernelei elkülönülnek. Az elkülönítési mód az alkalmazásjegyzék-fájl ContainerHostPolicies elemében van meghatározva. A megadható elkülönítési módok a következők: process, hyperv és default. Az alapértelmezett folyamatelkülönítési mód a Windows Server-gazdagépeken. Windows 10-gazdagépeken csak a Hyper-V elkülönítési mód támogatott, így a tároló az elkülönítési mód beállításától függetlenül Hyper-V elkülönítési módban fut. A következő kódrészlet azt mutatja be, hogyan van határozható meg az elkülönítési mód az alkalmazásjegyzék-fájlban.

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

Megjegyzés:

A HyperV elkülönítési módja az Azure beágyazott virtualizálástámogatással rendelkező Ev3 és Dv3 SKU-ján érhető el.

Az erőforrás-szabályozás konfigurálása

Az erőforrás-szabályozás korlátozza a tároló által a gazdagépen használható erőforrásokat. Az alkalmazásjegyzékben megadott ResourceGovernancePolicy elemmel határozhatók meg erőforráskorlátok a szolgáltatások kódcsomagjaihoz. A következő erőforrásokhoz állíthatók be erőforráskorlátok: Memory, MemorySwap, CpuShares (CPU relatív súlya), MemoryReservationInMB, BlkioWeight (BlockIO relatív súlya). Ebben a példában a Guest1Pkg szolgáltatáscsomag egy magot kap a fürtcsomópontokon, amelyekre el van helyezve. A memóriakorlátok abszolútak, ezért a kódcsomag 1024 MB memóriára van korlátozva (és ugyanennyi a gyenge garanciás foglalás). A kódcsomagok (tárolók vagy folyamatok) nem tudnak ennél a korlátnál több memóriát lefoglalni, és ennek megkísérlése memóriahiány miatti kivételt eredményez. Az erőforráskorlát érvényesítéséhez a szolgáltatáscsomagokban lévő minden kódcsomaghoz memóriakorlátokat kell meghatároznia.

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

Docker HEALTHCHECK konfigurálása

A 6.1-es verzióval kezdődően a Service Fabric automatikusan integrálja a docker HEALTHCHECK eseményeket a rendszerállapot-jelentésbe. Ez azt jelenti, hogy ha a tárolón engedélyezett a HEALTHCHECK, a Service Fabric jelenti az állapotát, valahányszor a tároló állapota módosul a Docker jelentése szerint. Egy OK állapotjelentés jelenik meg a Service Fabric Explorerben, amikor a health_status értéke healthy (megfelelő), és egy WARNING jelenik meg, ha a health_status értéke unhealthy (nem megfelelő).

A 6.4-es verzió legújabb frissítési kiadásától kezdve megadhatja, hogy a Docker HEALTHCHECK kiértékelései hibaként jelenjenek meg. Ha ez a beállítás engedélyezve van, egy OK állapotjelentés jelenik meg, ha health_statusállapota kifogástalan, és hiba jelenik meg, ha health_status nem megfelelő.

A tároló állapotának monitorozása céljából ténylegesen elvégzett ellenőrzésre mutató HEALTHCHECK utasításnak szerepelnie kell a tárolórendszerkép létrehozásához használt Docker-fájlban.

A HEALTHCHECK viselkedését konfigurálhatja az egyes tárolókhoz, ha megadja a HealthConfig beállításait a ContainerHostPolicies részeként az ApplicationManifest fájlban.

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

Alapértelmezés szerint az IncludeDockerHealthStatusInSystemHealthReport értéke igaz, a RestartContainerOnUnhealthyDockerHealthStatusértéke hamis, a TreatContainerUnhealthyStatusAsErrorértéke pedig hamis.

Ha a RestartContainerOnUnhealthyDockerHealthStatus beállítása true, egy újra és újra nem megfelelő állapotúnak jelentett tároló újraindul (lehetőleg más csomópontokon).

Ha a TreatContainerUnhealthyStatusAsError értéke igaz, akkor hibaállapot-jelentések jelennek meg, ha a tároló health_statusállapota nem megfelelő.

Ha az egész Service Fabric-fürthöz le szeretné tiltani a HEALTHCHECK integrációját, az EnableDockerHealthCheckIntegration elemet false értékre kell állítania.

A tárolóalkalmazás üzembe helyezése

Mentse az összes módosítást, és hozza létre az alkalmazást. Az alkalmazás közzétételéhez kattintson a jobb gombbal a MyFirstContainer elemre a Megoldáskezelőben, és válassza a Közzététel lehetőséget.

A Kapcsolati végpont területen adja meg a fürt kezelési végpontját, For example, containercluster.westus2.cloudapp.azure.com:19000. Az ügyfél csatlakozási végpontját a fürt Áttekintés lapján találja az Azure Portalon.

Kattintson a Publish (Közzététel) gombra.

A Service Fabric Explorer egy webalapú eszköz az alkalmazások és csomópontok vizsgálatához és kezeléséhez a Service Fabric-fürtökben. Nyisson meg egy böngészőt, lépjen a http://containercluster.westus2.cloudapp.azure.com:19080/Explorer/ helyre, és kövesse az alkalmazás üzembe helyezését. Az alkalmazás üzembe helyeződik, de hibaállapotban van, amíg a rendszerkép le nem töltődik a fürtcsomópontokra (ami a kép méretétől függően eltarthat egy ideig):

Az alkalmazás készen áll, ha állapotban Ready van:

Nyisson meg egy böngészőt, majd lépjen a következő helyre: http://containercluster.westus2.cloudapp.azure.com:8081. A böngészőben a ""Helló világ!" alkalmazás!" fejlécnek kell megjelennie.

A fölöslegessé vált elemek eltávolítása

A fürt futtatása költségekkel jár, ezért érdemes lehet törölni a fürtöt.

Miután leküldte a rendszerképet a tárolóregisztrációs adatbázisba, törölheti a helyi rendszerképet a fejlesztői számítógépről:

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

A Windows Server tároló operációs rendszere és a gazdagép operációs rendszerének kompatibilitása

A Windows Server-tárolók nem kompatibilisek a gazdagép operációs rendszerének összes verziójával. Például:

• A Windows Server 1709-es verziójával készült Windows Server-tárolók nem működnek a Windows Server 2016-os verzióját futtató gazdagépeken.
• A Windows Server 2016 használatával létrehozott Windows Server-tárolók Hyper-V elkülönítési módban csak a Windows Server 1709-es verzióját futtató gazdagépen működnek.
• A Windows Server 2016 használatával létrehozott Windows Server-tárolók esetén előfordulhat, hogy a tároló operációs rendszerének és a gazdagép operációs rendszerének felülvizsgálata megegyezik a Windows Server 2016 rendszert futtató gazdagép folyamatelkülönítési módban történő futtatásakor.

További információkért tekintse meg a Windows tárolóverzió kompatibilitását.

Fontolja meg a gazdagép operációs rendszerének és a tároló operációs rendszerének kompatibilitását, amikor tárolókat hoz létre és helyez üzembe a Service Fabric-fürtben. Például:

• Győződjön meg arról, hogy az operációs rendszerrel kompatibilis operációs rendszerrel rendelkező tárolókat helyez üzembe a fürtcsomópontokon.
• Győződjön meg arról, hogy a tárolóalkalmazáshoz megadott elkülönítési mód összhangban van a tároló operációs rendszerének támogatásával azon a csomóponton, ahol az üzembe helyezés folyamatban van.
• Fontolja meg, hogy a fürtcsomópontokra vagy tárolókra való operációsrendszer-frissítések hogyan befolyásolhatják azok kompatibilitását.

A következő eljárásokat javasoljuk annak biztosításához, hogy a tárolók megfelelően legyenek üzembe helyezve a Service Fabric-fürtön:

• A Docker-rendszerképekkel való explicit rendszerkép-címkézéssel megadhatja a Windows Server operációs rendszer azon verzióját, amelyből egy tároló készült.
• Az operációsrendszer-címkézést az alkalmazásjegyzékfájlban használva győződjön meg arról, hogy az alkalmazás kompatibilis a Különböző Windows Server-verziók és -frissítések között.

Megjegyzés:

A Service Fabric 6.2-es és újabb verziójával a Windows Server 2016-on alapuló tárolókat telepítheti helyileg Egy Windows 10-gazdagépen. Windows 10 rendszerben a tárolók Hyper-V elkülönítési módban futnak, függetlenül az alkalmazásjegyzékben beállított elkülönítési módtól. További információ: Elkülönítési mód konfigurálása.

Specifikus tárolórendszerképek megadása az operációs rendszer buildje alapján

Előfordulhat, hogy a Windows Server-tárolók nem kompatibilisek az operációs rendszer különböző verzióival. A Windows Server 2016 használatával készült Windows Server-tárolók például nem működnek a Windows Server 1709-es verzióján folyamatelkülönítési módban. Ezért ha a fürtcsomópontok a legújabb verzióra frissülnek, az operációs rendszer korábbi verzióival létrehozott tárolószolgáltatások meghiúsulhatnak. A futtatókörnyezet 6.1-es és újabb verziójával való megkerüléséhez a Service Fabric támogatja, hogy tárolónként több operációsrendszer-lemezképet adjon meg, és megjelölje őket az operációs rendszer buildverzióival az alkalmazásjegyzékben. Az operációs rendszer buildverzióját egy Windows parancssorban futtatva winver szerezheti be. Frissítse az alkalmazásjegyzékeket, és operációsrendszer-verziónként adjon meg külön rendszerkép-felülbírálásokat, mielőtt frissítené az operációs rendszert a csomópontokon. A következő kódrészlet azt mutatja be, hogyan adható meg több tároló-rendszerkép az ApplicationManifest.xml alkalmazásjegyzék-fájlban:

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

A Windows Server 2016 buildverziója 14393, a Windows Server 1709 buildverziója pedig 16299. A szolgáltatásjegyzék továbbra is csak egy rendszerképet ad meg mindegyik tárolószolgáltatáshoz, ahogy az alábbi kódrészletben is látható:

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

Megjegyzés:

Az operációs rendszer buildverzióját címkéző szolgáltatás csak a Windowson futó Service Fabric esetében érhető el

Ha a virtuális gép mögöttes operációs rendszerének buildverziója 16299 (1709-es verzió), a Service Fabric az ehhez Windows Server verzióhoz tartozó tárolórendszerképet választja ki. Ha a felcímkézett tárolórendszerképek mellett egy fel nem címkézett tárolórendszerkép is található az alkalmazásjegyzékben, a Service Fabric a fel nem címkézett rendszerképet az összes verzióban használható rendszerképként kezeli. A frissítések során felmerülő hibák elkerülése érdekében explicit módon címkézze fel a tárolórendszerképeket.

A címke nélküli tárolórendszerkép a ServiceManifest elemben megadott tárolórendszerképet felülíró értékként fog működni. Ennek értelmében a „myregistry.azurecr.io/samples/helloworldappDefault” rendszerkép felülírja a „myregistry.azurecr.io/samples/helloworldapp” rendszerképnevet a ServiceManifest elemben.

Példa teljes Service Fabric-alkalmazásra és szolgáltatásjegyzékre

Itt találja a jelen cikkben használt teljes szolgáltatás- és alkalmazásjegyzéket.

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>

A tároló kényszerített leállítását megelőző időköz beállítása

Konfigurálhat egy időintervallumot a futtatókörnyezet számára, ezzel megadva, hogy az mennyit várjon a tároló eltávolítása előtt, miután megkezdődött a szolgáltatás törlése (vagy másik csomópontba áthelyezése). Az időintervallum konfigurálásával a docker stop <time in seconds> parancsot küldi a tárolónak. További információ: docker stop. A várakozási időköz a Hosting szakaszban van meghatározva. A Hosting szakasz hozzáadható a fürt létrehozásakor vagy később egy konfigurációfrissítésben. Az alábbi fürtjegyzék kódrészlete azt mutatja be, hogyan adható meg a várakozási időköz:

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

Az alapértelmezett időintervallum 10 másodperc. Mivel ez egy dinamikus konfiguráció, a csak konfigurációs frissítés a fürtön frissíti az időkorlátot.

Futtatókörnyezet konfigurálása a nem használt tárolórendszerképek eltávolításához

A Service Fabric-fürtöt úgy is konfigurálhatja, hogy eltávolítsa a nem használt tárolórendszerképeket a csomópontról. Ez a konfiguráció lehetővé teszi a lemezterület visszanyerését, ha túl sok tárolórendszerkép található a csomóponton. A funkció engedélyezéséhez frissítse a fürtjegyzék Üzemeltetési szakaszát az alábbi kódrészletben látható módon:

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

A ContainerImagesToSkip paraméternél megadhatja azokat a rendszerképeket, amelyeket nem szabad törölni.

Tárolórendszerkép letöltési idejének konfigurálása

A Service Fabric futtatókörnyezete 20 percet foglal le a tárolórendszerképek letöltésére és kicsomagolására, és ez a tárolórendszerképek többségénél elegendő is. Nagyobb rendszerképek esetében, vagy ha a hálózati kapcsolat lassú, szükséges lehet növelni a rendszerkép letöltésének és kibontásának megszakításáig rendelkezésre álló időtartamot. Ez az időtúllépési érték a ContainerImageDownloadTimeout attribútummal állítható be a fürtjegyzék Üzemeltetés szakaszában, az alábbi kódrészletben látható módon:

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

Tárolómegőrzési szabályzat megadása

A tárolóindítási hibák diagnosztizálásának elősegítése céljából a Service Fabric (6.1-es vagy újabb verzió esetén) támogatja a megszakadt működésű vagy el sem induló tárolók megőrzését. Ez a szabályzat az ApplicationManifest.xml fájlban állítható be az alábbi kódrészletben látható módon:

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

A ContainersRetentionCount beállítása megadja a hiba esetén megőrzendő tárolók számát. Ha negatív érték van megadva, a rendszer minden olyan tárolót megőriz, amelyen hiba jelentkezik. Ha a ContainersRetentionCount attribútum nincs megadva, a rendszer nem őriz meg tárolókat. A ContainersRetentionCount attribútum az Alkalmazásparamétereket is támogatja, így a felhasználók különböző értékeket adhatnak meg a tesztelési és az éles fürtökön. A funkció használatakor alkalmazzon elhelyezési korlátozásokat, hogy a tárolószolgáltatás egy adott csomóponton maradjon, és a rendszer ne kerüljön át más csomópontokra. Az ezzel a funkcióval megőrzött tárolókat manuálisan kell eltávolítani.

A Docker-démon indítása egyéni argumentumokkal

A Service Fabric-futtatókörnyezet 6.2-es vagy újabb verzióiban a Docker-démon egyéni argumentumokkal is elindítható. Ha egyéni argumentumok vannak megadva, a Service Fabric csak a --pidfile argumentumot továbbítja a Docker-motornak. A --pidfile argumentumként való megadása ezért nem szükséges. Emellett az argumentumnak továbbra is meg kell határoznia, hogy a Docker-démon figyelje a Windows (vagy Linux esetén a Unix-tartománycsatorna) nevesített csövét, hogy a Service Fabric kommunikálni tudjon a démonnal. Az egyéni argumentumok a ContainerServiceArgumentsÜzemeltetés szakaszában, a fürtjegyzékben adhatók át, amint az az alábbi kódrészletben látható:

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

EntryPoint-felülbírálás

A ServiceFabric Runtime 8.2-es verziójával felül lehet bírálni a tároló- és exe-gazdagép kódcsomagjának belépési pontját. Ez olyan esetekben használható, amikor az összes jegyzékelem változatlan marad, de a tárolórendszerképet módosítani kell, majd egy másik alkalmazástípusú verzió kiépítésére már nincs szükség, vagy különböző argumentumokat kell átadni tesztelési vagy próbaforgatókönyv alapján, és a belépési pont változatlan marad.

Az alábbiakban egy példa látható a tárolóbeléptetési pont felülbírálására:

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>

Az alkalmazásjegyzékben szereplő felülbírálások megadása után a rendszer elindítja az myregistry.azurecr.io/samples/helloworldapp nevű tárolót, a parancsparancsokatOverride, a source SourceOverride és a entryPoint entryPointOverride parancsot.

Hasonlóképpen, az alábbi példa az ExeHost felülbírálására:

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

Megjegyzés:

A SetupEntryPoint nem támogatja a belépési pontok felülbírálását.

Következő lépések

• További információk a tárolók futtatásáról a Service Fabricban.
• Tekintse meg a .NET-alkalmazás üzembe helyezését ismertető oktatóanyagot.
• További információk a Service Fabric alkalmazásainak élettartamáról.
• Tekintse meg a Service Fabric-tárolók mintakódjait a GitHubon.