Definiera ditt program med flera containrar med docker-compose.yml

Artikel
08/16/2024

Dricks

Det här innehållet är ett utdrag från eBook, .NET Microservices Architecture for Containerized .NET Applications, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.

Ladda ned PDF

I den här guiden introducerades docker-compose.yml-filen i avsnittet Steg 4. Definiera dina tjänster i docker-compose.yml när du skapar ett Docker-program med flera containrar. Det finns dock ytterligare sätt att använda docker-compose-filerna som är värda att utforska närmare.

Du kan till exempel uttryckligen beskriva hur du vill distribuera ditt program med flera containrar i docker-compose.yml-filen. Du kan också beskriva hur du ska skapa dina anpassade Docker-avbildningar. (Anpassade Docker-avbildningar kan också skapas med Docker CLI.)

I grund och botten definierar du var och en av de containrar som du vill distribuera plus vissa egenskaper för varje containerdistribution. När du har en beskrivningsfil för distribution av flera containrar kan du distribuera hela lösningen i en enda åtgärd som samordnas av CLI-kommandot docker-compose , eller så kan du distribuera den transparent från Visual Studio. Annars skulle du behöva använda Docker CLI för att distribuera container för container i flera steg med hjälp docker run av kommandot från kommandoraden. Därför måste varje tjänst som definieras i docker-compose.yml ange exakt en avbildning eller version. Andra nycklar är valfria och motsvarar deras docker run kommandoradsmotsvarigheter.

Följande YAML-kod är definitionen av en möjlig global men enskild docker-compose.yml fil för exemplet eShopOnContainers. Den här koden är inte den faktiska docker-compose-filen från eShopOnContainers. I stället är det en förenklad och konsoliderad version i en enda fil, vilket inte är det bästa sättet att arbeta med docker-compose-filer, vilket förklaras senare.

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

Rotnyckeln i den här filen är tjänster. Under den nyckeln definierar du de tjänster som du vill distribuera och köra när du kör docker-compose up kommandot eller när du distribuerar från Visual Studio med hjälp av den här docker-compose.yml filen. I det här fallet har docker-compose.yml-filen flera definierade tjänster, enligt beskrivningen i följande tabell.

Servicenamn	beskrivning
webmvc	Container inklusive ASP.NET Core MVC-programmet som använder mikrotjänster från serversidan C#
catalog-api	Container, inklusive mikrotjänsten Catalog ASP.NET Core Web API
ordering-api	Container, inklusive mikrotjänsten Ordering ASP.NET Core Web API
sqldata	Container som kör SQL Server för Linux och som innehåller mikrotjänstdatabaserna
basket-api	Container med mikrotjänsten Basket ASP.NET Core Web API
basketdata	Container som kör REDIS-cachetjänsten med korgdatabasen som redis-cache

En enkel WEBBTJÄNST-API-container

Med fokus på en enda container har tjänsten catalog-api container-microservice en enkel definition:

  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

Den här containerbaserade tjänsten har följande grundläggande konfiguration:

Den baseras på den anpassade avbildningen eshop/catalog-api . För enkelhetens skull finns det ingen version: nyckelinställning i filen. Det innebär att avbildningen måste ha skapats tidigare (med docker build) eller har laddats ned (med docker-pull-kommandot) från alla Docker-register.
Den definierar en miljövariabel med namnet ConnectionString med den niska veze som ska användas av Entity Framework för att komma åt SQL Server-instansen som innehåller katalogdatamodellen. I det här fallet innehåller samma SQL Server-container flera databaser. Därför behöver du mindre minne i utvecklingsdatorn för Docker. Du kan dock även distribuera en SQL Server-container för varje mikrotjänstdatabas.
SQL Server-namnet är sqldata, som är samma namn som används för containern som kör SQL Server-instansen för Linux. Detta är praktiskt; Att kunna använda den här namnmatchningen (intern för Docker-värden) löser nätverksadressen så att du inte behöver känna till den interna IP-adressen för de containrar som du kommer åt från andra containrar.

Eftersom niska veze definieras av en miljövariabel kan du ange variabeln via en annan mekanism och vid en annan tidpunkt. Du kan till exempel ange en annan niska veze när du distribuerar till produktion i de sista värdarna, eller genom att göra det från dina CI/CD-pipelines i Azure DevOps Services eller ditt önskade DevOps-system.

Den exponerar port 80 för intern åtkomst till tjänsten catalog-api i Docker-värden. Värden är för närvarande en virtuell Linux-dator eftersom den är baserad på en Docker-avbildning för Linux, men du kan konfigurera containern så att den körs på en Windows-avbildning i stället.
Den vidarebefordrar den exponerade port 80 på containern till port 5101 på Docker-värddatorn (den virtuella Linux-datorn).
Den länkar webbtjänsten till sqldata-tjänsten (SQL Server-instansen för Linux-databasen som körs i en container). När du anger det här beroendet startar inte containern catalog-api förrän sqldata-containern redan har startat. Den här aspekten är viktig eftersom catalog-api måste ha SQL Server-databasen igång först. Den här typen av containerberoende räcker dock inte i många fall, eftersom Docker endast kontrollerar på containernivå. Ibland kanske tjänsten (i det här fallet SQL Server) fortfarande inte är redo, så det är lämpligt att implementera återförsökslogik med exponentiell backoff i klientmikrotjänsterna. På så sätt är programmet fortfarande motståndskraftigt om en beroendecontainer inte är redo under en kort tid.
Den är konfigurerad för att tillåta åtkomst till externa servrar: med inställningen extra_hosts kan du komma åt externa servrar eller datorer utanför Docker-värden (det vill säga utanför den virtuella Linux-standarddatorn, som är en Docker-värd för utveckling), till exempel en lokal SQL Server-instans på utvecklingsdatorn.

Det finns även andra, mer avancerade docker-compose.yml inställningar som vi kommer att diskutera i följande avsnitt.

Använda docker-compose-filer för att rikta in sig på flera miljöer

Filerna docker-compose.*.yml är definitionsfiler och kan användas av flera infrastrukturer som förstår det formatet. Det enklaste verktyget är kommandot docker-compose.

Genom att använda kommandot docker-compose kan du därför rikta in dig på följande huvudscenarier.

Utvecklingsmiljöer

När du utvecklar program är det viktigt att kunna köra ett program i en isolerad utvecklingsmiljö. Du kan använda CLI-kommandot docker-compose för att skapa den miljön eller Visual Studio, som använder docker-compose under täcket.

Med docker-compose.yml-filen kan du konfigurera och dokumentera alla programtjänstberoenden (andra tjänster, cacheminnen, databaser, köer osv.). Med kommandot docker-compose CLI kan du skapa och starta en eller flera containrar för varje beroende med ett enda kommando (docker-compose up).

De docker-compose.yml filerna är konfigurationsfiler som tolkas av Docker-motorn men fungerar också som praktiska dokumentationsfiler om sammansättningen av ditt program med flera containrar.

Testa miljöer

En viktig del av alla processer för kontinuerlig distribution (CD) eller kontinuerlig integrering (CI) är enhetstester och integreringstester. Dessa automatiserade tester kräver en isolerad miljö så att de inte påverkas av användarna eller någon annan ändring i programmets data.

Med Docker Compose kan du skapa och förstöra den isolerade miljön mycket enkelt i några få kommandon från kommandotolken eller skripten, som följande kommandon:

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

Produktionsdistributioner

Du kan också använda Compose för att distribuera till en fjärransluten Docker-motor. Ett vanligt fall är att distribuera till en enda Docker-värdinstans.

Om du använder någon annan orkestrerare (till exempel Azure Service Fabric eller Kubernetes) kan du behöva lägga till konfigurationsinställningar för installation och metadata som de i docker-compose.yml, men i det format som krävs av den andra dirigeratorn.

Docker-compose är i alla fall ett praktiskt verktyg och metadataformat för arbetsflöden för utveckling, testning och produktion, även om produktionsarbetsflödet kan variera på den orkestrering du använder.

Använda flera docker-compose-filer för att hantera flera miljöer

När du riktar in dig på olika miljöer bör du använda flera skrivfiler. Med den här metoden kan du skapa flera konfigurationsvarianter beroende på miljön.

Åsidosätta bas docker-compose-filen

Du kan använda en enda docker-compose.yml fil som i de förenklade exemplen som visas i föregående avsnitt. Det rekommenderas dock inte för de flesta program.

Som standard läser Compose två filer, en docker-compose.yml och en valfri docker-compose.override.yml fil. Som du ser i bild 6–11, när du använder Visual Studio och aktiverar Docker-stöd, skapar Visual Studio även ytterligare en docker-compose.vs.debug.g.yml fil för felsökning av programmet. Du kan ta en titt på den här filen i mappen obj\Docker\ i huvudlösningsmappen.

Filer i ett docker compose-projekt.

Bild 6-11. docker-compose-filer i Visual Studio 2019

docker-compose-projektfilstruktur :

.dockerignore – används för att ignorera filer
docker-compose.yml – används för att skapa mikrotjänster
docker-compose.override.yml – används för att konfigurera mikrotjänstmiljön

Du kan redigera docker-compose-filerna med valfri redigerare, till exempel Visual Studio Code eller Sublime, och köra programmet med kommandot docker-compose up.

Enligt konventionen innehåller docker-compose.yml-filen din baskonfiguration och andra statiska inställningar. Det innebär att tjänstkonfigurationen inte bör ändras beroende på vilken distributionsmiljö du riktar in dig på.

Den docker-compose.override.yml filen innehåller, som namnet antyder, konfigurationsinställningar som åsidosätter baskonfigurationen, till exempel konfiguration som är beroende av distributionsmiljön. Du kan också ha flera åsidosättningsfiler med olika namn. Åsidosättningsfilerna innehåller vanligtvis ytterligare information som krävs av programmet men som är specifik för en miljö eller en distribution.

Rikta in sig på flera miljöer

Ett vanligt användningsfall är när du definierar flera skrivfiler så att du kan rikta in dig på flera miljöer, till exempel produktion, mellanlagring, CI eller utveckling. För att stödja dessa skillnader kan du dela upp din Compose-konfiguration i flera filer, enligt bild 6–12.

Diagram över tre docker-compose-filer som angetts för att åsidosätta basfilen.

Bild 6-12. Flera docker-compose-filer som åsidosättar värden i basfilen docker-compose.yml

Du kan kombinera flera docker-compose*.yml-filer för att hantera olika miljöer. Du börjar med basfilen docker-compose.yml. Den här basfilen innehåller de grundläggande eller statiska konfigurationsinställningarna som inte ändras beroende på miljön. Till exempel har eShopOnContainers-appen följande docker-compose.yml fil (förenklad med färre tjänster) som basfil.

#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

Värdena i den grundläggande docker-compose.yml filen bör inte ändras på grund av olika måldistributionsmiljöer.

Om du till exempel fokuserar på webbmvc-tjänstdefinitionen kan du se hur den informationen är ungefär densamma oavsett vilken miljö du riktar in dig på. Du har följande information:

Tjänstnamnet: webmvc.
Containerns anpassade avbildning: eshop/webmvc.
Kommandot för att skapa den anpassade Docker-avbildningen som anger vilken Dockerfile som ska användas.
Beroenden för andra tjänster, så den här containern startar inte förrän de andra beroendecontainrarna har startats.

Du kan ha ytterligare konfiguration, men den viktiga punkten är att i basfilen docker-compose.yml vill du bara ange den information som är gemensam i olika miljöer. I docker-compose.override.yml eller liknande filer för produktion eller mellanlagring bör du sedan placera konfiguration som är specifik för varje miljö.

Vanligtvis används docker-compose.override.yml för din utvecklingsmiljö, som i följande exempel från 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"

I det här exemplet exponerar konfigurationen för åsidosättning av utveckling vissa portar för värden, definierar miljövariabler med omdirigerings-URL:er och anger niska veze för utvecklingsmiljön. De här inställningarna är bara för utvecklingsmiljön.

När du kör docker-compose up (eller startar den från Visual Studio) läser kommandot åsidosättningarna automatiskt som om de sammanfogade båda filerna.

Anta att du vill ha en till Compose-fil för produktionsmiljön med olika konfigurationsvärden, portar eller niska veze. Du kan skapa en annan åsidosättningsfil, till exempel en fil med namnet docker-compose.prod.yml med olika inställningar och miljövariabler. Filen kan lagras på en annan Git-lagringsplats eller hanteras och skyddas av ett annat team.

Distribuera med en specifik åsidosättningsfil

Om du vill använda flera åsidosättningsfiler eller en åsidosättningsfil med ett annat namn kan du använda alternativet -f med kommandot docker-compose och ange filerna. Skriv sammanfogar filer i den ordning de anges på kommandoraden. I följande exempel visas hur du distribuerar med åsidosättningsfiler.

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

Använda miljövariabler i docker-compose-filer

Det är praktiskt, särskilt i produktionsmiljöer, att kunna hämta konfigurationsinformation från miljövariabler, som vi har visat i tidigare exempel. Du kan referera till en miljövariabel i docker-compose-filerna med syntaxen ${MY_VAR}. Följande rad från en docker-compose.prod.yml-fil visar hur du refererar till värdet för en miljövariabel.

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

Miljövariabler skapas och initieras på olika sätt, beroende på din värdmiljö (Linux, Windows, molnkluster osv.). En praktisk metod är dock att använda en .env-fil. Docker-compose-filerna har stöd för att deklarera standardmiljövariabler i .env-filen. Dessa värden för miljövariablerna är standardvärdena. Men de kan åsidosättas av de värden som du kanske har definierat i var och en av dina miljöer (värdoperativsystem eller miljövariabler från klustret). Du placerar den här .env-filen i mappen där kommandot docker-compose körs från.

I följande exempel visas en .env-fil som .env-filen för eShopOnContainers-programmet.

# .env file

ESHOP_EXTERNAL_DNS_NAME_OR_IP=host.docker.internal

ESHOP_PROD_EXTERNAL_DNS_NAME_OR_IP=10.121.122.92

Docker-compose förväntar sig att varje rad i en .env-fil ska vara i formatet <variable>=<value>.

Värdena som anges i körningsmiljön åsidosätter alltid de värden som definierats i .env-filen. På liknande sätt åsidosätter värden som skickas via kommandoradsargument även de standardvärden som anges i .env-filen.

Ytterligare resurser

Översikt över Docker Compose
https://docs.docker.com/compose/overview/
Flera Skriv-filer
https://docs.docker.com/compose/multiple-compose-files/

Skapa optimerade ASP.NET Core Docker-avbildningar

Om du utforskar Docker och .NET på källor på Internet hittar du Dockerfiles som visar enkelheten i att skapa en Docker-avbildning genom att kopiera källan till en container. De här exemplen tyder på att du med hjälp av en enkel konfiguration kan ha en Docker-avbildning med miljön paketerad med ditt program. I följande exempel visas en enkel Dockerfile i den här venen.

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

En Dockerfile som den här fungerar. Du kan dock avsevärt optimera dina bilder, särskilt dina produktionsbilder.

I container- och mikrotjänstmodellen startar du ständigt containrar. Det vanliga sättet att använda containrar startar inte om en vilocontainer eftersom containern är disponibel. Orchestrators (som Kubernetes och Azure Service Fabric) skapar nya instanser av bilder. Det innebär att du skulle behöva optimera genom att förkompilera programmet när det skapas så att instansieringsprocessen blir snabbare. När containern startas bör den vara redo att köras. Återställ inte och kompilera inte vid körning med hjälp av dotnet restore CLI-kommandona och dotnet build som du kan se i blogginlägg om .NET och Docker.

.NET-teamet har gjort ett viktigt arbete för att göra .NET och ASP.NET Core till ett containeroptimerad ramverk. .NET är inte bara ett lättviktsramverk med ett litet minnesavtryck. teamet har fokuserat på optimerade Docker-avbildningar för tre huvudscenarier och publicerat dem i Docker Hub-registret på dotnet/, från och med version 2.1:

Utveckling: Prioriteten är möjligheten att snabbt iterera och felsöka ändringar och var storleken är sekundär.
Build: Prioriteten är att kompilera programmet och avbildningen innehåller binärfiler och andra beroenden för att optimera binärfiler.
Produktion: Fokus är snabb distribution och start av containrar, så dessa avbildningar är begränsade till de binärfiler och innehåll som behövs för att köra programmet.

.NET-teamet tillhandahåller några grundläggande varianter i dotnet/, till exempel:

sdk: för utvecklings- och byggscenarier
aspnet: för ASP.NET produktionsscenarier
runtime: för .NET-produktionsscenarier
runtime-deps: för produktionsscenarier för fristående program

För snabbare start anger körningsavbildningar också automatiskt aspnetcore_urls till port 80 och använder Ngen för att skapa en intern avbildningscache med sammansättningar.

Ytterligare resurser

Skapa optimerade Docker-avbildningar med ASP.NET Corehttps://learn.microsoft.com/archive/blogs/stevelasker/building-optimized-docker-images-with-asp-net-core
Skapa Docker-avbildningar för .NET-programhttps://learn.microsoft.com/dotnet/core/docker/building-net-docker-images

Föregående Nästa

Dela via

Definiera ditt program med flera containrar med docker-compose.yml

En enkel WEBBTJÄNST-API-container

Använda docker-compose-filer för att rikta in sig på flera miljöer

Utvecklingsmiljöer

Testa miljöer

Produktionsdistributioner

Använda flera docker-compose-filer för att hantera flera miljöer

Åsidosätta bas docker-compose-filen

Rikta in sig på flera miljöer

Distribuera med en specifik åsidosättningsfil

Använda miljövariabler i docker-compose-filer

Ytterligare resurser

Skapa optimerade ASP.NET Core Docker-avbildningar

Ytterligare resurser

Ytterligare resurser