Uso de contenedores de Windows para "incluir aplicaciones existentes en contenedores"

  • Artículo

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Los contenedores de Windows proporcionan un gran mecanismo para modernizar las aplicaciones tradicionales o heredadas. Aunque es posible que escuche referirse a este enfoque como "lift-and-shift a contenedores", la metáfora lift-and-shift tiene su origen en el traslado de cargas de trabajo de máquinas físicas a máquinas virtuales y se ha usado últimamente al hacer referencia a las cargas de trabajo móviles como es a la nube (ya sea privada o pública). En la actualidad, este término se aplica de forma más adecuada a la migración de máquinas virtuales (VM). Sin embargo, los contenedores no son máquinas virtuales y considerarlas como tales puede generar confusión sobre la manera de incluir una aplicación en contenedores, o incluso sobre si se puede o debe llevar a cabo esta acción.

Este tema ofrece instrucciones prácticas sobre cómo trasladar aplicaciones tradicionales a contenedores de Windows. Está dirigido a ayudarle a priorizar qué aplicaciones deben incluirse en contenedores, ya que explica consideraciones especiales por adelantado.

Introducción

Qué son los contenedores de Windows y qué no son

El término genérico contenedor hace referencia a una tecnología que virtualiza el sistema operativo (SO). Esta virtualización proporciona un nivel de aislamiento del sistema operativo del propio servidor o host, lo que, a su vez, permite una mayor agilidad para los desarrolladores de aplicaciones y los equipos de operaciones.

Los contenedores de Windows son una implementación específica de la tecnología de contenedores. Proporcionan instancias de sistemas operativos virtualizados que están aislados del sistema operativo Windows. Pero la interdependencia total entre el contenedor y el host es imposible: un contenedor de Windows debe coordinar la demanda de recursos y funciones con el sistema operativo Windows. ¿Por qué esto es importante? Dado que un contenedor de Windows no es un servidor virtualizado completo y algunas de las cosas que puede querer hacer con una aplicación no se pueden hacer solo con un sistema operativo virtualizado.

Puede leer más sobre este tema en Contenedores frente a máquinas virtuales. Pero algunos puntos importantes que le ayudarán a recordar la distinción entre el contenedor y la máquina virtual son:

  • Los contenedores no son una solución equivalente a la virtualización de aplicaciones de escritorio. Solo admiten aplicaciones del lado del servidor que no requieren una sesión interactiva. Dado que se ejecutan en imágenes de contenedor especializadas, solo admiten aquellas aplicaciones que no necesitan un front-end gráfico.
  • Los contenedores son efímeros por naturaleza. Esto significa que, de manera predeterminada, no hay ningún mecanismo para guardar el estado de una instancia de contenedor. Si se produce un error en una instancia, habrá otra instancia en su lugar.

La tecnología de contenedor comenzó en Linux, y Docker emergió como el estándar. Microsoft ha trabajado en estrecha colaboración con Docker para asegurarse de que la funcionalidad del contenedor sea lo más similar posible en Windows. Las diferencias inherentes entre Linux y Windows pueden aparecer de maneras que parecen ser limitaciones de los contenedores de Windows cuando, de hecho, son solo las diferencias de Linux frente a Windows. Por otro lado, los contenedores de Windows proporcionan algunas implementaciones únicas, como el aislamiento de Hyper-V, que se tratará más adelante. Este tema le ayudará a comprender esas diferencias y a adaptarlas.

Ventajas del uso de contenedores

Al igual que la ejecución de varias máquinas virtuales en un solo host físico, se pueden ejecutar varios contenedores en un solo host físico o virtual. Pero, a diferencia de las máquinas virtuales, no es necesario administrar el sistema operativo de un contenedor, lo que le ofrece la flexibilidad de centrarse en el desarrollo de aplicaciones y la infraestructura subyacente. También significa que puede aislar una aplicación para que no se vea afectada por ningún otro proceso compatible con el sistema operativo.

Los contenedores proporcionan un método ligero para crear y detener dinámicamente los recursos necesarios para una aplicación en funcionamiento. Aunque es posible crear e implementar máquinas virtuales a medida que aumenta la demanda de la aplicación, es más rápido usar contenedores para el escalado horizontal. Con los contenedores, también puede reiniciarse rápidamente en caso de bloqueo o interrupción del hardware. Los contenedores le permiten llevar cualquier aplicación del desarrollo a la producción con poco o ningún cambio de código, ya que "contienen" dependencias de aplicación para que funcionen en entornos. La capacidad de incluir en contenedores una aplicación existente con cambios mínimos en el código, debido a la integración de Docker en las herramientas de desarrollo de Microsoft, también es un factor eficaz en el desarrollo y el mantenimiento de aplicaciones.

Por último, una de las ventajas más importantes de usar contenedores es la agilidad que obtiene para el desarrollo de aplicaciones, ya que puede tener versiones diferentes de una aplicación que se ejecuta en el mismo host sin conflictos de recursos.

Puede encontrar una lista mucho más completa de las ventajas de usar contenedores para aplicaciones existentes en la página de documentación de Microsoft de .NET.

Concepto importante del nivel de aislamiento

Los contenedores de Windows proporcionan aislamiento del sistema operativo Windows, aislamiento que es ventajoso cuando se compila, prueba y promueve una aplicación a producción. Pero es importante comprender la forma en que se logra el aislamiento cuando se está pensando en incluir una aplicación en contenedores.

Los contenedores de Windows ofrecen dos modos distintos de aislamiento en tiempo de ejecución: proceso e Hyper-V. Los contenedores en ambos modos se crean, administran y funcionan de forma idéntica. Entonces, ¿cuáles son las diferencias y por qué debería tenerlas en cuenta? En el aislamiento de procesos, varios contenedores pueden ejecutarse simultáneamente en un único host con aislamiento proporcionado a través de espacio de nombres, control de recursos y otras características. Los contenedores en modo de aislamiento de procesos comparten el mismo kernel con el host y también entre sí. Esto equivale aproximadamente al modo en que se ejecutan los contenedores de Linux.

En el aislamiento de Hyper-V, varios contenedores también se ejecutan simultáneamente en un único host, pero se ejecutan dentro de máquinas virtuales altamente optimizadas, con cada uno de ellos obteniendo eficazmente su propio kernel. La presencia de esta máquina virtual, en realidad una VM de "utilidad", proporciona aislamiento de nivel de hardware entre cada contenedor y el host de contenedor.

De alguna manera, el modo de aislamiento de Hyper-V es casi como un híbrido de una máquina virtual y un contenedor, lo que proporciona una capa adicional de seguridad especialmente útil si la aplicación necesita varios inquilinos. Pero las posibles ventajas del uso del modo de aislamiento de Hyper-V incluyen:

  • Tiempo de inicio más largo para el contenedor y un impacto probable en el rendimiento general de la aplicación.
  • No todas las herramientas funcionan de forma nativa con aislamiento de Hyper-V.
  • Ni Azure Kubernetes Service (AKS) ni AKS en Azure Stack HCI admiten el aislamiento de Hyper-V en este momento.

Puede obtener más información sobre cómo se implementan los dos modos de aislamiento en el tema Modos de aislamiento. Al incluir una aplicación en contenedores por primera vez, deberá elegir entre los dos modos. Afortunadamente, es muy fácil cambiar de un modo a otro más adelante, ya que no requiere ningún cambio en la aplicación o en el contenedor. Pero tenga en cuenta que, al incluir una aplicación en contenedores, elegir entre los dos modos es una de las primeras cosas que tendrá que hacer.

Orquestación de contenedores

La capacidad de ejecutar varios contenedores en uno o varios hosts sin preocuparse por la administración del sistema operativo le proporciona una gran flexibilidad, lo que le ayuda a avanzar hacia una arquitectura basada en microservicios. Sin embargo, una ventaja de esa flexibilidad es que un entorno basado en contenedores y microservicios puede convertirse rápidamente en muchas partes móviles, demasiadas para realizar un seguimiento. Afortunadamente, administrar el equilibrio de carga, la alta disponibilidad, la programación de contenedores, la administración de recursos y mucho más, es el rol de un orquestador de contenedores.

Quizás los orquestadores tienen un nombre erróneo; son más similares a los directores de una orquesta en que coordinan la actividad de varios contenedores para hacer que la música siga sonando. En cierto modo, controlan la programación y la asignación de recursos para los contenedores de forma similar al funcionamiento de un sistema operativo. Por lo tanto, a medida que vaya incluyendo las aplicaciones en contenedores, deberá elegir entre los orquestadores que admiten contenedores de Windows. Algunos de los más comunes son Kubernetes y Docker Swarm.

¿Qué no se puede trasladar a contenedores de Windows?

Cuando considere si una aplicación se puede incluir en contenedores o no, es probable que sea más fácil empezar con la lista de factores que descartan completamente los contenedores de Windows como una opción.

En la tabla siguiente aparecen los tipos de aplicaciones que no se pueden trasladar a contenedores de Windows y el por qué. Las razones se explican más por completo en las subsecciones después de la tabla. Comprender las razones de estas limitaciones puede proporcionarle una idea más clara de lo que realmente son los contenedores, incluida la forma en que difieren de las máquinas virtuales. Esto le ayudará a evaluar mejor las funcionalidades de los contenedores de Windows que puede aprovechar con las aplicaciones existentes que puedes incluir en contenedores.

Nota: La lista siguiente no está completa. En su lugar, es una compilación de aplicaciones que los clientes intentan incluir en contenedores, según Microsoft.

Aplicaciones o características no admitidas ¿Por qué no es compatible? ¿Puede solucionar esto?
Aplicaciones que requieren un escritorio Los contenedores no admiten la interfaz gráfica de usuario (GUI) Si la aplicación solo requiere una GUI para instalarla, cambiarla a una instalación silenciosa podría ser una solución.
Aplicaciones que usan Protocolo de escritorio remoto (RDP) RDP es para sesiones interactivas, por lo que el principio anterior también se aplica Es posible que pueda usar Windows Admin Center (WAC) o PowerShell remoto como alternativa para la administración remota
Aplicaciones con estado Los contenedores son efímeros Sí, algunas aplicaciones pueden requerir un cambio mínimo, por lo que no almacenan datos ni estado dentro del contenedor
Aplicaciones de bases de datos Los contenedores son efímeros Sí, algunas aplicaciones pueden requerir un cambio mínimo, por lo que no almacenan datos ni estado dentro del contenedor
Active Directory El diseño y el propósito de Active Directory impide la ejecución en un contenedor No. Sin embargo, las aplicaciones que dependen de Active Directory pueden usar cuentas de servicio administradas por grupos (gMSA). A continuación se proporciona más información sobre gMSA
Versiones de Windows Server más antiguas Solo se admite Windows Server 2016 o una versión posterior No. Sin embargo, la compatibilidad de aplicaciones podría ser una opción: la mayoría de las aplicaciones de Windows Server 2008/R2 y anteriores se ejecutan en versiones más recientes de Windows Server
Aplicaciones que usan .NET Framework versión 2.0 o anterior Se requieren imágenes de contenedor específicas para admitir .NET Framework y solo se admiten versiones más recientes Las versiones anteriores a la 2.0 no se admiten en absoluto, pero consulte a continuación las imágenes de contenedor necesarias para versiones posteriores
Aplicaciones que usan otros marcos de terceros Microsoft no certifica ni admite específicamente el uso de marcos que no son de Microsoft en contenedores de Windows Consulte con el proveedor del marco o aplicación específicos la directiva de soporte técnico para contenedores de Windows. Consulte el apartado siguiente para obtener más información

Consideremos cada una de estas limitaciones a su vez.

Aplicaciones que requieren un escritorio

Los contenedores son ideales para funciones efímeras que se invocan desde otras aplicaciones, incluidas las que tienen interacciones del usuario. Pero no se pueden usar para aplicaciones que tienen GUI. Esto es cierto incluso si la propia aplicación no tiene una GUI, pero tiene un instalador que se basa en una GUI. En general, Windows Installer se puede invocar mediante PowerShell, pero si la aplicación requiere instalación a través de una GUI, ese requisito lo elimina como candidato para incluir en contenedores.

Esto no es un problema con la forma en que se han implementado los contenedores de Windows, sino un concepto fundamental de cómo funcionan los contenedores.

Es diferente si una aplicación necesita una API de GUI. Las API se admiten aunque la GUI que sirven esas API no. Esto se explica con más detalle en el tema Nano Server x Server Core x Server: ¿Qué imagen base es la adecuada para usted?

Aplicaciones que usan RDP

Dado que todo el propósito del Protocolo de escritorio remoto (RDP) es establecer una sesión visual interactiva, la limitación de GUI descrita también se aplica. Una aplicación que usa RDP no se puede incluir en contenedores tal cual.

Sin embargo, una buena alternativa es una herramienta de administración remota como Windows Admin Center. Puede usar Windows Admin Center para administrar hosts de contenedores de Windows y los propios contenedores, sin necesidad de RDP en ellos. También puede abrir una sesión remota de PowerShell en el host o contenedores para administrarlos.

Aplicaciones con estado

Las aplicaciones que necesitan conservar los datos de estado solo se pueden incluir en contenedores si aísla los datos necesarios de una sesión a la siguiente y los almacena en el almacenamiento persistente. Esto puede requerir una "reestructuración" que puede ser o no trivial, pero llevarla a cabo eliminará esta barrera para la inclusión en contenedores.

Un ejemplo de estado es una aplicación web que almacena imágenes o archivos de música en una carpeta local. En un entorno de Windows tradicional, un archivo se guarda en el disco en el momento en que finaliza la operación de escritura, por lo que si se produce un error en la instancia (una máquina virtual en este caso), simplemente vuelva a abrirlo y el archivo seguirá estando ahí. Por el contrario, si se produce un error en una instancia de contenedor que realiza una operación de escritura, la nueva instancia de contenedor no incluirá ese archivo. Por este motivo, debe considerar el uso del almacenamiento persistente para que todas las instancias de contenedor puedan almacenar datos de estado o archivos en una ubicación centralizada y duradera. Este manera de rediseñar no requiere que cambie el código de la aplicación, solo el tipo de almacenamiento usado por la instancia de Windows. Para obtener más información, consulte la documentación del contenedor de Windows sobre el almacenamiento.

Sin embargo, esto implica otro tema relacionado...

Aplicaciones de bases de datos

Como regla general, las aplicaciones de base de datos no son excelentes candidatas para la inclusión en contenedores. Aunque puede ejecutar una base de datos dentro de un contenedor, incluir una base de datos existente en contenedores no suele ser la mejor opción, por dos motivos.

En primer lugar, el rendimiento necesario para una base de datos podría requerir todos los recursos de hardware disponibles para el host, lo que devaloriza la ventaja de la consolidación. En segundo lugar, varias instancias de un nivel de base de datos único necesitan coordinación para sus operaciones de escritura. La orquestación de contenedores puede resolverlo, pero para las bases de datos existentes, la orquestación puede convertirse en una sobrecarga. La mayoría de las bases de datos, como Microsoft SQL Server, tienen un equilibrio de carga integrado y un mecanismo de alta disponibilidad.

Roles de infraestructura en Windows Server

Los roles de infraestructura de Windows Server controlan principalmente las funciones más cercanas al sistema operativo (por ejemplo, AD, DHCP y Servidor de archivos). Por lo tanto, no están disponibles para ejecutar contenedores. Por lo tanto, las aplicaciones que necesitan estos roles siempre serán difíciles de incluir en contenedores.

Hay algunas áreas poco claras. Por ejemplo, algunas características como DNS pueden funcionar en contenedores de Windows aunque no estén diseñadas para usarse realmente en contenedores. Otros roles de infraestructura simplemente se quitan de la imagen de contenedor base y no se pueden instalar, como Active Directory, DHCP y otros.

Active Directory (AD)

Active Directory se lanzó hace más de veinte años junto con Windows 2000 Server. Usa un mecanismo en el que cada dispositivo o usuario está representado por un objeto almacenado en su base de datos. Esta relación está estrechamente acoplada y los objetos se mantienen en la base de datos incluso si el usuario o el dispositivo reales ya no están en juego. Ese enfoque para Active Directory contradice directamente la naturaleza efímera de los contenedores, que se espera que sean de corta duración o se eliminen cuando se desactivan. Mantener esta relación uno a uno con Active Directory no es ideal para esos escenarios.

Por ese motivo, los contenedores de Windows no pueden estar unidos a un dominio. Como efecto de eso, no se puede ejecutar Active Directory Domain Services como rol de infraestructura en contenedores de Windows. Puede ejecutar el módulo de PowerShell para administrar controladores de dominio de forma remota dentro de un contenedor de Windows.

En el caso de las aplicaciones que se ejecutan en contenedores de Windows dependientes de Active Directory, puede usar cuentas de servicio administradas por grupos (gMSA), que se verán en más detalle.

Aplicaciones que usan .NET Framework versión 2.0 o anterior

Si la aplicación requiere .NET, la capacidad de incluir en contenedores depende completamente de la versión de .NET Framework que usa. No se admite ninguna versión anterior a .NET Framework 2.0; las versiones posteriores requieren el uso de imágenes específicas, como se describe más adelante.

Aplicaciones que usan marcos de terceros (que no son de Microsoft)

Por lo general, Microsoft no puede certificar plataformas o aplicaciones de terceros, ni admitir su ejecución en contenedores de Windows, o máquinas físicas y virtuales para el caso. Sin embargo, Microsoft realiza sus propias pruebas internas para la facilidad de uso de varios marcos y herramientas de terceros, como Apache, Cassandra, Chocolatey, Datadog, Django, Flask, Git, Golang, JBoss, Jenkins, Rust, Nodejs, Pearl, Python, Ruby, Tomcat y muchos otros.

Para cualquier marco o software de terceros, valide su compatibilidad en contenedores de Windows con el proveedor que lo proporciona.

Candidatos idóneos para incluir en contenedores

Ahora que hemos considerado las limitaciones estrictas de incluir aplicaciones en contenedores, es más fácil ver qué tipos de aplicaciones se prestan más fácilmente a los contenedores de Windows. Los candidatos ideales para los contenedores de Windows y las consideraciones especiales para incluirlos en contenedores se encuentran en la tabla siguiente.

Tipo de aplicación Por qué son buenos candidatos Consideraciones especiales
Aplicaciones de consola Sin limitaciones de GUI, las aplicaciones de consola son candidatas ideales para contenedores. Use la imagen de contenedor base adecuada en función de las necesidades de la aplicación.
Servicios de Windows Dado que estos son procesos en segundo plano que no requieren ninguna interacción directa del usuario Use la imagen de contenedor base adecuada en función de las necesidades de la aplicación. Debe crear un proceso en primer plano para mantener en ejecución cualquier proceso en segundo plano incluido en contenedor. Consulte la sección servicios en segundo plano a continuación.
Servicios de Windows Communication Foundation (WCF) Dado que son aplicaciones orientadas a servicios que también se pueden ejecutar en segundo plano Use la imagen de contenedor base adecuada en función de las necesidades de la aplicación. Es posible que tenga que crear un proceso en primer plano para mantener en ejecución cualquier proceso en segundo plano incluido en contenedor. Consulte la sección servicios en segundo plano a continuación.
Aplicaciones web Las aplicaciones web son esencialmente servicios en segundo plano que escuchan en un puerto específico y, por tanto, son excelentes candidatos para la inclusión en contenedores, ya que pueden aprovechar la escalabilidad que ofrecen los contenedores Use la imagen de contenedor base adecuada en función de las necesidades de la aplicación.

Nota: incluso estos candidatos perfectos para la inclusión en contenedores pueden depender de las características y componentes principales de Windows que deberán controlarse de forma diferente en contenedores de Windows. La siguiente sección, que incluye más detalles sobre estas consideraciones prácticas, le preparará para aprovechar la funcionalidad de los contenedores de Windows.

Consideraciones prácticas para las aplicaciones que se pueden incluir en contenedores

Normalmente, los proyectos de renovación de aplicaciones tienen en cuenta si una aplicación determinada se puede incluir en contenedores a través de la perspectiva de la función empresarial de la aplicación. Pero la funcionalidad empresarial no es el factor que determina si técnicamente es posible. Lo que es importante es la arquitectura de la aplicación, es decir, en qué componentes técnicos se basa. Por lo tanto, no hay respuesta fácil a una pregunta como "¿Puedo incluir en contenedores mi aplicación de RR. HH?", porque no se trata de lo que hace la aplicación, sino de cómo (y qué componentes o servicios de Windows usa) que marca la diferencia.

Se trata de una distinción importante, ya que si la aplicación no está compilada con una arquitectura de microservicios para comenzar, es probable que sea más difícil incluir en contenedores. A medida que lleve a cabo la inclusión en contenedores, es posible que ciertas características necesiten una administración especial. Algunos pueden deberse al uso de la aplicación de componentes y marcos principales de Windows que no se admiten en contenedores de Windows. Otros, como el registro y la supervisión de eventos, se deben a diferencias inherentes entre Linux y Windows que se hacen evidentes solo cuando se incluye la aplicación en contenedores. Otros, como las tareas programadas y los servicios en segundo plano, deben entenderse desde la perspectiva de que un contenedor no es una máquina virtual, pero es efímero y, por tanto, necesita una administración especial.

En la tabla siguiente se presenta un resumen rápido de los componentes o características de las aplicaciones que necesitan especial consideración si se quieren incluir en contenedores. Las subsecciones siguientes proporcionan más detalles, incluidos ejemplos que ilustran técnicas para controlar cada escenario. Aunque en la lista siguiente aparecen los escenarios que se admiten en contenedores de Windows, estos escenarios deben seguir respetando las instrucciones del capítulo anterior. Por ejemplo, aunque se admiten servicios en segundo plano, no se admite la ejecución de un servicio en segundo plano en .NET Framework 1.1.

Característica o componente de Windows que requiere una administración especial Motivo
Microsoft Messaging Queueing (MSMQ) MSMQ tiene su origen mucho antes de los contenedores y no todos sus modelos de implementación para las colas de mensajes son compatibles con la arquitectura de contenedor.
Microsoft DTC (Coordinador de transacciones distribuidas) La resolución de nombres entre MSDTC y el contenedor requiere una consideración especial.
IIS IIS es el mismo que en una máquina virtual, pero hay consideraciones importantes al ejecutarlo en un entorno de contenedor, como la administración de certificados, las cadenas de conexión de base de datos, etc.
Tareas programadas Los contenedores de Windows pueden ejecutar tareas programadas, al igual que cualquier instancia de Windows. Sin embargo, es posible que tenga que ejecutar una tarea en primer plano para mantener la instancia de contenedor en ejecución. En función de la aplicación, es posible que quiera considerar un enfoque controlado por eventos.
Servicios en segundo plano Dado que los contenedores se ejecutan como procesos efímeros, necesitará administración adicional para mantener el contenedor en ejecución
.NET Framework y .NET (anteriormente .Net Core) Asegúrese de usar la imagen correcta para garantizar la compatibilidad, como se explica en la subsección siguiente

Otros componentes auxiliares

Componente que requiere administración especial Motivo Enfoque alternativo
Registro y supervisión de eventos Dado que la forma en que Windows escribe eventos y registros es inherentemente diferente de Linux stdout Use la nueva herramienta de supervisión de registros para normalizar los datos y combinarlos desde Linux y Windows
Seguridad de contenedores de Windows Aunque muchas prácticas de seguridad siguen siendo las mismas, los contenedores requieren medidas de seguridad adicionales Empleo de una herramienta de examen de imágenes y registro creada específicamente: más detalles más adelante
Copia de seguridad de contenedores de Windows Los contenedores no deben tener datos ni estado en ella Haga una copia de seguridad de cualquier almacenamiento persistente usado por contenedores, así como imágenes de contenedor

Componentes y características de Windows

Ahora vamos a profundizar en los detalles de las aplicaciones y componentes que se pueden incluir en contenedores, pero que requieren administración adicional.

MSMQ

Si la aplicación depende de MSMQ, poder incluirla en contenedores depende de su escenario de implementación de MSMQ. MSMQ incluye varias opciones de implementación. Los factores de colas privadas frente a públicas, transaccionales o no, y el tipo de autenticación forman una matriz de escenarios que MSMQ debía admitir originalmente. No todos ellos se pueden trasladar fácilmente a contenedores de Windows. En la tabla siguiente se enumeran los escenarios admitidos:

Ámbito ¿Transaccional? Ubicación de la cola Tipo de autenticación ¿Envío y recepción?
Privados Sí Mismo contenedor (contenedor único) Anónimas Yes
Privados Sí El volumen-persistente. Anónimas Yes
Privados Sí Controlador de dominio Anónimas Yes
Privados Sí Host único (dos contenedores) Anónimas Sí
Público No Dos hosts Anónimas Sí
Público Yes Dos hosts Anónimas Yes

Algunos detalles sobre estos escenarios admitidos, que han sido validados por los equipos de desarrollo internos de Microsoft:

  • Modo de aislamiento: tanto el modo de proceso como el modo Hyper-V para el aislamiento funcionan con los escenarios enumerados anteriormente.
  • Imagen mínima del sistema operativo y del contenedor: la versión mínima del sistema operativo recomendada para usar con MSMQ es Windows Server 2019.
  • Volúmenes persistentes: los escenarios anteriores se validaron ejecutando MSMQ en Azure Kubernetes Service (AKS) mediante Azure Files para el almacenamiento persistente.

Al reunir estas consideraciones con la tabla anterior, puede ver que el único escenario que no se admite es para colas que requieren autenticación con Active Directory. La integración de gMSA (cuentas de servicio administradas de grupo) con MSMQ no se admite actualmente, ya que MSMQ tiene dependencias en Active Directory que aún no están en su lugar.

Como alternativa, use Azure Service Bus en lugar de MSMQ. Azure Service Bus es un agente de mensajes empresarial totalmente administrado que incluye colas de mensajes y temas que se pueden publicar y a los que es posible suscribirse (en un espacio de nombres). El cambio de MSMQ a Azure Service Bus requiere cambios de código y rehacer la arquitectura de la aplicación, pero le proporcionará la agilidad para trasladarla a una plataforma moderna.

MSDTC

Coordinador de transacciones distribuidas (MSDTC) se usa en gran medida en las aplicaciones heredadas de Windows entre grandes empresas. MSDTC se puede instalar en contenedores de Windows, pero hay ciertos escenarios que no funcionan y no se pueden reproducir en contenedores de Windows.

  • Al crear el contenedor, asegúrese de pasar el parámetro --name al comando docker run. Este parámetro name es lo que permite que los contenedores se comuniquen a través de la red de Docker. Si usa gMSA, el nombre debe coincidir con el nombre de host el cual debe coincidir con el nombre de la cuenta de gMSA.
    • Este es un ejemplo del comando run con gMSA:
docker run -d --security-opt "credentialspec=file://contoso_webapp01.json" --hostname webapp01 -- name webapp01 mcr.microsoft.com/windows/servercore:ltsc2022
  • Los contenedores deben poder resolverse entre sí mediante el nombre de NETBIOS. Si hay alguna dificultad con esto, la mejor manera de resolver es agregar el nombre y la dirección IP de los contenedores a cada uno de los archivos host.
  • El uuid para msdtc en ambos contenedores debe ser único. Para encontrar el uuid, ejecute "Get-Dtc" en PowerShell en los contenedores. Si no son únicos, una manera de resolver es desinstalar y reinstalar msdtc en uno de los contenedores. Se pueden usar estos comandos de PowerShell: "uninstall-dtc", "install-dtc".
  • Actualmente, MSDTC no se admite en Azure Kubernetes Services. Si tiene una necesidad específica de ejecutar MSDTC en AKS, informe al equipo de contenedores de Windows abriendo una incidencia en el repositorio de contenedores de Windows en GitHub.

Funcionamiento de IIS en un contenedor frente a una máquina virtual

IIS funciona igual en un contenedor de Windows que en una máquina virtual. Sin embargo, hay algunos aspectos de la ejecución de una instancia de IIS que se deben tener en cuenta al ejecutarse en un entorno de contenedor:

  • Almacenamiento persistente para datos locales: las carpetas en las que la aplicación escribe o lee archivos hacia o desde son un buen ejemplo de algo que mantendría en una máquina virtual para una instancia de IIS. Con los contenedores, los datos no deben escribirse directamente en el contenedor. Los contenedores usan un "espacio temporal" para el almacenamiento local y cuando aparece un nuevo contenedor para la misma aplicación, no tiene acceso a esa área desde un contenedor anterior. Por ese motivo, debe usar el almacenamiento persistente para los datos que deben ser accesibles desde la aplicación web, para que cualquier instancia de contenedor pueda tener acceso a ese almacenamiento.
  • Certificados: aunque puede tener certificados locales en instancias de contenedor, debe evitar hacerlo, ya que si es necesario actualizar un certificado, debe volver a generar la imagen de contenedor. Como alternativa, puede usar un orquestador de contenedores con control de entrada. Los controladores de entrada pueden aplicar directivas de red y también controlar la administración de certificados para el sitio web que se hospeda detrás de él. La ventaja es que desvincula la administración del ciclo de vida de los certificados de la administración del sitio web.
  • Cadenas de conexión de base de datos: para la implementación tradicional de IIS, puede pasar la cadena de conexión de base de datos como parte de la implementación de la aplicación. Aunque los contenedores de Windows permiten seguir ese modelo, considere la posibilidad de desvincular la cadena de conexión de base de datos del contenedor y vincularla a una configuración centralizada proporcionada por el orquestador de contenedores, desde la que la aplicación puede leer. Esto le permite administrar y actualizar la cadena de conexión de base de datos independientemente de la aplicación. Si la base de datos cambia (para los casos de lift-and-shift a la nube, por ejemplo), puede cambiar fácilmente la cadena de conexión sin volver a generar la imagen del contenedor. Este enfoque también permite mantener secretos (como el nombre de usuario y la contraseña para conectarse a la base de datos) en un almacén de secretos.
  • Escalado automático horizontal: cuando aumenta la carga, los sistemas de proceso tienden a ralentizar el rendimiento percibido al intentar procesar las solicitudes simultáneas. Por lo general, hay dos maneras de evitar el impacto en el rendimiento: escala vertical u horizontal. La escala vertical aumenta los recursos disponibles para las instancias de proceso existentes (más CPU, memoria, etc.). La escala horizontal aumenta el número de instancias que admiten las solicitudes (más hosts físicos, máquinas virtuales o contenedores). En el caso de los niveles web como IIS, la escala horizontal tiende a ser más eficaz que la vertical, pero los entornos locales pueden encontrar limitaciones de recursos y problemas de equilibrio de carga. Con los entornos de nube, la escala horizontal es mucho más fácil, ya que los recursos están disponibles (por un costo adicional) y el proveedor de nube normalmente diseña su mecanismo de equilibrio de carga teniendo en cuenta la escala horizontal. Los contenedores de Windows pueden aprovechar la escala horizontal para IIS, pero el aspecto efímero de los contenedores desempeña un papel importante. Es imperativo que los contenedores tengan la misma configuración y que no se almacene ningún estado o datos para permitir el escalado o reducción vertical del número de instancias que admiten la aplicación web.

Tareas programadas

Las tareas programadas se usan para llamar a un programa, servicio o script en cualquier momento en un entorno de Windows. Tradicionalmente, tiene una instancia de Windows en funcionamiento en todo momento y cuando se cumple un desencadenador, se ejecuta la tarea. Esto es posible con contenedores de Windows y, aparte del hecho de que necesita configurar y administrar tareas programadas a través de Azure PowerShell, funcionan exactamente igual.

Sin embargo, con un enfoque de microservicios, tiene algunas opciones para evitar mantener un contenedor en ejecución para esperar un desencadenador:

  • Use un PaaS (Plataforma como servicio) controlado por eventos, como Azure Functions, para almacenar el código y definir un desencadenador para esa aplicación. Azure Functions incluso admite la ejecución de imágenes de contenedor de Windows cuando se encuentra un desencadenador.
  • Use contenedores de Windows junto con un orquestador de contenedores. El contenedor solo se puede ejecutar cuando se cumple el desencadenador y se llama desde otras partes de la aplicación. En este caso, el orquestador de contenedores controlará la programación y el desencadenador de la aplicación.
  • Por último, mantenga un contenedor de Windows en ejecución para ejecutar una tarea programada. Necesitará un servicio en primer plano (como ServiceMonitor) para mantener el contenedor en ejecución.

Servicios en segundo plano

Aunque los contenedores suelen ser para procesos efímeros, puede incluir en contenedores una aplicación en segundo plano y de larga duración siempre que cree un proceso en primer plano para iniciarlo y mantenerlo en ejecución.

Un buen ejemplo de esto es ServiceMonitor, que es un ejecutable de Windows diseñado para usarse como un proceso de punto de entrada al ejecutar IIS en contenedores. Aunque se creó para IIS, la herramienta ServiceMonitor ofrece un modelo que también se puede usar para supervisar otros servicios, con algunas limitaciones.

Para más información sobre ServiceMonitor, consulte la documentación de Github.

.NET Framework y .NET

Los contenedores de Windows admiten .NET Framework y .NET (anteriormente, .NET Core). El equipo de .NET crea sus propias imágenes oficiales para ambos marcos sobre las imágenes de contenedor base de Windows. Elegir la imagen adecuada es fundamental para garantizar la compatibilidad. El equipo de .NET proporciona imágenes de .NET Framework sobre la imagen de contenedor base de Server Core e imágenes de .NET sobre las imágenes de contenedor base de Server Core y Nano Server. Server Core tiene un conjunto de varias API mayor que Nano Server, lo que permite una mayor compatibilidad, pero también un tamaño de imagen mayor. Nano Server tiene una superficie de API muy reducida, pero un tamaño de imagen mucho menor.

En algunos casos, es posible que tenga que crear su propia imagen de .NET Framework o .NET sobre las imágenes de contenedor base de servidor o Windows. Esto puede ser necesario si la aplicación no solo tiene una dependencia de marco, sino una dependencia del sistema operativo. Podrá detectar estas dependencias probando la aplicación con una imagen de contenedor base determinada.

Por ejemplo, las imágenes de contenedor base de Server Core y Nano Server solo tienen una fuente disponible para reducir el tamaño de la imagen. Si la aplicación requiere una fuente diferente, tendrá que instalar esa fuente o usar las imágenes de Server o Windows, que tienen un conjunto de API más grande e incluir todas las fuentes predeterminadas de Windows. Desde el punto de vista de la compatibilidad, esto permite que prácticamente cualquier aplicación (siempre y cuando respeten la naturaleza de los contenedores, como que no haya ninguna GUI) se pueda incluir en contenedores. La desventaja es que serán mucho mayores de tamaño, lo que puede afectar al rendimiento.

Al validar si la aplicación que se va a incluir en contenedores funciona en contenedores de Windows, Microsoft recomienda lo siguiente:

Para este marco Pruebe con esta imagen de contenedor primero Reserve en esta imagen de contenedor si la primera vez no funciona Base image
.NET Framework versiones 2.X y 3.X .NET Framework 4.x .NET Framework 3.5 Windows Server Core
Versiones 4.x de .NET Framework .NET Framework 4.x Compilación de la imagen de contenedor de .NET Framework con imágenes de Server o Windows Windows Server Core
.NET 6 o 7 .NET 6 o 7 respectivamente Compilación de la imagen de contenedor de .NET con imágenes base de Windows o Server Nano Server o Server Core de Windows

Otros componentes auxiliares

Los componentes y temas siguientes proporcionan instrucciones adicionales para los elementos que van junto a los contenedores de Windows o que proporcionan una mayor claridad.

Registros de eventos

Windows y Linux usan diferentes métodos para almacenar y presentar registros y eventos a sus usuarios. Tradicionalmente, Windows ha usado el formato EVT, que se puede ver de forma estructurada en Visor de eventos. Linux, por el contrario, ha proporcionado un enfoque simplificado con la salida estándar (stdout) en la que se basan otras herramientas, como Docker.

Docker siempre ha tenido un mecanismo para extraer registros de contenedores de Linux. Con el comando "docker logs" con una configuración de stdout predeterminada, Docker saca los registros de la aplicación del contenedor sin abrir el contenedor de forma interactiva. Sin embargo, hasta el inicio de la herramienta Supervisión de registros, la misma técnica no funcionaba en Windows.

La herramienta Supervisión de registros presenta los registros de Windows en el formato stdout para que otras herramientas, como Docker, puedan recopilar la información necesaria para mostrarla. Entre las ventajas adicionales para usar Supervisión de registros se incluyen las siguientes:

  • Poder filtrar qué tipos de eventos o registros desea exponer en stdout. Por ejemplo, puede filtrar el registro de la aplicación por mensajes de "error" y "advertencia" solo si no está interesado en eventos de "información".
  • La capacidad de elegir entre registros de eventos, archivos de registro personalizados o seguimiento de eventos para Windows (ETW). Esto es especialmente útil si la aplicación está escribiendo en un origen de registro diferente. Un ejemplo de esto son los registros de IIS ubicados en la carpeta "C:\inetpub".
  • El hecho de que Supervisión de registros hace que los contenedores de Windows se comporten de forma similar a los contenedores de Linux y, por lo tanto, las herramientas que buscan stdout e interactúan con el entorno de ejecución del contenedor funcionan según lo previsto. Por ejemplo, si pasa de Docker a ContainerD como entorno de ejecución del contenedor, los registros seguirán siendo visibles desde el host del contenedor a través de (por ejemplo) "registros crictl".

Puede obtener más información sobre Supervisión de registros en esta entrada de blog.

Seguridad de contenedores de Windows

Los contenedores de Windows se construyen en la misma base que las instancias de Windows que se ejecutan en máquinas físicas o virtuales. Comprender los detalles de cómo se implementan los contenedores, especialmente su naturaleza de kernel compartido, le ayuda a proteger una aplicación en contenedor:

  • Componentes compartidos. Los contenedores de Windows comparten algunos de los componentes del host con fines de seguridad. Esto incluye el firewall de Windows, Windows Defender (Antivirus) y otras limitaciones de acceso a los recursos. No es necesario configurar estos componentes en el contenedor directamente porque el host del contenedor realiza los ajustes necesarios en función de la carga de trabajo del contenedor. Por ejemplo, si el contenedor realiza una solicitud web, el host del contenedor reenviará el tráfico necesario a través de su firewall para que el contenedor pueda acceder a la web.
  • Modo de aislamiento. Como se ha explicado, los contenedores de Windows se pueden implementar en modo de aislamiento de proceso o Hyper-V (Hyper-V proporciona el aislamiento más seguro). En aislamiento de procesos, el contenedor comparte su kernel, sistema de archivos y registro con el host, lo que permite que un proceso elevado (administrador) interactúe con los procesos y servicios del contenedor. Es importante elegir el modo de aislamiento correcto para la aplicación para garantizar el modelo de seguridad adecuado.
  • Actualizaciones de Windows. Dado que la pila de mantenimiento no está presente en contenedores de Windows, los contenedores de Windows no reciben actualizaciones como las instancias generales de Windows. En su lugar, debe recompilar contenedores de Windows con la imagen de contenedor base disponible más reciente. Los clientes pueden aprovechar las canalizaciones de DevOps para ese propósito. Microsoft actualiza las imágenes de contenedor base para todas sus imágenes oficiales mensualmente siguiendo la cadencia de Patch Tuesday.
  • Cuenta de usuario de contenedor. De forma predeterminada, las aplicaciones dentro de contenedores de Windows se ejecutan con privilegios elevados en la cuenta de usuario ContainerAdmin. Esto resulta útil para instalar y configurar los componentes necesarios dentro de la imagen de contenedor. Sin embargo, debe considerar la posibilidad de cambiar la cuenta de usuario a ContainerUser al ejecutar una aplicación que no requiera los privilegios elevados. En escenarios específicos, también puede crear una nueva cuenta con los privilegios adecuados.
  • Examen de imágenes y tiempo de ejecución. Los contenedores requieren que las imágenes de los repositorios y las instancias de contenedores sean seguras. Microsoft recomienda usar Microsoft Defender para contenedores para el análisis de imágenes y el análisis de entorno de ejecución. Defender para contenedores admite contenedores de Windows para la evaluación de vulnerabilidades con el examen de registros y la protección de entorno de ejecución con detección de amenazas.

Puede encontrar más información sobre los temas anteriores en la página de documentación de contenedores de Windows.

Copia de seguridad de contenedores de Windows

Debe pensar en las copias de seguridad de forma diferente cuando se usan contenedores. Como se ha explicado anteriormente, un contenedor no se debe usar para almacenar el estado o los datos dada su naturaleza efímera. Si separa el estado y los datos de la instancia de contenedor, los problemas de copia de seguridad están fuera del entorno de ejecución de la instancia de contenedor, que se puede reemplazar por uno nuevo al que todo el almacenamiento persistente necesario seguirá estando disponible.

Sin embargo, todavía hay componentes de los cuales usted es responsable de realizar copias de seguridad; incluida la aplicación, la imagen de contenedor y el dockerfile que compila la imagen de contenedor. La mayoría de estas operaciones se controlan mediante la plataforma en la que se ejecutan las cargas de trabajo de producción y desarrollo. Al adoptar un enfoque de DevOps, tenga en cuenta los casos más comunes:

  • Aplicación: la aplicación probablemente reside en un repositorio de origen, como GitHub o Azure DevOps. Estos repositorios proporcionan control de versiones, lo que le permite volver a una versión específica de la aplicación. Si posee el repositorio de origen, asegúrese de seguir sus recomendaciones de copia de seguridad y administración.
  • Imagen de contenedor: para entornos de producción, la imagen de contenedor debe residir en un repositorio de imágenes centralizado, como Azure Container Registry (ACR). Puede insertar las imágenes de contenedor en ACR para que estén disponible y otros hosts puedan extraerlas. ACR administra la disponibilidad de las imágenes de contenedor y sirve como opción de copia de seguridad; sin embargo, tenga en cuenta que, aunque ACR administra la disponibilidad de la imagen, no impide que se elimine o sobrescriba una imagen. Para cualquier otro repositorio de imágenes local, siga la recomendación del proveedor para realizar copias de seguridad de registros existentes.
  • Dockerfile: los archivos dockerfiles crean nuevas imágenes de contenedor y normalmente se almacenan junto con el origen de la aplicación. Dado que es posible que el dockerfile no se haya creado con la aplicación, especialmente si se trata de una aplicación existente que se incluye en contenedores, es responsable de garantizar que dockerfile se almacena en una ubicación segura y de la que se realiza una copia de seguridad. También debe asegurarse de que se realice una copia de seguridad de cualquier otro recurso necesario para que la aplicación funcione en un contenedor; por ejemplo, los archivos YAML y JSON para Kubernetes, Docker Swarm y las plantillas de Azure ARM siguen las mismas directrices que los anteriores.

Planificación del proceso de lift-and-shift

Después de evaluar la preparación de la aplicación para la inclusión en contenedores, use las siguientes instrucciones generales para planear el proceso:

  1. Determine la imagen base del sistema operativo Windows que necesita: imágenes de Windows Server Core, Nano Server, Windows o Server.
  2. Determine el tipo de modo de aislamiento para el contenedor: elija entre los modos de aislamiento de proceso o Hyper-V. Nota: Actualmente, AKS y AKS en Azure Stack HCI solo admiten contenedores aislados de procesos. En una versión futura, tanto AKS como AKS en Azure Stack HCl serán compatibles con los contenedores aislados por Hyper-V. Para obtener más información, consulte Modos de aislamiento.
  3. Elija la versión correcta de Windows Server para la aplicación con fines de compatibilidad de aplicaciones. La versión mínima de Windows Server para contenedores es Windows Server 2016, pero Windows Server 2019 y Windows Server 2022 son los únicos sistemas operativos host de contenedor compatibles con AKS y AKS en Azure Stack HCI.
  4. Asegúrese de que las directivas de seguridad de la empresa están en vigor para el entorno de contenedor. Esto incluye la adaptación a requisitos específicos del contenedor, como el examen del registro y la detección de amenazas.
  5. Tenga en cuenta las necesidades de equilibrio de carga. Los propios contenedores no se mueven. Puede usar un orquestador en su lugar para iniciar o detener automáticamente los contenedores en los nodos del clúster, o para administrar los cambios en la carga y la disponibilidad con escala horizontal automática.
  6. Considere las necesidades de orquestación. Una vez en contenedores, es probable que la aplicación necesite administración automatizada disponible con herramientas como Kubernetes, AKS o AKS en Azure Stack HCI. Consulte Información general sobre la orquestación de contenedores de Windows para obtener una explicación completa y una guía para elegir entre las herramientas.
  7. Incluya la aplicación en contenedores.
  8. Inserte la aplicación en un repositorio de imágenes. Esto permitirá que los hosts de contenedor descarguen la imagen en cualquier entorno, incluido el desarrollo, la prueba y la producción.

Azure Migrate proporciona un proceso guiado para detectar, evaluar y migrar la aplicación de Windows existente a Azure Kubernetes Service. Para más información, consulte la página de documentación de Azure Migrate.