Docker: Contenedores Windows vs Linux
Llevo una temporada sin generar contenido…la verdad que un descanso, nunca viene mal para volver con más fuerza.
Desde que generé la última entrada sobre la instalación de Containers sobre Windows Server 2019, Microsoft ha evolucionado la integración con su sistema, así voy a intentar renovar la entrada, haciendo un pequeño resumen de como se instala, cómo trabajan los contenedores en Windows y la diferencia con los contenedores en un sistema Linux.
Me voy a basar en la documentación oficial, os dejo un par de enlaces interesantes:
- https://docs.microsoft.com/es-es/virtualization/windowscontainers/about/
- https://docs.microsoft.com/es-es/virtualization/windowscontainers/manage-containers/hyperv-container
- https://docs.microsoft.com/es-es/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server
Si queréis ver la anterior entrada, podréis comparar las diferencias:
El problema esencial de como se gestionaban los contenedores en Windows Server 2019, es que utilizaban Hyper-V para enmascarar la ejecución de los contenedores, siendo un handicap con respecto a los contenedores en Linux, que se integran directamente en el kernel de Linux.
Modo de ejecución contenedores Windows
Podemos ejecutar contenedores Windows de dos formas diferentes:
- Modo Aislamiento de Procesos (Isolation):
- Es el modo tradicional de ejecutar contenedores
- Los contenedores comparten el kernel del host en su ejecución, tal y como se hace en Linux
- Aunque es el modo tradicional, puede ser menos seguro, ya que se comparte el kernel tanto con el hosts, como con el resto de contenedores
- Modo Aislamiento bajo Hyper-V:
- Según Microsoft es el modo más seguro de ejecutar contenedores, ya que permite una mayor compatibilidad entre el host y el contenedor
- La ejecución se realiza mediante máquinas virtuales con su propio kernel
- También se proporciona aislamiento entre el hardware del host y cada contenedor
Aplicaciones que no trabajan en contenedores Windows
Un tema importante, a la hora de usar contenedores, es que no todas las aplicaciones pueden ser “contenerizadas” en Windows, os detallo algunos ejemplos:
- Actualmente, no se admiten contenedores Windows Microsoft DTC (Transacciones Distribuidas)
- Tampoco Office se puede usar con contenedores
- Aplicaciones cliente con interfaces de usuario visuales
- Y no podemos tampoco, crear contenedores Windows de roles típicos de Infraestructuras como DHCP, DNS, DC, NTP, Servidor de Impresión, de archivos o administrador de identidades.
Instalación Docker en Windows Server 2019
El resto de necesidades, las instalaremos mediante Powershell como Administrador. Primero instalamos el módulo con el siguiente comando:
1 |
Install-Module -Name DockerMsftProvider -Repository PSGallery -Force |
Pulsamos “S”:
Luego el paquete:
1 |
Install-Package -Name docker -ProviderName DockerMsftProvider |
Y reiniciamos el sistema para que los cambios sean activos. Y una vez reiniciado el sistema, comprobamos el estado:
1 2 |
Restart-Computer -Force Get-Package -Name Docker -ProviderName DockerMsftProvider |
Si el día de mañana queréis actualizar la versión usar el siguiente comando:
1 |
Install-Package -Name Docker -ProviderName DockerMsftProvider -Update -Force |
Lanzar contenedor en Windows Server 2019
Podéis lanzar un contenedor para realizar la prueba, de la misma forma que lo haríais en Linux:
1 |
docker run -it mcr.microsoft.com/windows/nanoserver:1903 cmd.exe |
Comprobar el aislamiento en contenedores Windows
Como hemos hablado, podemos ejecutar contenedores en Windows bajo Hyper-V o de forma tradicional sobre el propio kernel del host.
Ahora vamos a comprobar con un ejemplo, como se comporta un contenedor en Hyper-V y como lo hace en un modo tradicional.
Ejecución tradicional Docker
El anterior contenedor lo chequearemos, para saber el número de proceso:
1 2 3 |
docker top 5d8bf44026c8f63221a55e773bac1c60174bb6bab52ef427c6c8dbc8698f9d7a 3944 cmd |
El ID es el 3964. Si ahora revisamos los procesos en el host:
1 2 3 4 5 6 7 |
get-process -Name cmd Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id SI ProcessName ------- ------ ----- ----- ----- ------ -- -- ----------- 67 5 820 3836 ...71 0.03 3944 3 CMD |
Como veis tanto el proceso del contenedor como del host es el mismo….
Ejecución contenedores bajo Hyper-V
Ahora vamos a ejecutar bajo Hyper-V un contenedor:
1 |
docker run -d --isolation=hyperv mcr.microsoft.com/windows/servercore:ltsc2019 cmd localhost -t |
Hemos hecho una isolation bajo Hyper-V, y revisamos como antes el valor del proceso:
1 2 3 |
docker top 5d8bf44026c8f63221a55e773bac1c60174bb6bab52ef427c6c8dbc8698f9d7a 3944 cmd |
Ahora si vamos buscar al host el proceso, no lo vamos a encontrar:
1 2 3 |
get-process -Name cmd get-process : Cannot find a process with the name "cmd". Verify the process name and call the cmdlet again. At line:1 char:1 + get-process -Name cmd+ ~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (cmd:String) [Get-Process], ProcessCommandException + FullyQualifiedErrorId : NoProcessFoundForGivenName,Microsoft.PowerShell.Commands.GetProcessCommand |
Pero si encontraremos el proceso de la máquina virtual que contiene el contenedor:
1 2 3 4 5 6 7 |
get-process -Name vmwp Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id SI ProcessName ------- ------ ----- ----- ----- ------ -- -- ----------- 67 5 820 3836 ...71 0.03 3944 3 vmwp |
Diferencias contenedores Windows vs Linux
Como podéis apreciar, no existen grandes diferencias entre los contenedores Windows / Linux, cuando la isolación o aislamiento se hace con el propio host y no con Hyper-V.
Cambia el kernel entre un host a otro, y con ello el tipo de contenedor que puedes ejecutar.
Cosas a tener en cuenta:
- Un host Linux podrá ejecutar contenedores Linux, y un host Windows ejecuta contenedores Windows nativamente, pero tienes la posibilidad de ejecutar contenedores Linux mediante el aislamiento de Hyper-V (acordaros que no ejecuta el mismo kernel del host)
- A día de hoy, el desarrollo y diseño de contenedores, es mayoritariamente Linux, y aunque se pueden ejecutar contenedores .NET y de otros tipos, su uso no está tan extendido
- Ambas infraestructuras pueden implementarse vía On-Premise o Cloud
- El soporte en proveedores cloud está centrado en Linux y no Windows, aunque ya las grandes plataformas le dan soporte, aunque si vais a proveedores pequeños, podéis tener problemas
La brecha entre Windows y Linux cada día es inferior, esperemos que en un tiempo se reduzca del todo.
Te ha gustado la entrada SGUENOS EN TWITTER O INVITANOS A UN CAFE?
Gracias, es muy útil para mí.