Sdílet prostřednictvím

Pracovní postup vývoje aplikací Dockeru

  • Článek

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.

Stáhnout PDF

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

Životní cyklus vývoje aplikací začíná na vašem počítači jako vývojář, kde kódujete aplikaci pomocí preferovaného jazyka a otestujete ji místně. S tímto pracovním postupem bez ohledu na jazyk, architekturu a platformu, kterou zvolíte, vždy vyvíjíte a testujete kontejnery Dockeru, ale provádíte to místně.

Každý kontejner (instance image Dockeru) obsahuje následující komponenty:

  • Výběr operačního systému, například distribuce Linuxu, Windows Nano Serveru nebo Jádra Windows Serveru.
  • Soubory přidané během vývoje, například zdrojový kód a binární soubory aplikací.
  • Informace o konfiguraci, jako jsou nastavení prostředí a závislosti.

Pracovní postup pro vývoj aplikací založených na kontejnerech Dockeru

Tato část popisuje pracovní postup vývoje vnitřní smyčky pro aplikace založené na kontejnerech Dockeru. Pracovní postup vnitřní smyčky znamená, že nebere v úvahu širší pracovní postup DevOps, který může zahrnovat až produkční nasazení, a zaměřuje se jenom na vývojovou práci provedenou na počítači vývojáře. Počáteční kroky pro nastavení prostředí nejsou zahrnuté, protože tyto kroky se provádějí jenom jednou.

Aplikace se skládá z vlastních služeb a dalších knihoven (závislostí). Následuje základní postup, který obvykle provedete při vytváření aplikace Dockeru, jak je znázorněno na obrázku 5–1.

Diagram znázorňující sedm kroků potřebných k vytvoření kontejnerizované aplikace

Obrázek 5–1 Podrobný pracovní postup pro vývoj kontejnerizovaných aplikací Dockeru

V této části je tento celý proces podrobný a každý hlavní krok je vysvětlen zaměřením na prostředí sady Visual Studio.

Pokud používáte přístup pro vývoj editoru nebo rozhraní příkazového řádku (například Visual Studio Code a Rozhraní příkazového řádku Dockeru v macOS nebo Windows), musíte znát každý krok, obecně podrobněji, než když používáte Visual Studio. Další informace o práci v prostředí rozhraní příkazového řádku najdete v elektronické knize Životní cyklus kontejnerizované aplikace Dockeru s platformami a nástroji Microsoftu.

Při používání sady Visual Studio 2022 se mnohé z těchto kroků zpracovávají za vás, což výrazně zvyšuje vaši produktivitu. To platí hlavně v případě, že používáte Visual Studio 2022 a cílíte na vícekontenerové aplikace. Například pomocí jediného kliknutí myší Visual Studio přidá soubor Dockerfile a docker-compose.yml soubor do vašich projektů s konfigurací pro vaši aplikaci. Když aplikaci spustíte v sadě Visual Studio, sestaví image Dockeru a spustí aplikaci s více kontejnery přímo v Dockeru; umožňuje dokonce ladit několik kontejnerů najednou. Tyto funkce zvýší rychlost vývoje.

Jenom proto, že Visual Studio provádí tyto kroky automaticky, neznamená, že nemusíte vědět, co se děje s Dockerem. Proto následující doprovodné materiály podrobně popisuje každý krok.

Obrázek kroku 1

Krok 1. Zahájení kódování a vytvoření počáteční aplikace nebo směrného plánu služby

Vývoj aplikace Dockeru je podobný způsobu, jakým vyvíjíte aplikaci bez Dockeru. Rozdíl je v tom, že při vývoji pro Docker nasazujete a testujete aplikace nebo služby spuštěné v kontejnerech Dockeru ve vašem místním prostředí (buď nastavení virtuálního počítače s Linuxem pomocí Dockeru, nebo přímo Windows, pokud používáte kontejnery Windows).

Nastavení místního prostředí pomocí sady Visual Studio

Abyste mohli začít, ujistěte se, že máte nainstalovanou plochu Dockeru pro Windows pro Windows , jak je vysvětleno v následujících pokynech:

Začínáme s Desktopem Dockeru pro Windows

Kromě toho potřebujete Visual Studio 2022 verze 17.0 s nainstalovanými úlohami vývoje pro .ASP.NET a web , jak je znázorněno na obrázku 5–2.

Snímek obrazovky s výběrem pro vývoj pro různé platformy .NET Core

Obrázek 5–2 Výběr úlohy vývoje pro ASP.NET a web během instalace sady Visual Studio 2022

Aplikaci můžete začít kódovat v prostém .NET (obvykle v .NET Core nebo novějším, pokud plánujete používat kontejnery) i před povolením Dockeru ve vaší aplikaci a nasazením a testováním v Dockeru. Doporučujeme ale co nejdříve začít pracovat na Dockeru, protože to bude skutečné prostředí a co nejdříve se můžou objevit všechny problémy. To se doporučuje, protože Visual Studio usnadňuje práci s Dockerem, že je téměř transparentní – nejlepší příklad při ladění vícekontenerových aplikací ze sady Visual Studio.

Další materiály

Obrázek kroku 2

Pro každou vlastní image, kterou chcete sestavit, potřebujete soubor Dockerfile. Potřebujete také soubor Dockerfile pro každý kontejner, který se má nasadit automaticky ze sady Visual Studio, nebo ručně pomocí rozhraní příkazového řádku Dockeru (příkazy docker run a docker-compose). Pokud vaše aplikace obsahuje jednu vlastní službu, potřebujete jeden soubor Dockerfile. Pokud vaše aplikace obsahuje více služeb (jako v architektuře mikroslužeb), potřebujete pro každou službu jeden soubor Dockerfile.

Soubor Dockerfile se umístí do kořenové složky vaší aplikace nebo služby. Obsahuje příkazy, které dockeru říkají, jak nastavit a spustit aplikaci nebo službu v kontejneru. Soubor Dockerfile můžete v kódu vytvořit ručně a přidat ho do projektu spolu se závislostmi .NET.

V sadě Visual Studio a jeho nástrojích pro Docker vyžaduje tato úloha jenom několik kliknutí myší. Když v sadě Visual Studio 2022 vytvoříte nový projekt, existuje možnost Povolit podporu Dockeru, jak je znázorněno na obrázku 5–3.

Snímek obrazovky s zaškrtávacím políčkem Povolit podporu Dockeru

Obrázek 5–3 Povolení podpory Dockeru při vytváření nového projektu ASP.NET Core v sadě Visual Studio 2022

Podporu Dockeru můžete také povolit u existujícího projektu webové aplikace ASP.NET Core tak, že kliknete pravým tlačítkem na projekt v Průzkumník řešení a vyberete Přidat>podporu Dockeru..., jak je znázorněno na obrázku 5 až 4.

Snímek obrazovky s možností Podpora Dockeru v nabídce Přidat

Obrázek 5–4 Povolení podpory Dockeru v existujícím projektu sady Visual Studio 2022

Tato akce přidá do projektu soubor Dockerfile s požadovanou konfigurací a je k dispozici pouze v ASP.NET základních projektech.

Podobně může Visual Studio přidat docker-compose.yml soubor pro celé řešení s možností Přidat > podporu nástroje Container Orchestrator.... V kroku 4 tuto možnost podrobněji prozkoumáme.

Použití existující oficiální image Dockeru pro .NET

Obvykle vytváříte vlastní image pro kontejner nad základní imagí, kterou získáte z oficiálního úložiště, jako je registr Docker Hubu. Přesně to se děje pod popisy, když v sadě Visual Studio povolíte podporu Dockeru. Váš soubor Dockerfile bude používat existující dotnet/core/aspnet image.

Dříve jsme vysvětlili, které image a úložiště Dockeru můžete použít v závislosti na zvoleném rozhraní a operačním systému. Pokud například chcete použít ASP.NET Core (Linux nebo Windows), image, kterou chcete použít, je mcr.microsoft.com/dotnet/aspnet:8.0. Proto stačí zadat, jakou základní image Dockeru použijete pro svůj kontejner. Uděláte to přidáním FROM mcr.microsoft.com/dotnet/aspnet:8.0 do souboru Dockerfile. Visual Studio to provede automaticky, ale pokud jste verzi aktualizovali, aktualizujete tuto hodnotu.

Použití oficiálního úložiště imagí .NET z Docker Hubu s číslem verze zajišťuje, že na všech počítačích (včetně vývoje, testování a produkce) budou dostupné stejné jazykové funkce.

Následující příklad ukazuje ukázkový soubor Dockerfile pro kontejner ASP.NET Core.

FROM mcr.microsoft.com/dotnet/aspnet:8.0
ARG source
WORKDIR /app
EXPOSE 80
COPY ${source:-obj/Docker/publish} .
ENTRYPOINT ["dotnet", " MySingleContainerWebApp.dll "]

V tomto případě je image založená na verzi 8.0 oficiální image Dockeru ASP.NET Core (multi-arch pro Linux a Windows). Toto je nastavení FROM mcr.microsoft.com/dotnet/aspnet:8.0. (Další informace o této základní imagi najdete na stránce ASP.NET Základní image Dockeru .) V souboru Dockerfile také potřebujete dát Dockeru pokyn, aby naslouchal na portu TCP, který budete používat za běhu (v tomto případě port 80, jak je nakonfigurované s nastavením EXPOSE).

V souboru Dockerfile můžete zadat další nastavení konfigurace v závislosti na používaném jazyce a rozhraní. Například řádek ENTRYPOINT sděluje ["dotnet", "MySingleContainerWebApp.dll"] Dockeru, aby spustil aplikaci .NET. Pokud k sestavení a spuštění aplikace .NET používáte sadu SDK a rozhraní příkazového řádku .NET (rozhraní příkazového řádku dotnet), bude toto nastavení jiné. Dolní řádek je, že řádek ENTRYPOINT a další nastavení se budou lišit v závislosti na jazyce a platformě, kterou pro svou aplikaci zvolíte.

Další materiály

Použití úložišť s více archy obrázků

Jedno úložiště může obsahovat varianty platformy, jako je image Linuxu a image Windows. Tato funkce umožňuje dodavatelům, jako je Microsoft (tvůrci základních imagí), vytvořit jedno úložiště pro pokrytí více platforem (to znamená Linux a Windows). Například úložiště .NET dostupné v registru Docker Hubu poskytuje podporu pro Linux a Windows Nano Server pomocí stejného názvu úložiště.

Pokud zadáte značku, která cílí na platformu, která je explicitní jako v následujících případech:

  • mcr.microsoft.com/dotnet/aspnet:8.0-bullseye-slim
    Cíle: Modul runtime .NET 8 pouze v Linuxu

  • mcr.microsoft.com/dotnet/aspnet:8.0-nanoserver-ltsc2022
    Cíle: Modul runtime .NET 8 pouze pro Windows Nano Server

Pokud ale zadáte stejný název image i se stejnou značkou, budou multi-archové image (například aspnet image) používat verzi Linuxu nebo Windows v závislosti na hostitelském operačním systému Dockeru, který nasazujete, jak je znázorněno v následujícím příkladu:

  • mcr.microsoft.com/dotnet/aspnet:8.0
    Multi-arch: Modul runtime .NET 8 pouze v Linuxu nebo Windows Nano Serveru v závislosti na hostitelském operačním systému Dockeru

Když tak stáhnete image z hostitele s Windows, stáhne se varianta Windows a vyžádáním stejného názvu image z hostitele s Linuxem se přetáhne varianta Linuxu.

Vícefázové sestavení v souboru Dockerfile

Soubor Dockerfile je podobný dávkovému skriptu. Podobně jako kdybyste museli nastavit počítač z příkazového řádku.

Začíná základní imagí, která nastavuje počáteční kontext, je to jako spouštěcí systém souborů, který se nachází nad hostitelským operačním systémem. Nejedná se o operační systém, ale můžete si ho představit jako operační systém uvnitř kontejneru.

Spuštění každého příkazového řádku vytvoří novou vrstvu v systému souborů se změnami z předchozího řádku, takže při kombinaci vytvoří výsledný systém souborů.

Vzhledem k tomu, že každá nová vrstva "leží" nad předchozí vrstvou a výsledná velikost image se zvyšuje s každým příkazem, obrázky můžou být velmi velké, pokud musí obsahovat například sadu SDK potřebnou k sestavení a publikování aplikace.

To je místo, kde se vícefázové buildy dostanou do grafu (z Dockeru 17.05 a vyšší) a dělají své kouzlo.

Základní myšlenkou je, že můžete oddělit proces provádění souboru Dockerfile ve fázích, kde fáze je počáteční image následovaná jedním nebo více příkazy a poslední fáze určuje konečnou velikost image.

Stručně řečeno, vícefázové sestavení umožňují rozdělit vytváření v různých "fázích" a pak sestavit finální image, která přebírá pouze relevantní adresáře z přechodných fází. Obecná strategie použití této funkce je:

  1. Použijte základní image sady SDK (nezáleží na tom, jak velká) se vším, co je potřeba k sestavení a publikování aplikace do složky, a pak

  2. Použijte základní, malou bitovou kopii, jen pro modul runtime a zkopírujte složku publikování z předchozí fáze, abyste vytvořili malou konečnou image.

Pravděpodobně nejlepší způsob, jak porozumět vícefázové fázi, podrobně prochází souborEm Dockerfile, řádek po řádku, takže začněme počátečním souborem Dockerfile vytvořeným sadou Visual Studio při přidávání podpory Dockeru do projektu a později se do některých optimalizací dostaneme.

Počáteční soubor Dockerfile může vypadat přibližně takto:

 1  FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
 2  WORKDIR /app
 3  EXPOSE 80
 4
 5  FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
 6  WORKDIR /src
 7  COPY src/Services/Catalog/Catalog.API/Catalog.API.csproj …
 8  COPY src/BuildingBlocks/HealthChecks/src/Microsoft.AspNetCore.HealthChecks …
 9  COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions.HealthChecks …
10  COPY src/BuildingBlocks/EventBus/IntegrationEventLogEF/ …
11  COPY src/BuildingBlocks/EventBus/EventBus/EventBus.csproj …
12  COPY src/BuildingBlocks/EventBus/EventBusRabbitMQ/EventBusRabbitMQ.csproj …
13  COPY src/BuildingBlocks/EventBus/EventBusServiceBus/EventBusServiceBus.csproj …
14  COPY src/BuildingBlocks/WebHostCustomization/WebHost.Customization …
15  COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
16  COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
17  RUN dotnet restore src/Services/Catalog/Catalog.API/Catalog.API.csproj
18  COPY . .
19  WORKDIR /src/src/Services/Catalog/Catalog.API
20  RUN dotnet build Catalog.API.csproj -c Release -o /app
21
22  FROM build AS publish
23  RUN dotnet publish Catalog.API.csproj -c Release -o /app
24
25  FROM base AS final
26  WORKDIR /app
27  COPY --from=publish /app .
28  ENTRYPOINT ["dotnet", "Catalog.API.dll"]

A tady jsou podrobnosti, řádek po řádku:

  • Řádek č. 1: Zahajte fázi s "malou" základní imagí jen pro modul runtime, která je základem pro referenci.

  • Řádek č. 2: Vytvořte v obrázku adresář /app .

  • Řádek č. 3: Zveřejnění portu 80

  • Řádek č. 5: Začněte novou fázi s "velkou" imagí pro sestavování a publikování. Volejte sestavení pro referenci.

  • Řádek č. 6: Vytvořte v obrázku adresář /src .

  • Řádek č. 7: Až na řádek 16 zkopírujte odkazované soubory projektu .csproj , abyste mohli později obnovit balíčky.

  • Řádek č. 17: Obnovení balíčků pro projekt Catalog.API a odkazované projekty

  • Řádek 18: Zkopírujte veškerý adresářový strom pro řešení (s výjimkou souborů/adresářů zahrnutých v souboru .dockerignore ) do adresáře /src v imagi.

  • Řádek č. 19: Změňte aktuální složku na projekt Catalog.API .

  • Řádek č. 20: Sestavte projekt (a další závislosti projektu) a výstup do adresáře /app v obrázku.

  • Řádek č. 22: Zahajte novou fázi, která pokračuje z sestavení. Zavolejte ji publikovat pro referenci.

  • Řádek č. 23: Publikujte projekt (a závislosti) a výstup do adresáře /app v obrázku.

  • Řádek č. 25: Zahajte novou fázi, která pokračuje od základu , a volat ji jako dokončenou.

  • Řádek č. 26: Změňte aktuální adresář na /app.

  • Řádek č. 27: Zkopírujte adresář /app z fáze publikování do aktuálního adresáře.

  • Řádek č. 28: Definujte příkaz, který se má spustit při spuštění kontejneru.

Teď se podíváme na některé optimalizace, abychom zlepšili výkon celého procesu, který v případě eShopOnContainers znamená přibližně 22 minut nebo více pro sestavení kompletního řešení v kontejnerech Linuxu.

Využijete funkci mezipaměti vrstvy Dockeru, což je poměrně jednoduché: pokud základní image a příkazy jsou stejné jako dříve provedené příkazy, může jednoduše použít výslednou vrstvu bez nutnosti spouštět příkazy, což šetří čas.

Pojďme se tedy zaměřit na fázi sestavení , řádky 5-6 jsou většinou stejné, ale řádky 7-17 se pro každou službu od eShopOnContainers liší, takže musí provést pokaždé, ale pokud jste změnili řádky 7-16 na:

COPY . .

Pak by to bylo stejné pro každou službu, zkopírovalo by celé řešení a vytvořilo by větší vrstvu, ale:

  1. Proces kopírování se spustí jenom poprvé (a při opětovném sestavení souboru) a použije mezipaměť pro všechny ostatní služby a

  2. Vzhledem k tomu, že větší obrázek se vyskytuje v přechodné fázi, nemá vliv na konečnou velikost obrázku.

Další významná optimalizace zahrnuje restore příkaz spuštěný na řádku 17, který se také liší pro každou službu eShopOnContainers. Pokud tento řádek změníte na:

RUN dotnet restore

Balíčky pro celé řešení by se obnovily, ale pak by to udělalo jen jednou místo 15krát s aktuální strategií.

Spustí se ale jenom v případě, dotnet restore že je ve složce jeden projekt nebo soubor řešení, takže dosažení tohoto problému je trochu složitější a způsob, jak ho vyřešit, aniž byste se museli zabývat příliš mnoha podrobnostmi, je toto:

  1. Do souboru .dockerignore přidejte následující řádky:

    • *.sln– pokud chcete ignorovat všechny soubory řešení ve stromu hlavních složek

    • !eShopOnContainers-ServicesAndWebApps.slnzahrnout pouze tento soubor řešení.

  2. /ignoreprojectextensions:.dcproj Zahrňte argument do dotnet restore, takže také ignoruje projekt docker-compose a pouze obnoví balíčky pro řešení eShopOnContainers-ServicesAndWebApps.

V případě konečné optimalizace se stane, že řádek 20 je redundantní, protože řádek 23 také sestaví aplikaci a přichází v podstatě hned za řádkem 20, takže přijde další časově náročný příkaz.

Výsledný soubor je pak:

 1  FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
 2  WORKDIR /app
 3  EXPOSE 80
 4
 5  FROM mcr.microsoft.com/dotnet/sdk:8.0 AS publish
 6  WORKDIR /src
 7  COPY . .
 8  RUN dotnet restore /ignoreprojectextensions:.dcproj
 9  WORKDIR /src/src/Services/Catalog/Catalog.API
10  RUN dotnet publish Catalog.API.csproj -c Release -o /app
11
12  FROM base AS final
13  WORKDIR /app
14  COPY --from=publish /app .
15  ENTRYPOINT ["dotnet", "Catalog.API.dll"]

Vytvoření základní image úplně od začátku

Vlastní základní image Dockeru můžete vytvořit úplně od začátku. Tento scénář se nedoporučuje pro někoho, kdo začíná s Dockerem, ale pokud chcete nastavit konkrétní bity vlastní základní image, můžete to udělat.

Další materiály

Obrázek kroku 3

Krok 3. Vytvoření vlastních imagí Dockeru a vložení aplikace nebo služby do nich

Pro každou službu ve vaší aplikaci musíte vytvořit související image. Pokud je vaše aplikace tvořená jednou službou nebo webovou aplikací, potřebujete jenom jednu image.

Všimněte si, že image Dockeru se automaticky sestavují v sadě Visual Studio. Následující kroky jsou potřeba jenom pro pracovní postup editoru nebo rozhraní příkazového řádku a vysvětlují přehled o tom, co se děje pod ním.

Jako vývojář musíte vyvíjet a testovat místně, dokud nenasdílíte dokončenou funkci nebo se nezměníte do systému správy zdrojového kódu (například na GitHub). To znamená, že potřebujete vytvořit image Dockeru a nasadit kontejnery do místního hostitele Dockeru (virtuální počítač s Windows nebo Linuxem) a spustit, otestovat a ladit s těmito místními kontejnery.

Pokud chcete vytvořit vlastní image v místním prostředí pomocí Rozhraní příkazového řádku Dockeru a souboru Dockerfile, můžete použít příkaz docker buildu, jak je znázorněno na obrázku 5 až 5.

Snímek obrazovky znázorňující výstup konzoly příkazu docker build

Obrázek 5–5 Vytvoření vlastní image Dockeru

Volitelně můžete místo přímého spuštění sestavení Dockeru ze složky projektu nejprve vygenerovat nasaditelnou složku s požadovanými knihovnami .NET a binárními soubory spuštěním dotnet publisha pak příkazem docker build .

Tím se vytvoří image Dockeru s názvem cesardl/netcore-webapi-microservice-docker:first. V tomto případě je značka, :first která představuje konkrétní verzi. Tento krok můžete opakovat pro každou vlastní image, kterou potřebujete vytvořit pro složenou aplikaci Dockeru.

Když je aplikace tvořená více kontejnery (to znamená vícekontejnerovou aplikací), můžete také pomocí docker-compose up --build příkazu sestavit všechny související image pomocí jednoho příkazu pomocí metadat vystavených v souvisejících docker-compose.yml souborech.

Existující image v místním úložišti najdete pomocí příkazu docker images, jak je znázorněno na obrázku 5–6.

Výstup konzoly z imagí dockeru příkazů zobrazující existující image

Obrázek 5–6 Zobrazení existujících imagí pomocí příkazu docker images

Vytváření imagí Dockeru pomocí sady Visual Studio

Když k vytvoření projektu s podporou Dockeru použijete Visual Studio, nevytáčíte explicitně image. Místo toho se image vytvoří za vás, když stisknete klávesu F5 (nebo Ctrl+F5) a spustíte dockerizovanou aplikaci nebo službu. Tento krok je v sadě Visual Studio automatický a neuvidíte ho, ale je důležité, abyste věděli, co se děje pod ním.

Obrázek volitelného kroku 4

Krok 4. Definování služeb v docker-compose.yml při vytváření aplikace Dockeru s více kontejnery

Soubor docker-compose.yml umožňuje definovat sadu souvisejících služeb, které se mají nasadit jako složená aplikace s příkazy nasazení. Konfiguruje také své vztahy závislostí a konfiguraci modulu runtime.

Pokud chcete použít soubor docker-compose.yml, musíte ho vytvořit ve složce hlavního nebo kořenového řešení s podobným obsahem v následujícím příkladu:

version: '3.4'

services:

  webmvc:
    image: eshop/web
    environment:
      - CatalogUrl=http://catalog-api
      - OrderingUrl=http://ordering-api
    ports:
      - "80:80"
    depends_on:
      - catalog-api
      - ordering-api

  catalog-api:
    image: eshop/catalog-api
    environment:
      - ConnectionString=Server=sqldata;Port=1433;Database=CatalogDB;…
    ports:
      - "81:80"
    depends_on:
      - sqldata

  ordering-api:
    image: eshop/ordering-api
    environment:
      - ConnectionString=Server=sqldata;Database=OrderingDb;…
    ports:
      - "82:80"
    extra_hosts:
      - "CESARDLBOOKVHD:10.0.75.1"
    depends_on:
      - sqldata

  sqldata:
    image: mcr.microsoft.com/mssql/server:latest
    environment:
      - SA_PASSWORD=[PLACEHOLDER]
      - ACCEPT_EULA=Y
    ports:
      - "5433:1433"

Důležité

Microsoft doporučuje používat nejbezpečnější dostupný tok ověřování. Pokud se připojujete k Azure SQL, spravované identity pro prostředky Azure se doporučují metodou ověřování.

Tento docker-compose.yml soubor je zjednodušená a sloučená verze. Obsahuje statická konfigurační data pro každý kontejner (například název vlastní image), která se vždy vyžadují, a informace o konfiguraci, které můžou záviset na prostředí nasazení, jako je připojovací řetězec. V dalších částech se dozvíte, jak rozdělit konfiguraci docker-compose.yml do několika souborů docker-compose a přepsat hodnoty v závislosti na typu prostředí a spuštění (ladění nebo vydání).

Příklad docker-compose.yml souboru definuje čtyři služby: webmvc službu (webovou aplikaci), dvě mikroslužby (ordering-api a basket-api) a jeden kontejner zdroje dat založený sqldatana SQL Serveru pro Linux spuštěný jako kontejner. Každá služba se nasadí jako kontejner, takže pro každou z nich se vyžaduje image Dockeru.

Soubor docker-compose.yml určuje nejen to, jaké kontejnery se používají, ale jak se konfigurují jednotlivě. Například webmvc definice kontejneru v souboru .yml:

  • Používá předem vytvořenou eshop/web:latest image. Můžete ale také nakonfigurovat image, která se má sestavit jako součást provádění docker-compose s další konfigurací založenou na sestavení: oddíl v souboru docker-compose.

  • Inicializuje dvě proměnné prostředí (CatalogUrl a OrderingUrl).

  • Přesměruje vystavený port 80 v kontejneru na externí port 80 na hostitelském počítači.

  • Umožňuje propojit webovou aplikaci s katalogem a objednávkovou službou s nastavením depends_on. To způsobí, že služba počká, až se tyto služby spustí.

Když se podíváme na to, jak implementovat mikroslužby a vícekontenerové aplikace, vrátíme se k souboru docker-compose.yml v další části.

Práce s docker-compose.yml v sadě Visual Studio 2022

Kromě přidání souboru Dockerfile do projektu může Visual Studio 2017 (verze 15.8 zapnuté) do řešení přidat podporu orchestrátoru pro Docker Compose.

Když přidáte podporu orchestrátoru kontejnerů, jak je znázorněno na obrázku 5–7 poprvé, Visual Studio vytvoří soubor Dockerfile pro projekt a vytvoří v řešení nový projekt (oddíl služby) s několika globálními docker-compose*.yml soubory a pak projekt přidá do těchto souborů. Potom můžete otevřít docker-compose.yml soubory a aktualizovat je dalšími funkcemi.

Opakujte tuto operaci pro každý projekt, který chcete zahrnout do souboru docker-compose.yml.

V době psaní tohoto textu visual Studio podporuje orchestrátory Docker Compose .

Snímek obrazovky s možností Podpora nástroje Container Orchestrator v místní nabídce projektu

Obrázek 5–7 Přidání podpory Dockeru v sadě Visual Studio 2022 kliknutím pravým tlačítkem myši na projekt ASP.NET Core

Po přidání podpory orchestrátoru do vašeho řešení v sadě Visual Studio se také zobrazí nový uzel (v docker-compose.dcproj souboru projektu) v Průzkumník řešení, který obsahuje přidané docker-compose.yml soubory, jak je znázorněno na obrázku 5–8.

Snímek obrazovky uzlu docker-compose v Průzkumník řešení

Obrázek 5–8 Uzel stromu docker-compose přidaný v sadě Visual Studio 2022 Průzkumník řešení

Pomocí příkazu můžete nasadit vícekontenerovou aplikaci s jedním souborem docker-compose up docker-compose.yml. Visual Studio ale přidá skupinu, abyste mohli přepsat hodnoty v závislosti na prostředí (vývojovém nebo produkčním) a typu spuštění (vydání nebo ladění). Tato funkce bude vysvětlena v dalších částech.

Obrázek kroku 5

Krok 5. Sestavení a spuštění aplikace Dockeru

Pokud má vaše aplikace jenom jeden kontejner, můžete ho spustit tak, že ji nasadíte na hostitele Dockeru (virtuální počítač nebo fyzický server). Pokud ale vaše aplikace obsahuje více služeb, můžete ji nasadit jako složenou aplikaci, a to buď pomocí jednoho příkazu rozhraní příkazového řádku (docker-compose up)nebo pomocí sady Visual Studio, který tento příkaz použije pod kryty). Podívejme se na různé možnosti.

Možnost A: Spuštění aplikace s jedním kontejnerem

Použití Rozhraní příkazového řádku Dockeru

Kontejner Dockeru můžete spustit pomocí docker run příkazu, jak je znázorněno na obrázku 5–9:

docker run -t -d -p 80:5000 cesardl/netcore-webapi-microservice-docker:first

Výše uvedený příkaz vytvoří novou instanci kontejneru ze zadané image při každém spuštění. Pomocí parametru --name můžete kontejneru pojmenovat a pak použít (nebo použít docker start {name} ID kontejneru nebo automatický název) ke spuštění existující instance kontejneru.

Snímek obrazovky se spuštěním kontejneru Dockeru pomocí příkazu docker run

Obrázek 5–9 Spuštění kontejneru Dockeru pomocí příkazu docker run

V tomto případě příkaz vytvoří vazbu interního portu 5000 kontejneru na port 80 hostitelského počítače. To znamená, že hostitel naslouchá na portu 80 a předává na port 5000 v kontejneru.

Zobrazená hodnota hash je ID kontejneru a má také přiřazený náhodný čitelný název, pokud se --name tato možnost nepoužívá.

Používání sady Visual Studio

Pokud jste nepřidali podporu orchestrátoru kontejnerů, můžete v sadě Visual Studio spustit také jednu aplikaci kontejneru stisknutím kláves Ctrl+F5 a také pomocí klávesy F5 ladit aplikaci v rámci kontejneru. Kontejner běží místně pomocí spuštění Dockeru.

Možnost B: Spuštění vícekontenerové aplikace

Ve většině podnikových scénářů se aplikace Dockeru skládá z několika služeb, což znamená, že potřebujete spustit vícekontenerovou aplikaci, jak je znázorněno na obrázku 5–10.

Virtuální počítač s několika kontejnery Dockeru

Obrázek 5–10 Virtuální počítač s nasazenými kontejnery Dockeru

Použití Rozhraní příkazového řádku Dockeru

Pokud chcete spustit vícekontenerovou aplikaci pomocí Rozhraní příkazového řádku Dockeru, použijte tento docker-compose up příkaz. Tento příkaz používá soubor docker-compose.yml , který máte na úrovni řešení k nasazení vícekontenerové aplikace. Obrázek 5–11 ukazuje výsledky při spuštění příkazu z hlavního adresáře řešení, který obsahuje soubor docker-compose.yml.

Zobrazení obrazovky při spuštění příkazu docker-compose up

Obrázek 5–11 Příklady výsledků při spuštění příkazu docker-compose up

Po spuštění příkazu docker-compose se aplikace a související kontejnery nasadí do hostitele Dockeru, jak je znázorněno na obrázku 5 až 10.

Používání sady Visual Studio

Spuštění vícekontenerové aplikace pomocí sady Visual Studio 2019 nemůže být jednodušší. Stisknutím kombinace kláves Ctrl+F5 spustíte nebo F5 jako obvykle nastavíte projekt docker-compose jako spouštěný projekt. Visual Studio zpracovává všechna potřebná nastavení, takže můžete vytvářet zarážky jako obvykle a ladit, co se nakonec stane nezávislými procesy spuštěnými na "vzdálených serverech", a ladicí program je už připojený, stejně jako to.

Jak už bylo zmíněno dříve, pokaždé, když do projektu v rámci řešení přidáte podporu řešení Dockeru, je tento projekt nakonfigurovaný v globálním souboru (na úrovni řešení docker-compose.yml), který umožňuje spouštět nebo ladit celé řešení najednou. Visual Studio spustí jeden kontejner pro každý projekt, který má povolenou podporu řešení Dockeru, a provede všechny interní kroky za vás (publikování dotnet, sestavení Dockeru atd.).

Pokud se chcete podívat na všechny drudgery, podívejte se na soubor:

{root solution folder}\obj\Docker\docker-compose.vs.debug.g.yml

Důležitým bodem je, že jak je znázorněno na obrázku 5–12, v sadě Visual Studio 2019 existuje další příkaz Dockeru pro akci klávesy F5. Tato možnost umožňuje spustit nebo ladit vícekontejnerovou aplikaci spuštěním všech kontejnerů definovaných v souborech docker-compose.yml na úrovni řešení. Schopnost ladit řešení s více kontejnery znamená, že můžete nastavit několik zarážek, každou zarážku v jiném projektu (kontejneru) a při ladění ze sady Visual Studio se zastavíte u zarážek definovaných v různých projektech a spuštěných v různých kontejnerech.

Snímek obrazovky s panelem nástrojů ladění se spuštěným projektem docker-compose

Obrázek 5–12 Spouštění vícekontenerových aplikací v sadě Visual Studio 2022

Další materiály

Poznámka o testování a nasazení pomocí orchestrátorů

Příkazy docker-compose up a docker run (nebo spouštění a ladění kontejnerů v sadě Visual Studio) jsou vhodné pro testování kontejnerů ve vašem vývojovém prostředí. Tento přístup byste ale neměli používat pro produkční nasazení, kde byste měli cílit na orchestrátory, jako je Kubernetes nebo Service Fabric. Pokud používáte Kubernetes, musíte použít pody k uspořádání kontejnerů a služeb pro jejich síť. Nasazení slouží také k uspořádání vytváření a úprav podů .

Obrázek kroku 6

Krok 6. Otestování aplikace Docker pomocí místního hostitele Dockeru

Tento krok se bude lišit v závislosti na tom, co vaše aplikace dělá. V jednoduché webové aplikaci .NET, která je nasazená jako jeden kontejner nebo služba, můžete k této službě přistupovat tak, že otevřete prohlížeč na hostiteli Dockeru a přejdete na tento web, jak je znázorněno na obrázku 5–13. (Pokud konfigurace v souboru Dockerfile mapuje kontejner na port hostitele, který je cokoli jiného než 80, zahrňte port hostitele do adresy URL.)

Snímek obrazovky s odpovědí z localhost/API/values

Obrázek 5–13 Příklad místního testování aplikace Docker pomocí místního hostitele

Pokud localhost neodkazuje na IP adresu hostitele Dockeru (ve výchozím nastavení při použití Dockeru CE, měla by) přejít do vaší služby, použijte IP adresu síťové karty vašeho počítače.

Tato adresa URL v prohlížeči používá port 80 pro konkrétní příklad kontejneru, který je popsán. Interně se ale požadavky přesměrovávají na port 5000, protože to bylo způsob nasazení pomocí příkazu docker run, jak je vysvětleno v předchozím kroku.

Aplikaci můžete také otestovat pomocí nástroje curl z terminálu, jak je znázorněno na obrázku 5–14. V instalaci Dockeru ve Windows je výchozí IP adresa hostitele Dockeru vždy 10.0.75.1 kromě skutečné IP adresy vašeho počítače.

Výstup konzoly ze získání http://10.0.75.1/API/values nástroje curl.

Obrázek 5–14 Příklad místního testování aplikace Docker pomocí nástroje curl

Testování a ladění kontejnerů pomocí sady Visual Studio 2022

Při spouštění a ladění kontejnerů pomocí sady Visual Studio 2022 můžete aplikaci .NET ladit podobným způsobem jako při spouštění bez kontejnerů.

Testování a ladění bez sady Visual Studio

Pokud vyvíjíte pomocí přístupu editoru nebo rozhraní příkazového řádku, ladění kontejnerů je obtížnější a pravděpodobně budete chtít ladit generováním trasování.

Další materiály

Zjednodušený pracovní postup při vývoji kontejnerů pomocí sady Visual Studio

Pracovní postup při použití sady Visual Studio je v podstatě mnohem jednodušší, než když používáte přístup editoru nebo rozhraní příkazového řádku. Většina kroků vyžadovaných Dockerem souvisejícím se souborem Dockerfile a docker-compose.yml jsou v sadě Visual Studio skryté nebo zjednodušené, jak je znázorněno na obrázku 5–15.

Diagram znázorňující pět zjednodušených kroků, které je potřeba k vytvoření aplikace

Obrázek 5–15 Zjednodušený pracovní postup při vývoji pomocí sady Visual Studio

Kromě toho musíte provést krok 2 (přidání podpory Dockeru do projektů) jen jednou. Pracovní postup je proto podobný obvyklým úkolům vývoje při použití .NET pro jakýkoli jiný vývoj. Potřebujete vědět, co se děje pod kryty (proces sestavení image, jaké základní image používáte, nasazení kontejnerů atd.) a někdy budete muset upravit soubor Dockerfile nebo docker-compose.yml soubor pro přizpůsobení chování. Většina práce je ale výrazně zjednodušená pomocí sady Visual Studio, což vám výrazně usnadňuje produktivitu.

Použití příkazů PowerShellu v souboru Dockerfile k nastavení kontejnerů Windows

Kontejnery Windows umožňují převést existující aplikace pro Windows na image Dockeru a nasadit je se stejnými nástroji jako zbytek ekosystému Dockeru. Pokud chcete používat kontejnery Windows, spusťte příkazy PowerShellu v souboru Dockerfile, jak je znázorněno v následujícím příkladu:

FROM mcr.microsoft.com/windows/servercore
LABEL Description="IIS" Vendor="Microsoft" Version="10"
RUN powershell -Command Add-WindowsFeature Web-Server
CMD [ "ping", "localhost", "-t" ]

V tomto případě používáme základní image Windows Serveru Core (nastavení FROM) a instalujeme službu IIS pomocí příkazu PowerShellu (nastavení SPUSTIT). Podobným způsobem můžete také použít příkazy PowerShellu k nastavení dalších komponent, jako jsou ASP.NET 4.x, .NET Framework 4.6 nebo jakýkoli jiný software windows. Například následující příkaz v souboru Dockerfile nastaví ASP.NET 4.5:

RUN powershell add-windowsfeature web-asp-net45

Další materiály

PředchozíDalší