Delen via

Uw toepassing met meerdere containers definiëren met docker-compose.yml

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.

In deze handleiding is het docker-compose.yml-bestand geïntroduceerd in de sectie Stap 4. Definieer uw services in docker-compose.yml bij het bouwen van een Docker-toepassing met meerdere containers. Er zijn echter aanvullende manieren om de docker-compose-bestanden te gebruiken die de moeite waard zijn om verder te verkennen.

U kunt bijvoorbeeld expliciet beschrijven hoe u uw toepassing met meerdere containers in het docker-compose.yml-bestand wilt implementeren. Desgewenst kunt u ook beschrijven hoe u uw aangepaste Docker-installatiekopieën gaat bouwen. (Aangepaste Docker-installatiekopieën kunnen ook worden gebouwd met de Docker CLI.)

In principe definieert u elk van de containers die u wilt implementeren plus bepaalde kenmerken voor elke containerimplementatie. Zodra u een beschrijvingsbestand met meerdere containers hebt, kunt u de hele oplossing implementeren in één actie die is ingedeeld met de CLI-opdracht docker-compose up , of u kunt deze transparant implementeren vanuit Visual Studio. Anders moet u de Docker CLI gebruiken om container-by-container in meerdere stappen te implementeren met behulp van de docker run opdracht vanaf de opdrachtregel. Daarom moet elke service die is gedefinieerd in docker-compose.yml precies één image of build specificeren. Andere sleutels zijn optioneel en zijn vergelijkbaar met hun docker run opdrachtregel tegenhangers.

De volgende YAML-code is de definitie van een mogelijk globaal maar enkel docker-compose.yml bestand voor het eShopOnContainers-voorbeeld. Deze code is niet het feitelijke docker-compose-bestand van eShopOnContainers. In plaats daarvan is het een vereenvoudigde en geconsolideerde versie in één bestand, wat niet de beste manier is om met docker-compose-bestanden te werken, zoals later wordt uitgelegd.

version: '3.4'

services:
  webmvc:
    image: eshop/webmvc
    environment:
      - CatalogUrl=http://catalog-api
      - OrderingUrl=http://ordering-api
      - BasketUrl=http://basket-api
    ports:
      - "5100:80"
    depends_on:
      - catalog-api
      - ordering-api
      - basket-api

  catalog-api:
    image: eshop/catalog-api
    environment:
      - ConnectionString=Server=sqldata;Initial Catalog=CatalogData;User Id=sa;Password=[PLACEHOLDER]
    expose:
      - "80"
    ports:
      - "5101:80"
    #extra hosts can be used for standalone SQL Server or services at the dev PC
    extra_hosts:
      - "CESARDLSURFBOOK:10.0.75.1"
    depends_on:
      - sqldata

  ordering-api:
    image: eshop/ordering-api
    environment:
      - ConnectionString=Server=sqldata;Database=Services.OrderingDb;User Id=sa;Password=[PLACEHOLDER]
    ports:
      - "5102:80"
    #extra hosts can be used for standalone SQL Server or services at the dev PC
    extra_hosts:
      - "CESARDLSURFBOOK:10.0.75.1"
    depends_on:
      - sqldata

  basket-api:
    image: eshop/basket-api
    environment:
      - ConnectionString=sqldata
    ports:
      - "5103:80"
    depends_on:
      - sqldata

  sqldata:
    environment:
      - SA_PASSWORD=[PLACEHOLDER]
      - ACCEPT_EULA=Y
    ports:
      - "5434:1433"

  basketdata:
    image: redis

De hoofdsleutel in dit bestand is services. Onder die sleutel definieert u de services die u wilt implementeren en uitvoeren wanneer u de docker-compose up opdracht uitvoert of wanneer u implementeert vanuit Visual Studio met behulp van dit docker-compose.yml-bestand. In dit geval heeft het bestand docker-compose.yml meerdere services gedefinieerd, zoals beschreven in de volgende tabel.

Servicenaam Beschrijving
webmvc Container met de ASP.NET Core MVC-toepassing die de microservices via server-side C# gebruikt
catalog-api Container met inbegrip van de microservice Catalog ASP.NET Core Web API
bestel-API Container met inbegrip van de microservice Order ASP.NET Core Web API
sqldata Container met SQL Server voor Linux, waarin de microservicesdatabases worden opgeslagen
winkelmandje-API Container met de winkelmand-microservice voor ASP.NET Core Web API
mandgegevens Container waarop de REDIS-cacheservice wordt uitgevoerd, met de manddatabase als redis-cache

Een eenvoudige webservice-API-container

De focus ligt op één container, de catalogus-API-container-microservice heeft een eenvoudige definitie.

  catalog-api:
    image: eshop/catalog-api
    environment:
      - ConnectionString=Server=sqldata;Initial Catalog=CatalogData;User Id=sa;Password=[PLACEHOLDER]
    expose:
      - "80"
    ports:
      - "5101:80"
    #extra hosts can be used for standalone SQL Server or services at the dev PC
    extra_hosts:
      - "CESARDLSURFBOOK:10.0.75.1"
    depends_on:
      - sqldata

Deze containerservice heeft de volgende basisconfiguratie:

  • Deze is gebaseerd op de aangepaste eshop/catalog-api image. Om het eenvoudig te houden, is er geen sleutelinstelling voor build in het bestand. Dit betekent dat de installatiekopie eerder moet zijn gebouwd (met docker-build) of dat deze is gedownload (met de opdracht docker pull) uit een Docker-register.

  • Hiermee definieert u een omgevingsvariabele met de naam ConnectionString met de verbindingsreeks die door Entity Framework moet worden gebruikt voor toegang tot het SQL Server-exemplaar dat het catalogusgegevensmodel bevat. In dit geval bevat dezelfde SQL Server-container meerdere databases. Daarom hebt u minder geheugen nodig op uw ontwikkelcomputer voor Docker. U kunt echter ook één SQL Server-container implementeren voor elke microservicedatabase.

  • De SQL Server-naam is sqldata. Dit is dezelfde naam die wordt gebruikt voor de container waarop het SQL Server-exemplaar voor Linux wordt uitgevoerd. Dit is handig; Als u deze naamomzetting (intern voor de Docker-host) kunt gebruiken, wordt het netwerkadres omgezet, zodat u het interne IP-adres niet hoeft te kennen voor de containers die u gebruikt vanuit andere containers.

Omdat de verbindingsreeks is gedefinieerd door een omgevingsvariabele, kunt u die variabele instellen via een ander mechanisme en op een ander tijdstip. U kunt bijvoorbeeld een andere verbindingsreeks instellen bij de implementatie naar productie op de uiteindelijke hosts of door dit te doen vanuit uw CI/CD-pijplijnen in Azure DevOps Services of uw favoriete DevOps-systeem.

  • Poort 80 wordt beschikbaar gesteld voor interne toegang tot de catalog-API-service binnen de Docker-host . De host is momenteel een Linux-VM omdat deze is gebaseerd op een Docker-installatiekopie voor Linux, maar u kunt de container configureren voor uitvoering op een Windows-installatiekopie.

  • Hiermee wordt de weergegeven poort 80 op de container doorgestuurd naar poort 5101 op de Docker-hostmachine (de Linux-VM).

  • De webservice wordt gekoppeld aan de sqldata-service (het SQL Server-exemplaar voor Linux-database die in een container wordt uitgevoerd). Wanneer u deze afhankelijkheid opgeeft, wordt de catalogus-API-container pas gestart als de sqldata-container al is gestart; dit aspect is belangrijk omdat catalog-API de SQL Server-database eerst moet laten werken. Dit soort containerafhankelijkheid is echter in veel gevallen niet voldoende, omdat Docker alleen op containerniveau controleert. Soms is de service (in dit geval SQL Server) nog steeds niet gereed, dus het is raadzaam om logica voor opnieuw proberen te implementeren met exponentieel uitstel in uw clientmicroservices. Op die manier is de toepassing nog steeds veerkrachtig, zelfs als een afhankelijkheidscontainer voor een korte tijd niet gereed is.

  • Het is geconfigureerd om toegang tot externe servers toe te staan: met de extra_hosts-instelling hebt u toegang tot externe servers of computers buiten de Docker-host (dat wil gezegd buiten de standaard-Linux-VM, een ontwikkelings-Docker-host), zoals een lokaal SQL Server-exemplaar op uw ontwikkelcomputer.

Er zijn ook andere, geavanceerdere docker-compose.yml instellingen die in de volgende secties worden besproken.

Docker-compose-bestanden gebruiken om meerdere omgevingen te targeten

De docker-compose.*.yml bestanden zijn definitiebestanden en kunnen worden gebruikt door meerdere infrastructuren die die indeling begrijpen. Het eenvoudigste hulpprogramma is de opdracht docker-compose.

Daarom kunt u met behulp van de opdracht docker-compose de volgende hoofdscenario's toepassen.

Ontwikkelomgevingen

Wanneer u toepassingen ontwikkelt, is het belangrijk dat u een toepassing in een geïsoleerde ontwikkelomgeving kunt uitvoeren. U kunt de CLI-opdracht docker-compose gebruiken om die omgeving te creëren of Visual Studio, dat achter de schermen gebruikmaakt van docker-compose.

Met het docker-compose.yml-bestand kunt u alle serviceafhankelijkheden van uw toepassing configureren en documenteren (andere services, cache, databases, wachtrijen, enzovoort). Met behulp van de CLI-opdracht docker compose kunt u voor elke afhankelijkheid een of meer containers maken en starten met één opdracht (docker-compose up).

De docker-compose.yml-bestanden zijn configuratiebestanden die worden geïnterpreteerd door de Docker-engine, maar dienen ook als handige documentatiebestanden over de samenstelling van uw toepassing met meerdere containers.

Testomgevingen

Een belangrijk onderdeel van een CD-proces (continue implementatie) of een CI-proces (continue integratie) zijn de unit tests en integratietests. Voor deze geautomatiseerde tests is een geïsoleerde omgeving vereist, zodat deze niet worden beïnvloed door de gebruikers of een andere wijziging in de gegevens van de toepassing.

Met Docker Compose kunt u die geïsoleerde omgeving heel eenvoudig maken en vernietigen in een paar opdrachten vanaf uw opdrachtprompt of scripts, zoals de volgende opdrachten:

docker-compose -f docker-compose.yml -f docker-compose-test.override.yml up -d
./run_unit_tests
docker-compose -f docker-compose.yml -f docker-compose-test.override.yml down

Productie-uitrol

U kunt Compose ook gebruiken om te implementeren in een externe Docker Engine. Een veelvoorkomend geval is om te implementeren naar één Docker-hostinstantie.

Als u een andere orchestrator (bijvoorbeeld Azure Service Fabric of Kubernetes) gebruikt, moet u mogelijk instellingen voor installatie- en metagegevensconfiguratie toevoegen, zoals die in docker-compose.yml, maar in de indeling die is vereist voor de andere orchestrator.

Docker-compose is in elk geval een handige indeling voor hulpprogramma's en metagegevens voor ontwikkelings-, test- en productiewerkstromen, hoewel de productiewerkstroom kan variëren op de orchestrator die u gebruikt.

Meerdere docker-compose-bestanden gebruiken om verschillende omgevingen te verwerken

Wanneer u zich richt op verschillende omgevingen, moet u meerdere opstelbestanden gebruiken. Met deze benadering kunt u meerdere configuratievarianten maken, afhankelijk van de omgeving.

Het basis-docker-compose-bestand overschrijven

U kunt één docker-compose.yml bestand gebruiken, zoals in de vereenvoudigde voorbeelden die in de vorige secties worden weergegeven. Dit wordt echter niet aanbevolen voor de meeste toepassingen.

Standaard leest Compose twee bestanden, een docker-compose.yml en een optionele docker-compose.override.yml bestand. Zoals wordt weergegeven in afbeelding 6-11, kunt u, wanneer u Visual Studio gebruikt en Docker-ondersteuning inschakelt, ook een extra docker-compose.vs.debug.g.yml-bestand maken voor foutopsporing van de toepassing. U kunt dit bestand bekijken in map obj\Docker\ in de hoofdoplossingsmap.

Bestanden in een docker-compose-project.

Afbeelding 6-11. docker-compose-bestanden in Visual Studio 2019

structuur van projectbestand docker compose :

  • .dockerignore - wordt gebruikt om bestanden te negeren
  • docker-compose.yml - gebruikt voor het opstellen van microservices
  • docker-compose.override.yml : wordt gebruikt voor het configureren van een microservicesomgeving

U kunt de docker-compose-bestanden bewerken met elke editor, zoals Visual Studio Code of Subliem, en de toepassing uitvoeren met de opdracht docker-compose up.

Standaard bevat het docker-compose.yml bestand uw basisconfiguratie en andere statische instellingen. Dit betekent dat de serviceconfiguratie niet mag veranderen, afhankelijk van de implementatieomgeving die u wilt gebruiken.

Het docker-compose.override.yml-bestand, zoals de naam al aangeeft, bevat configuratie-instellingen die de basisconfiguratie overschrijven, zoals configuratie die afhankelijk is van de implementatieomgeving. U kunt meerdere override-bestanden met verschillende namen hebben. De override-bestanden bevatten meestal aanvullende informatie die nodig is voor de applicatie, maar specifiek voor een omgeving of voor een implementatie.

Meerdere omgevingen targeten

Een typische use-case is wanneer u meerdere opstellenbestanden definieert, zodat u zich kunt richten op meerdere omgevingen, zoals productie, fasering, CI of ontwikkeling. Ter ondersteuning van deze verschillen kunt u de compose-configuratie splitsen in meerdere bestanden, zoals wordt weergegeven in afbeelding 6-12.

Diagram van drie docker-compose-bestanden die zijn ingesteld om het basisbestand te overschrijven.

Afbeelding 6-12. Meerdere docker-compose-bestanden die waarden overschrijven in het basisbestand docker-compose.yml

U kunt meerdere docker-compose*.yml bestanden combineren om verschillende omgevingen te verwerken. U begint met het basisbestand docker-compose.yml. Dit basisbestand bevat de basis- of statische configuratie-instellingen die niet veranderen, afhankelijk van de omgeving. De eShopOnContainers-app heeft bijvoorbeeld het volgende docker-compose.yml bestand (vereenvoudigd met minder services) als het basisbestand.

#docker-compose.yml (Base)
version: '3.4'
services:
  basket-api:
    image: eshop/basket-api:${TAG:-latest}
    build:
      context: .
      dockerfile: src/Services/Basket/Basket.API/Dockerfile
    depends_on:
      - basketdata
      - identity-api
      - rabbitmq

  catalog-api:
    image: eshop/catalog-api:${TAG:-latest}
    build:
      context: .
      dockerfile: src/Services/Catalog/Catalog.API/Dockerfile
    depends_on:
      - sqldata
      - rabbitmq

  marketing-api:
    image: eshop/marketing-api:${TAG:-latest}
    build:
      context: .
      dockerfile: src/Services/Marketing/Marketing.API/Dockerfile
    depends_on:
      - sqldata
      - nosqldata
      - identity-api
      - rabbitmq

  webmvc:
    image: eshop/webmvc:${TAG:-latest}
    build:
      context: .
      dockerfile: src/Web/WebMVC/Dockerfile
    depends_on:
      - catalog-api
      - ordering-api
      - identity-api
      - basket-api
      - marketing-api

  sqldata:
    image: mcr.microsoft.com/mssql/server:2019-latest

  nosqldata:
    image: mongo

  basketdata:
    image: redis

  rabbitmq:
    image: rabbitmq:3-management

De waarden in het basisbestand docker-compose.yml mogen niet worden gewijzigd vanwege verschillende doelimplementatieomgevingen.

Als u zich bijvoorbeeld richt op de definitie van de webmvc-service, kunt u zien hoe die informatie grotendeels hetzelfde blijft, ongeacht de omgeving waarop u zich richt. U hebt de volgende informatie:

  • De servicenaam: webmvc.

  • De aangepaste beeld van de container: eshop/webmvc.

  • De opdracht voor het bouwen van de aangepaste Docker-installatiekopieën, waarmee wordt aangegeven welke Dockerfile moet worden gebruikt.

  • Afhankelijkheden van andere services, dus deze container start pas als de andere afhankelijkheidscontainers zijn gestart.

U kunt aanvullende configuratie hebben, maar het belangrijkste punt is dat u in het basisbestand docker-compose.yml alleen de informatie wilt instellen die gebruikelijk is in omgevingen. Vervolgens moet u in de docker-compose.override.yml of vergelijkbare bestanden voor productie of fasering configuraties plaatsen die specifiek zijn voor elke omgeving.

Meestal wordt de docker-compose.override.yml gebruikt voor uw ontwikkelomgeving, zoals in het volgende voorbeeld van eShopOnContainers:

#docker-compose.override.yml (Extended config for DEVELOPMENT env.)
version: '3.4'

services:
# Simplified number of services here:

  basket-api:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://0.0.0.0:80
      - ConnectionString=${ESHOP_AZURE_REDIS_BASKET_DB:-basketdata}
      - identityUrl=http://identity-api
      - IdentityUrlExternal=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5105
      - EventBusConnection=${ESHOP_AZURE_SERVICE_BUS:-rabbitmq}
      - EventBusUserName=${ESHOP_SERVICE_BUS_USERNAME}
      - EventBusPassword=${ESHOP_SERVICE_BUS_PASSWORD}
      - AzureServiceBusEnabled=False
      - ApplicationInsights__InstrumentationKey=${INSTRUMENTATION_KEY}
      - OrchestratorType=${ORCHESTRATOR_TYPE}
      - UseLoadTest=${USE_LOADTEST:-False}

    ports:
      - "5103:80"

  catalog-api:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://0.0.0.0:80
      - ConnectionString=${ESHOP_AZURE_CATALOG_DB:-Server=sqldata;Database=Microsoft.eShopOnContainers.Services.CatalogDb;User Id=sa;Password=[PLACEHOLDER]}
      - PicBaseUrl=${ESHOP_AZURE_STORAGE_CATALOG_URL:-http://host.docker.internal:5202/api/v1/catalog/items/[0]/pic/}
      - EventBusConnection=${ESHOP_AZURE_SERVICE_BUS:-rabbitmq}
      - EventBusUserName=${ESHOP_SERVICE_BUS_USERNAME}
      - EventBusPassword=${ESHOP_SERVICE_BUS_PASSWORD}
      - AzureStorageAccountName=${ESHOP_AZURE_STORAGE_CATALOG_NAME}
      - AzureStorageAccountKey=${ESHOP_AZURE_STORAGE_CATALOG_KEY}
      - UseCustomizationData=True
      - AzureServiceBusEnabled=False
      - AzureStorageEnabled=False
      - ApplicationInsights__InstrumentationKey=${INSTRUMENTATION_KEY}
      - OrchestratorType=${ORCHESTRATOR_TYPE}
    ports:
      - "5101:80"

  marketing-api:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://0.0.0.0:80
      - ConnectionString=${ESHOP_AZURE_MARKETING_DB:-Server=sqldata;Database=Microsoft.eShopOnContainers.Services.MarketingDb;User Id=sa;Password=[PLACEHOLDER]}
      - MongoConnectionString=${ESHOP_AZURE_COSMOSDB:-mongodb://nosqldata}
      - MongoDatabase=MarketingDb
      - EventBusConnection=${ESHOP_AZURE_SERVICE_BUS:-rabbitmq}
      - EventBusUserName=${ESHOP_SERVICE_BUS_USERNAME}
      - EventBusPassword=${ESHOP_SERVICE_BUS_PASSWORD}
      - identityUrl=http://identity-api
      - IdentityUrlExternal=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5105
      - CampaignDetailFunctionUri=${ESHOP_AZUREFUNC_CAMPAIGN_DETAILS_URI}
      - PicBaseUrl=${ESHOP_AZURE_STORAGE_MARKETING_URL:-http://host.docker.internal:5110/api/v1/campaigns/[0]/pic/}
      - AzureStorageAccountName=${ESHOP_AZURE_STORAGE_MARKETING_NAME}
      - AzureStorageAccountKey=${ESHOP_AZURE_STORAGE_MARKETING_KEY}
      - AzureServiceBusEnabled=False
      - AzureStorageEnabled=False
      - ApplicationInsights__InstrumentationKey=${INSTRUMENTATION_KEY}
      - OrchestratorType=${ORCHESTRATOR_TYPE}
      - UseLoadTest=${USE_LOADTEST:-False}
    ports:
      - "5110:80"

  webmvc:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://0.0.0.0:80
      - PurchaseUrl=http://webshoppingapigw
      - IdentityUrl=http://10.0.75.1:5105
      - MarketingUrl=http://webmarketingapigw
      - CatalogUrlHC=http://catalog-api/hc
      - OrderingUrlHC=http://ordering-api/hc
      - IdentityUrlHC=http://identity-api/hc
      - BasketUrlHC=http://basket-api/hc
      - MarketingUrlHC=http://marketing-api/hc
      - PaymentUrlHC=http://payment-api/hc
      - SignalrHubUrl=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5202
      - UseCustomizationData=True
      - ApplicationInsights__InstrumentationKey=${INSTRUMENTATION_KEY}
      - OrchestratorType=${ORCHESTRATOR_TYPE}
      - UseLoadTest=${USE_LOADTEST:-False}
    ports:
      - "5100:80"
  sqldata:
    environment:
      - SA_PASSWORD=[PLACEHOLDER]
      - ACCEPT_EULA=Y
    ports:
      - "5433:1433"
  nosqldata:
    ports:
      - "27017:27017"
  basketdata:
    ports:
      - "6379:6379"
  rabbitmq:
    ports:
      - "15672:15672"
      - "5672:5672"

In dit voorbeeld maakt de ontwikkelingsoverschrijdingsconfiguratie enkele poorten beschikbaar voor de host, definieert omgevingsvariabelen met omleidings-URL's en geeft verbindingsreeksen op voor de ontwikkelomgeving. Deze instellingen zijn allemaal alleen voor de ontwikkelomgeving.

Wanneer u docker-compose up uitvoert (of het start vanuit Visual Studio), leest de opdracht de overrides automatisch alsof het beide bestanden samenvoegt.

Stel dat u een ander Compose-bestand voor de productieomgeving wilt, met verschillende configuratiewaarden, poorten of verbindingsreeksen. U kunt een ander overschrijvingsbestand maken, zoals een bestand met de naam docker-compose.prod.yml, met verschillende instellingen en omgevingsvariabelen. Dit bestand kan worden opgeslagen in een andere Git-opslagplaats of worden beheerd en beveiligd door een ander team.

Hoe uit te rollen met een specifiek overschrijvingsbestand

Als u meerdere override-bestanden of een override-bestand met een andere naam wilt gebruiken, kunt u de optie -f gebruiken met de opdracht docker-compose en de bestanden specificeren. Opstellen voegt bestanden samen in de volgorde waarin ze zijn opgegeven op de opdrachtregel. Het volgende voorbeeld laat zien hoe u kunt deployen met overschrijvingsbestanden.

docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d

Omgevingsvariabelen gebruiken in docker-compose-bestanden

Het is handig, met name in productieomgevingen, om configuratiegegevens op te halen uit omgevingsvariabelen, zoals we in eerdere voorbeelden hebben laten zien. U kunt verwijzen naar een omgevingsvariabele in uw docker-compose-bestanden met behulp van de syntaxis ${MY_VAR}. De volgende regel uit een docker-compose.prod.yml-bestand laat zien hoe u naar de waarde van een omgevingsvariabele verwijst.

IdentityUrl=http://${ESHOP_PROD_EXTERNAL_DNS_NAME_OR_IP}:5105

Omgevingsvariabelen worden op verschillende manieren gemaakt en geïnitialiseerd, afhankelijk van uw hostomgeving (Linux, Windows, Cloudcluster, enzovoort). Een handige methode is echter om een .env-bestand te gebruiken. De docker-compose-bestanden ondersteunen het declareren van standaardomgevingsvariabelen in het .env-bestand. Deze waarden voor de omgevingsvariabelen zijn de standaardwaarden. Ze kunnen echter worden overschreven door de waarden die u mogelijk hebt gedefinieerd in elk van uw omgevingen (hostbesturingssystemen of omgevingsvariabelen van uw cluster). U plaatst dit .env-bestand in de map waaruit de opdracht docker-compose wordt uitgevoerd.

In het volgende voorbeeld ziet u een .env-bestand, zoals het .env-bestand voor de toepassing eShopOnContainers.

# .env file

ESHOP_EXTERNAL_DNS_NAME_OR_IP=host.docker.internal

ESHOP_PROD_EXTERNAL_DNS_NAME_OR_IP=10.121.122.92

Docker-compose verwacht dat elke regel in een .env-bestand in de indeling <variabele>=<waarde> staat.

De waarden die zijn ingesteld in de runtime-omgeving, overschrijven altijd de waarden die in het .env-bestand zijn gedefinieerd. Op een vergelijkbare manier overschrijven waarden die worden doorgegeven via opdrachtregelargumenten ook de standaardwaarden die zijn ingesteld in het .env-bestand.

Aanvullende bronnen

Geoptimaliseerde ASP.NET Core Docker-installatiekopieën bouwen

Als u Docker en .NET verkent via online bronnen, vindt u Dockerfiles die de eenvoud demonstreren van het bouwen van een Docker-image door uw code naar een container te kopiëren. Deze voorbeelden suggereren dat u met behulp van een eenvoudige configuratie een Docker-installatiekopie kunt hebben met de omgeving die is verpakt met uw toepassing. In het volgende voorbeeld ziet u een eenvoudig Docker-bestand in deze context.

FROM mcr.microsoft.com/dotnet/sdk:8.0
WORKDIR /app
ENV ASPNETCORE_URLS http://+:80
EXPOSE 80
COPY . .
RUN dotnet restore
ENTRYPOINT ["dotnet", "run"]

Een Dockerfile zoals dit werkt. U kunt uw afbeeldingen echter aanzienlijk optimaliseren, met name uw productieafbeeldingen.

In het container- en microservicesmodel start u voortdurend containers. De gebruikelijke manier om containers te gebruiken, start een slapende container niet opnieuw op, omdat het een wegwerpcontainer is. Orchestratoren (zoals Kubernetes en Azure Service Fabric) maken nieuwe exemplaren van afbeeldingen. Wat dit betekent, is dat u moet optimaliseren door de toepassing vooraf te compileren wanneer deze wordt gebouwd, zodat het instantiëringsproces sneller verloopt. Wanneer de container wordt gestart, moet deze klaar zijn om te draaien. Herstel en compileer tijdens runtime niet met behulp van de dotnet restore en dotnet build CLI-opdrachten, zoals u kunt zien in blogberichten over .NET en Docker.

Het .NET-team heeft belangrijk werk verricht om .NET en ASP.NET Core een framework te maken dat is geoptimaliseerd voor containers. Niet alleen is .NET een lichtgewicht framework met een kleine geheugenvoetafdruk; het team heeft zich gericht op geoptimaliseerde Docker-installatiekopieën voor drie hoofdscenario's en gepubliceerd in het Docker Hub-register op dotnet/, vanaf versie 2.1:

  • Ontwikkeling: De prioriteit is de mogelijkheid om snel wijzigingen te herhalen en fouten op te sporen, en waar de grootte secundair is.
  • Build: De prioriteit is het compileren van de applicatie, en de afbeeldingen bevatten binaire bestanden en andere afhankelijkheden om de prestaties van de binaire bestanden te optimaliseren.
  • Productie: De focus is het snel implementeren en starten van containers, dus deze installatiekopieën zijn beperkt tot de binaire bestanden en inhoud die nodig zijn om de toepassing uit te voeren.

Het .NET-team biedt enkele basisvarianten in dotnet/, bijvoorbeeld:

  • sdk: voor ontwikkelings- en buildscenario's
  • aspnet: voor ASP.NET productiescenario's
  • runtime: voor .NET-productiescenario's
  • runtime-deps: voor productiescenario's van zelfstandige toepassingen

Voor een snellere opstart worden runtime-afbeeldingen automatisch ingesteld op aspnetcore_urls voor poort 80, en wordt Ngen gebruikt om een cache van systeemeigen afbeeldingen van assembly's te maken.

Aanvullende bronnen

VorigeVolgende