Partager via

Définition de votre application multiconteneur avec docker-compose.yml

Conseil / Astuce

Ce contenu est un extrait du livre électronique 'Architecture des microservices .NET pour les applications .NET conteneurisées', disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement, lisible hors ligne.

Télécharger le PDF

Architecture de microservices .NET pour les applications .NET conteneurisées - vignette de couverture du livre électronique.

Dans ce guide, le fichier docker-compose.yml a été introduit à l’étape 4 de la section. Définissez vos services dans docker-compose.yml lors de la création d’une application Docker à plusieurs conteneurs. Toutefois, il existe d’autres façons d’utiliser les fichiers docker-compose qui méritent d’être explorés plus en détail.

Par exemple, vous pouvez décrire explicitement comment déployer votre application multiconteneur dans le fichier docker-compose.yml. Si vous le souhaitez, vous pouvez également décrire la façon dont vous allez créer vos images Docker personnalisées. (Les images Docker personnalisées peuvent également être générées avec l’interface CLI Docker.)

En fait, vous définissez chacun des conteneurs que vous souhaitez déployer plus certaines caractéristiques pour chaque déploiement de conteneur. Une fois que vous disposez d’un fichier de description de déploiement à plusieurs conteneurs, vous pouvez déployer l’ensemble de la solution dans une seule action orchestrée par la commande CLI docker-compose up , ou vous pouvez la déployer de manière transparente à partir de Visual Studio. Sinon, vous devez utiliser l’interface CLI Docker pour déployer container-by-container en plusieurs étapes à l’aide de la docker run commande à partir de la ligne de commande. Par conséquent, chaque service défini dans docker-compose.yml doit spécifier exactement une image ou une build. D’autres clés sont facultatives et sont analogues à leurs docker run équivalents de ligne de commande.

Le code YAML suivant est la définition d’un fichier global mais unique docker-compose.yml possible pour l’exemple eShopOnContainers. Ce code n’est pas le fichier docker-compose réel d’eShopOnContainers. Au lieu de cela, il s’agit d’une version simplifiée et consolidée dans un seul fichier, ce qui n’est pas le meilleur moyen d’utiliser des fichiers docker-compose, comme expliqué plus loin.

version: '3.4'

services:
  webmvc:
    image: eshop/webmvc
    environment:
      - CatalogUrl=http://catalog-api
      - OrderingUrl=http://ordering-api
      - BasketUrl=http://basket-api
    ports:
      - "5100:80"
    depends_on:
      - catalog-api
      - ordering-api
      - basket-api

  catalog-api:
    image: eshop/catalog-api
    environment:
      - ConnectionString=Server=sqldata;Initial Catalog=CatalogData;User Id=sa;Password=[PLACEHOLDER]
    expose:
      - "80"
    ports:
      - "5101:80"
    #extra hosts can be used for standalone SQL Server or services at the dev PC
    extra_hosts:
      - "CESARDLSURFBOOK:10.0.75.1"
    depends_on:
      - sqldata

  ordering-api:
    image: eshop/ordering-api
    environment:
      - ConnectionString=Server=sqldata;Database=Services.OrderingDb;User Id=sa;Password=[PLACEHOLDER]
    ports:
      - "5102:80"
    #extra hosts can be used for standalone SQL Server or services at the dev PC
    extra_hosts:
      - "CESARDLSURFBOOK:10.0.75.1"
    depends_on:
      - sqldata

  basket-api:
    image: eshop/basket-api
    environment:
      - ConnectionString=sqldata
    ports:
      - "5103:80"
    depends_on:
      - sqldata

  sqldata:
    environment:
      - SA_PASSWORD=[PLACEHOLDER]
      - ACCEPT_EULA=Y
    ports:
      - "5434:1433"

  basketdata:
    image: redis

La clé racine de ce fichier est services. Sous cette clé, vous définissez les services que vous souhaitez déployer et exécuter lorsque vous exécutez la commande ou lorsque vous effectuez le docker-compose up déploiement à partir de Visual Studio à l’aide de ce fichier docker-compose.yml. Dans ce cas, le fichier docker-compose.yml a plusieurs services définis, comme décrit dans le tableau suivant.

Nom du service Descriptif
webmvc Conteneur incluant l’application ASP.NET Core MVC consommant les microservices côté serveur C#
catalog-api Conteneur incluant le microservice de l’API web de catalogue ASP.NET Core
ordering-api Conteneur incluant le microservice de commande basé sur ASP.NET Core Web API
sqldata Conteneur exécutant SQL Server pour Linux, contenant les bases de données de microservices
basket-api Conteneur avec le microservice de l’API web Basket ASP.NET Core
basketdata Conteneur exécutant le service de cache REDIS, avec la base de données panier en tant que cache REDIS

Un conteneur d’API de service web simple

En se concentrant sur un seul conteneur, le microservice catalog-api a une définition simple.

  catalog-api:
    image: eshop/catalog-api
    environment:
      - ConnectionString=Server=sqldata;Initial Catalog=CatalogData;User Id=sa;Password=[PLACEHOLDER]
    expose:
      - "80"
    ports:
      - "5101:80"
    #extra hosts can be used for standalone SQL Server or services at the dev PC
    extra_hosts:
      - "CESARDLSURFBOOK:10.0.75.1"
    depends_on:
      - sqldata

Ce service conteneurisé a la configuration de base suivante :

  • Elle est basée sur l’image eshop/catalog-api personnalisée. Par souci de simplicité, il n’y a pas de paramètre 'build: key' dans le fichier. Cela signifie que l’image doit avoir été créée précédemment (avec docker build) ou téléchargée (avec la commande docker pull) à partir de n’importe quel registre Docker.

  • Il définit une variable d’environnement nommée ConnectionString avec la chaîne de connexion à utiliser par Entity Framework pour accéder à l’instance SQL Server qui contient le modèle de données du catalogue. Dans ce cas, le même conteneur SQL Server contient plusieurs bases de données. Par conséquent, vous avez besoin de moins de mémoire dans votre ordinateur de développement pour Docker. Toutefois, vous pouvez également déployer un conteneur SQL Server pour chaque base de données de microservice.

  • Le nom de SQL Server est sqldata, qui est le même nom que celui utilisé pour le conteneur qui exécute l’instance SQL Server pour Linux. C’est pratique ; la possibilité d’utiliser cette résolution de noms (interne à l’hôte Docker) résout l’adresse réseau afin que vous n’ayez pas besoin de connaître l’adresse IP interne des conteneurs que vous accédez à partir d’autres conteneurs.

Étant donné que la chaîne de connexion est définie par une variable d’environnement, vous pouvez définir cette variable par le biais d’un mécanisme différent et à un moment différent. Par exemple, vous pouvez définir une chaîne de connexion différente lors du déploiement en production dans les hôtes finaux, ou en le faisant à partir de vos pipelines CI/CD dans Azure DevOps Services ou votre système DevOps préféré.

  • Il expose le port 80 pour l’accès interne au service catalog-api au sein de l’hôte Docker. L’hôte est actuellement une machine virtuelle Linux, car elle est basée sur une image Docker pour Linux, mais vous pouvez configurer le conteneur pour qu’il s’exécute sur une image Windows à la place.

  • Il transfère le port exposé 80 sur le conteneur au port 5101 sur la machine hôte Docker (machine virtuelle Linux).

  • Il lie le service web au service sqldata (l’instance SQL Server pour la base de données Linux s’exécutant dans un conteneur). Lorsque vous spécifiez cette dépendance, le conteneur catalog-api ne démarre pas tant que le conteneur sqldata n’a pas déjà démarré ; cet aspect est important, car catalog-api doit d’abord disposer de la base de données SQL Server opérationnelle. Toutefois, ce type de dépendance de conteneur n’est pas suffisant dans de nombreux cas, car Docker vérifie uniquement au niveau du conteneur. Parfois, le service (dans ce cas SQL Server) peut toujours ne pas être prêt. Il est donc conseillé d’implémenter une logique de nouvelle tentative avec une interruption exponentielle dans vos microservices clients. De cette façon, si un conteneur de dépendances n’est pas prêt pendant une courte période, l’application sera toujours résiliente.

  • Il est configuré pour autoriser l’accès aux serveurs externes : le paramètre extra_hosts vous permet d’accéder à des serveurs externes ou à des machines en dehors de l’hôte Docker (autrement dit, en dehors de la machine virtuelle Linux par défaut, qui est un hôte Docker de développement), tel qu’une instance SQL Server locale sur votre PC de développement.

Il existe également d’autres paramètres plus avancés docker-compose.yml que nous aborderons dans les sections suivantes.

Utilisation de fichiers docker-compose pour cibler plusieurs environnements

Les fichiers sont des docker-compose.*.yml fichiers de définition et peuvent être utilisés par plusieurs infrastructures qui comprennent ce format. L’outil le plus simple est la commande docker-compose.

Par conséquent, à l’aide de la commande docker-compose, vous pouvez cibler les scénarios principaux suivants.

Environnements de développement

Lorsque vous développez des applications, il est important de pouvoir exécuter une application dans un environnement de développement isolé. Vous pouvez utiliser la commande CLI docker-compose pour créer cet environnement ou Visual Studio, qui utilise docker-compose en arrière-plan.

Le fichier docker-compose.yml vous permet de configurer et de documenter toutes les dépendances de service de votre application (autres services, cache, bases de données, files d’attente, etc.). À l’aide de la commande CLI docker-compose, vous pouvez créer et démarrer un ou plusieurs conteneurs pour chaque dépendance avec une seule commande (docker-compose up).

Les fichiers docker-compose.yml sont des fichiers de configuration interprétés par le moteur Docker, mais servent également de fichiers de documentation pratiques sur la composition de votre application multiconteneur.

Environnements de test

Une partie importante de tout processus de déploiement continu (CD) ou d’intégration continue (CI) est les tests unitaires et les tests d’intégration. Ces tests automatisés nécessitent un environnement isolé afin qu’ils ne soient pas affectés par les utilisateurs ou toute autre modification des données de l’application.

Avec Docker Compose, vous pouvez créer et détruire cet environnement isolé très facilement dans quelques commandes à partir de votre invite de commandes ou de scripts, comme les commandes suivantes :

docker-compose -f docker-compose.yml -f docker-compose-test.override.yml up -d
./run_unit_tests
docker-compose -f docker-compose.yml -f docker-compose-test.override.yml down

Déploiements de production

Vous pouvez également utiliser Compose pour effectuer un déploiement sur un moteur Docker distant. Un cas classique consiste à effectuer un déploiement sur une seule instance d’hôte Docker.

Si vous utilisez un autre orchestrateur (par exemple, Azure Service Fabric ou Kubernetes), vous devrez peut-être ajouter des paramètres de configuration d’installation et de métadonnées comme ceux de docker-compose.yml, mais dans le format requis par l’autre orchestrateur.

Dans tous les cas, docker-compose est un outil pratique et un format de métadonnées pour le développement, les tests et les flux de travail de production, bien que le flux de travail de production puisse varier sur l’orchestrateur que vous utilisez.

Utilisation de plusieurs fichiers docker-compose pour gérer plusieurs environnements

Lorsque vous ciblez différents environnements, vous devez utiliser plusieurs fichiers de composition. Cette approche vous permet de créer plusieurs variantes de configuration en fonction de l’environnement.

Remplacement du fichier docker-compose de base

Vous pouvez utiliser un fichier docker-compose.yml unique comme dans les exemples simplifiés présentés dans les sections précédentes. Toutefois, cela n’est pas recommandé pour la plupart des applications.

Par défaut, Compose lit deux fichiers, un docker-compose.yml et un fichier docker-compose.override.yml facultatif. Comme illustré dans la figure 6-11, lorsque vous utilisez Visual Studio et que vous activez la prise en charge de Docker, Visual Studio crée également un fichier docker-compose.vs.debug.g.yml supplémentaire pour le débogage de l’application, vous pouvez examiner ce fichier dans le dossier obj\Docker\ dans le dossier principal de la solution.

Les fichiers dans un projet Docker Compose.

Figure 6-11. Fichiers docker-compose dans Visual Studio 2019

structure de fichiers projet docker-compose :

  • .dockerignore - utilisé pour ignorer les fichiers
  • docker-compose.yml - utilisé pour composer des microservices
  • docker-compose.override.yml - utilisé pour configurer l’environnement de microservices

Vous pouvez modifier les fichiers docker-compose avec n’importe quel éditeur, comme Visual Studio Code ou Sublime, et exécuter l’application avec la commande docker-compose up.

Par convention, le fichier docker-compose.yml contient votre configuration de base et d’autres paramètres statiques. Cela signifie que la configuration du service ne doit pas changer en fonction de l’environnement de déploiement que vous ciblez.

Le fichier docker-compose.override.yml, comme son nom l’indique, contient des paramètres de configuration qui remplacent la configuration de base, comme la configuration qui dépend de l’environnement de déploiement. Vous pouvez également avoir plusieurs fichiers de remplacement avec différents noms. Les fichiers de remplacement contiennent généralement des informations supplémentaires nécessaires à l’application, mais spécifiques à un environnement ou à un déploiement.

Ciblage de plusieurs environnements

Un cas d’usage classique est lorsque vous définissez plusieurs fichiers de composition afin de pouvoir cibler plusieurs environnements, tels que la production, la préproduction, l’intégration continue ou le développement. Pour prendre en charge ces différences, vous pouvez fractionner votre configuration Compose en plusieurs fichiers, comme illustré dans la figure 6-12.

Diagramme de trois fichiers docker-compose définis pour remplacer le fichier de base.

Figure 6-12. Plusieurs fichiers docker-compose remplaçant des valeurs du fichier docker-compose.yml de base

Vous pouvez combiner plusieurs fichiers docker-compose*.yml pour gérer différents environnements. Vous commencez par le fichier de base docker-compose.yml. Ce fichier de base contient les paramètres de configuration de base ou statique qui ne changent pas en fonction de l’environnement. Par exemple, l’application eShopOnContainers a le fichier docker-compose.yml suivant (simplifié avec moins de services) comme fichier de base.

#docker-compose.yml (Base)
version: '3.4'
services:
  basket-api:
    image: eshop/basket-api:${TAG:-latest}
    build:
      context: .
      dockerfile: src/Services/Basket/Basket.API/Dockerfile
    depends_on:
      - basketdata
      - identity-api
      - rabbitmq

  catalog-api:
    image: eshop/catalog-api:${TAG:-latest}
    build:
      context: .
      dockerfile: src/Services/Catalog/Catalog.API/Dockerfile
    depends_on:
      - sqldata
      - rabbitmq

  marketing-api:
    image: eshop/marketing-api:${TAG:-latest}
    build:
      context: .
      dockerfile: src/Services/Marketing/Marketing.API/Dockerfile
    depends_on:
      - sqldata
      - nosqldata
      - identity-api
      - rabbitmq

  webmvc:
    image: eshop/webmvc:${TAG:-latest}
    build:
      context: .
      dockerfile: src/Web/WebMVC/Dockerfile
    depends_on:
      - catalog-api
      - ordering-api
      - identity-api
      - basket-api
      - marketing-api

  sqldata:
    image: mcr.microsoft.com/mssql/server:2019-latest

  nosqldata:
    image: mongo

  basketdata:
    image: redis

  rabbitmq:
    image: rabbitmq:3-management

Les valeurs du fichier de base docker-compose.yml ne doivent pas changer en raison de différents environnements de déploiement cible.

Si vous vous concentrez sur la définition de service webmvc, par exemple, vous pouvez voir comment ces informations sont beaucoup identiques, quel que soit l’environnement que vous ciblez. Vous disposez des informations suivantes :

  • Nom du service : webmvc.

  • Image personnalisée du conteneur : eshop/webmvc.

  • Commande permettant de générer l’image Docker personnalisée, indiquant le fichier Dockerfile à utiliser.

  • Dépendances sur d’autres services, de sorte que ce conteneur ne démarre pas tant que les autres conteneurs de dépendances n’ont pas démarré.

Vous pouvez avoir une configuration supplémentaire, mais le point important est que dans le fichier de base docker-compose.yml, vous souhaitez simplement définir les informations communes entre les environnements. Ensuite, dans le fichier docker-compose.override.yml ou des fichiers similaires pour la production ou la préproduction, vous devez placer la configuration spécifique à chaque environnement.

En règle générale, le docker-compose.override.yml est utilisé pour votre environnement de développement, comme dans l’exemple suivant d’eShopOnContainers :

#docker-compose.override.yml (Extended config for DEVELOPMENT env.)
version: '3.4'

services:
# Simplified number of services here:

  basket-api:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://0.0.0.0:80
      - ConnectionString=${ESHOP_AZURE_REDIS_BASKET_DB:-basketdata}
      - identityUrl=http://identity-api
      - IdentityUrlExternal=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5105
      - EventBusConnection=${ESHOP_AZURE_SERVICE_BUS:-rabbitmq}
      - EventBusUserName=${ESHOP_SERVICE_BUS_USERNAME}
      - EventBusPassword=${ESHOP_SERVICE_BUS_PASSWORD}
      - AzureServiceBusEnabled=False
      - ApplicationInsights__InstrumentationKey=${INSTRUMENTATION_KEY}
      - OrchestratorType=${ORCHESTRATOR_TYPE}
      - UseLoadTest=${USE_LOADTEST:-False}

    ports:
      - "5103:80"

  catalog-api:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://0.0.0.0:80
      - ConnectionString=${ESHOP_AZURE_CATALOG_DB:-Server=sqldata;Database=Microsoft.eShopOnContainers.Services.CatalogDb;User Id=sa;Password=[PLACEHOLDER]}
      - PicBaseUrl=${ESHOP_AZURE_STORAGE_CATALOG_URL:-http://host.docker.internal:5202/api/v1/catalog/items/[0]/pic/}
      - EventBusConnection=${ESHOP_AZURE_SERVICE_BUS:-rabbitmq}
      - EventBusUserName=${ESHOP_SERVICE_BUS_USERNAME}
      - EventBusPassword=${ESHOP_SERVICE_BUS_PASSWORD}
      - AzureStorageAccountName=${ESHOP_AZURE_STORAGE_CATALOG_NAME}
      - AzureStorageAccountKey=${ESHOP_AZURE_STORAGE_CATALOG_KEY}
      - UseCustomizationData=True
      - AzureServiceBusEnabled=False
      - AzureStorageEnabled=False
      - ApplicationInsights__InstrumentationKey=${INSTRUMENTATION_KEY}
      - OrchestratorType=${ORCHESTRATOR_TYPE}
    ports:
      - "5101:80"

  marketing-api:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://0.0.0.0:80
      - ConnectionString=${ESHOP_AZURE_MARKETING_DB:-Server=sqldata;Database=Microsoft.eShopOnContainers.Services.MarketingDb;User Id=sa;Password=[PLACEHOLDER]}
      - MongoConnectionString=${ESHOP_AZURE_COSMOSDB:-mongodb://nosqldata}
      - MongoDatabase=MarketingDb
      - EventBusConnection=${ESHOP_AZURE_SERVICE_BUS:-rabbitmq}
      - EventBusUserName=${ESHOP_SERVICE_BUS_USERNAME}
      - EventBusPassword=${ESHOP_SERVICE_BUS_PASSWORD}
      - identityUrl=http://identity-api
      - IdentityUrlExternal=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5105
      - CampaignDetailFunctionUri=${ESHOP_AZUREFUNC_CAMPAIGN_DETAILS_URI}
      - PicBaseUrl=${ESHOP_AZURE_STORAGE_MARKETING_URL:-http://host.docker.internal:5110/api/v1/campaigns/[0]/pic/}
      - AzureStorageAccountName=${ESHOP_AZURE_STORAGE_MARKETING_NAME}
      - AzureStorageAccountKey=${ESHOP_AZURE_STORAGE_MARKETING_KEY}
      - AzureServiceBusEnabled=False
      - AzureStorageEnabled=False
      - ApplicationInsights__InstrumentationKey=${INSTRUMENTATION_KEY}
      - OrchestratorType=${ORCHESTRATOR_TYPE}
      - UseLoadTest=${USE_LOADTEST:-False}
    ports:
      - "5110:80"

  webmvc:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://0.0.0.0:80
      - PurchaseUrl=http://webshoppingapigw
      - IdentityUrl=http://10.0.75.1:5105
      - MarketingUrl=http://webmarketingapigw
      - CatalogUrlHC=http://catalog-api/hc
      - OrderingUrlHC=http://ordering-api/hc
      - IdentityUrlHC=http://identity-api/hc
      - BasketUrlHC=http://basket-api/hc
      - MarketingUrlHC=http://marketing-api/hc
      - PaymentUrlHC=http://payment-api/hc
      - SignalrHubUrl=http://${ESHOP_EXTERNAL_DNS_NAME_OR_IP}:5202
      - UseCustomizationData=True
      - ApplicationInsights__InstrumentationKey=${INSTRUMENTATION_KEY}
      - OrchestratorType=${ORCHESTRATOR_TYPE}
      - UseLoadTest=${USE_LOADTEST:-False}
    ports:
      - "5100:80"
  sqldata:
    environment:
      - SA_PASSWORD=[PLACEHOLDER]
      - ACCEPT_EULA=Y
    ports:
      - "5433:1433"
  nosqldata:
    ports:
      - "27017:27017"
  basketdata:
    ports:
      - "6379:6379"
  rabbitmq:
    ports:
      - "15672:15672"
      - "5672:5672"

Dans cet exemple, la configuration de surdéfinition de développement expose certains ports à l'ordinateur hôte, définit des variables d'environnement avec des URL de redirection et spécifie des chaînes de connexion pour l'environnement de développement. Ces paramètres sont uniquement destinés à l’environnement de développement.

Quand vous exécutez docker-compose up, ou quand vous lancez cette commande à partir de Visual Studio, elle lit automatiquement les remplacements comme si elle fusionnait les deux fichiers.

Supposons que vous souhaitez un autre fichier Compose pour l’environnement de production, avec différentes valeurs de configuration, ports ou chaînes de connexion. Vous pouvez créer un autre fichier de remplacement, tel que le fichier nommé docker-compose.prod.yml avec différents paramètres et variables d’environnement. Ce fichier peut être stocké dans un autre dépôt Git ou géré et sécurisé par une autre équipe.

Comment déployer avec un fichier de remplacement spécifique

Pour utiliser plusieurs fichiers de remplacement ou un fichier de remplacement portant un autre nom, vous pouvez utiliser l’option -f avec la commande docker-compose et spécifier les fichiers. Compose fusionne les fichiers dans l’ordre dans lequel ils sont spécifiés sur la ligne de commande. L’exemple suivant montre comment déployer avec des fichiers de remplacement.

docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d

Utilisation de variables d’environnement dans des fichiers docker-compose

Il est pratique, en particulier dans les environnements de production, d’obtenir des informations de configuration à partir de variables d’environnement, comme nous l’avons montré dans les exemples précédents. Vous pouvez référencer une variable d’environnement dans vos fichiers docker-compose à l’aide de la syntaxe ${MY_VAR}. La ligne suivante d’un fichier docker-compose.prod.yml montre comment référencer la valeur d’une variable d’environnement.

IdentityUrl=http://${ESHOP_PROD_EXTERNAL_DNS_NAME_OR_IP}:5105

Les variables d’environnement sont créées et initialisées de différentes façons, selon votre environnement hôte (Linux, Windows, cluster cloud, etc.). Toutefois, une approche pratique consiste à utiliser un fichier .env. Les fichiers docker-compose prennent en charge la déclaration des variables d’environnement par défaut dans le fichier .env. Ces valeurs pour les variables d’environnement sont les valeurs par défaut. Toutefois, elles peuvent être remplacées par les valeurs que vous avez peut-être définies dans chacun de vos environnements (système d’exploitation hôte ou variables d’environnement à partir de votre cluster). Vous placez ce fichier .env dans le dossier à partir duquel la commande docker-compose est exécutée.

L’exemple suivant montre un fichier .env comme le fichier .env pour l’application eShopOnContainers.

# .env file

ESHOP_EXTERNAL_DNS_NAME_OR_IP=host.docker.internal

ESHOP_PROD_EXTERNAL_DNS_NAME_OR_IP=10.121.122.92

Docker-compose s’attend à ce que chaque ligne d’un fichier .env soit au format <variable>=<value>.

Les valeurs définies dans l’environnement d’exécution remplacent toujours les valeurs définies dans le fichier .env. De la même façon, les valeurs passées via des arguments de ligne de commande remplacent également les valeurs par défaut définies dans le fichier .env.

Ressources supplémentaires

Création d’images Docker de base ASP.NET optimisées

Si vous explorez Docker et .NET sur des sources sur Internet, vous trouverez des fichiers Dockerfile qui illustrent la simplicité de création d’une image Docker en copiant votre source dans un conteneur. Ces exemples suggèrent qu’à l’aide d’une configuration simple, vous pouvez avoir une image Docker avec l’environnement empaqueté avec votre application. L’exemple suivant montre un fichier Dockerfile simple dans cette veine.

FROM mcr.microsoft.com/dotnet/sdk:8.0
WORKDIR /app
ENV ASPNETCORE_URLS http://+:80
EXPOSE 80
COPY . .
RUN dotnet restore
ENTRYPOINT ["dotnet", "run"]

Un fichier Dockerfile comme celui-ci fonctionnera. Toutefois, vous pouvez optimiser considérablement vos images, en particulier vos images de production.

Dans le modèle reposant sur un conteneur et des microservices, vous démarrez constamment des conteneurs. La méthode habituelle d’utilisation des conteneurs ne permet pas de redémarrer un conteneur en veille, parce que le conteneur est conçu pour être jetable. Les orchestrateurs (comme Kubernetes et Azure Service Fabric) créent de nouvelles instances d’images. Cela signifie que vous devez optimiser en précompilant l’application lorsqu’elle est générée afin que le processus d’instanciation soit plus rapide. Une fois le conteneur démarré, il doit être prêt à fonctionner. Ne restaurez pas et ne compilez pas au moment de l’exécution à l’aide des commandes CLI dotnet restore et dotnet build comme vous le voyez dans les billets de blog sur .NET et Docker.

L’équipe .NET a effectué un travail important pour rendre .NET et ASP.NET Core un framework optimisé pour les conteneurs. Non seulement .NET est-il un framework léger avec une petite empreinte mémoire ; l’équipe s’est concentrée sur les images Docker optimisées pour trois scénarios principaux et les a publiées dans le registre Docker Hub à dotnet/, à compter de la version 2.1 :

  • Développement : la priorité est la possibilité d’itérer et de déboguer rapidement les modifications, et où la taille est secondaire.
  • Build : la priorité consiste à compiler l’application et l’image inclut des fichiers binaires et d’autres dépendances pour optimiser les fichiers binaires.
  • Production : L'accent est mis sur le déploiement et le démarrage rapides des conteneurs, de sorte que ces images se limitent aux fichiers binaires et au contenu nécessaires pour exécuter l’application.

L’équipe .NET fournit des variantes de base dans dotnet/, par exemple :

  • sdk : pour les scénarios de développement et de génération
  • aspnet : pour les scénarios de production ASP.NET
  • runtime : pour les scénarios de production .NET
  • runtime-deps : pour les scénarios de production d’applications autonomes

Pour un démarrage plus rapide, les images runtime définissent également automatiquement aspnetcore_urls sur le port 80 et utilisent Ngen pour créer un cache d'images natives des assemblages.

Ressources supplémentaires

PrécédentSuivant