Questions fréquentes sur les conteneurs

Linux et Windows Server implémentent tous deux des technologies similaires au sein de leurs noyau et système d’exploitation principal. La différence provient de la plateforme et des charges de travail qui s’exécutent dans les conteneurs.

Lorsqu'un client utilise des conteneurs Windows Server, ils peuvent être intégrés aux technologies Windows existantes, comme .NET, ASP.NET et PowerShell.

Les conteneurs ont été introduits sur la plateforme avec Windows Server 2016. Pour utiliser des conteneurs, vous devez disposer de Windows Server 2016, de la mise à jour anniversaire de Windows 10 (version 1607) ou plus récente, ou de Windows 10 IoT Enterprise ou plus récent. Pour plus d’informations, consultez Configuration requise.

La prise en charge des conteneurs Windows dépend de la plateforme Kubernetes sur laquelle il s’exécute. Azure Kubernetes Service (AKS) et AKS sur Azure Stack HCI et Windows Server prennent en charge les nœuds Windows Server 2019 et Windows Server 2022. Azure Kubernetes Service Edge Essentials prend en charge Windows Server 2019, Windows Server 2022 et Windows 10/11 Entreprise ou Professionnel. Pour la compatibilité des versions des conteneurs Windows, consultez Compatibilité des versions des conteneurs Windows.

Les nœuds Windows Server dans AKS et AKS sur Azure Stack HCI et Windows Server doivent être mis à niveau pour recevoir les mises à jour et les correctifs les plus récents. Les mises à jour Windows ne sont pas activées sur les nœuds Windows sur ces services. Toutefois, les deux services fournissent des mécanismes pour mettre à jour les images de nœud Windows.

Oui, gMSA est pris en charge avec les nœuds worker Windows joints à un domaine. Pour découvrir comment utiliser gMSA avec des conteneurs Windows, consultez Préparer les nœuds Windows pour gMSA.

WCOW est l’abréviation de « Windows Containers on Windows » (conteneurs Windows sur Windows). LCOW est l'abréviation de « Linux Containers on Windows » (conteneurs Linux sur Windows).

L’image de conteneur Windows CLUF décrit une utilisation reposant sur un utilisateur qui dispose d’un système d’exploitation hôte sous licence valide. Le nombre de conteneurs qu’un utilisateur est autorisé à exécuter dépend de l’édition du système d’exploitation hôte et du mode d'isolation avec lequel un conteneur est exécuté, ainsi que de l’exécution de ces conteneurs à des fins de développement/test ou de production.

L’utilisation des images de conteneur Windows Server est déterminée par la lecture du nombre d'invités de virtualisation pris en charge pour cette édition.

Non. Les images des conteneurs Windows sont communes aux conteneurs Windows Server et à l'isolation Hyper-V. Le choix du type de conteneur est effectué quand vous démarrez le conteneur. Du point de vue d’un développeur, les conteneurs Windows Server et l'isolation Hyper-V sont deux versions du même élément. Ils offrent la même expérience de développement, de programmation et de gestion, sont ouverts et extensibles, et présentent le même niveau d’intégration et de prise en charge avec Docker.

Un développeur peut créer une image de conteneur à l’aide d’un conteneur Windows Server et la déployer dans l'isolation Hyper-V ou inversement, sans modification autre que la spécification de l’indicateur d’exécution approprié.

Les conteneurs Windows Server fournissent une densité et des performances supérieures lorsque la vitesse est primordiale, notamment, une durée de rotation inférieure, des performances d’exécution plus rapides par rapport aux configurations imbriquées. Comme son nom l'indique, l'isolation Hyper-V offre une isolation supérieure en garantissant que le code s’exécutant dans un conteneur ne peut pas compromettre ni affecter le système d’exploitation hôte ni d’autres conteneurs exécutés sur le même hôte. Cela est utile pour les scénarios avec plusieurs clients (où l’hébergement de code non fiable est requis), y compris les applications SaaS et l’hébergement d’ordinateurs.

À partir de la mise à jour d'octobre 2018 de Windows 10, vous pouvez exécuter un conteneur Windows avec isolation de processus mais devez, dans un premier temps, demander l’isolation de processus à l’aide de l’indicateur --isolation=process lors de l’exécution de vos conteneurs avec docker run. L'isolation des processus est compatible avec Windows 10, 11 Professionnel (ou plus récent), Windows 10 Entreprise (ou plus récent), Windows 10 IoT Core et Windows 10 IoT Enterprise (ou plus récent).

Si vous souhaitez exécuter vos conteneurs Windows de cette manière, vous devez vous assurer que votre hôte exécute Windows 10 Build 17763+ et que vous disposez d’une version Docker dotée du moteur 18.09 ou plus récent.

Les images de base de conteneur Windows contiennent des artefacts dont la distribution est limitée par licence. Lorsque vous créez en utilisant ces images et les transmettez (push) à un registre public ou privé, vous pouvez constater que la couche de base n’est jamais envoyée. En effet, nous utilisons le concept de couche étrangère qui pointe vers la couche de base réelle résidant dans le stockage cloud Azure.

Cela peut compliquer la situation lorsque vous disposez d'une machine isolée capable uniquement d'extraire des images à partir de l'adresse de votre registre de conteneurs privé. Dans ce cas, les tentatives de suivi de la couche étrangère visant à récupérer l’image de base échoueront. Pour contourner le comportement de la couche étrangère, vous pouvez utiliser l’indicateur --allow-nondistributable-artifacts dans le démon Docker.

Commentaires supplémentaires

Vous souhaitez ajouter des éléments au Forum aux questions ? Ouvrez un nouveau problème dans la section des commentaires ou configurez une requête de tirage pour cette page avec GitHub.