Narzędzia kontenerów programu Visual Studio z platformą ASP.NET Core

Program Visual Studio 2017 i jego nowsze wersje obsługują kompilowanie, debugowanie i uruchamianie konteneryzowanych aplikacji ASP.NET Core przeznaczonych dla platformy .NET Core. Obsługiwane są kontenery zarówno systemu Windows, jak i Linux.

Wyświetl lub pobierz przykładowy kod (jak pobrać)

Wymagania wstępne

Instalacja i konfiguracja

W przypadku instalacji platformy Docker najpierw zapoznaj się z informacjami w witrynie Docker for Windows: Co należy wiedzieć przed zainstalowaniem. Następnie zainstaluj platformę Docker dla systemu Windows.

Udostępnione dyski na platformie Docker dla systemu Windows muszą być skonfigurowane do obsługi mapowania woluminów i debugowania. Kliknij prawym przyciskiem myszy ikonę platformy Docker na pasku zadań, wybierz pozycję Settings (Ustawienia) i wybierz pozycję Shared Drives (Udostępnione dyski). Wybierz dysk, na którym platforma Docker przechowuje pliki. Kliknij Zastosuj.

Dialog to select local C drive sharing for containers

Napiwek

W programie Visual Studio 2017 w wersji 15.6 i nowszych jest wyświetlany monit, jeśli udostępnione dyski nie są skonfigurowane.

Dodawanie projektu do kontenera platformy Docker

Aby umieścić w kontenerze projekt ASP.NET Core, musi on być przeznaczony dla platformy .NET Core. Obsługiwane są kontenery zarówno systemu Linux, jak i Windows.

Podczas dodawania obsługi platformy Docker do projektu wybierz kontener systemu Windows lub Linux. Na hoście platformy Docker musi być uruchomiony ten sam typ kontenera. Aby zmienić typ kontenera w uruchomionym wystąpieniu platformy Docker, kliknij prawym przyciskiem myszy ikonę platformy Docker na pasku zadań i wybierz polecenie Switch to Windows containers... (Przełącz do kontenerów systemu Windows...) lub polecenie Switch to Linux containers... (Przełącz do kontenerów systemu Linux...).

Nowa aplikacja

Podczas tworzenia nowej aplikacji przy użyciu szablonów projektów aplikacji internetowej platformy ASP.NET Core zaznacz pole wyboru Włącz obsługę platformy Docker:

Enable Docker Support checkbox

Jeśli platformą docelową jest .NET Core, lista rozwijana System operacyjny umożliwia wybranie typu kontenera.

Istniejąca aplikacja

W przypadku projektów ASP.NET Core przeznaczonych dla platformy .NET Core dostępne są dwie opcje dodawania obsługi platformy Docker za pomocą narzędzi. Otwórz projekt w programie Visual Studio, a następnie wybierz jedną z następujących opcji:

  • Wybierz pozycję Obsługa platformy Docker z menu Projekt.
  • Kliknij projekt prawym przyciskiem myszy w Eksploratorze rozwiązań i wybierz pozycję Dodaj>Obsługa platformy Docker.

Narzędzia kontenerów programu Visual Studio nie obsługują dodawania platformy Docker do istniejącego projektu ASP.NET Core przeznaczonego dla platformy .NET Framework.

Plik Dockerfile — przegląd

Plik Dockerfile, zawierający opis tworzenia końcowego obrazu platformy Docker, jest dodawany do katalogu głównego projektu. Opis poleceń znajdujących się w tym pliku można znaleźć w dokumentacji pliku Dockerfile. Ten konkretny plik Dockerfile używa kompilacji wieloetapowej z czterema odrębnymi, nazwanymi etapami kompilacji:

FROM mcr.microsoft.com/dotnet/core/aspnet:2.1 AS base
WORKDIR /app
EXPOSE 59518
EXPOSE 44364

FROM mcr.microsoft.com/dotnet/core/sdk:2.1 AS build
WORKDIR /src
COPY HelloDockerTools/HelloDockerTools.csproj HelloDockerTools/
RUN dotnet restore HelloDockerTools/HelloDockerTools.csproj
COPY . .
WORKDIR /src/HelloDockerTools
RUN dotnet build HelloDockerTools.csproj -c Release -o /app

FROM build AS publish
RUN dotnet publish HelloDockerTools.csproj -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "HelloDockerTools.dll"]

Powyższy obraz pliku Dockerfile zawiera pakiety ASP.NET Core runtime i NuGet. Pakiety są kompilowane w trybie Just-In-Time (JIT), aby zwiększyć wydajność uruchamiania.

Po zaznaczeniu pola wyboru Konfiguruj pod kątem protokołu HTTPS w oknie dialogowym nowego projektu plik Dockerfile uwidacznia dwa porty. Jeden port jest używany na potrzeby ruchu HTTP, a drugi na potrzeby protokołu HTTPS. Jeśli pole wyboru nie jest zaznaczone, dla ruchu HTTP jest uwidoczniony pojedynczy port (80).

FROM microsoft/aspnetcore:2.0 AS base
WORKDIR /app
EXPOSE 80

FROM microsoft/aspnetcore-build:2.0 AS build
WORKDIR /src
COPY HelloDockerTools/HelloDockerTools.csproj HelloDockerTools/
RUN dotnet restore HelloDockerTools/HelloDockerTools.csproj
COPY . .
WORKDIR /src/HelloDockerTools
RUN dotnet build HelloDockerTools.csproj -c Release -o /app

FROM build AS publish
RUN dotnet publish HelloDockerTools.csproj -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "HelloDockerTools.dll"]

Powyższy obraz dockerfile zawiera pakiety NuGet ASP.NET Core, które są kompilowane just in time (JIT), aby zwiększyć wydajność uruchamiania.

Dodawanie do aplikacji obsługi orkiestratora kontenerów

Program Visual Studio 2017 w wersji 15.7 lub starszych jako rozwiązanie aranżacji kontenerów obsługuje tylko narzędzie Docker Compose. Artefakty narzędzia Docker Compose są dodawane za pośrednictwem polecenia Dodaj>Obsługa platformy Docker.

W programie Visual Studio 2017 w wersji 15.8 i nowszych rozwiązanie aranżacji jest dodawane tylko na wyraźne żądanie. Kliknij projekt prawym przyciskiem myszy w Eksploratorze rozwiązań i wybierz pozycję Dodaj>Obsługa orkiestratora kontenerów. Dostępne są następujące opcje:

Docker Compose

Narzędzia kontenerów programu Visual Studio dodają do rozwiązania projekt docker-compose z następującymi plikami:

  • docker-compose.dcproj: plik reprezentujący projekt. Zawiera element <DockerTargetOS> określający system operacyjny, który ma być używany.
  • .dockerignore: Wyświetla listę wzorców plików i katalogów do wykluczenia podczas generowania kontekstu kompilacji.
  • docker-compose.yml: podstawowy plik Docker Compose używany do definiowania kolekcji obrazów skompilowanych i uruchamianych za pomocą docker-compose build poleceń i docker-compose run.
  • docker-compose.override.yml: opcjonalny plik, odczytany przez aplikację Docker Compose z przesłonięciami konfiguracji dla usług. Program Visual Studio wykonuje polecenie docker-compose -f "docker-compose.yml" -f "docker-compose.override.yml", aby scalić te pliki.

Plik docker-compose.yml przywołuje nazwę obrazu utworzonego podczas uruchamiania projektu:

version: '3.4'

services:
  hellodockertools:
    image: ${DOCKER_REGISTRY}hellodockertools
    build:
      context: .
      dockerfile: HelloDockerTools/Dockerfile

W poprzednim przykładzie polecenie image: hellodockertools generuje obraz hellodockertools:dev, gdy aplikacja działa w trybie debugowania. Obraz hellodockertools:latest jest generowany, gdy aplikacja działa w trybie wydania.

Dodaj do nazwy obrazu prefiks Docker Hub nazwa użytkownika (na przykład dockerhubusername/hellodockertools), jeśli obraz jest wypychany do rejestru. Możesz również zmienić nazwę obrazu tak, aby zawierała adres URL rejestru prywatnego (na przykład privateregistry.domain.com/hellodockertools) w zależności od konfiguracji.

Jeśli chcesz wymusić różne zachowania w zależności od konfiguracji kompilacji (na przykład debugowanie lub wydanie), dodaj specyficzne dla konfiguracji pliki docker-compose. Pliki powinny mieć nazwy zgodne z konfiguracją kompilacji (na przykład docker-compose.vs.debug.yml i docker-compose.vs.release.yml) i powinny być umieszczone w tej samej lokalizacji co plik docker-compose-override.yml.

Przy użyciu plików przesłonięć specyficznych dla konfiguracji można określić różne ustawienia konfiguracji (na przykład zmienne środowiskowe lub punkty wejścia) dla kompilacji w trybie debugowania i wydania.

Aby w narzędziu Docker Compose była wyświetlana opcja uruchamiania w programie Visual Studio, projekt platformy Docker musi być projektem startowym.

Service Fabric

Oprócz podstawowych wymagań wstępnych rozwiązanie aranżacji Service Fabric ma następujące wymagania wstępne:

Usługa Service Fabric nie obsługuje uruchamiania kontenerów systemu Linux w lokalnym klastrze programistycznym w systemie Windows. Jeśli projekt używa już kontenera systemu Linux, program Visual Studio wyświetli komunikat z prośbą o przełączenie do kontenerów systemu Windows.

Narzędzia kontenerów programu Visual Studio wykonują następujące zadania:

  • <Dodaje projekt aplikacji usługi ApplicationFabric project_name>do rozwiązania.

  • Dodają do projektu ASP.NET Core pliki Dockerfile i .dockerignore. Jeśli plik Dockerfile już istnieje w projekcie ASP.NET Core, jego nazwa zostanie zmieniona na Dockerfile.original. Tworzony jest nowy plik Dockerfile podobny do następującego:

    # See https://aka.ms/containerimagehelp for information on how to use Windows Server 1709 containers with Service Fabric.
    # FROM microsoft/aspnetcore:2.0-nanoserver-1709
    FROM microsoft/aspnetcore:2.0-nanoserver-sac2016
    ARG source
    WORKDIR /app
    COPY ${source:-obj/Docker/publish} .
    ENTRYPOINT ["dotnet", "HelloDockerTools.dll"]
    
  • <IsServiceFabricServiceProject> Dodaje element do pliku projektu .csproj ASP.NET Core:

    <IsServiceFabricServiceProject>True</IsServiceFabricServiceProject>
    
  • Dodają folder PackageRoot do projektu ASP.NET Core. Ten folder zawiera manifest usługi i ustawienia nowej usługi.

Aby uzyskać więcej informacji, zobacz Wdrażanie aplikacji .NET w kontenerze systemu Windows w usłudze Azure Service Fabric.

Debugowanie

Wybierz pozycję Docker z listy rozwijanej debugowania na pasku narzędzi i rozpocznij debugowanie aplikacji. W widoku Docker w oknie Dane wyjściowe widać wykonywanie następujących akcji:

  • Uzyskiwany jest tag 2.1-aspnetcore-runtime obrazu środowiska uruchomieniowego microsoft/dotnet (jeśli nie znajduje się już w pamięci podręcznej). Obraz instaluje środowiska uruchomieniowe platform ASP.NET Core i .NET Core oraz powiązane biblioteki. Są one zoptymalizowane pod kątem uruchamiania aplikacji ASP.NET Core w środowisku produkcyjnym.
  • Zmienna środowiskowa ASPNETCORE_ENVIRONMENT jest ustawiona na wartość Development w kontenerze.
  • Uwidaczniane są dwa dynamicznie przypisywane porty: jeden dla protokołu HTTP i jeden dla protokołu HTTPS. Do portu przypisanego do hosta lokalnego można wysłać polecenie docker ps.
  • Aplikacja jest kopiowana do kontenera.
  • Uruchamiana jest domyślna przeglądarka z debugerem dołączonym do kontenera przy użyciu dynamicznie przypisanego portu.

Wynikowy obraz platformy Docker aplikacji jest oznaczony tagiem dev. Obraz bazuje na tagu 2.1-aspnetcore-runtime obrazu podstawowego microsoft/dotnet. Uruchom polecenie docker images w oknie konsoli menedżera pakietów (PMC). Na komputerze są wyświetlane następujące obrazy:

REPOSITORY        TAG                     IMAGE ID      CREATED         SIZE
hellodockertools  dev                     d72ce0f1dfe7  30 seconds ago  255MB
microsoft/dotnet  2.1-aspnetcore-runtime  fcc3887985bb  6 days ago      255MB
  • Uzyskiwany jest obraz środowiska uruchomieniowego microsoft/aspnetcore (jeśli nie znajduje się już w pamięci podręcznej).
  • Zmienna środowiskowa ASPNETCORE_ENVIRONMENT jest ustawiona na wartość Development w kontenerze.
  • Port 80 jest uwidaczniany i mapowany na dynamicznie przypisany port dla hosta lokalnego. Port jest określany przez hosta platformy Docker i można do niego wysłać zapytanie przy użyciu polecenia docker ps.
  • Aplikacja jest kopiowana do kontenera.
  • Uruchamiana jest domyślna przeglądarka z debugerem dołączonym do kontenera przy użyciu dynamicznie przypisanego portu.

Wynikowy obraz platformy Docker aplikacji jest oznaczony tagiem dev. Obraz bazuje na obrazie podstawowym microsoft/aspnetcore. Uruchom polecenie docker images w oknie konsoli menedżera pakietów (PMC). Na komputerze są wyświetlane następujące obrazy:

REPOSITORY            TAG  IMAGE ID      CREATED        SIZE
hellodockertools      dev  5fafe5d1ad5b  4 minutes ago  347MB
microsoft/aspnetcore  2.0  c69d39472da9  13 days ago    347MB

Uwaga

Obraz dev nie zawiera zawartości aplikacji, ponieważ konfiguracje debugowania używają instalacji woluminu w celu zapewnienia iteracyjnych działań. Aby wypchnąć obraz, należy użyć konfiguracji wydania.

Uruchom polecenie docker ps w konsoli PMC. Zauważ, że aplikacja działa przy użyciu kontenera:

CONTAINER ID        IMAGE                  COMMAND                   CREATED             STATUS              PORTS                   NAMES
baf9a678c88d        hellodockertools:dev   "C:\\remote_debugge..."   21 seconds ago      Up 19 seconds       0.0.0.0:37630->80/tcp   dockercompose4642749010770307127_hellodockertools_1

Edytowanie i kontynuowanie

Zmiany plików statycznych i Razor widoków są automatycznie aktualizowane bez konieczności wykonania kroku kompilacji. Wprowadź zmiany, zapisz je i odśwież przeglądarkę, aby wyświetlić aktualizację.

Modyfikacje pliku kodu wymagają kompilacji i ponownego Kestrel uruchomienia w kontenerze. Po wprowadzeniu zmiany użyj klawiszy CTRL+F5, aby wykonać przetwarzanie i uruchomić aplikację w kontenerze. Kontener platformy Docker nie jest ponownie kompilowany ani zatrzymywany. Uruchom polecenie docker ps w konsoli PMC. Zwróć uwagę, że oryginalny kontener nadal działa od 10 minut:

CONTAINER ID        IMAGE                  COMMAND                   CREATED             STATUS              PORTS                   NAMES
baf9a678c88d        hellodockertools:dev   "C:\\remote_debugge..."   10 minutes ago      Up 10 minutes       0.0.0.0:37630->80/tcp   dockercompose4642749010770307127_hellodockertools_1

Publikowanie obrazów platformy Docker

Po zakończeniu cyklu opracowywania i debugowania aplikacji narzędzia kontenerów programu Visual Studio ułatwiają tworzenie obrazu produkcyjnego aplikacji. Zmień opcję listy rozwijanej konfiguracji na Wydanie i skompiluj aplikację. Narzędzia uzyskują obraz kompilowania/publikowania z usługi Docker Hub (jeśli jeszcze nie znajduje się on w pamięci podręcznej). Obraz jest tworzony z tagiem latest (najnowszy) i można go wypchnąć do rejestru prywatnego lub usługi Docker Hub.

Uruchom polecenie docker images w konsoli PMC, aby wyświetlić listę obrazów. Wyświetlane są dane wyjściowe podobne do następujących:

REPOSITORY        TAG                     IMAGE ID      CREATED             SIZE
hellodockertools  latest                  e3984a64230c  About a minute ago  258MB
hellodockertools  dev                     d72ce0f1dfe7  4 minutes ago       255MB
microsoft/dotnet  2.1-sdk                 9e243db15f91  6 days ago          1.7GB
microsoft/dotnet  2.1-aspnetcore-runtime  fcc3887985bb  6 days ago          255MB
REPOSITORY                  TAG     IMAGE ID      CREATED         SIZE
hellodockertools            latest  cd28f0d4abbd  12 seconds ago  349MB
hellodockertools            dev     5fafe5d1ad5b  23 minutes ago  347MB
microsoft/aspnetcore-build  2.0     7fed40fbb647  13 days ago     2.02GB
microsoft/aspnetcore        2.0     c69d39472da9  13 days ago     347MB

Obrazy microsoft/aspnetcore-build i microsoft/aspnetcore wyświetlane w poprzednich danych wyjściowych zostały zastąpione obrazami microsoft/dotnet platformy .NET Core 2.1. Aby uzyskać więcej informacji, zobacz zapowiedź migracji repozytoriów platformy Docker.

Uwaga

Polecenie docker images zwraca obrazy pośredniczące z nazwami repozytoriów i tagami zidentyfikowanymi jako <brak> (nie wymieniono powyżej). Te nienazwane obrazy są tworzone przez plik Dockerfile kompilacjiwieloetapowej. Zwiększają one wydajność tworzenia obrazu końcowego — tylko niezbędne warstwy są odbudowywane po wystąpieniu zmian. Gdy obrazy pośrednie nie będą już potrzebne, można je usunąć za pomocą polecenia docker rmi.

Może wystąpić oczekiwanie, że rozmiar obrazu produkcyjnego lub wydania będzie mniejszy niż obraz dev. Ze względu na mapowanie woluminu debuger i aplikacja były uruchomione z poziomu komputera lokalnego, a nie w kontenerze. Obraz latest (najnowszy) zawiera spakowany kod aplikacji niezbędny do uruchomienia aplikacji na komputerze hosta. Różnica w rozmiarach wynika zatem z rozmiaru kodu aplikacji.

Dodatkowe zasoby