Sdílet prostřednictvím


Definování vícekontejnerové aplikace pomocí docker-compose.yml

Tip

Tento obsah je výňatek z eBooku, architektury mikroslužeb .NET pro kontejnerizované aplikace .NET, které jsou k dispozici na .NET Docs nebo jako zdarma ke stažení PDF, které lze číst offline.

Architektura mikroslužeb .NET pro kontejnerizované eBooky aplikací .NET

V této příručce byl soubor docker-compose.yml představen v části Krok 4. Definujte služby v docker-compose.yml při vytváření vícekontenerové aplikace Dockeru. Existují však další způsoby použití souborů docker-compose, které stojí za podrobnější zkoumání.

Můžete například explicitně popsat, jak chcete v souboru docker-compose.yml nasadit aplikaci s více kontejnery. Volitelně můžete také popsat, jak budete vytvářet vlastní image Dockeru. (Vlastní image Dockeru je možné vytvořit také pomocí Rozhraní příkazového řádku Dockeru.)

V podstatě definujete každý z kontejnerů, které chcete nasadit, plus určité charakteristiky pro každé nasazení kontejneru. Jakmile máte soubor s popisem nasazení s více kontejnery, můžete celé řešení nasadit v jediné akci orchestrované příkazem rozhraní příkazového řádku docker-compose nebo ho můžete transparentně nasadit ze sady Visual Studio. Jinak byste museli pomocí rozhraní příkazového řádku Dockeru nasadit kontejner-by-container v několika krocích pomocí docker run příkazu z příkazového řádku. Proto musí každá služba definovaná v docker-compose.yml zadat přesně jednu image nebo sestavení. Další klíče jsou volitelné a jsou podobné jejich docker run protějškům příkazového řádku.

Následující kód YAML je definice možného globálního, ale jediného souboru docker-compose.yml pro ukázku eShopOnContainers. Tento kód není skutečný soubor docker-compose z eShopOnContainers. Místo toho se jedná o zjednodušenou a konsolidovanou verzi v jednom souboru, což není nejlepší způsob práce se soubory docker-compose, jak je vysvětleno později.

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

Kořenový klíč v tomto souboru je služba. V rámci tohoto klíče definujete služby, které chcete nasadit a spustit při spuštění docker-compose up příkazu nebo při nasazení ze sady Visual Studio pomocí tohoto souboru docker-compose.yml. V tomto případě má soubor docker-compose.yml definovaných více služeb, jak je popsáno v následující tabulce.

Service name Popis
webmvc Kontejner, včetně aplikace ASP.NET Core MVC, která využívá mikroslužby z C na straně serveru#
catalog-api Kontejner včetně mikroslužby webového rozhraní API služby Catalog ASP.NET Core
ordering-api Kontejner, včetně mikroslužby mikroslužby webového rozhraní API pro objednávky ASP.NET Core
sqldata Kontejner s SQL Serverem pro Linux, který drží databáze mikroslužeb
basket-api Kontejner s mikroslužbou rozhraní Basket ASP.NET Core Web API
basketdata Kontejner se službou mezipaměti REDIS s databází košíku jako mezipamětí REDIS

Jednoduchý kontejner rozhraní API webové služby

Když se zaměříte na jeden kontejner, mikroslužba catalog-api container-microservice má jednoduchou definici:

  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

Tato kontejnerizovaná služba má následující základní konfiguraci:

  • Je založená na vlastní imagi eshopu/catalog-api . Pro zjednodušení neexistuje žádné nastavení sestavení: nastavení klíče v souboru. To znamená, že image musí být dříve sestavená (s sestavením Dockeru) nebo se stáhla (pomocí příkazu docker pull) z libovolného registru Dockeru.

  • Definuje proměnnou prostředí s názvem ConnectionString s připojovací řetězec, kterou má Entity Framework použít pro přístup k instanci SYSTÉMU SQL Server, která obsahuje datový model katalogu. V tomto případě stejný kontejner SQL Serveru obsahuje více databází. Proto ve vývojovém počítači pro Docker potřebujete méně paměti. Můžete ale také nasadit jeden kontejner SQL Serveru pro každou databázi mikroslužeb.

  • Název SQL Serveru je sqldata, což je stejný název jako pro kontejner, na kterém běží instance SQL Serveru pro Linux. To je pohodlné; schopnost používat tento překlad ip adres (interní pro hostitele Dockeru) přeloží síťovou adresu, takže nemusíte znát interní IP adresu kontejnerů, ke které přistupujete z jiných kontejnerů.

Vzhledem k tomu, že připojovací řetězec je definována proměnnou prostředí, můžete tuto proměnnou nastavit pomocí jiného mechanismu a v jiném čase. Můžete například nastavit jiné připojovací řetězec při nasazování do produkčního prostředí v konečných hostitelích nebo ho provést z kanálů CI/CD v Azure DevOps Services nebo preferovaném systému DevOps.

  • Zpřístupňuje port 80 pro interní přístup ke službě catalog-api v rámci hostitele Dockeru. Hostitel je aktuálně virtuální počítač s Linuxem, protože je založený na imagi Dockeru pro Linux, ale místo toho můžete kontejner nakonfigurovat tak, aby běžel na imagi Windows.

  • Přesměruje vystavený port 80 v kontejneru na port 5101 na hostitelském počítači Dockeru (virtuální počítač s Linuxem).

  • Propojuje webovou službu se službou SQLData (instance SQL Serveru pro linuxovou databázi spuštěnou v kontejneru). Při zadání této závislosti se kontejner catalog-api nespustí, dokud kontejner sqldata již nezačne; tento aspekt je důležitý, protože rozhraní CATALOG-API musí mít nejprve spuštěnou databázi SQL Serveru. Tento druh závislosti kontejneru však v mnoha případech nestačí, protože Docker kontroluje pouze na úrovni kontejneru. Někdy nemusí být služba (v tomto případě SQL Server) připravená, proto doporučujeme implementovat logiku opakování s exponenciálním zpochybněním v mikroslužbách klienta. Pokud tedy kontejner závislostí není připravený na krátkou dobu, bude aplikace stále odolná.

  • Je nakonfigurovaná tak, aby umožňovala přístup k externím serverům: nastavení extra_hosts umožňuje přístup k externím serverům nebo počítačům mimo hostitele Dockeru (to znamená mimo výchozí virtuální počítač s Linuxem, což je vývojový hostitel Dockeru), například místní instanci SQL Serveru na vašem vývojovém počítači.

K dispozici jsou i další pokročilejší docker-compose.yml nastavení, která probereme v následujících částech.

Použití souborů docker-compose k cílení na více prostředí

Soubory docker-compose.*.yml jsou definiční soubory a mohou je používat různé infrastruktury, které tento formát chápou. Nejjednodušším nástrojem je příkaz docker-compose.

Proto můžete pomocí příkazu docker-compose cílit na následující hlavní scénáře.

Vývojová prostředí

Při vývoji aplikací je důležité mít možnost spustit aplikaci v izolovaném vývojovém prostředí. Pomocí příkazu docker-compose CLI můžete vytvořit toto prostředí nebo sadu Visual Studio, která používá docker-compose pod popisy.

Soubor docker-compose.yml umožňuje nakonfigurovat a zdokumentovat všechny závislosti služeb vaší aplikace (jiné služby, mezipaměť, databáze, fronty atd.). Pomocí příkazu rozhraní příkazového řádku docker-compose můžete vytvořit a spustit jeden nebo více kontejnerů pro každou závislost jedním příkazem (docker-compose up).

Soubory docker-compose.yml jsou konfigurační soubory interpretované modulem Dockeru, ale slouží také jako pohodlné soubory dokumentace ke složení vícekontejnerové aplikace.

Testovací prostředí

Důležitou součástí jakéhokoli procesu průběžného nasazování (CD) nebo kontinuální integrace (CI) jsou testy jednotek a integrační testy. Tyto automatizované testy vyžadují izolované prostředí, aby na nich neměli uživatelé vliv ani na žádné jiné změny dat aplikace.

Pomocí Docker Compose můžete vytvořit a zničit izolované prostředí velmi snadno v několika příkazech z příkazového řádku nebo skriptů, jako jsou následující příkazy:

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

Produkční nasazení

K nasazení do vzdáleného modulu Dockeru můžete použít také Funkci Compose. Typickým případem je nasazení do jedné instance hostitele Dockeru.

Pokud používáte jakýkoli jiný orchestrátor (například Azure Service Fabric nebo Kubernetes), možná budete muset přidat nastavení nastavení a konfigurace metadat, jako jsou v docker-compose.yml, ale ve formátu požadovaném jiným orchestrátorem.

V každém případě je docker-compose pohodlným nástrojem a formátem metadat pro vývoj, testování a produkční pracovní postupy, i když se produkční pracovní postup může u orchestrátoru, který používáte, lišit.

Použití několika souborů docker-compose ke zpracování několika prostředí

Při cílení na různá prostředí byste měli použít více souborů pro psaní zpráv. Tento přístup umožňuje vytvořit více variant konfigurace v závislosti na prostředí.

Přepsání základního souboru docker-compose

Jeden soubor docker-compose.yml můžete použít stejně jako ve zjednodušených příkladech zobrazených v předchozích částech. To se ale nedoporučuje pro většinu aplikací.

Ve výchozím nastavení compose čte dva soubory, docker-compose.yml a volitelný soubor docker-compose.override.yml. Jak je znázorněno na obrázku 6–11, když používáte Visual Studio a povolíte podporu Dockeru, Visual Studio také vytvoří další docker-compose.vs.debug.g.yml soubor pro ladění aplikace, můžete se podívat na tento soubor ve složce obj\Docker\ v hlavní složce řešení.

Soubory v projektu docker compose

Obrázek 6–11 soubory docker-compose v sadě Visual Studio 2019

struktura souboru projektu docker-compose :

  • .dockerignore – používá se k ignorování souborů.
  • docker-compose.yml – používá se k vytváření mikroslužeb
  • docker-compose.override.yml – používá se ke konfiguraci prostředí mikroslužeb.

Soubory docker-compose můžete upravit pomocí libovolného editoru, jako je Visual Studio Code nebo Sublime, a spustit aplikaci pomocí příkazu docker-compose up.

Podle konvence soubor docker-compose.yml obsahuje základní konfiguraci a další statická nastavení. To znamená, že konfigurace služby by se neměla měnit v závislosti na prostředí nasazení, na které cílíte.

Soubor docker-compose.override.yml, jak naznačuje jeho název, obsahuje nastavení konfigurace, která přepíší základní konfiguraci, například konfiguraci, která závisí na prostředí nasazení. Můžete mít také více přepsání souborů s různými názvy. Soubory přepsání obvykle obsahují další informace potřebné aplikací, ale specifické pro prostředí nebo nasazení.

Cílení na více prostředí

Typický případ použití je, když definujete více souborů pro vytváření, abyste mohli cílit na více prostředí, jako je produkční, přípravný, CI nebo vývoj. Pokud chcete tyto rozdíly podporovat, můžete konfiguraci compose rozdělit na několik souborů, jak je znázorněno na obrázku 6–12.

Diagram tří souborů docker-compose nastavených pro přepsání základního souboru

Obrázek 6–12 Více souborů docker-compose přepisuje hodnoty v základním souboru docker-compose.yml

Ke zpracování různých prostředí můžete zkombinovat několik souborů docker-compose*.yml. Začnete se základním docker-compose.yml souborem. Tento základní soubor obsahuje základní nebo statická nastavení konfigurace, která se nemění v závislosti na prostředí. Například aplikace eShopOnContainers má jako základní soubor následující docker-compose.yml soubor (zjednodušený s menším počtem služeb).

#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

Hodnoty v základním souboru docker-compose.yml by se neměly měnit kvůli různým cílovým prostředím nasazení.

Pokud se například zaměříte na definici služby webmvc, uvidíte, jak jsou informace mnohem stejné bez ohledu na to, jaké prostředí byste mohli cílit. Máte následující informace:

  • Název služby: webmvc.

  • Vlastní image kontejneru: eshop/webmvc.

  • Příkaz k sestavení vlastní image Dockeru označující, který soubor Dockerfile se má použít.

  • Závislosti na jiných službách, takže se tento kontejner nespustí, dokud ostatní kontejnery závislostí nezačnou.

Můžete mít další konfiguraci, ale důležitým bodem je, že v základním docker-compose.yml souboru chcete jenom nastavit informace, které jsou společné v různých prostředích. Potom byste v docker-compose.override.yml nebo podobných souborech pro produkční nebo pracovní prostředí měli umístit konfiguraci specifickou pro každé prostředí.

Obvykle se docker-compose.override.yml používá pro vaše vývojové prostředí, jak je znázorněno v následujícím příkladu z 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"

V tomto příkladu konfigurace přepsání vývoje zveřejňuje některé porty hostiteli, definuje proměnné prostředí s adresami URL přesměrování a určuje připojovací řetězec pro vývojové prostředí. Tato nastavení jsou určená jenom pro vývojové prostředí.

Když spustíte (nebo ho spustíte docker-compose up ze sady Visual Studio), příkaz přečte přepsání automaticky, jako by slučoval oba soubory.

Předpokládejme, že chcete jiný soubor Compose pro produkční prostředí s různými hodnotami konfigurace, porty nebo připojovací řetězec. Můžete vytvořit další soubor přepsání, například soubor s názvem docker-compose.prod.yml s různými nastaveními a proměnnými prostředí. Tento soubor může být uložený v jiném úložišti Git nebo spravovaný a zabezpečený jiným týmem.

Postup nasazení s konkrétním souborem přepsání

Pokud chcete použít více přepsání souborů nebo přepsání souboru s jiným názvem, můžete použít možnost -f s příkazem docker-compose a určit soubory. Vytváření slučuje soubory v pořadí, v jakém jsou zadané na příkazovém řádku. Následující příklad ukazuje, jak nasadit s přepsání souborů.

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

Použití proměnných prostředí v souborech docker-compose

Je to praktické, zejména v produkčních prostředích, aby bylo možné získat informace o konfiguraci z proměnných prostředí, jak jsme si ukázali v předchozích příkladech. Na proměnnou prostředí v souborech docker-compose můžete odkazovat pomocí syntaxe ${MY_VAR}. Následující řádek ze souboru docker-compose.prod.yml ukazuje, jak odkazovat na hodnotu proměnné prostředí.

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

Proměnné prostředí se vytvářejí a inicializují různými způsoby v závislosti na vašem hostitelském prostředí (Linux, Windows, cloudový cluster atd.). Pohodlným přístupem je však použití souboru .env. Soubory docker-compose podporují deklarování výchozích proměnných prostředí v souboru .env. Tyto hodnoty proměnných prostředí jsou výchozími hodnotami. Můžete je ale přepsat hodnotami, které jste mohli definovat v každém z vašich prostředí (hostitelský operační systém nebo proměnné prostředí z clusteru). Tento soubor .env umístíte do složky, ze které se spustí příkaz docker-compose.

Následující příklad ukazuje soubor .env, jako je soubor .env pro aplikaci 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 očekává, že každý řádek v souboru .env bude ve formátu <variable>=<value>.

Hodnoty nastavené v prostředí za běhu vždy přepíší hodnoty definované v souboru .env. Podobně hodnoty předané prostřednictvím argumentů příkazového řádku také přepíší výchozí hodnoty nastavené v souboru .env.

Další materiály

Sestavování optimalizovaných imagí Dockeru ASP.NET Core

Pokud zkoumáte Docker a .NET na zdrojích na internetu, najdete soubory Dockerfile, které demonstrují jednoduchost vytváření image Dockeru zkopírováním zdroje do kontejneru. Tyto příklady naznačují, že pomocí jednoduché konfigurace můžete mít image Dockeru s prostředím zabaleným ve vaší aplikaci. Následující příklad ukazuje jednoduchý soubor Dockerfile v tomto vein.

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

Soubor Dockerfile bude fungovat takto. Image ale můžete podstatně optimalizovat, zejména produkční image.

V modelu kontejnerů a mikroslužeb neustále spouštíte kontejnery. Typický způsob použití kontejnerů nerestartuje kontejner spánku, protože kontejner je uvolnitelný. Orchestrátory (například Kubernetes a Azure Service Fabric) vytvářejí nové instance imagí. To znamená, že byste museli optimalizovat předkompilováním aplikace při vytváření, aby proces vytváření instancí byl rychlejší. Po spuštění kontejneru by měl být připravený ke spuštění. Neobnovujte a kompilujte za běhu pomocí dotnet restore příkazů a dotnet build příkazů rozhraní příkazového řádku, jak můžete vidět v blogových příspěvcích o .NET a Dockeru.

Tým .NET dělá důležitou práci, aby .NET a ASP.NET Core architekturu optimalizovanou pro kontejnery. Jedná se nejen o zjednodušenou architekturu .NET s malými nároky na paměť; tým se zaměřil na optimalizované image Dockeru pro tři hlavní scénáře a publikoval je v registru Docker Hubu v dotnet/, počínaje verzí 2.1:

  • Vývoj: Prioritou je schopnost rychle iterovat a ladit změny a kde je velikost sekundární.
  • Sestavení: Prioritou je kompilace aplikace a image obsahuje binární soubory a další závislosti pro optimalizaci binárních souborů.
  • Produkce: Fokus je rychlé nasazování a spouštění kontejnerů, takže tyto image jsou omezené na binární soubory a obsah potřebný ke spuštění aplikace.

Tým .NET poskytuje některé základní varianty v dotnet/, například:

  • sdk: pro scénáře vývoje a sestavení
  • aspnet: pro ASP.NET produkční scénáře
  • runtime: pro produkční scénáře .NET
  • runtime-deps: pro produkční scénáře samostatných aplikací

V případě rychlejšího spuštění image modul runtime také automaticky nastaví aspnetcore_urls na port 80 a pomocí nástroje Ngen vytvoříte nativní mezipaměť bitových kopií sestavení.

Další materiály