Microsoft ofrece muchos modelos de contenedores diferentes en Windows. Si usa Windows 10, está ejecutando varios sin siquiera darse cuenta: encapsule y aísle todas sus aplicaciones para UWP; use máquinas virtuales livianas para brindar seguridad; y, si es desarrollador, instancias Docker de Windows o Linux.

Este modelo de contenedor en capas es clave para el futuro de Windows, un modelo que se extiende al próximo Windows 10X y al mundo más amplio de las nubes públicas y privadas, con contenedores de Windows Docker que ahora forman parte oficialmente de Kubernetes. Microsoft está trabajando en la minificación de Windows Server para producir imágenes base de contenedores livianos con Windows de mayor rendimiento.

Índice

¿Windows o Docker?

Si bien los contenedores de escritorio están destinados a simplificar y proteger sus aplicaciones de escritorio, proporcionando un aislamiento muy necesario para las aplicaciones instaladas a través de appx o MSIX (y en Windows 10X para todos los demás códigos Win32), los contenedores de Windows 10 se basan en el aislamiento de procesos de Windows. La tecnologia. No es el modelo familiar de Docker que encontramos en nuestras aplicaciones empresariales alojadas en la nube.

Eso no quiere decir que Windows 10 no pueda ejecutar contenedores Docker. Microsoft utiliza los servicios de Docker para respaldar sus contenedores de Windows Server. Puede compilar y probar el código que se ejecuta en PC con Windows, con versiones Pro o Enterprise, y la próxima versión 2004 de Windows 10 trae WSL2 y soporte para contenedores de Linux que se ejecutan en Windows.

Docker ha desarrollado una nueva versión de sus herramientas Docker Desktop para Windows en torno a WSL2, lo que facilita el desarrollo y la prueba de contenedores de Linux en Windows 10, ya que funciona con los propios contenedores de Windows. Con Microsoft posicionando a Windows como una plataforma de desarrollo para Kubernetes y otras plataformas en la nube, el soporte Docker de primera clase en las PC con Windows es esencial.

Contenedores de Windows en la nube híbrida

No se trata solo de contenedores de Linux en la nube. Los contenedores de Windows también tienen su lugar, alojando .NET y otras plataformas de Windows. En lugar de implementar SQL Server u otra aplicación de servidor de Windows en sus servicios en la nube, puede instalarlo en un contenedor e implementar rápidamente el código como parte de una implementación de CI/CD de DevOps. Modern DevOps trata la infraestructura (especialmente la infraestructura virtual) como el estado final de una compilación, por lo que tratar las aplicaciones de componentes en contenedores como uno de los muchos tipos de artefactos de compilación tiene mucho sentido.

Lo importante aquí no es la aplicación, sino cómo se organiza y administra. Ahí es donde entra Kubernetes, con el servicio OpenShift Kubernetes de RedHat. Las versiones recientes han agregado soporte para contenedores de Windows junto con Linux, administrando ambos desde el mismo controlador.

Aunque OpenShift y Kubernetes ahora admiten contenedores de Windows, en realidad no ejecutan contenedores de Windows en hosts de Linux. No hay ninguna razón práctica por la que no puedan usar una técnica similar a la que usa Docker para ejecutar contenedores de Linux en Windows. Sin embargo, los términos de licencia relativamente estrictos de Windows Server requieren una licencia de Windows para cada instancia de VM que aloje contenedores de Windows.

Creación de contenedores de Windows para Windows Server y Azure

El uso de contenedores de Windows en Kubernetes significa crear una infraestructura híbrida que combine hosts de Linux y Windows, con contenedores de Windows ejecutándose en nodos de trabajo con tecnología de Windows Server. El uso de herramientas como OpenShift o Azure Kubernetes Service automatiza la ubicación del código en estos trabajadores, administrando un clúster entre sistemas operativos para su aplicación. El código .NET se puede cargar en un contenedor de Windows Docker e implementar a través de Azure Container Registry. Puede administrar estos nodos desde el mismo controlador que sus nodos de Linux.

VER: Informática sin servidor: una guía para administradores de TI (Premium de TechRepublic)

No es necesario que aprenda nada nuevo si usa Linux para contenedores de Windows. Utiliza las herramientas familiares de Docker para crear y administrar las imágenes de su contenedor, y luego las mismas herramientas de Kubernetes que usaría para una aplicación de Linux pura. La combinación y combinación de microservicios de Windows y Linux en una sola aplicación le permite aprovechar las funciones específicas del sistema operativo y conservar la experiencia de los equipos de desarrolladores existentes, incluso al pasar de un entorno de aplicación monolítica tradicional a un sistema distribuido moderno.

Microsoft está creando un conjunto de herramientas de código abierto para ayudar a administrar los contenedores de Windows, con un repositorio de GitHub para el primero, una herramienta de registro. El registro mejorado tiene sentido para una aplicación distribuida, donde varios contenedores interactúan bajo el control de los operadores de Kubernetes.

Elegir aislamiento: ¿proceso o Hyper-V?

Además de Kubernetes, los contenedores de Windows en Windows Server tienen dos modos de aislamiento diferentes. El primero, el aislamiento de procesos, es similar al que usan los contenedores de Linux, que ejecutan varias imágenes en un sistema operativo host y usan el mismo kernel para todas las imágenes y el host. Los espacios de nombres mantienen los procesos aislados y administran los recursos de manera adecuada. Es un enfoque que se usa mejor cuando sabe qué procesos se están ejecutando en un servidor, lo que garantiza que no haya riesgo de fuga de información entre diferentes imágenes de contenedores. El pequeño riesgo de seguridad que conlleva un kernel compartido es la razón por la que Microsoft ofrece una alternativa más segura: contenedores aislados.

Bajo el capó de los contenedores aislados de Windows Server se encuentra, por supuesto, Hyper-V. Microsoft lo usa para mejorar el aislamiento del contenedor de Docker en Windows, usando una capa delgada de sistema operativo que se ejecuta en Hyper-V para alojar una imagen de contenedor de Docker, manteniendo el rendimiento y asegurando que los contenedores permanezcan completamente aislados. Aunque técnicamente cada contenedor es una máquina virtual con su propio kernel, están optimizados para ejecutar imágenes de contenedor. L'utilisation de la virtualisation de cette manière ajoute une couche d'isolation matérielle entre les images de conteneur, ce qui rend plus difficile la fuite d'informations entre elles et vous offre une plate-forme capable d'héberger plusieurs images de locataires pour vosotras.

Es bastante fácil crear y ejecutar un contenedor de Hyper-V. Todo lo que tiene que hacer es establecer el parámetro de aislamiento en la línea de comando de Docker en "hyperv", lo que iniciará el contenedor usando la virtualización para protegerlo. El valor predeterminado en los escritorios es usar Hyper-V, para los servidores es usar el aislamiento de Docker. Por lo tanto, es posible que prefiera forzar contenedores de Hyper-V en sus hosts de contenedores de Windows Server.

Microsoft ha trabajado duro para reducir el tamaño de la imagen del servidor Hyper-V que se usa para los contenedores de Windows. Pasó de casi 5 GB con Windows Server 1809 y 1903 a la mitad del tamaño a 2,46 GB en la próxima versión de 2004. ¡Y eso es Windows Server Core, no Nano! Confiar en Windows Server Core tiene sentido porque tiene más superficie de API, lo que reduce el riesgo de incompatibilidad de aplicaciones.

Con dos casos de uso para sus contenedores y cinco modelos de contenedores diferentes, parecería que la estrategia de contenedores de Microsoft es confusa. Pero no es el caso. Las tecnologías de aislamiento de aplicaciones propias de Windows son manejadas automáticamente por el instalador. Por lo tanto, solo necesita determinar si las aplicaciones de su servidor se ejecutan mediante el aislamiento de procesos o en Hyper-V. Y es mejor tomar la decisión si ejecuta sus aplicaciones en sus propios servidores en su propio centro de datos o en la nube pública.