Pracovní postup vývoje aplikací Dockeru

Návod

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é aplikace .NET – miniatura obálky eBooku.

Ž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 v iteraci inner-loop pro aplikace založené na kontejnerech Docker. 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 nebo novějšího se mnohé z těchto kroků zpracovávají za vás, což výrazně zvyšuje vaši produktivitu. To platí zejména v případě, že 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

Než začnete, ujistěte se, že máte nainstalovaný Docker Desktop 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 nebo novější s nainstalovanými úlohami ASP.NET a vývoje webu, jak je znázorněno na obrázku 5–2.

Snímek obrazovky s možností .NET Core pro multiplatformní vývoj.

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 je vítané, protože Visual Studio natolik usnadňuje práci s Dockerem, že to působí skoro nepostřehnutelně – nejlépe je to vidět při ladění vícekontejnerových aplikací ve Visual Studiu.

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ší. Při vytváření nového projektu v sadě Visual Studio 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 >, jak je znázorněno na obrázku 5 až 4.

Snímek obrazovky zobrazující 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 svůj kontejner na základě základního imagu, který získáte z oficiálního repozitáře, například z registru Docker Hub. Přesně to se děje na pozadí, když ve Visual Studiu 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žena na verzi 8.0 oficiální Docker image pro ASP.NET Core (pro více architektur pro Linux a Windows). Toto je nastavení FROM mcr.microsoft.com/dotnet/aspnet:8.0. (Další informace o této základní bitové kopii najdete na stránce ASP.NET Core Docker Image.) V souboru Dockerfile musíte Dockeru také určit, aby naslouchal na portu TCP, který budete používat za běhu (v tomto případě na portu 80, jak je nakonfigurováno pomocí instrukce EXPOSE).

V souboru Dockerfile můžete zadat další nastavení konfigurace v závislosti na používaném jazyce a rozhraní. Například řádek ENTRYPOINT s ["dotnet", "MySingleContainerWebApp.dll"] říká 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é. Podstatné je, že řádek ENTRYPOINT a další nastavení se budou lišit podle jazyka a platformy, které 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 štítek cílený na výslovně určenou platformu, jako v následujících případech:

  • mcr.microsoft.com/dotnet/aspnet:8.0-bullseye-slim
    Cílová platforma: pouze běhové prostředí .NET 8 pro Linux

  • 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

Tímto způsobem se při stažení image z hostitele s Windows stáhne varianta pro Windows a při stažení image se stejným názvem z hostitele s Linuxem se stáhne varianta pro Linux.

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á to základním obrazem, který vytváří počáteční prostředí; je to něco jako výchozí souborový systém při spuštění, který běží 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 image pouze pro běhové prostředí a zkopírujte publikační složku z předchozí fáze, abyste vytvořili malou výslednou image.

Pravděpodobně nejlepším způsobem, jak porozumět vícefázovému sestavení, je projít si podrobně soubor Dockerfile řádek po řádku, takže začněme původním souborem Dockerfile, který Visual Studio vytvoří při přidání podpory Dockeru do projektu, a k některým optimalizacím se dostaneme později.

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: Začněte fázi s „malou“ základní imagí pouze pro běhové prostředí a pro další použití ji pojmenujte base.

  • Řá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 „velkým“ obrazem pro sestavení/publikování. Nazvěte to build 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 navazující na sestavení. Říkejte tomu publish pro přehlednost.

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

  • Řádek č. 25: Zahajte novou fázi navazující na base a nazvěte ji final.

  • Řá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 u jednotlivých služeb v eShopOnContainers liší, takže se musejí spustit pokaždé, pokud jste však řádky 7–16 změnili 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 jen na:

RUN dotnet restore

Balíčky pro celé řešení by se obnovily, ale na druhou stranu by se to provedlo jen jednou místo současných 15krát při použití aktuální strategie.

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 se pro vás obrazy Dockeru automaticky sestavují ve Visual Studiu. 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 konzole z příkazu docker images, 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ž ve Visual Studiu vytvoříte projekt s podporou Dockeru, image nevytváříte výslovně. 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 jsou doporučenou 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 Dockeru tak, aby se sestavil jako součást spuštění docker-compose, a to pomocí dodatečné konfigurace založené na sekci build: 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 prostředí Visual Studio

Kromě přidání souboru Dockerfile do projektu může Visual Studio 2017 (od verze 15.8), jak jsme již zmínili, přidat do řešení podporu nástroje Docker Compose pro orchestraci.

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 orchestraci Docker Compose.

Snímek obrazovky zobrazující možnost „Container Orchestrator Support“ v kontextové 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 řešení v sadě Visual Studio se v Průzkumníku řešení také zobrazí nový uzel v souboru projektu docker-compose.dcproj, který obsahuje přidané soubory docker-compose.yml, jak ukazuje obrázek 5–8.

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

Obrázek 5–8 Uzel docker-compose přidaný do Průzkumníka řešení v aplikaci Visual Studio 2022

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í Docker CLI

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í 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šší. Stačí stisknout Ctrl+F5 pro spuštění nebo F5 pro ladění a jako obvykle nastavit projekt docker-compose jako spouštěcí projekt. Visual Studio zajistí veškeré potřebné nastavení, takže můžete jako obvykle nastavovat body přerušení a ladit kód, který nakonec poběží jako samostatné procesy na vzdálených serverech, s již připojeným ladicím programem, a to bez dalších kroků.

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 mrknout na všechnu tu dřinu, podívejte se do souboru:

{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 panelu nástrojů pro ladění při spuštění projektu docker-compose.

Obrázek 5–12 Spouštění aplikací s více kontejnery ve Visual Studiu 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íť. Také používáte deploymenty k organizaci 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 neukazuje na IP adresu hostitele Dockeru (což by při použití Docker CE mělo být výchozí nastavení), použijte pro přístup ke své službě IP adresu síťového rozhraní svého 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 konzole při získání http://10.0.75.1/API/values pomocí 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

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

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

Pokud vyvíjíte pomocí editoru nebo CLI, ladění kontejnerů je obtížnější a pravděpodobně je budete chtít ladit pomocí generování trasovacích záznamů.

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 Server Core (nastavení FROM) a instalujeme IIS pomocí příkazu PowerShell (nastavení RUN). 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ší

  • Last updated on