Partager via

Utilisation de conteneurs Windows pour « conteneuriser » des applications existantes

  • Article

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

Les conteneurs Windows offrent un mécanisme idéal pour moderniser les applications traditionnelles ou héritées. Même si vous pouvez parfois entendu parler de cette approche dans les termes « lift-and-shift vers des containeurs », la métaphore « lift-and-shift » provient du passage de charges de travail physiques sur des machines virtuelles et elle a été utilisée plus tard lors du déplacement de charges de travail telles quelles vers le cloud (qu’il soit privé ou public). Aujourd’hui, ce terme est appliqué de façon plus appropriée à la migration de machines virtuelles. Les conteneurs ne sont cependant pas des machines virtuelles et les considérer ainsi peut entraîner de la confusion quant à la façon dont une application peut être conteneurisée, ou même 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. Elle vise à vous aider à prioriser les applications à conteneuriser, en expliquant d’abord les considérations spéciales à prendre en compte.

Introduction

Ce que sont les conteneurs Windows et ce qu’ils ne sont pas

Le terme générique « conteneur » fait référence à une technologie qui virtualise le système d’exploitation. Cette virtualisation fournit un niveau d’isolation vis-à-vis du système d’exploitation du serveur/de l’hôte lui-même, ce qui à son tour donne plus d’agilité aux développeurs d’applications et aux équipes des opérations.

Les conteneurs Windows sont une implémentation spécifique de la technologie des conteneurs. 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 un conteneur et un 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 ? Parce qu’un conteneur Windows n’est pas un serveur virtualisé entier et que certaines choses que vous voulez faire avec une application ne peuvent pas être effectuées avec seulement un système d’exploitation virtualisé.

Vous pouvez en savoir plus sur cette question dans Conteneurs et machines virtuelles. Voici néanmoins quelques éléments qui vous aident à vous rappeler les distinctions entre un conteneur et une machine virtuelle :

  • Les conteneurs ne sont pas une solution équivalente à la virtualisation des applications sur ordinateur. Ils prennent en charge seulement les applications côté serveur qui ne nécessitent pas de session interactive. Comme ils s’exécutent sur des images conteneur spécialisées, ils prennent en charge seulement 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, il n’y a pas de mécanisme pour enregistrer l’état d’une instance de conteneur. Si une instance échoue, une autre instance prendra sa place.

La technologie des conteneurs a commencé sur Linux, avec Docker émergeant comme standard. Microsoft a travaillé étroitement avec Docker pour garantir que les fonctionnalités des conteneurs soit aussi identiques que possible sur Windows. Les différences inhérentes entre Linux et Windows peuvent apparaître comme des limitations des conteneurs Windows, alors qu’en fait, ce ne sont que les différences entre Linux et Windows. En revanche, les conteneurs Windows fournissent quelques implémentations uniques, comme l’isolation Hyper-V, qui sera abordée ultérieurement. Cette rubrique vous aidera à comprendre ces différences et comment vous y adapter.

Avantages de l’utilisation des conteneurs

Tout comme plusieurs machines virtuelles peuvent s’exécuter sur un même hôte physique, vous pouvez exécuter plusieurs conteneurs sur un même 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 offre la flexibilité nécessaire pour vous concentrer sur le développement d’applications et sur 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 pour créer et arrêter dynamiquement les ressources nécessaires pour une application en fonctionnement. Bien qu’il soit possible de créer et de déployer des machines virtuelles à mesure que la demande des applications augmente, il est plus rapide d’utiliser des conteneurs pour effectuer un scale-out. Avec les conteneurs, vous pouvez aussi redémarrer rapidement en cas de plantage ou d’interruption matérielle. Les conteneurs vous permettent de prendre en charge n’importe quelle application du développement à la production sans ou avec peu de modification du code, car elles « contiennent » les dépendances de l’application pour que celle-ci puisse fonctionner sur différents environnements. La possibilité de conteneuriser une application existante avec des modifications minimales du code grâce à l’intégration de Docker dans les outils de développement Microsoft est également un facteur puissant dans le développement et la maintenance des applications.

Enfin, un des avantages les plus importants de l’utilisation de conteneurs est l’agilité dont vous bénéficiez 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 qu’il y ait de conflits de ressources.

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

Le niveau d’isolation : un concept important

Les conteneurs Windows fournissent une isolation vis-à-vis du système d’exploitation Windows, isolation qui est un avantage quand vous créez, que vous testez et que vous faites passer une application en production. Mais comprendre la façon dont l’isolation est obtenue est important quand vous envisagez de conteneuriser une application.

Les conteneurs Windows offrent deux modes distincts d’isolation du runtime : processus et Hyper-V. Les conteneurs s’exécutant sous les deux modes d’isolation sont créés et gérés de façon identique, et ils fonctionnent de façon identique. Quelles sont donc les différences et pourquoi devez-vous y être attentif ? Dans l’isolation des processus, plusieurs conteneurs s’exécutent simultanément sur un même hôte en bénéficiant d’une 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 avec les autres conteneurs. Ceci est pratiquement identique à la façon dont les conteneurs Linux s’exécutent.

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

D’une certaine façon, le mode d’isolation Hyper-V est presque comme un hybride d’une machine virtuelle et d’un conteneur, fournissant une couche supplémentaire de sécurité particulièrement utile si votre application a besoin du multilocataire. Cependant, les compromis éventuellement à faire lors de 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 de l’application.
  • Certains outils ne fonctionnent nativement avec l’isolation Hyper-V.
  • Ni Azure Kubernetes Service (AKS) ni AKS sur Azure Stack HCI ne prennent pas en charge actuellement 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. Quand 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, car cela ne nécessite aucune modification de l’application ou du conteneur. Notez cependant que, quand vous conteneurisez une application, le choix entre les deux modes est 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 s’inquiéter de la gestion du système d’exploitation vous offre une grande flexibilité, ce qui vous permet de passer à une architecture basée sur les microservices. Un compromis pour bénéficier de cette est cependant qu’un environnement basé sur des conteneurs et des microservices peut rapidement aboutir à un trop grand nombre d’éléments mobiles, trop nombreux pour que le suivi en soit possible. Heureusement, la gestion de l’équilibrage de charge, la haute disponibilité, la planification des conteneurs, la gestion des ressources et d’autres choses encore, est le rôle d’un orchestrateur de conteneurs.

Les orchestrateurs sont peut-être mal nommés : ce sont en fait davantage des chefs d’orchestre en cela qu’ils coordonnent l’activité de plusieurs conteneurs pour que tout se passe bien. En un sens, ils gèrent la planification et l’allocation des ressources pour les conteneurs d’une façon similaire au fonctionnement d’un système d’exploitation. Ainsi, quand vous passez à la conteneurisation de vos applications, vous devez choisir parmi les orchestrateurs qui prennent en charge les conteneurs Windows. Kubernetes et Docker Swarm sont parmi les plus courants.

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

Quand vous considérez 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 le choix des conteneurs Windows.

Le tableau suivant récapitule les types d’applications qui ne peuvent pas être déplacés vers des conteneurs Windows et pourquoi ce n’est pas possible. Les raisons sont plus expliquées plus complètement 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 en quoi ils diffèrent des machines virtuelles. Ceci vous aidera à mieux évaluer les fonctionnalité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 exhaustive. Il s’agit en fait d’une compilation d’applications dont Microsoft a pu voir que les clients essayaient de conteneuriser.

Applications/fonctionnalités non prises en charge Pourquoi elles ne sont pas pris en charge. Pouvez-vous contourner cela ?
Applications nécessitant un bureau Les conteneurs ne prennent pas en charge l’interface utilisateur graphique Si l’application nécessite une interface utilisateur graphique seulement pour son installation, passer à une installation silencieuse peut être une solution
Applications utilisant le protocole RDP (Remote Desktop Protocol) RDP est destiné aux sessions interactives : le principe ci-dessus s’applique donc également ici. Vous pouvez peut-être utiliser Windows Admin Center (WAC) ou Remote PowerShell comme alternative à la gestion à distance
Applications avec état Les conteneurs sont éphémères Oui, certaines applications peuvent nécessiter une modification minimale, de façon à qu’elles ne stockent pas de données ou d’état à l’intérieur du conteneur
applications de base de données ; Les conteneurs sont éphémères Oui, certaines applications peuvent nécessiter une modification minimale, de façon à qu’elles ne stockent pas de données ou d’état à l’intérieur du conteneur
Active Directory La conception et l’objectif d’Active Directory excluent son exécution dans un conteneur Non. Cependant, les applications dépendantes d’Active Directory peuvent utiliser des comptes de service administré de groupe (gMSA). D’autres informations sur gMSA sont fournies ci-dessous.
Versions plus anciennes de Windows Server Seul Windows Server 2016 ou ultérieur est pris en charge. Non. Cependant, la compatibilité des applications peut être une option : la plupart des applications Windows Server 2008/R2 et des applications plus anciennes fonctionnent sur des versions plus récentes de Windows Server
Applications utilisant .NET Framework version 2.0 ou antérieure Des images conteneur spécifiques sont nécessaires pour prendre en charge le .NET Framework, et seules les versions plus récentes sont prises en charge Les versions antérieures à 2.0 ne sont pas du tout prises en charge, mais reportez-vous ci-dessous pour les images conteneur nécessaires pour les versions ultérieures
Applications utilisant d’autres frameworks de tiers Microsoft ne certifie ni ne prend en charge spécifiquement l’utilisation de frameworks non-Microsoft sur des conteneurs Windows Vérifiez avec le fournisseur du framework ou de l’application spécifique la stratégie de prise en charge des conteneurs Windows. Pour plus d’informations, voir ci-dessous.

Considérons chacune de ces limitations.

Applications nécessitant un bureau

Les conteneurs sont idéaux pour les fonctions éphémères qui sont appelées depuis d’autres applications, y compris celles qui impliquent des interactions utilisateur. Vous ne pouvez cependant pas les utiliser pour les applications qui ont elles-mêmes des interfaces utilisateur graphiques. Ceci est vrai même si l’application elle-même n’a pas d’interface utilisateur graphique, mais qu’elle a un programme d’installation qui s’appuie sur une interface utilisateur graphique. En général, Windows Installer peut être appelé en utilisant PowerShell, mais si votre application nécessite une installation via une interface utilisateur graphique, cette exigence l’élimine comme candidat à la 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 la façon dont les conteneurs fonctionnent.

C’est une autre question si une application a besoin d’API d’interface utilisateur graphique. Les API sont prises en charge même si l’interface utilisateur graphique fournie par ces API ne le sont pas. Ceci est expliqué plus en détails dans la rubrique Nano Server x Server Core x Server - Quelle image de base convient pour vous ?

Applications utilisant RDP

L’objectif général du protocole RDP (Remote Desktop Protocol) étant d’établir une session visuelle interactive, la limitation de l’interface utilisateur graphique qui vient d’être décrite s’applique également. Une application utilisant RDP ne peut pas être conteneurisée telle quelle.

Cependant, une bonne alternative est un outil de gestion à distance, comme Windows Admin Center. Vous pouvez utiliser Windows Admin Center pour gérer les hôtes de conteneurs Windows et les conteneurs eux-mêmes, sans avoir besoin de RDP dans ceux-ci. Vous pouvez aussi ouvrir une session PowerShell distante sur l’hôte et/ou sur les conteneurs pour les gérer.

Applications avec état

Les applications qui doivent conserver les données d’état peuvent être conteneurisées seulement si vous isolez les données nécessaires d’une session à la suivante et que vous les stockez dans un stockage persistant. Ceci peut nécessiter une « réarchitecture » qui peut ou non être triviale, mais qui va éliminer cet obstacle à la conteneurisation.

Un exemple d’état est une application web qui stocke des images ou des fichiers audio 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 : si l’instance (dans ce cas, une machine virtuelle) échoue, vous pouvez donc simplement la remettre en service et le fichier sera toujours là. En revanche, si une instance de conteneur effectuant une opération d’écriture échoue, la nouvelle instance de conteneur ne va pas inclure 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, mais seulement le type de stockage utilisé par l’instance Windows. Pour plus d’informations, consultez la documentation sur le stockage des conteneurs Windows.

Ceci nous amène cependant à un sujet connexe...

applications de base de données ;

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

Tout d’abord, les performances nécessaires pour une base de données peuvent nécessiter que l’ensemble des ressources matérielles soient disponibles pour l’hôte, ce qui dévalorise le bénéfice de la consolidation. Deuxièmement, plusieurs instances d’un même niveau de base de données ont besoin de coordination pour leurs opérations d’écriture. L’orchestration de conteneurs peut résoudre cela, mais pour des bases de données existantes, l’orchestration peut devenir une surcharge. La plupart des bases de données, comme Microsoft SQL Server, ont un mécanisme intégré d’équilibrage de charge et 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). Ils ne sont donc pas disponibles pour exécuter des conteneurs. Par conséquent, les applications nécessitant ces rôles seront toujours difficiles à conteneuriser.

Il y a quelques zones grises. Par exemple, certaines fonctionnalités, comme 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 rôles.

Active Directory (AD)

Active Directory a été publié il y a plus de vingt ans avec 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 utilisé. Cette approche pour Active Directory contredit directement la nature éphémère des conteneurs, qui sont censés avoir une durée de vie courte ou être supprimés quand ils sont arrêtés. Conserver 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 raison de cela, 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, vous pouvez utiliser des comptes de service administrés de groupe (gMSA), qui seront expliqués plus loin.

Applications utilisant .NET Framework version 2.0 ou antérieure

Si votre application nécessite .NET, votre possibilité de 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 du tout prise en charge ; les versions ultérieures nécessitent l’utilisation d’images spécifiques, comme décrit plus loin.

Applications utilisant des frameworks de tiers (non-Microsoft)

D’une façon générale, Microsoft ne peut pas certifier des frameworks ou des applications de tiers, ou supporter leur exécution sur des conteneurs Windows, ou des machines physiques et virtuelles utilisées à cette fin. Cependant, Microsoft procède à ses propres tests internes sur l’utilisabilité de plusieurs frameworks et outils de tiers, notamment Apache, Cassandra, Chocolatey, Datadog, Django, Flask, Git, Golang, JBoss, Jenkins, Rust, Nodejs, Pearl, Python, Ruby, Tomcat et beaucoup d’autres.

Pour n’importe quel framework ou logiciel de tiers, vérifiez sa prise en charge sur les conteneurs Windows avec son fournisseur.

Candidats idéaux à la conteneurisation

Maintenant que nous avons considéré les limites strictes de la conteneurisation des applications, 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 les considérations particulières à prendre en compte pour les conteneuriser figurent dans le tableau suivant.

Type d’application Pourquoi ce sont de bons candidats Considérations spéciales
Applications console Sans limitations liées à l’interface utilisateur graphique, les applications console sont des candidats idéaux pour les conteneurs. Utilisez l’image conteneur de base appropriée en fonction des besoins de l’application.
Services Windows Parce que ce sont des processus d’arrière-plan qui ne nécessitent aucune interaction directe avec l’utilisateur Utilisez l’image conteneur de base appropriée en fonction des besoins de l’application. Vous devez créer un processus d’avant-plan pour qu’un processus d’arrière-plan conteneurisé continue de s’exécuter. Consultez la section sur les services d’arrière-plan ci-dessous.
Services WCF (Windows Communication Foundation) Parce que ce sont des applications orientées service qui peuvent également s’exécuter en arrière-plan Utilisez l’image conteneur de base appropriée en fonction des besoins de l’application. Il peut être nécessaire de créer un processus d’avant-plan pour qu’un processus d’arrière-plan conteneurisé continue de s’exécuter. Consultez la section sur les services d’arrière-plan ci-dessous.
les applications web Les applications web sont par essence des services d’arrière-plan qui écoutent sur un port spécifique et ce sont donc de bons candidats à la conteneurisation, car elles peuvent tirer parti de la scalabilité offerte par les conteneurs Utilisez l’image conteneur de base appropriée en fonction des besoins de l’application.

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

Considérations pratiques pour les applications qui peuvent être conteneurisées

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

C’est une distinction importante, car si votre application n’est pas créée au départ avec une architecture de microservices, elle est probablement plus difficile à conteneuriser. Quand vous procédez à sa conteneurisation, certaines fonctionnalités peuvent avoir besoin d’une gestion spéciale. Elle peut être due en partie à l’utilisation par l’application de composants et de frameworks Windows de base qui ne sont pas pris en charge dans les conteneurs Windows. D’autres fonctionnalités, comme la journalisation et la supervision des événements, nécessitent cette gestion spéciale en raison de différences entre Linux et Windows qui apparaissent seulement quand vous conteneurisez l’application. D’autres encore, comme les tâches planifiées et les services d’arrière-plan, doivent être comprises selon le point de vue qu’un conteneur n’est pas une machine virtuelle, mais qu’il est éphémère et nécessite donc une gestion spéciale.

Le tableau suivant présente un récapitulatif rapide des composants/fonctionnalités des applications qui doivent considérés d’une façon particulière quand vous envisagez la conteneurisation. Les sous-sections qui suivent vous donnent plus de détails, avec des exemples illustrant des techniques pour gérer chaque scénario. Bien que la liste ci-dessous couvre des 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 des services d’arrière-plan sont pris en charge, l’exécution d’un service d’arrière-plan sur .NET Framework 1.1 n’est pas prise en charge.

Fonctionnalité/composant Windows nécessitant une gestion spéciale Motif
MSMQ (Microsoft Message Queuing) MSMQ est apparu bien avant les conteneurs et certains de ses modèles de déploiement pour les files d’attente de messages ne sont pas compatibles avec l’architecture des conteneurs.
Microsoft Distributed Transaction Coordinator (MSDTC) La résolution de noms entre MSDTC et le conteneur nécessite une attention particulière.
IIS IIS est identique à ce qu’il est dans une machine virtuelle, mais il y a des considérations importantes quand il est exécuté dans un environnement de conteneur, comme la gestion des certificats, les chaînes de connexion de base de données, etc.
Tâches planifiées Les conteneurs Windows peuvent exécuter des tâches planifiées, tout comme n’importe quelle instance Windows. Cependant, il peut être nécessaire d’exécuter une tâche d’avant-plan pour que l’instance de conteneur continue de s’exécuter. Selon l’application, vous pouvez envisager une approche pilotée par les événements.
Services d’arrière-plan Comme les conteneurs s’exécutent en tant que processus éphémères, vous aurez besoin d’une gestion supplémentaire pour que le conteneur continue de s’exécuter.
.NET Framework et .NET (anciennement .NET Core) Veillez à utiliser l’image appropriée pour garantir la compatibilité, comme expliqué dans la sous-section ci-dessous.

Autres composants de prise en charge

Composant nécessitant une gestion spéciale Motif Autre approche
Journalisation/supervision des événements Parce que la façon dont Windows écrit les événements et les journaux est intrinsèquement différente du flux stdout de Linux Utilisez le nouvel outil Log Monitor pour normaliser les données, et pour les combiner à partir de Linux et de Windows
Sécurité des conteneurs Windows Bien que de nombreuses pratiques de sécurité restent les mêmes, les conteneurs nécessitent des mesures de sécurité supplémentaires Utilisez un outil d’analyse de registre et d’image spécialement conçu (ceci est présenté plus en détails plus loin)
Sauvegarde des conteneurs Windows Les conteneurs ne doivent pas contenir des données ou des états Sauvegardez le stockage persistant utilisé par les conteneurs ainsi que les images conteneur

Composants/fonctionnalités Windows

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

MSMQ

Si votre application dépend de MSMQ, la possibilité de la conteneuriser dépend de son scénario de déploiement MSMQ. MSMQ inclut plusieurs options de déploiement. Les facteurs que sont les files d’attente privées ou publiques, le caractère transactionnel ou non, et le type d’authentification forment une matrice de scénarios que MSMQ a été conçu à l’origine pour prendre en charge. Certains de ces scénarios ne peuvent pas être facilement implémentés dans des conteneurs Windows. Le tableau suivant liste les scénarios pris en charge :

Étendue Transactionnel ? Emplacement de la file d’attente Type d'authentification Envoyer et recevoir ?
Privées Oui Même conteneur (un seul conteneur) Anonyme Yes
Privées Oui Volume persistant Anonyme Yes
Privées Oui Contrôleur de domaine Anonyme Yes
Privées Oui Un seul hôte (deux conteneurs) Anonyme Yes
Public No Deux hôtes Anonyme Yes
Public Yes Deux hôtes Anonyme Yes

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 : le mode processus et le mode Hyper-V pour l’isolation fonctionnent avec les scénarios listés ci-dessus.
  • Système d’exploitation minimal et image conteneur : la version minimale du système d’exploitation recommandée à utiliser avec MSMQ est Windows Server 2019.
  • Volumes persistants : les scénarios ci-dessus ont été validés comme exécutant MSMQ sur Azure Kubernetes Service (AKS) en utilisant Azure Files pour le stockage persistant.

Quand vous rapprochez ces considérations du tableau ci-dessus, vous pouvez voir que le seul scénario qui n’est pas pris en charge concerne les files d’attente qui nécessitent une authentification auprès d’Active Directory. L’intégration des comptes de service administrés de groupe (gMSA) à MSMQ n’est actuellement pas prise en charge, car MSMQ a des dépendances vis-à-vis d’Active Directory qui ne sont pas encore en place.

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

MSDTC

Microsoft Distributed Transaction Coordinator (MSDTC) est très utilisé dans les applications existantes 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.

  • Lorsque vous créez le conteneur, veillez à passer le paramètre --name à la commande docker run. Ce paramètre name est ce qui 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 run 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 avec le nom NETBIOS. Si vous rencontrez des difficultés avec cela, la meilleure résolution consiste à ajouter le nom et l’adresse IP des conteneurs aux fichiers hôtes des uns et des autres.
  • L’uuid pour msdtc sur les deux conteneurs doit être unique. Vous pouvez trouver l’uuid en exécutant « Get-Dtc » dans PowerShell sur les conteneurs. S’ils ne sont pas uniques, une résolution consiste à désinstaller et à réinstaller msdtc sur l’un des conteneurs. Ces commandes PowerShell 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, informez l’équipe des conteneurs Windows en ouvrant un problème dans le dépôt de conteneurs Windows sur GitHub.

Fonctionnement d’IIS dans un conteneur et dans une machine virtuelle

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

  • Stockage persistant pour les données locales : les dossiers où l’application écrit/lit des fichiers sont un bon exemple de quelque chose que vous conservez dans une machine virtuelle pour une instance IIS. Avec les conteneurs, vous ne voulez pas que des données soient écrites directement dans le conteneur. Les conteneurs utilisent un « espace de brouillon » pour le stockage local et, quand un nouveau conteneur est créé pour la même application, il n’a pas accès à cette zone provenant d’un conteneur précédent. Pour cette raison, vous devez utiliser un stockage persistant pour les données qui doivent être accessibles à l’application web, pour que les instances de conteneur puissent avoir accès à ce stockage.
  • Certificats : bien que vous puissiez avoir des certificats locaux sur des instances de conteneur, vous devez éviter de faire cela, 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 prendre en charge la gestion des certificats pour le site web hébergé derrière ces contrôleurs. L’avantage est que vous découplez la gestion du cycle de vie des certificats de la gestion du site web.
  • Chaînes de connexion de base de données : pour les déploiements IIS traditionnels, vous pouvez passer la chaîne de connexion de base de données dans le cadre du déploiement de votre application. Si les conteneurs Windows vous permettent de suivre ce modèle, vous pouvez néanmoins envisager de découpler la chaîne de connexion de base de données du conteneur et utiliser à la place une configuration centralisée fournie par l’orchestrateur de conteneurs, à partir de laquelle l’application peut lire. Ceci 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 (par exemple dans le cas d’une opération lift-and-shift vers le cloud), vous pouvez facilement changer la chaîne de connexion sans reconstruire votre image conteneur. Cette approche vous permet aussi de conserver les secrets (par exemple 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 : quand la charge augmente, les systèmes informatiques ont tendance à ralentir les performances perçues quand il y a des tentatives pour traiter des requêtes simultanées. Il existe en général deux façons d’éviter un impact sur les performances : une mise à l’échelle verticale ou une mise à l’échelle horizontale. La mise à l’échelle verticale augmente les ressources disponibles pour les instances 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 comme IIS, la mise à l’échelle horizontale tend à être plus efficace que la mise à l’échelle verticale, mais les environnements locaux peuvent rencontrer des limitations de ressources et des problèmes d’équilibrage de charge. Avec les environnements cloud, la mise à l’échelle horizontale est beaucoup plus facile, car les ressources sont facilement disponibles (moyennant un coût supplémentaire) et le fournisseur de cloud conçoit généralement son mécanisme d’équilibrage de charge avec la mise à l’é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 ne soient stockés 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 à n’importe quel moment dans un environnement Windows. Traditionnellement, vous avec une instance Windows opérationnelle à tout moment et, quand un déclencheur est activé, la tâche est exécutée. Ceci 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.

Cependant, avec une approche de microservices, vous avez quelques options pour éviter de conserver un conteneur en cours d’exécution dans l’attente d’un déclencheur :

  • Utilisez un service PaaS (Platform as a Service) piloté par les événements comme Azure Functions 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 quand un déclencheur est activé.
  • Utilisez des conteneurs Windows en conjonction avec un orchestrateur de conteneurs. Le conteneur peut s’exécuter seulement quand le déclencheur est activé et appelé depuis d’autres parties de l’application. Dans ce cas, l’orchestrateur de conteneurs gère la planification et le déclencheur pour 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 d’avant-plan (comme Service Monitor) pour conserver le conteneur en cours d’exécution.

Services d’arrière-plan

Bien que les conteneurs soient généralement destinés à des processus éphémères, vous pouvez conteneuriser une application d’arrière-plan qui s’exécute sur des durées longues à condition de créer un processus d’avant-plan pour le lancer et le maintenir en cours d’exécution.

Un bon exemple de cela est Service Monitor, 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 Service Monitor offre un modèle qui peut également être utilisé pour superviser d’autres services, avec certaines limitations.

Pour plus d’informations sur Service Monitor, 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 étendu que Nano Server, ce qui permet une plus grande compatibilité, mais a aussi comme conséquence une taille d’image plus grande. Nano Server a une surface d’API fortement réduite, mais une taille d’image beaucoup plus petite.

Dans certains cas, il peut être nécessaire de créer votre propre image .NET Framework ou .NET à partir des images conteneur de base Windows ou Server. Ceci peut être nécessaire si votre application a non seulement une dépendance vis-à-vis d’un framework mais aussi une dépendance vis-à-vis d’un 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, de façon à réduire la taille de l’image. Si votre application nécessite une autre police, 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, par exemple ne pas comporter d’interface utilisateur graphique) d’être conteneurisée. L’inconvénient est que leur taille sera beaucoup plus grande, ce qui peut affecter les performances.

Quand vous vérifiez si l’application à conteneuriser fonctionne sur des conteneurs Windows, Microsoft recommande ce qui suit :

Pour ce framework Testez d’abord avec cette image conteneur Passez à cette image conteneur si la première ne fonctionne pas Base image
.NET Framework versions 2.X et 3.X .NET Framework 4.x .NET Framework 3.5 Ordinateur Windows Server principal
.NET Framework versions 4.x .NET Framework 4.x Créez votre image conteneur .NET Framework avec des images Server ou Windows Ordinateur Windows Server principal
.NET 6 ou 7 .NET 6 ou 7, respectivement Créez votre image conteneur .NET avec des images de base Windows ou Server Windows Nano Server ou Server Core

Autres composants de prise en charge

Les composants et les sujets ci-dessous fournissent des conseils supplémentaires pour les éléments qui vont de pair avec les conteneurs Windows ou qui apportent un meilleur éclairage sur ceux-ci.

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 visualisé de manière structurée dans l’Observateur d’événements. Par opposition, Linux a fourni une approche fluidifiée avec la sortie standard (stdout) sur laquelle d’autres outils s’appuient, comme Docker.

Docker a toujours eu un mécanisme pour extraire les journaux des conteneurs Linux. En utilisant la commande « docker logs » avec une configuration de stdout par défaut, Docker extrait du conteneur les journaux d’application sans ouvrir le conteneur de façon interactive. Jusqu’au lancement de l’outil Log Monitor, la même technique ne fonctionnait cependant pas sur Windows.

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

  • Possibilité de filtrer les types d’événements/journaux que vous voulez exposer sur stdout. Par exemple, vous pouvez filtrer le journal d’application seulement sur les messages « erreur » et « avertissement » si vous n’êtes pas intéressé par les événements « informations ».
  • Possibilité de choisir parmi les journaux d’événements, les fichiers journaux personnalisés ou le suivi des événements pour Windows (ETW). Ceci est particulièrement utile si votre application écrit sur une autre source de journaux. Les journaux IIS qui se trouvent dans le dossier « C:\inetpub » en sont un exemple.
  • Le fait que Log Monitor permette aux conteneurs Windows de se comporter comme des conteneurs Linux, et donc des outils qui recherchent stdout et interagissent avec la fonction d’exécution des conteneurs comme attendu. 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 créés sur la même base que les instances Windows qui s’exécutent sur des machines physiques ou virtuelles. Une bonne compréhension des spécificités de la façon dont les conteneurs sont implémentés, 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 du conteneur effectue les ajustements nécessaires en fonction de la charge de travail de votre conteneur. Par exemple, si le conteneur fait une requête web, l’hôte du conteneur va transférer le trafic nécessaire à travers son pare-feu, afin que le conteneur puisse accéder au web.
  • Modes d’isolation. Comme déjà expliqué, les conteneurs Windows peuvent être déployés en mode d’isolation de processus ou en mode d’isolation Hyper-V, avec Hyper-V fournissant l’isolation la plus sécurisée. Dans l’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 (administrateur) avec élévation de privilèges d’interagir avec les processus et les services de conteneur. Le choix du mode d’isolation correct pour votre application est important pour garantir le modèle de sécurité approprié.
  • Mises à jour Windows. Comme la pile de maintenance n’est pas présente sur les conteneurs Windows, ils ne reçoivent pas les mises à jour comme les instances Windows générales. Au lieu de cela, vous devez recréer les conteneurs Windows en utilisant la dernière image 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. Ceci est pratique pour installer et configurer les composants nécessaires à l’intérieur de l’image conteneur. Cependant, vous devez envisager de changer le compte d’utilisateur en ContainerUser lors de l’exécution d’une application qui ne nécessite pas de privilèges élevés. Pour des scénarios spécifiques, vous pouvez aussi 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 dépôts et les instances des conteneurs soient sécurisés. Microsoft vous recommande d’utiliser Microsoft Defender pour les conteneurs pour l’analyse des images et l’analyse des runtimes. Defender pour les conteneurs prend en charge les conteneurs Windows pour l’évaluation des vulnérabilités avec l’analyse du registre et la protection des runtimes avec la détection des menaces.

Pour plus d’informations sur les sujets ci-dessus, consultez la page de documentation des conteneurs Windows.

Sauvegarde des conteneurs Windows

Quand vous utiliser des conteneurs, vous devez penser différemment la question des sauvegardes. Comme indiqué précédemment, un conteneur ne doit pas être utilisé pour stocker un état ou des données, en raison 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 se trouvent en dehors du runtime de l’instance de conteneur, qui peut être remplacée par un nouvelle, pour laquelle tous les stockages persistants nécessaires seront néanmoins toujours disponibles.

Il existe néanmoins cependant des composants dont vous êtes responsable de la sauvegarde, y compris l’application, l’image conteneur et le fichier dockerfile qui crée 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, considérez les cas les plus courants :

  • Application : votre application se trouve probablement dans un dépôt source, comme GitHub ou Azure DevOps. Ces dépôts 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 dépôt source, veillez à suivre ses recommandations pour la sauvegarde et la gestion.
  • Image conteneur : pour les environnements de production, votre image conteneur doit se trouver dans un dépôt d’images centralisé, comme Azure Container Registry (ACR). Vous pouvez envoyer (push) vos images conteneur à ACR pour les rendre disponibles et permettre à d’autres hôtes de les extraire. ACR gère la disponibilité des images conteneur et sert d’option de sauvegarde. Gardez cependant à l’esprit que si ACR gère la disponibilité de l’image, il n’empêche pas la suppression ou le remplacement d’une image. Pour tout autre dépôt d’images local, 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 fichier Dockerfile n’a peut-être pas été créé avec l’application, en particulier s’il s’agit d’une application existante en cours de conteneurisation, c’est votre responsabilité de vérifier que le fichier Dockerfile est stocké à un emplacement sécurisé et sauvegardé. Vous devez aussi vérifier que toutes les autres ressources nécessaires pour que votre application fonctionne dans un conteneur soient 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 la 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 : les images Windows Server Core, Nano Server, Windows ou Server.
  2. Déterminez le type du mode d’isolation pour le conteneur : choisissez entre les modes d’isolation de processus ou Hyper-V. Remarque : Actuellement, AKS et AKS sur Azure Stack HCI prennent en charge seulement les conteneurs isolés en mode de processus. Dans une version ultérieure, AKS et AKS sur Azure Stack HCI prendront en charge les conteneurs isolés en mode Hyper-V. Pour plus d’informations, consultez Modes d’isolation.
  3. Choisissez la version de Windows Server appropriée pour votre application pour assurer sa compatibilité. 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 conteneurs 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 conteneurs. Ceci inclut l’adaptation aux exigences spécifiques des conteneurs, comme l’analyse du registre et la détection des menaces.
  5. Considérez les besoins en matière d’équilibrage de charge. Les conteneurs eux-mêmes ne se déplacent pas : vous pouvez utiliser à la place un orchestrateur pour démarrer ou arrêter automatiquement des conteneurs sur des nœuds de cluster, ou pour gérer les modifications de la charge et de la disponibilité avec une mise à l’échelle horizontale automatique.
  6. Considérez les besoins en matière d’orchestration. Une fois conteneurisée, votre application a probablement besoin d’une gestion automatisée disponible avec des outils comme 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. Conteneurisez l’application.
  8. Envoyez (push) l’application à un dépôt d’images. Ceci va permettre aux hôtes de conteneurs de télécharger l’image dans n’importe quel environnement, y compris les environnements de développement, de test et de 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.