Les conteneurs sont adorables, au cas où vous ne l'auriez pas entendu. Ils constituent un moyen agréable et propre d'obtenir un déploiement fiable et garanti, quel que soit le système hôte.
Si je veux exécuter mon application ASP.NET Core, je peux simplement taper "docker run -p 5000:80 shanselman/demos" sur la ligne de commande, et ça va démarrer ! Je n'ai aucune inquiétude quant au fait qu'il ne fonctionnera pas. Il fonctionnera, et fonctionnera bien.
Certains opposants aux conteneurs disent, bien sûr, nous pourrions faire la même chose avec les machines virtuelles, mais même aujourd'hui, un VHD (disque dur virtuel) est plutôt une chose indisciplinée et inclut une tonne de frais généraux qu'un conteneur n'a pas. Les conteneurs se produisent et vous devriez y prêter attention pour vos déploiements.
Historiquement sous Windows, cependant, les conteneurs Linux s'exécutaient dans une machine virtuelle Hyper-V. Cela peut être une bonne ou une mauvaise chose, selon vos objectifs. L'exécution de conteneurs à l'intérieur d'une machine virtuelle vous offre une isolation importante avec une surcharge. C'est bien pour les serveurs mais moins pour mon ordinateur portable. Docker pour Windows cache la plupart du temps la machine virtuelle, mais elle est là. Votre conteneur s'exécute dans une machine virtuelle Linux qui s'exécute dans Hyper-V sous Windows proprement dit.
Avec la dernière version de Windows 10 (ou 10 Server) et la version bêta de Docker pour Windows, il existe une prise en charge native du conteneur Linux sur Windows. Cela signifie qu'aucune machine virtuelle ou Hyper-V n'est impliquée (sauf si vous le souhaitez), donc les conteneurs Linux s'exécutent sur Windows lui-même en utilisant la prise en charge intégrée des conteneurs de Windows 10.
Pour l'instant, vous devez basculer les "modes" entre Hyper V et les conteneurs natifs, et vous ne pouvez pas (encore) exécuter les conteneurs Linux et Windows côte à côte. Le mot dans la rue est qu'il ne s'agit que d'un point dans le temps et que Docker prendra en charge à un moment donné l'exécution de conteneurs Linux et Windows en parallèle. C'est plutôt sympa car cela ouvre toutes sortes de scénarios hybrides sympas. Je pourrais exécuter un conteneur Windows Server avec une application .NET Framework ASP.NET qui communique avec un conteneur Linux exécutant Redis ou Postgres. Je pourrais ensuite les mettre tous dans Kubernetes dans Azure, par exemple.
Une fois que j'ai activé les conteneurs Linux sur Windows dans Docker, tout fonctionne et comporte une partie mobile de moins.
Je peux facilement et rapidement exécuter busybox ou le vrai Ubuntu (bien que Windows 10 supporte déjà Ubuntu nativement avec WSL) :
Il est même plus utile d'exécuter la ligne de commande Azure sans installation ! Juste "docker run -it microsoft/azure-cli" et il s'exécute dans un conteneur Linux.
Je peux même exécuter nyancat ! (Merci Thomas !)
docker run -it supertest2014/nyan
Spéculation - J'attends avec impatience le jour où je pourrai exécuter "minikube start --vm-driver="windows" (ou quelque chose) et configurer facilement un système de développement Kubernetes localement en utilisant la prise en charge native des conteneurs Linux de Windows plutôt que d'utiliser des machines virtuelles Hyper-V , si je le souhaite.
Parrain : Pourquoi manquer le contrôle de version de votre base de données ? C'est plus facile que vous ne le pensez car SQL Source Control connecte votre base de données aux mêmes outils de contrôle de version que vous utilisez pour les applications. Trouver comment.