Cuando hablo con ingenieros de Linux y les cuento sobre los problemas del clúster de Kubernetes en Windows, me miran con mucha sospecha. Algunos ni siquiera creen que
esto sea legítimo . Los contenedores en Windows no son tan comunes y solicitados como en Linux. Pero creo que vale la pena hablar sobre este tema, aunque solo sea para comprender el concepto general y las principales diferencias entre los contenedores de Windows y Linux. La primera entrada repasaré el lienzo con un pincel ancho, y luego, en publicaciones posteriores, intentaré profundizar gradualmente en los matices.
Contenedores de Windows
De acuerdo con
este artículo:Muchos desarrolladores de .NET o SQL Server se mordieron los codos y envidiaron a sus compañeros de Linux.
De hecho, los contenedores en Windows eran exóticos hasta hace poco. Y la peor parte es que la documentación tenía que recopilarse en migajas, en cada recurso, ya fuera el sitio web oficial de Docker o Microsoft, todo se presentaba en forma general sin una descripción de "cómo y por qué", y después de un mes o dos la información existente se volvió obsoleta. Y no hay nada sobrenatural en esto: los contenedores y las tecnologías asociadas con ellos se están desarrollando a una velocidad poco realista.
Por el momento, todo es mejor con la documentación y para sumergirse en el mundo de los contenedores para Windows, solo lea la
documentación oficial de Microsoft y monitoree sus cambios. Curiosamente, la documentación está bien escrita y en ruso, aunque con un estudio profundo no puede evitar hacer clic en enlaces a varios recursos como
https://www.docker.com/ o
https://kubernetes.io/ donde todo está escrito en el antiguo buen ingles
Ahora las respuestas a cualquier pregunta se pueden encontrar en la documentación oficial, pero hay algunos matices que son más conocidos de antemano. Quizás esto le sea útil y ahorre tiempo cuando esté inmerso en la tecnología de contenedores bajo la bandera de Microsoft.
No puede ejecutar contenedores de Windows en Linux y en Windows *
La tecnología de contenedores facilita el manejo del entorno gracias a las imágenes de aplicaciones reconfiguradas. Es como una Apple Appstore o Google Play, pero solo para ingenieros y desarrolladores. Al igual que en las tiendas de aplicaciones móviles, no puede colocar la aplicación de Google Play en iOS. Entonces, en el host Docker con el sistema operativo Linux, no puede iniciar el contenedor con el sistema operativo Windows. Lo contrario también es cierto, aunque con algunos "peros", ya que el host Docker con Windows todavía puede proporcionar a Linux un entorno para ejecutar contenedores.
Además, no puede iniciar un contenedor de Windows en un entorno de Windows sin asegurarse de que las versiones del sistema operativo sean compatibles. Cuando trabaje con contenedores de Microsoft, deberá consultar la
Compatibilidad de la versión del contenedor de Windows y abrir periódicamente este documento.
Hablando de versiones: Microsoft con la llegada de los contenedores decidió lanzar nuevas versiones semestrales de Windows semestral. Estas son versiones como Windows Server 1703, 1709, 1803, 1809, 1903. Los números indican el año y el mes de lanzamiento, y son compatibles durante 18 meses. Los dos primeros ya están en paz y están al final del servicio. Además, hay versiones LTS como Windows Server 2016 y Windows Server 2019.
Lista de versiones.Entonces, si recolectó el contenedor en un host con una versión de Windows 1803, entonces solo puede ejecutar este contenedor en hosts con Windows 1803. En consecuencia, para no reconstruir el contenedor en sí cada vez, tendrá que usar la versión LTS de Windows, que con velocidades de desarrollo de tecnología moderna No siempre justificado. O, sin embargo, piense en el control de versiones y todavía reensamble constantemente los contenedores siguiendo el programa paso a paso para el semestre.
La última etiqueta en Dokerfile para contenedores de Windows no siempre está presente y, en general, está en
desuso . En el buen sentido, siempre necesita saber cuál es su versión de Windows y hacer los cambios apropiados en el Dockerfile.
Los contenedores son parte del enfoque de Infraestructura como Código. Es necesario volver a armar los contenedores constantemente, no solo es simple y divertido, sino que esta es la magia principal, que permite que las aplicaciones trabajen siempre en software nuevo y mejorado. Pero en nuestro caso, nos enfrentamos a una limitación: no funcionará mantener un Dockerfile universal para todos los sistemas Windows. Esto debe tenerse en cuenta.
Todo lo anterior es cierto para los contenedores que se ejecutan en modo de aislamiento de proceso. En el modo de aislamiento de Hyper-V, se aplica la compatibilidad con versiones anteriores: puede ejecutar todos los contenedores creados en las versiones actual y anterior. En general, con el aislamiento de Hyper-V, también puede ejecutar contenedores de Linux en un host de Windows. Pero este modo hasta ahora admite menos golosinas, que es solo la falta de Kubernetes.
La diferencia entre el aislamiento del proceso y el aislamiento de Hyper-V es el tema de un artículo separado. Por ahora, solo diré que los escenarios con aislamiento de Hyper-V no son completamente obvios para mí y, de manera predeterminada, Windows usa el aislamiento de procesos.
Otro dolor de cabeza es encontrar la versión correcta de las imágenes en Docker Hub. Generalmente faltan algunas imágenes para Windows. Por ejemplo, no encontrará la compilación oficial de Nginx, MySQL, Nodejs, así como cientos de otras aplicaciones para Windows y tendrá que recopilar contenedores usted mismo o utilizar contenedores recopilados y proporcionados por miembros de la comunidad.
Windows cuesta dinero.No olvides que Windows sigue siendo una cosa paga. Por ejemplo, las versiones semestrales están disponibles a través de la suscripción de Visual Studio o con Software Assurance en el acuerdo de licencia existente de Microsoft.
EnlacePero Microsoft tiene una gran cantidad de formas de recibir pagos gratis. Este es el programa BizSpark y todo tipo de versiones de prueba de Windows Server 2019 durante 180 días y así sucesivamente.
Los contenedores de Windows no son livianos.En general, se acepta que los contenedores son livianos, pero que la verdad para Linux no siempre es cierta para Windows. La gran mayoría de los contenedores de Windows, a primera vista, pesan mucho. Y a segunda vista, la impresión no cambia. Por ejemplo, un aspnet básico: la imagen 4.8 pesa aproximadamente 7.5 GB.
Incluso si aloja las imágenes base en un repositorio local, la carga inicial de la imagen en el host llevará bastante tiempo, y mucho menos repositorios remotos como Docker Hub.
Sí, puede usar el ligero Windows Nano Server en algunos escenarios, pero, por desgracia, tiene muchas limitaciones. Y aún más, no está en camino con Windows Nano Server si está desarrollando para .Net Framework.
Para administrar, debe conocer bien CMD y Powershell.Lo más probable es que tenga que trabajar con la versión principal de Windows Server en los hosts Docker. Windows Server tiene una gran cantidad de capacidades de administración remota. El enfoque general es que al tener un servidor de Windows con una interfaz gráfica, puede conectar todos los complementos gráficos a cualquier servidor central.
Este enfoque no funciona en escenarios de contenedor, aunque el contenedor contiene una versión completa de Windows Server. Dentro de un contenedor de Windows, es teóricamente posible conectarse a través de WMI, pero esto no es tan simple, solo porque el sistema operativo host interceptará este tráfico por sí mismo. Puede haber varias decenas y cientos de contenedores en un host, y en este caso, dirigir el tráfico al contenedor correcto es una cosa completa.
Se necesitarán CMD y Powershell tanto para la administración de contenedores como para el host en el que está instalado Docker. Además, el conocimiento de estos shells es necesario para escribir un Dockerfile, ya que todas las instrucciones RUN se ejecutarán en los shells mencionados anteriormente.
Recordar todos los cmdlets largos de Powershell es bastante complicado. Estos no son comandos bash concisos para ti. Aunque ahora la mayoría de los cmdlets tienen alias claros para cualquier ingeniero de Linux. En powershell, puedes usar:
rm Remove-Item pwd Get-Location. cat Get-Content touch New-Item etc. # Linux . rm –rf . # Powershell man Get-Help <>
De las cosas extremadamente útiles, esto es que usando Powershell puede ejecutar un
servidor web simple en un contenedor con fines de prueba. En Powershell, todo aparece como objetos. Si es un defensor de la OOP, apreciará rápidamente los beneficios de este shell.
Como conclusión del artículo introductorio, quiero decir que deliberadamente no abordé el tema de la orquestación y la gestión de clústeres. Docker en Windows se está poniendo al día y las aplicaciones de orquestación como Swarm y Kubernetes en Windows no se dan cuenta plenamente de su funcionalidad.
También en este momento, si desea elevar el clúster Docker, lo más probable es que sea multiplataforma. Es decir, tendrá que tener uno o más hosts Linux en el clúster. Por ejemplo, para Kubernetes, los nodos maestros deben estar en Linux. Y en Swarm, se necesitan contenedores de Linux, por ejemplo, para implementar un equilibrador en Nginx o ejecutar otras aplicaciones de clúster populares que solo están disponibles para Linux.
PS El uso de Windows en contenedores tiene un conjunto muy limitado de scripts para usar. Sin embargo, estos escenarios pueden ser extremadamente productivos. Por supuesto, lo primero que viene a la mente son las aplicaciones web IIS, pero mi experiencia muestra que los servicios autónomos de Windows y algunos servicios como MSMQ están bien aislados en contenedores.
UPD Hay una pequeña imprecisión en el artículo; puede construir un clúster Docker solo en hosts de Windows. Además, esto no es solo Swarm, sino también un producto desarrollado por Micrisoft para orquestar el clúster de Service Fabric
UPD2. Los contenedores Docker para Windows 10 solo están disponibles en modo de aislamiento Hyper-V y usan imágenes básicas que no sean Windows Server.