Delen via

Ontwikkelwerkstroom voor Docker-apps

Aanbeveling

Deze inhoud is een fragment uit het eBook, .NET Microservices Architecture for Containerized .NET Applications, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.

PDF downloaden

.NET Microservices Architectuur voor Gecontaineriseerde .NET Toepassingen eBook omslagthumbnail.

De levenscyclus van de ontwikkeling van toepassingen begint bij uw computer, als ontwikkelaar, waar u de toepassing codeert met behulp van uw voorkeurstaal en deze lokaal test. Met deze werkstroom, ongeacht welke taal, framework en platform u kiest, ontwikkelt en test u altijd Docker-containers, maar dat doet u lokaal.

Elke container (een exemplaar van een Docker-installatiekopieën) bevat de volgende onderdelen:

  • Een besturingssysteemselectie, bijvoorbeeld een Linux-distributie, Windows Nano Server of Windows Server Core.
  • Bestanden die zijn toegevoegd tijdens de ontwikkeling, bijvoorbeeld binaire broncode- en toepassingsbestanden.
  • Configuratie-informatie, zoals omgevingsinstellingen en afhankelijkheden.

Werkstroom voor het ontwikkelen van Docker-toepassingen op basis van containers

In deze sectie wordt de interne-lusontwikkelingswerkstroom voor docker-toepassingen op basis van containers beschreven. De interne-luswerkstroom betekent dat deze niet de bredere DevOps-werkstroom overweegt, die maximaal productie-implementatie kan bevatten en zich alleen richt op het ontwikkelwerk dat op de computer van de ontwikkelaar wordt uitgevoerd. De eerste stappen voor het instellen van de omgeving zijn niet opgenomen, omdat deze stappen slechts één keer worden uitgevoerd.

Een toepassing bestaat uit uw eigen services plus aanvullende bibliotheken (afhankelijkheden). Hier volgen de basisstappen die u meestal uitvoert bij het bouwen van een Docker-toepassing, zoals geïllustreerd in afbeelding 5-1.

Diagram met de zeven stappen die nodig zijn om een container-app te maken.

Afbeelding 5-1. Stapsgewijze werkstroom voor het ontwikkelen van docker-apps in containers

In deze sectie wordt dit hele proces gedetailleerd beschreven en wordt elke belangrijke stap uitgelegd door te focussen op een Visual Studio-omgeving.

Wanneer u een editor-/CLI-ontwikkelbenadering gebruikt (bijvoorbeeld Visual Studio Code plus Docker CLI in macOS of Windows), moet u elke stap kennen, meestal in meer detail dan wanneer u Visual Studio gebruikt. Zie voor meer informatie over het werken in een CLI-omgeving de levenscyclus van een Containerized Docker-toepassing met Microsoft Platformen en Hulpprogramma's.

Wanneer u Visual Studio 2022 of hoger gebruikt, worden veel van deze stappen voor u verwerkt, waardoor uw productiviteit aanzienlijk wordt verbeterd. Dit geldt met name wanneer u zich richt op toepassingen met meerdere containers. Met slechts één muisklik voegt Visual Studio bijvoorbeeld het Dockerfile en docker-compose.yml bestand toe aan uw projecten met de configuratie voor uw toepassing. Wanneer u de toepassing uitvoert in Visual Studio, wordt de Docker-installatiekopieën gebouwd en wordt de toepassing met meerdere containers rechtstreeks in Docker uitgevoerd; Hiermee kunt u zelfs in één keer fouten opsporen in verschillende containers. Deze functies zullen uw ontwikkelsnelheid verhogen.

Omdat Visual Studio deze stappen echter automatisch maakt, betekent dit niet dat u niet hoeft te weten wat er aan de hand is met Docker. Daarom worden elke stap in de volgende richtlijnen beschreven.

Afbeelding voor stap 1.

Stap 1. Beginnen met coderen en uw eerste toepassing of servicebasislijn maken

Het ontwikkelen van een Docker-toepassing is vergelijkbaar met de manier waarop u een toepassing ontwikkelt zonder Docker. Het verschil is dat u tijdens het ontwikkelen voor Docker uw toepassing of services die worden uitgevoerd in Docker-containers in uw lokale omgeving implementeert en test (een linux-VM-installatie door Docker of rechtstreeks windows als u Windows-containers gebruikt).

Uw lokale omgeving instellen met Visual Studio

Controleer eerst of Docker Desktop voor Windows voor Windows is geïnstalleerd, zoals wordt uitgelegd in de volgende instructies:

Aan de slag met Docker Desktop voor Windows

Bovendien hebt u Visual Studio 2022 of hoger nodig waarop de workload .ASP.NET en webontwikkeling is geïnstalleerd, zoals wordt weergegeven in afbeelding 5-2.

Schermopname van de platformoverschrijdende ontwikkelselectie van .NET Core.

Afbeelding 5-2. De workload voor ASP.NET en webontwikkeling selecteren tijdens de installatie van Visual Studio 2022

U kunt beginnen met het coderen van uw toepassing in gewone .NET (meestal in .NET Core of hoger als u van plan bent containers te gebruiken), zelfs voordat u Docker inschakelt in uw toepassing en docker implementeert en test in Docker. Het wordt echter aanbevolen om zo snel mogelijk aan Docker te werken, omdat dat de echte omgeving is en eventuele problemen zo snel mogelijk kunnen worden gedetecteerd. Dit wordt aangemoedigd omdat Visual Studio het zo eenvoudig maakt om met Docker te werken dat het bijna transparant is, het beste voorbeeld bij het opsporen van fouten in toepassingen met meerdere containers vanuit Visual Studio.

Aanvullende bronnen

Afbeelding voor stap 2.

U hebt een Dockerfile nodig voor elke aangepaste installatiekopieën die u wilt bouwen; U hebt ook een Dockerfile nodig voor elke container die moet worden geïmplementeerd, ongeacht of u automatisch implementeert vanuit Visual Studio of handmatig met behulp van de Docker CLI (docker-run- en docker-compose-opdrachten). Als uw toepassing één aangepaste service bevat, hebt u één Dockerfile nodig. Als uw toepassing meerdere services bevat (zoals in een microservicesarchitectuur), hebt u één Dockerfile nodig voor elke service.

Het Dockerfile wordt in de hoofdmap van uw toepassing of service geplaatst. Het bevat de opdrachten die Docker vertellen hoe u uw toepassing of service in een container instelt en uitvoert. U kunt handmatig een Dockerfile in code maken en toevoegen aan uw project, samen met uw .NET-afhankelijkheden.

Voor Visual Studio en de bijbehorende hulpprogramma's voor Docker hebt u slechts enkele muisklikken nodig. Wanneer u een nieuw project maakt in Visual Studio, is er een optie met de naam Docker-ondersteuning inschakelen, zoals wordt weergegeven in afbeelding 5-3.

Schermopname van het selectievakje Docker-ondersteuning inschakelen.

Afbeelding 5-3. Docker-ondersteuning inschakelen bij het maken van een nieuw ASP.NET Core-project in Visual Studio 2022

U kunt docker-ondersteuning ook inschakelen voor een bestaand ASP.NET Core-web-app-project door met de rechtermuisknop op het project in Solution Explorer te klikken en Docker-ondersteuning toevoegen, zoals wordt weergegeven in afbeelding 5-4.

Schermopname van de optie Docker-ondersteuning in het menu Toevoegen.

Afbeelding 5-4. Docker-ondersteuning inschakelen in een bestaand Visual Studio 2022-project

Met deze actie wordt een Dockerfile aan het project toegevoegd met de vereiste configuratie en is deze alleen beschikbaar voor ASP.NET Core-projecten.

Op vergelijkbare wijze kan Visual Studio ook een docker-compose.yml bestand voor de hele oplossing toevoegen met de optie Container Orchestrator-ondersteuning toevoegen > .... In stap 4 verkennen we deze optie in meer detail.

Een bestaande officiële .NET Docker-installatiekopieën gebruiken

Meestal bouwt u een aangepaste installatiekopieën voor uw container op basisinstallatiekopieën die u krijgt van een officiële opslagplaats, zoals het Docker Hub-register . Dat is precies wat er onder de dekking gebeurt wanneer u Docker-ondersteuning inschakelt in Visual Studio. Uw Dockerfile gebruikt een bestaande dotnet/core/aspnet installatiekopieën.

Eerder hebben we uitgelegd welke Docker-installatiekopieën en opslagplaatsen u kunt gebruiken, afhankelijk van het framework en het besturingssysteem dat u hebt gekozen. Als u bijvoorbeeld ASP.NET Core (Linux of Windows) wilt gebruiken, is mcr.microsoft.com/dotnet/aspnet:8.0de installatiekopieën die u wilt gebruiken. Daarom hoeft u alleen op te geven welke Docker-basisinstallatiekopieën u voor uw container gaat gebruiken. U doet dit door deze toe te voegen aan FROM mcr.microsoft.com/dotnet/aspnet:8.0 uw Dockerfile. Dit wordt automatisch uitgevoerd door Visual Studio, maar als u de versie wilt bijwerken, werkt u deze waarde bij.

Het gebruik van een officiële .NET-installatiekopieënopslagplaats vanuit Docker Hub met een versienummer zorgt ervoor dat dezelfde taalfuncties beschikbaar zijn op alle computers (inclusief ontwikkeling, testen en productie).

In het volgende voorbeeld ziet u een Dockerfile-voorbeeld voor een ASP.NET Core-container.

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

In dit geval is de installatiekopieën gebaseerd op versie 8.0 van de officiële ASP.NET Core Docker-installatiekopieën (multi-arch voor Linux en Windows). Dit is de instelling FROM mcr.microsoft.com/dotnet/aspnet:8.0. (Zie de pagina ASP.NET Core Docker-installatiekopieën voor meer informatie over deze basisinstallatiekopieën.) In het Dockerfile moet u docker ook instrueren om te luisteren op de TCP-poort die u tijdens runtime gebruikt (in dit geval poort 80, zoals geconfigureerd met de instelling EXPOSE).

U kunt aanvullende configuratie-instellingen opgeven in het Dockerfile, afhankelijk van de taal en het framework dat u gebruikt. De ENTRYPOINT-regel met ["dotnet", "MySingleContainerWebApp.dll"] geeft Docker bijvoorbeeld opdracht om een .NET-toepassing uit te voeren. Als u de SDK en de .NET CLI (dotnet CLI) gebruikt om de .NET-toepassing te bouwen en uit te voeren, is deze instelling anders. De onderste regel is dat de ENTRYPOINT-regel en andere instellingen verschillen, afhankelijk van de taal en het platform dat u voor uw toepassing kiest.

Aanvullende bronnen

Opslagplaatsen met meerdere arch-installatiekopieën gebruiken

Eén opslagplaats kan platformvarianten bevatten, zoals een Linux-installatiekopieën en een Windows-installatiekopieën. Met deze functie kunnen leveranciers zoals Microsoft (makers van basisinstallatiekopieën) één opslagplaats maken voor meerdere platforms (dat wil gezegd Linux en Windows). De .NET-opslagplaats die beschikbaar is in het Docker Hub-register biedt bijvoorbeeld ondersteuning voor Linux en Windows Nano Server met dezelfde opslagplaatsnaam.

Als u een tag opgeeft, richt u zich op een platform dat expliciet is zoals in de volgende gevallen:

  • mcr.microsoft.com/dotnet/aspnet:8.0-bullseye-slim
    Doelen: alleen .NET 8 runtime op Linux

  • mcr.microsoft.com/dotnet/aspnet:8.0-nanoserver-ltsc2022
    Doelen: .NET 8 runtime alleen op Windows Nano Server

Maar als u dezelfde installatiekopienaam opgeeft, zelfs met dezelfde tag, gebruiken de installatiekopieën met meerdere boog (zoals de aspnet installatiekopie) de Linux- of Windows-versie, afhankelijk van het Docker-hostbesturingssysteem dat u implementeert, zoals wordt weergegeven in het volgende voorbeeld:

  • mcr.microsoft.com/dotnet/aspnet:8.0
    Multi-arch: .NET 8 runtime-only op Linux of Windows Nano Server, afhankelijk van het Docker-hostbesturingssysteem

Op deze manier haalt u, wanneer u een installatiekopie ophaalt van een Windows-host, de Windows-variant op en haalt u dezelfde installatiekopienaam op van een Linux-host.

Builds met meerdere fasen in Dockerfile

Het Dockerfile is vergelijkbaar met een batchscript. Vergelijkbaar met wat u zou doen als u de computer vanaf de opdrachtregel moest instellen.

Het begint met een basisinstallatiekopie waarmee de eerste context wordt ingesteld, net als het opstartbestandssysteem dat zich boven op het host-besturingssysteem bevindt. Het is geen besturingssysteem, maar u kunt het zien als 'het' besturingssysteem in de container.

De uitvoering van elke opdrachtregel maakt een nieuwe laag op het bestandssysteem met de wijzigingen uit de vorige, zodat, wanneer deze worden gecombineerd, het resulterende bestandssysteem produceert.

Omdat elke nieuwe laag boven op de vorige laag wordt geplaatst en de resulterende afbeeldingsgrootte toeneemt met elke opdracht, kunnen installatiekopieën zeer groot worden als ze bijvoorbeeld de SDK moeten opnemen die nodig is om een toepassing te bouwen en te publiceren.

Dit is waar builds met meerdere fasen in de plot komen (van Docker 17.05 en hoger) om hun magie uit te voeren.

Het belangrijkste idee is dat u het dockerfile-uitvoeringsproces in fasen kunt scheiden, waarbij een fase een eerste installatiekopieën is, gevolgd door een of meer opdrachten, en de laatste fase bepaalt de uiteindelijke grootte van de installatiekopieën.

Kortom, builds met meerdere fasen maken het maken in verschillende fasen splitsen en vervolgens de uiteindelijke installatiekopie samenstellen die alleen de relevante directory's uit de tussenliggende fasen maakt. De algemene strategie voor het gebruik van deze functie is:

  1. Gebruik een basis-SDK-installatiekopieën (maakt niet uit hoe groot) met alles wat nodig is om de toepassing te bouwen en te publiceren naar een map en vervolgens

  2. Gebruik een basisinstallatiekopie, een kleine, alleen runtime-installatiekopie en kopieer de publicatiemap uit de vorige fase om een kleine uiteindelijke installatiekopie te produceren.

Waarschijnlijk de beste manier om meer inzicht te krijgen in een Dockerfile in detail, regel per regel, dus laten we beginnen met het eerste Dockerfile dat door Visual Studio is gemaakt bij het toevoegen van Docker-ondersteuning aan een project en later enkele optimalisaties krijgt.

Het eerste Dockerfile ziet er ongeveer als volgt uit:

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

En dit zijn de details, regel per regel:

  • Regel 1: Begin een fase met een 'kleine' basisinstallatiekopie die alleen voor runtime wordt gebruikt, en noem deze basis ter referentie.

  • Regel 2: Maak de map /app in de afbeelding.

  • Regel 3: Poort 80 beschikbaar maken.

  • Regel 5: Begin een nieuwe fase met de 'grote' installatiekopie voor het bouwen/publiceren. Noem deze build ter referentie.

  • Regel 6: Map /src maken in de afbeelding.

  • Regel 7: Tot regel 16 kopieert u naar .csproj-projectbestanden waarnaar wordt verwezen om later pakketten te kunnen herstellen.

  • Regel 17: Pakketten herstellen voor het project Catalog.API en de projecten waarnaar wordt verwezen.

  • Regel 18: Kopieer alle mapstructuur voor de oplossing (behalve de bestanden/mappen die zijn opgenomen in het .dockerignore-bestand ) naar de map /src in de installatiekopie.

  • Regel 19: Wijzig de huidige map in het project Catalog.API .

  • Regel 20: Bouw het project (en andere projectafhankelijkheden) en uitvoer naar de map /app in de afbeelding.

  • Regel 22: Begin een nieuwe fase die wordt voortgezet vanuit de build. Noem het publiceren ter referentie.

  • Regel 23: Publiceer het project (en afhankelijkheden) en uitvoer naar de map /app in de afbeelding.

  • Regel 25: Begin een nieuwe fase die vanaf de basis wordt voortgezet en noem deze definitief.

  • Regel 26: Wijzig de huidige map in /app.

  • Regel 27: Kopieer de map /app vanuit het stadium publiceren naar de huidige map.

  • Regel 28: Definieer de opdracht die moet worden uitgevoerd wanneer de container wordt gestart.

Laten we nu enkele optimalisaties verkennen om de volledige procesprestaties te verbeteren die, in het geval van eShopOnContainers, ongeveer 22 minuten of meer betekent om de volledige oplossing in Linux-containers te bouwen.

U profiteert van de cachefunctie van Docker, wat vrij eenvoudig is: als de basisinstallatiekopieën en de opdrachten hetzelfde zijn als sommige eerder uitgevoerde opdrachten, kan deze gewoon de resulterende laag gebruiken zonder dat u de opdrachten hoeft uit te voeren, waardoor u enige tijd bespaart.

Laten we ons richten op de buildfase , regels 5-6 zijn meestal hetzelfde, maar regels 7-17 verschillen voor elke service van eShopOnContainers, dus ze moeten elke keer worden uitgevoerd, maar als u regels 7-16 wijzigt in:

COPY . .

Dan zou het voor elke service hetzelfde zijn, zou het de hele oplossing kopiëren en een grotere laag maken, maar:

  1. Het kopieerproces wordt alleen de eerste keer uitgevoerd (en bij het opnieuw opbouwen als een bestand wordt gewijzigd) en wordt de cache gebruikt voor alle andere services en

  2. Omdat de grotere afbeelding plaatsvindt in een tussenliggende fase, heeft dit geen invloed op de uiteindelijke afbeeldingsgrootte.

De volgende significante optimalisatie omvat de restore opdracht die wordt uitgevoerd in regel 17, wat ook verschilt voor elke service van eShopOnContainers. Als u deze regel wijzigt in alleen:

RUN dotnet restore

Het zou de pakketten voor de hele oplossing herstellen, maar vervolgens opnieuw zou het slechts één keer doen, in plaats van de 15 keer met de huidige strategie.

dotnet restore Wordt echter alleen uitgevoerd als er één project- of oplossingsbestand in de map staat, dus het bereiken hiervan is iets ingewikkelder en de manier om dit op te lossen, zonder te veel details te krijgen, is dit:

  1. Voeg de volgende regels toe aan .dockerignore:

    • *.slnom alle oplossingsbestanden in de hoofdmapstructuur te negeren

    • !eShopOnContainers-ServicesAndWebApps.slnom alleen dit oplossingsbestand op te nemen.

  2. Neem het /ignoreprojectextensions:.dcproj argument op dotnet restore, dus negeert het docker-compose-project en herstelt alleen de pakketten voor de oplossing eShopOnContainers-ServicesAndWebApps.

Voor de laatste optimalisatie gebeurt het alleen dat regel 20 redundant is, omdat regel 23 ook de toepassing bouwt en in wezen direct na regel 20 komt, dus er gaat nog een tijdrovende opdracht.

Het resulterende bestand is dan:

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

Uw basisinstallatiekopieën helemaal zelf maken

U kunt uw eigen Docker-basisinstallatiekopieën helemaal zelf maken. Dit scenario wordt niet aanbevolen voor iemand die begint met Docker, maar als u de specifieke bits van uw eigen basisinstallatiekopieën wilt instellen, kunt u dit doen.

Aanvullende bronnen

Afbeelding voor stap 3.

Stap 3. Uw aangepaste Docker-installatiekopieën maken en uw toepassing of service erin insluiten

Voor elke service in uw toepassing moet u een gerelateerde installatiekopieën maken. Als uw toepassing bestaat uit één service of webtoepassing, hebt u slechts één installatiekopieën nodig.

Houd er rekening mee dat de Docker-installatiekopieën automatisch voor u worden gemaakt in Visual Studio. De volgende stappen zijn alleen nodig voor de editor/CLI-werkstroom en worden uitgelegd wat er daaronder gebeurt.

Als ontwikkelaar moet u lokaal ontwikkelen en testen totdat u een voltooide functie pusht of wijzigt in uw broncodebeheersysteem (bijvoorbeeld naar GitHub). Dit betekent dat u de Docker-installatiekopieën moet maken en containers moet implementeren op een lokale Docker-host (Windows- of Linux-VM) en deze lokale containers moet uitvoeren, testen en fouten moet opsporen.

Als u een aangepaste installatiekopieën wilt maken in uw lokale omgeving met behulp van Docker CLI en uw Dockerfile, kunt u de opdracht docker build gebruiken, zoals in afbeelding 5-5.

Schermopname van de console-uitvoer van de docker-buildopdracht.

Afbeelding 5-5. Een aangepaste Docker-installatiekopieën maken

In plaats van docker-build rechtstreeks uit te voeren vanuit de projectmap, kunt u eerst een implementeerbare map genereren met de vereiste .NET-bibliotheken en binaire bestanden door deze uit te voeren dotnet publishen vervolgens de docker build opdracht te gebruiken.

Hiermee maakt u een Docker-installatiekopieën met de naam cesardl/netcore-webapi-microservice-docker:first. In dit geval :first is dit een tag die een specifieke versie vertegenwoordigt. U kunt deze stap herhalen voor elke aangepaste installatiekopieën die u moet maken voor uw samengestelde Docker-toepassing.

Wanneer een toepassing uit meerdere containers bestaat (dat wil gezegd, het is een toepassing met meerdere containers), kunt u ook de docker-compose up --build opdracht gebruiken om alle gerelateerde installatiekopieën met één opdracht te maken met behulp van de metagegevens die worden weergegeven in de gerelateerde docker-compose.yml bestanden.

U vindt de bestaande installatiekopieën in uw lokale opslagplaats met behulp van de opdracht docker-installatiekopieën, zoals wordt weergegeven in afbeelding 5-6.

Console-uitvoer van opdracht docker-installatiekopieën, met bestaande installatiekopieën.

Afbeelding 5-6. Bestaande installatiekopieën weergeven met behulp van de opdracht docker-installatiekopieën

Docker-installatiekopieën maken met Visual Studio

Wanneer u Visual Studio gebruikt om een project te maken met Docker-ondersteuning, maakt u geen installatiekopieën expliciet. In plaats daarvan wordt de installatiekopieën voor u gemaakt wanneer u op F5 (of Ctrl+) drukt om de dockerized toepassing of service uit te voeren. Deze stap is automatisch in Visual Studio en u ziet deze stap niet, maar het is belangrijk dat u weet wat er daaronder gebeurt.

Afbeelding voor de optionele stap 4.

Stap 4. Uw services definiëren in docker-compose.yml bij het bouwen van een Docker-toepassing met meerdere containers

Met het docker-compose.yml-bestand kunt u een set gerelateerde services definiëren die moeten worden geïmplementeerd als een samengestelde toepassing met implementatieopdrachten. Ook worden de afhankelijkheidsrelaties en runtimeconfiguratie geconfigureerd.

Als u een docker-compose.yml-bestand wilt gebruiken, moet u het bestand maken in de hoofd- of hoofdoplossingsmap, met inhoud die vergelijkbaar is met die in het volgende voorbeeld:

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"

Belangrijk

Microsoft raadt u aan de veiligste verificatiestroom te gebruiken die beschikbaar is. Als u verbinding maakt met Azure SQL, is Managed Identities voor Azure-resources de aanbevolen verificatiemethode.

Dit docker-compose.yml bestand is een vereenvoudigde en samengevoegde versie. Deze bevat statische configuratiegegevens voor elke container (zoals de naam van de aangepaste installatiekopieën), die altijd vereist zijn en configuratiegegevens die mogelijk afhankelijk zijn van de implementatieomgeving, zoals de verbindingsreeks. In latere secties leert u hoe u de docker-compose.yml-configuratie splitst in meerdere docker-compose-bestanden en waarden overschrijft, afhankelijk van het omgevings- en uitvoeringstype (foutopsporing of release).

In het voorbeeld van het bestand docker-compose.yml worden vier services gedefinieerd: de webmvc service (een webtoepassing), twee microservices (ordering-api en basket-api) en één gegevensbroncontainer, sqldataop basis van SQL Server voor Linux die als een container wordt uitgevoerd. Elke service wordt geïmplementeerd als een container, dus voor elke service is een Docker-installatiekopie vereist.

Het docker-compose.yml-bestand geeft niet alleen aan welke containers worden gebruikt, maar hoe ze afzonderlijk worden geconfigureerd. Bijvoorbeeld de webmvc containerdefinitie in het .yml-bestand:

  • Maakt gebruik van een vooraf gemaakte eshop/web:latest installatiekopie. U kunt echter ook configureren dat de installatiekopie wordt gebouwd als onderdeel van de uitvoering van docker-compose met een extra configuratie op basis van een build: sectie in het docker-compose-bestand.

  • Initialiseert twee omgevingsvariabelen (CatalogUrl en OrderingUrl).

  • Hiermee wordt de weergegeven poort 80 op de container doorgestuurd naar de externe poort 80 op de hostcomputer.

  • Hiermee koppelt u de web-app aan de catalogus en bestelservice met de instelling depends_on. Dit zorgt ervoor dat de service wacht totdat deze services zijn gestart.

We gaan het docker-compose.yml-bestand in een latere sectie opnieuw bekijken wanneer we bespreken hoe we microservices en apps met meerdere containers kunnen implementeren.

Werken met docker-compose.yml in Visual Studio

Naast het toevoegen van een Dockerfile aan een project, zoals eerder is vermeld, kan Visual Studio 2017 (vanaf versie 15.8 on) orchestratorondersteuning voor Docker Compose toevoegen aan een oplossing.

Wanneer u ondersteuning voor containerorchestrator toevoegt, zoals wordt weergegeven in afbeelding 5-7, maakt Visual Studio voor het eerst het Dockerfile voor het project en maakt een nieuw (servicesectie)-project in uw oplossing met verschillende globale docker-compose*.yml bestanden en voegt het project vervolgens toe aan die bestanden. Vervolgens kunt u de docker-compose.yml bestanden openen en bijwerken met aanvullende functies.

Herhaal deze bewerking voor elk project dat u wilt opnemen in het docker-compose.yml-bestand.

Op het moment van schrijven ondersteunt Visual Studio Docker Compose-orchestrators .

Schermopname van de optie Ondersteuning voor Container Orchestrator in het contextmenu van het project.

Afbeelding 5-7. Docker-ondersteuning toevoegen in Visual Studio 2022 door met de rechtermuisknop op een ASP.NET Core-project te klikken

Nadat u orchestratorondersteuning aan uw oplossing in Visual Studio hebt toegevoegd, ziet u ook een nieuw knooppunt (in het docker-compose.dcproj projectbestand) in Solution Explorer met de toegevoegde docker-compose.yml bestanden, zoals wordt weergegeven in afbeelding 5-8.

Schermopname van het docker-compose-knooppunt in Solution Explorer.

Afbeelding 5-8. Het structuurknooppunt docker compose toegevoegd in Visual Studio 2022 Solution Explorer

U kunt een toepassing met meerdere containers met één docker-compose.yml-bestand implementeren met behulp van de docker-compose up opdracht. Visual Studio voegt echter een groep ervan toe, zodat u waarden kunt overschrijven, afhankelijk van de omgeving (ontwikkeling of productie) en het uitvoeringstype (release of foutopsporing). Deze mogelijkheid wordt in latere secties uitgelegd.

Afbeelding voor stap 5.

Stap 5. Uw Docker-toepassing bouwen en uitvoeren

Als uw toepassing slechts één container heeft, kunt u deze uitvoeren door deze te implementeren op uw Docker-host (VM of fysieke server). Als uw toepassing echter meerdere services bevat, kunt u deze implementeren als een samengestelde toepassing, hetzij met één CLI-opdracht (docker-compose up)of met Visual Studio, die die opdracht onder de dekkingen gebruikt. Laten we eens kijken naar de verschillende opties.

Optie A: Een toepassing met één container uitvoeren

Docker CLI gebruiken

U kunt een Docker-container uitvoeren met behulp van de docker run opdracht, zoals wordt weergegeven in afbeelding 5-9:

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

Met de bovenstaande opdracht maakt u een nieuwe containerinstantie op basis van de opgegeven installatiekopieën, telkens wanneer deze wordt uitgevoerd. U kunt de --name parameter gebruiken om een naam aan de container te geven en vervolgens een bestaande containerinstantie uit te voeren (of de container-id of automatische naam te gebruiken docker start {name} ).

Schermopname van het uitvoeren van een Docker-container met behulp van de opdracht docker run.

Afbeelding 5-9. Een Docker-container uitvoeren met behulp van de opdracht docker-run

In dit geval verbindt de opdracht de interne poort 5000 van de container met poort 80 van de hostcomputer. Dit betekent dat de host luistert op poort 80 en doorstuurt naar poort 5000 op de container.

De weergegeven hash is de container-id en er wordt ook een willekeurige leesbare naam toegewezen als de --name optie niet wordt gebruikt.

Visual Studio gebruiken

Als u geen ondersteuning voor containerorchestrator hebt toegevoegd, kunt u ook één container-app uitvoeren in Visual Studio door op Ctrl+om fouten in de toepassing in de container op te sporen. De container wordt lokaal uitgevoerd met behulp van docker run.

Optie B: Een toepassing met meerdere containers uitvoeren

In de meeste bedrijfsscenario's bestaat een Docker-toepassing uit meerdere services, wat betekent dat u een toepassing met meerdere containers moet uitvoeren, zoals wordt weergegeven in afbeelding 5-10.

VM met verschillende Docker-containers

Afbeelding 5-10. VM met Docker-containers geïmplementeerd

Docker CLI gebruiken

Als u een toepassing met meerdere containers wilt uitvoeren met de Docker CLI, gebruikt u de docker-compose up opdracht. Met deze opdracht wordt het docker-compose.yml-bestand gebruikt dat u op oplossingsniveau hebt om een toepassing met meerdere containers te implementeren. Afbeelding 5-11 toont de resultaten bij het uitvoeren van de opdracht vanuit de hoofdmap van de oplossing, die het docker-compose.yml bestand bevat.

Schermweergave bij het uitvoeren van de opdracht docker-compose up

Afbeelding 5-11. Voorbeeldresultaten bij het uitvoeren van de opdracht docker-compose up

Nadat de opdracht docker-compose up is uitgevoerd, worden de toepassing en de bijbehorende containers geïmplementeerd in uw Docker-host, zoals weergegeven in afbeelding 5-10.

Visual Studio gebruiken

Het uitvoeren van een toepassing met meerdere containers met Visual Studio 2019 kan niet eenvoudiger. U drukt gewoon op Ctrl+F5 om uit te voeren of F5 om fouten op te sporen, zoals gebruikelijk, om het docker-compose-project in te stellen als het opstartproject. Visual Studio verwerkt alle benodigde instellingen, zodat u zoals gebruikelijk onderbrekingspunten kunt maken en fouten kunt opsporen in wat uiteindelijk onafhankelijke processen worden die worden uitgevoerd in 'externe servers', waarbij het foutopsporingsprogramma al is gekoppeld, net als dat.

Zoals eerder vermeld, wordt dat project telkens wanneer u docker-oplossingsondersteuning toevoegt aan een project binnen een oplossing, geconfigureerd in het globale bestand (op oplossingsniveau) docker-compose.yml, waarmee u de hele oplossing tegelijk kunt uitvoeren of fouten in de hele oplossing kunt opsporen. Visual Studio start één container voor elk project waarvoor ondersteuning voor Docker-oplossingen is ingeschakeld en voert alle interne stappen voor u uit (dotnet publish, docker build, enzovoort).

Als u alle drudgery wilt bekijken, bekijkt u het bestand:

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

Het belangrijkste punt hier is dat er, zoals weergegeven in afbeelding 5-12, in Visual Studio 2019, een extra Docker-opdracht is voor de F5-sleutelactie. Met deze optie kunt u een toepassing met meerdere containers uitvoeren of fouten opsporen door alle containers uit te voeren die zijn gedefinieerd in de docker-compose.yml bestanden op oplossingsniveau. De mogelijkheid om fouten in oplossingen met meerdere containers op te sporen, betekent dat u verschillende onderbrekingspunten kunt instellen, elk onderbrekingspunt in een ander project (container) en dat u tijdens foutopsporing vanuit Visual Studio stopt bij onderbrekingspunten die in verschillende projecten zijn gedefinieerd en op verschillende containers worden uitgevoerd.

Schermopname van de werkbalk voor foutopsporing met een docker-compose-project.

Afbeelding 5-12. Apps met meerdere containers uitvoeren in Visual Studio 2022

Aanvullende bronnen

Een opmerking over testen en implementeren met orchestrators

De docker-compose-opdrachten en docker-run-opdrachten (of het uitvoeren en opsporen van fouten in de containers in Visual Studio) zijn geschikt voor het testen van containers in uw ontwikkelomgeving. Maar u moet deze benadering niet gebruiken voor productie-implementaties, waar u orchestrators zoals Kubernetes of Service Fabric moet richten. Als u Kubernetes gebruikt, moet u pods gebruiken om containers en services te organiseren om ze te netwerken. U gebruikt ook implementaties om het maken en wijzigen van pods te organiseren.

Afbeelding voor stap 6.

Stap 6. Uw Docker-toepassing testen met behulp van uw lokale Docker-host

Deze stap is afhankelijk van wat uw toepassing doet. In een eenvoudige .NET-webtoepassing die is geïmplementeerd als één container of service, hebt u toegang tot de service door een browser op de Docker-host te openen en naar die site te navigeren, zoals wordt weergegeven in afbeelding 5-13. (Als de configuratie in het Dockerfile de container toe wijst aan een poort op de host die iets anders is dan 80, neemt u de hostpoort op in de URL.)

Schermopname van het antwoord van localhost/API/values.

Afbeelding 5-13. Voorbeeld van het lokaal testen van uw Docker-toepassing met behulp van localhost

Als localhost niet verwijst naar het IP-adres van de Docker-host (standaard wanneer u Docker CE gebruikt, moet dit wel), gebruikt u het IP-adres van de netwerkkaart van uw computer.

Deze URL in de browser maakt gebruik van poort 80 voor het voorbeeld van de specifieke container die wordt besproken. Intern worden de aanvragen echter omgeleid naar poort 5000, omdat dit de implementatie was met de docker-opdracht uitvoeren, zoals in een vorige stap is uitgelegd.

U kunt de toepassing ook testen met behulp van curl vanuit de terminal, zoals weergegeven in afbeelding 5-14. In een Docker-installatie in Windows is het standaard-IP-adres van de Docker-host altijd 10.0.75.1 naast het werkelijke IP-adres van uw computer.

Console-uitvoer van het ophalen van de http://10.0.75.1/API/values met curl.

Afbeelding 5-14. Voorbeeld van het lokaal testen van uw Docker-toepassing met behulp van curl

Containers testen en fouten opsporen met Visual Studio

Wanneer u de containers uitvoert en foutopsporing uitvoert met Visual Studio, kunt u op dezelfde manier fouten opsporen in de .NET-toepassing als bij het uitvoeren zonder containers.

Testen en foutopsporing zonder Visual Studio

Als u ontwikkelt met behulp van de editor-/CLI-benadering, is foutopsporing van containers moeilijker en wilt u waarschijnlijk fouten opsporen door traceringen te genereren.

Aanvullende bronnen

Vereenvoudigde werkstroom bij het ontwikkelen van containers met Visual Studio

In feite is de werkstroom bij het gebruik van Visual Studio veel eenvoudiger dan wanneer u de editor-/CLI-benadering gebruikt. De meeste stappen die vereist zijn voor Docker met betrekking tot de Dockerfile- en docker-compose.yml-bestanden worden verborgen of vereenvoudigd door Visual Studio, zoals wordt weergegeven in afbeelding 5-15.

Diagram met de vijf vereenvoudigde stappen die nodig zijn om een app te maken.

Afbeelding 5-15. Vereenvoudigde werkstroom bij het ontwikkelen met Visual Studio

Daarnaast moet u stap 2 (Docker-ondersteuning toevoegen aan uw projecten) slechts één keer uitvoeren. Daarom is de werkstroom vergelijkbaar met uw gebruikelijke ontwikkelingstaken bij het gebruik van .NET voor elke andere ontwikkeling. U moet weten wat er gebeurt onder de covers (het buildproces voor installatiekopieën, welke basisinstallatiekopieën u gebruikt, implementatie van containers, enzovoort) en soms moet u ook het Dockerfile- of docker-compose.yml-bestand bewerken om gedrag aan te passen. Maar het meeste werk wordt aanzienlijk vereenvoudigd door Visual Studio te gebruiken, waardoor u veel productiever bent.

PowerShell-opdrachten gebruiken in een Dockerfile om Windows-containers in te stellen

Met Windows-containers kunt u uw bestaande Windows-toepassingen converteren naar Docker-installatiekopieën en deze implementeren met dezelfde hulpprogramma's als de rest van het Docker-ecosysteem. Als u Windows-containers wilt gebruiken, voert u PowerShell-opdrachten uit in het Dockerfile, zoals wordt weergegeven in het volgende voorbeeld:

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

In dit geval gebruiken we een Windows Server Core-basisinstallatiekopieën (de FROM-instelling) en installeren we IIS met een PowerShell-opdracht (de RUN-instelling). Op een vergelijkbare manier kunt u ook PowerShell-opdrachten gebruiken om extra onderdelen in te stellen, zoals ASP.NET 4.x, .NET Framework 4.6 of andere Windows-software. Met de volgende opdracht in een Dockerfile wordt bijvoorbeeld ASP.NET 4.5 ingesteld:

RUN powershell add-windowsfeature web-asp-net45

Aanvullende bronnen

VorigeVolgende

  • Last updated on