Utilisation de conteneurs Windows pour « conteneuriser » des applications existantes

S’applique à : Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Les conteneurs Windows offrent un excellent mécanisme pour moderniser les applications traditionnelles ou héritées. Bien que vous entendiez peut-être cette approche appelée « lift-and-shift to containers », la métaphore lift-and-shift provient du déplacement des charges de travail de machines physiques vers des machines virtuelles, et est utilisée lors du déplacement de charges de travail vers le cloud. Aujourd’hui, ce terme est plus approprié pour migrer des machines virtuelles. Toutefois, les conteneurs ne sont pas des machines virtuelles et pensent-les comme des machines virtuelles peuvent entraîner une confusion sur la façon dont une application est conteneurisée, ou si elle peut, ou doit, être conteneurisée.

Cette rubrique fournit des conseils pratiques sur le déplacement d’applications traditionnelles vers des conteneurs Windows. Il vise à vous aider à hiérarchiser les applications devant être conteneurisées, en expliquant les considérations spéciales à prendre en compte.

Présentation

Quels sont les conteneurs Windows et ce qu’ils ne sont pas

Le terme générique conteneur désigne une technologie qui virtualise le système d’exploitation. Cette virtualisation offre un niveau d’isolation du système d’exploitation du serveur/hôte lui-même, ce qui permet à son tour une plus grande agilité pour les développeurs d’applications et les équipes d’exploitation.

Les conteneurs Windows sont une implémentation spécifique de la technologie de conteneur. Ils fournissent des instances de systèmes d’exploitation virtualisés isolés du système d’exploitation Windows. Mais l’interdépendance totale entre le conteneur et l’hôte est impossible : un conteneur Windows doit coordonner sa demande de ressources et de fonctions avec le système d’exploitation Windows. Pourquoi est-ce important ? Étant donné qu’un conteneur Windows n’est pas un serveur virtualisé entier et que certaines des choses que vous souhaitez peut-être faire avec une application ne peuvent pas être effectuées uniquement avec un système d’exploitation virtualisé.

Vous pouvez en savoir plus sur ce sujet dans Conteneurs vs. machines virtuelles. Voici quelques points utiles qui vous aideront à vous rappeler la distinction entre conteneurs et machines virtuelles :

• Les conteneurs ne sont pas une solution équivalente à la virtualisation des applications de bureau. Ils prennent uniquement en charge les applications côté serveur qui ne nécessitent pas de session interactive. Étant donné qu’ils s’exécutent sur des images conteneur spécialisées, ils prennent uniquement en charge les applications qui n’ont pas besoin d’un front-end graphique.
• Les conteneurs sont éphémères par nature. Cela signifie que, par défaut, aucun mécanisme n’est utilisé pour enregistrer l’état d’une instance de conteneur. En cas d’échec d’une instance, une autre instance aura lieu.

La technologie de conteneur a commencé sur Linux, avec Docker émergent comme standard. Microsoft a travaillé en étroite collaboration avec Docker pour garantir que la fonctionnalité de conteneur est la même sur Windows que possible. Les différences inhérentes entre Linux et Windows peuvent apparaître de manière à ce qu’elles semblent être des limitations des conteneurs Windows lorsqu’en fait ils sont uniquement les différences Linux et Windows. D’autre part, les conteneurs Windows fournissent des implémentations uniques, telles que Hyper-V isolation, qui seront couvertes ultérieurement. Cette rubrique vous aide à comprendre ces différences et comment les prendre en charge.

Avantages de l’utilisation de conteneurs

Tout comme l’exécution de plusieurs machines virtuelles sur un seul hôte physique, vous pouvez exécuter plusieurs conteneurs sur un seul hôte physique ou virtuel. Mais contrairement aux machines virtuelles, vous n’avez pas besoin de gérer le système d’exploitation pour un conteneur, ce qui vous donne la possibilité de vous concentrer sur le développement d’applications et l’infrastructure sous-jacente. Cela signifie également que vous pouvez isoler une application afin qu’elle ne soit pas affectée par d’autres processus pris en charge par le système d’exploitation.

Les conteneurs fournissent une méthode légère de création et d’arrêt dynamique des ressources requises pour une application fonctionnelle. Bien qu’il soit possible de créer et de déployer des machines virtuelles à mesure que la demande d’application augmente, il est plus rapide d’utiliser des conteneurs pour effectuer un scale-out. Avec les conteneurs, vous pouvez également redémarrer rapidement en cas d’incident ou d’interruption matérielle. Les conteneurs vous permettent de passer du développement à la production avec peu ou pas de modification du code, car ils « contiennent » des dépendances d’application afin qu’elles fonctionnent entre les environnements. La possibilité de conteneuriser une application existante avec des modifications de code minimales, en raison de l’intégration docker dans les outils de développement Microsoft, est également un facteur puissant dans le développement et la maintenance des applications.

Enfin, l’un des avantages les plus importants de l’utilisation de conteneurs est l’agilité que vous gagnez pour le développement d’applications, car vous pouvez avoir différentes versions d’une application s’exécutant sur le même hôte sans conflit de ressources.

Vous trouverez une liste plus complète des avantages liés à l’utilisation de conteneurs pour les applications existantes sur la page de documentation Microsoft .NET.

Concept important de niveau d’isolation

Les conteneurs Windows fournissent l’isolation du système d’exploitation Windows, l’isolation qui est avantageuse lorsque vous créez, testez et favorisez une application en production. Mais la façon dont l’isolation est obtenue est importante pour comprendre quand vous envisagez de conteneuriser une application.

Les conteneurs Windows offrent deux modes distincts d’isolation du runtime : processus et Hyper-V . Les conteneurs sous les deux modes sont créés et gérés de façon identique et fonctionnent de façon identique. Alors, quelles sont les différences et pourquoi devez-vous vous soucier ?

Dans le processus d'isolation , plusieurs conteneurs s’exécutent simultanément sur un seul hôte avec l’isolation fournie via l’espace de noms, le contrôle des ressources et d'autres fonctionnalités. Les conteneurs en mode d’isolation de processus partagent le même noyau avec l’hôte et les uns les autres. Il s’agit à peu près de la même chose que la façon dont les conteneurs Linux s’exécutent.

Dans Hyper-V isolation, plusieurs conteneurs s’exécutent également simultanément sur un seul hôte, mais les conteneurs s’exécutent à l’intérieur de machines virtuelles hautement optimisées, chacun obtenant efficacement son propre noyau. La présence de cette machine virtuelle – en fait une machine virtuelle « utilitaire » fournit une isolation au niveau matériel entre chaque conteneur et l’hôte de conteneur.

En un sens, le mode d'isolement Hyper-V est presque comme un hybride entre une machine virtuelle et un conteneur, fournissant une couche supplémentaire de sécurité particulièrement utile si votre application a besoin de multilocataires. Toutefois, les compromis possibles liés à l’utilisation du mode d’isolation Hyper-V sont les suivants :

• Durée de démarrage plus longue pour le conteneur et impact probable sur les performances globales des applications.
• Tous les outils ne fonctionnent pas nativement avec l'isolation Hyper-V.
• Actuellement, ni Azure Kubernetes Service (AKS) ni AKS sur Azure Stack HCI ne prennent en charge l’isolation Hyper-V.

Vous pouvez en savoir plus sur la façon dont les deux modes d’isolation sont implémentés dans la rubrique Modes d’isolation. Lorsque vous conteneurisez une application pour la première fois, vous devez choisir entre les deux modes. Heureusement, il est très facile de passer d’un mode à un autre ultérieurement, car il ne nécessite aucune modification de l’application ou du conteneur. Mais sachez que, lorsque vous conteneurisez une application, le choix entre les deux modes est l’une des premières choses que vous devrez faire.

Orchestration de conteneurs

La possibilité d’exécuter plusieurs conteneurs sur un ou plusieurs hôtes sans souci de gestion du système d’exploitation vous offre une grande flexibilité, ce qui vous permet de passer à une architecture basée sur des microservices. Un compromis pour cette flexibilité, cependant, est qu’un environnement basé sur des conteneurs et des microservices peut rapidement se transformer en de nombreuses parties mobiles - trop nombreux pour être suivis. Heureusement, la gestion de l’équilibrage de charge, de la haute disponibilité, de la planification des conteneurs, de la gestion des ressources, et bien plus encore, est le rôle d’un orchestrateur de conteneurs.

Les orchestrateurs sont peut-être mal nommés ; ils ressemblent davantage à des chefs d’orchestre, car ils coordonnent l’activité de plusieurs conteneurs pour faire jouer la musique. Dans un sens, ils gèrent la planification et l’allocation de ressources pour les conteneurs d’une manière similaire au fonctionnement d’un système d’exploitation. Par conséquent, lorsque vous passez à la conteneurisation de vos applications, vous devez choisir parmi les orchestrateurs qui prennent en charge les conteneurs Windows. Certaines des plus courantes sont Kubernetes et Docker Swarm.

Ce qui ne peut pas être déplacé vers des conteneurs Windows

Lorsque vous déterminez si une application peut être conteneurisée ou non, il est probablement plus facile de commencer par la liste des facteurs qui excluent complètement les conteneurs Windows comme option.

Le tableau suivant récapitule les types d’applications qui ne peuvent pas être déplacés vers des conteneurs Windows, et pourquoi pas. Les raisons sont plus complètes dans les sous-sections après le tableau. Comprendre les raisons de ces limitations peut vous donner une idée plus claire de ce que sont réellement les conteneurs, y compris la façon dont ils diffèrent des machines virtuelles. Cela vous aidera à mieux évaluer les capacités des conteneurs Windows dont vous pouvez tirer parti avec les applications existantes que vous pouvez conteneuriser.

Remarque : la liste ci-dessous n’est pas une liste complète. Au lieu de cela, il s’agit d’une compilation d’applications que Microsoft a vu les clients essayer de conteneuriser.

Prenons chacun de ces limitations à son tour.

Applications nécessitant un bureau

Les conteneurs sont idéaux pour les fonctions éphémères appelées à partir d’autres applications, y compris celles avec des interactions utilisateur. Mais vous ne pouvez pas les utiliser pour les applications qui ont elles-mêmes des interfaces graphiques. Cela est vrai même si l’application elle-même n’a pas d’interface utilisateur graphique, mais a un programme d’installation qui s’appuie sur une interface utilisateur utilisateur. En règle générale, Windows Installer peut être appelé à l’aide de PowerShell, mais si votre application nécessite une installation via une interface utilisateur graphique, cette exigence l’élimine en tant que candidat au conteneurisation.

Ce n’est pas un problème avec la façon dont les conteneurs Windows ont été implémentés, mais plutôt un concept fondamental de fonctionnement des conteneurs.

Il s’agit d’une autre question si une application a besoin d’API d’interface graphique graphique. Les API sont prises en charge même si l'interface graphique fournie par ces API ne l'est pas. Ceci est plus entièrement expliqué dans la rubrique Nano Server x Server Core x Server - Quelle image de base est la bonne pour vous ?

Applications utilisant RDP

Étant donné que l’objectif complet du protocole RDP (Remote Desktop Protocol) est d’établir une session visuelle interactive, la limitation de l’interface graphique graphique s’applique également. Une application utilisant RDP ne peut pas être conteneurisée as-is.

Toutefois, une bonne alternative est un outil de gestion à distance tel que Windows Admin Center. Vous pouvez utiliser Windows Admin Center pour gérer les hôtes de Windows containers et les conteneurs eux-mêmes, sans avoir besoin de se connecter via RDP. Vous pouvez également ouvrir une session PowerShell distante sur l’hôte et/ou les conteneurs pour les gérer.

Applications avec état

Les applications qui doivent conserver les données d’état peuvent être conteneurisées uniquement si vous isolez les données nécessaires d’une session à l’autre et stockez-les dans un stockage persistant. Cela peut nécessiter une « réarchitecture », qui peut ou non être triviale, mais continuer avec elle éliminera cette barrière au conteneurisation.

Un exemple d’état est une application web qui stocke des images ou des fichiers musicaux dans un dossier local. Dans un environnement Windows traditionnel, un fichier est enregistré sur le disque au moment où l’opération d’écriture se termine. Par conséquent, si l’instance (une machine virtuelle dans ce cas) échoue, il vous suffit de le ramener et le fichier reste là. En revanche, si une instance de conteneur effectuant une opération d’écriture échoue, la nouvelle instance de conteneur n’inclut pas ce fichier. Pour cette raison, vous devez envisager d’utiliser un stockage persistant afin que toutes les instances de conteneur puissent stocker des données d’état ou des fichiers à un emplacement centralisé et durable. Ce type de réarchitecture ne vous oblige pas à modifier le code de l’application, juste le type de stockage utilisé par l’instance Windows. Pour plus d’informations, consultez la documentation relative au stockage du conteneur Windows.

Toutefois, cela apporte un autre sujet connexe...

Applications de base de données

En règle générale, les applications de base de données ne sont pas idéales pour la conteneurisation. Bien que vous puissiez exécuter une base de données à l’intérieur d’un conteneur, le conteneurisation d’une base de données existante n’est généralement pas idéal, pour deux raisons.

Tout d’abord, les performances nécessaires pour une base de données peuvent nécessiter l’ensemble des ressources matérielles disponibles pour l’hôte, ce qui dévalue l’avantage de la consolidation. Deuxièmement, plusieurs instances d’un niveau base de données unique nécessitent une coordination pour ses opérations d’écriture. L’orchestration de conteneurs peut résoudre ce problème, mais pour les bases de données existantes, l’orchestration peut devenir une surcharge. La plupart des bases de données, telles que Microsoft SQL Server, disposent d’un équilibre de charge intégré et d’un mécanisme de haute disponibilité.

Rôles d’infrastructure sur Windows Server

Les rôles d’infrastructure Windows Server gèrent principalement les fonctions plus proches du système d’exploitation (par exemple, AD, DHCP et Serveur de fichiers). Par conséquent, elles ne sont pas disponibles pour l’exécution de conteneurs. Par conséquent, les applications qui ont besoin de ces rôles seront toujours difficiles à conteneuriser.

Il y a des zones grises. Par exemple, certaines fonctionnalités telles que DNS peuvent fonctionner sur des conteneurs Windows, même si elles ne sont pas vraiment destinées à être utilisées dans des conteneurs. D’autres rôles d’infrastructure sont simplement supprimés de l’image conteneur de base et ne peuvent pas être installés, comme Active Directory, DHCP et d’autres.

Active Directory (AD)

Active Directory a été publié il y a plus de vingt ans le long de Windows 2000 Server. Il utilise un mécanisme dans lequel chaque appareil ou utilisateur est représenté par un objet stocké dans sa base de données. Cette relation est étroitement couplée et les objets sont conservés dans la base de données même si l’utilisateur ou l’appareil réel n’est plus actif. Cette approche d'Active Directory contredit directement la nature éphémère des conteneurs, qui sont censés être de courte durée ou supprimés lorsqu'ils sont désactivés. La gestion de cette relation un-à-un avec Active Directory n’est pas idéale pour ces scénarios.

Pour cette raison, les conteneurs Windows ne peuvent pas être joints à un domaine. En conséquence, vous ne pouvez pas exécuter active Directory Domain Services en tant que rôle d’infrastructure sur des conteneurs Windows. Vous pouvez exécuter le module PowerShell pour gérer les contrôleurs de domaine à distance à l’intérieur d’un conteneur Windows.

Pour les applications s’exécutant sur des conteneurs Windows dépendants d’Active Directory, utilisez des comptes de service administré de groupe (gMSA), qui seront expliqués plus en détail.

Applications utilisant .NET Framework version 2.0 ou antérieure

Si votre application nécessite .NET, votre capacité à conteneuriser dépend entièrement de la version de .NET Framework qu’elle utilise. Toute version antérieure à .NET Framework 2.0 n’est pas prise en charge du tout ; Les versions ultérieures nécessitent l’utilisation d’images spécifiques, comme décrit plus loin.

Applications utilisant des infrastructures tierces (non-Microsoft)

En règle générale, Microsoft ne parvient pas à certifier des infrastructures ou applications tierces, ou à les prendre en charge sur des conteneurs Windows, ou des machines physiques et virtuelles. Toutefois, Microsoft effectue ses propres tests internes pour la convivialité de plusieurs frameworks et outils tiers, notamment Apache, Cassandra, Chocolatey, Datadog, Django, Flask, Git, Golang, JBoss, Jenkins, Rust, Nodejs, Pearl, Python, Ruby, Tomcat, etc.

Pour tout framework ou logiciel tiers, vérifiez sa prise en charge sur les conteneurs Windows avec le fournisseur qui l’fournit.

Candidats idéaux pour la conteneurisation

Maintenant que nous avons considéré les limitations difficiles sur les applications conteneurisées, il est plus facile de voir quels types d’applications se prêtent plus facilement aux conteneurs Windows. Les candidats idéaux pour les conteneurs Windows, et toutes les considérations particulières à prendre en compte pour les conteneuriser, se trouvent dans le tableau suivant.

Remarque : même ces candidats idéaux pour la conteneurisation peuvent s’appuyer sur les principales fonctionnalités et composants Windows qui devront être gérés différemment dans les conteneurs Windows. La section suivante, qui aborde plus en détail ces considérations pratiques, vous préparera mieux à tirer parti des fonctionnalités des conteneurs Windows.

Considérations pratiques pour les applications pouvant être conteneurisées

Les projets de rénovation d’application prennent généralement en compte si une application particulière peut être conteneurisée par le biais de la perspective de la fonction métier de l’application. Mais la fonctionnalité métier n’est pas le facteur qui détermine s’il est techniquement possible. Ce qui est important, c’est l’architecture de l’application, c’est-à-dire les composants techniques sur lesquels elle repose. Par conséquent, il n’existe aucune réponse facile à une question telle que « Puis-je conteneuriser mon application RH ? », car ce n’est pas ce que fait l’application, c’est comment (et quels composants/services Windows il utilise) qui fait la différence.

Il s’agit d’une distinction importante, car si votre application n’est pas créée avec une architecture de microservices pour commencer, il est probable qu’elle soit plus difficile à conteneuriser. Au fur et à mesure que vous continuez à le conteneuriser, certaines fonctionnalités peuvent nécessiter une gestion spéciale. Certains peuvent être dus à l’utilisation par l’application des composants et infrastructures Windows de base qui ne sont pas pris en charge dans les conteneurs Windows. D’autres, telles que la journalisation et la surveillance des événements, sont dues à des différences inhérentes entre Linux et Windows qui ne deviennent apparentes que lorsque vous conteneurisez l’application. D’autres encore, telles que les tâches planifiées et les services en arrière-plan, doivent être comprises du point de vue du fait qu’un conteneur n’est pas une machine virtuelle, mais qu’il est éphémère et a donc besoin d’une gestion spéciale.

Le tableau suivant présente un résumé rapide des composants/fonctionnalités des applications qui ont besoin d’une considération particulière lorsque vous envisagez de conteneuriser. Les sous-sections qui suivent vous donnent plus de détails, notamment des exemples illustrant des techniques de gestion de chaque scénario. Bien que la liste ci-dessous couvre les scénarios pris en charge sur les conteneurs Windows, ces scénarios doivent toujours respecter les instructions du chapitre précédent. Par exemple, si les services en arrière-plan sont pris en charge, l’exécution d’un service en arrière-plan sur .NET Framework 1.1 n’est pas prise en charge.

Autres composants de soutien

Composants/fonctionnalités Windows

Examinons maintenant les détails des applications et des composants qui peuvent être conteneurisés, mais nécessitent une gestion supplémentaire.

MSMQ

Si votre application dépend de MSMQ, si vous pouvez la conteneuriser dépend de son scénario de déploiement MSMQ. MSMQ inclut plusieurs options de déploiement. Les facteurs de files d’attente privées et publiques, transactionnelles ou non, et le type d’authentification forment une matrice de scénarios initialement conçus pour prendre en charge MSMQ. Tous ces éléments ne peuvent pas être facilement déplacés vers des conteneurs Windows. Le tableau suivant répertorie les scénarios pris en charge :

Quelques remarques sur ces scénarios pris en charge, qui ont été validés par les équipes de développement internes de Microsoft :

• Mode d’isolation : mode processus et mode Hyper-V pour l’isolation fonctionnent avec les scénarios répertoriés ci-dessus.
• Image minimale du système d’exploitation et du conteneur : la version minimale du système d’exploitation recommandée pour l’utilisation avec MSMQ est Windows Server 2019.
• Volumes persistants : les scénarios ci-dessus ont été validés en exécutant MSMQ sur Azure Kubernetes Service (AKS) à l’aide de fichiers Azure pour le stockage persistant.

Lorsque vous mettez ces considérations ensemble avec le tableau ci-dessus, vous pouvez voir que le seul scénario qui n’est pas pris en charge est destiné aux files d’attente qui nécessitent l’authentification avec Active Directory. L’intégration des comptes de service administrés de groupe (gMSA) avec MSMQ n’est actuellement pas prise en charge, car MSMQ a des dépendances sur Active Directory qui ne sont pas encore en place.

Vous pouvez également utiliser Azure Service Bus au lieu de MSMQ. Azure Service Bus est un répartiteur de messages d’entreprise entièrement géré avec des files d’attente de messages et des rubriques de publication-abonnement (dans un espace de noms). Le passage de MSMQ à Azure Service Bus nécessite des modifications de code et une nouvelle architecture d’application, mais vous donnera l’agilité nécessaire pour passer à une plateforme moderne.

MSDTC

Microsoft Distributed Transaction Coordinator (MSDTC) est fortement utilisé dans les applications héritées Windows parmi les grandes entreprises. MSDTC peut être installé sur des conteneurs Windows, mais certains scénarios ne fonctionnent pas et ne peuvent pas être reproduits sur des conteneurs Windows.

• Lors de la création du conteneur, veillez à passer le paramètre --name à la commande Docker Run. Ce paramètre de nom permet aux conteneurs de communiquer sur le réseau Docker. Si vous utilisez gMSA, le nom doit correspondre au nom d’hôte qui doit correspondre au nom du compte gMSA.
  • Voici un exemple de commande d’exécution avec gMSA :

docker run -d --security-opt "credentialspec=file://contoso_webapp01.json" --hostname webapp01 -- name webapp01 mcr.microsoft.com/windows/servercore:ltsc2022

• Les conteneurs doivent être en mesure de se résoudre mutuellement à l’aide du nom NETBIOS. S’il existe des difficultés à résoudre, la meilleure façon de résoudre consiste à ajouter le nom et l’adresse IP des conteneurs aux autres fichiers hôtes.
• L'identifiant UUID pour msdtc sur chaque conteneur doit être unique. L’UUID peut être trouvé en exécutant « Get-Dtc » dans PowerShell sur les conteneurs. S’ils ne sont pas uniques, une façon de résoudre consiste à désinstaller et réinstaller msdtc sur l’un des conteneurs. Ces commandes powershelll peuvent être utilisées : « uninstall-dtc », « install-dtc ».
• Actuellement, MSDTC n’est pas pris en charge sur Azure Kubernetes Services. Si vous avez un besoin spécifique d’exécuter MSDTC sur AKS, veuillez en informer l’équipe des conteneurs Windows en ouvrant un problème sur le dépôt Windows containers sur GitHub.

Fonctionnement d’IIS dans un conteneur et une machine virtuelle

IIS fonctionne de la même façon sur un conteneur Windows que dans une machine virtuelle. Toutefois, certains aspects de l’exécution d’une instance IIS doivent être pris en compte lors de l’exécution sur un environnement de conteneur :

• Stockage persistant pour les données locales : dossiers sur lesquels l’application écrit/lit des fichiers vers/depuis sont un excellent exemple d’élément que vous conservez dans une machine virtuelle pour une instance IIS. Avec les conteneurs, vous ne souhaitez pas écrire de données directement dans le conteneur. Les conteneurs utilisent un « espace de travail » pour le stockage local et lorsqu’un nouveau conteneur apparaît pour la même application, il n’a pas accès à cette zone à partir d’un conteneur précédent. Pour cette raison, utilisez le stockage persistant pour les données qui doivent être accessibles à l’application web, afin que n’importe quelle instance de conteneur puisse avoir accès à ce stockage.
• Certificats : bien que vous puissiez avoir des certificats locaux sur des instances de conteneur, évitez de le faire, car si un certificat doit être mis à jour, vous devez reconstruire votre image conteneur. Vous pouvez aussi utiliser un orchestrateur de conteneurs avec un contrôle d’entrée. Les contrôleurs d’entrée peuvent appliquer des stratégies réseau et gérer la gestion des certificats pour le site web hébergé derrière lui. L’avantage est de dissocier la gestion du cycle de vie des certificats de la gestion du site web.
• Chaînes de connexion de base de données : pour le déploiement IIS traditionnel, vous pouvez passer la chaîne de connexion de base de données dans le cadre de votre déploiement d’application. Bien que les conteneurs Windows vous permettent de suivre ce modèle, vous pouvez envisager de découpler la chaîne de connexion de base de données du conteneur à une configuration centralisée fournie par l’orchestrateur de conteneur, à partir de laquelle l’application peut lire. Cela vous permet de gérer et de mettre à jour la chaîne de connexion de base de données indépendamment de l’application. Si la base de données change (pour les cas de lift-and-shift vers le cloud, par exemple), vous pouvez facilement modifier la chaîne de connexion sans regénérer votre image conteneur. Cette approche vous permet également de conserver des secrets (tels que le nom d’utilisateur et le mot de passe pour la connexion à la base de données) sur un magasin de secrets.
• Mise à l’échelle automatique horizontale : lorsque la charge augmente, les systèmes de calcul ont tendance à ralentir les performances perçues lors de la tentative de traitement des demandes simultanées. Il existe généralement deux façons d’éviter l’impact sur les performances, soit l’échelle verticale ou horizontale. L’échelle verticale augmente les ressources disponibles pour les instances de calcul existantes (plus d’UC, de mémoire, etc.). La mise à l’échelle horizontale augmente le nombre d’instances prenant en charge les requêtes (plus d’hôtes physiques, de machines virtuelles ou de conteneurs). Pour les niveaux web tels que IIS, l’échelle horizontale tend à être plus efficace que verticale, mais les environnements locaux peuvent rencontrer des limitations de ressources et des problèmes d’équilibrage de charge. Avec les environnements cloud, l’échelle horizontale est beaucoup plus facile à mesure que les ressources sont facilement disponibles (pour un coût supplémentaire) et le fournisseur de cloud conçoit généralement son mécanisme d’équilibrage de charge avec une échelle horizontale à l’esprit. Les conteneurs Windows peuvent tirer parti de la mise à l’échelle horizontale pour IIS, mais l’aspect éphémère des conteneurs joue un rôle important. Il est impératif que vos conteneurs aient la même configuration et qu’aucun état ou données n’est stocké pour permettre un scale-up ou un scale-down du nombre d’instances prenant en charge votre application web.

Tâches planifiées

Les tâches planifiées sont utilisées pour appeler un programme, un service ou un script à tout moment dans un environnement Windows. Traditionnellement, vous disposez d’une instance Windows opérationnelle à tout moment et quand un déclencheur est atteint, la tâche est exécutée. Cela est possible avec les conteneurs Windows et, en dehors du fait que vous devez configurer et gérer des tâches planifiées via Azure PowerShell, ils fonctionnent exactement de la même façon.

Toutefois, avec une approche de microservices, vous disposez de plusieurs options pour éviter de maintenir un conteneur actif en attente d'un déclencheur :

• Utilisez un PaaS piloté par les événements (Platform as a Service) tel qu’Azure Function pour stocker votre code et définir un déclencheur pour cette application. Azure Functions prend même en charge l’exécution d’images conteneur Windows lorsqu’un déclencheur est activé.
• Utilisez des conteneurs Windows conjointement avec un orchestrateur de conteneurs. Le conteneur ne peut s’exécuter que lorsque le déclencheur est atteint et appelé à partir d’autres parties de l’application. Dans ce cas, l'orchestrateur des conteneurs gère la planification et le déclenchement de l’application.
• Enfin, conservez un conteneur Windows en cours d’exécution pour exécuter une tâche planifiée. Vous aurez besoin d’un service de premier plan (tel que Service Monitor) pour garantir le fonctionnement continu du conteneur.

Services en arrière-plan

Bien que les conteneurs soient généralement destinés aux processus éphémères, vous pouvez conteneuriser une application en arrière-plan, à long terme, à condition de créer un processus de premier plan pour le lancer et le maintenir en cours d’exécution.

Un excellent exemple est ServiceMonitor, qui est un exécutable Windows conçu pour être utilisé comme processus de point d’entrée lors de l’exécution d’IIS dans des conteneurs. Bien qu’il ait été créé pour IIS, l’outil ServiceMonitor offre un modèle qui peut également être utilisé pour surveiller d’autres services, avec certaines limitations.

Pour plus d’informations sur ServiceMonitor, consultez la documentation sur Github.

.NET Framework et .NET

Les conteneurs Windows prennent en charge .NET Framework et .NET (anciennement .NET Core). L’équipe .NET crée ses propres images officielles pour les deux frameworks à partir des images conteneur de base Windows. Le choix de l’image appropriée est essentiel pour garantir la compatibilité. L’équipe .NET fournit des images .NET Framework créées à partir de l’image conteneur de base Server Core, et les images .NET créées à partir des images conteneur de base Server Core et Nano Server. Server Core a un ensemble d’API plus volumineux que Nano Server, ce qui permet une plus grande compatibilité, mais également une plus grande taille d’image. Nano Server a une surface d’API fortement réduite, mais une taille d’image beaucoup plus petite.

Dans certains cas, vous devrez peut-être créer votre propre image .NET Framework ou .NET par-dessus les images conteneur de base Windows Server. Cela peut être nécessaire si votre application a non seulement une dépendance d’infrastructure, mais une dépendance de système d’exploitation. Vous pourrez détecter toutes ces dépendances en testant votre application avec une image conteneur de base particulière.

Par exemple, les images conteneur de base Server Core et Nano Server n’ont qu’une seule police disponible pour réduire la taille de l’image. Si votre application nécessite une police différente, vous devez installer cette police ou utiliser les images Server ou Windows, qui ont un ensemble d’API plus étendu et incluent toutes les polices Windows par défaut. Du point de vue de la compatibilité, cela permet à pratiquement n’importe quelle application (tant qu’elles respectent la nature des conteneurs, comme no-GUI) d’être conteneurisées. À l’inconvénient, elles seront beaucoup plus volumineuses, ce qui peut affecter les performances.

Lors de la validation si l’application à conteneuriser fonctionne sur des conteneurs Windows, Microsoft recommande les éléments suivants :

Autres composants de soutien

Les composants et les rubriques ci-dessous fournissent des conseils supplémentaires pour les éléments qui s’accompagnent ou qui fournissent une meilleure clarté sur les conteneurs Windows.

Journalisation des événements

Windows et Linux utilisent différentes méthodes pour stocker et présenter les journaux et les événements à leurs utilisateurs. Traditionnellement, Windows a utilisé le format EVT, qui peut être consulté de manière structurée dans l’Observateur d’événements. En revanche, Linux a fourni une approche simplifiée avec la sortie standard (stdout) sur laquelle d’autres outils, tels que Docker, s’appuient.

Docker a toujours eu un mécanisme pour extraire les journaux des conteneurs Linux. À l’aide de la commande « docker logs » avec une configuration stdout par défaut, Docker fait sortir les journaux d’activité de l’application du conteneur sans ouvrir le conteneur de manière interactive. Toutefois, jusqu’au lancement de l’outil Log Monitor, la même technique ne fonctionnait pas sur Windows.

L’outil Log Monitor présente les journaux Windows au format stdout afin que d’autres outils, tels que Docker, puissent collecter les informations nécessaires pour l’afficher. Les avantages supplémentaires de l’utilisation de Log Monitor sont les suivants :

• Être en mesure de filtrer les types d’événements/journaux que vous souhaitez exposer sur stdout. Par exemple, vous pouvez filtrer le journal des applications pour les messages « erreur » et « avertissement » uniquement si vous n’êtes pas intéressé par les événements « information ».
• Possibilité de choisir parmi les journaux d’événements, les fichiers journaux personnalisés ou le suivi des événements pour Windows (ETW). Cela est particulièrement utile si votre application écrit sur une autre source de log. Les journaux IIS qui se trouvent dans le dossier « C:\inetpub » en sont un exemple.
• Le fait que Log Monitor amène les conteneurs Windows à se comporter de manière semblable à des conteneurs Linux permet aux outils qui recherchent la sortie standard et interagissent avec le runtime du conteneur de fonctionner comme prévu. Par exemple, si vous passez de Docker à ContainerD comme runtime des conteneurs, les journaux doivent toujours être visibles depuis l’hôte des conteneurs via (par exemple) « crictl logs ».

Pour plus d’informations sur l’outil Log Monitor, consultez ce billet de blog.

Sécurité des conteneurs Windows

Les conteneurs Windows sont basés sur la même base que les instances Windows s’exécutant sur des machines physiques ou virtuelles. Comprendre les spécificités de l’implémentation des conteneurs, en particulier leur nature de noyau partagé, vous aide à sécuriser une application conteneurisée :

• Composants partagés. Les conteneurs Windows partagent certains des composants de l’hôte à des fins de sécurité. Cela inclut le Pare-feu Windows, Windows Defender (Antivirus) et d’autres limitations d’accès aux ressources. Vous n’avez pas besoin de configurer ces composants directement sur votre conteneur, car l’hôte de conteneur effectue les ajustements nécessaires en fonction de votre charge de travail de conteneur. Par exemple, si le conteneur effectue une requête web, l’hôte du conteneur transfère le trafic nécessaire via son pare-feu afin que le conteneur puisse accéder au web.
• Mode d’isolation. Comme indiqué, les conteneurs Windows peuvent être déployés en mode processus ou d'isolation Hyper-V, Hyper-V offrant l'isolation la plus sécurisée. En isolation de processus, le conteneur partage son noyau, son système de fichiers et son registre avec l’hôte, ce qui permet à un processus avec élévation de privilèges (administrateur) d’interagir avec les processus et services du conteneur. Le choix du mode d’isolation approprié pour votre application est important pour garantir le modèle de sécurité approprié.
• Mises à jour Windows. Étant donné que la pile de maintenance n’est pas présente sur les conteneurs Windows, les conteneurs Windows ne reçoivent pas de mises à jour telles que les instances Windows générales. Au lieu de cela, vous devez reconstruire des conteneurs Windows à l’aide de la dernière image de conteneur de base disponible. Les clients peuvent tirer parti des pipelines DevOps à cet effet. Microsoft met à jour les images conteneur de base pour toutes ses images officielles chaque mois, en suivant la cadence de Patch Tuesday.
• Compte d’utilisateur de conteneur. Par défaut, les applications à l’intérieur des conteneurs Windows s’exécutent avec des privilèges élevés sous le compte d’utilisateur ContainerAdmin. Cela est utile pour installer et configurer les composants nécessaires à l’intérieur de l’image conteneur. Toutefois, vous devez envisager de modifier le compte d’utilisateur en ContainerUser lors de l’exécution d’une application qui ne nécessite pas les privilèges élevés. Pour des scénarios spécifiques, vous pouvez également créer un compte avec les privilèges appropriés.
• Analyse des images et des runtimes. Les conteneurs nécessitent que les images sur les référentiels et les instances des conteneurs soient sécurisés. Microsoft vous recommande d’utiliser Microsoft Defender pour conteneurs pour l’analyse d’images et l’analyse du runtime. Defender pour conteneurs prend en charge les conteneurs Windows pour l’évaluation des vulnérabilités avec l’analyse du Registre et la protection du runtime avec la détection des menaces.

Vous pouvez trouver plus d’informations sur les rubriques ci-dessus sur la page de documentation des conteneurs Windows.

Sauvegarde des conteneurs Windows

Vous devez réfléchir aux sauvegardes différemment lors de l’utilisation de conteneurs. Comme indiqué précédemment, un conteneur ne doit pas être utilisé pour stocker l’état ou les données en fonction de sa nature éphémère. Si vous séparez l’état et les données de l’instance de conteneur, vos problèmes de sauvegarde sont en dehors du runtime de l’instance de conteneur, ce qui peut être remplacé par un nouveau dans lequel tout le stockage persistant nécessaire sera toujours disponible.

Toutefois, il existe toujours des composants que vous êtes responsable de la sauvegarde ; y compris l’application, l’image conteneur et le fichier dockerfile qui génère l’image conteneur. La plupart de ces opérations sont gérées par la plateforme sur laquelle vous exécutez vos charges de travail de production et de développement. Lors de l’adoption d’une approche DevOps, tenez compte des cas les plus courants :

• Application : votre application réside probablement dans un référentiel source tel que GitHub ou Azure DevOps. Ces référentiels fournissent un contrôle de version, ce qui vous permet de revenir à une version spécifique de l’application. Si vous êtes propriétaire du référentiel source, veillez à suivre ses recommandations de sauvegarde et de gestion.
• Image conteneur : pour les environnements de production, votre image conteneur doit se trouver dans un référentiel d’images centralisé, tel qu’Azure Container Registry (ACR). Vous pouvez envoyer (push) vos images conteneur vers ACR afin qu’elles puissent être extraites par d’autres hôtes. ACR gère la disponibilité des images conteneur et sert d’option de sauvegarde. Toutefois, gardez à l’esprit que, bien que L’ACR gère la disponibilité de l’image, elle n’empêche pas la suppression ou le remplacement d’une image. Pour tout autre référentiel d'images local ou sur site, suivez la recommandation du fournisseur pour sauvegarder les registres existants.
• Dockerfile : Les fichiers Dockerfile créent de nouvelles images conteneur et sont généralement stockés avec la source de l’application. Étant donné que le dockerfile n’a peut-être pas été créé avec l’application, surtout s’il s’agit d’une application existante en cours de conteneurisation, il est de votre responsabilité de vous assurer que le dockerfile est stocké dans un emplacement sécurisé et sauvegardé. Vous devez également vous assurer que toutes les autres ressources nécessaires pour que votre application fonctionne dans un conteneur sont sauvegardées ; par exemple : les fichiers YAML et JSON pour Kubernetes, Docker Swarm et les modèles Azure ARM suivent les mêmes instructions que ci-dessus.

Planification du processus lift-and-shift

Une fois que vous avez évalué la préparation de votre application pour le conteneurisation, utilisez les conseils généraux suivants pour planifier le processus :

1. Déterminez l’image de base du système d’exploitation Windows dont vous avez besoin : Windows Server Core, Nano Server, Windowsou Server images.
2. Déterminez le type de mode d’isolation du conteneur : choisissez entre le mode processus ou le mode Hyper-V. Remarque : Actuellement, AKS et AKS sur Azure Stack HCI prennent uniquement en charge les conteneurs isolés par processus. Dans une prochaine version, AKS et AKS sur Azure Stack HCI prennent également en charge les conteneurs isolés Hyper-V. Pour plus d’informations, consultez Modes d’isolation.
3. Choisissez la version de Windows Server appropriée pour votre application à des fins de compatibilité d’application. La version minimale de Windows Server pour les conteneurs est Windows Server 2016, mais Windows Server 2019 et Windows Server 2022 sont les seuls systèmes d’exploitation hôtes de conteneur pris en charge sur AKS et AKS sur Azure Stack HCI.
4. Vérifiez que les stratégies de sécurité de votre entreprise sont en place pour l’environnement de conteneur. Cela inclut l’adaptation aux exigences spécifiques au conteneur, telles que l’analyse du Registre et la détection des menaces.
5. Tenez compte des besoins d’équilibrage de charge. Les conteneurs eux-mêmes ne se déplacent pas ; Vous pouvez utiliser un orchestrateur à la place pour démarrer ou arrêter automatiquement des conteneurs sur des nœuds de cluster, ou pour gérer les modifications de charge et de disponibilité avec une mise à l’échelle horizontale automatique.
6. Tenez compte des besoins d’orchestration. Une fois en conteneur, votre application a probablement besoin d’une gestion automatisée disponible avec des outils tels que Kubernetes, AKS ou AKS sur Azure Stack HCI. Consultez Vue d’ensemble de l’orchestration de conteneurs Windows pour obtenir une présentation complète et un guide pour choisir parmi les outils.
7. Conteneuriser l’application.
8. Envoyez l’application à un référentiel d’images. Cela permet aux hôtes de conteneur de télécharger l’image dans n’importe quel environnement, notamment le développement, le test et la production.

Azure Migrate peut fournir un processus guidé pour découvrir, évaluer et migrer votre application Windows existante vers Azure Kubernetes Service. Pour plus d’informations, consultez la page de documentation Azure Migrate.