Megosztás a következőn keresztül:

A többtárolós alkalmazás beállítása a docker-compose.yml segítségével

Jótanács

Ez a tartalom egy részlet a '.NET Microservices Architecture for Containerized .NET Applications' című eBook-ból, amely elérhető a .NET Docs oldalon, vagy ingyenesen letölthető PDF formátumban, amely offline módban is olvasható.

PDF letöltése

.NET mikroszolgáltatások architektúrája konténerizált .NET alkalmazásokhoz e-könyv borító miniatűr.

Ebben az útmutatóban a docker-compose.yml fájl a 4. lépésben lett bevezetve. A szolgáltatások meghatározá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ületet kell használnia, hogy az egyes konténereket több lépésben üzembe helyezze a docker run parancs használatával a parancssorból. 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 az ASP.NET Core MVC alkalmazást, amely kiszolgálóoldali C# nyelven mikroszolgáltatásokat használ.
katalógus-API A katalógus ASP.NET Core Web API mikroszolgáltatását tartalmazó konténer
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 ASP.NET Core Web API mikroszolgáltatást tartalmazó Basket tároló
basketdata A REDIS cache szolgáltatást futtató tároló, amely a kosár adatbázist REDIS-gyorsítótárként használja.

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 képet korábban már fel kell építeni (a docker build paranccsal), vagy le kell tölteni (a docker pull paranccsal) bármelyik Docker-regiszterből.

  • Egy ConnectionString nevű környezeti változót határoz meg azzal a kapcsolati sztringgel, 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 sztringet egy környezeti változó definiálja, ezt a változót egy másik mechanizmussal és más időpontban is beállíthatja. Beállíthat például egy másik kapcsolati karakterláncot, amikor az éles környezetben történő üzembe helyezéskor a végső gazdagépeket használja, vagy ezt megteheti az Azure DevOps Services CI/CD-folyamatai során, vagy az Ön által 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 egy Linux virtuális gép, mivel egy linuxos Docker-rendszerképen alapul, de a tárolót konfigurálhatja úgy, hogy Windows rendszerképen fusson.

  • Áttovábbítja a tárolón lévő kinyitott 80-as portot a Docker-gazdagépen (a Linux VM-en) lévő 5101-es 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 vagy a Visual Studio segítségével hozhatja létre ezt a környezetet, amely a háttérben a docker-compose-t használja.

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

Gyártási telepítések

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, amely megkönnyíti a fejlesztési, tesztelési és éles munkafolyamatokat, 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.

Docker-komponálási projekt fájljai.

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 az, amikor több compose fájlt határoz meg, hogy több környezetet célozzon meg, mint például az éles környezet, az előkészítés, a CI vagy a fejlesztés. 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ó.

Három docker-compose fájl diagramja, amely felülbírálja az alapfájlt.

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ók állnak rendelkezésére:

  • A szolgáltatás neve: webmvc.

  • A konténer személyre szabott 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 tesztkörnyezet számára készült docker-compose.override.yml vagy hasonló fájlokban az adott környezethez specifikus konfigurációt kell elhelyeznie.

A docker-compose.override.yml általában használatos a fejlesztési környezethez, ahogyan az eShopOnContainers alábbi példája mutatja:

#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ó néhány portot elérhetővé tesz a gazdagép számára, környezeti változókat határoz meg átirányítási URL-címekkel, és megadja a fejlesztési környezet kapcsolati karakterláncait. 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 láncokkal. 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.

Adott felülbírálási fájl alkalmazásával történő üzembe helyezés

Ha több felülbírálási fájlt vagy más néven felülbíráló fájlt szeretne használni, használja a -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 telepítsen felülíró 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

Különösen éles környezetekben kényelmes megoldás a környezeti változókból származó konfigurációs információk lekérése, mint ahogyan a korábbi példákban is bemutattuk. 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

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 az ilyen módon készült egyszerű Dockerfile-t mutatja be.

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 működni fog. Azonban jelentősen optimalizálhatja a képeket, különösen a gyártási képeket.

A tároló- és mikroszolgáltatási modellben megszakítás nélkül indítja a tárolókat. A konténerek használatának tipikus módja nem indít újra alvó konténert, mert a konténer eldobható. A vezénylők (például a Kubernetes és az Azure Service Fabric) új példányokat hoznak létre a képekből. Ez azt jelenti, hogy optimalizálnia kell az alkalmazást a létrehozáskor, hogy a példányosítási folyamat gyorsabb legyen. Amikor a konténer elindul, készen kell állnia a futtatáshoz. Ne állítsa vissza és ne fordítsa futásidőben a dotnet restore és dotnet build parancssori felület parancsokkal, ahogyan láthatja a .NET-ről és Dockerről szóló blogbejegyzésekben.

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.
  • Termelés: A fókusz a konténerek gyors üzembe helyezésén és indításán van, ezért ezek az imázsok az alkalmazás futtatásához szükséges binárisokra é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 futási rendszerképek automatikusan beállítják az aspnetcore_urls 80-as portra, és az Ngen használatával natív rendszerkép-gyorsítótárat hoznak létre összeállításokból.

További erőforrások

ElőzőKövetkező