Conteneurs dans Windows Server 2016: ce que vous devez savoir

Dans un article que j'ai écrit pour Computerworld en janvier, qui était un examen de Windows Server 2016 Technical Preview 4, j'ai mentionné la nouvelle prise en charge de Windows Server pour les conteneurs Hyper-V qui avait été ajoutée à sa prise en charge des conteneurs de style Docker (présents dans la version bêta produit depuis la version bêta précédente).

Cependant, la présence de deux options de conteneurs a conduit à de nombreuses questions. Quelle est la différence entre un conteneur Docker et un nouveau conteneur Hyper-V? Dans quels scénarios souhaiteriez-vous utiliser une solution de conteneur plutôt qu'une autre? Existe-t-il des méthodes distinctes pour déployer chacun de ces éléments?

Microsoft n'a pas fait un excellent travail de documentation de ces deux options de conteneur, et les conteneurs eux-mêmes sont nouveaux sur la plate-forme Windows Server. Compte tenu de ces deux facteurs, je souhaite dédier toute une histoire aux solutions de conteneurs spécifiques que Windows Server 2016 fournit maintenant sous forme d'aperçu dans les versions disponibles, ou promet de fournir avant la date de sortie du logiciel à la fabrication (RTM), très probablement en la seconde moitié de 2016.

Aperçu

Il existe actuellement deux types de conteneurs dans Windows Server 2016: les conteneurs Windows Server et les conteneurs Hyper-V. Les deux prennent uniquement en charge Windows Server; ni l'un ni l'autre ne peut mélanger Linux et / ou Unix, par exemple.

Pour les administrateurs paresseux comme moi, laissons la question importante de côté: l'un des deux types de conteneurs est-il plus difficile à déployer que l'autre? La réponse est un non insistant.

[Lectures complémentaires: premier regard: exécuter des machines virtuelles dans des machines virtuelles avec des conteneurs Hyper-V]

Les types de conteneurs s'exécutent différemment et ont différents niveaux d'isolation et de confiance dans l'hyperviseur. Mais à la base, il s'agit d'une décision de déploiement prise par le propriétaire de la machine physique - le propriétaire de l'hôte - sur le type de conteneur qui sera utilisé, et c'est aussi simple que de vérifier le bon bouton radio dans un assistant. . Vous choisissez simplement entre les deux au moment de la création. La décision affecte la façon dont Windows Server 2016 - le système d'exploitation lui-même (l'hyperviseur, assis au bas de tout cela, fonctionnant sur le silicium et le fer physique) - isole et exécute les charges de travail dans chaque conteneur.

Alors maintenant que vous savez que l'une ou l'autre des options de conteneur représente la même quantité de travail pour vous, comment décidez-vous intelligemment entre les deux? Essentiellement, cela se résume à la confiance: si vous faites confiance au code exécuté dans le conteneur, vous choisirez un conteneur Windows Server (lire: traditionnel, de style Docker). Si vous ne faites pas confiance au code, ou ne pouvez pas le vérifier, ou s'il ne provient pas de vos développeurs internes au sein de votre propre organisation, un conteneur Hyper-V est la solution. Regardons chaque option en détail.

Conteneurs Windows Server

Les conteneurs Windows Server ne sont en fait qu'une partie du projet de conteneur open source Docker, donc si vous pensez à un conteneur de style Docker, vous penserez à un conteneur Windows Server. Ces conteneurs sont essentiellement un nouveau type de machine virtuelle qui, à certains égards, est moins isolée qu'une machine virtuelle traditionnelle, notamment parce que, dans de nombreux cas, les éléments communs à tous les conteneurs exécutés sur un hôte sont partagés. Parmi ces éléments partagés figurent les fichiers du système d'exploitation, les répertoires et les services en cours d'exécution. Ceci est fait pour une plus grande efficacité, car si vous exécutez trois conteneurs différents sur un hôte, tous avec la même version de Windows Server que les invités, vous n'avez besoin que d'une seule copie du répertoire C: \ Windows à tout moment.

Ce partage sépare toujours les conteneurs de toute application donnée qui pourrait s'exécuter sur un hôte, mais il réduit également les frais généraux et rend les conteneurs plus légers. Vous avez plus de marge par serveur exécutant des conteneurs grâce à ce partage, par opposition à l'exécution de machines virtuelles traditionnelles, qui sont plus isolées et ne partagent rien - et ont donc tendance à avoir beaucoup plus de duplication. Vous utiliserez également généralement des conteneurs Windows Server lorsque votre hôte et votre invité exécutent tous le même système d'exploitation afin de profiter de ce partage; par conséquent, vous ne pouvez pas exécuter un conteneur avec Ubuntu Server s'exécutant sur un hôte Windows Server 2016. (Pour ce type de charge de travail, vous utiliseriez des machines virtuelles traditionnelles. Les conteneurs ne seraient pas appropriés pour cela. Vous utiliseriez simplement des machines virtuelles, qui sont prises en charge par Windows depuis 2008.)

Pour ce que cela vaut, à l'heure actuelle, les deux systèmes d'exploitation d'image de conteneur pris en charge par les conteneurs Windows Server sont Server Core (Windows sans son interface utilisateur graphique) et Windows Nano Server, le microserveur radicalement refactoré adapté aux petits rôles orientés microservices. (Plus d'informations sur les microservices dans un peu.)

Alors, comment Docker s'intègre-t-il dans tout cela? Docker fournit une «couche de gestion», si vous voulez, d'API et de moteurs pour gérer les conteneurs - une couche qui est rapidement devenue une norme de l'industrie, probablement parce que Docker lui-même est open source et largement utilisé. Le Docker Hub, disponible pour toute personne sur Internet, est un véritable référentiel d'applications de style marketplace qui s'exécutent toutes dans des conteneurs de style Docker.

Docker fournit également un cadre mental que les développeurs peuvent utiliser pour se rapprocher du fonctionnement réel de leur code et pour créer des conteneurs entiers des environnements dont leur code a besoin pour s'exécuter. Les développeurs créent essentiellement des images de conteneurs, qui sont ensuite envoyées aux opérations assez facilement, et s'exécutent essentiellement telles qu'elles sont en tant qu'invités sur cet hôte. Les mises à jour et les correctifs de code peuvent être traités rapidement et facilement de la même manière.

Chacune de ces images de conteneur peut même fonctionner sur une très petite partie de l'application globale, ce qui compose la solution et facilite le travail dans un environnement orienté microservices. Dans une perspective globale, travailler avec des conteneurs augmente la responsabilité des développeurs d'écrire un bon code qui fonctionne exactement dans leur environnement. Les développeurs ne peuvent plus écrire du code qui fonctionne parfaitement sur leurs machines de développement, mais tombe lorsqu'il est déployé sur un logiciel de production - puisqu'ils sont identiques, le code doit fonctionner dans les deux endroits. Cela réduit également les frictions entre les opérations et l'IT - IT avec ses environnements de serveurs immaculés et les développeurs qui s'attendent à certaines configurations mais n'ont souvent pas la capacité ou la justification de modifier les environnements de production pour répondre à leurs attentes.

Ces conteneurs Windows Server de style Docker impliquent une certaine confiance - soit que vous avez téléchargé une application approuvée à partir de Docker Hub, soit que vos développeurs internes ou sous-traitants vous ont fourni un conteneur exécutant du code en lequel vous avez confiance. Pour les applications dans des conteneurs contenant du code de confiance, les conteneurs Windows Server sont recommandés et appropriés. Le partage et la projection des fichiers du système d'exploitation ne doivent pas être un problème pour le code de confiance.

Mais que se passe-t-il lorsqu'il y a un besoin d'un peu plus de sécurité, d'un peu plus d'isolement, avec un code ou des applications moins fiables?

Conteneurs Hyper-V

C'est à ce moment que vous commencez à regarder les conteneurs Hyper-V, qui marient le modèle d'isolation et d'abstraction des machines virtuelles traditionnelles avec la flexibilité, l'image et les formats de redéploiement faciles des conteneurs Windows Server de style Docker, ainsi que l'API Docker et les outils de gestion qui J'ai discuté dans la section précédente.

Mark Russinovich, CTO pour Microsoft Azure, l'a exprimé ainsi dans une entrée de blog l'année dernière: les conteneurs Hyper-V «isolent les applications avec les garanties associées à la virtualisation traditionnelle, mais avec la facilité, le format d'image et le modèle de gestion des conteneurs Windows Server, y compris le support de Docker Engine. " La différence ici est le niveau d'isolement: les conteneurs Hyper-V ne partagent pas directement les fichiers, processus et services du système d'exploitation avec l'hôte. Au lieu de cela, Windows Server encapsule chaque petite image de conteneur dans une machine virtuelle à très faible coût, ce qui atteint la limite d'abstraction et de confiance qu'un conteneur Windows Server de style Docker ne fait pas.

Cependant, cette machine virtuelle est, à toutes fins utiles, transparente pour l'administrateur. Les images de conteneur elles-mêmes qui exécutent Windows Server comprennent qu'elles sont, en fait, des images de conteneur et qu'elles ne s'exécutent pas sur du silicium normal sans entraves, et peuvent donc tirer parti des optimisations du système d'exploitation qui découlent de cette prise de conscience. Mais même si ces images de conteneur sont plus isolées, elles ne sont pas déployées différemment des conteneurs Windows Server. Vous utilisez toujours les API Docker. Vous utilisez toujours le client Docker. Vous cochez simplement une case différente, mais les images de conteneur elles-mêmes sont créées et livrées de la même manière, quel que soit le modèle d'isolation que vous souhaitez utiliser pour les exécuter.

L'inconvénient de cette approche: il y a plus de frais généraux. En raison de l'isolation supplémentaire, davantage de code et de processus sont dupliqués. Il y a aussi le fait que, même si le wrapper de machine virtuelle léger pour un conteneur Hyper-V est petit, il ajoute en effet une «taxe» au coût d'exécution d'une image de conteneur. Ainsi, bien que vous puissiez remplir un hôte puissant de conteneurs Windows Server de style Docker, les conteneurs Hyper-V seraient limités à un certain nombre de conteneurs plus petit, tout le reste étant égal sur le plan matériel.

Encore une fois, ces images de conteneur prendraient uniquement en charge Windows Server. Même s'il y a isolation, il existe toujours des points communs entre les images de conteneur et le système d'exploitation hôte. Donc, si vos images de conteneur exécutent Linux, une autre version d'Unix, BSD ou tout autre système d'exploitation alternatif, aucune de ces nouvelles fonctionnalités de Windows Server 2016 n'aura d'importance pour vous.

L'essentiel: le code tiers, le code du marché ou le code qui, autrement, n'est pas totalement approuvé par une partie de votre organisation doit être exécuté dans des conteneurs Hyper-V. Il s'agit également du meilleur choix pour les clouds publics mutualisés et d'autres environnements similaires. Vous ne perdez rien d'autre que de la capacité et vous bénéficiez des avantages de sécurité d'être plus isolés.

Conteneurs Docker

Maintenant, pour prouver que l'image de marque est toujours la partie la plus difficile de toute technologie, permettez-moi de vous présenter les conteneurs Docker. Ci-dessus, j'ai mentionné que les conteneurs Windows Server font partie du projet open source Docker. Les conteneurs Docker sont distincts des conteneurs Windows Server. Les conteneurs Windows Server peuvent utiliser toute la technologie sous-jacente Docker, mais l'ensemble d'outils Docker existant pour la gestion des conteneurs Docker ne fonctionne pas (du moins dans cette version) avec les conteneurs Windows Server. Les outils de gestion de conteneurs Windows Server - à ce stade, un ensemble de commandes PowerShell - ne peuvent pas non plus faire quoi que ce soit de valeur avec les conteneurs Docker eux-mêmes.

Les conteneurs Docker sont leur propre spécificité, et bien que les conteneurs Windows Server agissent comme des conteneurs Docker dans leur capacité à partager mais à isoler - c'est pourquoi je les ai appelés conteneurs Windows Server de style Docker - ils ne sont pas des conteneurs Docker en soi . Cela peut changer à l'avenir, en particulier dans un Service Pack ou la prochaine version de Windows Server, mais pour l'instant, ces trois types de conteneurs, même s'ils peuvent tous être similaires, restent des concepts distincts. Seuls deux sont actuellement pris en charge par Windows Server.

Où se trouve la technologie aujourd'hui

À l'heure actuelle, la prise en charge des conteneurs dans Windows Server 2016 est un travail en cours. Il existe de nombreuses pièces mobiles vers les conteneurs: suppression des dépendances sur les fichiers hôte et système d'exploitation, ainsi que sur des versions et des niveaux de correctifs spécifiques; réaliser le bon isolement et garantir qu'aucun code ne peut enfreindre cette limite de sécurité et de confiance; rendre l'histoire du développeur juste avec des outils et l'automatisation qui permettent aux développeurs de travailler avec des conteneurs dans leur environnement de développement intégré (IDE) préféré et «d'exporter» leurs applications directement vers le conteneur; s'assurer que les conteneurs peuvent monter et descendre dans le cloud public de manière transparente et plus.

Dans tous ces cas, il reste des erreurs fatales et des bogues à résoudre. Si les conteneurs sont cruciaux pour votre feuille de route des offres de services au sein de votre boutique, vous souhaiterez peut-être commencer à tester les capacités des conteneurs Windows Server et Hyper-V dès maintenant, et en particulier consulter les commandes PowerShell disponibles pour activer les conteneurs et les gérer. sur un hôte Windows Server 2016.

Cependant, si les conteneurs sont une bonne option mais pas un must pour votre organisation, alors ma recommandation éclairée serait de ne pas tenter autre chose que l'exploration la plus rudimentaire à l'aide de l'Aperçu technique 4 bits. Il y a encore trop de verrues - y compris les erreurs fatales et les bogues mentionnés précédemment - pour vraiment avoir une idée cohérente de ce qui se passe.

La prise en charge des conteneurs sera un ajout intéressant à la plate-forme Windows. Il reste beaucoup de cette histoire à écrire et à raconter.

Cette histoire, «Conteneurs dans Windows Server 2016: ce que vous devez savoir» a été publiée à l'origine par Computerworld.