Többtárolós alkalmazás definiálása docker-compose.yml

Tipp.

Ez a tartalom egy részlet a .NET-alkalmazásokhoz készült .NET-alkalmazásokhoz készült eBook, .NET Microservices Architecture című eBookból, amely elérhető a .NET Docs-on vagy egy ingyenesen letölthető PDF-fájlként, amely offline módban is olvasható.

PDF letöltése

Ebben az útmutatóban a docker-compose.yml fájl a 4. lépésben lett bevezetve. A szolgáltatások definiálása docker-compose.yml többtárolós Docker-alkalmazás létrehozásakor. Vannak azonban további módszerek a docker-compose fájlok használatára, amelyeket érdemes részletesebben megvizsgálni.

Például explicit módon leírhatja, hogyan szeretné üzembe helyezni a többtárolós alkalmazást a docker-compose.yml fájlban. Emellett azt is leírhatja, hogyan fogja létrehozni az egyéni Docker-rendszerképeket. (Az egyéni Docker-rendszerképek a Docker parancssori felületével is felépíthetők.)

Alapvetően definiálja az üzembe helyezni kívánt tárolókat, valamint az egyes tárolótelepítések bizonyos jellemzőit. Ha már rendelkezik egy többtárolós üzembe helyezési leírásfájllal, a teljes megoldást egyetlen műveletben helyezheti üzembe, amelyet a docker-compose up CLI parancs vezényl, vagy transzparensen üzembe helyezheti a Visual Studióból. Ellenkező esetben a Docker parancssori felületével több lépésben is üzembe kell helyeznie a tárolónkénti tárolót a docker run parancssorból származó paranccsal. Ezért minden docker-compose.yml definiált szolgáltatásnak pontosan egy rendszerképet vagy buildet kell megadnia. Más kulcsok nem kötelezőek, és hasonlóak a parancssori megfelelőikhez docker run .

Az alábbi YAML-kód az eShopOnContainers-minta egy lehetséges globális, de egyetlen docker-compose.yml fájljának definíciója. Ez a kód nem az eShopOnContainers tényleges docker-compose fájlja. Ehelyett ez egy egyszerűsített és konszolidált verzió egyetlen fájlban, amely nem a legjobb módszer a docker-compose fájlok használatára, amint azt később ismertetjük.

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

A fájl gyökérkulcsa a szolgáltatások. A kulcs alatt megadhatja azokat a szolgáltatásokat, amelyeket a parancs végrehajtásakor vagy a Visual Studióból való üzembe helyezéskor szeretne üzembe helyezni és futtatni ezzel a docker-compose up docker-compose.yml fájllal. Ebben az esetben a docker-compose.yml fájl több szolgáltatást is definiál, az alábbi táblázatban leírtak szerint.

Szolgáltatás neve	Leírás
webmvc	Tároló, beleértve a ASP.NET Core MVC-alkalmazást, amely a mikroszolgáltatásokat a kiszolgálóoldali C-ből fogyasztja#
catalog-api	Tároló, beleértve a Katalógus ASP.NET Core Web API-mikroszolgáltatást
ordering-api	Tároló, beleértve az Ordering ASP.NET Core Web API mikroszolgáltatást
sqldata	Linuxhoz készült SQL Servert futtató tároló, amely a mikroszolgáltatási adatbázisokat tartja fogva
basket-api	Tároló a Basket ASP.NET Core Web API mikroszolgáltatással
basketdata	A REDIS cache szolgáltatást futtató tároló, a kosáradatbázissal REDIS-gyorsítótárként

Egy egyszerű Web Service API-tároló

Egyetlen tárolóra összpontosítva a catalog-api container-microservice egyszerű definícióval rendelkezik:

  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

Ez a tárolóalapú szolgáltatás az alábbi alapkonfigurációval rendelkezik:

• Ez az egyéni eshop/catalog-api rendszerképen alapul. Az egyszerűség kedvéért nincs build: kulcsbeállítás a fájlban. Ez azt jelenti, hogy a rendszerképnek korábban (a Docker buildel együtt) vagy (a Docker lekéréses parancsával) le kell töltenie bármelyik Docker-beállításjegyzékből.

• Egy ConnectionString nevű környezeti változót határoz meg azzal a kapcsolati sztring, amelyet az Entity Framework használ a katalógusadatmodellt tartalmazó SQL Server-példány eléréséhez. Ebben az esetben ugyanaz az SQL Server-tároló több adatbázist is tárol. Ezért kevesebb memóriára van szüksége a Docker fejlesztői gépében. Az egyes mikroszolgáltatási adatbázisokhoz azonban egy SQL Server-tárolót is üzembe helyezhet.

• Az SQL Server neve sqldata, amely ugyanazt a nevet használja a linuxos SQL Server-példányt futtató tárolóhoz. Ez kényelmes; Ha képes használni ezt a névfeloldást (a Docker-gazdagépen belül), az feloldja a hálózati címet, így nem kell tudnia a más tárolókból elért tárolók belső IP-címét.

Mivel a kapcsolati sztring egy környezeti változó határozza meg, ezt a változót egy másik mechanizmussal és más időpontban állíthatja be. Beállíthat például egy másik kapcsolati sztring, amikor a végső gazdagépeken üzemel az éles környezetben, vagy az Azure DevOps Services CI-/CD-folyamataiban vagy az előnyben részesített DevOps-rendszerben.

• A 80-es portot teszi elérhetővé a Catalog-API szolgáltatáshoz való belső hozzáféréshez a Docker-gazdagépen belül. A gazdagép jelenleg Linux rendszerű virtuális gép, mivel linuxos Docker-rendszerképen alapul, de a tárolót windowsos rendszerképen való futtatásra konfigurálhatja.

• Továbbítja a tárolón lévő 80-at a Docker-gazdagépen (a Linux rendszerű virtuális gépen) lévő 5101-s portra.

• Összekapcsolja a webszolgáltatást az sqldata szolgáltatással (a tárolóban futó Linux-adatbázis SQL Server-példányával). A függőség megadásakor a catalog-api tároló csak akkor indul el, ha az sqldata-tároló már elindult; ez a szempont azért fontos, mert a catalog-api-nak először az SQL Server-adatbázist kell futtatnia. Az ilyen típusú tárolófüggőség azonban sok esetben nem elegendő, mert a Docker csak a tároló szintjén ellenőrzi. Előfordulhat, hogy a szolgáltatás (ebben az esetben az SQL Server) még mindig nem áll készen, ezért célszerű az újrapróbálkozási logikát exponenciális visszalépéssel implementálni az ügyfél mikroszolgáltatásaiban. Így ha egy függőségi tároló rövid ideig nem áll készen, az alkalmazás továbbra is rugalmas lesz.

• Úgy van konfigurálva, hogy engedélyezze a külső kiszolgálókhoz való hozzáférést: a extra_hosts beállítás lehetővé teszi, hogy külső kiszolgálókat vagy gépeket érhessen el a Docker-gazdagépen kívül (azaz az alapértelmezett Linux rendszerű virtuális gépen kívül, amely egy fejlesztői Docker-gazdagép), például egy helyi SQL Server-példányt a fejlesztői számítógépen.

A következő szakaszokban további, speciálisabb docker-compose.yml beállításokat is bemutatunk.

Docker-compose-fájlok használata több környezet megcélzásához

A docker-compose.*.yml fájlok definíciós fájlok, és több olyan infrastruktúra is használhatja, amelyek megértik ezt a formátumot. A legegyszerűbb eszköz a docker-compose parancs.

Ezért a docker-compose paranccsal a következő fő forgatókönyveket célozhatja meg.

Fejlesztői környezetek

Alkalmazások fejlesztésekor fontos, hogy egy alkalmazást izolált fejlesztési környezetben lehessen futtatni. A docker-compose CLI paranccsal létrehozhatja azt a környezetet vagy a Visual Studiót, amely docker-compose-t használ a borítók alatt.

A docker-compose.yml fájl lehetővé teszi az alkalmazás összes szolgáltatásfüggőségének (egyéb szolgáltatások, gyorsítótárak, adatbázisok, üzenetsorok stb.) konfigurálását és dokumentálását. A docker-compose CLI paranccsal létrehozhat és elindíthat egy vagy több tárolót minden függőséghez egyetlen paranccsal (docker-compose up).

A docker-compose.yml fájlok a Docker motor által értelmezett konfigurációs fájlok, de kényelmes dokumentációs fájlokként is szolgálnak a többtárolós alkalmazás összetételéről.

Tesztelési környezetek

A folyamatos üzembe helyezés (CD) vagy a folyamatos integrációs (CI) folyamatok fontos része az egységtesztek és az integrációs tesztek. Ezek az automatizált tesztek izolált környezetet igényelnek, hogy a felhasználók ne befolyásolják őket, illetve az alkalmazás adataiban bekövetkező egyéb változásokat.

A Docker Compose használatával nagyon könnyen létrehozhatja és megsemmisítheti ezt az elszigetelt környezetet a parancssorból vagy szkriptekből származó néhány parancsban, például a következő parancsokkal:

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

Éles környezetek

A Compose használatával távoli Docker-motoron is üzembe helyezheti azokat. Általában egyetlen Docker-gazdagéppéldányon kell üzembe helyezni.

Ha más vezénylőt (például Azure Service Fabricet vagy Kubernetes-t) használ, előfordulhat, hogy hozzá kell adnia a beállítási és metaadat-konfigurációs beállításokat, például a docker-compose.yml, de a másik vezénylő által megkövetelt formátumban.

Mindenesetre a docker-compose egy kényelmes eszköz- és metaadat-formátum a fejlesztési, tesztelési és éles munkafolyamatokhoz, bár az éles munkafolyamat a használt vezénylőtől eltérő lehet.

Több docker-compose fájl használata több környezet kezeléséhez

Ha különböző környezeteket céloz meg, több írási fájlt kell használnia. Ez a módszer lehetővé teszi, hogy a környezettől függően több konfigurációs változatot is létrehozhasson.

Az alap docker-compose fájl felülírása

Egyetlen docker-compose.yml fájlt is használhat, ahogyan az előző szakaszokban bemutatott egyszerűsített példákban is látható. Ez azonban a legtöbb alkalmazás esetében nem ajánlott.

Alapértelmezés szerint a Compose két fájlt, egy docker-compose.yml és egy opcionális docker-compose.override.yml fájlt olvas be. Ahogy a 6–11. ábrán látható, a Visual Studio használata és a Docker-támogatás engedélyezése esetén a Visual Studio egy további docker-compose.vs.debug.g.yml fájlt is létrehoz az alkalmazás hibakereséséhez, ezt a fájlt a fő megoldásmappában, az obj\Docker\ mappában tekintheti meg.

6–11. ábra. docker-compose fájlok a Visual Studio 2019-ben

docker-compose projektfájl-struktúra:

• .dockerignore – fájlok figyelmen kívül hagyására szolgál
• docker-compose.yml – mikroszolgáltatások írására szolgál
• docker-compose.override.yml – mikroszolgáltatási környezet konfigurálására szolgál

A docker-compose fájlokat bármely szerkesztővel szerkesztheti, például a Visual Studio Code-ot vagy a Sublime-t, és futtathatja az alkalmazást a docker-compose up paranccsal.

Konvenció szerint a docker-compose.yml fájl tartalmazza az alapkonfigurációt és az egyéb statikus beállításokat. Ez azt jelenti, hogy a szolgáltatáskonfiguráció nem változhat a megcélzott üzemi környezettől függően.

A docker-compose.override.yml fájl, ahogy a neve is sugallja, olyan konfigurációs beállításokat tartalmaz, amelyek felülírják az alapkonfigurációt, például az üzembehelyezési környezettől függő konfigurációt. Több különböző nevű felülbírálási fájl is lehet. A felülbírálási fájlok általában az alkalmazás által igényelt, de a környezetre vagy az üzembe helyezésre vonatkozó további információkat tartalmaznak.

Több környezet megcélzása

Tipikus használati eset, ha több levélírási fájlt határoz meg, hogy több környezetet célozzon meg, például az éles környezetet, az előkészítést, a CI-t vagy a fejlesztést. A különbségek támogatásához a Compose-konfigurációt több fájlra oszthatja, ahogyan az a 6–12. ábrán látható.

6–12. ábra. Több docker-compose fájl, amely felülírja az alap docker-compose.yml fájl értékeit

A különböző környezetek kezeléséhez több docker-compose*.yml fájlt is kombinálhat. Az alap docker-compose.yml fájllal kell kezdenie. Ez az alapfájl tartalmazza azokat az alap- vagy statikus konfigurációs beállításokat, amelyek a környezettől függően nem változnak. Az eShopOnContainers alkalmazás például az alábbi docker-compose.yml fájllal rendelkezik (kevesebb szolgáltatással egyszerűsítve), mint alapfájl.

#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

Az alap docker-compose.yml fájl értékei nem módosíthatók a különböző céltelepítési környezetek miatt.

Ha például a webmvc szolgáltatásdefinícióra összpontosít, láthatja, hogy ez az információ mennyire azonos, függetlenül attól, hogy milyen környezetet céloz meg. A következő információval rendelkezik:

• A szolgáltatás neve: webmvc.

• A tároló egyéni képe: eshop/webmvc.

• Az egyéni Docker-rendszerkép összeállítására szolgáló parancs, amely azt jelzi, hogy melyik Docker-fájlt kell használni.

• Más szolgáltatások függőségei, ezért ez a tároló csak a többi függőségi tároló elindításáig indul el.

További konfigurációval is rendelkezhet, de a lényeg az, hogy az alap docker-compose.yml fájlban csak a környezetekben gyakori információkat szeretné beállítani. Ezután az éles vagy átmeneti docker-compose.override.yml vagy hasonló fájlokban az egyes környezetekhez tartozó konfigurációt kell elhelyeznie.

A docker-compose.override.yml általában a fejlesztési környezethez használják, ahogyan az eShopOnContainers alábbi példájában is látható:

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

Ebben a példában a fejlesztési felülbírálási konfiguráció elérhetővé tesz néhány portot a gazdagépnek, a környezeti változókat átirányítási URL-címekkel definiálja, és meghatározza a fejlesztési környezet kapcsolati sztring. Ezek a beállítások csak a fejlesztési környezethez tartoznak.

Amikor futtatja docker-compose up (vagy elindítja a Visual Studióból), a parancs automatikusan felolvassa a felülbírálásokat, mintha mindkét fájlt egyesítenék.

Tegyük fel, hogy egy másik Compose-fájlt szeretne az éles környezethez különböző konfigurációs értékekkel, portokkal vagy kapcsolati sztring. Létrehozhat egy másik felülbírálási fájlt, például a különböző beállításokkal és környezeti változókkal elnevezett docker-compose.prod.yml fájlt. Előfordulhat, hogy a fájlt egy másik Git-adattárban tárolják, vagy egy másik csapat felügyeli és védi.

Üzembe helyezés adott felülbírálási fájllal

Ha több felülbírálási fájlt vagy más nevű felülbírálási fájlt szeretne használni, használja az -f lehetőséget a docker-compose paranccsal, és adja meg a fájlokat. A Compose a parancssorban megadott sorrendben egyesíti a fájlokat. Az alábbi példa bemutatja, hogyan helyezhet üzembe felülbírálási fájlokkal.

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

Környezeti változók használata docker-compose fájlokban

A környezeti változók konfigurációs információinak lekérése – különösen éles környezetekben – kényelmes, ahogy azt a korábbi példákban is láthattuk. A docker-compose fájlokban található környezeti változóra a ${MY_VAR} szintaxissal hivatkozhat. Egy docker-compose.prod.yml-fájl alábbi sora bemutatja, hogyan hivatkozhat egy környezeti változó értékére.

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

A környezeti változók a gazdakörnyezettől (Linux, Windows, Felhőfürt stb.) függően különböző módokon jönnek létre és inicializálódnak. Kényelmes módszer azonban egy .env fájl használata. A docker-compose fájlok támogatják az alapértelmezett környezeti változók deklarálását az .env fájlban. A környezeti változók értékei az alapértelmezett értékek. Ezeket azonban felül lehet bírálni az egyes környezetekben (gazdagép operációs rendszere vagy a fürt környezeti változói) definiált értékek alapján. Ezt az .env fájlt abban a mappában helyezi el, ahonnan a docker-compose parancsot végrehajtja.

Az alábbi példa egy .env fájlt mutat be, például az eShopOnContainers alkalmazás .env fájlját.

# .env file

ESHOP_EXTERNAL_DNS_NAME_OR_IP=host.docker.internal

ESHOP_PROD_EXTERNAL_DNS_NAME_OR_IP=10.121.122.92

A Docker-compose elvárja, hogy egy .env fájl minden sora változó=<érték> formátumban <>legyen.

A futásidejű környezetben beállított értékek mindig felülbírálják az .env fájlban definiált értékeket. Hasonlóképpen, a parancssori argumentumokon keresztül átadott értékek felülbírálják az .env fájlban beállított alapértelmezett értékeket is.

További erőforrások

• A Docker Compose áttekintése
  https://docs.docker.com/compose/overview/

• Több írási fájl
  https://docs.docker.com/compose/multiple-compose-files/

Optimalizált ASP.NET Core Docker-rendszerképek létrehozása

Ha a Dockert és a .NET-et az internetes forrásokon vizsgálja, olyan Docker-fájlokat talál, amelyek bemutatják a Docker-rendszerképek létrehozásának egyszerűségét a forrás tárolóba másolásával. Ezek a példák arra utalnak, hogy egy egyszerű konfigurációval docker-rendszerképet készíthet az alkalmazáshoz csomagolt környezettel. Az alábbi példa egy egyszerű Dockerfile-t mutat be ebben a vénában.

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

Az ilyen Dockerfile-fájlok működni fognak. Azonban jelentősen optimalizálhatja a képeket, különösen az éles rendszerképeket.

A tároló- és mikroszolgáltatási modellben folyamatosan indít tárolókat. A tárolók használatának tipikus módja nem indít újra alvó tárolót, mert a tároló eldobható. A vezénylők (például a Kubernetes és az Azure Service Fabric) új lemezképpéldányokat hoznak létre. Ez azt jelenti, hogy optimalizálnia kell az alkalmazást a létrehozáskor, hogy a példányosítási folyamat gyorsabb legyen. A tároló indításakor készen kell állnia a futtatásra. A .NET-ről és a Dockerről szóló blogbejegyzésekben látható módon ne állítsa vissza és dotnet build ne állítsa vissza futásidőben a dotnet restore parancssori felület parancsait.

A .NET csapata fontos munkát végzett annak érdekében, hogy a .NET és ASP.NET Core tárolóoptimalizált keretrendszer legyen. A .NET nem csupán egy kis memóriaigényű, könnyű keretrendszer; a csapat az optimalizált Docker-rendszerképekre összpontosított három fő forgatókönyv esetében, és közzétette őket a Docker Hub regisztrációs adatbázisában a dotnet/, a 2.1-es verziótól kezdve:

• Fejlesztés: A prioritás a változások gyors iterálásának és hibakeresésének képessége, valamint a másodlagos méret.
• Build: A prioritás az alkalmazás összeállítása, és a rendszerkép bináris fájlokat és egyéb függőségeket tartalmaz a bináris fájlok optimalizálásához.
• Éles környezet: A fókusz a tárolók gyors üzembe helyezése és elindítása, ezért ezek a képek az alkalmazás futtatásához szükséges bináris fájlokra és tartalmakra korlátozódnak.

A .NET-csapat néhány alapvető változatot biztosít a dotnet/-ben, például:

• sdk: fejlesztési és buildelési forgatókönyvekhez
• aspnet: ASP.NET éles forgatókönyvekhez
• futtatókörnyezet: .NET éles forgatókönyvekhez
• runtime-deps: önálló alkalmazások éles forgatókönyveihez

A gyorsabb indítás érdekében a futtatókörnyezeti rendszerképek automatikusan beállítják aspnetcore_urls a 80-at, és a Ngen használatával natív rendszerkép-gyorsítótárat hoznak létre szerelvényekből.

További erőforrások

• Optimalizált Docker-rendszerképek létrehozása a ASP.NET Core használatávalhttps://learn.microsoft.com/archive/blogs/stevelasker/building-optimized-docker-images-with-asp-net-core

• Docker-rendszerképek létrehozása .NET-alkalmazásokhozhttps://learn.microsoft.com/dotnet/core/docker/building-net-docker-images

Előzőkövetkező