Images Docker pour ASP.NET Core

Cet article explique comment exécuter une application ASP.NET Core dans des conteneurs Docker.

Windows Home Edition ne prend pas en charge Hyper-V, et Hyper-V est nécessaire pour Docker.

Images Docker ASP.NET Core

Dans ce tutoriel, vous allez télécharger un exemple d’application ASP.NET Core pour l’exécuter dans des conteneurs Docker. L’exemple s’applique aux conteneurs Linux et Windows.

L’exemple de fichier Dockerfile utilise la fonctionnalité de build en plusieurs étapes de Docker pour séparer le build et l’exécution dans différents conteneurs. Les conteneurs de build et d’exécution sont créés à partir d’images fournies par Microsoft dans Docker Hub :

  • dotnet/sdk

    L’exemple utilise cette image pour créer l’application. L’image contient le Kit de développement logiciel (SDK) .NET, qui inclut les outils en ligne de commande (CLI). Elle est optimisée pour le développement, le débogage et le test unitaire en local. Les outils installés pour le développement et la compilation rendent l’image relativement grande.

  • dotnet/core/sdk

    L’exemple utilise cette image pour créer l’application. Elle contient le Kit SDK .NET Core, qui inclut les outils en ligne de commande. Elle est optimisée pour le développement, le débogage et le test unitaire en local. Les outils installés pour le développement et la compilation rendent l’image relativement grande.

  • dotnet/aspnet

    L’exemple utilise cette image pour exécuter l’application. Elle contient le runtime ASP.NET Core et les bibliothèques. Elle est optimisée pour l’exécution d’applications en production. Conçue pour la vitesse de déploiement et de démarrage de l’application, elle est relativement petite afin d’optimiser les performances réseau du Registre Docker vers l’hôte Docker. Seuls les binaires et le contenu nécessaires pour exécuter une application sont copiés dans le conteneur. Le contenu est prêt à s’exécuter, ce qui réduit le délai entre docker run et le démarrage de l’application. La compilation de code dynamique n’est pas nécessaire dans le modèle Docker.

  • dotnet/core/aspnet

    L’exemple utilise cette image pour exécuter l’application. Elle contient le runtime ASP.NET Core et les bibliothèques. Elle est optimisée pour l’exécution d’applications en production. Conçue pour la vitesse de déploiement et de démarrage de l’application, elle est relativement petite afin d’optimiser les performances réseau du Registre Docker vers l’hôte Docker. Seuls les binaires et le contenu nécessaires pour exécuter une application sont copiés dans le conteneur. Le contenu est prêt à s’exécuter, ce qui réduit le délai entre docker run et le démarrage de l’application. La compilation de code dynamique n’est pas nécessaire dans le modèle Docker.

Prérequis

Télécharger l’exemple d’application

Exécutez l’application localement.

  • Accédez au dossier de projet à l’adresse dotnet-docker/samples/aspnetapp/aspnetapp.

  • Exécutez la commande suivante pour générer et exécuter l’application localement :

    dotnet run
    
  • Accédez à http://localhost:5000 dans un navigateur pour tester l’application.

  • Appuyez sur Ctrl+C dans l’invite de commande pour arrêter l’application.

Exécuter dans un conteneur Linux ou un conteneur Windows

  • Pour exécuter dans un conteneur Linux, cliquez avec le bouton droit sur l’icône client Docker de la barre d’état système, puis sélectionnez Basculer vers les conteneurs Linux.

  • Pour exécuter dans un conteneur Windows, cliquez avec le bouton droit sur l’icône du client Docker de la barre d’état système et sélectionnez Basculer vers les conteneurs Windows.

  • Accédez au dossier Dockerfile à l’adresse dotnet-docker/samples/aspnetapp.

  • Exécutez les commandes suivantes pour générer et exécuter l’exemple dans Docker :

    docker build -t aspnetapp .
    docker run -it --rm -p 5000:80 --name aspnetcore_sample aspnetapp
    

    Voici le rôle des arguments de la commande build :

    • nommer l’image aspnetapp ;
    • rechercher le fichier Dockerfile dans le dossier actif (le point final).

    Voici le rôle des arguments de la commande run :

    • allouer un pseudoterminal TTY et le laisser ouvert même s’il n’est pas attaché (même effet que --interactive --tty) ;
    • supprimer automatiquement le conteneur lorsqu’il se ferme ;
    • mapper le port 5000 de l’ordinateur local avec le port 80 du conteneur ;
    • nommer le conteneur aspnetcore_sample ;
    • spécifier l’image aspnetapp.
  • Accédez à http://localhost:5000 dans un navigateur pour tester l’application.

Effectuer manuellement le build et le déploiement

Dans certains scénarios, vous pouvez déployer une application sur un conteneur en copiant ses ressources nécessaires au moment de l’exécution. Cette section montre comment effectuer un déploiement manuel.

  • Accédez au dossier de projet à l’adresse dotnet-docker/samples/aspnetapp/aspnetapp.

  • Exécutez la commande dotnet publish :

    dotnet publish -c Release -o published
    

    Voici le rôle des arguments de la commande :

    • Générez l’application en mode de mise en production (la valeur par défaut est le mode débogage).
    • Créez les ressources dans le dossier publié .
  • Exécutez l’application.

    • Windows :

      dotnet published\aspnetapp.dll
      
    • Linux :

      dotnet published/aspnetapp.dll
      
  • Accédez à http://localhost:5000 pour afficher la page d’accueil.

Pour utiliser l’application publiée manuellement dans un conteneur Docker, créez un fichier Dockerfile et utilisez la docker build . commande pour générer une image.

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS runtime
WORKDIR /app
COPY published/ ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]

Pour afficher la nouvelle image, utilisez la docker images commande .

Le fichier Dockerfile

Voici le fichier Dockerfile utilisé par la docker build commande que vous avez exécutée précédemment. Il utilise dotnet publish comme nous l’avons fait dans cette section pour le build et le déploiement.

# https://hub.docker.com/_/microsoft-dotnet
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /source

# copy csproj and restore as distinct layers
COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore

# copy everything else and build app
COPY aspnetapp/. ./aspnetapp/
WORKDIR /source/aspnetapp
RUN dotnet publish -c release -o /app --no-restore

# final stage/image
FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /app
COPY --from=build /app ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS runtime
WORKDIR /app
COPY published/ ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]

Pour afficher la nouvelle image, utilisez la docker images commande .

Le fichier Dockerfile

Voici le fichier Dockerfile utilisé par la docker build commande que vous avez exécutée précédemment. Il utilise dotnet publish comme nous l’avons fait dans cette section pour le build et le déploiement.

# https://hub.docker.com/_/microsoft-dotnet
FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /source

# copy csproj and restore as distinct layers
COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore

# copy everything else and build app
COPY aspnetapp/. ./aspnetapp/
WORKDIR /source/aspnetapp
RUN dotnet publish -c release -o /app --no-restore

# final stage/image
FROM mcr.microsoft.com/dotnet/aspnet:5.0
WORKDIR /app
COPY --from=build /app ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]

Dans le fichier Dockerfile précédent, les *.csproj fichiers sont copiés et restaurés en tant que couches distinctes. Lorsque la docker build commande génère une image, elle utilise un cache intégré. Si les *.csproj fichiers n’ont pas changé depuis la dernière exécution de la docker build commande, la dotnet restore commande n’a pas besoin de s’exécuter à nouveau. Au lieu de cela, le cache intégré pour la couche correspondante dotnet restore est réutilisé. Pour plus d’informations, consultez Meilleures pratiques pour l’écriture de fichiers Dockerfiles.

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0 AS runtime
WORKDIR /app
COPY published/ ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]

Le fichier Dockerfile

Voici le fichier Dockerfile utilisé par la docker build commande que vous avez exécutée précédemment. Il utilise dotnet publish comme nous l’avons fait dans cette section pour le build et le déploiement.

FROM mcr.microsoft.com/dotnet/core/sdk:3.0 AS build
WORKDIR /app

# copy csproj and restore as distinct layers
COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore

# copy everything else and build app
COPY aspnetapp/. ./aspnetapp/
WORKDIR /app/aspnetapp
RUN dotnet publish -c Release -o out

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0 AS runtime
WORKDIR /app
COPY --from=build /app/aspnetapp/out ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]

Comme indiqué dans le fichier Dockerfile précédent, les *.csproj fichiers sont copiés et restaurés en tant que couches distinctes. Lorsque la docker build commande génère une image, elle utilise un cache intégré. Si les *.csproj fichiers n’ont pas changé depuis la dernière exécution de la docker build commande, la dotnet restore commande n’a pas besoin de s’exécuter à nouveau. Au lieu de cela, le cache intégré pour la couche correspondante dotnet restore est réutilisé. Pour plus d’informations, consultez Bonnes pratiques pour l’écriture de dockerfiles.

FROM mcr.microsoft.com/dotnet/core/aspnet:2.2 AS runtime
WORKDIR /app
COPY published/ ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]

Le fichier Dockerfile

Voici le dockerfile utilisé par la commande que docker build vous avez exécutée précédemment. Il utilise dotnet publish comme nous l’avons fait dans cette section pour le build et le déploiement.

FROM mcr.microsoft.com/dotnet/core/sdk:2.2 AS build
WORKDIR /app

# copy csproj and restore as distinct layers
COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore

# copy everything else and build app
COPY aspnetapp/. ./aspnetapp/
WORKDIR /app/aspnetapp
RUN dotnet publish -c Release -o out

FROM mcr.microsoft.com/dotnet/core/aspnet:2.2 AS runtime
WORKDIR /app
COPY --from=build /app/aspnetapp/out ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]

Ressources supplémentaires

Étapes suivantes

Le référentiel Git qui contient l’exemple d’application comporte également une documentation. Pour une vue d’ensemble des ressources disponibles dans le référentiel, voir le fichier Lisez-moi. En particulier, découvrez comment implémenter le protocole HTTPS :