Compartir a través de

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

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

Los contenedores de Windows proporcionan un excelente mecanismo para modernizar las aplicaciones tradicionales o heredadas. Aunque es posible que vea que a este enfoque se le denomina "migración mediante lift-and-shift a contenedores", la metáfora de "migración mediante lift-and-shift" se origina por el traslado de cargas de trabajo de máquinas físicas a máquinas virtuales y se utiliza cuando se habla de mover cargas de trabajo a la nube. En la actualidad, este término se aplica más adecuadamente a la migración de máquinas virtuales (VM). Sin embargo, los contenedores no son máquinas virtuales y pensar en ellos como máquinas virtuales puede provocar confusión sobre cómo se contenediza una aplicación, o si puede o debe ser contenedizada.

En este tema se proporcionan instrucciones prácticas sobre cómo mover aplicaciones tradicionales a contenedores de Windows. Tiene como objetivo ayudarle a priorizar qué aplicaciones deben incluirse en contenedores, al explicar consideraciones especiales por adelantado.

Introducción

Qué son los contenedores de Windows y cuáles 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 más 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 su demanda de recursos y funciones con el sistema operativo Windows. ¿Por qué 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 obtener más información sobre este tema en Contenedores frente a máquinas virtuales. Pero algunos puntos buenos que le ayudan 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 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 forma predeterminada, no hay ningún mecanismo para guardar el estado de una instancia de contenedor. Si se produce un error en una instancia, otra instancia tendrá su lugar.

La tecnología de contenedores comenzó en Linux, con Docker emergente como estándar. Microsoft ha trabajado estrechamente con Docker para asegurarse de que la funcionalidad del contenedor sea la misma en Windows que sea razonablemente posible. 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 Hyper-V aislamiento, que se tratarán más adelante. Este tema le ayuda a comprender esas diferencias y a adaptarlas.

Ventajas del uso de contenedores

Al igual que ejecutar varias máquinas virtuales en un único host físico, puede ejecutar varios contenedores en un único 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 cualquier 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 aplicaciones, 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 de hardware. Los contenedores permiten tomar cualquier aplicación de desarrollo a 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 de 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 se 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 más completa de ventajas para usar contenedores para aplicaciones existentes en la página de documentación de Microsoft .NET.

Concepto importante del nivel de aislamiento

Los contenedores de Windows proporcionan aislamiento del sistema operativo Windows, aislamiento que es ventajoso al compilar, probar y promover una aplicación a producción. Pero la manera en que se logra el aislamiento es importante comprender cuándo está pensando en la contenedorización de una aplicación.

Los contenedores de Windows ofrecen dos modos distintos de aislamiento de tiempo de ejecución: proceso y Hyper-V. Los contenedores de ambos modos se crean y administran de forma idéntica y funcionan de forma idéntica. Entonces, ¿cuáles son las diferencias y por qué debe preocuparse?

En el aislamiento de procesos, varios contenedores se ejecutan simultáneamente en un único host con aislamiento proporcionado mediante el espacio de nombres, el control de recursos y otras características. Los contenedores en modo de aislamiento de proceso comparten el mismo kernel con el host y entre sí. Esto es aproximadamente igual que la forma 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 lo hacen dentro de máquinas virtuales altamente optimizadas, y cada uno de ellos obtiene de forma eficaz su propio kernel. La presencia de esta máquina virtual, de hecho una máquina virtual 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 una especie de híbrido entre 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 las siguientes:

  • 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 el aislamiento de Hyper-V.
  • Ni Azure Kubernetes Service (AKS) ni AKS en Azure Stack HCI admiten el aislamiento Hyper-V actualmente.

Puede obtener más información sobre cómo se implementan los dos modos de aislamiento en el tema Modos de aislamiento. Cuando contenerizas una aplicación por primera vez, deberás 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 un solo host o varios hosts sin preocuparse por la administración del sistema operativo le ofrece una gran flexibilidad, lo que le ayuda a avanzar hacia una arquitectura basada en microservicios. Sin embargo, una compensación por esa flexibilidad es que un entorno basado en contenedores y microservicios puede expandirse 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 como los directores de una orquesta en el sentido de que coordinan la actividad de varios contenedores para que la música siga sonando. En cierto sentido, 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 pase a incluir en contenedores las aplicaciones, deberá elegir entre los orquestadores que admiten contenedores de Windows. Algunos de los más comunes son Kubernetes y Docker Swarm.

Lo que no se puede mover a contenedores de Windows

Cuando se considera 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 se resumen los tipos de aplicaciones que no se pueden mover a contenedores de Windows y por qué no. 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, incluido cómo difieren de las máquinas virtuales. Esto, a su vez, te ayudará a evaluar mejor las funcionalidades de los contenedores de Windows que puedes aprovechar con las aplicaciones existentes que puedes incluir en contenedores.

Nota: La lista siguiente no es una lista 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 compatibles ¿Por qué no es compatible? ¿Puedes 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 el protocolo de escritorio remoto (RDP) RDP es para sesiones interactivas, por lo que el principio anterior también se aplica aquí. Puede usar Windows Admin Center (WAC) o PowerShell remoto como alternativa para la administración remota.
Aplicaciones con estado Los contenedores son efímeros Sí, es posible que algunas aplicaciones requieran un cambio mínimo, por lo que no almacenan datos ni estado dentro del contenedor.
Aplicaciones de base de datos Los contenedores son efímeros Sí, es posible que algunas aplicaciones requieran 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 impiden la ejecución en un contenedor. No. Sin embargo, las aplicaciones que dependen de Active Directory pueden usar cuentas de servicio administradas de grupo (gMSA). A continuación se proporciona más información sobre gMSA.
Versiones anteriores de Windows Server Solo se admite Windows Server 2016 o posterior No. Sin embargo, la compatibilidad de aplicaciones podría ser una opción: la mayoría de windows Server 2008/R2 y las aplicaciones 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 versión 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 específico o la aplicación la directiva de soporte técnico para contenedores de Windows. Consulte a continuación para obtener más información.

Vamos a considerar 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 las aplicaciones que tienen GUIs por sí mismos. 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, Se puede invocar Windows Installer mediante PowerShell, pero si la aplicación requiere la instalación a través de una GUI, ese requisito lo elimina como candidato para la inclusión 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 API de GUI. Se admiten API, aunque no la GUI que sirven esas API. Esto se explica más detalladamente 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 as-is.

Sin embargo, una buena alternativa es una herramienta de administración remota como Windows Admin Center. Puedes usar Windows Admin Center para administrar hosts de contenedores de Windows y los contenedores en sí mismos, sin necesidad de usar 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 se aíslan los datos necesarios de una sesión a la siguiente y se almacenan en el almacenamiento persistente. Esto puede requerir una "rediseño", que puede ser o no trivial, pero continuar con ella eliminará esta barrera para la contenedorización.

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 tradicional de Windows, un archivo se guarda al disco en el momento en que finaliza la operación de escritura, por lo que si se produce un fallo en la instancia, en este caso, una máquina virtual, simplemente la reinicia y el archivo seguirá allí. 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 la posibilidad de usar el almacenamiento persistente para que todas las instancias de contenedor puedan almacenar datos de estado o archivos en una ubicación centralizada y duradera. Este tipo de rediseño no requiere que cambies 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 trae otro tema relacionado...

Aplicaciones de base de datos

Como regla general, las aplicaciones de base de datos no son excelentes candidatas para la contenedorización. Aunque puede ejecutar una base de datos dentro de un contenedor, la contenedorización de una base de datos existente no suele ser ideal, 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 devalora 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 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 grises. Por ejemplo, algunas características como DNS pueden funcionar en contenedores de Windows aunque realmente no estén diseñadas para usarse 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 a lo largo de 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 contradiga directamente la naturaleza efímera de los contenedores, que se espera que sean de corta duración o se eliminen cuando se desactiven. 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, 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, use cuentas de servicio administradas de grupo (gMSA), que se explicarán más adelante.

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 ideales para la contenedorización

Ahora que hemos considerado las limitaciones difíciles 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 se trata de 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 funcionando cualquier proceso en segundo plano containerizado. Consulte la sección sobre los servicios en segundo plano a continuación.
Servicios de Windows Communication Foundation (WCF) Dado que son aplicaciones orientadas al servicio que también se ejecutan 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 en contenedor. Consulte la sección sobre los 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 contenedorización, ya que aprovechan 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 ideales para la contenedorización pueden depender de las características y componentes principales de Windows que deban controlarse de forma diferente en contenedores de Windows. La siguiente sección, que incluye más detalles sobre estas consideraciones prácticas, le preparará mejor 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, qué componentes técnicos se basan. Por lo tanto, no hay respuesta fácil a una pregunta como "¿Puedo incluir en contenedores mi aplicación de RR. HH?", porque no es lo que hace la aplicación, es cómo (y qué componentes o servicios de Windows usa) que marca la diferencia.

Se trata de una distinción importante, ya que si tu aplicación no se construyó con una arquitectura de microservicios desde el principio, es probable que sea más difícil containerizarla. 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 de eventos y la supervisión, se deben a diferencias inherentes entre Linux y Windows que se vuelven aparentes 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 lo tanto, necesita un control especial.

En la tabla siguiente se presenta un resumen rápido de los componentes o características de las aplicaciones que necesitan una consideración especial al pensar en la contenedorización. Las subsecciones siguientes proporcionan más detalles, incluidos ejemplos que muestran técnicas para controlar cada escenario. Aunque en la lista siguiente se describen los escenarios que se admiten en contenedores de Windows, estos escenarios siguen teniendo que respetar 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ísticas o componentes de Windows que requieren un control especial Razón
Microsoft Messaging Queueing (MSMQ) MSMQ se originó mucho antes de que los contenedores y no todos sus modelos de implementación para las colas de mensajes sean compatibles con la arquitectura de contenedor.
Coordinador de transacciones distribuidas de Microsoft (MSDTC) La resolución de nombres entre MSDTC y el contenedor necesita 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 desee considerar un enfoque controlado por eventos.
Servicios en segundo plano Como los contenedores se ejecutan como procesos efímeros, necesitará un control 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 un control especial Razón Enfoque alternativo
Registro y supervisión de eventos Dado que la forma en que Windows escribe eventos y registros es inherentemente diferente de Stdout de Linux Use la nueva herramienta Log Monitor 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 análisis de imágenes y registro diseñada específicamente: más detalles más adelante.
Copia de seguridad de contenedores de Windows Los contenedores no deben tener datos ni estado Realice una copia de seguridad de cualquier almacenamiento persistente que usen los contenedores, así como las 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 un control adicional.

MSMQ

Si la aplicación depende de MSMQ, si puede 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 se diseñó originalmente para admitir. No todos estos se pueden mover fácilmente a contenedores de Windows. En la tabla siguiente se enumeran los escenarios admitidos:

Alcance ¿Transaccional? Ubicación de la cola Tipo de autenticación ¿Enviar y recibir?
Privado Sí Mismo contenedor (contenedor único) Anónimo Sí
Privado Sí Volumen persistente Anónimo Sí
Privado Sí Controlador de dominio Anónimo Sí
Privado Sí Host único (dos contenedores) Anónimo Sí
Público No Dos anfitriones Anónimo Sí
Público Sí Dos anfitriones Anónimo Sí

Algunas notas 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 funcionan para el aislamiento en 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.

Cuando se colocan estas consideraciones junto con la tabla anterior, puede ver que el único escenario que no se admite es para las 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 vigor.

Como alternativa, use Azure Service Bus en lugar de MSMQ. Azure Service Bus es un agente de mensajes empresarial totalmente administrado con colas de mensajes y temas de publicación y suscripción (en un espacio de nombres). El cambio de MSMQ a Azure Service Bus requiere cambios de código y la nueva arquitectura de la aplicación, pero le proporcionará la agilidad para pasar a una plataforma moderna.

MSDTC

El Coordinador de transacciones distribuidas de Microsoft (MSDTC) se usa en gran medida en 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 a los contenedores comunicarse a través de la red de Docker. Si usa gMSA, el nombre debe coincidir con el nombre de host que 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 se deben poder resolver entre sí mediante el nombre 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 los archivos host entre sí.
  • El uuid para msdtc en ambos contenedores debe ser único. El UUID se puede encontrar ejecutando "Get-Dtc" en el PowerShell dentro de 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 el problema 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: carpetas en las que la aplicación escribe o lee archivos hacia o desde son un excelente ejemplo de algo que se mantendría en una máquina virtual para una instancia de IIS. Con los contenedores, no quieres que ningún dato se escriba 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, use el almacenamiento persistente para los datos que deben ser accesibles para la aplicación web, de modo que cualquier instancia de contenedor pueda tener acceso a ese almacenamiento.
  • Certificados: aunque puede tener certificados locales en instancias de contenedor, evite 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 ingreso pueden aplicar políticas de red y también gestionar el manejo de certificados para el sitio web alojado detrás de ellos. La ventaja es desacoplar 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, es posible que quiera considerar la posibilidad de desacoplar la cadena de conexión de base de datos del contenedor 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 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 o 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, usted tiene una instancia de Windows en funcionamiento en todo momento y cuando se cumple una condición, 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 a la espera de un desencadenante:

  • Use un PaaS basado en eventos (plataforma como servicio), como Azure Functions, para almacenar el código y definir un desencadenador para esa aplicación. Azure Functions admite incluso 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 encuentra 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 Service Monitor) para mantener el contenedor en ejecución.

Servicios en segundo plano

Aunque los contenedores suelen ser para procesos efímeros, puede contenerizar una aplicación en segundo plano y de larga duración, siempre que cree un proceso en primer plano para lanzarla y mantenerla 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 en 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 frameworks a partir de las imágenes base del contenedor 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 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 una imagen propia de .NET Framework o .NET sobre las imágenes de contenedor base de Server 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 un tipo de letra disponible con el fin de reducir el tamaño de la imagen. Si la aplicación necesita otra fuente, tendrá que instalar esa fuente o usar las imágenes de Server o Windows, que tienen un conjunto de API más grande e incluyen todas las fuentes predeterminadas de Windows. Desde el punto de vista de la compatibilidad, esto permite que prácticamente cualquier aplicación (siempre que respete la naturaleza de los contenedores, como la ausencia de interfaz gráfica) se pueda contenerizar. Sin embargo, serán mucho más grandes, lo que puede afectar el 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 Prueba con esta imagen de contenedor primero Recurre a esta imagen de contenedor si la primera no funciona Imagen base
Versiones 2.X y 3.X de .NET Framework .NET Framework 4.x .NET Framework 3.5 Windows Server Core
Versiones de .NET Framework 4.x .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 Construye tu imagen de contenedor de .NET con imágenes base de Windows o servidor. Windows Nano Server o Server Core

Otros componentes auxiliares

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

Registro 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 el 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 predeterminada de stdout, Docker cierra los registros de la aplicación del contenedor sin abrir el contenedor de forma interactiva. Sin embargo, hasta el lanzamiento de la herramienta Monitor de registro, la misma técnica no funcionó en Windows.

La herramienta Monitor de registro 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 el Monitor de registro 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 le interesan los eventos de "información".
  • La capacidad de elegir entre registros de eventos, archivos de registro personalizados o seguimiento de eventos para Windows (ETW). Esto resulta especialmente útil si la aplicación está escribiendo en un origen de registro diferente. Un ejemplo de esto es los registros de IIS ubicados en la carpeta "C:\inetpub".
  • El hecho de que Log Monitor hace que los contenedores de Windows se comporten de manera muy similar a los contenedores de Linux permite que las herramientas que buscan stdout e interactúan con el entorno de ejecución del contenedor funcionen según lo esperado. Por ejemplo, si se mueve de Docker a ContainerD como entorno de ejecución de contenedores, los logs deberían seguir siendo visibles desde el host del contenedor a través de (por ejemplo) "crictl logs".

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

Seguridad de contenedores de Windows

Los contenedores de Windows se basan 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 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 reenvía el tráfico necesario a través de su firewall para que el contenedor pueda acceder a la web.
  • Modo de aislamiento. Como se explicó, los contenedores de Windows se pueden implementar en modo de aislamiento de procesos o modo de aislamiento de Hyper-V, con Hyper-V proporcionando 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. Como 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 reconstruir los contenedores de Windows utilizando 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 cuenta con los privilegios adecuados.
  • Examen de imágenes y runtime. Los contenedores necesitan que las imágenes de los repositorios y las instancias de contenedores sean seguras. Microsoft recomienda usar Microsoft Defender para contenedores para el examen de imágenes y el examen en tiempo de ejecución. Defender for Containers admite contenedores de Windows para la evaluación de vulnerabilidades con el examen del registro y la protección en tiempo 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 al usar contenedores. Como se explicó anteriormente, un contenedor no debe usarse para almacenar el estado ni 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 seguirá estando disponible todo el almacenamiento persistente necesario.

Todavía hay componentes que usted es responsable de realizar copias de seguridad, sin embargo; 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 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 controla la disponibilidad de las imágenes de contenedor y actúa como opción de copia de seguridad; sin embargo, tenga en cuenta que, aunque ACR controla la disponibilidad de la imagen, no impide que se elimine o sobrescriba una imagen. Para cualquier otro repositorio de imágenes local o en las instalaciones, siga la recomendación del proveedor para hacer copias de seguridad de los registros existentes.
  • Dockerfile: Dockerfiles compila 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 está contenedorizando, usted es responsable de garantizar que el dockerfile se almacene en una ubicación segura y respaldada. También debe asegurarse de que se realice una copia de seguridad de los demás recursos necesarios 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 anteriormente.

Planificación del proceso de migrar mediante lift-and-shift

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

  1. Determine la imagen base del sistema operativo Windows que necesita: windows Server Core, Nano Server, Windowso Server imágenes.
  2. Determine el tipo de modo de aislamiento para el contenedor: elija entre los modos de proceso o de aislamiento Hyper-V. Nota: Actualmente, AKS y AKS en Azure Stack HCI solo admiten contenedores aislados de procesos. En una versión futura, AKS y AKS en Azure Stack HCI también admitirán contenedores aislados de Hyper-V. Para obtener más información, vea Modos de aislamiento.
  3. Elija la versión correcta de Windows Server para la aplicación con fines de compatibilidad de la aplicación. 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. Considere las necesidades de equilibrio de carga. Los 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 de carga y 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. Vea 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 puede proporcionar 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.