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.
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í.
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.
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
Přehled Docker Compose
https://docs.docker.com/compose/overview/Více souborů pro psaní zpráv
https://docs.docker.com/compose/multiple-compose-files/
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
Sestavování optimalizovaných imagí Dockeru pomocí ASP.NET Corehttps://learn.microsoft.com/archive/blogs/stevelasker/building-optimized-docker-images-with-asp-net-core
Vytváření imagí Dockeru pro aplikace .NEThttps://learn.microsoft.com/dotnet/core/docker/building-net-docker-images