Megosztás a következőn keresztül:

Fejlesztési munkafolyamat Docker-alkalmazásokhoz

Tipp.

Ez a tartalom egy részlet a .NET-alkalmazásokhoz készült .NET-alkalmazásokhoz készült eBook, .NET Microservices Architecture című eBookból, amely elérhető a .NET Docs-on vagy egy ingyenesen letölthető PDF-fájlként, amely offline módban is olvasható.

PDF letöltése

.NET mikroszolgáltatások architektúrája konténerizált .NET alkalmazásokhoz e-könyv borító miniatűr.

Az alkalmazásfejlesztési életciklus fejlesztőként a számítógépen kezdődik, ahol az alkalmazást az előnyben részesített nyelv használatával kódozza, és helyileg teszteli. Ezzel a munkafolyamattal a választott nyelvtől, keretrendszertől és platformtól függetlenül mindig Docker-tárolókat fejleszt és tesztel, de ezt helyileg végzi.

Minden tároló (Egy Docker-rendszerkép egy példánya) a következő összetevőket tartalmazza:

  • Operációs rendszer kiválasztása, például Linux-disztribúció, Windows Nano Server vagy Windows Server Core.
  • A fejlesztés során hozzáadott fájlok, például a forráskód és az alkalmazás bináris fájljai.
  • Konfigurációs információk, például környezeti beállítások és függőségek.

Munkafolyamat Docker-tárolóalapú alkalmazások fejlesztéséhez

Ez a szakasz a Docker-tárolóalapú alkalmazások belső ciklusú fejlesztési munkafolyamatát ismerteti. A belső ciklusú munkafolyamat azt jelenti, hogy nem veszi figyelembe a szélesebb körű DevOps-munkafolyamatot, amely akár az éles üzembe helyezést is magában foglalhatja, és csak a fejlesztő számítógépén végzett fejlesztési munkára összpontosít. A környezet beállításának kezdeti lépései nem szerepelnek benne, mivel ezek a lépések csak egyszer lesznek végrehajtva.

Az alkalmazások saját szolgáltatásokból és további kódtárakból (függőségekből) állnak. A Docker-alkalmazások létrehozásakor általában az alábbi alapvető lépéseket kell elvégeznie az 5–1. ábrán látható módon.

A tárolóalapú alkalmazások létrehozásának hét lépését bemutató ábra.

5-1. ábra. Részletes munkafolyamat a Docker-tárolóalapú alkalmazások fejlesztéséhez

Ebben a szakaszban ez az egész folyamat részletes, és minden fontos lépést egy Visual Studio-környezetre összpontosítva magyarázunk.

Ha szerkesztői/CLI-fejlesztési megközelítést használ (például a Visual Studio Code-ot és a Docker CLI-t macOS vagy Windows rendszeren), minden lépést ismernie kell, általában részletesebben, mint ha a Visual Studiót használja. A CLI-környezetek használatával kapcsolatos további információkért tekintse meg a Tárolóalapú Docker-alkalmazások életciklusát a Microsoft Platformokkal és eszközökkel című e-könyvben.

A Visual Studio 2022 vagy újabb verziójának használatakor a rendszer számos ilyen lépést kezel, ami jelentősen javítja a termelékenységet. Ez különösen akkor igaz, ha többtárolós alkalmazásokat céloz meg. Egy kattintással például a Visual Studio hozzáadja a Dockerfile projektet és docker-compose.yml a fájlt az alkalmazás konfigurációjával. Amikor az alkalmazást a Visual Studióban futtatja, az létrehozza a Docker-lemezképet, és közvetlenül a Dockerben futtatja a többtárolós alkalmazást; lehetővé teszi több tároló egyszerre történő hibakeresését is. Ezek a funkciók növelik a fejlesztési sebességet.

Azonban csak azért, mert a Visual Studio automatikusan teszi ezeket a lépéseket, nem jelenti azt, hogy nem kell tudnia, mi folyik alatta a Dockerrel. Ezért az alábbi útmutató minden lépést részletez.

Az 1. lépés képe.

1. lépés Kódolás indítása és a kezdeti alkalmazás- vagy szolgáltatáskonfiguráció létrehozása

A Docker-alkalmazások fejlesztése hasonló ahhoz, ahogyan Docker nélkül fejleszt egy alkalmazást. A különbség az, hogy a Docker fejlesztése során üzembe helyezi és teszteli a Docker-tárolókban futó alkalmazást vagy szolgáltatásokat a helyi környezetben (a Docker által beállított Linux rendszerű virtuális gépeken vagy közvetlenül a Windowson, ha Windows-tárolókat használ).

A helyi környezet beállítása a Visual Studióval

Először győződjön meg arról, hogy telepítve van a WindowsHoz készült Docker Desktop, az alábbi utasításoknak megfelelően:

A WindowsHoz készült Docker Desktop használatának első lépései

Emellett a Visual Studio 2022-et vagy újabb verziót is telepítenie kell a .ASP.NET és a webfejlesztési számítási feladattal, ahogyan az 5–2. ábrán látható.

Képernyőkép a .NET Core platformfüggetlen fejlesztési kiválasztásáról.

5-2. ábra. A ASP.NET és a webfejlesztési számítási feladat kiválasztása a Visual Studio 2022 telepítése során

Az alkalmazás kódolását egyszerű .NET-ben is elkezdheti (általában a .NET Core-ban vagy később, ha tárolókat szeretne használni), mielőtt engedélyezi a Dockert az alkalmazásban, és üzembe helyezheti és tesztelheti a Dockerben. Javasoljuk azonban, hogy a lehető leghamarabb kezdjen el dolgozni a Dockeren, mert ez lesz a valós környezet, és a problémák a lehető leghamarabb felderíthetők. Ez azért ajánlott, mert a Visual Studio olyan egyszerűvé teszi a Docker használatát, hogy szinte transzparensnek érzi magát – ez a legjobb példa többtárolós alkalmazások Visual Studióból történő hibakeresésére.

További erőforrások

A 2. lépés képe.

Minden összeállítani kívánt egyéni rendszerképhez dockerfile szükséges; Az egyes tárolók üzembe helyezéséhez szükség van egy Dockerfile-ra is, akár automatikusan a Visual Studióból, akár manuálisan, a Docker parancssori felületének használatával (docker-run és docker-compose parancsok). Ha az alkalmazás egyetlen egyéni szolgáltatást tartalmaz, egyetlen Docker-fájlra van szüksége. Ha az alkalmazás több szolgáltatást tartalmaz (mint egy mikroszolgáltatás-architektúrában), minden szolgáltatáshoz egy Docker-fájl szükséges.

A Dockerfile az alkalmazás vagy szolgáltatás gyökérmappájába kerül. Ez tartalmazza azokat a parancsokat, amelyek közlik a Dockerrel, hogyan állíthatja be és futtathatja az alkalmazást vagy szolgáltatást egy tárolóban. Manuálisan létrehozhat egy Docker-fájlt a kódban, és hozzáadhatja a projekthez a .NET-függőségekkel együtt.

A Visual Studio és a Docker eszközei csak néhány kattintást igényelnek. Amikor új projektet hoz létre a Visual Studióban, az 5–3. ábrán látható módon megjelenik egy Docker-támogatás engedélyezése lehetőség.

Képernyőkép a Docker-támogatás engedélyezéséről jelölőnégyzetről.

5-3. ábra. A Docker támogatásának engedélyezése új ASP.NET Core-projekt létrehozásakor a Visual Studio 2022-ben

A Docker-támogatást egy meglévő ASP.NET Core-webalkalmazás-projekten is engedélyezheti, ha a jobb gombbal a projektre kattint a Megoldáskezelő, majd válassza a Docker-támogatás hozzáadása, ahogyan az 5–4. ábrán látható.

Képernyőkép a Docker-támogatás lehetőségről a Hozzáadás menüben.

5-4. ábra. Docker-támogatás engedélyezése meglévő Visual Studio 2022-projektben

Ez a művelet hozzáad egy Dockerfile-t a projekthez a szükséges konfigurációval, és csak ASP.NET Core-projekteken érhető el.

Hasonló módon a Visual Studio is hozzáadhat egy docker-compose.yml fájlt az egész megoldáshoz a Container Orchestrator támogatás hozzáadása > lehetőséggel. A 4. lépésben részletesebben ismertetjük ezt a lehetőséget.

Meglévő hivatalos .NET Docker-rendszerkép használata

A tárolóhoz általában egy olyan alaprendszerkép tetején készít egyéni rendszerképet, amely egy hivatalos adattárból, például a Docker Hub beállításjegyzékéből származik. Pontosan ez történik a borítók alatt, amikor engedélyezi a Docker támogatását a Visual Studióban. A Dockerfile egy meglévő dotnet/core/aspnet lemezképet fog használni.

Korábban már ismertettük, hogy mely Docker-rendszerképeket és -tárházakat használhatja a kiválasztott keretrendszertől és operációs rendszertől függően. Ha például ASP.NET Core-t (Linux vagy Windows) szeretne használni, a használni kívánt rendszerkép a mcr.microsoft.com/dotnet/aspnet:8.0. Ezért csak meg kell adnia, hogy milyen alapszintű Docker-rendszerképet fog használni a tárolóhoz. Ezt a Docker-fájlhoz való hozzáadással FROM mcr.microsoft.com/dotnet/aspnet:8.0 teheti meg. Ezt a Visual Studio automatikusan végrehajtja, de ha frissíteni szeretné a verziót, akkor ezt az értéket kell frissítenie.

A Docker Hub hivatalos .NET-rendszerkép-adattárának verziószámmal való használata biztosítja, hogy minden gépen (beleértve a fejlesztést, tesztelést és éles használatot) ugyanazokat a nyelvi funkciókat használják.

Az alábbi példában egy ASP.NET Core-tárolóhoz tartozó Dockerfile-minta látható.

FROM mcr.microsoft.com/dotnet/aspnet:8.0
ARG source
WORKDIR /app
EXPOSE 80
COPY ${source:-obj/Docker/publish} .
ENTRYPOINT ["dotnet", " MySingleContainerWebApp.dll "]

Ebben az esetben a rendszerkép a Hivatalos ASP.NET Core Docker-rendszerkép 8.0-s verzióján alapul (Linux és Windows esetén többíves). Ez a beállítás FROM mcr.microsoft.com/dotnet/aspnet:8.0. (Az alaprendszerképről további információt a ASP.NET Core Docker-rendszerkép oldalán talál.) A Dockerfile-ban arra is utasítania kell a Dockert, hogy figyelje meg a futtatókörnyezetben használni kívánt TCP-portot (ebben az esetben a 80-as portot, az EXPOSE beállítással konfigurálva).

A Dockerfile-ban a használt nyelvtől és keretrendszertől függően további konfigurációs beállításokat is megadhat. A ENTRYPOINT sor ["dotnet", "MySingleContainerWebApp.dll"] például arra utasítja a Dockert, hogy futtasson egy .NET-alkalmazást. Ha az SDK-t és a .NET CLI-t (dotnet CLI) használja a .NET-alkalmazás létrehozásához és futtatásához, ez a beállítás eltérő lesz. A lényeg az, hogy az ENTRYPOINT sor és más beállítások az alkalmazás által választott nyelvtől és platformtól függően eltérőek lesznek.

További erőforrások

Többíves rendszerképtárak használata

Egyetlen adattár tartalmazhat platformvariánsokat, például Linux-lemezképeket és Windows-lemezképeket. Ez a funkció lehetővé teszi az olyan gyártók számára, mint a Microsoft (alaprendszerkép-készítők) számára, hogy egyetlen adattárat hozzanak létre több platform (azaz Linux és Windows) lefedésére. A Docker Hub beállításjegyzékében elérhető .NET-adattár például ugyanazzal az adattárnévvel támogatja a Linuxot és a Windows Nano Servert.

Ha címkét ad meg, olyan platformot céloz meg, amely explicit, mint a következő esetekben:

  • mcr.microsoft.com/dotnet/aspnet:8.0-bullseye-slim
    Célok: .NET 8 futtatókörnyezet csak Linuxon

  • mcr.microsoft.com/dotnet/aspnet:8.0-nanoserver-ltsc2022
    Célok: .NET 8 futtatókörnyezet csak Windows Nano Serveren

Ha azonban ugyanazt a rendszerképnevet adja meg, még ugyanazzal a címkével is, a többíves rendszerképek (például a aspnet rendszerkép) a linuxos vagy a Windows-verziót fogják használni az üzembe helyezendő Docker-gazdagép operációs rendszerétől függően, ahogyan az alábbi példában látható:

  • mcr.microsoft.com/dotnet/aspnet:8.0
    Többíves: .NET 8 futtatókörnyezet csak Linuxon vagy Windows Nano Serveren a Docker gazdagép operációs rendszerétől függően

Így amikor lekér egy rendszerképet egy Windows-gazdagépről, az lekéri a Windows-változatot, és ugyanazt a rendszerképnevet lekéri egy Linux-gazdagépről.

Többfázisú buildek a Dockerfile-ban

A Dockerfile hasonló egy kötegelt szkripthez. Hasonló ahhoz, amit a parancssorból kell beállítania.

Egy alaprendszerképpel kezdődik, amely beállítja a kezdeti környezetet, olyan, mint az indítási fájlrendszer, amely a gazdagép operációs rendszerének tetején helyezkedik el. Ez nem operációs rendszer, de úgy gondolhatja, mint "a" operációs rendszer a tárolóban.

Minden parancssor végrehajtása új réteget hoz létre a fájlrendszeren az előző módosításaival, így kombinálva létrehozza az eredményként kapott fájlrendszert.

Mivel minden új réteg az előzőre "támaszkodik", és az eredményül kapott képméret minden paranccsal megnő, a képek nagyon nagyok lehetnek, ha például az alkalmazás létrehozásához és közzétételéhez szükséges SDK-t is tartalmazniuk kell.

Ez az a pont, ahol a többfázisú buildek bekerülnek a rajzba (a Docker 17.05-ös vagy újabb verziójából), hogy elvégezzék a varázslatukat.

Az alapötlet az, hogy a Dockerfile végrehajtási folyamatát szakaszokban különítheti el, ahol a szakasz egy kezdeti rendszerkép, amelyet egy vagy több parancs követ, és az utolsó szakasz határozza meg a végső kép méretét.

Röviden, a többfázisú buildek lehetővé teszik a létrehozás különböző "fázisokban" való felosztását, majd összeállítják a végső képet, amely csak a köztes szakaszok megfelelő könyvtárait készíti el. A funkció használatának általános stratégiája a következő:

  1. Használjon egy alapszintű SDK-lemezképet (nem számít, hogy mekkora méretű), az alkalmazás létrehozásához és egy mappában való közzétételéhez szükséges mindennel, majd

  2. Használjon egy alapszintű, kisméretű, futásidejű lemezképet, és másolja ki a közzétételi mappát az előző szakaszból egy kis végleges kép létrehozásához.

A többfázisú műveletek megértésének talán legjobb módja a Dockerfile részletes, sorról sorra történő végiglépése, ezért kezdjük a Visual Studio által létrehozott kezdeti Docker-fájllal, amikor Docker-támogatást ad hozzá egy projekthez, és később optimalizálásba kezdünk.

A kezdeti Dockerfile a következőképpen nézhet ki:

 1  FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
 2  WORKDIR /app
 3  EXPOSE 80
 4
 5  FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
 6  WORKDIR /src
 7  COPY src/Services/Catalog/Catalog.API/Catalog.API.csproj …
 8  COPY src/BuildingBlocks/HealthChecks/src/Microsoft.AspNetCore.HealthChecks …
 9  COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions.HealthChecks …
10  COPY src/BuildingBlocks/EventBus/IntegrationEventLogEF/ …
11  COPY src/BuildingBlocks/EventBus/EventBus/EventBus.csproj …
12  COPY src/BuildingBlocks/EventBus/EventBusRabbitMQ/EventBusRabbitMQ.csproj …
13  COPY src/BuildingBlocks/EventBus/EventBusServiceBus/EventBusServiceBus.csproj …
14  COPY src/BuildingBlocks/WebHostCustomization/WebHost.Customization …
15  COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
16  COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
17  RUN dotnet restore src/Services/Catalog/Catalog.API/Catalog.API.csproj
18  COPY . .
19  WORKDIR /src/src/Services/Catalog/Catalog.API
20  RUN dotnet build Catalog.API.csproj -c Release -o /app
21
22  FROM build AS publish
23  RUN dotnet publish Catalog.API.csproj -c Release -o /app
24
25  FROM base AS final
26  WORKDIR /app
27  COPY --from=publish /app .
28  ENTRYPOINT ["dotnet", "Catalog.API.dll"]

És ezek a részletek, sorról sorra:

  • 1. sor: Kezdjen egy szakaszt egy "kicsi" futásidejű alaprendszerképpel, és nevezd alapnak referenciaként.

  • 2. sor: Hozza létre az /app könyvtárat a képen.

  • 3. sor: A 80-as port elérhetővé tétele.

  • 5. sor: Kezdjen egy új szakaszt a "nagy" képpel az összeállításhoz/közzétételhez. Nevezd buildnek referenciaként.

  • 6. sor: Könyvtár /src létrehozása a képen.

  • 7. sor: A 16. sorig másolja a hivatkozott .csproj projektfájlokat, hogy később visszaállíthassa a csomagokat.

  • 17. sor: Csomagok visszaállítása a Catalog.API-projekthez és a hivatkozott projektekhez.

  • 18. sor: Másolja a megoldás összes könyvtárfáját (kivéve a .dockerignore fájlban található fájlokat/könyvtárakat) a kép /src könyvtárába.

  • 19. sor: Módosítsa az aktuális mappát a Catalog.API-projektre .

  • 20. sor: A projekt (és más projektfüggőségek) létrehozása és kimenete a kép /alkalmazás könyvtárába.

  • 22. sor: Kezdjen el egy új szakaszt folytatni a buildből. Hívja meg a közzétételre referenciaként.

  • 23. sor: A projekt (és függőségek) közzététele és kimenete a kép /alkalmazás könyvtárában.

  • 25. sor: Kezdjen el egy új szakaszt folytatni az alaptól, és nevezd véglegesnek.

  • 26. sor: Módosítsa az aktuális könyvtárat /appra.

  • 27. sor: Másolja az /app könyvtárat a szakasz közzétételéből az aktuális könyvtárba.

  • 28. sor: Adja meg a tároló indításakor futtatandó parancsot.

Most tekintsünk át néhány optimalizálást a teljes folyamat teljesítményének javítása érdekében, amelyek az eShopOnContainers esetében körülbelül 22 percet vagy többet jelentenek a teljes megoldás Linux-tárolókban való létrehozásához.

Kihasználhatja a Docker réteggyorsítótár-funkciójának előnyeit, ami meglehetősen egyszerű: ha az alaprendszerkép és a parancsok megegyeznek néhány korábban végrehajtottéval, akkor egyszerűen használhatja az eredményül kapott réteget anélkül, hogy végre kellene hajtania a parancsokat, így időt takaríthat meg.

Koncentráljunk tehát a buildelési fázisra, az 5-6. sorok többnyire azonosak, de a 7-17. sor az eShopOnContainers összes szolgáltatásához eltérő, ezért minden alkalommal végre kell hajtaniuk őket, azonban ha a 7-16. sorokat a következőre módosította:

COPY . .

Ezután minden szolgáltatás esetében ugyanaz lenne, az egész megoldást másolná, és egy nagyobb réteget hozna létre, de:

  1. A másolási folyamat csak az első alkalommal lesz végrehajtva (és a fájl módosítása esetén az újraépítéskor), és a gyorsítótárat minden más szolgáltatáshoz és

  2. Mivel a nagyobb kép köztes fázisban történik, nem befolyásolja a végső kép méretét.

A következő jelentős optimalizálás magában foglalja a restore 17. sorban végrehajtott parancsot, amely szintén különbözik az eShopOnContainers minden szolgáltatásához. Ha ezt a sort a következőre módosítja:

RUN dotnet restore

Visszaállítaná a csomagokat az egész megoldáshoz, de ismét csak egyszer, a jelenlegi stratégia 15-szöröse helyett.

Azonban csak akkor fut, dotnet restore ha egyetlen projekt vagy megoldásfájl található a mappában, ezért ennek elérése egy kicsit bonyolultabb, és a megoldás módja, anélkül, hogy túl sok részletbe belemenni, a következő:

  1. Adja hozzá a következő sorokat a .dockerignore fájlhoz:

    • *.sln, a fő mappafában lévő összes megoldásfájl figyelmen kívül hagyásához

    • !eShopOnContainers-ServicesAndWebApps.slnlehetőséget, hogy csak ezt a megoldásfájlt vegye fel.

  2. Adja hozzá az /ignoreprojectextensions:.dcproj argumentumot a következőhöz dotnet restore, így figyelmen kívül hagyja a docker-compose projektet is, és csak az eShopOnContainers-ServicesAndWebApps megoldás csomagjait állítja vissza.

A végső optimalizáláshoz egyszerűen előfordul, hogy a 20. sor redundáns, mivel a 23. sor is létrehozza az alkalmazást, és lényegében közvetlenül a 20. sor után jön, így egy másik időigényes parancsra kerül sor.

Az eredményként kapott fájl ezután a következő:

 1  FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
 2  WORKDIR /app
 3  EXPOSE 80
 4
 5  FROM mcr.microsoft.com/dotnet/sdk:8.0 AS publish
 6  WORKDIR /src
 7  COPY . .
 8  RUN dotnet restore /ignoreprojectextensions:.dcproj
 9  WORKDIR /src/src/Services/Catalog/Catalog.API
10  RUN dotnet publish Catalog.API.csproj -c Release -o /app
11
12  FROM base AS final
13  WORKDIR /app
14  COPY --from=publish /app .
15  ENTRYPOINT ["dotnet", "Catalog.API.dll"]

Az alaprendszerkép létrehozása az alapoktól

Létrehozhat saját Docker-alaprendszerképet az alapoktól. Ez a forgatókönyv nem ajánlott a Dockerrel kezdődő felhasználók számára, de ha a saját alaprendszerkép adott bitjeinek beállítására van szükség, ezt megteheti.

További erőforrások

A 3. lépés képe.

3. lépés Egyéni Docker-rendszerképek létrehozása és az alkalmazás vagy szolgáltatás beágyazása bennük

Az alkalmazás minden szolgáltatásához létre kell hoznia egy kapcsolódó rendszerképet. Ha az alkalmazás egyetlen szolgáltatásból vagy webalkalmazásból áll, csak egyetlen rendszerképre van szüksége.

Vegye figyelembe, hogy a Docker-rendszerképek automatikusan létrejönnek a Visual Studióban. A következő lépésekre csak a szerkesztői/parancssori felület munkafolyamatához van szükség, és az alatta lévő műveletek egyértelműségéhez kell magyarázni.

Fejlesztőként helyi fejlesztést és tesztelést kell végeznie, amíg le nem küld egy befejezett funkciót, vagy át nem vált a forrásvezérlő rendszerre (például a GitHubra). Ez azt jelenti, hogy létre kell hoznia a Docker-lemezképeket, és tárolókat kell üzembe helyeznie egy helyi Docker-gazdagépen (Windows vagy Linux rendszerű virtuális gépen), és futtatnia, tesztelnie és hibakeresést kell végeznie ezeken a helyi tárolókon.

Ha egyéni rendszerképet szeretne létrehozni a helyi környezetben a Docker CLI és a Dockerfile használatával, használhatja a Docker buildelési parancsát, ahogyan az 5–5. ábrán is látható.

Képernyőkép a docker buildelési parancs konzolkimenetéről.

5–5. ábra. Egyéni Docker-rendszerkép létrehozása

Ha nem közvetlenül a projektmappából futtatja a Docker-buildet, először létrehozhat egy üzembe helyezhető mappát a szükséges .NET-kódtárakkal és bináris fájlokkal dotnet publish, majd használhatja a docker build parancsot.

Ezzel létrehoz egy Docker-rendszerképet a névvel cesardl/netcore-webapi-microservice-docker:first. Ebben az esetben :first egy adott verziót képviselő címke. Ezt a lépést minden olyan egyéni lemezkép esetében megismételheti, amely a docker-alkalmazáshoz szükséges.

Ha egy alkalmazás több tárolóból (azaz többtárolós alkalmazásból) készül, a docker-compose up --build parancs használatával az összes kapcsolódó rendszerképet egyetlen paranccsal is létrehozhatja a kapcsolódó docker-compose.yml fájlokban közzétett metaadatok használatával.

A meglévő képeket a docker images paranccsal találja meg a helyi adattárban, ahogyan az 5–6. ábrán látható.

A konzol kimenete parancs docker-rendszerképekből, meglévő lemezképeket jelenítve meg.

5–6. ábra. Meglévő képek megtekintése a Docker-rendszerképek paranccsal

Docker-képek létrehozása a Visual Studióval

Ha a Visual Studióval hoz létre projektet Docker-támogatással, akkor nem hoz létre kifejezetten képet. Ehelyett a rendszerkép akkor jön létre, amikor az F5 (vagy Ctrl F5) billentyűkombinációt+lenyomva futtatja a dockerized alkalmazást vagy szolgáltatást. Ez a lépés automatikus a Visual Studióban, és nem fogja látni, de fontos, hogy tudja, mi történik alatta.

A választható 4. lépés képe.

4. lépés: Szolgáltatások definiálása docker-compose.yml többtárolós Docker-alkalmazás létrehozásakor

A docker-compose.yml fájl lehetővé teszi az üzembe helyezendő kapcsolódó szolgáltatások egy készletének meghatározását, amelyek üzembe helyezési parancsokkal rendelkező, összeállított alkalmazásként lesznek üzembe helyezve. Emellett a függőségi kapcsolatokat és a futtatókörnyezet konfigurációját is konfigurálja.

Ha docker-compose.yml fájlt szeretne használni, létre kell hoznia a fájlt a fő vagy a gyökérmegoldás mappájában az alábbi példához hasonló tartalommal:

version: '3.4'

services:

  webmvc:
    image: eshop/web
    environment:
      - CatalogUrl=http://catalog-api
      - OrderingUrl=http://ordering-api
    ports:
      - "80:80"
    depends_on:
      - catalog-api
      - ordering-api

  catalog-api:
    image: eshop/catalog-api
    environment:
      - ConnectionString=Server=sqldata;Port=1433;Database=CatalogDB;…
    ports:
      - "81:80"
    depends_on:
      - sqldata

  ordering-api:
    image: eshop/ordering-api
    environment:
      - ConnectionString=Server=sqldata;Database=OrderingDb;…
    ports:
      - "82:80"
    extra_hosts:
      - "CESARDLBOOKVHD:10.0.75.1"
    depends_on:
      - sqldata

  sqldata:
    image: mcr.microsoft.com/mssql/server:latest
    environment:
      - SA_PASSWORD=[PLACEHOLDER]
      - ACCEPT_EULA=Y
    ports:
      - "5433:1433"

Fontos

A Microsoft azt javasolja, hogy a legbiztonságosabb hitelesítési folyamatot használja. Ha azure SQL-hez csatlakozik, az Azure-erőforrások felügyelt identitásai az ajánlott hitelesítési módszer.

Ez a docker-compose.yml fájl egy egyszerűsített és egyesített verzió. Statikus konfigurációs adatokat tartalmaz minden tárolóhoz (például az egyéni rendszerkép nevéhez), amely mindig szükséges, és olyan konfigurációs információkat, amelyek az üzembe helyezési környezettől függhetnek, például a kapcsolati sztring. A későbbi szakaszokban megtudhatja, hogyan oszthatja fel a docker-compose.yml konfigurációt több docker-compose fájlra, és hogyan bírálhatja felül az értékeket a környezettől és a végrehajtás típusától függően (hibakeresés vagy kiadás).

A docker-compose.yml példafájl négy szolgáltatást határoz meg: a webmvc szolgáltatást (egy webalkalmazást), két mikroszolgáltatást (ordering-api és ) és basket-apiegy adatforrástárolót, sqldataamely a tárolóként futó SQL Serveren alapul. Minden szolgáltatás tárolóként lesz üzembe helyezve, ezért mindegyikhez Docker-rendszerképre van szükség.

A docker-compose.yml fájl nem csak a használt tárolókat határozza meg, hanem az egyes tárolók egyéni konfigurálását is. A tárolódefiníció például webmvc a .yml fájlban:

  • Előre elkészített eshop/web:latest rendszerképet használ. A rendszerképet azonban úgy is konfigurálhatja, hogy a docker-compose végrehajtás részeként készüljön el egy további konfigurációval, amely a docker-compose fájl egy szakaszán alapul.

  • Inicializál két környezeti változót (CatalogUrl és OrderingUrl).

  • Továbbítja a tárolón lévő 80-at a gazdagép külső 80-ai portjára.

  • A webalkalmazást a katalógushoz és a rendelési szolgáltatáshoz csatolja a depends_on beállítással. Ez azt eredményezi, hogy a szolgáltatás megvárja a szolgáltatások indítását.

A docker-compose.yml fájlt egy későbbi szakaszban fogjuk újra áttekinteni, amikor bemutatjuk, hogyan implementálhat mikroszolgáltatásokat és többtárolós alkalmazásokat.

Docker-compose.yml használata a Visual Studióban

Amellett, hogy egy Dockerfile-t ad hozzá egy projekthez, ahogy korábban már említettük, a Visual Studio 2017 (a 15.8-as verzióból) vezénylői támogatást adhat a Docker Compose-hoz egy megoldáshoz.

Amikor első alkalommal ad hozzá tárolóvezénylői támogatást az 5–7. ábrán látható módon, a Visual Studio létrehozza a dockerfile-t a projekthez, és létrehoz egy új (szolgáltatásszakaszos) projektet a megoldásban több globális docker-compose*.yml fájllal, majd hozzáadja a projektet ezekhez a fájlokhoz. Ezután megnyithatja a docker-compose.yml fájlokat, és további funkciókkal frissítheti őket.

Ismételje meg ezt a műveletet az docker-compose.yml fájlba felvenni kívánt összes projektnél.

Az írás idején a Visual Studio támogatja a Docker Compose vezénylőit.

Képernyőkép a Container Orchestrator támogatási lehetőségről a projekt helyi menüjében.

5-7. ábra. Docker-támogatás hozzáadása a Visual Studio 2022-ben egy ASP.NET Core-projekt jobb gombbal történő kattintásával

Miután a Visual Studióban hozzáadta a vezénylői támogatást a megoldáshoz, egy új csomópont (a docker-compose.dcproj projektfájlban) is megjelenik a Megoldáskezelő, amely tartalmazza a hozzáadott docker-compose.yml fájlokat, ahogyan az 5–8. ábrán látható.

Képernyőkép a docker-compose csomópontról Megoldáskezelő.

5-8. ábra. A Visual Studio 2022-ben hozzáadott docker-compose facsomópont Megoldáskezelő

A parancs használatával többtárolós alkalmazást helyezhet üzembe egyetlen docker-compose.yml fájllal docker-compose up . A Visual Studio azonban hozzáad egy csoportot, így felülbírálhatja az értékeket a környezettől (fejlesztés vagy éles környezet) és a végrehajtás típusától (kiadás vagy hibakeresés) függően. Ezt a képességet a későbbi szakaszokban ismertetjük.

Az 5. lépés képe.

5. lépés A Docker-alkalmazás létrehozása és futtatása

Ha az alkalmazás csak egyetlen tárolóval rendelkezik, futtathatja a Docker-gazdagépre (virtuális gépre vagy fizikai kiszolgálóra) való üzembe helyezéssel. Ha azonban az alkalmazás több szolgáltatást is tartalmaz, üzembe helyezheti azt önálló alkalmazásként, egyetlen CLI-paranccsal (docker-compose up)vagy a Visual Studióval, amely ezt a parancsot fogja használni a borítók alatt). Nézzük meg a különböző lehetőségeket.

A lehetőség: Egytárolós alkalmazás futtatása

A Docker parancssori felületének használata

Docker-tárolót futtathat a docker run paranccsal, ahogyan az 5–9. ábrán látható:

docker run -t -d -p 80:5000 cesardl/netcore-webapi-microservice-docker:first

A fenti parancs minden futtatáskor létrehoz egy új tárolópéldányt a megadott rendszerképből. A paraméterrel --name nevet adhat a tárolónak, majd docker start {name} használhatja (vagy használhatja a tárolóazonosítót vagy az automatikus nevet) egy meglévő tárolópéldány futtatásához.

Docker-tárolót a docker-futtatási paranccsal futtató képernyőkép.

5-9. ábra. Docker-tároló futtatása a Docker-futtatási paranccsal

Ebben az esetben a parancs a tároló 5000 belső portját a gazdagép 80-ai portjához köti. Ez azt jelenti, hogy a gazdagép figyeli a 80-at, és a tároló 5000-s portjára továbbítja.

A megjelenített kivonat a tárolóazonosító, és véletlenszerűen olvasható nevet is hozzárendel, ha a --name beállítás nincs használatban.

A Visual Studio használata

Ha még nem adott hozzá tárolóvezénylői támogatást, egyetlen tárolóalkalmazást is futtathat a Visual Studióban a Ctrl F5+, és az F5 használatával is hibakeresést végezhet az alkalmazáson belül. A tároló helyileg fut a Docker-futtatás használatával.

B lehetőség: Többtárolós alkalmazás futtatása

A legtöbb vállalati forgatókönyvben a Docker-alkalmazások több szolgáltatásból állnak, ami azt jelenti, hogy többtárolós alkalmazást kell futtatnia az 5–10. ábrán látható módon.

Több Docker-tárolóval rendelkező virtuális gép

5–10. ábra. Üzembe helyezett Docker-tárolókkal rendelkező virtuális gép

A Docker parancssori felületének használata

Ha többtárolós alkalmazást szeretne futtatni a Docker parancssori felületével, használja a docker-compose up parancsot. Ez a parancs a megoldás szintjén található docker-compose.yml fájlt használja egy többtárolós alkalmazás üzembe helyezéséhez. Az 5–11. ábra a docker-compose.yml fájlt tartalmazó fő megoldáskönyvtárból futtatott parancs eredményeit mutatja.

Képernyőnézet a docker-compose up parancs futtatásakor

5–11. ábra. Példaeredmények a docker-compose up parancs futtatásakor

A docker-compose up parancs futtatása után az alkalmazás és a kapcsolódó tárolók üzembe lesznek helyezve a Docker-gazdagépen az 5–10. ábrán látható módon.

A Visual Studio használata

A többtárolós alkalmazások Visual Studio 2019 használatával történő futtatása nem lehet egyszerűbb. A Ctrl F5 billentyűkombinációtfuttathatja az F5+a szokásos módon hibakeresést végezhet a docker-compose projekt indítási projektként való beállításához. A Visual Studio kezeli az összes szükséges beállítást, így a szokásos módon hozhat létre töréspontokat, és hibakeresést végezhet a "távoli kiszolgálókon" futó független folyamatokban, és a hibakereső már csatlakoztatva van.

Ahogy korábban említettük, minden alkalommal, amikor Docker-megoldástámogatást ad hozzá egy megoldáson belüli projekthez, a projekt a globális (megoldásszintű) docker-compose.yml fájlban van konfigurálva, amely lehetővé teszi a teljes megoldás egyszerre történő futtatását vagy hibakeresését. A Visual Studio minden olyan projekthez elindít egy tárolót, amelyben engedélyezve van a Docker-megoldás támogatása, és végrehajtja az összes belső lépést (dotnet publish, docker build stb.).

Ha szeretné áttekinteni az összes drudgery-t, tekintse meg a fájlt:

{root solution folder}\obj\Docker\docker-compose.vs.debug.g.yml

A lényeg itt az, hogy az 5–12. ábrán látható módon a Visual Studio 2019-ben egy további Docker-parancs is elérhető az F5 billentyűművelethez. Ez a beállítás lehetővé teszi többtárolós alkalmazások futtatását vagy hibakeresését az docker-compose.yml fájlokban definiált összes tároló megoldásszinten való futtatásával. A többtárolós megoldások hibakeresésének lehetősége azt jelenti, hogy több töréspontot állíthat be, mindegyik töréspontot egy másik projektben (tárolóban), és a Visual Studióban végzett hibakeresés során a különböző projektekben definiált és különböző tárolókon futó töréspontoknál fog leállni.

Képernyőkép a docker-compose projektet futtató hibakeresési eszköztárról.

5–12. ábra. Többtárolós alkalmazások futtatása a Visual Studio 2022-ben

További erőforrások

Megjegyzés a vezénylőkkel való tesztelésről és üzembe helyezésről

A docker-compose up and docker run parancsok (vagy a Tárolók futtatása és hibakeresése a Visual Studióban) megfelelőek a tárolók teszteléséhez a fejlesztési környezetben. Ez a megközelítés azonban nem használható éles környezetekhez, ahol olyan vezénylőket kell megcéloznia, mint a Kubernetes vagy a Service Fabric. Ha Kubernetes-t használ, podokkal kell rendszereznie a tárolókat és a szolgáltatásokat a hálózatukba. Az üzembe helyezésekkel rendszerezheti a podok létrehozását és módosítását.

A 6. lépés képe.

6. lépés Docker-alkalmazás tesztelése a helyi Docker-gazdagép használatával

Ez a lépés attól függően változik, hogy az alkalmazás mit csinál. Egyetlen tárolóként vagy szolgáltatásként üzembe helyezett egyszerű .NET-webalkalmazásban a docker-gazdagép böngészőjének megnyitásával és a webhelyre való navigálással érheti el a szolgáltatást az 5–13. ábrán látható módon. (Ha a Dockerfile konfigurációja leképezi a tárolót a gazdagép egy olyan portjára, amely nem 80, vegye fel a gazdagépportot az URL-címre.)

Képernyőkép a localhost/API/values válaszáról.

5–13. ábra. Példa a Docker-alkalmazás helyi tesztelésére a localhost használatával

Ha a localhost nem a Docker-gazdagép IP-címére mutat (alapértelmezés szerint a Docker CE használatakor azt kell használnia), a szolgáltatáshoz való navigáláshoz használja a számítógép hálózati kártyájának IP-címét.

Ez az URL-cím a böngészőben a 80-as portot használja a tárgyalt tároló példájához. A rendszer azonban belsőleg átirányítja a kéréseket az 5000-as portra, mert így lett üzembe helyezve a Docker-futtatási paranccsal, amint azt az előző lépésben ismertette.

Az alkalmazást a terminál curl használatával is tesztelheti az 5–14. ábrán látható módon. Windows rendszerű Docker-telepítés esetén az alapértelmezett Docker-gazdagép IP-címe mindig 10.0.75.1 a gép tényleges IP-címe mellett.

A konzol kimenete a http://10.0.75.1/API/values curl lekéréséből.

5–14. ábra. Példa a Docker-alkalmazás helyi tesztelésére a curl használatával

Tárolók tesztelése és hibakeresése a Visual Studióval

A tárolók Visual Studióval való futtatásakor és hibakeresésekor a .NET-alkalmazás ugyanúgy hibakeresést végezhet, mint a tárolók nélküli futtatáskor.

Tesztelés és hibakeresés a Visual Studio nélkül

Ha a szerkesztő/parancssori felület megközelítésével fejleszt, a tárolók hibakeresése nehezebb, és valószínűleg nyomkövetések létrehozásával szeretne hibakeresést végezni.

További erőforrások

Egyszerűsített munkafolyamat tárolók fejlesztésekor a Visual Studióval

A Visual Studio használata esetén a munkafolyamat hatékonyan egyszerűbb, mint a szerkesztő/parancssori felület megközelítése. A Docker által a Docker-fájlokkal és docker-compose.yml fájlokkal kapcsolatos lépések többsége rejtett vagy leegyszerűsített a Visual Studio által, ahogyan az 5–15. ábrán látható.

Az alkalmazás létrehozásához szükséges öt egyszerűsített lépést bemutató ábra.

5–15. ábra. Egyszerűsített munkafolyamat a Visual Studióval való fejlesztéskor

Emellett csak egyszer kell elvégeznie a 2. lépést (Docker-támogatás hozzáadása a projektekhez). Ezért a munkafolyamat hasonló a szokásos fejlesztési feladatokhoz, amikor a .NET-et bármilyen más fejlesztéshez használja. Tudnia kell, hogy mi folyik a borítók alatt (a képkészítési folyamat, a használt alaplemezképek, a tárolók üzembe helyezése stb.), és néha a Dockerfile-t vagy docker-compose.yml fájlt is módosítania kell a viselkedés testreszabásához. A legtöbb munkát azonban jelentősen leegyszerűsíti a Visual Studio használata, így sokkal hatékonyabb lesz.

PowerShell-parancsok használata Docker-fájlban a Windows-tárolók beállításához

A Windows-tárolók lehetővé teszik, hogy meglévő Windows-alkalmazásait Docker-rendszerképekké konvertálja, és ugyanazokat az eszközöket használja, mint a Docker-ökoszisztéma többi része. A Windows-tárolók használatához PowerShell-parancsokat kell futtatnia a Dockerfile-ban, az alábbi példában látható módon:

FROM mcr.microsoft.com/windows/servercore
LABEL Description="IIS" Vendor="Microsoft" Version="10"
RUN powershell -Command Add-WindowsFeature Web-Server
CMD [ "ping", "localhost", "-t" ]

Ebben az esetben Egy Windows Server Core alaprendszerképet (a FROM beállítást) használunk, és az IIS-t egy PowerShell-paranccsal (a RUN beállítással) telepítjük. Hasonló módon a PowerShell-parancsokkal további összetevőket is beállíthat, például ASP.NET 4.x, .NET-keretrendszer 4.6 vagy bármely más Windows-szoftver. Egy Dockerfile következő parancsa például a 4.5-ös ASP.NET állítja be:

RUN powershell add-windowsfeature web-asp-net45

További erőforrások

Előzőkövetkező

  • Last updated on