Díganos qué opina sobre la experiencia de descarga del PDF.

Contenedores en la documentación de
Windows
Los contenedores de Windows permiten a los usuarios empaquetar aplicaciones con sus
dependencias y aprovechar la virtualización de nivel de sistema operativo para
proporcionar entornos rápidos y totalmente aislados en un único sistema. Obtenga
información sobre cómo usar contenedores de Windows con nuestras guías de inicio
rápido, guías de implementación y ejemplos.

Contenido destacado

ｅ INFORMACIÓN GENERAL

Pruebe los contenedores de Windows en AKS.

Pruebe contenedores de Windows en AKS en Azure Stack HCI.

Consulte nuestras imágenes de contenedor en Docker Hub.

Lea el blog contenedores.

Visión general

ｅ INFORMACIÓN GENERAL

Acerca de los contenedores de Windows

Requisitos del sistema

Preguntas más frecuentes

Comenzar

ｂ INTRODUCCIÓN

Configuración del entorno

Ejecución del primer contenedor

Contenedorización de una aplicación de ejemplo

Migración mediante lift-and-shift a contenedores

Tutoriales

ｇ TUTORIAL

Creación de un contenedor de Windows

Ejecución en Azure Kubernetes Service en Azure Stack HCI

Ejecución en AKS

Ejecución en Service Fabric

Ejecución en Azure App Service

Configurar la extensión Containers en Windows Admin Center

Conceptos

ｐ CONCEPTO

Estibador

Orquestación de contenedores

Aspectos básicos del contenedor de Windows

Protección de contenedores de Windows

Cuentas de servicio administradas de grupo

Referencia

ｉ REFERENCIA

Compatibilidad de versiones

Ciclos de vida de mantenimiento de imágenes

CLUF de imagen del sistema operativo de contenedor

Recursos
ｉ REFERENCIA

Muestras

Solución de problemas
Windows y contenedores
Artículo • 21/03/2023

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

Los contenedores son una tecnología para empaquetar y ejecutar aplicaciones de Windows y
Linux en diversos entornos locales y en la nube. Los contenedores proporcionan un entorno
ligero y aislado que facilita el desarrollo, implementación y administración de las aplicaciones.
Los contenedores se inician y detienen rápidamente, por lo que son ideales para las
aplicaciones que necesitan adaptarse rápidamente a la demanda cambiante. La naturaleza
ligera de los contenedores también los convierte en una herramienta útil para aumentar la
densidad y el uso de la infraestructura.

El ecosistema de contenedores de Microsoft

Microsoft ofrece una serie de herramientas y plataformas que le ayudarán a desarrollar e
implementar aplicaciones en contenedores:

Ejecute contenedores basados en Windows o Linux en Windows 10 para procesos de

desarrollo y pruebas con Docker Desktop , que usa la funcionalidad de contenedores
integrada en Windows. También puede ejecutar contenedores de forma nativa en
Windows Server.

Desarrolle, pruebe, publique e implemente contenedores basados en Windows gracias

a la eficaz compatibilidad con contenedores en Visual Studio y Visual Studio Code , que
 incluyen compatibilidad con Docker, Docker Compose, Kubernetes, Helm y otras
tecnologías útiles.

Publique sus aplicaciones como imágenes de contenedor en DockerHub público para

que las usen otros usuarios, o en una instancia privada de Azure Container Registry
para los procesos de desarrollo e implementación de su organización. De este modo,
podrá enviar ("push") e incorporar ("pull") cambios directamente desde Visual Studio y
Visual Studio Code.

Implemente contenedores a escala en Azure u otras nubes:

Extraiga la aplicación (imagen de contenedor) de un registro de contenedor (como
Azure Container Registry) y después impleméntela y adminístrela a escala mediante un
orquestador como Azure Kubernetes Service (AKS).
Azure Kubernetes Service implementa contenedores en máquinas virtuales de Azure y
los administra a escala, independientemente de si son docenas de contenedores,
cientos o incluso miles. Las máquinas virtuales de Azure ejecutan una imagen de
Windows Server personalizada (si va a implementar una aplicación basada en
Windows) o una imagen de Ubuntu Linux personalizada (si va a implementar una
aplicación basada en Linux).

Implemente contenedores en el entorno local mediante AKS en Azure Stack HCI, Azure
Stack con el motor de AKS o Azure Stack con OpenShift. También puede configurar
Kubernetes en Windows Server (consulte Kubernetes en Windows) y estamos trabajando
en admitir la ejecución de contenedores de Windows en RedHat OpenShift Container
Platform .

Cómo funcionan los contenedores

Un contenedor es un paquete aislado y ligero para ejecutar una aplicación en el sistema
operativo host. Los contenedores se basan en el kernel del sistema operativo host (que puede
considerarse la fontanería del sistema operativo), tal como se muestra en el diagrama a
continuación.

Container Container

Apps Services Apps Services Apps Services

OS Kernel

Hardware
Aunque un contenedor comparte el kernel del sistema operativo host, no obtiene acceso sin
restricciones a dicho kernel. En su lugar, el contenedor obtiene una vista aislada (y, en
ocasiones, virtualizada) del sistema. Por ejemplo, un contenedor puede tener acceso a una
versión virtualizada del sistema de archivos y el registro, pero los cambios solo afectan al
contenedor y se descartan cuando se detiene. Para guardar los datos, el contenedor puede
montar una instancia de almacenamiento persistente, como Azure Disk o un recurso
compartido de archivos (incluido Azure Files ).

Un contenedor se basa en el kernel, pero el kernel no proporciona todas las API y servicios que
una aplicación necesita para ejecutarse; la mayoría de estos últimos se proporcionan a través
de archivos del sistema (bibliotecas) que se ejecutan sobre el kernel en modo de usuario. Dado
que un contenedor está aislado del entorno de modo de usuario del host, el contenedor
necesita su propia copia de estos archivos del sistema de modo de usuario, que se
empaquetan en algo conocido como imagen base. La imagen base cumple el papel de la capa
fundamental en la que se basa el contenedor y le proporciona los servicios de sistema
operativo que no ofrece el kernel. Sin embargo, mencionaremos más detalles acerca de las
imágenes de contenedor más adelante.

Contenedores frente a máquinas virtuales

A diferencia de un contenedor, una máquina virtual (VM) ejecuta un sistema operativo
completo, incluido su propio kernel, tal como se muestra en este diagrama.

Virtual Machine

Apps Services Apps Services

OS Kernel OS Kernel

Hardware

Los contenedores y las máquinas virtuales tienen sus usos particulares; de hecho, muchas
implementaciones de contenedores usan máquinas virtuales como sistema operativo host en
lugar de ejecutarse directamente en el hardware, sobre todo cuando se ejecutan contenedores
en la nube.

Para obtener más información sobre las similitudes y las diferencias de estas tecnologías
complementarias, consulte Contenedores frente a máquinas virtuales.
Imágenes del contenedor
Todos los contenedores se crean a partir de imágenes de contenedor. Una imagen de
contenedor es un conjunto de archivos organizados en una pila de capas que se hospeda en el
equipo local o en un registro de contenedor remoto. La imagen de contenedor está compuesta
por los archivos de sistema operativo del modo de usuario que son necesarios para admitir la
aplicación, los entornos de ejecución o las dependencias de la aplicación, y cualquier otro
archivo de configuración que la aplicación necesite para ejecutarse correctamente.

Microsoft ofrece varias imágenes (denominadas imágenes base) que puede usar como punto
de partida para crear su propia imagen de contenedor:

Windows: contiene el conjunto completo de API y servicios del sistema de Windows

(menos los roles de servidor).
Windows Server: contiene el conjunto completo de API y servicios del sistema de
Windows.
Windows Server Core: una imagen más pequeña que contiene un subconjunto de las API
de Windows Server; es decir, la versión completa de .NET Framework. También incluye la
mayoría de los roles de servidor, pero no todos (por ejemplo, servidor de fax no está
incluido).
Nano Server: referente a la imagen de Windows Server más pequeña, compatible con las
API de .NET Core y algunas funciones de servidor.

Como se mencionó anteriormente, las imágenes de contenedor se componen de una serie de

capas. Cada capa contiene un conjunto de archivos que, cuando se superponen, representan la
imagen de contenedor. Debido a la naturaleza por capas de los contenedores, no es necesario
que siempre tenga como destino una imagen base para compilar un contenedor de Windows.
En su lugar, puede elegir como destino otra imagen que ya contenga el marco de trabajo que
quiere. Por ejemplo, el equipo de .NET publica una imagen de .NET Core que incluye el
entorno de ejecución de .NET Core. Esto evita que los usuarios tengan que realizar nuevamente
el proceso de instalación de .NET Core. En su lugar, pueden volver a usar las capas de esta
imagen de contenedor. La imagen de .NET Core está basada en Nano Server.

Para obtener más información, consulte Imágenes base del contenedor.

Usuarios de los contenedores

Contenedores para desarrolladores

Los contenedores ayudan a los desarrolladores a crear y distribuir aplicaciones de mayor
calidad, más rápido. Con los contenedores, los desarrolladores pueden crear una imagen de
contenedor que se implementa en segundos de forma idéntica en todos los entornos. Los
contenedores actúan como un mecanismo sencillo para compartir código entre equipos y
arrancar un entorno de desarrollo sin afectar al sistema de archivos del host.

Los contenedores son portátiles y versátiles, pueden ejecutar aplicaciones escritas en cualquier
lenguaje y son compatibles con cualquier equipo que ejecute Windows 10, versión 1607 o
posterior, o Windows Server 2016 o posterior. Los desarrolladores pueden crear y probar
contenedores localmente en su equipo portátil o de escritorio y luego implementar esa misma
imagen de contenedor en la nube privada, la nube pública o el proveedor de servicios de su
empresa. La agilidad natural de los contenedores admite patrones de desarrollo de
aplicaciones modernas en entornos de nube virtualizados y a gran escala. La ventaja más útil
para los desarrolladores es quizás la capacidad de aislar el entorno para que la aplicación
siempre reciba la versión de las bibliotecas que se especifique, a fin de evitar conflictos con las
dependencias.

Contenedores para los profesionales de TI

Los contenedores ayudan a los administradores a crear una infraestructura que sea más fácil de
actualizar y mantener, y que el uso de los recursos de hardware sea más completo. Los
profesionales de TI pueden utilizar los contenedores para ofrecer entornos estandarizados para
su desarrollo, sus controles de calidad y sus equipos de producción. Mediante el uso de
contenedores, los administradores de sistemas abstraen las diferencias en las instalaciones de
sistemas operativos y la infraestructura subyacente.

También puede usar el modo interactivo de contenedores para ejecutar en el mismo sistema
las instancias en conflicto de una herramienta de línea de comandos.

Orquestación de contenedores
Los orquestadores son una parte fundamental de la infraestructura al configurar un entorno
basado en contenedores. Aunque puede administrar algunos contenedores manualmente
mediante Docker y Windows, las aplicaciones suelen usar cinco, diez o incluso cientos de
contenedores, donde se encuentran los orquestadores.

Los orquestadores de contenedor se crearon para ayudar a administrar contenedores a escala

y en producción. Los orquestadores proporcionan las funcionalidades para:

Los orquestadores le ayudan a aumentar el tamaño de las aplicaciones en contenedores a

escala, lo que proporciona funcionalidades para:

Implementación a escala
Programación de cargas de trabajo
 Supervisión de estado
Conmutación por error cuando se produce un error en un nodo
Escalado o reducción vertical
Funciones de red
Detección de servicios
Coordinación de las actualizaciones de aplicaciones
Afinidad de nodos de clúster

Hay muchos orquestadores diferentes que puede utilizar con los contenedores de Windows.
Estas son las opciones que proporciona Microsoft:

Azure Kubernetes Service (AKS): use un servicio administrado de Azure Kubernetes.

Azure Kubernetes Service (AKS) en Azure Stack HCI: use Azure Kubernetes Service en el
entorno local.

Prueba de contenedores en Windows

Para empezar a trabajar con contenedores en Windows Server o Windows 10, consulte lo
siguiente:

Introducción: configuración del entorno para los contenedores

Para obtener ayuda a la hora de decidir qué servicios de Azure son adecuados para su
escenario, consulte Azure Container Services y Selección de los servicios de Azure que se
usarán para hospedar la aplicación.

Recursos
Para ver los recursos a fin de usar Windows Server:

Para ver las incidencias actuales y las actualizaciones de características planeadas,

consulte el repositorio de GitHub de contenedores de Windows .

Consulte nuestro blog: blog de contenedores de Windows .

Para ponerse en contacto con el equipo encargado de los contenedores de

Windows Server, envíe un correo electrónico a Clientes de contenedores de Windows.
Contenedores frente a máquinas
virtuales
Artículo • 05/02/2025

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

En este tema se describen algunas de las principales similitudes y diferencias entre

contenedores y máquinas virtuales (VM) y cuándo es posible que desee usar cada una.
Los contenedores y las máquinas virtuales tienen sus usos, de hecho, muchas
implementaciones de contenedores usan máquinas virtuales como sistema operativo
host en lugar de ejecutarse directamente en el hardware, especialmente cuando se
ejecutan contenedores en la nube.

Para obtener información general sobre los contenedores, consulte Windows y

contenedores.

Arquitectura de contenedor
Un contenedor es un silo aislado y ligero para ejecutar una aplicación en el sistema
operativo host. Los contenedores se basan en el kernel del sistema operativo host (que
se puede considerar como la fontanería enterrada del sistema operativo) y contienen
solo aplicaciones y algunas API y servicios ligeros del sistema operativo que se ejecutan
en modo de usuario, como se muestra en este diagrama.

diagrama de arquitectura de
Container Container

Apps Services Apps Services Apps Services

OS Kernel

Hardware

Arquitectura de máquina virtual

A diferencia de los contenedores, las máquinas virtuales ejecutan un sistema operativo
completo, incluido su propio kernel, como se muestra en este diagrama.
diagrama de arquitectura de
Virtual Machine

Apps Services Apps Services

OS Kernel OS Kernel

Hardware

Contenedores frente a máquinas virtuales

En la tabla siguiente se muestran algunas de las similitudes y diferencias de estas
tecnologías complementarias.

ﾉ Expandir tabla

Característica Máquina virtual Contenedor

Aislamiento Proporciona aislamiento completo Normalmente proporciona

del sistema operativo host y de aislamiento ligero del host y otros
otras máquinas virtuales. Esto contenedores, pero no proporciona
resulta útil cuando un límite de un límite de seguridad tan sólido
seguridad fuerte es crítico, como como una máquina virtual. (Puede
hospedar aplicaciones de empresas aumentar la seguridad si usa el modo
competidoras en el mismo servidor de aislamiento de Hyper-V para aislar
o clúster. cada contenedor en una máquina
virtual ligera).

Sistema operativo Ejecuta un sistema operativo Ejecuta la parte del modo de usuario
completo, incluido el kernel, lo que de un sistema operativo y se puede
requiere más recursos del sistema adaptar para contener solo los
(CPU, memoria y almacenamiento). servicios necesarios para la
aplicación, con menos recursos del
sistema.

Compatibilidad de Ejecuta casi cualquier sistema Se ejecuta en la misma versión del

invitados operativo dentro de la máquina sistema operativo que el host (el
virtual. aislamiento de Hyper-V le permite
ejecutar versiones anteriores del
mismo sistema operativo en un
entorno de máquina virtual ligera).

Despliegue Implementar máquinas virtuales Implementar contenedores

individuales mediante Windows individuales mediante Docker a través
Admin Center o Hyper-V Manager; de la línea de comandos; implemente
Característica Máquina virtual Contenedor

implemente varias máquinas varios contenedores mediante un

virtuales mediante PowerShell o orquestador como Azure Kubernetes
System Center Virtual Machine Service.
Manager.

Actualizaciones y Descargue e instale las Actualizar o mejorar los archivos del

mejoras del actualizaciones del sistema sistema operativo dentro de un
sistema operativo operativo en cada máquina virtual. contenedor es lo mismo:
La instalación de una nueva versión
del sistema operativo requiere 1. Edite el archivo de compilación
actualizar o, a menudo, de la imagen de contenedor
simplemente crear una máquina (conocido como Dockerfile)
virtual completamente nueva. Esto para que apunte a la versión
puede llevar mucho tiempo, más reciente de la imagen base
especialmente si tiene muchas de Windows.
máquinas virtuales. 2. Vuelva a generar la imagen de
contenedor con esta nueva
imagen base.
3. Sube la imagen del contenedor
a tu registro de contenedores.
4. Vuelva a implementar
mediante un orquestador.
El orquestador proporciona
una automatización eficaz para
hacerlo a escala. Para más
información, consulte Tutorial:
Actualización de una aplicación
en Azure Kubernetes Service.

Almacenamiento Use un disco duro virtual (VHD) Use Azure Disks para el
persistente para el almacenamiento local para almacenamiento local para un solo
una sola máquina virtual o un nodo o Azure Files (recursos
recurso compartido de archivos compartidos SMB) para el
SMB para el almacenamiento almacenamiento compartido por
compartido por varios servidores. varios nodos o servidores.

Equilibrio de carga El equilibrio de carga de las Los contenedores no se mueven; en

máquinas virtuales mueve las VMs su lugar, un orquestador puede
en ejecución a otros servidores de iniciar o detener automáticamente los
un clúster de conmutación por contenedores en los nodos del
error. clúster para administrar los cambios
en la carga y la disponibilidad.

Tolerancia a Las máquinas virtuales pueden Si se produce un error en un nodo de

errores conmutarse a otro servidor de un clúster, el orquestador vuelve a crear
clúster, reiniciando su sistema rápidamente los contenedores que se
operativo en el nuevo servidor. ejecutan en él en otro nodo de
clúster.
 Característica Máquina virtual Contenedor

Gestión de redes Usa adaptadores de red virtual. Usa una vista aislada de un
adaptador de red virtual, lo que
proporciona un poco menos
virtualización: el firewall del host se
comparte con contenedores, al
tiempo que usa menos recursos. Para
más información, vea Redes de
contenedores en Windows.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Requisitos del contenedor de Windows
Artículo • 05/02/2025

Se aplica a: Windows Server 2025, Windows Server 2022, Windows Server 2019,
Windows Server 2016; Azure Stack HCI, versiones 21H2 y 20H2, Windows 10,
Windows 11

En esta guía se enumeran los requisitos de un host de contenedor de Windows.

Requisitos del sistema operativo

La característica contenedor de Windows está disponible en Windows Server 2016
y versiones posteriores, Windows 10 Professional y Enterprise Edition (versión 1607
y posteriores) y Windows 11 Pro y Enterprise.
El rol Hyper-V se debe instalar antes de ejecutar el aislamiento de Hyper-V.
Los hosts de contenedor de Windows Server deben tener Windows instalado en c:.
Esta restricción no se aplica si solo se implementarán Hyper-V contenedores
aislados.

Hosts de contenedor virtualizados

Si va a ejecutar un host de contenedores de Windows desde una máquina virtual Hyper-
V y también va a hospedar aislamiento de Hyper-V, debe habilitar la virtualización
anidada. La virtualización anidada tiene los siguientes requisitos:

Al menos 4 GB de RAM disponible para el host de Hyper-V virtualizado.

Procesador con Intel VT-x (esta característica está disponible actualmente para
procesadores Intel y AMD).
La máquina virtual del host de contenedor también necesita al menos dos
procesadores virtuales.

Requisitos de memoria
Puede configurar restricciones en la memoria disponible para los contenedores a través
de controles de recursos o sobrecargando un host de contenedor. La cantidad mínima
de memoria necesaria para iniciar un contenedor y ejecutar comandos básicos
( ipconfig , dir , etc.) se enumeran a continuación.
 ７ Nota

Estos valores no tienen en cuenta el uso compartido de recursos entre

contenedores o requisitos de la aplicación que se ejecuta en el contenedor. Por
ejemplo, un host con 512 MB de memoria libre puede ejecutar varios contenedores
de Server Core bajo aislamiento Hyper-V porque los contenedores comparten
recursos.

Consulte también
directiva de soporte técnico para contenedores de Windows y Docker en escenarios
locales

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Preguntas más frecuentes sobre
los contenedores
Preguntas más frecuentes

¿Tiene alguna pregunta acerca de los contenedores de Windows Server? Consulte si se

ha respondido en la lista siguiente.

¿Cuál es la diferencia entre los

contenedores de Windows Server y
Linux?
Los contenedores de Windows Server y Linux implementan tecnologías similares dentro
de su kernel y su sistema operativo base. La diferencia reside en la plataforma y las
cargas de trabajo que se ejecutan dentro de los contenedores.

Cuando un cliente usa contenedores de Windows Server, puede integrarlos con las
tecnologías de Windows existentes, como. NET, ASP.NET y PowerShell.

¿Cuáles son los requisitos previos para

ejecutar contenedores en Windows?
Los contenedores se introdujeron en la plataforma con Windows Server 2016. Para usar
contenedores, se necesitarán Windows Server 2016, la actualización de Windows 10
Anniversary (versión 1607) o posterior, o bien Windows 10 IoT Enterprise o posterior.
Lee los Requisitos del sistema para obtener más información.

¿Cuáles de los sistemas operativos

Windows se admiten en Kubernetes?
La compatibilidad con contenedores de Windows depende de la plataforma de
Kubernetes en la que se ejecute. Azure Kubernetes Service (AKS), AKS en Azure Stack
HCI y Windows Server admiten los nodos de Windows de Windows Server 2019 y
Windows Server 2022. Azure Kubernetes Service Edge Essentials admite Windows
Server 2019, Windows Server 2022 y Windows 10/11 Enterprise o Pro. Para consultar la
compatibilidad de versiones de contenedor de Windows, consulte Compatibilidad con
versiones de contenedores de Windows.

¿Cómo se aplica una revisión a los

nodos de Windows?
Los nodos de Windows Server en AKS y AKS en Azure Stack HCl y Windows Server
deben actualizarse para obtener las actualizaciones y correcciones de revisión más
recientes. Las actualizaciones de Windows no están habilitadas en los nodos de
Windows de esos servicios. Sin embargo, ambos servicios proporcionan mecanismos
para actualizar las imágenes de nodo de Windows.

¿Pueden usar gMSA los contenedores

de Windows Server?
Sí, gMSA es compatible con los nodos de trabajo de Windows unidos a un dominio.
Para obtener más información sobre el uso de gMSA con contenedores de Windows,
consulte Preparación de nodos de Windows para gMSA.

¿Qué son WCOW y LCOW?

WCOW es la abreviatura de "Windows containers on Windows" (Contenedores de
Windows en Windows). LCOW es la abreviatura de "Linux containers on Windows"
(Contenedores de Linux en Windows).

¿Cómo se concede la licencia de

contenedores? ¿Hay un límite en el
número de contenedores que puedo
ejecutar?
En el CLUF de la imagen de contenedor de Windows se describe un uso que depende
de un usuario que tiene un sistema operativo host con licencia válida. El número de
contenedores que puede ejecutar un usuario depende de la edición del sistema
operativo host y del modo de aislamiento con el que se ejecuta un contenedor, así
como de si estos contenedores se ejecutan con fines de desarrollo y pruebas o en
producción.
 ﾉ Expandir tabla

Sistema operativo Límite de contenedor Límite de contenedor

host aislado de proceso aislado de Hyper-V

Windows Server Sin límite 2

Standard

Windows Server Sin límite Sin límite

Datacenter

Windows Pro y Sin límite (solo con fines de Sin límite (solo con fines de
Enterprise prueba o desarrollo) prueba o desarrollo)

Windows 10 Sin límite* Sin límite*

IoT Core

Windows IoT Sin límite* Sin límite*

Enterprise

El uso de imágenes de contenedor de Windows Server se determina mediante la lectura

del número de invitados de virtualización admitidos para esa edición.

７ Nota

*El uso de contenedores en producción en una edición IoT de Windows depende

de si has aceptado los términos de uso comerciales de Microsoft para imágenes de
tiempo de ejecución de Windows 10 Core o la licencia de dispositivo de
Windows 10 IoT Enterprise ("Contrato de Windows IoT Commercial"). Se aplican
términos y restricciones adicionales en los contratos de IoT Windows Commercial al
uso de la imagen de contenedor en un entorno de producción. Lee el CLUF de la
imagen de contenedor para comprender exactamente lo que se permite y lo que
no.

Como desarrollador, ¿tengo que volver

a escribir la aplicación para cada tipo de
contenedor?
No. Las imágenes de contenedores de Windows son comunes para los contenedores de
Windows Server y el aislamiento de Hyper-V. La elección del tipo de contenedor se
realiza cuando se inicia el contenedor. Desde la perspectiva del desarrollador, los
contenedores de Windows Server y el aislamiento de Hyper-V son dos versiones de lo
mismo. Ofrecen la misma experiencia de desarrollo, programación y administración, son
abiertos y extensibles e incluyen el mismo nivel de integración y compatibilidad con
Docker.

Un desarrollador puede crear una imagen de contenedor con un contenedor de

Windows Server e implementarla en el aislamiento de Hyper-V o viceversa, sin ningún
cambio aparte de especificar la marca de tiempo de ejecución adecuada.

Los contenedores de Windows Server ofrecen mayor densidad y rendimiento para

cuando la velocidad es clave, como un menor tiempo de spin up y un rendimiento en
tiempo de ejecución más rápido en comparación con las configuraciones anidadas. El
aislamiento de Hyper-V, como su nombre indica, ofrece mayor aislamiento,
garantizando que el código que se ejecuta en un contenedor no se pueda poner en
peligro ni afectar negativamente al sistema operativo host u otros contenedores que se
ejecutan en el mismo host. Esto es útil en los escenarios de varios inquilinos con
requisitos para el hospedaje de código no seguro, entre los que se incluyen las
aplicaciones de SaaS y el hospedaje de procesos.

¿Puedo ejecutar contenedores de

Windows en modo aislado de proceso
en Windows 10?
A partir de la actualización de Windows 10 de octubre de 2018, puedes ejecutar un
contenedor de Windows con aislamiento de procesos, pero primero debes solicitar
directamente el aislamiento de procesos con la marca --isolation=process al ejecutar
los contenedores con docker run . El aislamiento de procesos es compatible con
Windows 10 Pro (o más reciente), Windows 10 Enterprise (o más reciente), Windows
10 IoT Core (o más reciente) y Windows 10 IoT Enterprise (o más reciente).

Si quieres ejecutar los contenedores de Windows de esta manera, debes asegurarte de

que el host ejecuta Windows 10 compilación 17763 o versión posterior y de que tiene
una versión de Docker con el motor 18.09 o más reciente.

２ Advertencia
 Aparte de los hosts de IoT Core e IoT Enterprise (después de aceptar los términos y
restricciones adicionales), esta característica solo está pensada para el desarrollo y
pruebas. Debes seguir usando Windows Server como host para las
implementaciones de producción. Con esta característica, también debe asegurarse
de que las etiquetas de la versión y el número de compilación del contenedor y del
host coinciden; de lo contrario, el contenedor puede no iniciarse o mostrar un
comportamiento indefinido.

¿Cómo hago que mis imágenes de

contenedor estén disponibles en
máquinas con separación de aire?
Las imágenes base del contenedor de Windows contienen artefactos cuya distribución
está restringida por licencia. Al compilar en estas imágenes e insertarlas en un registro
privado o público, observarás que la capa base nunca se inserta. En su lugar, usamos el
concepto de una capa externa que apunta a la capa base real que reside en el
almacenamiento en la nube de Azure.

Esto puede complicar las cosas cuando tienes una máquina con separación de aire que
solo puede extraer imágenes de la dirección del registro de contenedor privado. En este
caso, los intentos de seguir la capa externa para obtener la imagen base no funcionarán.
Para reemplazar el comportamiento de la capa externa, puedes usar la marca --allow-
nondistributable-artifacts en el demonio de Docker.

） Importante

El uso de esta marca no excluirá la obligación de cumplir los términos de la licencia

de imagen base del contenedor de Windows; no debes publicar el contenido de
Windows para la redistribución pública o de terceros. Se permite el uso dentro de
su propio entorno.

Comentario adicional
¿Quites agregar algo a las preguntas más frecuentes? Abre un nuevo problema de
comentarios en la sección de comentarios o configura una solicitud de incorporación de
cambios para esta página con GitHub.
Comentarios
¿Le ha resultado útil esta página?  Sí  No
Introducción: Preparar Windows para
contenedores
Artículo • 09/04/2025

En este inicio rápido, verá varios enfoques para crear un entorno listo para contenedores en
Windows y Windows Server. También se instala un entorno de ejecución de contenedor.

Los contenedores proporcionan un entorno ligero y aislado que facilita el desarrollo, la

implementación y la administración de las aplicaciones. Para poder usar un contenedor, debe
configurar un entorno de ejecución adecuado.

Este inicio rápido se aplica a Windows Server 2025, Windows Server 2022, Windows Server
2019, Windows Server 2016, Windows 11 y Windows 10.

Prerrequisitos
El entorno que necesita para esta introducción rápida depende de su sistema operativo (SO).

Windows 10 y Windows 11
Para ejecutar contenedores en Windows 10 o Windows 11, necesita el siguiente entorno:

Un sistema de equipo físico que ejecuta Windows 11 o Windows 10 con la actualización

de aniversario (versión 1607) o posterior
Edición Professional o Enterprise
Hyper-V habilitado

Los contenedores de Windows Server utilizan aislamiento Hyper-V por defecto en Windows 10
y Windows 11 para proporcionar a los desarrolladores la misma versión y configuración del
kernel utilizada en producción. Para obtener más información sobre el aislamiento de Hyper-V,
consulte Modos de aislamiento.

Windows Server
Para ejecutar contenedores de Windows Server en entornos de desarrollo, necesita un servidor
físico o una máquina virtual (VM) que ejecute Windows Server.

Para realizar pruebas, puede descargar una copia de evaluación de Windows Server 2025 o
una versión preliminar del Programa Windows Server Insider .
Elección de un método
El enfoque que se toma para construir un entorno listo para contenedores depende del
sistema operativo. También depende de otros factores, como la complejidad y el costo de la
implementación.

Windows 10 y Windows 11
En las ediciones Windows 10 y Windows 11 Professional y Enterprise, puedes usar Docker
Desktop para ejecutar aplicaciones en contenedores. Docker Desktop proporciona una manera
de administrar contenedores, aplicaciones e imágenes.

Windows Server
Para muchas aplicaciones y patrones de orquestación, debe compilar e implementar sus
propias máquinas virtuales personalizadas. Con la transición de compatibilidad para el
entorno de ejecución del contenedor de Windows a Mirantis, el entorno de ejecución del
contenedor ya no se proporciona como parte de una oferta de máquina virtual de
Marketplace. En el resto de esta guía se muestra cómo compilar una máquina virtual para
Azure con el entorno de ejecución del contenedor instalado y listo para usarse.

Azure sigue ofreciendo una experiencia completa y totalmente administrada de un extremo a

otro a través de Azure Kubernetes Service (AKS) tanto en la nube como en el entorno local.
AKS y Azure Kubernetes Service en Azure Stack HCI son servicios totalmente administrados con
una sobrecarga de administración menor que las implementaciones personalizadas. La
compatibilidad con el entorno de ejecución del contenedor se incluye en los servicios AKS y
Azure Kubernetes Service en Azure Stack HCI en su suscripción de Azure.

Implementación de un contenedor de Windows Server en un clúster de Azure Kubernetes

Service (AKS) mediante la CLI de Azure
Configuración de un host de Azure Kubernetes Service en Azure Local y Windows Server
e implementación de un clúster de cargas de trabajo mediante PowerShell

También existen otras opciones para hacer que la experiencia de construcción de máquinas
virtuales de Azure listas para contenedores sea lo más fluida posible. Dos ejemplos son Azure
VM Image Builder y extensiones de script personalizadas. Al comparar opciones, tenga en
cuenta los siguientes puntos. Es necesario que su organización decida qué aspecto optimizar.

¿Qué tan complejo es implementarlo?

¿Cuál es el costo?
¿Cómo afecta a mi carga de trabajo en producción?
En las subsecciones siguientes se describen las ventajas y desventajas de VM Image Builder y
las extensiones de script personalizadas, y se muestra cómo empezar.

Generador de imágenes de máquina virtual

La ventaja de usar VM Image Builder es que la configuración se realiza durante un tiempo de

compilación y no tiene ningún efecto en la carga de trabajo en tiempo de ejecución. Cuando el
conjunto de escalado de máquinas virtuales crea una instancia de una nueva máquina virtual a
partir de la imagen personalizada, la imagen ya está preparada y está lista para ejecutar
contenedores.

Sin embargo, VM Image Builder puede ser más complejo de implementar que las extensiones
de script y hay más pasos implicados. Además, el servicio Vm Image Builder es gratuito, pero
debe pagar por el uso de proceso, almacenamiento y redes asociado al proceso de
compilación. Para obtener más información, consulte Costos.

Para obtener un procedimiento detallado y paso a paso para crear su propia imagen de
máquina virtual Windows Server, consulte Crear una máquina virtual Windows utilizando Azure
VM Image Builder. Para instalar el entorno de ejecución de contenedor que prefiera, use los
scripts de PowerShell de esta guía.

 Sugerencia

Asegúrese de almacenar en caché las imágenes de contenedor que planea usar

localmente en la máquina virtual. Esta práctica ayuda a mejorar el tiempo de inicio del
contenedor después de la implementación. Para ver los scripts que ayudan con esta tarea,
consulte Windows Server, más adelante en este inicio rápido.

Extensiones de script personalizado

Las extensiones de script personalizadas son más rápidas de implementar que una solución vm
Image Builder. El único costo asociado a las extensiones es el precio de almacenar el script en
Azure o GitHub. Sin embargo, el script solo se puede ejecutar después de aprovisionar una
máquina virtual. Como resultado, el presupuesto debe incluir tiempo adicional para la
preparación de la máquina virtual en el momento de ampliación.

Con los scripts que se ofrecen en esta guía, configure los conjuntos de escalado de máquinas
virtuales para instalar el entorno de ejecución del contenedor que prefiera después del
aprovisionamiento. Para usar una extensión de script personalizada para automatizar el
proceso de instalación de aplicaciones en máquinas virtuales de Azure, consulte Tutorial:
Instalación de aplicaciones en virtual Machine Scale Sets con la CLI de Azure.
Instalación del entorno de ejecución del
contenedor
El procedimiento que se usa para instalar un entorno de ejecución de contenedor depende del
sistema operativo.

Windows 10 y Windows 11
Para instalar Docker en las ediciones Windows 10 o Windows 11 Professional y Enterprise, siga
estos pasos:

1. Descargue e instale Docker Desktop y cree una cuenta de Docker si aún no tiene una.
Puede crear una cuenta gratuita de Docker para usuarios personales o de pequeñas
empresas. Sin embargo, para empresas más grandes, hay una tarifa mensual. Para
obtener información detallada, consulte la documentación de Docker .

2. Durante la instalación, establezca el tipo de contenedor predeterminado en

Contenedores de Windows. Para cambiar el tipo una vez finalizada la instalación, realice
uno de los pasos siguientes:

Ejecute el siguiente comando en una ventana de PowerShell.

Consola

& $Env:ProgramFiles\Docker\Docker\DockerCli.exe -SwitchDaemon

Use el elemento de Docker en la bandeja del sistema de Windows, como se muestra

en la captura de pantalla siguiente:
Centro de Administración de Windows (Windows Admin
Center)
Para usar Windows Admin Center para configurar una máquina Windows Server como host de
contenedor, siga estos pasos:

1. En Windows Admin Center, asegúrese de que tiene instalada la extensión Containers más
reciente. Para obtener más información sobre cómo instalar y configurar extensiones,
consulte la documentación de Windows Admin Center.

2. Abra la máquina Windows Server que desea configurar.

3. En el panel lateral, en Herramientas, seleccione Contenedores.

4. Seleccione Instalar.
 Windows Admin Center inicia la configuración de Windows Server y Docker en segundo
plano.

5. Una vez completado el proceso, actualice la página para ver otra funcionalidad de la
extensión Containers.

Windows Server
Para ejecutar un contenedor de Windows, debe tener un entorno de ejecución de contenedor
compatible disponible en la máquina. Los entornos de ejecución admitidos actualmente en
Windows son Moby , Mirantis Container Runtime y containerd .

En esta sección se muestra cómo instalar cada tiempo de ejecución en una máquina virtual que
ejecuta Windows Server. En el caso de los entornos de ejecución de Moby y contenedores,
puede usar scripts de PowerShell para completar la instalación en unos pocos pasos.

Docker CE/Moby
 Docker Community Edition (Docker CE) proporciona un entorno de tiempo de ejecución
estándar para contenedores. El entorno ofrece una API común y una interfaz de línea de
comandos. La comunidad de código abierto administra el marco y los componentes de
Docker CE como parte del proyecto Moby .

Para empezar a trabajar con Docker en Windows Server, use el siguiente comando para
ejecutar el script de PowerShellinstall-docker-ce.ps1 . Este script configura el entorno
para habilitar las características del sistema operativo relacionadas con el contenedor. El
script también instala el entorno de ejecución de Docker.

PowerShell

Invoke-WebRequest -UseBasicParsing
"https://raw.githubusercontent.com/microsoft/Windows-
Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1" -o
install-docker-ce.ps1
.\install-docker-ce.ps1

Para obtener información detallada sobre cómo configurar el motor de Docker, consulte
Motor de Docker en Windows.

Pasos siguientes

７ Nota

Para obtener instrucciones del equipo de productos contenedores de Windows, consulte

el repositorio contenedores de Windows en GitHub.

Ahora que el entorno está configurado correctamente, consulte cómo ejecutar un contenedor.

Ejecutar su primer contenedor

Introducción: Ejecución del primer
contenedor de Windows
10/06/2025

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

En este artículo se muestra cómo ejecutar el primer contenedor de Windows, después de

configurar el entorno como se describe en Introducción: Preparación de Windows para
contenedores. La ejecución de un contenedor implica dos pasos generales:

Descargar una imagen base. Con los contenedores, el proceso de descarga de una
imagen base se conoce como una operación de extracción. La imagen base proporciona
una capa fundamental de servicios de sistema operativo al contenedor.
Crear y ejecutar una imagen de contenedor basada en la imagen base.

Extracción de una imagen base de contenedor

Todos los contenedores se crean a partir de imágenes de contenedor. Microsoft ofrece varias
imágenes de inicio, llamadas imágenes base, entre las que elegir. Para obtener más
información, consulte Imágenes base de contenedor.

Puede usar el siguiente procedimiento para extraer la imagen base ligera de Nano Server o, en
otras palabras, para descargar e instalar esa imagen.

1. Abra una ventana de consola, como el Símbolo del sistema integrado, PowerShell o
Windows Terminal .

2. Ejecute el siguiente comando para descargar e instalar la imagen base:

Consola

docker pull mcr.microsoft.com/windows/nanoserver:ltsc2022

Mientras espera, lea los términos de la licencia complementaria para la imagen.

Si Docker no se inicia al intentar descargar la imagen, es posible que no se pueda acceder

al demonio de Docker. Para resolver este problema, reinicie el servicio Docker.

 Sugerencia
 Si ve el mensaje de error "No hay manifiesto coincidente para linux/amd64 en las
entradas de la lista de manifiestos", Docker podría configurarse para ejecutar
contenedores de Linux en lugar de contenedores de Windows. Para cambiar a
contenedores de Windows en Docker, siga uno de los pasos siguientes:

En la bandeja del sistema de Windows, haga clic con el botón derecho en el

icono de Docker y seleccione Cambiar a contenedores de Windows.
En un intérprete de comandos, ejecute &
$Env:ProgramFiles\Docker\Docker\DockerCli.exe -SwitchDaemon .

3. Compruebe la existencia de la imagen en el sistema consultando el repositorio de

imágenes de Docker local. Para realizar esta comprobación, ejecute el docker images
comando , que devuelve una lista de imágenes instaladas.

Este es un ejemplo de salida de ese comando, que muestra la imagen de Nano Server.

Consola

REPOSITORY TAG IMAGE ID CREATED

SIZE
mcr.microsoft.com/windows/nanoserver ltsc2022 4f0ead5b1b67 6 days ago
296MB

Ejecución de un contenedor de Windows

En este ejemplo básico, crea e implementa una imagen de contenedor de Hola Mundo. Para
obtener la mejor experiencia, ejecute los comandos de esta sección en una terminal con
privilegios elevados. Pero no use el entorno de scripting integrado (ISE) de Windows
PowerShell. No es adecuado para sesiones interactivas con contenedores; los contenedores
parecen dejar de responder.

1. Inicie un contenedor con una sesión interactiva a partir de la imagen nanoserver

ingresando el siguiente comando en el terminal:

Consola

docker run -it mcr.microsoft.com/windows/nanoserver:ltsc2022 cmd.exe

Cuando el contenedor se inicia, la ventana de la consola cambia de contexto al

contenedor.
2. Dentro del contenedor, ejecute los siguientes comandos. El primer comando crea un
archivo de texto que contiene la frase "Hello World!" El segundo comando sale del
contenedor.

Símbolo del sistema de Windows

echo "Hello World!" > Hello.txt

exit

3. Ejecute el docker ps comando para obtener el identificador de contenedor del

contenedor que acaba de salir:

Consola

docker ps -a

4. Cree una nueva imagen helloworld que incluya los cambios realizados en el primer
contenedor que ejecutó. Para ello, ejecute el docker commit comando y reemplace
<container-ID> por el identificador del contenedor:

Consola

docker commit <container-ID> helloworld

Ahora tiene una imagen personalizada que contiene el archivo Hello.txt. Puede usar el
docker images comando para ver la nueva imagen.

Consola

docker images

Este es un ejemplo de la salida:

Consola

REPOSITORY TAG IMAGE ID CREATED

SIZE
helloworld latest 81013d6b73ae 25 seconds
ago 299MB
mcr.microsoft.com/windows/nanoserver ltsc2022 4f0ead5b1b67 6 days ago
296MB

5. Ejecute el nuevo contenedor mediante el docker run comando con la --rm opción .
Cuando se usa esta opción, Docker quita automáticamente el contenedor cuando el
 comando, cmd.exe en este caso, se detiene.

Consola

docker run --rm helloworld cmd.exe /s /c type Hello.txt

Docker crea un contenedor a partir de la helloworld imagen e inicia una instancia de

cmd.exe en el contenedor. El cmd.exe proceso lee el archivo Hello.txt y escribe el

contenido en la ventana de la consola. Como último paso, Docker detiene y quita el

contenedor.

Ejecución de un contenedor de Windows mediante

Windows Admin Center
Puedes usar Windows Admin Center para ejecutar los contenedores localmente. En concreto,
puedes usar la extensión Containers de Windows Admin Center para este propósito.

Visualización de imágenes de contenedor

1. Abra el host de contenedor que desea administrar.

2. En el panel Herramientas , seleccione Contenedores para abrir la extensión Containers.

3. En el panel principal, en Host de contenedor, seleccione Imágenes.

Descargar una imagen de contenedor

1. Si el host no tiene una imagen de contenedor base, seleccione Descargar para abrir el
cuadro de diálogo Descargar imagen de contenedor.

2. En el cuadro de diálogo Obtener imagen de contenedor, escriba la dirección URL de la

imagen y la etiqueta.

Si no está seguro de qué imagen se va a extraer, expanda Imágenes comunes de

Windows para ver una lista de imágenes comunes de Microsoft.
 Si desea extraer una imagen de un repositorio privado, expanda Autenticación del
Registro para escribir las credenciales.

3. Seleccione Extraer. Windows Admin Center inicia el proceso de extracción en el host del
contenedor. Una vez completada la descarga, verá la nueva imagen en la pestaña
Imágenes .

Ejecutar una imagen

1. Seleccione la imagen que desea ejecutar y, a continuación, seleccione Ejecutar. Se abre el
cuadro de diálogo Ejecutar imagen .
2. En el cuadro de diálogo Ejecutar imagen , escriba información para configurar el
contenedor, como el nombre del contenedor, el tipo de aislamiento, los puertos que se
van a publicar y la asignación de memoria y CPU. También puede agregar opciones para
anexar al docker run comando, como -v para especificar un volumen persistente. Para
 obtener más información sobre los parámetros disponibles docker run , vea docker
container run .

3. Seleccione Ejecutar. La pestaña Contenedores muestra el estado de los contenedores en

ejecución.

Paso siguiente
Vea cómo incluir en contenedores una aplicación de ejemplo
Contenerizar una aplicación de .NET
Core
Artículo • 05/02/2025

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

En este tema se describe cómo empaquetar una aplicación de .NET de ejemplo existente
para la implementación como un contenedor de Windows, después de configurar el
entorno, tal como se describe en Introducción a Windows: Preparación de Windows
para contenedoresy ejecución del primer contenedor como se describe en Ejecutar el
primer contenedor de Windows.

También necesitará el sistema de control de código fuente de Git instalado en el equipo.

Para instalarlo, visite Git .

Clonación del código de ejemplo desde GitHub

Todo el código fuente de ejemplo de contenedor se mantiene en el repositorio git de
Virtualization-Documentation en una carpeta denominada windows-container-
samples .

1. Abra una sesión de PowerShell y cambie los directorios a la carpeta en la que

desea almacenar este repositorio. (Otros tipos de ventanas de la línea de
comandos también funcionan, pero nuestros comandos de ejemplo utilizan
PowerShell).

2. Clona el repositorio en el directorio de trabajo actual.

PowerShell

git clone https://github.com/MicrosoftDocs/Virtualization-

Documentation.git

3. Vaya al directorio de ejemplo que se encuentra en Virtualization-

Documentation\windows-container-samples\asp-net-getting-started y cree un

Dockerfile con los siguientes comandos.

Un dockerfile es como un archivo Make, es una lista de instrucciones que indican

al motor de contenedor cómo compilar la imagen de contenedor.
 Powershell

# Navigate into the sample directory

Set-Location -Path Virtualization-Documentation\windows-container-
samples\asp-net-getting-started

# Create the Dockerfile for our project

New-Item -Name Dockerfile -ItemType file

Escritura de Dockerfile
Abra el Archivo Dockerfile que acaba de crear con el editor de texto que desee y
agregue el siguiente contenido:

Dockerfile

FROM mcr.microsoft.com/dotnet/core/sdk:2.1 AS build-env

WORKDIR /app

COPY *.csproj ./
RUN dotnet restore

COPY . ./
RUN dotnet publish -c Release -o out

FROM mcr.microsoft.com/dotnet/core/aspnet:2.1
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "asp-net-getting-started.dll"]

Vamos a desglosarlo de línea a línea y explicar lo que hace cada una de las
instrucciones.

Dockerfile

FROM mcr.microsoft.com/dotnet/core/sdk:2.1 AS build-env

WORKDIR /app

El primer grupo de líneas declara la imagen base que se usará para crear el contenedor.
Si el sistema local aún no tiene esta imagen, Docker intentará capturarla
automáticamente. El mcr.microsoft.com/dotnet/core/sdk:2.1 viene empaquetado con el
SDK de .NET Core 2.1 instalado, por lo que está preparado para compilar proyectos de
ASP.NET Core dirigidos a la versión 2.1. La siguiente instrucción cambia el directorio de
trabajo de nuestro contenedor para que sea /app , por lo que todos los comandos
siguientes a este se ejecutan en este contexto.
 Dockerfile

COPY *.csproj ./
RUN dotnet restore

A continuación, estas instrucciones copian los archivos .csproj hacia el directorio /app
del contenedor build-env . Después de copiar este archivo, .NET leerá de él y, a
continuación, extraerá y capturará todas las dependencias y herramientas necesarias
para nuestro proyecto.

Dockerfile

COPY . ./
RUN dotnet publish -c Release -o out

Una vez que .NET ha extraído todas las dependencias en el contenedor de build-env , la
siguiente instrucción copia todos los archivos de origen del proyecto en el contenedor.
A continuación, le decimos a .NET que publique nuestra aplicación con una
configuración de versión y especifique la ruta de salida.

La compilación debería tener éxito. Ahora debemos crear la imagen final.

 Sugerencia

En este inicio rápido se compila un proyecto de .NET Core a partir del origen. Al
crear imágenes de contenedor, se recomienda incluir solo la carga de producción y
sus dependencias en la imagen de contenedor. No queremos que el SDK de .NET
Core se incluya en nuestra imagen final porque solo necesitamos el entorno de
ejecución de .NET Core, por lo que el dockerfile se escribe para usar un contenedor
temporal que se empaqueta con el SDK llamado build-env para compilar la
aplicación.

Dockerfile

FROM mcr.microsoft.com/dotnet/core/aspnet:2.1
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "asp-net-getting-started.dll"]

Dado que la aplicación es ASP.NET, especificamos una imagen con este tiempo de
ejecución incluido. A continuación, copiamos todos los archivos del directorio de salida
de nuestro contenedor temporal en nuestro contenedor final. Configuramos el
contenedor para que se ejecute con nuestra nueva aplicación como punto de entrada
cuando se inicia el contenedor.

Se ha escrito el Dockerfile para realizar una compilación de varias fases. Cuando se

ejecuta el dockerfile, usa el contenedor temporal, build-env , con el SDK de .NET Core
2.1 para compilar la aplicación de ejemplo y, a continuación, copia los archivos binarios
generados en otro contenedor que contiene solo el entorno de ejecución de .NET Core
2.1 para que se minimice el tamaño del contenedor final.

Compilación y ejecución de la aplicación

Con el Dockerfile escrito, podemos apuntar a Docker en nuestro Dockerfile y indicarle
que compile y, a continuación, ejecute nuestra imagen:

1. En una ventana de la terminal, vaya al directorio donde reside el Dockerfile y, a

continuación, ejecute el comando docker build para construir el contenedor
desde el Dockerfile.

Powershell

docker build -t my-asp-app .

2. Para ejecutar el contenedor recién compilado, ejecute el comando docker run .

Powershell

docker run -d -p 5000:80 --name myapp my-asp-app

Vamos a diseccionar este comando:

-d indica a Docker que ejecute el contenedor "desasociado", lo que significa

que no se enlaza ninguna consola a la consola dentro del contenedor. El

contenedor se ejecuta en segundo plano.
-p 5000:80 indica a Docker que asigne el puerto 5000 en el host al puerto 80

del contenedor. Cada contenedor obtiene su propia dirección IP. ASP .NET
escucha de forma predeterminada en el puerto 80. La asignación de puertos
nos permite ir a la dirección IP del host en el puerto asignado y Docker
reenvía todo el tráfico al puerto de destino dentro del contenedor.
--name myapp indica a Docker que asigne a este contenedor un nombre

conveniente para realizar consultas (en lugar de tener que buscar el

identificador de contenedor asignado en tiempo de ejecución por Docker).
 my-asp-app es la imagen que queremos que Docker ejecute. Esta es la

imagen de contenedor generada como la culminación del proceso de docker

build .

3. Abra un explorador web y vaya a http://localhost:5000 para ver la aplicación en

contenedor.

Pasos siguientes
1. El siguiente paso consiste en publicar la aplicación web ASP.NET contenedorizada
en un registro privado mediante Azure Container Registry. Esto le permite
implementarlo en la organización.

Crear un registro de contenedor privado

Cuando llegue a la sección donde la imagen de contenedor se inserta en el

registro, especifique el nombre de la aplicación ASP.NET que acaba de empaquetar
( my-asp-app ) junto con el registro de contenedor (por ejemplo: contoso-container-
registry ):

PowerShell

docker tag my-asp-app contoso-container-registry.azurecr.io/my-asp-

app:v1

Para ver más ejemplos de aplicaciones y sus dockerfiles asociados, consulte

ejemplos adicionales de contenedores.
 2. Una vez publicada la aplicación en el registro de contenedor, el siguiente paso es
implementar la aplicación en un clúster de Kubernetes que cree con Azure
Kubernetes Service.

Creación de un clúster de Kubernetes

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Uso de contenedores de Windows para
"incluir en contenedores" aplicaciones
existentes
Artículo • 22/01/2025

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.

ﾉ Expandir tabla

Aplicaciones o ¿Por qué no es compatible? ¿Puedes solucionar esto?

características no
compatibles

Aplicaciones que Los contenedores no admiten Si la aplicación solo requiere una GUI
requieren un la interfaz gráfica de usuario para instalarla, cambiarla a una
escritorio (GUI) instalación silenciosa podría ser una
solución.

Aplicaciones que RDP es para sesiones Puede usar Windows Admin Center
usan el protocolo de interactivas, por lo que el (WAC) o PowerShell remoto como
escritorio remoto principio anterior también se alternativa para la administración
(RDP) aplica aquí. remota.

Aplicaciones con Los contenedores son Sí, es posible que algunas aplicaciones
estado efímeros requieran un cambio mínimo, por lo que
no almacenan datos ni estado dentro
del contenedor.

Aplicaciones de base Los contenedores son Sí, es posible que algunas aplicaciones
de datos efímeros 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 No. Sin embargo, las aplicaciones que
Active Directory impiden la dependen de Active Directory pueden
ejecución en un contenedor. usar cuentas de servicio administradas
de grupo (gMSA). A continuación se
proporciona más información sobre
gMSA.

Versiones anteriores Solo se admite Windows No. Sin embargo, la compatibilidad de

de Windows Server Server 2016 o posterior aplicaciones podría ser una opción: la
mayoría de windows Server 2008/R2 y
las aplicaciones anteriores se ejecutan
 Aplicaciones o ¿Por qué no es compatible? ¿Puedes solucionar esto?
características no
compatibles

en versiones más recientes de Windows

Server

Aplicaciones que Se requieren imágenes de Las versiones anteriores a la versión 2.0

usan .NET Framework contenedor específicas para no se admiten en absoluto, pero
versión 2.0 o anterior admitir .NET Framework y solo consulte a continuación las imágenes de
se admiten versiones más contenedor necesarias para versiones
recientes. posteriores.

Aplicaciones que Microsoft no certifica ni Consulte con el proveedor del marco

usan otros marcos de admite específicamente el uso específico o la aplicación la directiva de
terceros de marcos que no son de soporte técnico para contenedores de
Microsoft en contenedores de Windows. Consulte a continuación para
Windows 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.

ﾉ Expandir tabla

Tipo de ¿Por qué son buenos candidatos? Consideraciones especiales

aplicación

Aplicaciones de Sin limitaciones de GUI, las Use la imagen de contenedor base

consola aplicaciones de consola son adecuada en función de las
candidatas ideales para necesidades de la aplicación.
contenedores.

Servicios de Dado que se trata de procesos en Use la imagen de contenedor base

Windows segundo plano que no requieren adecuada en función de las
ninguna interacción directa del necesidades de la aplicación. Debe
usuario crear un proceso en primer plano para
mantener funcionando cualquier
proceso en segundo plano
containerizado. Consulte la sección
 Tipo de ¿Por qué son buenos candidatos? Consideraciones especiales
aplicación

sobre los servicios en segundo plano a

continuación.

Servicios de Dado que son aplicaciones Use la imagen de contenedor base

Windows orientadas al servicio que también adecuada en función de las
Communication se ejecutan en segundo plano necesidades de la aplicación. Es
Foundation (WCF) 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 Use la imagen de contenedor base
esencialmente servicios en adecuada en función de las
segundo plano que escuchan en necesidades de la aplicación.
un puerto específico y, por tanto,
son excelentes candidatos para la
contenedorización, ya que
aprovechan la escalabilidad que
ofrecen los contenedores.

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.

ﾉ Expandir tabla

Características o Razón
componentes de Windows
que requieren un control
especial

Microsoft Messaging MSMQ se originó mucho antes de que los contenedores y no

Queueing (MSMQ) todos sus modelos de implementación para las colas de
mensajes sean compatibles con la arquitectura de contenedor.

Coordinador de transacciones La resolución de nombres entre MSDTC y el contenedor necesita

distribuidas de Microsoft una consideración especial.
(MSDTC)

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
 Características o Razón
componentes de Windows
que requieren un control
especial

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 Asegúrese de usar la imagen correcta para garantizar la

(anteriormente .Net Core) compatibilidad, como se explica en la subsección siguiente.

Otros componentes auxiliares

ﾉ Expandir tabla

Componente que Razón Enfoque alternativo

requiere un
control especial

Registro y Dado que la forma en que Use la nueva herramienta Log

supervisión de Windows escribe eventos y Monitor para normalizar los datos y
eventos registros es inherentemente combinarlos desde Linux y Windows.
diferente de Stdout de Linux

Seguridad de Aunque muchas prácticas de Empleo de una herramienta de

contenedores de seguridad siguen siendo las análisis de imágenes y registro
Windows mismas, los contenedores diseñada específicamente: más
requieren medidas de seguridad detalles más adelante.
adicionales.

Copia de seguridad Los contenedores no deben tener Realice una copia de seguridad de
de contenedores datos ni estado cualquier almacenamiento
de Windows 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:

ﾉ Expandir tabla

Alcance ¿Transaccional? Ubicación de la cola Tipo de ¿Enviar y

autenticación recibir?

Privado Sí Mismo contenedor Anónimo Sí

(contenedor único)

Privado Sí Volumen persistente Anónimo Sí

Privado Sí Controlador de dominio Anónimo Sí

Privado Sí Host único (dos Anónimo Sí

contenedores)

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:

PowerShell

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:

ﾉ Expandir tabla

Para este marco Prueba con esta Recurre a esta imagen de Imagen base
imagen de contenedor si la primera no
contenedor primero funciona

Versiones 2.X y .NET Framework 4.x .NET Framework 3.5 Windows

3.X de .NET Server Core
Framework

Versiones de .NET Framework 4.x Compilación de la imagen de Windows

.NET Framework contenedor de .NET Framework Server Core
 Para este marco Prueba con esta Recurre a esta imagen de Imagen base
imagen de contenedor si la primera no
contenedor primero funciona

4.x con imágenes de Server o

Windows

.NET 6 o 7 .NET 6 o 7 Construye tu imagen de Windows

respectivamente contenedor de .NET con Nano Server o
imágenes base de Windows o Server Core
servidor.

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 , Windows o 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.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Dockerfile en Windows
Artículo • 05/02/2025

El motor de Docker incluye herramientas que automatizan la creación de imágenes de

contenedor. Aunque puede crear imágenes de contenedor manualmente mediante la
ejecución del comando docker commit , la adopción de un proceso de creación de
imágenes automatizada tiene muchas ventajas, entre las que se incluyen:

Almacenamiento de imágenes de contenedor como código.

Recreación rápida y precisa de imágenes de contenedor con fines de
mantenimiento y actualización.
Integración continua entre imágenes de contenedor y el ciclo de desarrollo.

Los componentes de Docker que controlan esta automatización son dockerfile y el

comando docker build .

Dockerfile es un archivo de texto que contiene las instrucciones necesarias para crear
una nueva imagen de contenedor. Estas instrucciones incluyen la identificación de una
imagen existente que se usará como base, los comandos que se ejecutarán durante el
proceso de creación de imágenes y un comando que se ejecutará cuando se
implementen nuevas instancias de la imagen de contenedor.

Docker build es el comando del motor de Docker que consume un Dockerfile y

desencadena el proceso de creación de una imagen.

En este tema se muestra cómo usar Dockerfiles con contenedores de Windows,

comprender su sintaxis básica y cuáles son las instrucciones de Dockerfile más comunes.

En este documento se describe el concepto de imágenes de contenedor y capas de

imagen de contenedor. Si quiere obtener más información sobre imágenes y capas de
imágenes, veaImágenes base de contenedores.

Para tener una visión completa de los Dockerfiles, vea Referencia de Dockerfile .

Sintaxis básica
En su forma más básica, un Dockerfile puede ser muy sencillo. En el ejemplo siguiente se
crea una nueva imagen, que incluye IIS y un sitio "hola mundo". En este ejemplo se
incluyen comentarios (indicados con un # ), que explican cada paso. En las secciones
posteriores de este artículo se detallarán las reglas de sintaxis de Dockerfile y las
instrucciones de Dockerfile.
 ７ Nota

Se debe crear un Dockerfile sin extensión. Para ello en Windows, cree el archivo con
el editor que prefiera y guárdelo con la notación "Dockerfile" (incluidas las
comillas).

Dockerfile

# Sample Dockerfile

# Indicates that the windowsservercore image will be used as the base image.
FROM mcr.microsoft.com/windows/servercore:ltsc2019

# Metadata indicating an image maintainer.

LABEL maintainer="[email protected]"

# Uses dism.exe to install the IIS role.

RUN dism.exe /online /enable-feature /all /featurename:iis-webserver
/NoRestart

# Creates an HTML file and adds content to this file.

RUN echo "Hello World - Dockerfile" > c:\inetpub\wwwroot\index.html

# Sets a command or process that will run each time a container is run from
the new image.
CMD [ "cmd" ]

A fin de obtener ejemplos adicionales de Dockerfiles para Windows, vea el repositorio

de Dockerfile para Windows .

Instrucciones
Las instrucciones de Dockerfile proporcionan al motor de Docker las instrucciones que
necesita para crear una imagen de contenedor. Estas instrucciones se realizan uno a uno
y en orden. Los ejemplos siguientes son las instrucciones más usadas en Dockerfiles.
Para obtener una lista completa de las instrucciones de Dockerfile, consulte la referencia
de Dockerfile .

FROM
La FROM instrucción establece la imagen de contenedor que se usará durante el nuevo
proceso de creación de imágenes. Por ejemplo, cuando se usa la instrucción FROM
mcr.microsoft.com/windows/servercore , la imagen resultante se deriva de y tiene una

dependencia de , la imagen del sistema operativo base de Windows Server Core. Si la

imagen especificada no está presente en el sistema donde se ejecuta el proceso de
compilación de Docker, el motor de Docker intentará descargar la imagen de un registro
de imágenes público o privado.

El formato de la instrucción FROM es similar al siguiente:

Dockerfile

FROM <image>

Este es un ejemplo del comando FROM:

Para descargar la versión ltsc2019 de Windows Server Core desde Microsoft Container
Registry (MCR):

FROM mcr.microsoft.com/windows/servercore:ltsc2019

Para más información, vea la referencia de FROM .

RUN
La instrucción RUN especifica los comandos que se van a ejecutar y que se capturarán en
la nueva imagen del contenedor. Estos comandos pueden incluir elementos como
instalar software, crear archivos y directorios y crear la configuración del entorno.

La instrucción RUN es similar a la siguiente:

Dockerfile

# exec form

RUN ["<executable>", "<param 1>", "<param 2>"]

# shell form

RUN <command>

La diferencia entre el formulario exec y shell es en cómo se ejecuta la instrucción RUN . Al

usar el formulario exec, el programa especificado se ejecuta explícitamente.

Este es un ejemplo del formulario exec:

 FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN ["powershell", "New-Item", "c:/test"]

La imagen resultante ejecuta el comando powershell New-Item c:/test :

Dockerfile

docker history doc-exe-method

IMAGE CREATED CREATED BY SIZE

COMMENT
b3452b13e472 2 minutes ago powershell New-Item c:/test 30.76
MB

Por el contrario, en el ejemplo siguiente se ejecuta la misma operación en formato de

shell:

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN powershell New-Item c:\test

La imagen resultante tiene una instrucción de ejecución de cmd /S /C powershell New-

Item c:\test .

Dockerfile

docker history doc-shell-method

IMAGE CREATED CREATED BY

SIZE COMMENT
062a543374fc 19 seconds ago cmd /S /C powershell New-Item
c:\test 30.76 MB

Consideraciones para usar RUN con Windows

En Windows, al usar la instrucción RUN con el formato exec, se debe aplicar escape a las
barras diagonales.

Dockerfile

RUN ["powershell", "New-Item", "c:\\test"]

Cuando el programa de destino sea un instalador de Windows, deberá extraer la
configuración a través de la marca /x:<directory> para poder iniciar el procedimiento
de instalación real (silencioso). También debe esperar a que el comando termine antes
de realizar cualquier otra operación. De lo contrario, el proceso finalizará
prematuramente sin instalar nada. Para obtener más información, consulte el ejemplo
siguiente.

Ejemplos de uso de RUN con Windows

En el ejemplo siguiente dockerfile se usa DISM para instalar IIS en la imagen de
contenedor:

Dockerfile

RUN dism.exe /online /enable-feature /all /featurename:iis-webserver

/NoRestart

En este ejemplo se instala el paquete redistribuible de Visual Studio. Start-Process y el

parámetro -Wait se usan para ejecutar el instalador. Esto garantiza que la instalación se
complete antes de pasar a la siguiente instrucción en el Dockerfile.

Dockerfile

RUN powershell.exe -Command Start-Process c:\vcredist_x86.exe -ArgumentList

'/quiet' -Wait

Para obtener información detallada sobre la instrucción RUN, consulte la referencia

RUN .

COPY
La instrucción COPY copia archivos y directorios en el sistema de archivos del
contenedor. Los archivos y directorios deben estar en una ruta de acceso relativa al
Dockerfile.

El formato de la instrucción COPY es similar al siguiente:

Dockerfile

COPY <source> <destination>

Si el origen o el destino incluyen espacios en blanco, incluya la ruta de acceso entre
corchetes y comillas dobles, como se muestra en el ejemplo siguiente:

Dockerfile

COPY ["<source>", "<destination>"]

Consideraciones para usar COPY con Windows

En Windows, el formato de destino debe usar barras diagonales. Por ejemplo, estas son
instrucciones COPY válidas:

Dockerfile

COPY test1.txt /temp/

COPY test1.txt c:/temp/

Por tanto, el siguiente formato con barras diagonales inversas no funcionará:

Dockerfile

COPY test1.txt c:\temp\

Ejemplos de uso de COPY con Windows

En el ejemplo siguiente se agrega el contenido del directorio de origen a un directorio

denominado sqllite en la imagen del contenedor:

Dockerfile

COPY source /sqlite/

En el ejemplo siguiente se agregarán todos los archivos que comienzan con la

configuración al directorio c:\temp de la imagen de contenedor:

Dockerfile

COPY config* c:/temp/

Para obtener información más detallada sobre la instrucción de COPY , consulte la

referencia de COPY .
AGREGAR
La instrucción ADD es como la instrucción COPY, pero con aún más funcionalidades.
Además de copiar archivos del host en la imagen de contenedor, la instrucción ADD
también puede copiar archivos desde una ubicación remota con una especificación de
dirección URL.

El formato de la instrucción ADD es similar al siguiente:

Dockerfile

ADD <source> <destination>

Si el origen o el destino incluyen espacios en blanco, incluya la ruta entre corchetes y

comillas dobles:

Dockerfile

ADD ["<source>", "<destination>"]

Consideraciones para ejecutar ADD con Windows

En Windows, el formato de destino debe usar barras diagonales. Por ejemplo, estas son
instrucciones ADD válidas:

Dockerfile

ADD test1.txt /temp/

ADD test1.txt c:/temp/

Por tanto, el siguiente formato con barras diagonales inversas no funcionará:

Dockerfile

ADD test1.txt c:\temp\

Además, en Linux, la instrucción ADD expandirá los paquetes comprimidos al copiar. Esta
funcionalidad no está disponible en Windows.

Ejemplos de uso de ADD con Windows

En el ejemplo siguiente se agrega el contenido del directorio de origen a un directorio
denominado sqllite en la imagen del contenedor:

Dockerfile

ADD source /sqlite/

En el ejemplo siguiente se agregarán todos los archivos que comienzan por "config" al
directorio c:\temp de la imagen de contenedor.

Dockerfile

ADD config* c:/temp/

En el ejemplo siguiente se descargará Python para Windows en el directorio c:\temp de

la imagen de contenedor.

Dockerfile

ADD https://www.python.org/ftp/python/3.5.1/python-3.5.1.exe /temp/python-

3.5.1.exe

Para más información sobre la instrucción ADD , vea la referencia de ADD .

WORKDIR
La instrucción WORKDIR establece un directorio de trabajo para otras instrucciones de
Dockerfile, como RUN , CMD y también el directorio de trabajo para ejecutar instancias de
la imagen de contenedor.

El formato de la instrucción WORKDIR es similar al siguiente:

Dockerfile

WORKDIR <path to working directory>

Consideraciones para usar WORKDIR con Windows

En Windows, si el directorio de trabajo incluye una barra diagonal inversa, se le debe

aplicar escape.

Dockerfile
 WORKDIR c:\\windows

Ejemplos

Dockerfile

WORKDIR c:\\Apache24\\bin

Para obtener información detallada sobre la instrucción WORKDIR , consulte la referencia

de WORKDIR .

CMD
La instrucción CMD establece que se ejecute el comando predeterminado al implementar
una instancia de la imagen de contenedor. Por ejemplo, si el contenedor hospedará un
servidor web NGINX, el CMD podría incluir instrucciones para iniciar el servidor web con
un comando como nginx.exe . Si se especifican varias instrucciones CMD en un
Dockerfile, solo se evalúa la última.

El formato de la instrucción CMD es similar al siguiente:

Dockerfile

# exec form

CMD ["<executable", "<param>"]

# shell form

CMD <command>

Consideraciones para usar CMD con Windows

En Windows, las rutas de acceso de archivo especificadas en la instrucción CMD deben

usar barras diagonales o tener barras diagonales inversas con escape \\ . A
continuación se muestran instrucciones CMD válidas:

Dockerfile

# exec form

CMD ["c:\\Apache24\\bin\\httpd.exe", "-w"]

 # shell form

CMD c:\\Apache24\\bin\\httpd.exe -w

Sin embargo, el siguiente formato sin las barras diagonales adecuadas no funcionará:

Dockerfile

CMD c:\Apache24\bin\httpd.exe -w

Para obtener información más detallada sobre la instrucción CMD , consulte la referencia
de CMD de .

Carácter de escape
En muchos casos, una instrucción Dockerfile tendrá que abarcar varias líneas. Para ello,
puede usar un carácter de escape. El carácter de escape predeterminado de Dockerfile
es una barra diagonal inversa \ . Sin embargo, dado que la barra diagonal inversa
también es un separador de rutas de acceso de archivos en Windows, el hecho de usarla
para abarcar varias líneas puede causar problemas. Para solucionar este problema,
puede usar una directiva de analizador para cambiar el carácter de escape
predeterminado. Para obtener más información sobre las directivas de analizador,
consulte directivas de analizador .

En el ejemplo siguiente se muestra una única instrucción RUN que abarca varias líneas
mediante el carácter de escape predeterminado:

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN powershell.exe -Command \

$ErrorActionPreference = 'Stop'; \
wget https://www.python.org/ftp/python/3.5.1/python-3.5.1.exe -OutFile
c:\python-3.5.1.exe ; \
Start-Process c:\python-3.5.1.exe -ArgumentList '/quiet
InstallAllUsers=1 PrependPath=1' -Wait ; \
Remove-Item c:\python-3.5.1.exe -Force

Para modificar el carácter de escape, coloque una directiva del analizador de escape en
la primera línea del Dockerfile. Esto se puede ver en el ejemplo siguiente.

７ Nota
 Solo se pueden usar dos valores como caracteres de escape: \ y ` .

Dockerfile

# escape=`

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN powershell.exe -Command `

$ErrorActionPreference = 'Stop'; `
wget https://www.python.org/ftp/python/3.5.1/python-3.5.1.exe -OutFile
c:\python-3.5.1.exe ; `
Start-Process c:\python-3.5.1.exe -ArgumentList '/quiet
InstallAllUsers=1 PrependPath=1' -Wait ; `
Remove-Item c:\python-3.5.1.exe -Force

Para más información sobre la directiva del analizador de escape, vea Directiva del
analizador de escape .

PowerShell en Dockerfile

Cmdlets de PowerShell
Los cmdlets de PowerShell se pueden ejecutar en un Dockerfile con la operación RUN .

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN powershell -command Expand-Archive -Path c:\apache.zip -DestinationPath

c:\

Llamadas REST
El cmdlet Invoke-WebRequest de PowerShell puede ser útil al recopilar información o
archivos de un servicio web. Por ejemplo, si crea una imagen que incluye Python, puede
establecer $ProgressPreference en SilentlyContinue para lograr descargas más rápidas,
como se muestra en el ejemplo siguiente.

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN powershell.exe -Command \

 $ErrorActionPreference = 'Stop'; \
$ProgressPreference = 'SilentlyContinue'; \
Invoke-WebRequest https://www.python.org/ftp/python/3.5.1/python-3.5.1.exe
-OutFile c:\python-3.5.1.exe ; \
Start-Process c:\python-3.5.1.exe -ArgumentList '/quiet InstallAllUsers=1
PrependPath=1' -Wait ; \
Remove-Item c:\python-3.5.1.exe -Force

７ Nota

Invoke-WebRequest también funciona en Nano Server.

Otra opción para usar PowerShell para descargar archivos durante el proceso de
creación de imágenes es usar la biblioteca WebClient de .NET. Esto puede aumentar el
rendimiento de la descarga. En el ejemplo siguiente se descarga el software de Python
mediante la biblioteca WebClient.

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN powershell.exe -Command \

$ErrorActionPreference = 'Stop'; \
(New-Object
System.Net.WebClient).DownloadFile('https://www.python.org/ftp/python/3.5.1/
python-3.5.1.exe','c:\python-3.5.1.exe') ; \
Start-Process c:\python-3.5.1.exe -ArgumentList '/quiet InstallAllUsers=1
PrependPath=1' -Wait ; \
Remove-Item c:\python-3.5.1.exe -Force

７ Nota

Nano Server no admite actualmente WebClient.

Scripts de PowerShell
En algunos casos, puede resultar útil copiar un script en los contenedores que use
durante el proceso de creación de imágenes y, a continuación, ejecutar el script desde
dentro del contenedor.

７ Nota
 Esto limitará el almacenamiento en caché de cualquier capa de imagen y reducirá la
legibilidad de Dockerfile.

En este ejemplo se copia un script de la máquina de compilación en el contenedor

mediante la instrucción ADD . A continuación, este script se ejecuta mediante la
instrucción RUN.

FROM mcr.microsoft.com/windows/servercore:ltsc2019
ADD script.ps1 /windows/temp/script.ps1
RUN powershell.exe -executionpolicy bypass c:\windows\temp\script.ps1

Compilación de Docker
Una vez creado y guardado un Dockerfile en el disco, puede ejecutar docker build para
crear la nueva imagen. El comando docker build toma varios parámetros opcionales y
una ruta de acceso al Dockerfile. Para obtener documentación completa sobre La
compilación de Docker, incluida una lista de todas las opciones de compilación, consulte
la referencia de compilación .

El formato del comando docker build es similar al siguiente:

Dockerfile

docker build [OPTIONS] PATH

Por ejemplo, el siguiente comando creará una imagen denominada "iis".

Dockerfile

docker build -t iis .

Cuando se haya iniciado el proceso de compilación, la salida indicará el estado y

devolverá los errores producidos.

Dockerfile

C:\> docker build -t iis .

Sending build context to Docker daemon 2.048 kB

Step 1 : FROM mcr.microsoft.com/windows/servercore:ltsc2019
---> 6801d964fda5
 Step 2 : RUN dism /online /enable-feature /all /featurename:iis-webserver
/NoRestart
---> Running in ae8759fb47db

Deployment Image Servicing and Management tool

Version: 10.0.10586.0

Image Version: 10.0.10586.0

Enabling feature(s)
The operation completed successfully.

---> 4cd675d35444
Removing intermediate container ae8759fb47db

Step 3 : RUN echo "Hello World - Dockerfile" > c:\inetpub\wwwroot\index.html

---> Running in 9a26b8bcaa3a
---> e2aafdfbe392
Removing intermediate container 9a26b8bcaa3a

Successfully built e2aafdfbe392

El resultado es una nueva imagen de contenedor, que en este ejemplo se denomina

"iis".

Dockerfile

docker images

REPOSITORY TAG IMAGE ID CREATED

VIRTUAL SIZE
iis latest e2aafdfbe392 About a minute
ago 207.8 MB
windowsservercore latest 6801d964fda5 4 months ago
0 B

Lectura y referencias adicionales

Optimizar dockerfiles y la compilación de Docker para Windows
Referencia de Dockerfile

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Optimizar Dockerfiles de Windows
Artículo • 23/01/2025

Existen varias maneras de optimizar el proceso de compilación de Docker y las

imágenes de Docker resultantes. En este artículo se explica cómo funciona el proceso de
compilación de Docker y cómo crear imágenes óptimamente para contenedores de
Windows.

Capas de imagen en la compilación de Docker

Antes de poder optimizar la compilación de Docker, debe saber cómo funciona la
compilación de Docker. Durante el proceso de compilación de Docker se usa un
Dockerfile y cada instrucción accionable se ejecuta, de una en una, en su propio
contenedor temporal. El resultado es una nueva capa de imagen para cada instrucción
accionable.

Por ejemplo, en el siguiente ejemplo de Dockerfile se usa la imagen de sistema

operativo base mcr.microsoft.com/windows/servercore:ltsc2019 , se instala IIS y, a
continuación, se crea un sitio web sencillo.

Dockerfile

# Sample Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2019
RUN dism /online /enable-feature /all /featurename:iis-webserver /NoRestart
RUN echo "Hello World - Dockerfile" > c:\inetpub\wwwroot\index.html
CMD [ "cmd" ]

Podría esperar que este Dockerfile genere una imagen con dos capas, una para la
imagen del sistema operativo del contenedor y otra que incluye IIS y el sitio web. Sin
embargo, la imagen real tiene muchas capas y cada capa depende de la anterior.

Para que esto quede más claro, vamos a ejecutar el comando docker history en la
imagen que se ha creado en el ejemplo de Dockerfile.

Dockerfile

docker history iis

IMAGE CREATED CREATED BY

SIZE COMMENT
f4caf476e909 16 seconds ago cmd /S /C REM (nop) CMD ["cmd"]
 41.84 kB
f0e017e5b088 21 seconds ago cmd /S /C echo "Hello World -
Dockerfile" > c 6.816 MB
88438e174b7c About a minute ago cmd /S /C dism /online /enable-
feature /all / 162.7 MB
6801d964fda5 4 months ago
0 B

La salida muestra que esta imagen tiene cuatro capas: la capa base y tres capas
adicionales que se asignan a cada instrucción de Dockerfile. La capa inferior
( 6801d964fda5 en este ejemplo) representa la imagen base del sistema operativo. Una
capa más arriba está la instalación de IIS. La siguiente capa incluye el nuevo sitio web y
así sucesivamente.

Se pueden escribir Dockerfiles para minimizar las capas de imagen, optimizar el

rendimiento de la compilación y optimizar la accesibilidad a través de la legibilidad. En
última instancia, hay muchas formas de realizar la misma tarea de compilación de la
imagen. La comprensión de cómo afecta el formato de Dockerfile al tiempo de
compilación y a la imagen que crea mejora la experiencia de automatización.

Optimización del tamaño de la imagen

En función de los requisitos de espacio, el tamaño de la imagen puede ser un factor
importante a la hora de crear imágenes de contenedor de Docker. Las imágenes de
contenedor se mueven entre registros y host, se exportan e importan y, en última
instancia, usan espacio. En esta sección se explica cómo minimizar el tamaño de la
imagen durante el proceso de compilación de Docker para contenedores de Windows.

Para obtener información adicional sobre los procedimientos recomendados de

Dockerfile, consulta Procedimientos recomendados para escribir Dockerfiles .

Acciones relacionadas con grupos

Dado que cada instrucción RUN crea una nueva capa en la imagen del contenedor, la
agrupación de acciones en una instrucción RUN puede reducir el número de capas en
una instancia de Dockerfile. Aunque la minimización de capas puede no afectar mucho
al tamaño de la imagen, la agrupación de acciones relacionadas sí, lo que se verá en los
ejemplos siguientes.

En esta sección, se compararán dos ejemplos de Dockerfile que hacen lo mismo. Sin
embargo, una instancia de Dockerfile contiene una instrucción por acción, mientras que
en el otro se han agrupado sus acciones relacionadas.
En el siguiente ejemplo de Dockerfile desagrupado se descarga Python para Windows,
se instala y se quita el archivo de instalación descargado una vez finalizada. En este
Dockerfile, cada acción recibe su propia instrucción RUN .

Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN powershell.exe -Command Invoke-WebRequest

"https://www.python.org/ftp/python/3.5.1/python-3.5.1.exe" -OutFile
c:\python-3.5.1.exe
RUN powershell.exe -Command Start-Process c:\python-3.5.1.exe -ArgumentList
'/quiet InstallAllUsers=1 PrependPath=1' -Wait
RUN powershell.exe -Command Remove-Item c:\python-3.5.1.exe -Force

La imagen resultante se compone de tres capas adicionales, una para cada instrucción
RUN .

Dockerfile

docker history doc-example-1

IMAGE CREATED CREATED BY

SIZE COMMENT
a395ca26777f 15 seconds ago cmd /S /C powershell.exe -Command
Remove-Item 24.56 MB
6c137f466d28 28 seconds ago cmd /S /C powershell.exe -Command
Start-Proce 178.6 MB
957147160e8d 3 minutes ago cmd /S /C powershell.exe -Command
Invoke-WebR 125.7 MB

El segundo ejemplo es una instancia de Dockerfile que realiza la misma operación

exacta. Sin embargo, todas las acciones relacionadas se han agrupado en una sola
instrucción RUN . Cada paso de la instrucción RUN está en una nueva línea de Dockerfile y
se usa el carácter "\" para el ajuste de línea.

Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN powershell.exe -Command \

$ErrorActionPreference = 'Stop'; \
Invoke-WebRequest https://www.python.org/ftp/python/3.5.1/python-3.5.1.exe
-OutFile c:\python-3.5.1.exe ; \
Start-Process c:\python-3.5.1.exe -ArgumentList '/quiet InstallAllUsers=1
PrependPath=1' -Wait ; \
Remove-Item c:\python-3.5.1.exe -Force
La imagen resultante solo tiene una capa adicional para la instrucción RUN .

Dockerfile

docker history doc-example-2

IMAGE CREATED CREATED BY

SIZE COMMENT
69e44f37c748 54 seconds ago cmd /S /C powershell.exe -Command
$ErrorAct 216.3 MB

Quitar archivos sobrantes

Si hay un archivo en Dockerfile, como un instalador, que no necesitas después de usarlo,
puedes quitarlo para reducir el tamaño de la imagen. Esto debe hacerse en el mismo
paso en el que se copia el archivo en la capa de imagen. Esto evita que el archivo se
conserve en una capa de la imagen de nivel inferior.

En el siguiente ejemplo de Dockerfile, se descarga, ejecuta y se quita el paquete de

Python. Todo se realiza en una operación RUN y da lugar a una única capa de imagen.

Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN powershell.exe -Command \

$ErrorActionPreference = 'Stop'; \
Invoke-WebRequest https://www.python.org/ftp/python/3.5.1/python-3.5.1.exe
-OutFile c:\python-3.5.1.exe ; \
Start-Process c:\python-3.5.1.exe -ArgumentList '/quiet InstallAllUsers=1
PrependPath=1' -Wait ; \
Remove-Item c:\python-3.5.1.exe -Force

Optimización de la velocidad de compilación

Varias líneas
Puedes dividir las operaciones en varias instrucciones individuales para optimizar la
velocidad de compilación de Docker. Varias operaciones RUN aumentan la eficacia del
almacenamiento en caché porque se crean capas individuales para cada instrucción RUN .
Si ya se ha ejecutado una instrucción idéntica en una operación de compilación de
Docker diferente, se reutiliza esta operación almacenada en caché (capa de imagen), lo
que disminuye el tiempo de ejecución de compilación de Docker.
En el ejemplo siguiente, se descargan los paquetes de redistribución de Apache y Visual
Studio, se instalan y luego se limpian quitando los archivos que ya no se necesitan. Todo
se hace con una única instrucción RUN . Si alguna de estas acciones se actualiza, se
vuelven a ejecutar todas.

Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN powershell -Command \

# Download software ; \

wget https://www.apachelounge.com/download/VC11/binaries/httpd-2.4.18-
win32-VC11.zip -OutFile c:\apache.zip ; \
wget "https://download.microsoft.com/download/1/6/B/16B06F60-3B20-4FF2-
B699-5E9B7962F9AE/VSU_4/vcredist_x86.exe" -OutFile c:\vcredist.exe ; \
wget -Uri http://windows.php.net/downloads/releases/php-5.5.33-Win32-VC11-
x86.zip -OutFile c:\php.zip ; \

# Install Software ; \

Expand-Archive -Path c:\php.zip -DestinationPath c:\php ; \

Expand-Archive -Path c:\apache.zip -DestinationPath c:\ ; \
Start-Process c:\vcredist.exe -ArgumentList '/quiet' -Wait ; \

# Remove unneeded files ; \

Remove-Item c:\apache.zip -Force; \

Remove-Item c:\vcredist.exe -Force; \
Remove-Item c:\php.zip

La imagen resultante consta de dos capas, una para la imagen base del sistema
operativo y otra que contiene todas las operaciones de la instrucción única RUN .

Dockerfile

docker history doc-sample-1

IMAGE CREATED CREATED BY

SIZE COMMENT
9bdf3a21fd41 8 minutes ago cmd /S /C powershell -Command
Invoke-WebR 205.8 MB
6801d964fda5 5 months ago
0 B

Para comparar, aquí están las mismas acciones divididas en tres instrucciones RUN . En
este caso, cada instrucción RUN se almacena en caché en una capa de imagen de
contenedor y solo es necesario volver a ejecutar aquellas que han cambiado en
posteriores compilaciones del Dockerfile.

Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN powershell -Command \

$ErrorActionPreference = 'Stop'; \
wget https://www.apachelounge.com/download/VC11/binaries/httpd-2.4.18-
win32-VC11.zip -OutFile c:\apache.zip ; \
Expand-Archive -Path c:\apache.zip -DestinationPath c:\ ; \
Remove-Item c:\apache.zip -Force

RUN powershell -Command \

$ErrorActionPreference = 'Stop'; \
wget "https://download.microsoft.com/download/1/6/B/16B06F60-3B20-4FF2-
B699-5E9B7962F9AE/VSU_4/vcredist_x86.exe" -OutFile c:\vcredist.exe ; \
Start-Process c:\vcredist.exe -ArgumentList '/quiet' -Wait ; \
Remove-Item c:\vcredist.exe -Force

RUN powershell -Command \

$ErrorActionPreference = 'Stop'; \
wget http://windows.php.net/downloads/releases/php-5.5.33-Win32-VC11-
x86.zip -OutFile c:\php.zip ; \
Expand-Archive -Path c:\php.zip -DestinationPath c:\php ; \
Remove-Item c:\php.zip -Force

La imagen resultante se compone de cuatro capas: una capa para la imagen base del
sistema operativo y tres para cada una de las instrucciones RUN . Dado que cada
instrucción RUN se ejecutó en su propia capa, todas las ejecuciones posteriores de este
Dockerfile o de un conjunto idéntico de instrucciones de un Dockerfile diferente usarán
la capa de imagen almacenada en caché, lo que disminuirá el tiempo de compilación.

Dockerfile

docker history doc-sample-2

IMAGE CREATED CREATED BY

SIZE COMMENT
ddf43b1f3751 6 days ago cmd /S /C powershell -Command Sleep
2 ; Inv 127.2 MB
d43abb81204a 7 days ago cmd /S /C powershell -Command Sleep
2 ; Inv 66.46 MB
7a21073861a1 7 days ago cmd /S /C powershell -Command Sleep
2 ; Inv 115.8 MB
6801d964fda5 5 months ago
La forma de ordenar las instrucciones es importante cuando se trabaja con cachés de
imágenes, como se verá en la sección siguiente.

Clasificación de instrucciones
Un Dockerfile se procesa de arriba a abajo y cada instrucción se compara con las capas
almacenadas en caché. Cuando se encuentra una instrucción sin una capa en caché, esta
instrucción y todas las siguientes se procesan en nuevas capas de la imagen del
contenedor. Por este motivo, es importante el orden en que se colocan las instrucciones.
Coloque las instrucciones que se van a mantener constantes hacia la parte superior del
Dockerfile. Coloque las que pueden cambiar hacia la parte inferior del Dockerfile. Al
hacerlo, se reduce la probabilidad de que se niegue la caché existente.

En los siguientes ejemplos se muestra cómo puede afectar la clasificación de las

instrucciones de Dockerfile a la eficacia del almacenamiento en caché. Este sencillo
ejemplo de Dockerfile tiene cuatro carpetas numeradas.

Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN mkdir test-1

RUN mkdir test-2
RUN mkdir test-3
RUN mkdir test-4

La imagen resultante tiene cinco capas, una para la imagen base del sistema operativo y
una para cada instrucción RUN .

Dockerfile

docker history doc-sample-1

IMAGE CREATED CREATED BY SIZE

COMMENT
afba1a3def0a 38 seconds ago cmd /S /C mkdir test-4 42.46 MB
86f1fe772d5c 49 seconds ago cmd /S /C mkdir test-3 42.35 MB
68fda53ce682 About a minute ago cmd /S /C mkdir test-2 6.745 MB
5e5aa8ba1bc2 About a minute ago cmd /S /C mkdir test-1 7.12 MB
6801d964fda5 5 months ago 0 B

El Dockerfile siguiente se ha modificado ligeramente, ya que se ha cambiado la tercera

instrucción RUN a un archivo nuevo. Cuando se ejecuta la compilación de Docker en este
Dockerfile, las tres primeras instrucciones, que son idénticas a las del último ejemplo,
usan las capas de la imagen almacenadas en caché. Sin embargo, dado que la
instrucción RUN modificada no se ha almacenado en caché, se crea una nueva capa para
ella y todas las instrucciones posteriores.

Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN mkdir test-1

RUN mkdir test-2
RUN mkdir test-5
RUN mkdir test-4

Cuando se comparan los id. de imagen de la nueva imagen con los del primer ejemplo
de esta sección, observarás que las tres primeras capas de abajo a arriba están
compartidas, pero la cuarta y la quinta son únicas.

Dockerfile

docker history doc-sample-2

IMAGE CREATED CREATED BY SIZE

COMMENT
c92cc95632fb 28 seconds ago cmd /S /C mkdir test-4 5.644 MB
2f05e6f5c523 37 seconds ago cmd /S /C mkdir test-5 5.01 MB
68fda53ce682 3 minutes ago cmd /S /C mkdir test-2 6.745 MB
5e5aa8ba1bc2 4 minutes ago cmd /S /C mkdir test-1 7.12 MB
6801d964fda5 5 months ago 0 B

Optimización cosmética

Mayúsculas y minúsculas de las instrucciones

La instrucciones de Dockerfile no distinguen mayúsculas de minúsculas, pero la
convención es usar mayúsculas. Esto mejora la legibilidad al diferenciar entre la llamada
y la operación de la instrucción. En los dos ejemplos siguientes se compara un
Dockerfile con mayúsculas y sin mayúsculas.

A continuación, se muestra un Dockerfile sin mayúsculas:

Dockerfile

# Sample Dockerfile

from mcr.microsoft.com/windows/servercore:ltsc2019
run dism /online /enable-feature /all /featurename:iis-webserver /NoRestart
 run echo "Hello World - Dockerfile" > c:\inetpub\wwwroot\index.html
cmd [ "cmd" ]

El siguiente es el mismo Dockerfile usando mayúsculas:

Dockerfile

# Sample Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2019
RUN dism /online /enable-feature /all /featurename:iis-webserver /NoRestart
RUN echo "Hello World - Dockerfile" > c:\inetpub\wwwroot\index.html
CMD [ "cmd" ]

Ajuste de línea
Las operaciones largas y complejas pueden dividirse en varias líneas por el carácter de
barra diagonal inversa \ . El Dockerfile siguiente instala el paquete redistribuible de
Visual Studio, quita los archivos del instalador y luego crea un archivo de configuración.
Estas tres operaciones se especifican en una sola línea.

Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN powershell -Command c:\vcredist_x86.exe /quiet ; Remove-Item

c:\vcredist_x86.exe -Force ; New-Item c:\config.ini

El comando se puede dividir con barras inclinadas inversas para que cada operación de
la instrucción RUN se especifique en su propia línea.

Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN powershell -Command \

$ErrorActionPreference = 'Stop'; \
Start-Process c:\vcredist_x86.exe -ArgumentList '/quiet' -Wait ; \
Remove-Item c:\vcredist_x86.exe -Force ; \
New-Item c:\config.ini

Lecturas y referencias adicionales

Dockerfile en Windows
Best practices for writing Dockerfiles (Procedimientos recomendados para escribir
Dockerfiles) en Docker.com

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Implementación de aplicaciones Windows
Artículo • 17/04/2025

Se aplica a: AKS en Windows Server

En este tutorial se describe cómo implementar una aplicación de ejemplo de ASP.NET en un

contenedor de Windows Server en el clúster de Azure Kubernetes Service (AKS) en AKS en
Windows Server y, a continuación, probar y escalar la aplicación. También aprenderá a unir un
nodo de Windows a un dominio de Active Directory.

En este tutorial se da por supuesto que tiene un conocimiento básico de los conceptos de
Kubernetes. Para obtener más información, consulte Conceptos básicos de Kubernetes para
AKS en Windows Server.

Antes de empezar
Asegúrese de cumplir los siguientes requisitos:

Un clúster de Azure Kubernetes Service con al menos un nodo de trabajo de Windows en

ejecución.
Un archivo kubeconfig para obtener acceso al clúster.
El módulo de PowerShell de AksHci está instalado.

Al seguir los procedimientos:

Ejecute los comandos en una ventana de administrador de PowerShell.

Asegúrese de que las cargas de trabajo específicas del SO se encuentran en el host de
contenedor adecuado. Si el clúster de Kubernetes tiene una combinación de nodos de
trabajo de Linux y Windows, puede usar selectores de nodos o intolerancias y tolerancias.
Para obtener más información, consulte Uso de los selectores de nodo y la opción para
rechazar o aceptarlos.

Implementación de la aplicación
Un archivo de manifiesto de Kubernetes define un estado deseado del clúster, por ejemplo,
qué imágenes de contenedor se van a ejecutar. En estos procedimientos, se usa un manifiesto
para crear todos los objetos necesarios para ejecutar la aplicación de ejemplo ASP.NET en un
contenedor de Windows Server. Este manifiesto incluye una implementación de Kubernetes
para la aplicación de ejemplo de ASP.NET y un servicio de Kubernetes externo para acceder a la
aplicación desde Internet.
La aplicación de ejemplo ASP.NET se proporciona como parte de los ejemplos de .NET
Framework y se ejecuta en un contenedor de Windows Server. AKS Arc requiere que los
contenedores de Windows Server se basen en imágenes de Windows Server 2019.

El archivo de manifiesto de Kubernetes también debe definir un selector de nodos para indicar
al clúster que ejecute el pod de la aplicación de ejemplo de ASP.NET en un nodo que pueda
ejecutar contenedores de Windows Server.

Cree un archivo denominado sample.yaml y copie o pegue la siguiente definición de YAML:

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
name: sample
labels:
app: sample
spec:
replicas: 1
template:
metadata:
name: sample
labels:
app: sample
spec:
nodeSelector:
"beta.kubernetes.io/os": windows
containers:
- name: sample
image: mcr.microsoft.com/dotnet/framework/samples:aspnetapp
resources:
limits:
cpu: 1
memory: 800M
requests:
cpu: .1
memory: 300M
ports:
- containerPort: 80
selector:
matchLabels:
app: sample
---
apiVersion: v1
kind: Service
metadata:
name: sample
spec:
type: LoadBalancer
ports:
- protocol: TCP
 port: 80
selector:
app: sample

Implemente la aplicación con el kubectl apply comando y especifique el nombre del

manifiesto de YAML:

PowerShell

kubectl apply -f sample.yaml

En la salida de ejemplo siguiente se muestra que la implementación y el servicio se crearon

correctamente:

Resultados

deployment.apps/sample created
service/sample created

Prueba de la aplicación
Cuando se ejecuta la aplicación, un servicio de Kubernetes expone el front-end de la aplicación
a Internet. Este proceso puede tardar unos minutos en completarse. En ocasiones, el servicio
puede tardar más de algunos minutos en provisionarse. Espere hasta 10 minutos en estos
casos.

Para supervisar el progreso, use el kubectl get service comando con el --watch argumento :

PowerShell

kubectl get service sample --watch

Inicialmente, el EXTERNAL-IP para el servicio de ejemplo se muestra como pendiente:

Resultados

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

sample LoadBalancer 10.0.37.27 <pending> 80:30572/TCP 6s

Cuando la dirección EXTERNAL-IP cambie de pendiente a una dirección IP pública real, use
CTRL-C para detener el proceso de inspección de kubectl . En la salida del ejemplo siguiente se

muestra una dirección IP pública válida asignada al servicio:

 Resultados

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

sample LoadBalancer 10.0.37.27 52.179.23.131 80:30572/TCP 2m

Para ver la aplicación de ejemplo en acción, abra un explorador web en la dirección IP externa
del servicio.

Si la conexión agota el tiempo de espera al intentar cargar la página, compruebe si la

aplicación de ejemplo está lista ejecutando el kubectl get pods --watch comando . A veces, la
dirección IP externa está disponible antes de que se inicie el contenedor de Windows.

Escalado de pods de la aplicación

Hemos creado una sola réplica del front-end de la aplicación. Para ver el número y el estado de
los pods del clúster, use el comando kubectl get tal como se indica a continuación:

PowerShell

kubectl get pods -n default

Para cambiar el número de pods en la implementación de ejemplo, use el comando kubectl
scale . El ejemplo siguiente aumenta el número de pods de front-end a 3:

PowerShell

kubectl scale --replicas=3 deployment/sample

Vuelva a ejecutar kubectl get pods para verificar que los pods se han creado. Tras un minuto
aproximadamente, los pods adicionales están disponibles en el clúster:

PowerShell

kubectl get pods -n default

Pasos siguientes
Uso de Azure Monitor para supervisar el clúster y la aplicación
Uso de volúmenes persistentes en un clúster de Kubernetes
Implementación de un contenedor de
Windows Server en un clúster de
Azure Kubernetes Service (AKS) mediante
la CLI de Azure
14/04/2025

Azure Kubernetes Service (AKS) es un servicio de Kubernetes administrado que le permite

implementar y administrar clústeres rápidamente. En este artículo, usará la CLI de Azure para
implementar un clúster de AKS que ejecute contenedores de Windows Server. También
implementará una aplicación de ejemplo de ASP.NET en un contenedor de Windows Server en
el clúster.

７ Nota

Para empezar a aprovisionar rápidamente un clúster de AKS, en este artículo se incluyen

los pasos para implementar un clúster con la configuración predeterminada solo con fines
de evaluación. Antes de implementar un clúster listo para producción, se recomienda
familiarizarse con nuestra arquitectura de referencia de línea de base para considerar
cómo se alinea con sus requisitos empresariales.

Antes de empezar
En esta guía rápida se presupone un conocimiento básico de los conceptos de Kubernetes.
Para más información, consulte Conceptos básicos de Kubernetes de Azure Kubernetes Service
(AKS).

Si no tiene una cuenta de Azure, cree una cuenta gratuita antes de comenzar.

Use el entorno de Bash en Azure Cloud Shell. Para más información, consulte
Introducción a Azure Cloud Shell.

Si prefiere ejecutar comandos de referencia de la CLI localmente, instale la CLI de Azure.

Si utiliza Windows o macOS, considere la posibilidad de ejecutar la CLI de Azure en un
contenedor Docker. Para más información, vea Ejecución de la CLI de Azure en un
contenedor de Docker.
 Si usa una instalación local, inicie sesión en la CLI de Azure mediante el comando az
login. Siga los pasos que se muestran en el terminal para completar el proceso de
autenticación. Para ver otras opciones de inicio de sesión, consulte Autenticación en
Azure mediante la CLI de Azure.

En caso de que se le solicite, instale las extensiones de la CLI de Azure la primera vez
que la use. Para obtener más información sobre las extensiones, consulte Uso y
administración de extensiones con la CLI de Azure.

Ejecute az version para buscar cuál es la versión y las bibliotecas dependientes que
están instaladas. Para realizar la actualización a la versión más reciente, ejecute az
upgrade.

En este artículo se necesita la versión 2.0.64 de la CLI de Azure, o cualquier versión

posterior. Si usa Azure Cloud Shell, ya está instalada allí la versión más reciente.
Asegúrese de que la identidad que usará para crear el clúster tenga los permisos mínimos
adecuados. Para más información sobre el acceso y la identidad en AKS, consulte
Opciones de acceso e identidad en Azure Kubernetes Service (AKS).
Si tiene varias suscripciones de Azure, seleccione el identificador de suscripción adecuado
en el que se deben facturar los recursos con el comando az account set. Para más
información, consulte Cómo administrar suscripciones de Azure: CLI de Azure.

Crear un grupo de recursos

Un grupo de recursos de Azure es un grupo lógico en el que se implementan y administran
recursos de Azure. Cuando se crea un grupo de recursos, se le pide que especifique una
ubicación. Esta ubicación es donde se almacenan los metadatos del grupo de recursos y el
lugar en el que los recursos se ejecutan en Azure si no se especifica otra región al crearlos.

Cree un grupo de recursos con el comando az group create. En el ejemplo siguiente se

crea un grupo de recursos denominado myResourceGroup en la ubicación WestUS2 .
Utilice este comando y otros comandos de este artículo en un shell de BASH:

Bash

export RANDOM_SUFFIX=$(openssl rand -hex 3)

export REGION="canadacentral"
export MY_RESOURCE_GROUP_NAME="myAKSResourceGroup$RANDOM_SUFFIX"
az group create --name $MY_RESOURCE_GROUP_NAME --location $REGION

Resultados:

JSON
 {
"id": "/subscriptions/xxxxx-xxxxx-xxxxx-
xxxxx/resourceGroups/myResourceGroupxxxxx",
"location": "WestUS2",
"managedBy": null,
"name": "myResourceGroupxxxxx",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null,
"type": "Microsoft.Resources/resourceGroups"
}

Creación de un clúster de AKS

En esta sección, se crea un clúster de AKS con la siguiente configuración:

El clúster se configura con dos nodos para asegurarse de que funciona de forma
confiable. Un nodo es una máquina virtual de Azure que ejecuta los componentes de
nodo de Kubernetes y el entorno de ejecución del contenedor.
Los parámetros --windows-admin-password y --windows-admin-username establecen las
credenciales de administrador para los nodos de Windows Server del clúster y deben
satisfacer los requisitos de contraseña de Windows Server.
El grupo de nodos usa VirtualMachineScaleSets .

Para crear el clúster de AKS con la CLI de Azure, siga estos pasos:

1. Cree un nombre de usuario para usarlo como credenciales de administrador para los
nodos de Windows Server en el clúster. (En el ejemplo original se solicita la entrada; en
este documento exec, la variable de entorno se establece de forma no interactiva).

Bash

export WINDOWS_USERNAME="winadmin"

2. Cree una contraseña para el nombre de usuario de administrador que creó en el paso
anterior. La contraseña debe tener un mínimo de 14 caracteres y cumplir los requisitos de
complejidad de contraseña de Windows Server.

Bash

export WINDOWS_PASSWORD=$(echo "P@ssw0rd$(openssl rand -base64 10 | tr -dc 'A-Za-

z0-9!@#$%^&*()' | cut -c1-6)")
 3. Utilice el comando az aks create para crear un clúster y especifique los parámetros --
windows-admin-username y --windows-admin-password . El siguiente comando de ejemplo

crea un clúster con los valores de WINDOWS_USERNAME y WINDOWS_PASSWORD

establece en los comandos anteriores. Se anexa un sufijo aleatorio al nombre del clúster
para la unicidad.

Bash

export MY_AKS_CLUSTER="myAKSCluster$RANDOM_SUFFIX"
az aks create \
--resource-group $MY_RESOURCE_GROUP_NAME \
--name $MY_AKS_CLUSTER \
--node-count 2 \
--enable-addons monitoring \
--generate-ssh-keys \
--windows-admin-username $WINDOWS_USERNAME \
--windows-admin-password $WINDOWS_PASSWORD \
--vm-set-type VirtualMachineScaleSets \
--network-plugin azure

Transcurridos unos minutos, el comando se completa y devuelve información en formato JSON

sobre el clúster. En ocasiones, el clúster puede tardar más de unos minutos en aprovisionarse.
Espere hasta 10 minutos para que se produzca el aprovisionamiento.

Si recibe un error de validación de contraseña y la contraseña que estableció cumple los

requisitos de longitud y complejidad, pruebe a crear el grupo de recursos en otra región. A
continuación, intente crear el clúster con el nuevo grupo de recursos.

Si no especifica un nombre de usuario y una contraseña de administrador al crear el grupo de

nodos, el nombre de usuario se establece en azureuser y la contraseña se establece en un valor
aleatorio. Para obtener más información, consulte las preguntas más frecuentes de Windows
Server

El nombre de usuario del administrador no se puede cambiar, pero la contraseña de

administrador que el clúster de AKS usa para los nodos de Windows Server mediante az aks
update sí que se puede cambiar. Para obtener más información, consulte las preguntas más

frecuentes de Windows Server.

Para ejecutar un clúster de AKS que admita grupos de nodos para contenedores de
Windows Server, el clúster debe utilizar una directiva de red que use el complemento de red de
Azure CNI (avanzado) . El parámetro --network-plugin azure especifica Azure CNI.

Adición de un grupo de nodos

De forma predeterminada, se crea un clúster de AKS con un grupo de nodos que puede
ejecutar contenedores de Linux. Debe agregar otro grupo de nodos que pueda ejecutar
contenedores de Windows Server en combinación con el grupo de nodos de Linux.

Windows Server 2022 es el sistema operativo predeterminado para Kubernetes versiones 1.25.0
y posteriores. Windows Server 2019 es el sistema operativo predeterminado para versiones
anteriores. Si no especifica una SKU de sistema operativo determinada, Azure crea el grupo de
nodos con la SKU predeterminada de la versión de Kubernetes que usa el clúster.

Grupo de nodos de Windows (SKU predeterminada)

Para usar la SKU predeterminada del sistema operativo, cree el grupo de nodos sin
especificar ninguna SKU de sistema operativo. El grupo de nodos está configurado para el
sistema operativo predeterminado en función de la versión de Kubernetes del clúster.

Agregue un grupo de nodos de Windows con el comando az aks nodepool add . El

siguiente comando crea un nuevo grupo de nodos denominado npwin y lo agrega a
myAKSCluster. El comando también usa la subred predeterminada en la red virtual
predeterminada que se crea al ejecutar az aks create . No se especificó ninguna SKU del
sistema operativo, por lo que el grupo de nodos se establece en el sistema operativo
predeterminado en función de la versión de Kubernetes del clúster.

text

az aks nodepool add \

--resource-group $MY_RESOURCE_GROUP_NAME \
--cluster-name $MY_AKS_CLUSTER \
--os-type Windows \
--name npwin \
--node-count 1

Conectarse al clúster
Para administrar un clúster de Kubernetes, usará kubectl , el cliente de línea de comandos de
Kubernetes. Si usa Azure Cloud Shell, kubectl ya está instalado. Si desea instalar y ejecutar
kubectl localmente, llame al comando az aks install-cli.

1. Para configurar kubectl para conectarse a su clúster de Kubernetes, use el comando az

aks get-credentials. Con este comando se descargan las credenciales y se configura la CLI
de Kubernetes para usarlas.

Bash
 az aks get-credentials --resource-group $MY_RESOURCE_GROUP_NAME --name
$MY_AKS_CLUSTER

2. Compruebe la conexión al clúster, para lo que debe usar el comando kubectl get , que
devuelve una lista de los nodos del clúster.

Bash

kubectl get nodes -o wide

La siguiente salida de ejemplo muestra todos los nodos del clúster. Asegúrese de que el estado
de todos los nodos sea Listo:

text

NAME STATUS ROLES AGE VERSION INTERNAL-IP

EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-
RUNTIME
aks-nodepool1-20786768-vmss000000 Ready agent 22h v1.27.7 10.224.0.4
<none> Ubuntu 22.04.3 LTS 5.15.0-1052-azure
containerd://1.7.5-1
aks-nodepool1-20786768-vmss000001 Ready agent 22h v1.27.7 10.224.0.33
<none> Ubuntu 22.04.3 LTS 5.15.0-1052-azure
containerd://1.7.5-1
aksnpwin000000 Ready agent 20h v1.27.7 10.224.0.62
<none> Windows Server 2022 Datacenter 10.0.20348.2159
containerd://1.6.21+azure

７ Nota

El entorno de ejecución de contenedor para cada grupo de nodos se muestra en

CONTAINER-RUNTIME. Los valores del runtime del contenedor comienzan por
containerd:// , lo que significa que usan containerd para el runtime del contenedor.

Implementación de la aplicación
Un archivo de manifiesto de Kubernetes define un estado deseado del clúster, por ejemplo,
qué imágenes de contenedor se van a ejecutar. En este artículo, usará un manifiesto para crear
todos los objetos necesarios para ejecutar la aplicación de ejemplo de ASP.NET en un
contenedor de Windows Server. Este manifiesto incluye una implementación de Kubernetes
para la aplicación de ejemplo de ASP.NET y un servicio de Kubernetes externo para acceder a la
aplicación desde Internet.
La aplicación de ejemplo de ASP.NET se proporciona como parte de los ejemplos de .NET
Framework y se ejecuta en un contenedor de Windows Server. AKS requiere contenedores
de Windows Server que se basen en imágenes de Windows Server 2019 o una versión
posterior. El archivo de manifiesto de Kubernetes también debe definir un selector de nodos
que le indique al clúster de AKS que ejecute el pod de la aplicación de ejemplo de ASP.NET en
un nodo que pueda ejecutar contenedores de Windows Server.

1. Cree un archivo denominado sample.yaml y cópielo en la siguiente definición de código

YAML.

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
name: sample
labels:
app: sample
spec:
replicas: 1
template:
metadata:
name: sample
labels:
app: sample
spec:
nodeSelector:
"kubernetes.io/os": windows
containers:
- name: sample
image: mcr.microsoft.com/dotnet/framework/samples:aspnetapp
resources:
limits:
cpu: 1
memory: 800M
ports:
- containerPort: 80
selector:
matchLabels:
app: sample
---
apiVersion: v1
kind: Service
metadata:
name: sample
spec:
type: LoadBalancer
ports:
- protocol: TCP
port: 80
 selector:
app: sample

Para obtener un desglose de los archivos de manifiesto de YAML, consulte Implementaciones y

manifiestos de YAML.

Si crea y guarda el archivo YAML localmente, para cargar el archivo de manifiesto en el

directorio predeterminado de CloudShell, seleccione el botón Cargar y descargar archivos y
elija el archivo en el sistema de archivos local.

2. Implemente la aplicación mediante el comando kubectl apply y especifique el nombre

del manifiesto de YAML:

Bash

kubectl apply -f sample.yaml

En la salida de ejemplo siguiente se muestran la implementación y el servicio que se crearon

correctamente:

text

{
"deployment.apps/sample": "created",
"service/sample": "created"
}

Prueba de la aplicación
Cuando se ejecuta la aplicación, un servicio de Kubernetes expone el front-end de la aplicación
a Internet. Este proceso puede tardar unos minutos en completarse. En ocasiones, el servicio
puede tardar más de unos minutos en activarse. Espere hasta 10 minutos para que se produzca
el aprovisionamiento.

1. Compruebe el estado de los pods implementados con el comando kubectl get pods .
Asegúrate de que todos los pods tengan el estado Running antes de continuar.

Bash

kubectl get pods

2. Para supervisar el progreso, utilice el comando kubectl get service con el argumento --
watch .
 Bash

while true; do
export EXTERNAL_IP=$(kubectl get service sample -o jsonpath="
{.status.loadBalancer.ingress[0].ip}" 2>/dev/null)
if [[ -n "$EXTERNAL_IP" && "$EXTERNAL_IP" != "<pending>" ]]; then
kubectl get service sample
break
fi
echo "Still waiting for external IP assignment..."
sleep 5
done

Inicialmente, la salida muestra el parámetro EXTERNAL-IP del servicio de ejemplo como

pendiente:

text

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

sample LoadBalancer xx.xx.xx.xx pending xx:xxxx/TCP 2m

Cuando la dirección EXTERNAL-IP cambie de pendiente a una dirección IP pública real, use
CTRL-C para detener el proceso de inspección de kubectl . En la salida del ejemplo siguiente se

muestra una dirección IP pública válida asignada al servicio:

JSON

{
"NAME": "sample",
"TYPE": "LoadBalancer",
"CLUSTER-IP": "10.0.37.27",
"EXTERNAL-IP": "52.179.23.131",
"PORT(S)": "80:30572/TCP",
"AGE": "2m"
}

Para ver la aplicación de ejemplo en acción, abra un explorador web en la dirección IP externa
del servicio después de unos minutos.
 

Pasos siguientes
En este inicio rápido, ha implementado un clúster de Kubernetes y luego ha desplegado una
aplicación de ejemplo de ASP.NET en un contenedor de Windows Server. Esta aplicación de
ejemplo es solo para fines de demostración y no representa todos los procedimientos
recomendados para las aplicaciones de Kubernetes. Para instrucciones sobre cómo crear
soluciones completas con AKS para producción, consulte Guía de soluciones de AKS.

Para más información sobre AKS y obtener un ejemplo completo desde el código hasta la
implementación, continúe con el tutorial del clúster de Kubernetes.

Tutorial de AKS
Preguntas más frecuentes sobre Windows
Server en AKS
En este artículo se proporcionan respuestas a algunas de las preguntas más comunes sobre el
uso de contenedores de Windows Server en Azure Kubernetes Service (AKS).

¿Qué tipo de discos se admiten en

Windows?
Azure Disks y Azure Files son los tipos de volumen admitidos y se accede a ellos como
volúmenes del Sistema de archivos de nueva tecnología (NTFS) en el contenedor de Windows
Server.

¿Admite Windows máquinas virtuales de

generación 2?
Las máquinas virtuales de Generación 2 solo se admiten en Windows para WS2022.

Para más información, consulte Compatibilidad para máquinas virtuales de generación 2 en

Azure.

¿Cómo se aplica una revisión a los nodos

de Windows?
Para obtener las revisiones más recientes de los nodos de Windows, puede actualizar el grupo
de nodos o actualizar la imagen de los nodos.

¿Se admite la conservación de la IP de

origen del cliente?
En este momento, la conservación de la IP de origen del cliente no es compatible con los
nodos de Windows.

¿Se puede cambiar el número máximo de

pods por nodo?
Sí. Para más información, consulte Número máximo de pods.

¿Cuál es el tiempo de espera

predeterminado del protocolo de control
de transmisión (TCP) en el sistema
operativo Windows?
El tiempo de espera de TCP predeterminado en el sistema operativo Windows es de cuatro
minutos. Este valor no se puede configurar. Cuando una aplicación usa un tiempo de espera
más largo, las conexiones TCP entre distintos contenedores del mismo nodo se cierran después
de cuatro minutos.

¿Por qué se muestra un error al tratar de

crear un nuevo grupo de agentes de
Windows?
Si creó el clúster antes de febrero de 2020 y no ha hecho ninguna operación de actualización,
el clúster sigue usando una imagen antigua de Windows. Es posible que vea un error similar al
ejemplo siguiente:

"No se encuentra la siguiente lista de imágenes a las que se hace referencia desde la plantilla
de implementación: Publicador: MicrosoftWindowsServer, Oferta WindowsServer, Sku: 2019-
datacenter-core-smalldisk-2004, Versión: más raciente. Vea Búsqueda y uso de imágenes de
máquina virtual de Azure Marketplace con Azure PowerShell para obtener instrucciones para
encontrar imágenes disponibles."

Para corregir este problema, debe realizar los pasos siguientes:

1. Actualice el plano de control del clúster a fin de actualizar la oferta y el publicador de la

imagen.
2. Cree nuevos grupos de agentes de Windows.
3. Mueva los pods de Windows de los grupos de agentes de Windows existentes a los
nuevos.
4. Elimine los grupos de agentes de Windows anteriores.
¿Por qué se muestra un error al tratar de
implementar pods de Windows?
Si especifica un valor en --max-pods menor que el número de pods que desea crear, es posible
que vea el error No available addresses .

Para corregir este error, use el comando az aks nodepool add con un valor --max-pods
suficientemente alto. Por ejemplo:

Azure CLI

az aks nodepool add \

--cluster-name $CLUSTER_NAME \
--resource-group $RESOURCE_GROUP \
--name $NODEPOOL_NAME \
--max-pods 3

Para más información, consulte la --max-pods documentación.

¿Por qué hay un usuario inesperado

denominado "sshd" en mi nodo de
máquina virtual?
AKS agrega un usuario denominado "sshd" al instalar el servicio OpenSSH. Este usuario no es
malintencionado. Se recomienda que los clientes actualicen sus alertas para omitir esta cuenta
de usuario inesperada.

¿Cómo se realiza la rotación de la entidad

de servicio para el grupo de nodos de
Windows?
Los grupos de nodos de Windows no admiten la rotación de la entidad de servicio. Para
actualizar la entidad de servicio, cree un nuevo grupo de nodos de Windows y migre los pods
del grupo anterior al nuevo. Después de migrar los pods al nuevo grupo, elimine el grupo de
nodos anterior.

En lugar de las entidades de servicio, puede usar identidades administradas. Para más
información, consulte Uso de identidades administradas en AKS.
¿Cómo cambio la contraseña de
administrador de los nodos de Windows
Server en el clúster?
Para cambiar la contraseña de administrador mediante la CLI de Azure, use el comando az aks
update con el parámetro --admin-password . Por ejemplo:

Azure CLI

az aks update \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--admin-password <new-password>

Para cambiar la contraseña mediante Azure PowerShell, use el cmdlet Set-AzAksCluster con el
parámetro -AdminPassword . Por ejemplo:

Azure PowerShell

Set-AzAksCluster `
-ResourceGroupName $RESOURCE_GROUP `
-Name $CLUSTER_NAME `
-AdminPassword <new-password>

Tenga en cuenta que realizar una actualización del clúster provoca un reinicio y solo actualiza
los grupos de nodos de Windows Server. Para obtener información sobre los requisitos de
contraseña de Windows Server, consulte Requisitos de contraseña de Windows Server.

¿Cuántos grupos de nodos puedo crear?

Los clústeres de AKS con grupos de nodos de Windows tienen los mismos límites de recursos
que los límites predeterminados especificados para el servicio AKS. Consulte Cuotas,
restricciones de tamaño de máquinas virtuales y disponibilidad de regiones en Azure
Kubernetes Service (AKS).

¿Puedo ejecutar controladores de entrada

en los nodos de Windows?
Sí, puede ejecutar controladores de entrada que admitan contenedores de Windows Server.
¿Pueden usar gMSA los contenedores de
Windows Server?
Sí. La compatibilidad con la cuenta de servicio administrada por grupo (gMSA) está disponible
con carácter general (GA) para Windows en AKS. Para más información, consulte Habilitación
de cuentas de servicio administradas de grupo (GMSA) para los nodos de Windows Server en
el clúster de Azure Kubernetes Service (AKS)

¿Existe alguna limitación en el número de

servicios que puede haber en un clúster
con nodos de Windows?
Un clúster con nodos de Windows puede tener aproximadamente 500 servicios (algunas veces
menos) antes de que se agote el puerto. Esta limitación se aplica a un servicio de Kubernetes
con la directiva de tráfico externo establecida en "Clúster".

Cuando la directiva de tráfico externo en un servicio está configurada como un clúster, el

tráfico se somete a una NAT de origen adicional en el nodo. Este proceso también da como
resultado la reserva de un puerto del grupo de puertos dinámicos TCPIP. Este grupo de puertos
es un recurso limitado (unos 16 000 puertos de forma predeterminada) y muchas conexiones
activas a un servicio pueden dar lugar a un agotamiento dinámico del grupo de puertos, lo que
provoca caídas de conexión.

Si Kubernetes Service está configurado con la directiva de tráfico externo establecida en

"Local", es probable que los problemas de agotamiento de puertos no se produzcan en 500
servicios.

¿Cómo se cambia la zona horaria de un

contenedor en ejecución?
Para cambiar la zona horaria de un contenedor de Windows Server en ejecución, conéctese al
contenedor en ejecución con una sesión de PowerShell. Por ejemplo:

Azure CLI

kubectl exec -it CONTAINER-NAME -- powershell

En el contenedor en ejecución, use Set-TimeZone para establecer la zona horaria del
contenedor en ejecución. Por ejemplo:

Azure PowerShell

Set-TimeZone -Id "Russian Standard Time"

Para ver la zona horaria actual del contenedor en ejecución o una lista disponible de zonas
horarias, use Get-TimeZone.
Inicio rápido: Ejecución de un contenedor
personalizado en Azure
Artículo • 03/03/2025

Azure App Serviceen Linux proporciona pilas de aplicaciones predefinidas en Linux compatibles
con lenguajes como .NET, Java, Node.js y PHP. También puede usar una imagen personalizada
de Docker para ejecutar la aplicación web en una pila de aplicaciones aún sin definir en Azure.
En este inicio rápido se muestra cómo implementar una imagen desde Azure Container
Registry (ACR) en App Service.

Para obtener más información sobre las aplicaciones en contenedores en un entorno sin
servidor, consulte Container Apps.

Requisitos previos
Una cuenta de Azure .
Docker .
Visual Studio Code .
La extensión de Azure App Service para VS Code . Puede usar esta extensión para crear,
administrar e implementar Web Apps de Linux en la Plataforma como servicio (PaaS) de
Azure.
La extensión de Docker para VS Code . Puede usar esta extensión para simplificar la
administración de imágenes y comandos locales de Docker e implementar imágenes de
aplicaciones compiladas en Azure.

Creación de un Registro de contenedor

En este inicio rápido se usa Azure Container Registry como registro. Puede usar otros registros,
pero los pasos pueden diferir ligeramente.

Cree un registro de contenedor según las instrucciones que se indican en Inicio rápido:
Creación de un instancia de Azure Container Registry mediante Azure Portal.

） Importante

Asegúrese de establecer la opción Usuario administrador en Habilitar al crear el registro

de contenedor de Azure. También puede establecerla en la sección Claves de acceso de la
página de registro en Azure Portal. Esta opción de configuración es necesaria para el
 acceso a App Service. Para obtener información sobre la identidad administrada, consulte
Implementación desde el tutorial de ACR.

Iniciar sesión
1. Inicie Visual Studio Code.

2. Seleccione el logotipo de Azure en la barra de actividades y vaya a CUENTAS e

INQUILINOS. Seleccione Iniciar sesión en Azure y siga las instrucciones.

3. En la barra de estado de la parte inferior, compruebe la dirección de correo electrónico

de la cuenta de Azure. Se debe mostrar la suscripción en el explorador APP SERVICE.

4. En la barra de actividades, seleccione el logotipo de Docker. En el explorador REGISTROS,

compruebe que aparece el registro de contenedor que ha creado.

Comprobación de los requisitos previos

Compruebe que Docker está instalado y en ejecución. El comando siguiente muestra la versión
de Docker si se está ejecutando.

Bash

docker --version

Creación y compilación de una imagen

1. En Visual Studio Code, abra una carpeta vacía y agregue un archivo denominado
Dockerfile. En Dockerfile, pegue el contenido en función del marco de lenguaje deseado:

.NET

En este archivo Dockerfile, la imagen primaria es uno de los contenedores de .NET

integrados de App Service.

Dockerfile

FROM mcr.microsoft.com/appsvc/dotnetcore:lts

ENV PORT 8080

EXPOSE 8080

ENV ASPNETCORE_URLS "http://*:${PORT}"

ENTRYPOINT ["dotnet", "/defaulthome/hostingstart/hostingstart.dll"]

2. Abra la paleta de comandos y escriba Docker Images: Build Image (Imágenes de

Docker: compilar imagen). Seleccione Entrar para ejecutar el comando.

3. En el cuadro de etiqueta de imagen, especifique la etiqueta que desee en el formato

siguiente: <acr-name>.azurecr.io/<image-name>:<tag> , donde <acr-name> es el nombre
del registro de contenedor que ha creado. Seleccione Entrar.

4. Cuando la imagen termine de compilarse, seleccione Actualizar en la parte superior del

explorador IMAGES y compruebe que la imagen se ha compilado correctamente.
Implementación en el registro de contenedor
1. En la barra de actividades, seleccione el icono de Docker. En el explorador IMÁGENES,
busque la imagen compiló.

2. Expanda la imagen, haga clic con el botón derecho en la etiqueta que desee y seleccione
Insertar.

3. Asegúrese de que la etiqueta de imagen comienza por <acr-name>.azurecr.io y pulse

Entrar.

4. Cuando Visual Studio Code finalice la inserción de la imagen en el registro de

contenedor, seleccione Actualizar en la parte superior del explorador REGISTROS y
compruebe que la imagen se ha insertado correctamente.

Implementación en App Service

1. En el explorador REGISTROS, expanda la imagen, haga clic derecho en la etiqueta y
seleccione Implementar imagen en Azure App Service.
 2. Siga las indicaciones para elegir una suscripción, un nombre de aplicación globalmente
único, un grupo de recursos y un plan de App Service. Elija B1 Básico como plan de tarifa
y una región cercana.

Después de la implementación, la aplicación está disponible en http://<app-

name>.azurewebsites.net .

Un grupo de recursos es una colección con nombre de todos los recursos de la aplicación en
Azure. Por ejemplo, un grupo de recursos puede contener una referencia a un sitio web, una
base de datos y una función de Azure.

Un plan de App Service define los recursos físicos que se usarán para hospedar el sitio web. En
este inicio rápido se usa un plan de hospedaje de Básico en infraestructura de Linux, lo que
significa que el sitio se hospeda en una máquina Linux junto con otros sitios web. Si empieza
con el plan básico, puede usar Azure Portal para escalar verticalmente de modo que el suyo
sea el único sitio que se ejecute en una máquina. Para conocer los precios, consulte Precios de
App Service .

Exploración del sitio web

El panel Salida muestra el estado de las operaciones de implementación. Cuando finalice la
operación, seleccione Abrir sitio en la notificación emergente para abrir el sitio en el
explorador.

He tenido un problema

Limpieza de recursos
En los pasos anteriores, creó recursos de Azure en un grupo de recursos. Si no cree que vaya a
necesitar estos recursos en el futuro, puede eliminarlos mediante la eliminación del grupo de
recursos.

En el menú de Azure Portal o la página Inicio, seleccione Grupos de recursos. En la página

Grupos de recursos, seleccione myResourceGroup.

En la página myResourceGroup, asegúrese de que los recursos enumerados sean los que
desea eliminar.

Seleccione Eliminar grupo de recursos, escriba myResourceGroup en el cuadro de texto para

confirmar y, después, seleccione Eliminar.
Contenido relacionado
Enhorabuena, ha completado correctamente este inicio rápido

La aplicación de App Service extrae del registro de contenedor cada vez que se inicia. Si
recompila la imagen, solo tiene que insertarla en el registro de contenedor y la aplicación
extrae la imagen actualizada cuando se reinicia. Para indicar a la aplicación que extraiga la
imagen actualizada inmediatamente, reiníciela.

Protección con un certificado y dominio personalizado

Migrar al contenedor de Windows en Azure
Integración de su aplicación con una instancia de Azure Virtual Network
Puntos de conexión privados para aplicaciones de App Service
Introducción a Azure Monitor
Información general sobre la supervisión de aplicaciones para Azure App Service
Cómo usar identidades administradas para App Service y Azure Functions
Configuración de un contenedor personalizado
Tutorial del contenedor Sidecar

Otras extensiones de Azure:

Azure Cosmos DB
Funciones de Azure
Herramientas de la CLI de Azure
Herramientas de Azure Resource Manager
Paquete de extensiones de Azure Tools incluye todas las extensiones de esta lista.
Migración de software personalizado a
Azure App Service mediante un contenedor
personalizado
Artículo • 04/09/2024

Azure App Service usa la tecnología de contenedores de Docker para hospedar imágenes
integradas e imágenes personalizadas. Para ver una lista de imágenes integradas, ejecute el
comando de la CLI de Azure 'az webapp list-runtimes --os linux'. Si esas imágenes no
satisfacen sus necesidades, puede crear e implementar una imagen personalizada.

７ Nota

El contenedor debe tener como destino la arquitectura x86-64. No se admite ARM64.

En este tutorial, aprenderá a:

＂ Inserte una imagen personalizada de Docker en Azure Container Registry.

＂ Implemente la imagen personalizada en App Service.
＂ Configure variables de entorno.
＂ Extraiga la imagen en App Service mediante una identidad administrada.
＂ Acceda a los registros de diagnóstico.
＂ Habilite CI/CD desde Azure Container Registry en App Service.
＂ Conéctese al contenedor mediante SSH.

Al completar este tutorial, se incurre en un pequeño gasto en la cuenta de Azure para el

registro de contenedor y puede suponer costos adicionales si hospeda el contenedor durante
más de un mes.

Configuración del entorno inicial

En este tutorial se necesita la versión 2.0.80, o versiones posteriores, de la CLI de Azure. Si usa
Azure Cloud Shell, ya está instalada la versión más reciente.

Disponga de una cuenta de Azure con una suscripción activa. Cree una cuenta gratuita .

Use el entorno de Bash en Azure Cloud Shell. Para más información, consulte Inicio rápido
para Bash en Azure Cloud Shell.
 Si prefiere ejecutar comandos de referencia de la CLI localmente, instale la CLI de Azure.
Si utiliza Windows o macOS, considere la posibilidad de ejecutar la CLI de Azure en un
contenedor Docker. Para más información, vea Ejecución de la CLI de Azure en un
contenedor de Docker.

Si usa una instalación local, inicie sesión en la CLI de Azure mediante el comando az
login. Siga los pasos que se muestran en el terminal para completar el proceso de
autenticación. Para ver otras opciones de inicio de sesión, consulte Inicio de sesión con
la CLI de Azure.

En caso de que se le solicite, instale las extensiones de la CLI de Azure la primera vez
que la use. Para más información sobre las extensiones, consulte Uso de extensiones
con la CLI de Azure.

Ejecute az version para buscar cuál es la versión y las bibliotecas dependientes que
están instaladas. Para realizar la actualización a la versión más reciente, ejecute az
upgrade.

Instale Docker , el cual se usará para compilar imágenes de Docker. La instalación de

Docker puede requerir reiniciar el equipo.

Después de instalar Docker, abra una ventana de terminal y compruebe que Docker está
instalado:

Bash

docker --version

Clonación o descarga de la aplicación de ejemplo

Puede obtener el ejemplo de este tutorial a través de Git Clone o mediante descarga.

Clonación con Git

Clone el repositorio de ejemplo:

terminal

git clone https://github.com/Azure-Samples/docker-django-webapp-linux.git --config

core.autocrlf=input

Asegúrese de incluir el argumento --config core.autocrlf=input para garantizar los finales de

línea correctos en los archivos que se usan en el contenedor de Linux.
Después, vaya a la carpeta:

terminal

cd docker-django-webapp-linux

Descargar desde GitHub

En lugar de usar git clone, puede visitar https://github.com/Azure-Samples/docker-django-
webapp-linux y seleccionar Código>Local>Descargar ZIP.

Descomprima el archivo ZIP en una carpeta denominada docker-django-webapp-linux.

Después, abra una ventana de terminal en la carpeta docker-django-webapp-linux.

(Opcional) Examen del archivo de Docker

Este es el archivo del ejemplo denominado Dockerfile. Describe la imagen de Docker y contiene
instrucciones de configuración.

Dockerfile

FROM tiangolo/uwsgi-nginx-flask:python3.6

RUN mkdir /code

WORKDIR /code
ADD requirements.txt /code/
RUN pip install -r requirements.txt --no-cache-dir
ADD . /code/

# ssh
ENV SSH_PASSWD "root:Docker!"
RUN apt-get update \
&& apt-get install -y --no-install-recommends dialog \
&& apt-get update \
&& apt-get install -y --no-install-recommends openssh-server \
&& echo "$SSH_PASSWD" | chpasswd

COPY sshd_config /etc/ssh/

COPY init.sh /usr/local/bin/

RUN chmod u+x /usr/local/bin/init.sh

EXPOSE 8000 2222

#CMD ["python", "/code/manage.py", "runserver", "0.0.0.0:8000"]

ENTRYPOINT ["init.sh"]
 El primer grupo de comandos instala los requisitos de la aplicación en el entorno.
El segundo grupo de comandos crea un servidor SSH para ofrecer comunicación
segura y mejorada entre el contenedor y el host.
La última línea del archivo, ENTRYPOINT ["init.sh"] , invoca a init.sh para iniciar el
servicio SSH y el servidor de Python.

Compilación y prueba de la imagen de forma local

７ Nota

Docker Hub tiene cuotas para el número de extracciones anónimas por IP y el número
de extracciones autenticadas por usuario gratuito. Si observa que las extracciones de
Docker Hub están limitadas, pruebe docker login si aún no ha iniciado sesión.

1. Ejecute el siguiente comando para compilar la imagen:

Bash

docker build --tag appsvc-tutorial-custom-image .

2. Ejecute el contenedor de Docker de forma local para comprobar que la compilación

funciona:

Bash

docker run -it -p 8000:8000 appsvc-tutorial-custom-image

Este comando docker run especifica el puerto con el argumento -p e incluye el

nombre de la imagen. -it le permite detenerlo con Ctrl+C.

 Sugerencia

Si ejecuta Windows y ve el error standard_init_linux.go:211: exec user process caused

"no such file or directory" (el proceso de usuario ejecutado provocó el error "no existe
dicho archivo o directorio"), el archivo init.sh contiene los finales de línea CRLF en
lugar de los finales LF esperados. Este error se produce si ha usado Git para clonar el
repositorio de ejemplo, pero ha omitido el parámetro --config core.autocrlf=input .
En este caso, vuelva a clonar el repositorio con el argumento --config . También
 puede ver el error si editó init.sh y lo guardó con finales CR o LF. En este caso,
guarde el archivo de nuevo solo con los finales LF.

3. Vaya a http://localhost:8000 para comprobar que la aplicación web y el contenedor

funcionan correctamente.

I. Crear una identidad administrada asignada por el

usuario
App Service puede usar una identidad administrada predeterminada o una identidad
administrada asignada por el usuario para autenticarse con un registro de contenedor. En este
tutorial, usará una identidad administrada asignada por el usuario.

CLI de Azure

1. Ejecute el comando az group create para crear un grupo de recursos:

Azure CLI

az group create --name msdocs-custom-container-tutorial --location

westeurope
 Puede cambiar el valor de --location para especificar una región cercana.

2. Cree una identidad administrada en el grupo de recursos:

Azure CLI

az identity create --name myID --resource-group msdocs-custom-container-

tutorial

II. Creación de un Registro de contenedor

CLI de Azure

1. Cree un registro de contenedor mediante el comando az acr create siguiente.

Reemplace <registry-name> por un nombre único para el registro. El nombre debe
contener solo letras y números, y debe ser único en todo Azure.

Azure CLI

az acr create --name <registry-name> --resource-group msdocs-custom-

container-tutorial --sku Basic --admin-enabled true

El parámetro --admin-enabled le permite insertar imágenes en el registro mediante

credenciales administrativas.

2. Para recuperar las credenciales administrativas, ejecute el comando az credential acr

show:

Azure CLI

az acr credential show --resource-group msdocs-custom-container-tutorial

--name <registry-name>

La salida JSON de este comando proporciona dos contraseñas junto con el nombre
de usuario del registro.

III. Inserción de la imagen de ejemplo en Azure

Container Registry
En esta sección, va a insertar en Azure Container Registry la imagen que App Service usará más
adelante.

1. Desde el terminal local donde creó la imagen de ejemplo, use el comando docker login
para iniciar sesión en el registro de contenedor:

Bash

docker login <registry-name>.azurecr.io --username <registry-username>

Reemplace <registry-name> y <registry-username> por los valores de los pasos

anteriores. Cuando se le solicite, escriba una de las contraseñas de la sección anterior.

Use el mismo nombre de registro en el resto de pasos de esta sección.

2. Cuando el inicio de sesión se haya realizado correctamente, etiquete la imagen de Docker

local en el registro:

Bash

docker tag appsvc-tutorial-custom-image <registry-name>.azurecr.io/appsvc-

tutorial-custom-image:latest

3. Use el comando docker push para enviar la imagen al registro:

Bash

docker push <registry-name>.azurecr.io/appsvc-tutorial-custom-image:latest

La primera vez que la imagen se carga puede tardar unos minutos, ya que incluye la
imagen base. Las cargas posteriores suelen ser más rápidas.

Mientras espera, puede completar los pasos de la sección siguiente para configurar App
Service de modo que la implementación se haga desde el registro.

IV. Autorización de la identidad administrada para

el registro
La identidad administrada que ha creado aún no tiene autorización para extraer datos del
registro de contenedor. En este paso, habilitará la autorización.

CLI de Azure
 1. Recupere el identificador de entidad de seguridad de la identidad administrada:

Azure CLI

principalId=$(az identity show --resource-group msdocs-custom-container-

tutorial --name myID --query principalId --output tsv)

2. Recupere el identificador de recurso del registro de contenedor:

Azure CLI

registryId=$(az acr show --resource-group msdocs-custom-container-

tutorial --name <registry-name> --query id --output tsv)

3. Conceda permiso a la identidad administrada para acceder al registro de contenedor:

Azure CLI

az role assignment create --assignee $principalId --scope $registryId --

role "AcrPull"

Para más información sobre estos permisos, vea ¿Qué es el control de acceso basado
en rol de Azure?.

V. Creación de la aplicación web

CLI de Azure

1. Cree un plan de App Service mediante el comando az appservice plan create:

Azure CLI

az appservice plan create --name myAppServicePlan --resource-group

msdocs-custom-container-tutorial --is-linux

Un plan de App Service corresponde a la máquina virtual que hospeda la aplicación

web. De manera predeterminada, el comando anterior usa un plan de tarifa B1
económico que es gratuito durante el primer mes. Puede especificar el nivel
mediante el parámetro --sku .
 2. Cree la aplicación web con el comando az webapp create:

Azure CLI

az webapp create --resource-group msdocs-custom-container-tutorial --plan

myAppServicePlan --name <app-name> --deployment-container-image-name
<registry-name>.azurecr.io/appsvc-tutorial-custom-image:latest

Reemplace <app-name> por un nombre para la aplicación web. El nombre debe ser
único en todo Azure. Reemplace también <registry-name> por el nombre del
registro de la sección anterior.

 Sugerencia

Puede recuperar la configuración del contenedor de la aplicación web en

cualquier momento con el comando az webapp config container show --name
<app-name> --resource-group msdocs-custom-container-tutorial . La imagen se

especifica en la propiedad DOCKER_CUSTOM_IMAGE_NAME . Cuando la aplicación web

se implementa con Azure DevOps o con las plantillas de Azure Resource
Manager, la imagen también puede aparecer en una propiedad denominada
LinuxFxVersion . Ambas propiedades tienen el mismo propósito. Si ambas están

presentes en la configuración de la aplicación web, LinuxFxVersion tiene

prioridad.

VI. Configuración de la aplicación web

En este paso, configurará la aplicación web de la siguiente manera:

Configure la aplicación para enviar solicitudes al puerto 8000. El contenedor de ejemplo

escucha las solicitudes web en el puerto 8000.
Indique a la aplicación que use la identidad administrada para extraer imágenes del
registro de contenedor.
Configure la implementación continua desde el registro de contenedor (cada inserción de
imagen en el registro provocará que la aplicación extraiga la nueva imagen). Este
elemento no es necesario para que la aplicación web extraiga del registro de contenedor,
pero puede permitir que la aplicación web sepa cuándo se inserta una nueva imagen en
el registro. Sin ella, debe desencadenar manualmente una extracción de imágenes
reiniciando la aplicación web.
CLI de Azure

1. Use az webapp config appsettings set para establecer la variable de entorno

WEBSITES_PORT según lo esperado por el código de la aplicación:

Azure CLI

az webapp config appsettings set --resource-group msdocs-custom-

container-tutorial --name <app-name> --settings WEBSITES_PORT=8000

Reemplace <app-name> por el valor que usó en el paso anterior.

2. Habilite la identidad administrada asignada por el usuario en la aplicación web con el

comando az webapp identity assign:

Azure CLI

id=$(az identity show --resource-group msdocs-custom-container-tutorial -

-name myID --query id --output tsv)
az webapp identity assign --resource-group msdocs-custom-container-
tutorial --name <app-name> --identities $id

Reemplace <app-name> por el valor que usó en el paso anterior.

3. Configure la aplicación para extraer de Azure Container Registry mediante

identidades administradas.

Azure CLI

appConfig=$(az webapp config show --resource-group msdocs-custom-

container-tutorial --name <app-name> --query id --output tsv)
az resource update --ids $appConfig --set
properties.acrUseManagedIdentityCreds=True

Reemplace <app-name> por el valor que usó en el paso anterior.

4. Establezca el identificador de cliente que usa la aplicación web para extraer de Azure
Container Registry. Este paso no es necesario si usa la identidad administrada
asignada por el sistema.

Azure CLI

clientId=$(az identity show --resource-group msdocs-custom-container-

tutorial --name myID --query clientId --output tsv)
 az resource update --ids $appConfig --set
properties.AcrUserManagedIdentityID=$clientId

5. Habilite CI/CD en App Service.

Azure CLI

cicdUrl=$(az webapp deployment container config --enable-cd true --name

<app-name> --resource-group msdocs-custom-container-tutorial --query
CI_CD_URL --output tsv)

CI_CD_URL es una dirección URL que App Service genera automáticamente. El

registro debe usar esta dirección URL para notificar a App Service que se ha
producido una inserción de imagen. En realidad, no crea el webhook
automáticamente.

6. Cree un webhook en el registro de contenedor mediante la dirección CI_CD_URL que

obtuvo en el último paso.

Azure CLI

az acr webhook create --name appserviceCD --registry <registry-name> --

uri $cicdUrl --actions push --scope appsvc-tutorial-custom-image:latest

7. Para probar si el webhook está configurado correctamente, haga ping en el webhook

y compruebe si obtiene una respuesta 200 OK.

Azure CLI

eventId=$(az acr webhook ping --name appserviceCD --registry <registry-

name> --query id --output tsv)
az acr webhook list-events --name appserviceCD --registry <registry-name>
--query "[?id=='$eventId'].eventResponseMessage"

 Sugerencia

Para ver toda la información sobre todos los eventos de webhook, quite el
parámetro --query .

Si transmite el registro de contenedor, debería ver un mensaje Starting

container for site después del ping en el webhook porque el webhook

desencadena el reinicio de la aplicación.

VII. Navegación hasta la aplicación web
CLI de Azure

Para probar la aplicación, vaya a https://<app-name>.azurewebsites.net . Reemplace <app-

name> por el nombre de la aplicación web.

La primera vez que intente acceder a la aplicación, es posible que tarde algún tiempo en
responder porque App Service debe extraer toda la imagen del registro. Si el tiempo del
explorador se agota, simplemente actualice la página. Una vez que se extraiga la imagen inicial,
las pruebas posteriores se ejecutarán mucho más rápido.

VIII. Acceso a los registros de diagnóstico

CLI de Azure

Mientras espera a que App Service extraiga la imagen, resulta útil para ver exactamente lo
que hace App Service transmitiendo los registros del contenedor al terminal.

1. Active el registro de contenedor:

 Azure CLI

az webapp log config --name <app-name> --resource-group msdocs-custom-

container-tutorial --docker-container-logging filesystem

2. Habilite el streaming de registro:

Azure CLI

az webapp log tail --name <app-name> --resource-group msdocs-custom-

container-tutorial

Si no ve los registros de la consola de inmediato, vuelve a comprobarlo en 30

segundos.

También puede inspeccionar los archivos de registro desde el explorador en

https://<app-name>.scm.azurewebsites.net/api/logs/docker .

3. Para detener el streaming de registro en cualquier momento, presione Ctrl+C.

IX. Modificación del código de la aplicación y

nueva implementación
En esta sección, realizará un cambio en el código de la aplicación web, reconstruirá la imagen
y, a continuación, lo enviará al registro de contenedor. A continuación, App Service extrae
automáticamente la imagen actualizada del registro para actualizar la aplicación web en
ejecución.

1. En la carpeta local docker-django-webapp-linux, abra el archivo

app/templates/app/index.html.

2. Cambie el primer elemento HTML para que coincida con el código siguiente.

HTML

<nav class="navbar navbar-inverse navbar-fixed-top">

<div class="container">
<div class="navbar-header">
<a class="navbar-brand" href="#">Azure App Service - Updated Here!</a>
</div>
</div>
</nav>
 3. Guarde los cambios.

4. Cambie a la carpeta docker-django-webapp-linux y vuelva a generar la imagen:

Bash

docker build --tag appsvc-tutorial-custom-image .

5. Actualice la etiqueta de la imagen a latest :

Bash

docker tag appsvc-tutorial-custom-image <registry-name>.azurecr.io/appsvc-

tutorial-custom-image:latest

Reemplace <registry-name> por el nombre del registro.

6. Inserte la imagen en el registro:

Bash

docker push <registry-name>.azurecr.io/appsvc-tutorial-custom-image:latest

7. Una vez que se complete la inserción de la imagen, el webhook notifica a App Service la
inserción y App Service intenta extraer la imagen actualizada. Espere unos minutos y, a
continuación, compruebe que la actualización se ha implementado. Para ello, vaya a
https://<app-name>.azurewebsites.net .

X. Conexión al contenedor con SSH

SSH habilita la comunicación segura mejorada entre un contenedor y un cliente. Para habilitar
una conexión SSH al contenedor, debe configurar la imagen personalizada para ello. Una vez
que el contenedor esté en ejecución, puede abrir una conexión SSH.

Configuración del contenedor para SSH

La aplicación de ejemplo que se usa en este tutorial ya tiene la configuración necesaria en el
archivo Dockerfile que instala el servidor SSH y que también establece las credenciales de inicio
de sesión. Esta sección solo es meramente informativa. Para conectarse al contenedor, vaya a la
sección siguiente.

Dockerfile
 ENV SSH_PASSWD "root:Docker!"
RUN apt-get update \
&& apt-get install -y --no-install-recommends dialog \
&& apt-get update \
&& apt-get install -y --no-install-recommends openssh-server \
&& echo "$SSH_PASSWD" | chpasswd

７ Nota

Esta configuración no permite realizar conexiones externas al contenedor. SSH solo está
disponible en el sitio de Kudu/SCM. El sitio de Kudu/SCM se autentica con la cuenta de
Azure. root:Docker! no se debe modificar al usar SSH. SCM/KUDU usará las credenciales
de Azure Portal. Al cambiar este valor, se producirá un error al usar SSH.

El archivo Dockerfile también copia el archivo sshd_config en la carpeta /etc/ssh/ y expone el

puerto 2222 en el contenedor:

Dockerfile

COPY sshd_config /etc/ssh/

# ...

EXPOSE 8000 2222

Se trata de un puerto interno al que solo pueden acceder los contenedores que se encuentren
en la red puente de una red privada virtual.

Por último, el script de entrada, init.sh, inicia el servidor SSH.

Bash

#!/bin/bash
service ssh start

Apertura de la conexión SSH al contenedor

CLI de Azure

1. Vaya a https://<app-name>.scm.azurewebsites.net/webssh/host e inicie sesión con su

cuenta de Azure. Reemplace <app-name> por el nombre de la aplicación web.
 2. Una vez que haya iniciado sesión, se le redirigirá a una página de información de la
aplicación web. Seleccione SSH en la parte superior de la página para abrir el shell y
usar los comandos.

Por ejemplo, puede examinar los procesos que se ejecutan dentro de la aplicación
mediante el comando top .

XI. Limpieza de recursos

CLI de Azure

Los recursos que creó en este artículo pueden incurrir en costos continuos. Para limpiar los
recursos, solo tiene que eliminar el grupo de recursos que los contiene:

Azure CLI

az group delete --name msdocs-custom-container-tutorial

Pasos siguientes
¿Qué ha aprendido?

＂ Inserte una imagen personalizada de Docker en Azure Container Registry.

＂ Implemente la imagen personalizada en App Service.
＂ Configure variables de entorno.
＂ Extraiga la imagen en App Service mediante una identidad administrada.
＂ Acceda a los registros de diagnóstico.
＂ Habilite CI/CD desde Azure Container Registry en App Service.
＂ Conéctese al contenedor mediante SSH.

En el tutorial siguiente, aprenderá a proporcionar seguridad para la aplicación con un dominio

personalizado y un certificado.

Protección con un certificado y dominio personalizado

O bien, eche un vistazo a otros recursos:

Configurar un contenedor personalizado

Tutorial: Configuración de un contenedor sidecar para un contenedor personalizado en
Azure App Service (versión preliminar)
Soluciones de contenedor de Windows
Artículo • 23/01/2025

Microsoft proporciona soluciones para contenedores de Windows con las imágenes

base de Windows Server 2022 más recientes para ayudar a nuestros consumidores a
empezar. Se trata de una colección de ejemplos en torno a marcos de aplicaciones,
lenguajes de programación, bases de datos e herramientas de integración continua (CI)
e infraestructura. Estos ejemplos se proporcionan tal cual y sin garantías ni garantías
realizadas. No dude en contribuir a ejemplos adicionales o enviar una solicitud de
incorporación de cambios para ayudar a mejorar el repositorio actual.

¿Qué son los contenedores de Windows?

Los contenedores son una tecnología para empaquetar y ejecutar aplicaciones de
Windows y Linux en diversos entornos locales y en la nube. Los contenedores
proporcionan un entorno ligero y aislado que facilita el desarrollo, implementación y
administración de las aplicaciones. Los contenedores se inician y detienen rápidamente,
por lo que son ideales para las aplicaciones que necesitan adaptarse rápidamente a la
demanda cambiante.

Todos los contenedores se crean a partir de imágenes de contenedor. Una imagen de

contenedor es un conjunto de archivos organizados en una pila de capas que se
hospeda en el equipo local o en un registro de contenedor remoto. Las imágenes de
contenedor usadas en los ejemplos descritos en este tema son imágenes basadas en
Windows Server, Windows Server Core y Nano Server:

Windows Server contiene el conjunto completo de API de Windows y servicios del

sistema.
Windows Server Core es una imagen más pequeña que contiene un subconjunto
de las API de Windows Server, es decir, el marco completo de .NET. También
incluye la mayoría, pero no todos, los roles de servidor (por ejemplo, el servidor de
fax no está incluido).
Nano Server es la imagen de Windows Server más pequeña e incluye
compatibilidad con las API de .NET Core y algunos roles de servidor.

Las imágenes base de Windows usadas para los ejemplos de contenedor son Windows
Server 2022, que se publicó en agosto de 2021. Los ejemplos le ayudan a empezar a
usar contenedores de Windows, por ejemplo, uno de los ejemplos le ayuda a instalar
bits de Python dentro de un contenedor de Windows.
Soluciones de contenedor
Use las pestañas de categorías siguientes para obtener información sobre cómo
aprovechar los contenedores de Windows con las imágenes base de Windows Server
más recientes en el desarrollo de aplicaciones. Los ejemplos proporcionados se ajustan
a seis categorías y se actualizan para reflejar los cambios de versión recientes, así como
la siguiente imagen de contenedor del sistema operativo base de Windows Server en
Docker Hub:

Windows Server
Windows Server Core
Nano Server

７ Nota

También puede usar guías de implementación paso a paso para ayudarle a

implementar una solución de ejemplo. Cada guía también puede hacer referencia a
un ejemplo de código complementario.

Marcos de trabajo de aplicaciones

aspnet

iis

iis-arr

iis-https

iis-php

Django

apache-http

apache-http-php

nginx

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Configuración de contenedores de Linux
en Windows
Artículo • 05/02/2025

Los contenedores de Linux constituyen un gran porcentaje del ecosistema de

contenedores general y son fundamentales para las experiencias de desarrollo y los
entornos de producción. Dado que los contenedores comparten un kernel con el host
de contenedor, la ejecución de contenedores de Linux directamente en Windows no es
una opción. Aquí es donde la virtualización entra en la imagen.

El ejercicio le guía por la creación y ejecución de contenedores de Linux en Windows 10

y Windows 11.

En este inicio rápido, harás lo siguiente:

1. Instalación de Docker Desktop

2. Ejecución de un contenedor de Linux sencillo

Prerrequisitos
Asegúrese de cumplir los siguientes requisitos:

Un sistema de equipo físico que ejecuta Windows 10 Professional, Windows 10

Enterprise o posterior. O Windows Server 2019, versión 1809 o posterior
Asegúrese de que Hyper-V está habilitado.

Instalación de Docker Desktop

Instale Docker Desktop en Windows.

Ejecución del primer contenedor de Linux

Para ejecutar contenedores de Linux, debe asegurarse de que Docker tiene como
destino el demonio correcto. Para alternar esto, seleccione Switch to Linux Containers
en el menú de acciones al hacer clic en el icono de ballena de Docker en la bandeja del
sistema. Si ve Switch to Windows Containers , entonces ya apunta al demonio de Linux.
Una vez que haya confirmado que tiene como destino el demonio correcto, ejecute el
contenedor con el siguiente comando:

Consola

docker run --rm busybox echo hello_world

El contenedor se ejecuta, imprime "hello_world" y, a continuación, se cierra.

Al consultar docker images , verá la imagen de contenedor de Linux que acaba de

extraer y ejecutar:

Consola

docker images

REPOSITORY TAG IMAGE ID CREATED

SIZE
busybox latest 59788edf1f3e 4 weeks ago
3.41MB

Pasos siguientes
 Aprenda a compilar una aplicación de ejemplo

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Usar contenedores con el Programa
Windows Insider
Artículo • 23/01/2025

En este tema recorrerás el proceso de implementación y el uso de la función de

contenedor de Windows en la última compilación para Insider de Windows Server desde
el programa Windows Insider Preview. Durante este ejercicio, instalarás el rol de
contenedor e implementará una edición de vista previa de las imágenes de sistema
operativo base. Si necesitas familiarizarte con los contenedores, encontrarás esta
información en Acerca de los contenedores.

Únase al Programa Windows Insider

Para ejecutar la versión de Insider de los contenedores de Windows, debes tener un
host que ejecute la última compilación de Windows Server del Programa Windows
Insider o la compilación más reciente de Windows 10 del Programa Windows Insider.
Únete al Programa Windows Insider y revisa los términos de uso.

） Importante

Para poder usar la imagen base que se describe a continuación, tienes que usar una
compilación de Windows Server del programa Windows Server Insider Preview, o
una compilación de Windows 10 del programa Windows Insider Preview. Si no usas
alguna de estas compilaciones, el estas imágenes base no permitirán iniciar un
contenedor.

Instalar Docker
Si aún no tienes Docker instalado, sigue la guía de introducción para instalar Docker.

Extracción de una imagen de contenedor de

Insider
Al formar parte del Programa Windows Insider, también puedes usar nuestras
compilaciones más recientes para las imágenes base. Especifica la imagen de
compilación de Insider que quieres usar en el comando docker pull , por ejemplo,
mcr.microsoft.com/windows/server/insider:10.0.{build}.{revision} .
Para recuperar la imagen base de Insider de Windows Server, ejecute lo siguiente:

Consola

docker pull mcr.microsoft.com/windows/server/insider:10.0.20348.1

Para recuperar la imagen base de Insider de Nano Server, ejecute lo siguiente:

Consola

docker pull mcr.microsoft.com/windows/nanoserver/insider:10.0.20348.1

Para recuperar la imagen base de Core Insider de Windows Server, ejecute lo siguiente:

Consola

docker pull mcr.microsoft.com/windows/servercore/insider:10.0.20348.1

Para ver todas las imágenes base de Insider disponibles, consulta Imágenes base para
usuarios de Windows Insider.

） Importante

Se recomienda leer CLUF de la imagen base del SO Windows y los Términos de

uso del Programa Windows Insider.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Administrador de trabajos de impresión
en contenedores de Windows
Artículo • 05/02/2025

Las aplicaciones con una dependencia de los servicios de impresión se pueden incluir
correctamente en contenedores de Windows. Hay requisitos especiales que deben
cumplirse para habilitar correctamente la funcionalidad del servicio de impresora. En
esta guía se explica cómo configurar correctamente la implementación.

） Importante

Aunque obtener acceso a los servicios de impresión correctamente en

contenedores funciona, la funcionalidad está limitada en forma; Es posible que
algunas acciones relacionadas con la impresión no funcionen. Por ejemplo, las
aplicaciones que dependen de la instalación de controladores de impresora en el
host no se pueden incluir en contenedores porque no se admite la instalación de
controladores desde dentro de un contenedor. Abra un comentario a
continuación si encuentra una característica de impresión no compatible que
quiera admitir en los contenedores.

Configuración
El host debe ser Windows Server 2019 o Windows 10 Pro/Enterprise, actualización
de octubre de 2018 o posterior.
Use la imagen base de para contenedores de Windows o la imagen base de para
contenedores de Windows Server . Otras imágenes base de contenedor de
Windows (como Nano Server y Windows Server Core) no llevan el rol de servidor
de impresión.

Hyper-V Aislamiento
Se recomienda ejecutar el contenedor con aislamiento de Hyper-V. Cuando se ejecuta
en este modo, puede tener tantos contenedores como quiera ejecutar con acceso a los
servicios de impresión. No es necesario modificar el servicio de administrador de
trabajos en cola en el servidor host.

Puede comprobar la funcionalidad con la siguiente consulta de PowerShell:

 PowerShell

PS C:\Users\Administrator> docker run -it --isolation hyperv

mcr.microsoft.com/windows:1809 powershell.exe
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\> Get-Service spooler

Status Name DisplayName

------ ---- -----------
Running spooler Print Spooler

PS C:\> Get-Printer

Name ComputerName Type DriverName

PortName Shared Published
---- ------------ ---- ----------
-------- ------ --------
Microsoft XPS Document Writer Local Microsoft XPS
Document... PORTPROMPT: False False
Microsoft Print to PDF Local Microsoft Print
To PDF PORTPROMPT: False False
Fax Local Microsoft Shared
Fax D... SHRFAX: False False

PS C:\>

Aislamiento de procesos
Debido a la naturaleza del kernel compartido de los contenedores con aislamiento de
procesos, el comportamiento actual limita al usuario a ejecutar solo una instancia del
servicio de administrador de trabajos en cola de impresora en todo el host y todos sus
contenedores secundarios. Si el host tiene el administrador de trabajos en cola de la
impresora en ejecución, debe detener el servicio en el host antes de intentar iniciar el
servicio de impresora en el invitado.

 Sugerencia

Si inicia un contenedor y consulta el servicio de administrador de trabajos en cola

tanto en el contenedor como en el host simultáneamente, ambos informarán que
su estado es "en ejecución". Pero no se engaña: el contenedor no podrá consultar
una lista de impresoras disponibles. El servicio de administrador de trabajos en cola
del host no se debe ejecutar.
Para comprobar si el host ejecuta el servicio de impresora, use la consulta en PowerShell
siguiente:

PowerShell

PS C:\Users\Administrator> Get-Service spooler

Status Name DisplayName

------ ---- -----------
Running spooler Print Spooler

PS C:\Users\Administrator>

Para detener el servicio de administrador de trabajos en cola en el host, use los

siguientes comandos en PowerShell:

PowerShell

Stop-Service spooler
Set-Service spooler -StartupType Disabled

Inicie el contenedor y compruebe el acceso a las impresoras.

PowerShell

PS C:\Users\Administrator> docker run -it --isolation process

mcr.microsoft.com/windows:1809 powershell.exe
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\> Get-Service spooler

Status Name DisplayName

------ ---- -----------
Running spooler Print Spooler

PS C:\> Get-Printer

Name ComputerName Type DriverName

PortName Shared Published
---- ------------ ---- ----------
-------- ------ --------
Microsoft XPS Document Writer Local Microsoft XPS
Document... PORTPROMPT: False False
Microsoft Print to PDF Local Microsoft Print
To PDF PORTPROMPT: False False
Fax Local Microsoft Shared
Fax D... SHRFAX: False False
 PS C:\>

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Adición de paquetes de fuentes
opcionales a contenedores de Windows
Artículo • 23/01/2025

En un esfuerzo por mejorar el rendimiento general de los contenedores de Windows,

hemos quitado muchos componentes de las imágenes de contenedor base de
Windows, incluidos componentes como fuentes, que en la mayoría de los casos no son
relevantes. Sin embargo, es posible que algunos escenarios necesiten estas fuentes para
que las aplicaciones funcionen correctamente.

Preparación del entorno

Cuando se quitan las fuentes de la imagen de contenedor base de Server Core, también
se ha quitado la característica que instala nuevas fuentes. A medida que compila la
imagen de contenedor, debe incorporar los pasos siguientes para volver a agregar la
característica necesaria a los contenedores de Windows. En primer lugar, necesita un
host o máquina virtual de Windows Server 2019 o 2022 actualizado como host de
contenedor. La restauración de características eliminadas requiere medios actualizados.

７ Nota

Hay varias maneras de adquirir medios de instalación actualizados, pero lo más

sencillo es tomar una máquina virtual de Windows Server 2019 o 2022 y dejar que
Windows Update lo ponga al día. También necesita una ISO del medio original de
Windows Server 2019 o 2022 RTM. Esta imagen se puede adquirir a través de una
suscripción de Visual Studio o un Centro de servicios de licencias por
volumen .

Para preparar el entorno, necesita un host de contenedor de Windows configurado

correctamente y compartir el directorio %windir%\WinSxS. También debe compartir el
directorio %windir%\WinSxS. En este ejemplo, creamos un usuario local con una
contraseña generada aleatoriamente:

Para el símbolo del sistema:

Consola

net user ShareUser <password> /ADD

net share WinSxS=%windir%\WinSxS /grant:ShareUser,READ
Para PowerShell:

PowerShell

net user ShareUser ‘<password>’ /ADD

net share WinSxS=${env:windir}\WinSxS /grant:ShareUser,READ

A continuación, monte el medio RTM.

Para el símbolo del sistema:

Consola

set imagePath=<path to RTM ISO>

powershell Mount-DiskImage -ImagePath %imagePath%
set driveLetter=<drive letter of the mounted ISO>
set repairMountDir=%SystemDrive%\repair
mkdir repairMountDir
dism /mount-image /imagefile:"%driveLetter%\sources\install.wim" /index:1
/mountdir:%repairMountDir%
net share RTM=%repairMountDir% /grant:ShareUser,READ

Para PowerShell:

PowerShell

$imagePath = <path to RTM ISO>

Mount-DiskImage -ImagePath $imagePath
# Find the drive letter of the mounted ISO
$driveLetter = <drive letter of mounted ISO>
$repairMountDir = "${env:systemdrive}\repair"
mkdir $repairMountDir
dism /mount-image /imagefile:"$driveLetter\sources\install.wim" /index:1
/mountdir:$repairMountDir
net share RTM=$repairMountDir /grant:ShareUser,READ

７ Nota

Asegúrese de que se especifica el índice de imagen 1 al montar el medio RTM.

A continuación, cree un archivo denominado InstallFonts.cmd y agregue el siguiente

contenido:

Consola

REM Connect to the WinSxS share on the container host

for /f "tokens=3 delims=: " %%g in ('netsh interface ip show address ^|
 findstr /c:"Default Gateway"') do set GATEWAY=%%g
net use o: \\%GATEWAY%\WinSxS /user:ShareUser %SHARE_PW%
net use r: \\%GATEWAY%\RTM /user:ShareUser %SHARE_PW%if errorlevel 1 goto
:eof

dism /online /enable-feature /featurename:ServerCoreFonts-NonCritical-Fonts-

MinConsoleFonts /Source:O:\ /Source:R:\ /LimitAccess
dism /online /enable-feature /featurename:ServerCoreFonts-NonCritical-Fonts-
Support /Source:O:\ /Source:R:\ /LimitAccess
dism /online /enable-feature /featurename:ServerCoreFonts-NonCritical-Fonts-
BitmapFonts /Source:O:\ /Source:R:\ /LimitAccess
dism /online /enable-feature /featurename:ServerCoreFonts-NonCritical-Fonts-
TrueType /Source:O:\ /Source:R:\ /LimitAccess
dism /online /enable-feature /featurename:ServerCoreFonts-NonCritical-Fonts-
UAPFonts /Source:O:\ /Source:R:\ /LimitAccess

Ahora puede agregar el contexto al dockerfile. A continuación se muestra un ejemplo:

Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2022
ARG SHARE_PW=
WORKDIR /install
COPY InstallFonts.cmd .
RUN InstallFonts.cmd

Con un dockerfile en su lugar, puede compilar y etiquetar la imagen de contenedor

mediante:

Consola

docker build -t <newname:tag> --build-arg SHARE_PW=<password> .

Obtiene SHARE_PW en el seguimiento de compilación, pero, si lo configura como una

cadena generada aleatoriamente para cada compilación, no está filtrando un secreto
real. Además, una vez completada la compilación, puede limpiar el recurso compartido y
el usuario mediante:

Consola

net share WinSxS /delete

net user ShareUser /delete

Ejecución de la carga de trabajo

Debido a una limitación en el modo en que los contenedores de Server Core controlan
las fuentes, es preciso indicar específicamente a Windows las nuevas fuentes disponibles
en el contenedor. Debe ejecutar un script de PowerShell después de iniciar el
contenedor y antes de ejecutar la carga de trabajo. Se recomienda llamarlo
LoadFonts.ps1:

PowerShell

$fontCSharpCode = @'
using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Runtime.InteropServices;
namespace FontResource
{
public class AddRemoveFonts
{
[DllImport("gdi32.dll")]
static extern int AddFontResource(string lpFilename);
public static int AddFont(string fontFilePath) {
try
{
return AddFontResource(fontFilePath);
}
catch
{
return 0;
}
}
}
}
'@

Add-Type $fontCSharpCode

foreach($font in $(gci C:\Windows\Fonts))

{

Write-Output "Loading $($font.FullName)"

[FontResource.AddRemoveFonts]::AddFont($font.FullName) | Out-Null

Microsoft espera eliminar esta limitación en una versión futura de Windows, pero el
script es necesario para las versiones actuales de Windows Server 2019 y 2022. Una vez
que haya compilado el contenedor como se describe aquí y ejecute este script dentro
del contenedor, todas las fuentes presentes en Windows Server Core están disponibles
para la carga de trabajo en contenedor.
Problemas al agregar fuentes
Si tiene problemas al habilitar fuentes en imágenes de contenedor de Server Core,
háganoslo saber en la sección Problemas de nuestro repositorio de GitHub .

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Configuración de la extensión de
contenedores en Windows Admin
Center
Artículo • 23/01/2025

En este tema se describe cómo configurar la extensión Containers en Windows Admin

Center. Para obtener más información sobre cómo instalar y configurar Windows Admin
Center, así como cómo dirigirse a servidores remotos, consulte la documentación de
Windows Admin Center.

Instalación de la extensión Containers en

Windows Admin Center
1. En la instancia de Windows Admin Center, seleccione el botón Configuración en la
parte superior derecha y, a continuación, en el panel izquierdo, en Puerta de
enlace, seleccione Extensiones.

2. En la pestaña Extensiones disponibles , seleccione la extensión Containers de la

lista.

3. Haga clic en Instalar para instalar la extensión.

Windows Admin Center se actualizará y, una vez completada, la extensión aparecerá en

la pestaña Extensiones instaladas.
Pasos siguientes
Administración de imágenes de contenedor en Windows Admin Center

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Administración de imágenes de
contenedor en Windows Admin Center
Artículo • 23/01/2025

En este tema se describe cómo administrar imágenes de contenedor en Windows

Admin Center. Las imágenes de contenedor se usan para crear nuevos contenedores en
máquinas Windows u otros servicios en la nube, como Azure Kubernetes Service. Para
obtener más información sobre las imágenes de Windows, consulte Introducción a las
imágenes de contenedor.

Extracción de imágenes de contenedor

Después de implementar un host de contenedor, el siguiente paso consiste en extraer (o
descargar) imágenes de contenedor para que se puedan crear nuevos contenedores a
partir de las imágenes. Puede usar Windows Admin Center para extraer nuevas
imágenes de contenedor seleccionando la extensión Containers en el host de
contenedor de destino. A continuación, seleccione la pestaña Imágenes dentro de la
extensión Contenedor en Host de contenedor y seleccione la opción Extracción .
En la configuración De imagen de contenedor de extracción, proporcione la dirección
URL de la imagen y la etiqueta de la imagen que desea extraer. También puede
seleccionar la opción para extraer todas las imágenes etiquetadas en ese repositorio.

Si la imagen que desea extraer está en un repositorio privado, proporcione el nombre

de usuario y la contraseña para autenticarse en ese repositorio. Si el repositorio se
hospeda en Azure Container Registry, use la autenticación nativa de Azure en Windows
Admin Center para acceder a la imagen. Esto requiere que la instancia de Windows
Admin Center se conecte a Azure y se autentique con su cuenta de Azure. Para más
información sobre cómo conectar una instancia de Windows Admin Center a Azure,
consulte Configuración de la integración de Azure.

Si no está seguro de la imagen que se va a extraer, Windows Admin Center proporciona

una lista de imágenes comunes de Microsoft. Seleccione la lista desplegable Imágenes
comunes de Windows para ver una lista de imágenes base que se extraen
normalmente. Seleccione la imagen que desea extraer y Windows Admin Center
rellenará los campos de repositorio y etiqueta.

Insertar imágenes de contenedor

Una vez creada la imagen de contenedor, se recomienda insertar esa imagen en un
repositorio centralizado para permitir que otros hosts de contenedor o servicios en la
nube extraigan la imagen.

En la pestaña Imágenes de la extensión Contenedores de Windows Admin Center,

seleccione la imagen que desea insertar y haga clic en Insertar.
En la configuración insertar imagen de contenedor , puede cambiar el nombre y la
etiqueta de la imagen antes de insertarla (cargarla). También puede elegir si insertarlo
en un repositorio genérico o en un repositorio en Azure Container Registry. Para un
repositorio genérico, deberá proporcionar un nombre de usuario y una contraseña. Para
Azure Container Registry, puede usar la autenticación integrada en Windows Admin
Center. En Azure, también puede seleccionar en qué suscripción y registro desea insertar
la imagen.
Pasos siguientes
Creación de contenedores en Windows Admin Center

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Ejecución de nuevos contenedores
mediante Windows Admin Center
Artículo • 23/01/2025

Windows Admin Center ayuda a ejecutar contenedores localmente en el host de

contenedor.

1. En Windows Admin Center con la extensión Containers instalada, abra el host de

contenedor que desea administrar.

2. En Herramientas en el panel izquierdo, seleccione la extensión Contenedores .

3. Seleccione la pestaña Imágenes en Host de contenedor.

4. Seleccione la imagen que desea ejecutar y haga clic en Ejecutar.

5. En Ejecutar imagen, puede especificar la configuración relacionada con el
contenedor:

Nombre del contenedor: se trata de una entrada opcional. Puede

proporcionar un nombre de contenedor para ayudarle a realizar un
 seguimiento del contenedor que creó; de lo contrario, Docker proporcionará
un nombre genérico.
Tipo de aislamiento: puede optar por usar el hipervisor en lugar del
aislamiento de proceso predeterminado. Para obtener más información sobre
los modos de aislamiento para contenedores de Windows, consulte Modos
de aislamiento.
Publicar puertos: de forma predeterminada, los contenedores de Windows
usan NAT para el modo de red. Esto significa que un puerto en el host del
contenedor se asignará al contenedor. Esta opción permite especificar esa
asignación.
Asignación de memoria y recuento de CPU: puede especificar cuánta
memoria y cuántas CPU debe poder usar un contenedor. Esta opción no
asigna la memoria asignada ni la CPU al contenedor. En su lugar, esta opción
especifica la cantidad máxima que podrá asignar un contenedor.
Agregar: también puede anexar parámetros de ejecución de Docker que no
están en la interfaz de usuario, como -v para el volumen persistente. Para
más información sobre los parámetros de ejecución de Docker disponibles,
consulte la documentación de Docker .

6. Una vez que haya terminado de configurar el contenedor, seleccione Ejecutar.

Puede ver el estado de los contenedores en ejecución en la pestaña Contenedores
:

Pasos siguientes
Administrar Azure Container Registry en Windows Admin Center
Comentarios
¿Le ha resultado útil esta página?  Sí  No
Creación de imágenes de contenedor en
Windows Admin Center
Artículo • 23/01/2025

En este tema se describe cómo crear nuevas imágenes de contenedor mediante

Windows Admin Center. Las imágenes de contenedor se usan para crear nuevos
contenedores en máquinas Windows u otros servicios en la nube, como Azure
Kubernetes Service. Para obtener más información sobre las imágenes de Windows,
consulte Introducción a las imágenes de contenedor.

Creación de nuevas imágenes de contenedores

Al trabajar con contenedores, escribirá instrucciones en Docker sobre cómo funciona la
imagen de contenedor y, después, Docker creará una nueva imagen de contenedor en
función de estas instrucciones. Estas instrucciones se guardan en un archivo
denominado "Dockerfile" que se guarda en la misma carpeta en la que reside la
aplicación.

Windows Admin Center puede reducir considerablemente la sobrecarga de escribir

dockerfiles o incluso quitar la necesidad de escribir estos archivos por completo. Para
empezar, en la extensión Containers , seleccione la opción Crear nuevo en la pestaña
Imágenes .

Al crear una nueva imagen de contenedor, tiene diferentes opciones entre las que
elegir:
 Usar un Dockerfile existente: esta opción permite recompilar una nueva imagen
de contenedor basada en un Dockerfile existente. Esto resulta útil cuando necesita
realizar pequeños cambios en un Dockerfile existente o cuando necesite volver a
crear el contenedor para detectar una actualización de la aplicación.
Carpeta de aplicación web de IIS/aplicación web estática: use esta opción para
crear una nueva imagen de contenedor mediante la imagen base de IIS. El
contenido de la carpeta se copia en la imagen de contenedor para agregarlo como
sitio web. No se agrega ningún marco con esta opción.
Aplicación web de IIS o solución de Visual Studio (ASP.NET):use esta opción para
crear una nueva imagen de contenedor basada en una solución de Visual Studio
existente. Esta opción usa un enfoque de fase de varias imágenes para almacenar
provisionalmente la aplicación, compilar los archivos binarios necesarios y
almacenar solo los recursos necesarios en la imagen final. La imagen de
contenedor ASP.NET se usa como imagen base. Esta opción también solicita la
carpeta en la que reside Visual Studio. Esto le permite ver una lista de los
proyectos existentes y puede seleccionar el que desea incluir en contenedor.
Aplicación web de IIS/Web Deploy (archivo Zip exportado): use esta opción para
crear una imagen de contenedor a partir de los artefactos exportados desde un
servidor en ejecución. Puede usar Web Deploy para exportar la aplicación a un
archivo Zip y, a continuación, usar Windows Admin Center para crear una nueva
imagen de contenedor basada en el archivo Zip exportado. La imagen de
contenedor ASP.NET se usa como imagen base.

Una vez que seleccione el tipo de aplicación que desea incluir en contenedores, puede
seleccionar opciones comunes para finalizar la creación de la imagen:

Versión del marco: tanto la solución de Visual Studio como las opciones Web
Deploy usan la imagen de ASP.NET como base para la imagen de contenedor. Sin
embargo, puede seleccionar qué versión de .NET Framework desea usar para dar
cabida a la aplicación.
Scripts adicionales para ejecutar: esta opción permite seleccionar un script de
PowerShell para usarlo en tiempo de compilación. Windows Admin Center agrega
una instrucción al Dockerfile para copiar el archivo .PS1 en la imagen de
contenedor y, a continuación, ejecutar este script cuando se crea la imagen de
contenedor. Esto puede resultar útil si la aplicación requiere que ejecute algún
paso adicional que no se complete en la propia aplicación.
Nombre de la imagen: nombre final de la imagen que se va a usar. Puede cambiar
el nombre más adelante al insertar la imagen en un registro de contenedor.
Etiqueta de imagen: la etiqueta se usa para diferenciar entre varias versiones de la
misma imagen. Proporcione un identificador, por lo que la imagen está etiquetada
correctamente.
Una vez que haya seleccionado todas las opciones de la imagen de contenedor, puede
revisar el Dockerfile. Si es necesario, también puede editar manualmente el Dockerfile.
Este Dockerfile se guarda en la ubicación de la aplicación que especificó en un paso
anterior.

７ Nota

Si ya existe un Dockerfile en la ubicación de la aplicación que intenta incluir en

contenedor, Windows Admin Center reemplazará ese archivo por el nuevo que
acaba de crear.

Pasos siguientes
Ejecución de contenedores en Windows Admin Center

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Administración de Azure Container
Registry mediante Windows Admin
Center
Artículo • 23/01/2025

En este tema se describe cómo administrar Azure Container Registry (ACR) mediante
Windows Admin Center. Azure Container Registry permite compilar, almacenar y
administrar imágenes y artefactos de contenedor en un registro privado para todo tipo
de implementaciones de contenedor.

７ Nota

Se requiere una suscripción de Azure para ejecutar los pasos de este tutorial. Para
más información sobre cómo conectar la instancia de Windows Admin Center a
Azure, consulte Configuración de la integración de Azure.

Windows Admin Center permite realizar una administración básica de Azure Container
Registry, como:

Enumerar registros e imágenes

Creación de nuevos registros
Eliminación de imágenes
Extracción de imágenes en el host de contenedor
Inicio de nuevos contenedores en Azure Container Instances a partir de imágenes
almacenadas en Azure Container Registry

Con Windows Admin Center para administrar ACR, puede preparar la ubicación de
Azure a la que puede insertar imágenes directamente desde la pestaña Imágenes en
host de contenedor. Para empezar, siga estos pasos:

1. Abra la instancia de Windows Admin Center y seleccione el host de contenedor.

2. En Herramientas en el panel izquierdo, desplácese hacia abajo y seleccione la

extensión Contenedores .

3. Abra la pestaña Azure Container Registry en Azure.

Administración de registros e imágenes
Para crear un nuevo registro, en Azure Container Registry, seleccione Crear nuevo
registro.
En Crear un nuevo registro, seleccione la suscripción que desea usar para crear un
registro y el grupo de recursos que desea asignar al registro. A continuación,
proporcione un nombre del Registro, una ubicación y una SKU. Para más información
sobre los precios y las características de cada SKU, consulte la documentación de ACR.
Haga clic en Crear para crear el registro. Una vez completado, Windows Admin Center le
notificará si la operación se ha completado correctamente y, a continuación, verá el
nuevo registro en la lista.
Una vez que se muestran los registros y las imágenes, puede quitar una imagen
existente o extraerla en el host de contenedor para su uso local. Para extraer una
imagen, seleccione la imagen que desea extraer y haga clic en Extraer imagen:

Una vez completado el proceso de extracción, Windows Admin Center le notificará y la

imagen estará disponible para su uso en la pestaña Imágenes en Host de contenedor.

Por último, puede ejecutar un nuevo contenedor basado en una imagen hospedada en
ACR. Para empezar, seleccione la imagen que desea ejecutar y haga clic en Ejecutar
instancia:
En Instancia de ejecución, debe proporcionar un nombre de contenedor, la suscripción
que se va a usar y el grupo de recursos y la ubicación que desea ejecutar esta instancia.

A continuación, proporcione la asignación de CPU y memoria para esta instancia, así

como el puerto que desea abrir, si es necesario. Haga clic en Crear y Windows Admin
Center envíe el comando a Azure para ejecutar la instancia. Puede comprobar el estado
de la instancia de contenedor en la pestaña Instancia de contenedor de Azure .

Pasos siguientes
Administración de Azure Container Instance en Windows Admin Center

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Administración de Azure Container
Instances mediante Windows Admin
Center
Artículo • 23/01/2025

En este tema se describe cómo administrar Azure Container Instances (ACI) mediante
Windows Admin Center. Azure Container Instances es una solución para cualquier
escenario que puede funcionar en contenedores aislados, sin orquestación.

７ Nota

Se requiere una suscripción de Azure para ejecutar los pasos descritos en este
tutorial. Para más información sobre cómo conectar la instancia de Windows Admin
Center a Azure, consulte Configuración de la integración de Azure.

Windows Admin Center permite realizar una administración básica de Azure Container
Instances, que incluye enumerar las instancias de contenedor existentes, iniciar y
detener una instancia, quitar instancias y abrir Azure Portal para la administración
avanzada.

Con la instancia de contenedor, puede realizar las siguientes acciones:

Start: para iniciar una instancia existente que está detenida actualmente.
End: para detener una instancia en ejecución.
Eliminar: para eliminar una instancia. Esto es irreversible y quita cualquier
configuración que se haya realizado en la instancia.
 Administrar en Azure: se abre el panel de Azure Portal para administrar la
instancia de contenedor seleccionada en una nueva pestaña del explorador.

Pasos siguientes
Administrar Azure Container Registry en Windows Admin Center

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Imágenes base de contenedor
Artículo • 23/01/2025

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

Windows ofrece cuatro imágenes base de contenedor desde las que los usuarios
pueden compilar. Cada imagen base es un tipo diferente del sistema operativo Windows
o Windows Server, tiene una superficie de disco diferente y tiene un conjunto de API de
Windows diferente.

Windo Nano Windo Windo

ws Server ws ws
Server Implementa Proporciona
Server
Core do para el conjunto
Proporciona
aplicaciones completo
el conjunto
Admite .NET Core. de API de
completo
aplicaciones Windows.
de API de
tradicionale
Windows.
s de
.NET Frame
work.

Detección de imágenes
Todas las imágenes base de contenedores de Windows se pueden detectar a través de
Docker Hub . Las imágenes base de contenedores de Windows se entregan desde
mcr.microsoft.com , Microsoft Container Registry (MCR). Este es el motivo por el que
los comandos de extracción para las imágenes base de contenedores de Windows
tienen el aspecto siguiente:

code
 docker pull mcr.microsoft.com/windows/servercore:ltsc2025

MCR no tiene su propia experiencia de catálogo y está pensado para admitir los
catálogos existentes, como Docker Hub. Gracias a la superficie global de Azure y junto
con Azure CDN, MCR ofrece una experiencia de extracción de imágenes que es
coherente y rápida. Los clientes de Azure que ejecutan sus cargas de trabajo en Azure se
benefician de las mejoras de rendimiento en la red, así como de una estrecha
integración con MCR (el origen de las imágenes de contenedores de Microsoft), Azure
Marketplace y el creciente número de servicios de Azure que ofrecen contenedores
como formato de paquete de implementación.

Elección de una imagen base

¿Cómo elegir la imagen base adecuada en función de la cual compilar? Para la mayoría
de los usuarios, Windows Server Core y Nanoserver serán la imagen más adecuada para
usar. Cada imagen base se describe brevemente a continuación:

Nano Server es una oferta de Windows ultraligera para el desarrollo de nuevas

aplicaciones.
Server Core tiene un tamaño medio y es una buena opción para migrar

aplicaciones de Windows Server mediante "lift-and-shift".

Windows es la imagen más grande y tiene compatibilidad completa con las API de

Windows para cargas de trabajo.

Windows Server es ligeramente más pequeña que la imagen de Windows, tiene

compatibilidad completa con las API de Windows y le permite usar más

características de servidor.

Directrices
Si bien tiene la posibilidad de usar la imagen que quiera, estas son algunas directrices
que le ayudarán a dirigir su elección:

¿Requiere la aplicación la versión completa de .NET Framework? Si la respuesta a

esta pregunta es afirmativa, deberías usar Windows Server Core .
¿Estás compilando una aplicación de Windows basada en .NET Core? Si la
respuesta a esta pregunta es afirmativa, deberías usar Nanoserver .
¿Falta en la imagen de contenedor de Windows Server Core una dependencia
que tu aplicación necesita? Si la respuesta a esta pregunta es afirmativa, deberías
intentar usar Windows . Esta imagen es mucho más grande que las otras imágenes
 base, pero incluye muchas de las bibliotecas de Windows principales (como la
biblioteca GDI).
¿Eres miembro de Windows Insider? En caso afirmativo, piensa en la posibilidad
de usar la versión de las imágenes para Insider. Para obtener más información,
consulte "Imágenes base para los usuarios de Windows Insider" a continuación.
¿Necesita compatibilidad con la aceleración de GPU para las cargas de trabajo
de contenedor? En caso afirmativo, analice la posibilidad de usar la imagen
Windows Server para incluir la aceleración de hardware para las cargas de trabajo

de contenedores Windows.

 Sugerencia

Muchos usuarios de Windows quieren incluir en contenedores las aplicaciones que

tienen una dependencia en .NET. Además de las cuatro imágenes base que se
describen aquí, Microsoft publica varias imágenes de contenedor de Windows que
están preconfiguradas con los marcos de Microsoft conocidos, como la imagen de
.NET Framework y la imagen de ASP .NET .

Windows frente a Windows Server

La imagen Windows Server (3,1 GB) tiene un tamaño ligeramente menor que la imagen
Windows (3,4 GB). La imagen de Windows Server también hereda todas las mejoras de

rendimiento y fiabilidad de la imagen de Server Core, tiene compatibilidad con GPU y

no tiene límites en las conexiones IIS. Para usar la imagen más reciente de Windows
Server, necesitará una instalación de Windows Server 2025. La imagen de Windows no
está disponible para Windows Server 2025.

Imágenes base para Windows Insider

Microsoft proporciona versiones de "Insider" de cada imagen base de contenedor. Estas
imágenes de contenedor de Insider incluyen el desarrollo de características más reciente
y mejor en nuestras imágenes de contenedor. Cuando ejecutes un host que sea una
versión de Windows para Insider (ya sea Windows Insider o Windows Server Insider), es
preferible usar estas imágenes. Las siguientes imágenes de Insider están disponibles en
Docker Hub:

mcr.microsoft.com/windows/servercore/insider
mcr.microsoft.com/windows/nanoserver/insider
mcr.microsoft.com/windows/server/insider:10.0.20344.1
 mcr.microsoft.com/windows/insider

Para más información, lee Usar contenedores con el Programa Windows Insider.

Windows Server Core frente a Nano Server

Windows Server Core y Nanoserver son las imágenes base de destino más comunes. La

diferencia principal entre estas imágenes es que Nano Server tiene una superficie de API
significativamente menor. PowerShell, WMI y la pila de servicio de Windows no están
presentes en la imagen de Nano Server.

Nano Server se compiló para proporcionar una superficie de API apenas suficiente para
ejecutar aplicaciones que tengan una dependencia en .NET Core u otros marcos de
código abierto modernos. Como contrapartida a la menor superficie de API, la imagen
de Nano Server tiene una superficie en disco considerablemente menor que el resto de
las imágenes base de Windows. Ten en cuenta que siempre se pueden agregar capas
sobre Nano Server según estimes oportuno. Para ver un ejemplo de esto, echa un
vistazo al Dockerfile de .NET Core Nano Server .

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Ciclos de vida de mantenimiento de
imágenes base
Artículo • 28/01/2025

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

７ Nota

Microsoft ha retrasado las fechas del final programado de soporte técnico y

servicio para una serie de productos para ayudar a las personas y organizaciones a
centrar su atención en mantener la continuidad empresarial. Consulte cambios en
el ciclo de vida hasta el final del soporte técnico y las fechas de mantenimiento
para obtener más información.

Las imágenes base de contenedores de Windows se basan en las publicaciones del

Canal de mantenimiento a largo plazo o en las publicaciones del Canal semianual de
Windows Server. En este artículo se explica el tiempo que durará el soporte técnico para
las distintas versiones de las imágenes base de ambos canales.

El Canal semianual es una versión de actualización de características que se publica dos

veces al año con unos plazos de mantenimiento de 18 meses para cada versión. Permite
a los clientes sacar partido de nuevas funcionalidades del sistema operativo a un ritmo
más rápido, tanto en aplicaciones, especialmente las integradas en contenedores y
microservicios, como en el centro de datos híbrido definido por software. Para más
información, consulta Introducción al Canal semianual de Windows Server.

En el caso de las imágenes de Server Core, los clientes también pueden usar el Canal de
servicio a largo plazo, que publica una nueva versión principal de Windows Server cada
dos o tres años. Las publicaciones del Canal de mantenimiento a largo plazo reciben un
soporte estándar y soporte extendido durante cinco años. Este canal funciona con
sistemas que requieren una opción de mantenimiento más prolongado y estabilidad
funcional.

En la tabla siguiente se enumeran los tipos de imagen base, su canal de mantenimiento

y el tiempo que durará el soporte técnico.

ﾉ Expandir tabla
Base Canal de Version Compilación Disponibilidad Fecha de Fecha del
image mantenimiento del sistema finalización soporte
operativo del soporte extendido
estándar

Server A largo plazo 2022 20348 18/08/2021 13/10/2026 14/10/2031

Core,
Nano
Server,
Datacenter
Container

Server Semianual 20H2 19042 20/10/2020 09/08/2022 N/A

Core,
Nano
Server,
Windows

Server Semianual 2004 19041 27/05/2020 14/12/2021 N/A

Core,
Nano
Server,
Windows

Server Semianual 1909 18363 12/11/2019 11/05/2021 N/A

Core,
Nano
Server,
Windows

Server Semianual 1903 18362 21/05/2019 08/12/2020 N/A

Core,
Nano
Server,
Windows

Server A largo plazo; 2019, 17763 13/11/2018 09/01/2024 09/01/2029

Core semestral 1809

Nano Semianual 1809 17763 13/11/2018 09/01/2024 09/01/2029

Server

Windows Semianual 1809 17763 13/11/2018 09/01/2024 09/01/2029

Server Semianual 1803 17134 30/04/2018 12/11/2019 N/A

Core,
Nano
Server

Server Semianual 1709 16299 17/10/2017 09/04/2019 N/A

Core,
 Base Canal de Version Compilación Disponibilidad Fecha de Fecha del
image mantenimiento del sistema finalización soporte
operativo del soporte extendido
estándar

Nano
Server

Server A largo plazo 2016 14393 15/10/2016 11/01/2022 11/01/2027

Core

Nano Semianual 1607 14393 15/10/2016 09/10/2018 N/A

Server

Para conocer los requisitos de mantenimiento y otra información adicional, consulte las
Preguntas más frecuentes sobre el ciclo de vida de Windows, información de versión de
Windows Server, y las siguientes imágenes del sistema operativo base de Windows
Server en el repositorio de Docker Hub:

Windows Server
Windows Server Core
Nano Server

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Modos de aislamiento
Artículo • 05/02/2025

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

Los contenedores de Windows ofrecen dos modos distintos de aislamiento en tiempo

de ejecución: process y Hyper-V . Los contenedores que se ejecutan en ambos modos
de aislamiento se crean, administran y funcionan de forma idéntica. También generan y
consumen las mismas imágenes de contenedor. La diferencia entre los modos de
aislamiento es hasta qué grado de aislamiento se crea entre el contenedor, el sistema
operativo host y todos los demás contenedores que se ejecutan en ese host.

Aislamiento de procesos
Este es el modo de aislamiento "tradicional" para los contenedores y es lo que se
describe en la visión general de los contenedores de Windows . Con el aislamiento de
procesos, varias instancias de contenedor se ejecutan simultáneamente en un host
determinado con aislamiento proporcionado a través del espacio de nombres, el control
de recursos y otras tecnologías de aislamiento de procesos. Cuando se ejecuta en este
modo, los contenedores comparten el mismo kernel con el host, así como entre sí. Esto
es aproximadamente lo mismo que la ejecución de contenedores de Linux.

Qué se aísla
Los contenedores de Windows virtualizan el acceso a varios espacios de nombres del
sistema operativo. Un espacio de nombres proporciona acceso a información, objetos o
recursos a través de un nombre. Por ejemplo, es probable que el sistema de archivos sea
el espacio de nombres más conocido. Hay numerosos espacios de nombres en Windows
que se aíslan para cada contenedor:
 sistema de archivos
registro
puertos de red
Espacio del id, de proceso y subproceso
Espacio de nombres del Administrador de objetos

Perforación del límite de aislamiento

Hay casos en los que resulta útil perforar el límite de aislamiento. El usuario debe
solicitar deliberadamente estas operaciones y debe realizarse con una consideración
cuidadosa, ya que puede poner en peligro la posición de seguridad del contenedor. Los
contenedores de Windows admiten lo siguiente:

mapear archivos compartidos o volúmenes del host al contenedor

mapeo de una canalización con nombre desde el host al contenedor
mapeo de un puerto desde el host al contenedor
personalización y uso compartido del espacio de nombres de red
Compartición de la visibilidad del dispositivo host en el contenedor

Los contenedores de Windows no admiten actualmente:

memoria compartida
compartir objetos de sincronización (semáforos, mutexes, etc.)
Espacios de nombres de procesos compartidos

Aislamiento de Hyper-V
Este modo de aislamiento ofrece mayor seguridad y compatibilidad más amplia entre
las versiones de host y contenedor. Mediante el aislamiento Hyper-V, varias instancias
de contenedores se ejecutan simultáneamente en un host; sin embargo, cada
contenedor se ejecuta dentro de una máquina virtual altamente optimizada y adquiere
de manera efectiva su propio kernel. La presencia de la máquina virtual proporciona
aislamiento a nivel de hardware entre cada contenedor, así como el host del
contenedor.
Ejemplos de aislamiento

Creación de un contenedor
La administración de contenedores aislados de Hyper-V con Docker es casi idéntica a la
administración de contenedores aislados de procesos. Para crear un contenedor con
aislamiento de Hyper-V mediante Docker, use el parámetro --isolation para establecer
--isolation=hyperv .

Símbolo del sistema de Windows

docker run -it --isolation=hyperv

mcr.microsoft.com/windows/servercore:ltsc2019 cmd

Para crear un contenedor con aislamiento de procesos mediante Docker, use el

parámetro --isolation para establecer --isolation=process .

Símbolo del sistema de Windows

docker run -it --isolation=process

mcr.microsoft.com/windows/servercore:ltsc2019 cmd

Los contenedores de Windows que se ejecutan en Windows Server se ejecutan de forma

predeterminada con aislamiento de procesos. Los contenedores de Windows que se
ejecutan en Windows 10 Pro y Enterprise lo hacen de manera predeterminada con
aislamiento de Hyper-V. A partir de la actualización de octubre de 2018 de Windows 10,
los usuarios que ejecutan un host de Windows 10 Pro o Enterprise pueden ejecutar un
contenedor de Windows con aislamiento de procesos. Los usuarios deben solicitar
directamente el aislamiento del proceso mediante la marca --isolation=process .

２ Advertencia

La ejecución con aislamiento de procesos en Windows 10 Pro y Enterprise está

pensada para desarrollo y pruebas. El host debe estar ejecutando la compilación
17763+ de Windows 10 y debe tener una versión de Docker con Engine 18.09 o
posterior.

Debe seguir usando Windows Server como host para implementaciones de

producción. Al usar esta característica en Windows 10 Pro y Enterprise, también
debes asegurarte de que las etiquetas de versión del host y del contenedor
 coincidan; de lo contrario, es posible que el contenedor no pueda iniciar o mostrar
un comportamiento indefinido.

Explicación del aislamiento

En este ejemplo se muestran las diferencias en las funcionalidades de aislamiento entre
el aislamiento de procesos y el aislamiento de Hyper-V.

En este caso, se está implementando un contenedor aislado de procesos y se hospedará

un proceso de ping de larga duración.

Símbolo del sistema de Windows

docker run -d mcr.microsoft.com/windows/servercore:ltsc2019 ping localhost -

t

Con el comando docker top , el proceso de ping se devuelve tal como aparece dentro
del contenedor. El proceso de este ejemplo tiene un identificador de 3964.

Símbolo del sistema de Windows

docker top 1f8bf89026c8f66921a55e773bac1c60174bb6bab52ef427c6c8dbc8698f9d7a

3964 ping

En el host del contenedor, el comando get-process se puede usar para devolver los
procesos de ping en ejecución desde el host. En este ejemplo hay uno y el identificador
de proceso coincide con el del contenedor. Es el mismo proceso visible desde el
contenedor y el host.

get-process -Name ping

Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id SI ProcessName

------- ------ ----- ----- ----- ------ -- -- -----------
67 5 820 3836 ...71 0.03 3964 3 PING

Por otro lado, en este ejemplo se inicia un contenedor con aislamiento de Hyper-V que
también tiene un proceso de ping.
 docker run -d --isolation=hyperv
mcr.microsoft.com/windows/servercore:ltsc2019 ping localhost -t

Del mismo modo, se puede usar docker top para devolver los procesos en ejecución
desde el contenedor.

docker top 5d5611e38b31a41879d37a94468a1e11dc1086dcd009e2640d36023aa1663e62

1732 ping

Sin embargo, al buscar el proceso en el host del contenedor, no se encuentra un

proceso de ping y se produce un error.

get-process -Name ping

get-process : Cannot find a process with the name "ping". Verify the process
name and call the cmdlet again.
At line:1 char:1
+ get-process -Name ping
+ ~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (ping:String) [Get-Process],
ProcessCommandException
+ FullyQualifiedErrorId :
NoProcessFoundForGivenName,Microsoft.PowerShell.Commands.GetProcessCommand

Por último, en el host, el proceso de vmwp es visible, que es la máquina virtual en

ejecución que encapsula el contenedor en ejecución y protege los procesos en
ejecución del sistema operativo host.

get-process -Name vmwp

Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id SI ProcessName

------- ------ ----- ----- ----- ------ -- -- -----------
1737 15 39452 19620 ...61 5.55 2376 0 vmwp

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Portabilidad de contenedores
Artículo • 05/02/2025

Se aplica a: Windows Server, versión 23H2

La portabilidad es una característica del canal anual de Windows Server para

contenedores. La portabilidad simplifica el proceso de actualización, lo que le ayuda a
aprovechar al máximo la flexibilidad mejorada y la compatibilidad que ofrecen los
contenedores. En este artículo se proporciona una explicación detallada de cómo se
optimiza la portabilidad de imágenes de contenedor para hosts de contenedores de
canal anual.

Canal anual de Windows Server para contenedores es una edición de Windows Server
diseñada para las implementaciones de Windows Server centradas en contenedores y
Azure Kubernetes Service para mejorar la eficacia y proporcionar portabilidad
optimizada para contenedores de Windows y Linux. Para más información sobre el canal
anual para contenedores en Windows Server, vea nuestro Anuncio de
TechCommunity .

Funcionamiento de la portabilidad
Windows usa un kernel modular donde los componentes suelen estar estrechamente
enlazados entre modo de usuario y modo kernel. Los componentes estrechamente
enlazados son interfaces gráficas útiles que se sitúan encima de los controladores en
modo kernel, o bien optimizan el rendimiento al reducir los cambios de contexto de
modo kernel a modo usuario. Sin embargo, presenta un desafío para los contenedores.
La portabilidad permite a los contenedores que se ejecutan en modo de usuario
ejecutar cargas de trabajo con una versión de imagen de contenedor diferente a la
versión del sistema operativo host.

Sin portabilidad, los usuarios solo podían ejecutar cargas de trabajo con versiones
coincidentes de imagen y host. Por ejemplo, un usuario que ejecuta un host de
Windows Server 2022 no pudo ejecutar contenedores aislados de procesos de Windows
Server 2019. El control de versiones entre el host y la imagen del contenedor
representaba un problema significativo en el uso de contenedores de Windows,
haciendo que la actualización a versiones más recientes de un host de contenedor sea
un desafío. Por ejemplo, Windows Server 2022 LTSC requería que todas las imágenes de
infraestructura y aplicación se actualizaran a la versión más reciente al mismo tiempo
que se actualizaba el servidor host.
Interfaz binaria de la aplicación
La interfaz binaria de aplicaciones, o ABI, permite que varios lenguajes de programación
interactúen con interfaces de modo de usuario y kernel. La interacción del código de
cliente con un objeto en tiempo de ejecución se produce en el nivel más bajo, con
construcciones de lenguaje cliente traducidas en llamadas a la ABI del objeto. La
portabilidad de los contenedores de Windows presenta una ABI estable para la
interacción entre el usuario y el kernel. Esta ABI estable desacopla los componentes de
usuario y kernel del sistema, y ofrece la capacidad de actualizar por separado los
elementos de kernel y usuario del sistema.

Los contenedores pueden ejecutar todos los archivos binarios en modo de usuario
desde su capa base, excepto la capa ABI.

En el diagrama siguiente se muestra la comunicación entre los componentes en modo

de usuario y en modo kernel.

¿Qué versiones puedo usar?

Las imágenes de contenedor de Nano Server, Server Core y Windows Server solo están
disponibles a través del canal de mantenimiento de Long-Term para contenedores que
ejecutan Windows Server 2019 o posterior. Para más información sobre las imágenes de
contenedores de Windows Server admitidas, vea Ciclos de vida de mantenimiento de
imágenes base.

Un host de contenedor de Windows Server, versión 23H2, solo admite la imagen de

contenedor del canal de mantenimiento a largo plazo (LTSC) de Windows Server 2022.

Azure Kubernetes Service admite actualmente Windows Server 2019 y hosts posteriores.
Canal anual de Windows Server para contenedores es otra opción de sistema operativo
de contenedor que Microsoft ofrece junto con Kubernetes 1.28. Puede crear nuevos
grupos de nodos en función del canal anual y seguir implementando las imágenes de
contenedor de Windows Server 2022 en esos nodos. Microsoft actualiza
automáticamente la versión del canal anual y las nuevas versiones de Kubernetes de
forma anual. Sin embargo, también es una buena idea seguir las últimas versiones de
LTSC para asegurarse de que los contenedores están actualizados.

７ Nota

Aunque las versiones anteriores de imágenes de contenedor se pueden ejecutar en

el sistema operativo host más reciente, los sistemas operativos de imágenes de
contenedor más recientes no se pueden ejecutar en el sistema operativo host
anterior.

Contenido relacionado
¿Qué es el Canal Anual de Windows Server para Contenedores?

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Compatibilidad con versiones de
contenedores de Windows
Artículo • 21/03/2023

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

Windows Server 2016 y la Actualización de aniversario de Windows 10 (versión 14393 en

ambos casos) fueron los primeros lanzamientos de Windows que podían compilar y
ejecutar contenedores de Windows Server. Los contenedores compilados con estas
versiones se pueden ejecutar en las versiones más recientes, pero hay algunos aspectos
que debes saber antes de empezar.

La arquitectura de Windows difiere enormemente de la de Linux. Linux tiene un kernel

monolítico, mientras que en el modo de kernel y usuario de Windows están enlazados
más estrechamente. Hasta la introducción de los contenedores, el modo de kernel y
usuario de Windows se enviaban en sincronía, lo que dio lugar a requisitos de
compatibilidad de contenedores en Windows que difieren de la norma en Linux.

Separar el límite de usuario/kernel en Windows es una tarea importante y nada trivial;

sin embargo, hemos estado trabajando duro para estabilizar este límite en todas las
instancias de Windows para proporcionar a nuestros clientes la flexibilidad de ejecutar
contenedores de nivel inferior. A partir de Windows 11 y Windows Server 2022,
estamos habilitando la capacidad de ejecutar contenedores WS2022 aislados por
procesos en hosts Windows 11. Hemos hecho todo lo posible para capturar las áreas
que rompen el límite, pero ahora queremos abrir la característica a los desarrolladores
en Windows 11 para recibir comentarios. Nos comprometemos a habilitar esta
experiencia para usted, así que háganoslo saber cuando experimente problemas .

En cualquier otro escenario en el que haya una discrepancia en el control de versiones

de Windows host/invitado, es posible que el modo Kernel/Usuario sea compatible, pero
no se garantiza, por lo que se impedirá que la imagen de contenedor se ejecute en el
host. Para cualquier versión con discrepancias, la ejecución con aislamiento de Hyper-V
proporciona al contenedor un conjunto de archivos binarios del Kernel coincidentes y
no depende de la versión del host. Consulte las tablas siguientes para obtener una
matriz de compatibilidad detallada.

Compatibilidad del sistema operativo host de

Windows Server
Windows Server 2022

Versión del sistema operativo de una Admite el Admite el

imagen base de contenedor aislamiento de aislamiento de
Hyper-V procesos

Windows Server 2022 ✔ ✔

Windows Server 2019 ✔ ❌

Windows Server 2016 ✔ ❌

Compatibilidad del sistema operativo host del

cliente de Windows
Windows 11

Versión del sistema operativo de una Admite el Admite el

imagen base de contenedor aislamiento de aislamiento de
Hyper-V procesos

Windows Server 2022 ✔ ✔(versión preliminar)

Windows Server 2019 ✔ ❌

Windows Server 2016 ✔ ❌

７ Nota

Windows 10 versión 1809 y Windows Server 2019 tenían el mismo número de

compilación en la etapa de disponibilidad general. Desde entonces, han recibido
actualizaciones independientes, lo que da lugar a un error de coincidencia en el
número de compilación. El aislamiento de procesos en el cliente de Windows está
disponible en versión preliminar para Windows 11 con imágenes de Windows
Server 2022, con un número de compilación que no coincide. Si tiene un requisito
para ejecutar contenedores de procesos aislados en Windows 10, comuníquenoslo
mediante la página Problemas de GitHub .
Coincidencia de la versión del host de
contenedor con las versiones de las imágenes
de contenedor

Contenedores de Windows Server

Número de compilación (nueva publicación de Windows)

El sistema operativo Windows tiene cuatro niveles de control de versiones: principal,

secundario, compilación y revisión (por ejemplo, 10.0.14393.0). Por ejemplo, la versión
10.0.14393.103 tendría una versión principal de 10, una versión secundaria de 0, un
número de compilación de 14393 y un número de revisión de 103. El número de
compilación solo cambia cuando se publican nuevas versiones del sistema operativo y el
número de revisión se actualiza a medida que se aplican las actualizaciones de
Windows.

Si el número de compilación entre el host de contenedor y la imagen del contenedor es

diferente, se bloquea el inicio de los contenedores de Windows Server, a excepción de
WS2022 y Windows 11. Por ejemplo, cuando el host de contenedor es la versión
10.0.14393.* (Windows Server 2016) e intenta ejecutar un contenedor con una versión
de imagen 10.0.16299.* (Windows Server, versión 1709), el servicio de proceso del
sistema operativo devolverá un error de incompatibilidad de versión.

Restricciones de Windows Server 2016

Los contenedores basados en Windows Server 2016 no se ejecutarán en un sistema en
el que los números de revisión del host de contenedor y la imagen del contenedor sean
diferentes. Por ejemplo, si el host del contenedor tiene la versión 10.0.14393.1914
(Windows Server 2016 con KB4051033) y la imagen del contenedor tiene la versión
10.0.14393.1944 (Windows Server 2016 con KB4053579), es posible que la imagen no se
inicie.

Para los hosts o imágenes que usan Windows Server, versión 1809 y versiones
posteriores, esta regla no se aplica: el host y la imagen del contenedor no necesitan
tener revisiones coincidentes.

７ Nota
 Te recomendamos encarecidamente que actualices el host y los contenedores con
las revisiones y actualizaciones más recientes para mantener la seguridad y la
compatibilidad. Para obtener instrucciones importantes sobre cómo actualizar los
contenedores de Windows, consulta Actualización de contenedores de Windows
Server.

Aplicación práctica
Ejemplo 1: el host del contenedor ejecuta Windows Server 2016 con KB4041691.
Cualquier contenedor de Windows Server implementado a este host debe basarse en las
imágenes base del contenedor versión 10.0.14393.1770. Si aplicas KB4053579 al
contenedor host, también debes actualizar las imágenes para asegurarte de que el
contenedor host las admita.

Ejemplo 2: El host de contenedor ejecuta Windows Server, versión 1809, con KB4534273.
Cualquier contenedor de Windows Server implementado en este host debe basarse en
una imagen base de contenedor de Windows Server versión 1809 (10.0.17763), pero no
necesita coincidir con el KB del host. Si se aplica KB4534273 al host, se seguirán
admitiendo las imágenes del contenedor, pero se recomienda actualizarlas para abordar
los posibles problemas de seguridad.

Consultar versiones
Método 1: Incluido en la versión 1709, el comando ver y el símbolo del sistema cmd
ahora deben devolver los detalles de revisión.

batch

Microsoft Windows [Version 10.0.16299.125]

(c) 2017 Microsoft Corporation. All rights reserved.

C:\>ver

Microsoft Windows [Version 10.0.16299.125]

Método 2: Consulta la siguiente clave del Registro:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion

Por ejemplo:

batch
 C:\>reg query "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion" /v BuildLabEx

PowerShell

Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.

PS C:\Users\Administrator> (Get-ItemProperty
'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\').BuildLabEx
14393.321.amd64fre.rs1_release_inmarket.161004-2338

Para comprobar qué versión usa la imagen base, revisa las etiquetas en Docker Hub o la
tabla hash de la imagen proporcionada en la descripción de la imagen. En la página
Historial de actualizaciones de Windows 10 se muestra cuándo se lanzó cada
compilación y revisión.

Aislamiento de Hyper-V para contenedores

Puedes ejecutar los contenedores de Windows con o sin aislamiento de Hyper-V. El
aislamiento de Hyper-V crea un límite seguro alrededor del contenedor con una VM
optimizada. A diferencia de los contenedores estándar de Windows, que comparten el
kernel entre los contenedores y el host, cada contenedor aislado con Hyper-V tiene su
propia instancia del kernel de Windows. Es decir, puedes tener diferentes versiones del
sistema operativo en el host y la imagen del contenedor (para más información,
consulta la matriz de compatibilidad a continuación).

Para ejecutar un contenedor con aislamiento de Hyper-V, solo tienes que agregar la
etiqueta --isolation=hyperv al comando de ejecución de docker.

Errores de las versiones que no coinciden

Si intentas ejecutar una combinación no admitida, se producirá el error siguiente:

Dockerfile

docker: Error response from daemon: container

b81ed896222eb87906ccab1c3dd2fc49324eafa798438f7979b87b210906f839 encountered
an error during CreateContainer: failure in a Windows system call: The
operating system of the container does not match the operating system of the
host. (0xc0370101) extra info:
{"SystemType":"Container","Name":"b81ed896222eb87906ccab1c3dd2fc49324eafa798
438f7979b87b210906f839","Owner":"docker","IsDummy":false,"VolumePath":"\\\\?
\\Volume{2443d38a-1379-4bcf-a4b7-
 fc6ad4cd7b65}","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"C:\\Program
Data\\docker\\windowsfilter\\b81ed896222eb87906ccab1c3dd2fc49324eafa798438f7
979b87b210906f839","Layers":[{"ID":"1532b584-8431-5b5a-8735-
5e1b4fe9c2a9","Path":"C:\\ProgramData\\docker\\windowsfilter\\b2b88bc2a47abc
c682e422507abbba9c9b6d826d34e67b9e4e3144cc125a1f80"},{"ID":"a64b8da5-cd6e-
5540-bc73-
d81acae6da54","Path":"C:\\ProgramData\\docker\\windowsfilter\\5caaedbced1f54
6bccd01c9d31ea6eea4d30701ebba7b95ee8faa8c098a6845a"}],"HostName":"b81ed89622
2e","MappedDirectories":[],"HvPartition":false,"EndpointList":["002a0d9e-
13b7-42c0-89b2-
c1e80d9af243"],"Servicing":false,"AllowUnqualifiedDNSQuery":true}.

Existen tres formas de resolver este error:

Volver a compilar el contenedor en función de la versión correcta de

mcr.microsoft.com/microsoft-windows-nanoserver o

mcr.microsoft.com/windows/servercore .
Si el host es más reciente, ejecutar docker run --isolation=hyperv ...
Intentar ejecutar el contenedor en otro host con la misma versión de Windows.

Elección de la versión del sistema operativo del

contenedor que se va a usar

７ Nota

A partir del 16 de abril de 2019, la etiqueta "más reciente" ya no se publica ni

mantiene para las imágenes base de contenedor del SO Windows . Declara una
etiqueta específica al extraer o hacer referencia a las imágenes desde estos
repositorios.

Debes saber qué versión debes utilizar para el contenedor. Por ejemplo, si quieres usar
Windows Server, versión 1809, como sistema operativo para el contenedor y quieres
tener las últimas revisiones de dicha versión, debes usar la etiqueta 1809 cuando
indiques qué versión de las imágenes base de contenedor del SO quieres, de este
modo:

Dockerfile

FROM mcr.microsoft.com/windows/nanoserver:1809
...
Sin embargo, si quieres una revisión específica de Windows Server versión 1809, puedes
especificar el número de KB en la etiqueta. Por ejemplo, para obtener una imagen base
de contenedor del SO Nano Server de Windows Server, versión 1809, con KB4493509,
tienes que indicarlo de la siguiente forma:

Dockerfile

FROM mcr.microsoft.com/windows/nanoserver:1809-KB4493509
...

También puedes especificar las revisiones exactas que necesitas con el esquema que
hemos usado anteriormente, es decir, indicar la versión del sistema operativo en la
etiqueta:

Dockerfile

FROM mcr.microsoft.com/windows/nanoserver:10.0.17763.437
...

Las imágenes base de Server Core basadas en Windows Server 2022 y Windows
Server 2019 son versiones del Canal de mantenimiento a largo plazo (LTSC). Si, por
ejemplo, quieres que Windows Server 2019 sea el sistema operativo de contenedor de
la imagen de Server Core y quieres tener las revisiones más recientes para él, puedes
especificar las versiones de LTSC como sigue:

Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2019
...

Coincidencia de versiones mediante Docker

Swarm
Actualmente, Docker Swarm no tiene un modo integrado para hacer coincidir la versión
de Windows que usa un contenedor con un host que tenga la misma versión. Si
actualizas el servicio para usar un contenedor más reciente, se ejecutará correctamente.

Si tienes que ejecutar varias versiones de Windows durante un largo período de tiempo,
existen dos enfoques que puedes seguir: configurar los hosts de Windows para usar
siempre el aislamiento de Hyper-V o usar restricciones de etiquetas.
Encontrar un servicio que no se inicia
Si un servicio no se inicia, notarás que MODE es replicated , pero REPLICAS se bloquea
en 0. Para ver si el problema es la versión del sistema operativo, ejecuta los siguientes
comandos:

Ejecuta docker service ls para buscar el nombre del servicio:

Dockerfile

ID NAME MODE REPLICAS

IMAGE PORTS
xh6mwbdq2uil angry_liskov replicated 0/1
windows/servercore/iis

Ejecuta docker service ps (nombre del servicio) para obtener el estado y los intentos
más recientes:

Dockerfile

C:\Program Files\Docker>docker service ps angry_liskov

ID NAME IMAGE
NODE DESIRED STATE CURRENT STATE ERROR
PORTS
klkbhn742lv0 angry_liskov.1 windows/servercore/iis WIN-
BSTMQDRQC2E Ready Ready 3 seconds ago
y5blbdum70zo \_ angry_liskov.1 windows/servercore/iis WIN-
BSTMQDRQC2E Shutdown Failed 24 seconds ago "starting
container failed: co…"
yjq6zwzqj8kt \_ angry_liskov.1 windows/servercore/iis WIN-
BSTMQDRQC2E Shutdown Failed 31 seconds ago "starting
container failed: co…"

ytnnv80p03xx \_ angry_liskov.1 windows/servercore/iis WIN-

BSTMQDRQC2E Shutdown Failed about a minute ago "starting
container failed: co…"
xeqkxbsao57w \_ angry_liskov.1 windows/servercore/iis WIN-
BSTMQDRQC2E Shutdown Failed about a minute ago "starting
container failed: co…"

Si ves starting container failed: ... , puedes ver el error completo con docker
service ps --no-trunc (nombre del contenedor) :

Dockerfile

C:\Program Files\Docker>docker service ps --no-trunc angry_liskov

ID NAME IMAGE
NODE DESIRED STATE CURRENT STATE
 ERROR
PORTS
dwsd6sjlwsgic5vrglhtxu178 angry_liskov.1
windows/servercore/iis@sha256:868bca7e89e1743792e15f78edb5a73070ef44eae6807d
c3f05f9b94c23943d5 WIN-BSTMQDRQC2E Running Starting less
than a second ago
y5blbdum70zoh1f6uhx5nxsfv \_ angry_liskov.1
windows/servercore/iis@sha256:868bca7e89e1743792e15f78edb5a73070ef44eae6807d
c3f05f9b94c23943d5 WIN-BSTMQDRQC2E Shutdown Failed 39
seconds ago "starting container failed: container
e7b5d3adba7e510569c18d8e55f7c689d7cb92be40a516c91b363e27f84604d0 encountered
an error during CreateContainer: failure in a Windows system call: The
operating system of the container does not match the operating system of the
host. (0xc0370101) extra info:
{"SystemType":"Container","Name":"e7b5d3adba7e510569c18d8e55f7c689d7cb92be40
a516c91b363e27f84604d0","Owner":"docker","VolumePath":"\\\\?
\\Volume{2443d38a-1379-4bcf-a4b7-
fc6ad4cd7b65}","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"C:\\Program
Data\\docker\\windowsfilter\\e7b5d3adba7e510569c18d8e55f7c689d7cb92be40a516c
91b363e27f84604d0","Layers":[{"ID":"bcf2630f-ea95-529b-b33c-
e5cdab0afdb4","Path":"C:\\ProgramData\\docker\\windowsfilter\\200235127f9241
6724ae1d53ed3fdc86d78767132d019bdda1e1192ee4cf3ae4"},{"ID":"e3ea10a8-4c2f-
5b93-b2aa-
720982f116f6","Path":"C:\\ProgramData\\docker\\windowsfilter\\0ccc9fa71a9f4c
5f6f3bc8134fe3533e454e09f453de662cf99ab5d2106abbdc"},{"ID":"cff5391f-e481-
593c-aff7-
12e080c653ab","Path":"C:\\ProgramData\\docker\\windowsfilter\\a49576b24cd6ec
4a26202871c36c0a2083d507394a3072186133131a72601a31"},{"ID":"499cb51e-b891-
549a-b1f4-
8a25a4665fbd","Path":"C:\\ProgramData\\docker\\windowsfilter\\fdf2f52c4323c6
2f7ff9b031c0bc3af42cf5fba91098d51089d039fb3e834c08"},{"ID":"1532b584-8431-
5b5a-8735-
5e1b4fe9c2a9","Path":"C:\\ProgramData\\docker\\windowsfilter\\b2b88bc2a47abc
c682e422507abbba9c9b6d826d34e67b9e4e3144cc125a1f80"},{"ID":"a64b8da5-cd6e-
5540-bc73-
d81acae6da54","Path":"C:\\ProgramData\\docker\\windowsfilter\\5caaedbced1f54
6bccd01c9d31ea6eea4d30701ebba7b95ee8faa8c098a6845a"}],"HostName":"e7b5d3adba
7e","HvPartition":false,"EndpointList":["298bb656-8800-4948-a41c-
1b0500f3d94c"],"AllowUnqualifiedDNSQuery":true}"

Es el mismo error que CreateContainer: failure in a Windows system call: The

operating system of the container does not match the operating system of the host.

(0xc0370101) .

Corrección: actualizar el servicio para que use una versión

coincidente
Hay dos consideraciones para tener en cuenta con Docker Swarm. En caso de que
tengas un archivo de Compose que tenga un servicio que use una imagen que no hayas
creado tú, es conveniente actualizar la referencia según corresponda. Por ejemplo:
 YAML

version: '3'

services:
YourServiceName:
image: windows/servercore:1709
...

La otra consideración es si la imagen a la que apuntas es una que has creado tú mismo
(por ejemplo, contoso/myimage):

YAML

version: '3'

services:
YourServiceName:
image: contoso/myimage
...

En este caso, tendrías que usar el método descrito en Errores de las versiones que no
coinciden para modificar ese Dockerfile en lugar de la línea docker-compose.

Mitigación: usar el aislamiento de Hyper-V con Docker

Swarm
Los contenedores de Windows admiten el uso del aislamiento de Hyper-V en cada
contenedor, lo que requiere cambiar la configuración del servicio de Docker y, a
continuación, reiniciar el motor de Docker.

1. Edita C:\ProgramData\docker\config\daemon.json .

2. Agrega una línea con "exec-opts":["isolation=hyperv"] .

７ Nota

No existe el archivo daemon.json de manera predeterminada. Si observas que

es así cuando echas un vistazo en el directorio, debes crear el archivo. A
continuación, copia lo siguiente:

JSON
 {
"exec-opts":["isolation=hyperv"]
}

3. Cierra el archivo y guárdalo. Luego reinicia Docker Engine ejecutando los

siguientes cmdlets en PowerShell:

PowerShell

Stop-Service docker
Start-Service docker

4. Una vez que hayas reiniciado el servicio, inicia los contenedores. Cuando estén en
ejecución, puedes verificar el nivel de aislamiento de un contenedor examinando el
contenedor con el cmdlet siguiente:

PowerShell

docker inspect --format='{{json .HostConfig.Isolation}}'

$instanceNameOrId

Se mostrarán los valores "process" o "hyperv". Si modificaste y estableciste tu archivo

daemon.json como se describe más arriba, debería mostrarse "hyperv".

Mitigación: usar etiquetas y restricciones

Aquí te mostramos cómo usar etiquetas y restricciones para hacer coincidir las
versiones:

1. Agrega etiquetas a cada nodo.

En cada nodo, agrega dos etiquetas: OS y OsVersion . En este procedimiento se

supone que estás ejecutando de forma local, pero podría modificarse para
establecerlas en un host remoto.

PowerShell

docker node update --label-add OS="windows" $ENV:COMPUTERNAME

docker node update --label-add OsVersion="$((Get-
ComputerInfo).OsVersion)" $ENV:COMPUTERNAME

Después, puedes comprobarlo mediante la ejecución del comando docker node

inspect, que debe mostrar las etiquetas recién agregadas:
 YAML

"Spec": {
"Labels": {
"OS": "windows",
"OsVersion": "10.0.16296"
},
"Role": "manager",
"Availability": "active"
}

2. Agrega una restricción de servicio.

Ahora que has etiquetado cada nodo, puedes actualizar las restricciones que
determinan la ubicación de los servicios. En el ejemplo a continuación, sustituye
"contoso_service" con el nombre de tu servicio real:

PowerShell

docker service update \

--constraint-add "node.labels.OS == windows" \
--constraint-add "node.labels.OsVersion == $((Get-
ComputerInfo).OsVersion)" \
contoso_service

Esto aplica y limita los lugares en los que se puede ejecutar un nodo.

Para más información sobre cómo usar las restricciones de servicios, consulta la
referencia de service create .

Coincidencia de versiones mediante

Kubernetes
El mismo problema descrito en Coincidencia de versiones mediante Docker Swarm
puede producirse cuando se programan pods en Kubernetes. Este problema puede
evitarse con estrategias similares:

Vuelve a compilar el contenedor en función de la misma versión de sistema

operativo de desarrollo y producción. Para saber cómo hacerlo, consulta Elección
de la versión del sistema operativo del contenedor que se va a usar.
Usa etiquetas de nodo y nodeSelectors para asegurarte de que los pods se
programen en nodos compatibles si hay nodos de Windows Server 2016 y de
Windows Server, versión 1709, en el mismo clúster.
Usar clústeres independientes según la versión de SO
Buscar pods con errores debido a la falta de coincidencia
del SO
En este caso, una implementación incluía un pod programado en un nodo con una
versión de sistema operativo no coincidente y sin el aislamiento de Hyper-V habilitado.

El mismo error se muestra en los eventos que se muestran con kubectl describe pod
<podname> . Después de varios intentos, el estado del pod probablemente será
CrashLoopBackOff .

$ kubectl -n plang describe pod fabrikamfiber.web-789699744-rqv6p

Name: fabrikamfiber.web-789699744-rqv6p
Namespace: plang
Node: 38519acs9011/10.240.0.6
Start Time: Mon, 09 Oct 2017 19:40:30 +0000
Labels: io.kompose.service=fabrikamfiber.web
pod-template-hash=789699744
Annotations: kubernetes.io/created-by=
{"kind":"SerializedReference","apiVersion":"v1","reference":
{"kind":"ReplicaSet","namespace":"plang","name":"fabrikamfiber.web-
789699744","uid":"b5062a08-ad29-11e7-b16e-000d3a...
Status: Running
IP: 10.244.3.169
Created By: ReplicaSet/fabrikamfiber.web-789699744
Controlled By: ReplicaSet/fabrikamfiber.web-789699744
Containers:
fabrikamfiberweb:
Container ID:
docker://eab0151378308315ed6c31adf4ad9e31e6d65fd300e56e742757004a969a803a
Image: patricklang/fabrikamfiber.web:latest
Image ID: docker-
pullable://patricklang/fabrikamfiber.web@sha256:562741016ce7d9a232a389449a4f
d0a0a55aab178cf324144404812887250ead
Port: 80/TCP
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: ContainerCannotRun
Message: container
eab0151378308315ed6c31adf4ad9e31e6d65fd300e56e742757004a969a803a encountered
an error during CreateContainer: failure in a Windows system call: The
operating system of the container does not match the operating system of the
host. (0xc0370101) extra info:
{"SystemType":"Container","Name":"eab0151378308315ed6c31adf4ad9e31e6d65fd300
e56e742757004a969a803a","Owner":"docker","IsDummy":false,"VolumePath":"\\\\?
\\Volume{037b6606-bc9c-461f-ae02-
829c28410798}","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"C:\\Program
Data\\docker\\windowsfilter\\eab0151378308315ed6c31adf4ad9e31e6d65fd300e56e7
42757004a969a803a","Layers":[{"ID":"f8bc427f-7aa3-59c6-b271-
7331713e9451","Path":"C:\\ProgramData\\docker\\windowsfilter\\e206d2514a6265
a76645b9d6b3dc6a78777c34dbf5da9fa2d564651645685881"},{"ID":"a6f35e41-a86c-
5e4d-a19a-
a6c2464bfb47","Path":"C:\\ProgramData\\docker\\windowsfilter\\0f21f1e28ef130
30bbf0d87cbc97d1bc75f82ea53c842e9a3250a2156ced12d5"},{"ID":"4f624ca7-2c6d-
5c42-b73f-
be6e6baf2530","Path":"C:\\ProgramData\\docker\\windowsfilter\\4d9e2ad969fbd7
4fd58c98b5ab61e55a523087910da5200920e2b6f641d00c67"},{"ID":"88e360ff-32af-
521d-9a3f-
3760c12b35e2","Path":"C:\\ProgramData\\docker\\windowsfilter\\9e16a3d53d3e9b
33344a6f0d4ed34c8a46448ee7636b672b61718225b8165e6e"},{"ID":"20f1a4e0-a6f3-
5db3-9bf2-
01fd3e9e855a","Path":"C:\\ProgramData\\docker\\windowsfilter\\7eec7f59f9adce
38cc0a6755da58a3589287d920d37414b5b21b5b543d910461"},{"ID":"c2b3d728-4879-
5343-a92a-
b735752a4724","Path":"C:\\ProgramData\\docker\\windowsfilter\\8ed04b60acc0f6
5f541292a9e598d5f73019c8db425f8d49ea5819eab16a42f3"},{"ID":"2973e760-dc59-
5800-a3de-
ab9d93be81e5","Path":"C:\\ProgramData\\docker\\windowsfilter\\cc71305d45f09c
e377ef497f28c3a74ee027c27f20657d2c4a5f157d2457cc75"},{"ID":"454a7d36-038c-
5364-8a25-
fa84091869d6","Path":"C:\\ProgramData\\docker\\windowsfilter\\9e8cde1ce8f5de
861a5f22841f1ab9bc53d5f606d06efeacf5177f340e8d54d0"},{"ID":"9b748c8c-69eb-
55fb-a1c1-
5688cac4efd8","Path":"C:\\ProgramData\\docker\\windowsfilter\\8e02bf54040570
55a71d542780a2bb2731be4b3707c01918ba969fb4d83b98ec"},{"ID":"bfde5c26-b33f-
5424-9405-
9d69c2fea4d0","Path":"C:\\ProgramData\\docker\\windowsfilter\\77483cedfb0964
008c33d92d306734e1fab3b5e1ebb27e898f58ccfd108108f2"},{"ID":"bdabfbf5-80d1-
57f1-86f3-
448ce97e2d05","Path":"C:\\ProgramData\\docker\\windowsfilter\\aed2ebbb31ad24
b38ee8521dd17744319f83d267bf7f360bc177e27ae9a006cf"},{"ID":"ad9b34f2-dcee-
59ea-8962-
b30704ae6331","Path":"C:\\ProgramData\\docker\\windowsfilter\\d44d3a675fec10
70b61d6ea9bacef4ac12513caf16bd6453f043eed2792f75d8"}],"HostName":"fabrikamfi
ber.web-789699744-rqv6p","MappedDirectories":
[{"HostPath":"c:\\var\\lib\\kubelet\\pods\\b50f0027-ad29-11e7-b16e-
000d3afd2878\\volumes\\kubernetes.io~secret\\default-token-
rw9dn","ContainerPath":"c:\\var\\run\\secrets\\kubernetes.io\\serviceaccount
","ReadOnly":true,"BandwidthMaximum":0,"IOPSMaximum":0}],"HvPartition":false
,"EndpointList":null,"NetworkSharedContainerName":"586870f5833279678773cb700
db3c175afc81d557a75867bf39b43f985133d13","Servicing":false,"AllowUnqualified
DNSQuery":false}
Exit Code: 128
Started: Mon, 09 Oct 2017 20:27:08 +0000
Finished: Mon, 09 Oct 2017 20:27:08 +0000
Ready: False
Restart Count: 10
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-rw9dn
(ro)
Conditions:
Type Status
 Initialized True
Ready False
PodScheduled True
Volumes:
default-token-rw9dn:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-rw9dn
Optional: false
QoS Class: BestEffort
Node-Selectors: beta.kubernetes.io/os=windows
Tolerations: <none>
Events:
FirstSeen LastSeen Count From
SubObjectPath Type Reason
Message
--------- -------- ----- ---- ------------
- -------- ------ -------
49m 49m 1 default-scheduler
Normal Scheduled Successfully assigned
fabrikamfiber.web-789699744-rqv6p to 38519acs9011
49m 49m 1 kubelet, 38519acs9011
Normal SuccessfulMountVolume MountVolume.SetUp succeeded for
volume "default-token-rw9dn"
29m 29m 1 kubelet, 38519acs9011
spec.containers{fabrikamfiberweb} Warning Failed
Failed to pull image "patricklang/fabrikamfiber.web:latest": rpc error: code
= 2 desc = Error response from daemon: {"message":"Get https://registry-
1.docker.io/v2/: dial tcp: lookup registry-1.docker.io: no such host"}
49m 3m 12 kubelet, 38519acs9011
spec.containers{fabrikamfiberweb} Normal Pulling
pulling image "patricklang/fabrikamfiber.web:latest"
33m 3m 11 kubelet, 38519acs9011
spec.containers{fabrikamfiberweb} Normal Pulled
Successfully pulled image "patricklang/fabrikamfiber.web:latest"
33m 3m 11 kubelet, 38519acs9011
spec.containers{fabrikamfiberweb} Normal Created
Created container
33m 2m 11 kubelet, 38519acs9011
spec.containers{fabrikamfiberweb} Warning Failed
Error: failed to start container "fabrikamfiberweb": Error response from
daemon: {"message":"container fabrikamfiberweb encountered an error during
CreateContainer: failure in a Windows system call: The operating system of
the container does not match the operating system of the host. (0xc0370101)
extra info:
{\"SystemType\":\"Container\",\"Name\":\"fabrikamfiberweb\",\"Owner\":\"dock
er\",\"IsDummy\":false,\"VolumePath\":\"\\\\\\\\?\\\\Volume{037b6606-bc9c-
461f-ae02-
829c28410798}\",\"IgnoreFlushesDuringBoot\":true,\"LayerFolderPath\":\"C:\\\
\ProgramData\\\\docker\\\\windowsfilter\\\\fabrikamfiberweb\",\"Layers\":
[{\"ID\":\"f8bc427f-7aa3-59c6-b271-
7331713e9451\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\e2
06d2514a6265a76645b9d6b3dc6a78777c34dbf5da9fa2d564651645685881\"},
{\"ID\":\"a6f35e41-a86c-5e4d-a19a-
a6c2464bfb47\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\0f
21f1e28ef13030bbf0d87cbc97d1bc75f82ea53c842e9a3250a2156ced12d5\"},
 {\"ID\":\"4f624ca7-2c6d-5c42-b73f-
be6e6baf2530\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\4d
9e2ad969fbd74fd58c98b5ab61e55a523087910da5200920e2b6f641d00c67\"},
{\"ID\":\"88e360ff-32af-521d-9a3f-
3760c12b35e2\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\9e
16a3d53d3e9b33344a6f0d4ed34c8a46448ee7636b672b61718225b8165e6e\"},
{\"ID\":\"20f1a4e0-a6f3-5db3-9bf2-
01fd3e9e855a\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\7e
ec7f59f9adce38cc0a6755da58a3589287d920d37414b5b21b5b543d910461\"},
{\"ID\":\"c2b3d728-4879-5343-a92a-
b735752a4724\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\8e
d04b60acc0f65f541292a9e598d5f73019c8db425f8d49ea5819eab16a42f3\"},
{\"ID\":\"2973e760-dc59-5800-a3de-
ab9d93be81e5\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\cc
71305d45f09ce377ef497f28c3a74ee027c27f20657d2c4a5f157d2457cc75\"},
{\"ID\":\"454a7d36-038c-5364-8a25-
fa84091869d6\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\9e
8cde1ce8f5de861a5f22841f1ab9bc53d5f606d06efeacf5177f340e8d54d0\"},
{\"ID\":\"9b748c8c-69eb-55fb-a1c1-
5688cac4efd8\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\8e
02bf5404057055a71d542780a2bb2731be4b3707c01918ba969fb4d83b98ec\"},
{\"ID\":\"bfde5c26-b33f-5424-9405-
9d69c2fea4d0\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\77
483cedfb0964008c33d92d306734e1fab3b5e1ebb27e898f58ccfd108108f2\"},
{\"ID\":\"bdabfbf5-80d1-57f1-86f3-
448ce97e2d05\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\ae
d2ebbb31ad24b38ee8521dd17744319f83d267bf7f360bc177e27ae9a006cf\"},
{\"ID\":\"ad9b34f2-dcee-59ea-8962-
b30704ae6331\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\d4
4d3a675fec1070b61d6ea9bacef4ac12513caf16bd6453f043eed2792f75d8\"}],\"HostNam
e\":\"fabrikamfiber.web-789699744-rqv6p\",\"MappedDirectories\":
[{\"HostPath\":\"c:\\\\var\\\\lib\\\\kubelet\\\\pods\\\\b50f0027-ad29-11e7-
b16e-000d3afd2878\\\\volumes\\\\kubernetes.io~secret\\\\default-token-
rw9dn\",\"ContainerPath\":\"c:\\\\var\\\\run\\\\secrets\\\\kubernetes.io\\\\
serviceaccount\",\"ReadOnly\":true,\"BandwidthMaximum\":0,\"IOPSMaximum\":0}
],\"HvPartition\":false,\"EndpointList\":null,\"NetworkSharedContainerName\"
:\"586870f5833279678773cb700db3c175afc81d557a75867bf39b43f985133d13\",\"Serv
icing\":false,\"AllowUnqualifiedDNSQuery\":false}"}
33m 11s 151 kubelet, 38519acs9011
Warning FailedSync Error syncing pod
32m 11s 139 kubelet, 38519acs9011
spec.containers{fabrikamfiberweb} Warning BackOff
Back-off restarting failed container

Mitigación: usar etiquetas de nodo y nodeSelector

Ejecuta kubectl get node para obtener una lista de todos los nodos. Después de esto,
puedes ejecutar kubectl describe node (nombre del nodo) para obtener más detalles.

En el ejemplo siguiente, dos nodos de Windows ejecutan versiones diferentes:

$ kubectl get node

NAME STATUS AGE VERSION

38519acs9010 Ready 21h v1.7.7-7+e79c96c8ff2d8e
38519acs9011 Ready 4h v1.7.7-25+bc3094f1d650a2
k8s-linuxpool1-38519084-0 Ready 21h v1.7.7
k8s-master-38519084-0 Ready 21h v1.7.7

$ kubectl describe node 38519acs9010

Name: 38519acs9010
Role:
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/instance-type=Standard_D2_v2
beta.kubernetes.io/os=windows
failure-domain.beta.kubernetes.io/region=westus2
failure-domain.beta.kubernetes.io/zone=0
kubernetes.io/hostname=38519acs9010
Annotations: node.alpha.kubernetes.io/ttl=0
volumes.kubernetes.io/controller-managed-attach-
detach=true
Taints: <none>
CreationTimestamp: Fri, 06 Oct 2017 01:41:02 +0000

...

System Info:
Machine ID: 38519acs9010
System UUID:
Boot ID:
Kernel Version: 10.0 14393
(14393.1715.amd64fre.rs1_release_inmarket.170906-1810)
OS Image:
Operating System: windows
Architecture: amd64
...

$ kubectl describe node 38519acs9011

Name: 38519acs9011
Role:
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/instance-type=Standard_DS1_v2
beta.kubernetes.io/os=windows
failure-domain.beta.kubernetes.io/region=westus2
failure-domain.beta.kubernetes.io/zone=0
kubernetes.io/hostname=38519acs9011
Annotations: node.alpha.kubernetes.io/ttl=0
volumes.kubernetes.io/controller-managed-attach-
detach=true
Taints: <none>
CreationTimestamp: Fri, 06 Oct 2017 18:13:25 +0000
Conditions:
...
 System Info:
Machine ID: 38519acs9011
System UUID:
Boot ID:
Kernel Version: 10.0 16299
(16299.0.amd64fre.rs3_release.170922-1354)
OS Image:
Operating System: windows
Architecture: amd64
...

Vamos a usar este ejemplo para mostrar cómo hacer coincidir las versiones:

1. Anota el nombre de cada nodo y el valor de Kernel Version de la información del

sistema.

En nuestro ejemplo, la información se verá como sigue:

Nombre Version

38519acs9010 14393.1715.amd64fre.rs1_release_inmarket.170906-1810

38519acs9011 16299.0.amd64fre.rs3_release.170922-1354

2. Agrega una etiqueta para cada nodo denominada beta.kubernetes.io/osbuild .

Windows Server 2016 necesita que se admitan las versiones principal y secundaria
(en este ejemplo, 14393.1715) sin aislamiento de Hyper-V. Windows Server, versión
1709, solo necesita la versión principal (en este ejemplo, 16299) para coincidir.

En este ejemplo, el comando para agregar las etiquetas tiene el siguiente aspecto:

$ kubectl label node 38519acs9010 beta.kubernetes.io/osbuild=14393.1715

node "38519acs9010" labeled

$ kubectl label node 38519acs9011 beta.kubernetes.io/osbuild=16299

node "38519acs9011" labeled

3. Comprueba que las etiquetas están allí ejecutando kubectl get nodes --show-
labels.

En este ejemplo, el resultado tendrá este aspecto:

 $ kubectl get nodes --show-labels

NAME STATUS AGE

VERSION LABELS
38519acs9010 Ready,SchedulingDisabled 3d
v1.7.7-7+e79c96c8ff2d8e
beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-
type=Standard_D2_v2,beta.kubernetes.io/os=windows,beta.kubernetes.io/os
build=14393.1715,failure-
domain.beta.kubernetes.io/region=westus2,failure-
domain.beta.kubernetes.io/zone=0,kubernetes.io/hostname=38519acs9010
38519acs9011 Ready 3d
v1.7.7-25+bc3094f1d650a2
beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-
type=Standard_DS1_v2,beta.kubernetes.io/os=windows,beta.kubernetes.io/o
sbuild=16299,failure-domain.beta.kubernetes.io/region=westus2,failure-
domain.beta.kubernetes.io/zone=0,kubernetes.io/hostname=38519acs9011
k8s-linuxpool1-38519084-0 Ready 3d v1.7.7
agentpool=linuxpool1,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/i
nstance-type=Standard_D2_v2,beta.kubernetes.io/os=linux,failure-
domain.beta.kubernetes.io/region=westus2,failure-
domain.beta.kubernetes.io/zone=0,kubernetes.io/hostname=k8s-linuxpool1-
38519084-0,kubernetes.io/role=agent
k8s-master-38519084-0 Ready 3d v1.7.7
beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-
type=Standard_D2_v2,beta.kubernetes.io/os=linux,failure-
domain.beta.kubernetes.io/region=westus2,failure-
domain.beta.kubernetes.io/zone=0,kubernetes.io/hostname=k8s-master-
38519084-0,kubernetes.io/role=master

4. Agrega selectores de nodo a las implementaciones. En este caso de ejemplo,

agregaremos nodeSelector a la especificación de contenedor con
beta.kubernetes.io/os = windows y beta.kubernetes.io/osbuild = 14393.* o
16299 para que coincida con el sistema operativo base utilizado por el contenedor.

A continuación se muestra un ejemplo completo para ejecutar un contenedor

creado para Windows Server 2016:

YAML

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
kompose.cmd: kompose convert -f docker-compose-combined.yml
kompose.version: 1.2.0 (99f88ef)
creationTimestamp: null
labels:
io.kompose.service: fabrikamfiber.web
name: fabrikamfiber.web
 spec:
replicas: 1
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
io.kompose.service: fabrikamfiber.web
spec:
containers:
- image: patricklang/fabrikamfiber.web:latest
name: fabrikamfiberweb
ports:
- containerPort: 80
resources: {}
restartPolicy: Always
nodeSelector:
"beta.kubernetes.io/os": windows
"beta.kubernetes.io/osbuild": "14393.1715"
status: {}

El pod ya puede iniciarse con la implementación actualizada. Los selectores de

nodo también se muestran en kubectl describe pod <podname> , por lo que puedes
ejecutar ese comando para verificar que se han agregado.

La salida de nuestro ejemplo es la siguiente:

$ kubectl -n plang describe po fa

Name: fabrikamfiber.web-1780117715-5c8vw
Namespace: plang
Node: 38519acs9010/10.240.0.4
Start Time: Tue, 10 Oct 2017 01:43:28 +0000
Labels: io.kompose.service=fabrikamfiber.web
pod-template-hash=1780117715
Annotations: kubernetes.io/created-by=
{"kind":"SerializedReference","apiVersion":"v1","reference":
{"kind":"ReplicaSet","namespace":"plang","name":"fabrikamfiber.web-
1780117715","uid":"6a07aaf3-ad5c-11e7-b16e-000d3...
Status: Running
IP: 10.244.1.84
Created By: ReplicaSet/fabrikamfiber.web-1780117715
Controlled By: ReplicaSet/fabrikamfiber.web-1780117715
Containers:
fabrikamfiberweb:
Container ID:
docker://c94594fb53161f3821cf050d9af7546991aaafbeab41d333d9f64291327fae
13
Image: patricklang/fabrikamfiber.web:latest
Image ID: docker-
pullable://patricklang/fabrikamfiber.web@sha256:562741016ce7d9a232a3894
49a4fd0a0a55aab178cf324144404812887250ead
Port: 80/TCP
State: Running
Started: Tue, 10 Oct 2017 01:43:42 +0000
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-
rw9dn (ro)
Conditions:
Type Status
Initialized True
Ready True
PodScheduled True
Volumes:
default-token-rw9dn:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-rw9dn
Optional: false
QoS Class: BestEffort
Node-Selectors: beta.kubernetes.io/os=windows
beta.kubernetes.io/osbuild=14393.1715
Tolerations: <none>
Events:
FirstSeen LastSeen Count From
SubObjectPath Type Reason
Message
--------- -------- ----- ---- -------
------ -------- ------
-------
5m 5m 1 default-scheduler
Normal Scheduled Successfully assigned
fabrikamfiber.web-1780117715-5c8vw to 38519acs9010
5m 5m 1 kubelet, 38519acs9010
Normal SuccessfulMountVolume MountVolume.SetUp succeeded for
volume "default-token-rw9dn"
5m 5m 1 kubelet, 38519acs9010
spec.containers{fabrikamfiberweb} Normal Pulling
pulling image "patricklang/fabrikamfiber.web:latest"
5m 5m 1 kubelet, 38519acs9010
spec.containers{fabrikamfiberweb} Normal Pulled
Successfully pulled image "patricklang/fabrikamfiber.web:latest"
5m 5m 1 kubelet, 38519acs9010
spec.containers{fabrikamfiberweb} Normal Created
Created container
5m 5m 1 kubelet, 38519acs9010
spec.containers{fabrikamfiberweb} Normal Started
Started container
Actualización de contenedores de
Windows Server
Artículo • 05/02/2025

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

Como parte del mantenimiento de Windows Server cada mes, publicamos

periódicamente imágenes base de contenedor del SO Windows Server actualizadas. Con
estas actualizaciones, puedes automatizar la creación de imágenes de contenedor
actualizadas o actualizarlas manualmente extrayendo de la versión más reciente. Los
contenedores de Windows Server no tienen una pila de servicio, como Windows Server.
No puedes obtener actualizaciones en un contenedor como lo haces con Windows
Server. Por lo tanto, cada mes volvemos a generar las imágenes base de contenedor del
SO Windows Server con las actualizaciones, y publicamos las imágenes de contenedor
actualizadas.

Otras imágenes de contenedor, como .NET o IIS, se volverán a generar en función de las
imágenes base de contenedor del SO actualizadas y se publicarán mensualmente.

Cómo obtener actualizaciones de contenedores

de Windows Server
Actualizamos las imágenes base de contenedor del SO Windows Server en consonancia
con la cadencia de entregas de Windows. Las imágenes de contenedor actualizadas se
publican el segundo martes de cada mes, a los que a veces llamamos la publicación "B",
con un número de prefijo según el mes de publicación. Por ejemplo, llamamos a la
actualización de febrero "2B" y a la actualización de marzo "3B". Este evento de
actualización mensual es la única versión normal que incluye nuevas correcciones de
seguridad.

El servidor que hospeda estos contenedores, denominado host de contenedor o

simplemente "host", se puede atender durante otros eventos de actualización distintos
de las publicaciones "B". Para más información sobre la cadencia de mantenimiento de
actualizaciones de Windows, vea nuestra entrada de blog Explicación de las
actualizaciones mensuales de Windows .

Si estás más familiarizado con Docker Hub que con MCR, esta entrada de blog te
proporcionará una explicación más detallada.
Para obtener una lista completa de las imágenes de contenedor del sistema operativo
base de Windows Server, las versiones y sus respectivas etiquetas, vea los siguientes
recursos en Docker Hub:

Windows Server
Windows Server Core
Nano Server

Las imágenes de Windows Server con entrega mensual que publica Microsoft en Azure
Marketplace también vienen con imágenes base de contenedor del SO preinstaladas.
Encontrarás más información en nuestra página de precios de Azure Marketplace para
Windows Server . Normalmente actualizamos estas imágenes unos cinco días
laborables después de la publicación "B".

Para obtener una lista completa de las imágenes y versiones de Windows Server,
consulta el historial de actualizaciones de publicación de Windows Server en Azure
Marketplace .

Compatibilidad de versiones de host y

contenedor
Hay dos tipos de modos de aislamiento para los contenedores de Windows: aislamiento
de procesos y aislamiento de Hyper-V. El aislamiento de Hyper-V es más flexible en
cuanto a la compatibilidad entre versiones de host y contenedor. Para más información,
consulta Compatibilidad de versiones y Modos de aislamiento. Esta sección se centrará
en los contenedores con aislamiento de procesos, a menos que se indique lo contrario.

Al actualizar el host de contenedor o la imagen del contenedor con las actualizaciones

mensuales, siempre y cuando se admitan tanto el host como la imagen de contenedor
(Windows Server versión 1809 o posterior), no es necesario que las revisiones del host y
de la imagen del contenedor coincidan para que el contenedor se inicie y ejecute con
normalidad.

No obstante, podrías tener problemas al usar contenedores de Windows Server con la

versión de actualización de seguridad del 11 de febrero de 2020 (también denominada
"2B") o versiones posteriores de actualización de seguridad mensuales. Para más
información, consulta este artículo de Soporte técnico de Microsoft . Estos problemas
provienen de un cambio de seguridad que exigía que una interfaz entre el modo de
usuario y el modo kernel cambiara para garantizar la seguridad de las aplicaciones.
Estos problemas solo se producen en los contenedores con aislamiento de procesos, ya
que estos contenedores comparten el modo de kernel con el host de contenedor. Esto
significa que las imágenes de contenedor sin el componente de modo de usuario
actualizado no eran seguras y no eran compatibles con la nueva interfaz de kernel
protegida.

El 18 de febrero de 2020 publicamos una corrección. Esta nueva versión ha establecido

una "nueva línea base". Esta nueva línea base sigue estas reglas:

Toda combinación de hosts y contenedores anteriores a 2B funcionará.

Toda combinación de hosts y contenedores donde ambos sean posteriores a 2B
funcionará.
Ninguna combinación de hosts y contenedores en distintos lados de la nueva base
de referencia funcionará. Por ejemplo, un host 3B y un contenedor 1B no
funcionarán.

Usemos la publicación de la actualización de seguridad mensual de marzo de 2020

como ejemplo para mostrar cómo funcionan estas nuevas reglas de compatibilidad. En
la tabla siguiente, la publicación de la actualización de seguridad de marzo de 2020 se
denomina "3B", la actualización de febrero de 2020 es "2B", y la actualización de enero
de 2020 es "1B".

ﾉ Expandir tabla

Host Contenedor Compatibilidad

3B 3B Sí

3B 2B Sí

3B 1B o anterior No

2B 3B Sí

2B 2B Sí

2B 1B o anterior No

1B o anterior 3B No

1B o anterior 2B No

1B o anterior 1B o anterior Sí

Solución de errores de coincidencia entre el

host y la imagen de contenedor
Antes de empezar, asegúrate de familiarizarte con la información de Compatibilidad de
versiones. Esta información te ayudará a averiguar si el problema se debe a que las
revisiones no coinciden. Si estableces que la causa se debe a la falta coincidencia entre
las revisiones, puedes seguir las instrucciones de esta sección para solucionar el
problema.

Consulta de la versión del host de contenedor

Si puedes acceder al host de contenedor, puedes ejecutar el comando ver para obtener
su versión del SO. Por ejemplo, si ejecutas ver en un sistema que ejecuta
Windows Server 2019 con la publicación más reciente de la actualización de seguridad
de febrero de 2020, verás lo siguiente:

batch

Microsoft Windows [Version 10.0.17763.1039]

(c) 2018 Microsoft Corporation. All rights reserved.

C:\>ver

Microsoft Windows [Version 10.0.17763.1039]

７ Nota

El número de revisión de este ejemplo se muestra como 1039, no 1040, porque la

publicación de la actualización de seguridad de febrero de 2020 no tenía una
versión 2B extraordinaria para Windows Server. Solo había una versión 2B
extraordinaria para los contenedores, que tenía un número de revisión de 1040.

Si no tienes acceso directo al host de contenedor, consulta con el administrador de TI. Si

trabajas en la nube, consulta el sitio web del proveedor de la nube para averiguar en
qué versión del SO del host de contenedor se ejecuta. Por ejemplo, si usas Azure
Kubernetes Service (AKS), puedes encontrar la versión del SO del host en las notas de la
versión de AKS .

Consulta de la versión de la imagen del contenedor

Sigue estas instrucciones para averiguar qué versión ejecuta el contenedor:

1. En PowerShell, ejecute el siguiente cmdlet:

PowerShell
 docker images

La salida debe parecerse a lo siguiente:

PowerShell

REPOSITORY TAG IMAGE ID

CREATED SIZE
mcr.microsoft.com/windows/servercore ltsc2019 b456290f487c
4 weeks ago 4.84GB
mcr.microsoft.com/windows 1809 58229ca44fa7
4 weeks ago 12GB
mcr.microsoft.com/windows/nanoserver 1809 f519d4f3a868
4 weeks ago 251M

2. Ejecute el comando docker inspect para el identificador de imagen de la imagen

de contenedor que no funciona. Esto le mostrará la versión de destino de la
imagen de contenedor.

Por ejemplo, supongamos que ejecutamos run docker inspect para una imagen
de contenedor ltsc 2019:

PowerShell

docker inspect b456290f487c

"Architecture": "amd64",

"Os": "windows",

"OsVersion": "10.0.17763.1039",

"Size": 4841309825,

"VirtualSize": 4841309825,

En este ejemplo, la versión del SO del contenedor se muestra como

10.0.17763.1039 .

Si ya estás ejecutando un contenedor, también puedes ejecutar el comando ver

dentro del contenedor para obtener la versión. Por ejemplo, al ejecutar ver en una
imagen de contenedor de Server Core de Windows Server 2019 con la publicación
más reciente de la actualización de seguridad de febrero de 2020, se mostrará lo
siguiente:
 batch

Microsoft Windows [Version 10.0.17763.1040]

(c) 2020 Microsoft Corporation. All rights reserved.

C:\>ver

Microsoft Windows [Version 10.0.17763.1040]

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Actualización de contenedores a una
nueva versión del sistema operativo
Windows
Artículo • 05/02/2025

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

En este tema se describe cómo actualizar contenedores de Windows a una nueva

versión del sistema operativo Windows o Windows Server. Hay dos pasos para actualizar
contenedores:

1. Actualice el host de contenedor a la nueva versión del sistema operativo.

2. Cree nuevas instancias de contenedor mediante la nueva versión del sistema
operativo.

７ Nota

Si solo tiene que actualizar (o revisar) la imagen actual del contenedor del sistema
operativo base de Windows, vea Actualización de los contenedores para extraer la
imagen de revisión más reciente para los contenedores.

Actualización del host del contenedor

Para actualizar el host de contenedor a una versión más reciente de Windows o
Windows Server, puede realizar una actualización local o una instalación limpia. Dado
que el host de contenedor y los contenedores de Windows comparten un único kernel,
debe asegurarse de que la versión del sistema operativo de la imagen base del
contenedor coincide con la del host. Pero todavía puede tener una versión más reciente
del host de contenedor con una imagen base anterior con aislamiento de Hyper-V. En
Windows Server 2022, puede implementar este escenario con aislamiento de procesos
(en versión preliminar).

Creación de nuevas instancias de contenedor

mediante la nueva versión del sistema
operativo
Para crear las nuevas instancias de contenedor, necesitará:

Extracción de la imagen base del contenedor

Edición del Dockerfile para que apunte a la nueva imagen base
Compilación y ejecución de la nueva imagen de aplicación
Etiquete e inserte la imagen en el registro

Extracción de la imagen base del contenedor

Después de haber extraído la nueva versión del sistema operativo Windows en el host
de contenedor, siga los pasos siguientes para actualizar la imagen base:

1. Seleccione la imagen base del contenedor a la que desea actualizar.

2. Abra una sesión de PowerShell como administrador y, en función de la versión del

sistema operativo que eligió, ejecute el comando de extracción de Docker para
extraer una imagen:

PowerShell

PS C:\> docker pull mcr.microsoft.com/windows/servercore:ltsc2022

En este ejemplo se extrae la imagen base Server Core versión 20H2.

3. Una vez finalizada la descarga de la imagen, puede comprobar que se ha extraído

la nueva imagen mediante la ejecución del comando docker images para
devolver una lista de imágenes extraídas:

PowerShell

docker images

Edición del Dockerfile para que apunte a la nueva imagen

base
A continuación, quiere crear e iniciar nuevas instancias de contenedor mediante la
nueva imagen base que ha extraído. Para automatizar este proceso, edite el Dockerfile
para redirigirlo a la nueva imagen.

７ Nota
 Si quiere actualizar la imagen de cualquier contenedor que se esté ejecutando
actualmente, deberá detener los contenedores mediante docker stop y, a
continuación, ejecutar docker rm para quitar los contenedores.

Abra el Dockerfile en un editor de texto y realice las actualizaciones. En el ejemplo

siguiente, el Dockerfile se actualiza a Server Core 20H2 con la aplicación IIS.

Dockerfile

FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022 AS
build-env
WORKDIR /app

COPY *.csproj ./
RUN PowerShell Install-WindowsFeature NET-Framework-45-ASPNET

FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["ServiceMonitor.exe", "w3svc"]

Compilación y ejecución de la nueva imagen de

aplicación
Una vez actualizado el Dockerfile, debe compilar y ejecutar la imagen de la aplicación.

1. Utiliza el comando docker build para construir tu imagen, como se muestra a

continuación:

PowerShell

docker build -t iss .

2. Para ejecutar el contenedor recién compilado, ejecute el comando docker run :

PowerShell

docker run -d -p 8080:80 --name iss-app iss

Etiquete e inserte la imagen en el registro

Para permitir que otros hosts vuelvan a usar la nueva imagen, debe etiquetar y, a
continuación, subir la imagen de contenedor a su registro.
 1. Use etiqueta docker para etiquetar la imagen de la siguiente manera:

PowerShell

docker tag mcr.microsoft.com/windows/servercore/iis:windowsservercore-

ltsc2022 <login-server>/iss

2. Use docker push para insertar la imagen en el registro de contenedores de la

siguiente manera:

PowerShell

docker push <login-server> iss

Actualización de contenedores mediante un

orquestador
También puede volver a implementar los contenedores de Windows mediante un
orquestador, como Azure Kubernetes Service y AKS en Azure Stack HCI. El orquestador
proporciona una automatización eficaz para hacerlo a escala. Para más información,
consulte Tutorial: Actualización de una aplicación en Azure Kubernetes Service o
Tutorial: Actualización de una aplicación en Azure Kubernetes Service en Azure Stack
HCI.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Implementar controles de recursos para
contenedores de Windows
Artículo • 21/03/2023

Se aplica a: Windows Server 2022, Windows Server 2019

Hay varios controles de recursos que pueden implementarse por contenedor y por
recurso. De forma predeterminada, los contenedores ejecutados están sujetos a la
administración habitual de recursos de Windows, lo que, en general, se comparte de
forma equitativa. Sin embargo, un desarrollador o administrador puede limitar el uso de
los recursos, o influir sobre él, tras configurar estos controles. Entre los recursos que se
pueden controlar se incluyen: CPU/procesador, memoria/RAM, disco/almacenamiento y
redes/rendimiento.

Los contenedores de Windows utilizan objetos de trabajo para agrupar y realizar un

seguimiento de los procesos asociados a cada contenedor. Los controles de recursos se
implementan en el objeto de trabajo principal asociado al contenedor.

En el caso de aislamiento de Hyper-V, los controles de recursos se aplican a la máquina

virtual y al objeto de trabajo del contenedor que se ejecuta automáticamente en dicha
máquina. Esto garantiza que aunque un proceso que se ejecuta en el contenedor
omitiera o pasara por alto los controles de objetos de trabajo, la máquina virtual se
aseguraría de que fuera incapaz de superar los controles de recursos definidos.

Recursos
Para cada recurso, esta sección ofrece una asignación entre la interfaz de línea de
comandos Docker como un ejemplo de cómo debería usarse el control de recursos (un
orquestador u otras herramientas pueden configurarlo) a la API de servicio de proceso
de host (HCS) que ha implementado Windows (ten en cuenta que esta descripción es de
nivel alto y que la implementación subyacente está sujeta a cambios).

Memoria

Resource Location

Interfaz de docker --memory

Interfaz de HCS MemoryMaximumInMB

Resource Location

Kernel compartido JOB_OBJECT_LIMIT_JOB_MEMORY

Aislamiento de Hyper-V Memoria de máquina virtual

７ Nota

Con respecto al aislamiento de Hyper-V en Windows Server 2016, al usar un límite

de memoria, verá cómo el contenedor asigna inicialmente el límite de memoria y,
luego, se inicia para devolverlo al host de contenedor. Las versiones posteriores de
Windows Server (1709 o posteriores) han optimizado este proceso.

CPU (recuento)

Resource Location

Interfaz de docker --cpus

Interfaz de HCS ProcessorCount

Kernel compartido Simulado con JOB_OBJECT_CPU_RATE_CONTROL_HARD_CAP*

Aislamiento de Hyper-V Número de procesadores virtuales expuestos

CPU (porcentaje)

Resource Location

Interfaz de docker --cpu-percent

Interfaz de HCS ProcessorMaximum

Kernel compartido JOB_OBJECT_CPU_RATE_CONTROL_HARD_CAP

Aislamiento de Hyper-V Límites de hipervisor en procesadores virtuales

CPU (recursos compartidos)

Resource Location

Interfaz de docker --cpu-shares

Interfaz de HCS ProcessorWeight

 Resource Location

Kernel compartido JOB_OBJECT_CPU_RATE_CONTROL_WEIGHT_BASED

Aislamiento de Hyper-V Pesos de procesadores virtuales de hipervisor

Almacenamiento (imagen)

Resource Location

Interfaz de docker --io-maxbandwidth/--io-maxiops

Interfaz de HCS StorageIOPSMaximum y StorageBandwidthMaximum

Kernel compartido JOBOBJECT_IO_RATE_CONTROL_INFORMATION

Aislamiento de Hyper-V JOBOBJECT_IO_RATE_CONTROL_INFORMATION

Almacenamiento (volúmenes)

Resource Location

Interfaz de docker --storage-opt size=

Interfaz de HCS StorageSandboxSize

Kernel compartido JOBOBJECT_IO_RATE_CONTROL_INFORMATION

Aislamiento de Hyper-V JOBOBJECT_IO_RATE_CONTROL_INFORMATION

Detalles o notas adicionales

Requisitos de memoria
Los contenedores de Windows ejecutan algún proceso del sistema en cada contenedor;
por lo general, aquellos que proporcionan funcionalidad por contenedor como la
administración de usuarios, redes etc… y si bien gran parte de la memoria necesaria
para estos procesos se comparte entre contenedores, el límite de memoria debe ser lo
suficientemente alto como para permitirlos. En el documento requisitos del sistema se
incluye una tabla para cada tipo de imagen base con y sin aislamiento de Hyper-V.

Recursos compartidos de CPU (sin el aislamiento de

Hyper-V)
Al usar los recursos compartidos de CPU, la implementación subyacente (cuando no se
utiliza el aislamiento de Hyper-V) configura
JOBOBJECT_CPU_RATE_CONTROL_INFORMATION, lo que establece específicamente la
marca de control en JOB_OBJECT_CPU_RATE_CONTROL_WEIGHT_BASED y proporciona
un peso adecuado. Los intervalos de peso válido del objeto de trabajo son 1 – 9 con un
valor predeterminado de 5, lo que supone una fidelidad inferior a los valores de
servicios de proceso de host de 1-10000. A modo de ejemplo, un peso de recurso
compartido de 7500 produciría un peso de 7 o un peso de recurso compartido de 2500
daría como resultado un valor de 2.
Zona horaria virtualizada
Artículo • 05/02/2025

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

Los contenedores de Windows admiten la capacidad de mantener una configuración de

zona horaria virtualizada independiente del host. Todas las configuraciones usadas
tradicionalmente para la zona horaria del host se han virtualizado y se crean instancias
de cada contenedor. Con esta característica, los contenedores de Windows ofrecen los
siguientes comportamientos:

Al iniciar el contenedor, la zona horaria del host se hereda y permanece dentro del
contenedor. Si la zona horaria del host cambia mientras se ejecuta el contenedor,
la zona horaria almacenada en el contenedor no cambia. Para volver a heredar la
zona horaria del host, se debe reiniciar el contenedor.
El contenedor mantiene la configuración de zona horaria del host que se observa
al iniciar el contenedor solo hasta que el usuario configura explícitamente la zona
horaria desde dentro del contenedor. Una vez establecida la zona horaria desde
dentro del contenedor, la configuración se virtualiza y el contenedor ya no hace
referencia al host.
Si configura la zona horaria del contenedor y, posteriormente, guarda el estado del
contenedor, la configuración de zona horaria persiste en los reinicios.

Todas las API de modo kernel y modo de usuario relacionadas con la configuración de la
zona horaria del sistema ahora son compatibles con contenedores. Cuando un
subproceso que se ejecuta en el contexto de un contenedor llama a una API del sistema
para consultar la hora local, recupera la configuración de zona horaria del contenedor
en lugar de la del host. Los datos de zona horaria escritos desde dentro de un
contenedor ahora se conservan en el almacenamiento específico del contenedor y el
contenedor en cuestión ya no hereda los datos de zona horaria actuales del host
durante el inicio. Esto significa que una vez establecida la zona horaria, el contenedor
sigue usando la zona horaria configurada entre reinicios. Los contenedores construidos
sobre una imagen heredan la configuración de zona horaria mientras esté
explícitamente establecida en alguna de las capas.

En la tabla siguiente se muestra la compilación admitida para cada SKU:

ﾉ Expandir tabla
 SKU Versión admitida

Windows Server 2019 10.0.17763.1935 o superior

20H2 SAC 10.0.19042.985 o posterior

Windows Server 2022 Todas las versiones

Windows Server 2025 Todas las versiones

¿Cómo se configura la zona horaria del

contenedor?
En primer lugar, necesita tanto las versiones de host como las de invitado que
contienen esta característica, lo que significa que ambas se deben ejecutar en una
revisión de mantenimiento de 2105B o superior. La ejecución de versiones anteriores
simplemente revierte el comportamiento del contenedor a reflejar la zona horaria del
host, y la configuración no afecta ni al host ni al sistema invitado.

７ Nota

La configuración de la zona horaria requiere privilegios administrativos,

específicamente SeTimeZonePrivilege. La cuenta ContainerAdministrator tiene este
privilegio. Por lo tanto, la recomendación es ejecutar con los privilegios mínimos
necesarios para la carga de trabajo y reservar la cuenta ContainerAdministrator
para las tareas administrativas, como establecer la zona horaria.

La manera recomendada de configurar la zona horaria del contenedor es a través de

la utilidad TZUtil.exe o el cmdlet Set-TimeZone de PowerShell. Estas utilidades se
mantienen bien y ofrecen comodidad para establecer fácilmente la zona horaria.
Cualquier otro método debe interactuar directamente con las API del sistema. Las
versiones de imagen base con TZUtil.exe o PowerShell incluido funcionarán de forma
inmediata. La imagen base de Nanoserver es una excepción, ya que esta imagen no
admite TZUtil.exe ni PowerShell de forma predeterminada, por lo que requiere una
utilidad personalizada para interactuar con las API del sistema. En cualquier caso, las
aplicaciones recién escritas NO deben depender de la zona horaria del sistema
operativo a menos que sea absolutamente necesario y, en su lugar, deben tenerlo en
cuenta en los datos y la lógica de la aplicación.

Ejemplo de uso de Windows Server 2019

Con la imagen base de Windows Server 2019 Server Core , a continuación se muestra
un ejemplo para establecer una zona horaria virtualizada.

1. Después de iniciar el contenedor, establezca la zona horaria en la zona horaria del

host (en este ejemplo, es hora estándar del Pacífico), como se muestra a
continuación:

PowerShell

PS C:\> tzutil /g
Pacific Standard Time

2. Establezca la zona horaria del host de en Hora estándar de Asia Central (UTC+6:00)
y observe que la hora estándar del Pacífico sigue apareciendo en el contenedor:

PowerShell

PS C:\> Get-TimeZone

Output

Id : Pacific Standard Time

DisplayName : (UTC-08:00) Pacific Time (US & Canada)
StandardName : Pacific Standard Time
DaylightName : Pacific Daylight Time
BaseUtcOffset : -08:00:00
SupportsDaylightSavingTime : True

Tenga en cuenta que, al iniciar el contenedor por primera vez, la configuración se

establece en lo que se configuró al crear la imagen base hasta configurarlo usted
mismo. En la mayoría de los casos para las imágenes base de Windows, el valor
predeterminado será Hora estándar del Pacífico.

3. A continuación, establezca la zona horaria del contenedor en "Hora estándar de

Samoa":

PowerShell

PS C:\> tzutil /s "Samoa Standard Time"

PS C:\> tzutil /g
Samoa Standard Time
PS C:\> Get-TimeZone

Output
 Id : Samoa Standard Time
DisplayName : (UTC+13:00) Samoa
StandardName : Samoa Standard Time
DaylightName : Samoa Daylight Time
BaseUtcOffset : 13:00:00
SupportsDaylightSavingTime : True

Ahora la zona horaria del contenedor se ha actualizado a la hora estándar de

Samoa, pero el host permanece en la hora estándar de Asia Central. Esta
configuración persiste al guardar el estado del contenedor.

4. Si reinicia el contenedor sin guardar previamente su estado, la zona horaria se

establece en la zona horaria del host, como se muestra a continuación:

PowerShell

PS C:\>tzutil /g
Central Asia Standard Time
PS C:\> Get-TimeZone

Output

Id : Central Asia Standard Time

DisplayName : (UTC+06:00) Astana
StandardName : Central Asia Standard Time
DaylightName : Central Asia Daylight Time
BaseUtcOffset : 06:00:00
SupportsDaylightSavingTime : False

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Información general sobre la
orquestación de contenedores de
Windows
Artículo • 05/02/2025

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

Debido a su tamaño pequeño y orientación a la aplicación, los contenedores son

perfectos para entornos de entrega ágiles y arquitecturas basadas en microservicios. Sin
embargo, un entorno que usa contenedores y microservicios puede tener cientos o
miles de componentes para realizar un seguimiento. Es posible que pueda administrar
manualmente unas docenas de máquinas virtuales o servidores físicos, pero no hay
ninguna manera de administrar correctamente un entorno de contenedor a escala de
producción sin automatización. Esta tarea debe caer en el orquestador, que es un
proceso que automatiza y administra un gran número de contenedores y cómo
interactúan entre sí.

Los orquestadores realizan las siguientes tareas:

Programación: al recibir una imagen de contenedor y una solicitud de recurso, el

orquestador busca una máquina adecuada para ejecutar el contenedor.
Afinidad/Antiafinidad: especifique si un conjunto de contenedores debe ejecutarse
cerca unos de otros para el rendimiento o lejos unos de otros para la
disponibilidad.
Seguimiento de estado: observe si hay errores de contenedor y vuelva a
programarlos automáticamente.
Conmutación por error: realice el seguimiento de lo que se ejecuta en cada
máquina y vuelva a programar contenedores de máquinas con error en nodos
correctos.
Escalado: agregar o quitar instancias de contenedor según la demanda, de forma
manual o automática.
Redes: proporcione una red superpuesta que coordina los contenedores para
comunicarse entre varias máquinas host.
Detección de servicios: habilite los contenedores para localizarse entre sí
automáticamente incluso cuando se mueven entre las máquinas host y cambian
las direcciones IP.
 Actualizaciones coordinadas de aplicaciones: administre las actualizaciones de
contenedores para evitar el tiempo de inactividad de la aplicación y habilitar la
reversión si algo va mal.

Tipos de orquestador
Azure ofrece los siguientes orquestadores de contenedor:

azure Kubernetes Service (AKS) facilita la creación, configuración y administración de un

clúster de máquinas virtuales preconfiguradas para ejecutar aplicaciones en contenedor.
Esto le permite usar sus aptitudes existentes y aprovechar un gran y creciente cuerpo de
conocimientos de la comunidad para implementar y administrar aplicaciones basadas
en contenedores en Microsoft Azure. Mediante AKS, puede aprovechar las
características de nivel empresarial de Azure, a la vez que mantiene la portabilidad de la
aplicación a través de Kubernetes y el formato de imagen de Docker.

AKS en Azure Stack HCI es una implementación local del conocido orquestador de AKS,
que automatiza la ejecución de aplicaciones en contenedores a escala. Azure
Kubernetes Service está disponible con carácter general en Azure Stack HCI y en
Windows Server 2019 Datacenter, lo que hace que sea más rápido empezar a hospedar
contenedores de Linux y Windows en el centro de datos.

Azure Service Fabric es una plataforma de sistemas distribuidos que facilita la

empaquetación, implementación y administración de microservicios y contenedores
escalables y confiables. Service Fabric aborda los desafíos importantes en el desarrollo y
la administración de aplicaciones nativas en la nube. Los desarrolladores y
administradores pueden evitar problemas complejos de infraestructura y centrarse en la
implementación de cargas de trabajo críticas y exigentes que son escalables, confiables
y administrables. Service Fabric representa la plataforma de próxima generación para
compilar y administrar estas aplicaciones de clase empresarial, de nivel 1 y de escala en
la nube que se ejecutan en contenedores.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Docker Engine en Windows
Artículo • 23/01/2025

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

El cliente y el motor de Docker no se incluyen con Windows y deberán instalarse y

configurarse por separado. Además, el motor de Docker puede aceptar varias
configuraciones personalizadas. Algunos ejemplos incluyen la configuración de cómo
acepta el demonio las solicitudes entrantes, las opciones de red predeterminadas y la
configuración de registro y depuración. En Windows, estas configuraciones pueden
especificarse en un archivo de configuración o mediante el Administrador de control de
servicios de Windows. En este documento se detalla cómo instalar y configurar el motor
de Docker. Además, se proporcionan algunos ejemplos de configuraciones frecuentes.

Instalar Docker
Se necesita Docker para trabajar con contenedores de Windows. Docker está formado
por el motor de Docker (dockerd.exe) y el cliente de Docker (docker.exe). La forma más
fácil de instalar todo se encuentra en la guía de inicio rápido, que te ayudará a preparar
todo el equipo y ejecutar el primer contenedor.

Instalación de Docker

Para instalaciones con script, consulta Uso de un script para instalar Docker EE .

Antes de poder usar Docker, deberás instalar las imágenes de contenedor. Para obtener
más información, consulta los documentos para nuestras imágenes base de contenedor.

Configuración de Docker con un archivo de

configuración
El método preferido para configurar el motor de Docker en Windows es usar un archivo
de configuración. El archivo de configuración se encuentra en
'C:\ProgramData\Docker\config\daemon.json'. Puedes crear este archivo si aún no
existe.

７ Nota
 No todas las opciones de configuración de Docker disponibles se pueden aplicar a
Docker en Windows. En el ejemplo siguiente, se muestran las opciones de
configuración que se aplican. Para información sobre la configuración del motor de
Docker, consulta Archivo de configuración de demonio de Docker .

JSON

{
"authorization-plugins": [],
"dns": [],
"dns-opts": [],
"dns-search": [],
"exec-opts": [],
"storage-driver": "",
"storage-opts": [],
"labels": [],
"log-driver": "",
"mtu": 0,
"pidfile": "",
"data-root": "",
"cluster-store": "",
"cluster-advertise": "",
"debug": true,
"hosts": [],
"log-level": "",
"tlsverify": true,
"tlscacert": "",
"tlscert": "",
"tlskey": "",
"group": "",
"default-ulimits": {},
"bridge": "",
"fixed-cidr": "",
"raw-logs": false,
"registry-mirrors": [],
"insecure-registries": [],
"disable-legacy-registry": false
}

Solo necesitas agregar los cambios de configuración deseados al archivo de

configuración. Por ejemplo, en este ejemplo se configura el motor de Docker para que
acepte las conexiones entrantes a través del puerto 2375. Las demás opciones de
configuración usarán los valores predeterminados.

JSON

{
"hosts": ["tcp://0.0.0.0:2375"]
}
Del mismo modo, en este ejemplo se configura el demonio de Docker para mantener
las imágenes y los contenedores en una ruta alternativa. Si no se especifica, el valor
predeterminado es c:\programdata\docker .

JSON

{
"data-root": "d:\\docker"
}

En este ejemplo se configura el demonio de Docker para aceptar únicamente

conexiones seguras a través del puerto 2376.

JSON

{
"hosts": ["tcp://0.0.0.0:2376", "npipe://"],
"tlsverify": true,
"tlscacert": "C:\\ProgramData\\docker\\certs.d\\ca.pem",
"tlscert": "C:\\ProgramData\\docker\\certs.d\\server-cert.pem",
"tlskey": "C:\\ProgramData\\docker\\certs.d\\server-key.pem",
}

Configuración de Docker en Docker Service

El motor de Docker también se puede configurar modificando el servicio de Docker con
sc config . Con este método, se establecen marcas de motor de Docker directamente

en el servicio de Docker. Ejecute el siguiente comando en un símbolo del sistema

(cmd.exe, no PowerShell):

Símbolo del sistema de Windows

sc config docker binpath= "\"C:\Program Files\docker\dockerd.exe\" --run-

service -H tcp://0.0.0.0:2375"

７ Nota

No es necesario ejecutar este comando si el archivo daemon.json ya contiene la

entrada "hosts": ["tcp://0.0.0.0:2375"] .

Configuración común
Los siguientes ejemplos de archivos de configuración muestran configuraciones de
Docker comunes. Esta configuración se puede combinar en un único archivo de
configuración.

Creación de red predeterminada

Para configurar el motor de Docker para que no se cree una red NAT predeterminada,
usa lo siguiente.

JSON

{
"bridge" : "none"
}

Para obtener más información, vea Administrar redes de Docker.

Definición del grupo de seguridad de Docker

Si has iniciado sesión en el host de Docker y ejecutas comandos de Docker de forma
local, estos se ejecutan a través de una canalización con nombre. De forma
predeterminada, solo los miembros del grupo de administradores pueden tener acceso
al motor de Docker a través de la canalización con nombre. Para especificar un grupo de
seguridad que tiene este acceso, use la marca group .

JSON

{
"group" : "docker"
}

Configuración de proxy
Para establecer la información del proxy para docker search y docker pull , cree una
variable de entorno de Windows con el nombre HTTP_PROXY o HTTPS_PROXY y un valor de
información del proxy. Esto se puede completar con PowerShell mediante un comando
similar al siguiente:

PowerShell

[Environment]::SetEnvironmentVariable("HTTP_PROXY",
"http://username:password@proxy:port/",
 [EnvironmentVariableTarget]::Machine)

Una vez que se ha establecido la variable, reinicie el servicio Docker.

PowerShell

Restart-Service docker

Para más información, consulta Archivo de configuración de Windows en Docker.com .

Desinstalación de Docker
En esta sección te indicamos cómo desinstalar Docker y realizar una limpieza completa
de componentes del sistema Docker del sistema Windows 10 o Windows Server 2016.

７ Nota

Debes ejecutar todos los comandos incluidos en estas instrucciones desde una
sesión de PowerShell con privilegios elevados.

Preparación del sistema para quitar Docker

Antes de desinstalar Docker, asegúrate de que no haya contenedores en ejecución en el
sistema.

Ejecuta los siguientes cmdlets para comprobar los contenedores en ejecución:

PowerShell

# Leave swarm mode (this will automatically stop and remove services and
overlay networks)
docker swarm leave --force

# Stop all running containers

docker ps --quiet | ForEach-Object {docker stop $_}

También recomendamos eliminar todos los contenedores, imágenes de contenedor,

redes y volúmenes del sistema antes de eliminar Docker. Puedes realizarlo usando el
siguiente cmdlet:

PowerShell
 docker system prune --volumes --all

Desinstalar Docker
A continuación, deberás desinstalar realmente Docker.

Para desinstalar Docker en Windows 10

Ve a Configuración>Aplicaciones en la máquina Windows 10

En Aplicaciones y características, busca Docker para Windows
Ve a Docker para Windows>Desinstalar

Para desinstalar Docker en Windows Server 2016:

Desde una sesión con privilegios elevados de PowerShell, usa los cmdlets Uninstall-
Package y Uninstall-Module para eliminar el módulo Docker y su correspondiente
Proveedor de administración de paquetes de tu sistema, como se muestra en el ejemplo
siguiente:

PowerShell

Uninstall-Package -Name docker -ProviderName DockerMsftProvider

Uninstall-Module -Name DockerMsftProvider

 Sugerencia

Puedes encontrar el Proveedor de paquetes que usaste para instalar Docker con PS
C:\> Get-PackageProvider -Name *Docker*

Limpieza de componentes del sistema y datos de Docker

Después de desinstalar Docker, deberás quitar las redes predeterminadas de Docker
para que su configuración no permanezca en el sistema después de que hayas
eliminado Docker. Puedes realizarlo usando el siguiente cmdlet:

PowerShell

Get-HNSNetwork | Remove-HNSNetwork

Para quitar las redes predeterminadas de Docker en Windows Server 2016.

 PowerShell

Get-ContainerNetwork | Remove-ContainerNetwork

Ejecuta el cmdlet siguiente para quitar del sistema los datos del programa de Docker:

PowerShell

Remove-Item "C:\ProgramData\Docker" -Recurse

También puedes eliminar las características opcionales de Windows asociadas a Docker

o los contenedores en Windows.

Esto incluye la característica "Contenedores", que se habilita automáticamente en

Windows 10 o Windows Server 2016 cuando se instala Docker. También puede incluir la
característica "Hyper-V", que se habilita automáticamente en Windows 10 cuando
Docker está instalado, pero debe estar habilitado de forma explícita en Windows Server
2016.

） Importante

La característica Hyper-V es una característica de virtualización general que habilita

mucho más que solo contenedores. Antes de deshabilitar la característica Hyper-V,
asegúrate de que no hay otros componentes virtualizados en el sistema que la
necesiten.

Para quitar características de Windows en Windows 10:

Ve a Panel de control>Programas>Programas y características>Activar o

desactivar las características de Windows.
Busca el nombre de la características o características que te gustaría deshabilitar,
en este caso, Contenedores y (de forma opcional) Hyper-V.
Desactiva la casilla junto al nombre de la característica que quieres deshabilitar.
Selecciona "Aceptar" .

Para quitar las características de Windows en Windows Server 2016:

Desde una sesión con privilegios elevados de PowerShell, usa los siguientes cmdlets
para deshabilitar las características Contenedores y (de forma opcional) Hyper-V del
sistema:

PowerShell
 Remove-WindowsFeature Containers
Remove-WindowsFeature Hyper-V

Reinicio del sistema

Para finalizar la desinstalación y la limpieza, ejecuta el siguiente cmdlet desde una sesión
de PowerShell con privilegios elevados para reiniciar el sistema:

PowerShell

Restart-Computer -Force

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Administración remota de un host de
Docker de Windows
Artículo • 05/02/2025

Incluso en ausencia de docker-machine todavía se puede crear un host de Docker

accesible de forma remota en una máquina virtual windows Server.

Los pasos son:

Cree los certificados en el servidor mediante dockertls . Si va a crear los

certificados con una dirección IP, puede considerar una dirección IP estática para
evitar tener que volver a crear certificados cuando cambie la dirección IP.
Reinicie el servicio docker Restart-Service Docker
Haga que los puertos TLS de Docker 2375 y 2376 estén disponibles mediante la
creación de una regla de NSG que permita el tráfico entrante. Tenga en cuenta que
para las conexiones seguras solo es necesario permitir 2376. En el portal se debe
mostrar una configuración de NSG como esta:

Permitir conexiones entrantes a través del Firewall de Windows.

PowerShell

New-NetFirewallRule -DisplayName 'Docker SSL Inbound' -Profile @('Domain',

'Public', 'Private') -Direction Inbound -Action Allow -Protocol TCP -
LocalPort 2376

Copie los archivos ca.pem , "cert.pem" y "key.pem" de la carpeta docker del usuario
en la máquina, por ejemplo, c:\users\chris\.docker a la máquina local. Por
ejemplo, se pueden copiar y pegar (Ctrl+C, Ctrl+V) los archivos de una sesión RDP.
Confirme que puede conectarse al host remoto de Docker. Ejecute:

PowerShell

docker -D -H tcp://wsdockerhost.southcentralus.cloudapp.azure.com:2376 --
tlsverify --tlscacert=c:\
users\foo\.docker\client\ca.pem --
 tlscert=c:\users\foo\.docker\client\cert.pem --tlskey=c:\users\foo\.doc
ker\client\key.pem ps

Solución de problemas

Pruebe a conectarse sin TLS para determinar que la

configuración del firewall de NSG es correcta.
Los errores de conectividad normalmente se manifiestan en errores como:

PowerShell

error during connect: Get

https://wsdockerhost.southcentralus.cloudapp.azure.com:2376/v1.25/version:
dial tcp 13.85.27.177:2376: connectex: A connection attempt failed because
the connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to respond.

Permitir conexiones sin cifrar, agregando

PowerShell

{
"tlsverify": false,
}

para c"\programdata\docker\config\daemon.json y, después, reinicie el servicio.

Conéctese al host remoto con una línea de comandos como:

PowerShell

docker -H tcp://wsdockerhost.southcentralus.cloudapp.azure.com:2376 --
tlsverify=0 version

Problemas de certificados
El acceso al host de Docker con un certificado no creado para la dirección IP o el
nombre DNS producirá un error:

Output
 error during connect: Get https://w.x.y.c.z:2376/v1.25/containers/json:
x509: certificate is valid for 127.0.0.1, a.b.c.d, not w.x.y.z

Asegúrese de que w.x.y.z sea el nombre DNS de la dirección IP pública del host y de que
el nombre DNS coincida exactamente con el nombre común del certificado , que era
la variable de entorno SERVER_NAME o una de las direcciones IP en la variable
IP_ADDRESSES proporcionada a dockertls.

advertencia crypto/x509
Es posible que reciba una advertencia.

Output

level=warning msg="Unable to use system certificate pool: crypto/x509:

system root pool is not available on Windows"

La advertencia es benigna.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Kubernetes en Windows
Artículo • 05/02/2025

 Sugerencia

¿Tiene curiosidad por averiguar qué características de Kubernetes se admiten

actualmente en Windows? Vea Características admitidas oficialmente para más
información.

Esta página sirve de información general para empezar a trabajar con Kubernetes en
Windows.

Prueba de Kubernetes en Windows

Consulte implementación de Kubernetes en Windows para obtener instrucciones sobre
cómo instalar Kubernetes manualmente en Windows en el entorno que prefiera.

Programación de contenedores de Windows

Consulte mejores prácticas para la programación de contenedores de Windows en
Kubernetes para recomendaciones sobre la programación de contenedores de
Windows en Kubernetes.

Implementación de Kubernetes en Windows en Azure

La guía Contenedores de Windows en Azure Kubernetes Service facilita esta tarea. Si
quiere implementar y administrar todos los componentes de Kubernetes usted mismo,
consulte nuestro tutorial paso a paso mediante la herramienta de AKS-Engine de
código abierto.

Solución de problemas
Consulte Solución de problemas de Kubernetes para obtener una lista sugerida de
soluciones y soluciones a problemas conocidos.

 Sugerencia
 Para obtener más recursos de autoayuda, también hay una entrada de blog Guía
de solución de problemas de redes de Kubernetes .

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Solución de problemas de Kubernetes
Artículo • 23/01/2025

En esta página se describen varios problemas comunes con la configuración, las redes y
las implementaciones de Kubernetes.

 Sugerencia

Sugerir un elemento de preguntas más frecuentes mediante la generación de una

solicitud de incorporación de cambios al repositorio de documentación.

Esta página se subdivide en las siguientes categorías:

1. Preguntas generales
2. Errores comunes de red
3. Errores comunes de Windows
4. Errores de maestro comunes de Kubernetes

Preguntas generales

Cómo saber que Kubernetes en Windows se completó

correctamente?
Debería ver kubelet, kube-proxy y (si eligió Flannel como solución de red) procesos
flanneld host-agent que se ejecutan en el nodo. Además de esto, el nodo de Windows
debe aparecer como "Listo" en el clúster de Kubernetes.

¿Puedo configurar para ejecutar todo esto en segundo

plano?
A partir de la versión 1.11 de Kubernetes, kubelet y kube-proxy se pueden ejecutar
como servicios nativos de Windows. También puede usar siempre administradores de
servicios alternativos como nssm.exe para ejecutar siempre estos procesos (flanneld,
kubelet y kube-proxy) en segundo plano.

Errores comunes de red

Los equilibradores de carga se agrupan de forma
incoherente entre los nodos del clúster
En Windows, kube-proxy crea un equilibrador de carga de HNS para cada servicio de
Kubernetes del clúster. En la configuración de kube-proxy (valor predeterminado), los
nodos de clústeres que contienen muchos equilibradores de carga (normalmente 100+)
pueden agotarse de puertos TCP efímeros disponibles (a.k.a. intervalo de puertos
dinámicos, que de forma predeterminada cubre los puertos 49152 a 65535). Esto se
debe al gran número de puertos reservados en cada nodo para cada equilibrador de
carga (no DSR). Este problema puede manifestarse a través de errores en kube-proxy,
como:

Output

Policy creation failed: hcnCreateLoadBalancer failed in Win32: The specified

port already exists.

Los usuarios pueden identificar este problema ejecutando el script CollectLogs.ps1 y

consultando los *portrange.txt archivos.

También CollectLogs.ps1 imitará la lógica de asignación de HNS para probar la

disponibilidad de asignación del grupo de puertos en el intervalo de puertos TCP
efímero y notificar el éxito o el error en reservedports.txt . El script reserva 10 intervalos
de 64 puertos efímeros TCP (para emular el comportamiento de HNS), cuenta los éxitos
y errores de reserva y, a continuación, libera los intervalos de puertos asignados. Un
número de éxito menor que 10 indica que el grupo efímero se está quedando sin
espacio libre. También se generará un resumen heuristico del número de reservas de
puertos de 64 bloques aproximadamente disponibles en reservedports.txt .

Para resolver este problema, se pueden realizar algunos pasos:

1. Para una solución permanente, el equilibrio de carga kube-proxy debe

establecerse en modo DSR. El modo DSR está totalmente implementado y está
disponible solo en la compilación 18945 o superior de Windows Server Insider.
2. Como solución alternativa, los usuarios también pueden aumentar la configuración
predeterminada de Windows de puertos efímeros disponibles mediante un
comando como netsh int ipv4 set dynamicportrange TCP <start_port>
<port_count> . ADVERTENCIA: Invalidar el intervalo de puertos dinámicos

predeterminado puede tener consecuencias en otros procesos o servicios en el

host que dependen de los puertos TCP disponibles del intervalo no efímero, por lo
que este intervalo debe seleccionarse cuidadosamente.
 3. Hay una mejora de escalabilidad para equilibradores de carga que no son DSR
mediante el uso compartido inteligente del grupo de puertos incluido en la
actualización acumulativa KB4551853 (y todas las actualizaciones acumulativas
más recientes).

La publicación de HostPort no funciona

Para usar la característica HostPort, asegúrese de que los complementos de CNI son la
versión v0.8.6 o superior, y de que el archivo de configuración de CNI tiene las
portMappings funcionalidades establecidas:

Output

"capabilities": {
"portMappings": true
}

Veo errores como "hnsCall failed in Win32: The wrong

diskette is in the drive".
Este error se puede producir al realizar modificaciones personalizadas en objetos HNS o
instalar una nueva Actualización de Windows que introduce cambios en HNS sin anular
objetos HNS antiguos. Indica que un objeto HNS que se creó anteriormente antes de
que una actualización no sea compatible con la versión de HNS instalada actualmente.

En Windows Server 2019 (y versiones anteriores), los usuarios pueden eliminar objetos
HNS eliminando el archivo HNS.data.

Output

Stop-Service HNS
rm C:\ProgramData\Microsoft\Windows\HNS\HNS.data
Start-Service HNS

Los usuarios deben poder eliminar directamente los puntos de conexión o redes de
HNS incompatibles:

Output

hnsdiag list endpoints

hnsdiag delete endpoints <id>
hnsdiag list networks
 hnsdiag delete networks <id>
Restart-Service HNS

Los usuarios de Windows Server, versión 1903 pueden ir a la siguiente ubicación del
Registro y eliminar cualquier NIC que empiece por el nombre de red (por ejemplo
vxlan0 , o cbr0 ):

Output

\\Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parame
ters\NicList

Los contenedores en la implementación de host-gw de

Flannel en Azure no pueden acceder a Internet
Al implementar Flannel en modo host-gw en Azure, los paquetes deben pasar por el
vSwitch del host físico de Azure. Los usuarios deben programar rutas definidas por el
usuario de tipo "aplicación virtual" para cada subred asignada a un nodo. Esto se puede
hacer a través de Azure Portal (consulte un ejemplo aquí) o a través de az la CLI de
Azure. Este es un ejemplo de UDR con el nombre "MyRoute" mediante comandos az
para un nodo con IP 10.0.0.4 y la subred de pod correspondiente 10.244.0.0/24:

Output

az network route-table create --resource-group <my_resource_group> --name

BridgeRoute
az network route-table route create --resource-group <my_resource_group> --
address-prefix 10.244.0.0/24 --route-table-name BridgeRoute --name MyRoute
--next-hop-type VirtualAppliance --next-hop-ip-address 10.0.0.4

 Sugerencia

Si va a implementar Kubernetes en máquinas virtuales iaaS o de Azure desde otros

proveedores de nube, también puede usar overlay networking en su lugar.

Mis pods de Windows no pueden hacer ping a recursos

externos
Los pods de Windows no tienen reglas de salida programadas para el protocolo ICMP
hoy mismo. Sin embargo, se admite TCP/UDP. Al intentar demostrar la conectividad a
los recursos fuera del clúster, sustituya ping <IP> por los comandos correspondientes
curl <IP> .

Si sigue teniendo problemas, lo más probable es que la configuración de red en

cni.conf merezca cierta atención adicional. Siempre puede editar este archivo estático,
la configuración se aplicará a los recursos de Kubernetes recién creados.

¿Por qué? Uno de los requisitos de red de Kubernetes (consulte modelo de

Kubernetes) es para que la comunicación del clúster se produzca sin NAT internamente.
Para cumplir este requisito, tenemos un exceptionList para toda la comunicación en la
que no queremos que se produzca NAT de salida. Sin embargo, esto también significa
que debe excluir la dirección IP externa que está intentando consultar de ExceptionList.
Solo entonces el tráfico que se origina en los pods de Windows será SNAT
correctamente para recibir una respuesta del mundo exterior. En este sentido, la clase
ExceptionList en cni.conf debe tener el siguiente aspecto:

conf

"ExceptionList": [
"10.244.0.0/16", # Cluster subnet
"10.96.0.0/12", # Service subnet
"10.127.130.0/24" # Management (host) subnet
]

Mi nodo de Windows no puede acceder a un servicio

NodePort
Es posible que se produzca un error en el acceso Local NodePort desde el propio nodo.
Se trata de una brecha de características conocida que se aborda con la actualización
acumulativa KB4571748 (o posterior). El acceso a NodePort funcionará desde otros
nodos o clientes externos.

Mi nodo de Windows detiene el enrutamiento thourgh

NodePorts después de reducir verticalmente mis pods
Debido a una limitación de diseño, debe haber al menos un pod que se ejecute en el
nodo de Windows para que el reenvío de NodePort funcione.

Después de algún tiempo, se eliminan los puntos de

conexión de VNIC y HNS de los contenedores.
Este problema puede deberse a que el hostname-override parámetro no se pasa a kube-
proxy . Para resolverlo, los usuarios deben pasar el nombre de host a kube-proxy de la
siguiente manera:

Output

C:\k\kube-proxy.exe --hostname-override=$(hostname)

En el modo Flannel (vxlan), mis pods tienen problemas de

conectividad después de volver a unir el nodo
Cada vez que se vuelve a unir un nodo eliminado previamente al clúster, flannelD
intentará asignar una nueva subred de pod al nodo. Los usuarios deben quitar los
archivos de configuración de subred de pod antiguos en las siguientes rutas de acceso:

PowerShell

Remove-Item C:\k\SourceVip.json
Remove-Item C:\k\SourceVipRequest.json

Después de iniciar Kubernetes, Flanneld está bloqueado

en "Esperando a que se cree la red"
Este problema debe solucionarse con Flannel v0.12.0 (y versiones posteriores). Si usa
una versión anterior de Flanneld, hay una condición de carrera conocida que puede
ocurrir de modo que no se establezca la dirección IP de administración de la red flannel.
Una solución alternativa consiste simplemente en volver a iniciar FlannelD
manualmente.

Output

PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "

<Windows_Worker_Hostname>")
PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=
<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1

Mis pods de Windows no se pueden iniciar debido a que

falta /run/flannel/subnet.env
Esto indica que Flannel no se ha lanzado correctamente. Puede intentar reiniciar
flanneld.exe o puede copiar los archivos manualmente desde el maestro de
/run/flannel/subnet.env Kubernetes en C:\run\flannel\subnet.env en el nodo de

trabajo de Windows y modificar la FLANNEL_SUBNET fila a la subred asignada. Por

ejemplo, si se asignó la subred del nodo 10.244.4.1/24:

Output

FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.4.1/24
FLANNEL_MTU=1500
FLANNEL_IPMASQ=true

Con más frecuencia que no, hay otro problema que podría estar causando este error
que debe investigarse primero. Se recomienda que genere flanneld.exe este archivo
automáticamente.

La conectividad de pod a pod entre hosts se interrumpe

en el clúster de Kubernetes que se ejecuta en vSphere
Dado que vSphere y Flannel reservan el puerto 4789 (puerto VXLAN predeterminado)
para las redes de superposición, los paquetes pueden acabar interceptándose. Si
vSphere se usa para las redes de superposición, debe configurarse para usar un puerto
diferente para liberar hasta 4789.

Mis puntos de conexión o direcciones IP están filtrando

Existen 2 problemas conocidos actualmente que pueden hacer que los puntos de
conexión se filtren.

1. El primer problema conocido es un problema en la versión 1.11 de Kubernetes.

Evite usar Kubernetes versión 1.11.0 - 1.11.2.
2. El segundo problema conocido que puede hacer que los puntos de conexión se
filtren es un problema de simultaneidad en el almacenamiento de puntos de
conexión. Para recibir la corrección, debe usar Docker EE 18.09 o superior.

Mis pods no se pueden iniciar debido a errores de "red:

no se pudo asignar el intervalo".
Esto indica que el espacio de direcciones IP del nodo se usa. Para limpiar los puntos de
conexión filtrados, migre los recursos de los nodos afectados y ejecute los siguientes
comandos:
 Output

c:\k\stop.ps1
Get-HNSEndpoint | Remove-HNSEndpoint
Remove-Item -Recurse c:\var

Mi nodo de Windows no puede acceder a mis servicios

mediante la dirección IP del servicio
Se trata de una limitación conocida de la pila de redes actual en Windows. Sin embargo,
los pods de Windows pueden acceder a la dirección IP del servicio.

No se encuentra ningún adaptador de red al iniciar

Kubelet
La pila de redes de Windows necesita un adaptador virtual para que funcionen las redes
de Kubernetes. Si los siguientes comandos no devuelven ningún resultado (en un shell
de administración), se ha producido un error en la creación de red de HNS ( un requisito
previo necesario para que Kubelet funcione):

PowerShell

Get-HnsNetwork | ? Name -ieq "cbr0"

Get-HnsNetwork | ? Name -ieq "vxlan0"
Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"

A menudo vale la pena modificar el parámetro InterfaceName del script start.ps1, en los
casos en los que el adaptador de red del host no es "Ethernet". De lo contrario, consulte
la salida del start-kubelet.ps1 script para ver si hay errores durante la creación de la
red virtual.

Sigo viendo problemas. ¿Cuál debo hacer?

Puede haber restricciones adicionales en su red o en hosts que impidan determinados
tipos de comunicación entre nodos. Asegúrate de que:

ha configurado correctamente la topología de red elegida ( l2bridge o overlay )

se permite el tráfico que parece que procede de pods.
Se permite el tráfico HTTP, si va a implementar servicios web
No se quitan paquetes de distintos protocolos (ie ICMP frente a TCP/UDP)
  Sugerencia

Para obtener más recursos de autoayuda, también hay una guía de solución de
problemas de redes de Kubernetes para Windows disponible aquí .

Errores comunes de Windows

Mis pods de Kubernetes están bloqueados en

"ContainerCreating"
Este problema puede tener muchas causas, pero una de las más comunes es que la
imagen de pausa estaba mal configurada. Este es un síntoma de alto nivel del siguiente
problema.

Al implementar, los contenedores de Docker siguen

reiniciando
Compruebe que la imagen de pausa es compatible con la versión del sistema operativo.
Kubernetes supone que tanto el sistema operativo como los contenedores tienen
números de versión del sistema operativo coincidentes. Si usa una compilación
experimental de Windows, como una compilación de Insider, deberá ajustar las
imágenes en consecuencia. Consulte el repositorio de Docker de Microsoft para
obtener imágenes.

Errores de maestro comunes de Kubernetes

La depuración del maestro de Kubernetes se divide en tres categorías principales (en
orden de probabilidad):

Algo está mal con los contenedores del sistema de Kubernetes.

Algo está mal con la forma kubelet en que se está ejecutando.
Algo está mal con el sistema.

Ejecute kubectl get pods -n kube-system para ver los pods creados por Kubernetes;
esto puede proporcionar información sobre qué puntos concretos se bloquean o no se
inician correctamente. A continuación, ejecute docker ps -a para ver todos los
contenedores sin procesar que respaldan estos pods. Por último, ejecute docker logs
[ID] en los contenedores que se sospecha que están causando el problema para ver la

salida sin procesar de los procesos.

No se puede conectar al servidor de API en

https://[address]:[port]

Con más frecuencia que no, este error indica problemas de certificado. Asegúrese de
que ha generado correctamente el archivo de configuración, de que las direcciones IP
de él coinciden con la del host y de que la ha copiado en el directorio montado por el
servidor de API.

Buenos lugares para encontrar este archivo de configuración son:

~/kube/kubelet/

$HOME/.kube/config
/etc/kubernetes/admin.conf

De lo contrario, consulte el archivo de manifiesto del servidor de API para comprobar

los puntos de montaje.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Service Fabric y contenedores
Artículo • 15/10/2024

Introducción
Azure Service Fabric es una plataforma de sistemas distribuidos que facilita el
empaquetado, la implementación y la administración de microservicios y contenedores
escalables y confiables.

Service Fabric es el orquestador de contenedores de Microsoft que implementa

microservicios en un clúster de máquinas. Service Fabric se beneficia de las lecciones
aprendidas durante sus años de ejecución de servicios en Microsoft a gran escala.

Se pueden desarrollar microservicios de muchas maneras, desde usando los modelos de

programación de Service Fabric o ASP.NET Core hasta implementando cualquier código
que prefiera. O, si simplemente quiere implementar y administrar contenedores, Service
Fabric es también una buena opción.

De forma predeterminada Service Fabric permite implementar y activar estos servicios

como procesos. Los procesos proporcionan la activación más rápida y el uso de
densidad más alto de los recursos del clúster. Service Fabric puede implementar
también servicios en imágenes de contenedor. También puede mezclar servicios en
procesos y servicios en contenedores en la misma aplicación.

Para comenzar de inmediato y probar contenedores en Service Fabric, pruebe una guía
de inicio rápido, tutorial o ejemplo:

Inicio rápido: Implementación de una aplicación contenedora de Linux en Service Fabric

Inicio rápido: Implementación de una aplicación contenedora de Windows en Service
Fabric
Inclusión de una aplicación .NET existente en un contenedor
Ejemplos de contenedores de Service Fabric

¿Qué son los contenedores?

Los contenedores vienen a solucionar el problema de ejecutar aplicaciones de forma
fiable en distintos entornos de proceso proporcionando un entorno inmutable para que
la aplicación se ejecute en él. Los contenedores encapsulan una aplicación y todas sus
dependencias, como bibliotecas y archivos de configuración, en su propio "cuadro"
aislado que contiene todo lo necesario para ejecutar el software en el contenedor.
Siempre que se ejecuta el contenedor, la aplicación que está dentro de él dispone de
todo lo necesario para ejecutarse como, por ejemplo, las versiones adecuadas de sus
bibliotecas dependientes, todos los archivos de configuración y cualquier otra cosa que
necesite para ejecutarse.

Los contenedores se ejecutan directamente en el kernel y tienen una vista aislada del
sistema de archivos y de otros recursos. Una aplicación en un contenedor no tiene
relación con ninguna otra aplicación o proceso fuera de su contenedor. Cada aplicación
y su entorno en tiempo de ejecución, las dependencias y las bibliotecas del sistema se
ejecutan dentro de un contenedor con acceso completo y privado a su propia vista
aislada del sistema operativo. Además de proporcionar con facilidad todas las
dependencias que la aplicación necesita para ejecutarse en diferentes entornos de
proceso, la seguridad y el aislamiento de los recursos son ventajas importantes del uso
de contenedores con Service Fabric que, de lo contrario, ejecutaría los servicios en un
proceso.

En comparación con las máquinas virtuales, los contenedores ofrecen las siguientes
ventajas:

Pequeño: usan un único espacio de almacenamiento y actualizaciones y versiones

de capa para aumentar la eficacia.
Rápidos: no tienen que arrancar un sistema operativo entero, así que pueden
iniciarse con mayor rapidez, normalmente en unos segundos.
Portabilidad: se puede portar una imagen de aplicación en contenedor para que
se ejecute en la nube o localmente, en máquinas virtuales o directamente en
máquinas físicas.
Gobernanza de recursos: un contenedor puede limitar los recursos físicos que
puede consumir en el host.

Compatibilidad de los contenedores con

Service Fabric
Service Fabric admite la implementación de contenedores de Docker en Linux y de
contenedores de Windows Server en Windows Server 2016 y versiones posteriores,
además de el modo de aislamiento de Hyper-V.

Entornos de ejecución de contenedor compatibles con ServiceFabric:

Linux: Docker
Windows:
Windows Server 2022: Mirantis Container Runtime
Windows Server 2019/2016: DockerEE
Contenedores de Docker en Linux
Docker ofrece API para crear y administrar contenedores sobre contenedores de kernel
de Linux. Docker Hub proporciona un repositorio central para almacenar y recuperar
imágenes de contenedor. Para ver un tutorial basado en Linux, consulte Cree la primera
aplicación de contenedor de Service Fabric en Linux.

Contenedores de Windows Server

Windows Server 2016 y versiones posteriores proporcionan dos tipos distintos de
contenedores que difieren en el nivel de aislamiento que ofrecen. Los contenedores de
Windows Server y los de Docker se parecen en que tienen un aislamiento del sistema de
archivos y un espacio de nombres, pero comparten el kernel con el host en que se
ejecutan. En Linux, este aislamiento tradicionalmente lo han proporcionado los cgroups
y los espacios de nombres, y los contenedores de Windows Server se comportan de
forma parecida.

Los contenedores de Windows compatibles con Hyper-V proporcionan mayor seguridad

y aislamiento, ya que los contenedores no comparten el kernel del sistema operativo
entre ellos ni con el host. Con este mayor nivel de aislamiento de seguridad, los
contenedores habilitados para Hyper-V están diseñados para escenarios potencialmente
hostiles y multiinquilino. Para ver un tutorial basado en Windows, consulte Cree la
primera aplicación de contenedor de Service Fabric en Windows.

La ilustración siguiente muestra los diferentes tipos de niveles de aislamiento y

virtualización disponibles.
Escenarios de uso de contenedores
Ejemplos típicos de buena elección de contenedor:

Migración mediante lift-and-shift de IIS: puede colocar una aplicación existente

de ASP.NET MVC en un contenedor en lugar de migrarla a ASP.NET Core. Estas
aplicaciones de ASP.NET MVC dependen de Internet Information Services (IIS).
Puede empaquetarlas en imágenes de contenedor a partir de la imagen de IIS
creada previamente e implementarlas con Service Fabric. Consulte Imágenes de
contenedores en Windows Server para obtener información sobre los
contenedores de Windows.

Mezcla de los contenedores y los microservicios de Service Fabric: Use una

imagen de contenedor existente para parte de la aplicación. Por ejemplo, podría
usar el contenedor NGINX para el front-end web de su aplicación y los servicios
con estado para la computación de back-end más intensa.

Reducción del impacto de los servicios de "vecinos ruidosos" : puede usar la

capacidad de gobernanza de recursos de los contenedores para restringir los
recursos que utiliza un servicio en un host. Si hay servicios que consuman un gran
número de recursos y afecten al rendimiento de otros (por ejemplo, una consulta
de larga ejecución como operación), considere la posibilidad de poner estos
servicios en contenedores con gobernanza de recursos.
 ７ Nota

Un clúster de Service Fabric es un único inquilino por diseño y las aplicaciones

hospedadas se consideran de confianza. Si está pensando en hospedar
aplicaciones que no son de confianza, consulte Hospedaje de aplicaciones que no
son de confianza en un clúster de Service Fabric.

Service Fabric proporciona un modelo de aplicaciónen el que un contenedor representa

un host de la aplicación en el que se colocan varias réplicas de servicio. Service Fabric
admite también un escenario de archivo ejecutable invitado en el que el usuario no usa
los modelos de programación de Service Fabric integrados y, en su lugar, empaqueta
una aplicación existente, escrita con cualquier lenguaje o plataforma, dentro de un
contenedor. Este escenario es el caso habitual de los contenedores.

También puede ejecutar servicios de Service Fabric dentro de un contenedor. La

compatibilidad con la ejecución de servicios de Service Fabric dentro de contenedores
está limitada actualmente.

Service Fabric ofrece varias funcionalidades de contenedor que le ayudarán a crear

aplicaciones que se componen de microservicios en contenedores, como:

Activación e implementación de la imagen de contenedor.

Gobernanza de recursos, incluida la configuración de valores de recursos
predeterminados en clústeres de Azure.
La autenticación de repositorios.
La asignación de puerto a host de contenedor.
La detección y comunicación entre contenedores.
La capacidad de configurar y establecer variables de entorno.
La capacidad de configurar credenciales de seguridad en el contenedor.
Selección de diferentes modos de red para contenedores.

Para obtener una introducción completa sobre la compatibilidad de contenedores en

Azure para, por ejemplo, crear un clúster de Kubernetes con Azure Kubernetes Service,
crear un registro privado de Docker en Azure Container Registry, etc, consulte Azure for
Containers.

Pasos siguientes
En este artículo, ha aprendido sobre la compatibilidad que ofrece Service Fabric para la
ejecución de contenedores. A continuación, analizaremos algunos ejemplos de cada una
de las características para mostrarle cómo utilizarlas.
Cree la primera aplicación de contenedor de Service Fabric en Linux
Cree la primera aplicación de contenedor en Service Fabric en Windows
Más información acerca de los contenedores de Windows

Comentarios
¿Le ha resultado útil esta página?  Sí  No

Proporcionar comentarios sobre el producto | Obtener ayuda en Microsoft Q&A

Regulación de recursos
Artículo • 15/10/2024

Cuando ejecuta varios servicios en el mismo clúster o nodo, es posible que un servicio
pueda consumir más recursos y privar así a otros servicios en el proceso. A este
problema se le conoce como el problema del entorno ruidoso. Azure Service Fabric
permite al desarrollador controlar este comportamiento al especificar las solicitudes y
los límites por servicio a fin de limitar el uso de recursos.

Antes de continuar con este artículo, le recomendamos que se familiarice con el

modelo de aplicación de Service Fabric y con el modelo de hospedaje de Service
Fabric.

Métricas de gobernanza de recursos

Service Fabric admite la gobernanza de recursos de acuerdo con el paquete de servicio.
Los recursos asignados al paquete de servicio pueden dividirse además entre paquetes
de código. Service Fabric admite la gobernanza de la memoria y la CPU por cada
paquete de servicio, con dos métricas integradas:

CPU (nombre de la métrica servicefabric:/_CpuCores ): un núcleo lógico que está

disponible en la máquina host. Todos los núcleos de los nodos se ponderan igual.

Memoria (nombre de métrica servicefabric:/_MemoryInMB ): la memoria se expresa

en megabytes y se asigna a la memoria física que está disponible en la máquina.

Para estas dos métricas, Cluster Resource Manager (CRM) realiza un seguimiento de la
capacidad total del clúster, la carga de cada nodo del clúster y los recursos restantes del
clúster. Estas dos métricas son equivalentes a cualquier otra métrica personalizada o de
usuario.

７ Nota

Los nombres de métricas personalizados no deben ser uno de estos dos nombres
de métrica, ya que provocará un comportamiento indefinido.

Todas las características existentes pueden utilizarse con ellas:

El clúster puede equilibrarse en función de estas dos métricas (comportamiento

predeterminado).
El clúster puede desfragmentarse en función de estas dos métricas.
 Para describir un clúster, se puede establecer la capacidad de almacenamiento en
búfer para estas dos métricas.

７ Nota

El informe de carga dinámica no es compatible con estas métricas, y las cargas

para estas métricas se definen en el momento de la creación.

Mecanismo de gobernanza de recursos

A partir de la versión 7.2, el entorno de ejecución de Service Fabric admite la
especificación de solicitudes y límites de recursos de CPU y memoria.

７ Nota

Las versiones del entorno de ejecución de Service Fabric anteriores a 7.2 solo
admiten un modelo en el que un único valor actúa como la solicitud y el límite de
un recurso determinado (CPU o memoria). Esto se describe como la especificación
RequestsOnly en este documento.

Solicitudes: los valores de solicitud de la CPU y la memoria representan las cargas

que utiliza Cluster Resource Manager (CRM) para las métricas
servicefabric:/_CpuCores y servicefabric:/_MemoryInMB . En otras palabras, CRM

considera que el consumo de recursos de un servicio es igual a sus valores de

solicitud y usa estos valores al tomar decisiones de selección de ubicación.

Límites: los valores de límite de memoria y CPU representan los límites de recursos
reales que se aplican cuando se activa un proceso o un contenedor en un nodo.

Service Fabric permite tanto las especificaciones RequestsOnly y LimitsOnly como

ambas (RequestsAndLimits) para la CPU y la memoria.

Cuando se usa la especificación RequestsOnly, Service Fabric también usa los

valores de solicitud como límites.
Cuando se usa la especificación LimitsOnly, Service Fabric considera que los
valores de solicitud son 0.
Cuando se usa la especificación RequestsAndLimits, los valores de límite deben ser
mayores o iguales que los valores de solicitud.

Para comprender mejor el mecanismo de gobernanza de recursos, echemos un vistazo a

un escenario de selección de ubicación de ejemplo con la especificación RequestsOnly
para el recurso de CPU (el mecanismo para la gobernanza de memoria es equivalente).
Considere un nodo con dos núcleos de CPU y dos paquetes de servicio que se
colocarán en él. El primer paquete de servicio que se va a colocar se compone de un
solo paquete de código de contenedor y solo especifica una solicitud de un núcleo de
CPU. El segundo paquete de servicio que se va a colocar se compone de un solo
paquete de código basado en proceso y también especifica una solicitud de un núcleo
de CPU. Puesto que ambos paquetes de servicio tienen una especificación
RequestsOnly, sus valores límite se establecen en sus valores de solicitud.

1. En primer lugar, el paquete de servicio basado en contenedor que solicita un

núcleo de CPU se coloca en el nodo. El entorno de ejecución activa el contenedor
y establece el límite de CPU en un núcleo. El contenedor no podrá usar más de un
núcleo.

2. A continuación, el paquete de servicio basado en proceso que solicita un núcleo

de CPU se coloca en el nodo. El entorno de ejecución activa el proceso de servicio
y establece su límite de CPU en un núcleo.

En este momento, la suma de las solicitudes es igual a la capacidad del nodo. CRM no
colocará más contenedores ni procesos de servicio con solicitudes de CPU en este nodo.
En el nodo, un proceso y un contenedor se ejecutan con un núcleo cada uno y no
compiten entre sí para la CPU.

Vamos a consultar de nuevo nuestro ejemplo con la especificación RequestsAndLimits.

Esta vez, el paquete de servicio basado en contenedor especifica una solicitud de un
núcleo de CPU y un límite de dos núcleos de CPU. El paquete de servicio basado en
proceso especifica una solicitud y un límite de un núcleo de CPU.

1. En primer lugar, el paquete de servicio basado en contenedor se coloca en el

nodo. El entorno de ejecución activa el contenedor y establece el límite de CPU en
dos núcleos. El contenedor no podrá usar más de dos núcleos.
2. A continuación, el paquete de servicio basado en proceso se coloca en el nodo. El
entorno de ejecución activa el proceso de servicio y establece su límite de CPU en
un núcleo.

En este momento, la suma de las solicitudes de CPU de los paquetes de servicio que se
colocan en el nodo es igual a la capacidad de CPU del nodo. CRM no colocará más
contenedores ni procesos de servicio con solicitudes de CPU en este nodo. Sin embargo,
en el nodo, la suma de los límites (dos núcleos para el contenedor y un núcleo para el
proceso) supera la capacidad de dos núcleos. Si el contenedor y el proceso se expanden
al mismo tiempo, existe la posibilidad de realizar una contención del recurso de la CPU.
El sistema operativo subyacente de la plataforma administra ese tipo de contención. En
este ejemplo, el contenedor podría expandirse en un total de dos núcleos de CPU, por
lo que la solicitud del proceso de un núcleo de CPU no se garantiza.

７ Nota

Como se muestra en el ejemplo anterior, los valores de solicitud de CPU y memoria

no dan lugar a la reserva de recursos en un nodo. Estos valores representan el
consumo de recursos que Cluster Resource Manager tiene en cuenta al tomar
decisiones de selección de ubicación. Los valores de límite representan los límites
de los recursos reales que se aplican cuando se activa un proceso o un contenedor
en un nodo.

Existen algunas situaciones en las que puede haber contención de la CPU. En estas
situaciones, el proceso y el contenedor del ejemplo pueden experimentar el problema
del entorno ruidoso:

Combinación de servicios con gobierno y sin gobierno y contenedores: si el usuario

crea un servicio sin especificar una gobernanza de recursos, el entorno de tiempo
de ejecución considera que no estaba consumiendo ningún recurso y puede
colocarlo en el nodo de nuestro ejemplo. En este caso, este nuevo proceso
consume eficazmente algún recurso de CPU a costa de los servicios que se
ejecutan en el nodo. Hay dos soluciones para este problema. Una solución consiste
en no combinar servicios con gobierno y sin gobierno en el mismo clúster, y la otra
en usar restricciones de posición para que estos dos tipos de servicio no finalicen
en el mismo conjunto de nodos.

Cuando se inicia otro proceso en el nodo, fuera de Service Fabric (por ejemplo, un
servicio de sistema operativo) : En esta situación, el proceso fuera de Service Fabric
también competirá por la CPU con los servicios existentes. La solución a este
problema consiste en configurar correctamente las capacidades del nodo en la
cuenta para la sobrecarga del sistema operativo, tal como se muestra en la sección
siguiente.

Cuando las solicitudes no son iguales a los límites: Tal y como se describe en el
ejemplo de RequestsAndLimits anterior, las solicitudes no dan lugar a la reserva de
recursos en un nodo. Cuando se coloca un servicio con límites superiores a las
solicitudes en un nodo, es posible que este consuma recursos (si están disponibles)
hasta sus límites. En tales casos, es posible que otros servicios del nodo no puedan
consumir recursos hasta sus valores de solicitud.
Configuración del clúster para habilitar la
gobernanza de recursos
Cuando el nodo se inicia y se une al clúster, Service Fabric detecta la cantidad de
memoria disponible y el número de núcleos disponibles, y establece las capacidades del
nodo para esos dos recursos.

Para dejar algún espacio en búfer al sistema operativo y para otros procesos que
puedan ejecutarse en el nodo, Service Fabric solo utiliza el 80 % de los recursos
disponibles en el nodo. Este porcentaje es configurable y puede cambiarse en el
manifiesto de clúster.

Este es un ejemplo que indica a Service Fabric cómo usar el 50 % de la CPU disponible y
el 70 % de memoria disponible:

XML

<Section Name="PlacementAndLoadBalancing">
<!-- 0.0 means 0%, and 1.0 means 100%-->
<Parameter Name="CpuPercentageNodeCapacity" Value="0.5" />
<Parameter Name="MemoryPercentageNodeCapacity" Value="0.7" />
</Section>

Para la mayoría de los clientes y escenarios, la detección automática de las capacidades

del nodo para la CPU y la memoria es la configuración recomendada (la detección
automática está activada de forma predeterminada). No obstante, si necesita realizar
una configuración manual completa de las capacidades del nodo, puede hacerlo por
tipo de nodo mediante el mecanismo para describir los nodos del clúster. Este es un
ejemplo de cómo configurar el tipo de nodo con cuatro núcleos y 2 GB de memoria:

XML

<NodeType Name="MyNodeType">
<Capacities>
<Capacity Name="servicefabric:/_CpuCores" Value="4"/>
<Capacity Name="servicefabric:/_MemoryInMB" Value="2048"/>
</Capacities>
</NodeType>

Cuando está habilitada la detección automática de los recursos disponibles y las

capacidades de nodo se han definido manualmente en el manifiesto de clúster, Service
Fabric comprueba si el nodo tiene suficientes recursos para admitir la capacidad que ha
definido el usuario:
 Si las capacidades de nodo que se definen en el manifiesto son menores o iguales
que los recursos disponibles en el nodo, Service Fabric usa las capacidades que se
especifican en el manifiesto.

Si las capacidades de nodo que se definen en el manifiesto son mayores que los
recursos disponibles, Service Fabric usa los recursos disponibles como capacidades
de nodo.

Puede desactivar la detección automática de los recursos disponibles si no es necesario.

Para desactivar esta función, cambie la configuración siguiente:

XML

<Section Name="PlacementAndLoadBalancing">
<Parameter Name="AutoDetectAvailableResources" Value="false" />
</Section>

Para obtener un rendimiento óptimo, también es necesario activar la siguiente

configuración en el manifiesto de clúster:

XML

<Section Name="PlacementAndLoadBalancing">
<Parameter Name="PreventTransientOvercommit" Value="true" />
<Parameter Name="AllowConstraintCheckFixesDuringApplicationUpgrade"
Value="true" />
</Section>

） Importante

A partir de la versión 7.0 de Service Fabric, actualizamos la regla de cómo se

calculan las capacidades de los recursos de nodo en casos donde el usuario
proporciona manualmente los valores de las capacidades de los recursos de nodo.
Consideremos el escenario siguiente:

Hay un total de 10 núcleos de CPU en el nodo.

SF está configurado para usar el 80 % del total de los recursos para los
servicios de usuario (configuración predeterminada), que deja un búfer del
20 % para los demás servicios que se ejecutan en el nodo (incluidos los
servicios del sistema de Service Fabric).
El usuario decide invalidar manualmente la capacidad del recurso del nodo
correspondiente a la métrica de núcleos de la CPU y la establece en 5 núcleos.
 Modificamos la regla sobre cómo se calcula la capacidad disponible para los
servicios de usuario de Service Fabric de la manera siguiente:

Antes de Service Fabric 7.0, la capacidad disponible de los servicios de usuario

se calcularía en 5 núcleos (se omite el búfer de capacidad del 20 %).
A partir de Service Fabric 7.0, la capacidad disponible de los servicios de
usuario se calcularía en 4 núcleos (no se omite el búfer de capacidad del
20 %).

Especificación de la gobernanza de recursos

Los límites y las solicitudes de la gobernanza de recursos se especifican en el manifiesto
de aplicación (sección ServiceManifestImport). Veamos algunos ejemplos:

Ejemplo 1: Especificación de RequestsOnly

XML

<?xml version='1.0' encoding='UTF-8'?>

<ApplicationManifest ApplicationTypeName='TestAppTC1'
ApplicationTypeVersion='vTC1'
xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric
ServiceFabricServiceModel.xsd'
xmlns='http://schemas.microsoft.com/2011/01/fabric'
xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName='ServicePackageA'
ServiceManifestVersion='v1'/>
<Policies>
<ServicePackageResourceGovernancePolicy CpuCores="1"/>
<ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512"
MemoryInMB="1024" />
<ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256"
MemoryInMB="1024" />
</Policies>
</ServiceManifestImport>

En este ejemplo, el atributo CpuCores se usa para especificar una solicitud de un núcleo
de CPU para ServicePackageA. Dado que no se especifica el límite de CPU (atributo
CpuCoresLimit ), Service Fabric también utiliza el valor de solicitud especificado de un

núcleo como límite de CPU del paquete de servicio.

ServicePackageA solo se colocará en un nodo en el que la capacidad restante de la CPU

sea mayor o igual que un núcleo después de restar la suma de las solicitudes de CPU
de todos los paquetes de servicio colocados en ese nodo. En el nodo, el paquete de
servicio se limitará a un núcleo. El paquete de servicio contiene dos paquetes de código
(CodeA1 y CodeA2), y ambos especifican el atributo CpuShares . La proporción de
CpuShares 512:256 se usa para calcular los límites de CPU para los paquetes de código
individuales. Por lo tanto, CodeA1 se limitará a dos tercios de un núcleo y CodeA2 se
limitará a un tercio de un núcleo. Si no se especifican las proporciones de CpuShares de
todos los paquetes de código, Service Fabric dividirá el límite de la CPU equitativamente
entre ellos.

Aunque las proporciones de CpuShares especificadas para los paquetes de código

representan su proporción relativa del límite total de CPU del paquete de servicio, los
valores de memoria de los paquetes de código se especifican en términos absolutos. En
este ejemplo, el atributo MemoryInMB se usa para especificar solicitudes de memoria de
1024 MB para CodeA1 y CodeA2. Dado que no se especifica el límite de memoria
(atributo MemoryInMBLimit ), Service Fabric también utiliza los valores de solicitud
especificados como límites para los paquetes de código. La solicitud de memoria (y el
límite) del paquete de servicio se calcula como la suma de los valores de solicitud de
memoria (y límite) de sus paquetes de código constituyentes. Por lo tanto, para
ServicePackageA, la solicitud de memoria y el límite se calculan como 2048 MB.

ServicePackageA solo se colocará en un nodo en el que la capacidad de memoria

restante sea mayor o igual que 2048 MB después de restar la suma de las solicitudes de
memoria de todos los paquetes de servicio colocados en ese nodo. En el nodo, ambos
paquetes de código se limitarán a 1024 MB de memoria cada uno. Los paquetes de
código (contenedores o procesos) no podrán asignar más memoria de la que establece
este límite y, si se intenta, el resultado serán excepciones de memoria insuficiente.

Ejemplo 2: Especificación RequestsOnly

XML

<?xml version='1.0' encoding='UTF-8'?>

<ApplicationManifest ApplicationTypeName='TestAppTC1'
ApplicationTypeVersion='vTC1'
xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric
ServiceFabricServiceModel.xsd'
xmlns='http://schemas.microsoft.com/2011/01/fabric'
xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName='ServicePackageA'
ServiceManifestVersion='v1'/>
<Policies>
<ServicePackageResourceGovernancePolicy CpuCoresLimit="1"/>
<ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512"
MemoryInMBLimit="1024" />
<ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256"
MemoryInMBLimit="1024" />
 </Policies>
</ServiceManifestImport>

En este ejemplo se utilizan los atributos CpuCoresLimit y MemoryInMBLimit , que solo

están disponibles en las versiones de SF 7.2 y posteriores. El atributo CpuCoresLimit se
usa para especificar un límite de CPU de 1 núcleo para ServicePackageA. Puesto que no
se especifica la solicitud de CPU (atributo CpuCores ), se considera que su valor es 0. El
atributo MemoryInMBLimit se usa para especificar los límites de memoria de 1024 MB
para CodeA1 y CodeA2 y, dado que no se especifican las solicitudes (atributo
MemoryInMB ), se considera que su valor es 0. El límite y la solicitud de memoria de

ServicePackageA se calculan como 0 y 2048, respectivamente. Dado que las solicitudes

de CPU y memoria de ServicePackageA son 0, no presenta ninguna carga que CRM
deba tener en cuenta para la selección de ubicación, en el caso de las métricas
servicefabric:/_CpuCores y servicefabric:/_MemoryInMB . Por lo tanto, desde la

perspectiva de la gobernanza de recursos, ServicePackageA se puede colocar en

cualquier nodo independientemente de la capacidad restante. Al igual que en el
ejemplo 1, en el nodo, CodeA1 se limitará a dos tercios de un núcleo y 1024 MB de
memoria, mientras que CodeA2 se limitará a un tercio de un núcleo y 1024 MB de
memoria.

Ejemplo 3: Especificación RequestsAndLimits

XML

<?xml version='1.0' encoding='UTF-8'?>

<ApplicationManifest ApplicationTypeName='TestAppTC1'
ApplicationTypeVersion='vTC1'
xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric
ServiceFabricServiceModel.xsd'
xmlns='http://schemas.microsoft.com/2011/01/fabric'
xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName='ServicePackageA'
ServiceManifestVersion='v1'/>
<Policies>
<ServicePackageResourceGovernancePolicy CpuCores="1"
CpuCoresLimit="2"/>
<ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512"
MemoryInMB="1024" MemoryInMBLimit="3072" />
<ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256"
MemoryInMB="2048" MemoryInMBLimit="4096" />
</Policies>
</ServiceManifestImport>

A partir de los dos primeros ejemplos, en este ejemplo se muestra la especificación de

las solicitudes y los límites de la CPU y la memoria. ServicePackageA tiene solicitudes de
CPU y memoria de un núcleo y 3072 (1024 + 2048) MB, respectivamente. Solo se puede
colocar en un nodo que tenga al menos un núcleo (y 3072 MB) de capacidad restante
después de restar la suma de todas las solicitudes de CPU (y memoria) de todos los
paquetes de servicio que se colocan en el nodo de la capacidad total de CPU (y
memoria) del nodo. En el nodo, CodeA1 se limitará a dos tercios de 2 núcleos y
3072 MB de memoria, mientras que CodeA2 se limitará a un tercio de 2 núcleos y
4096 MB de memoria.

Uso de los parámetros de la aplicación

Al especificar la configuración de gobernanza de recursos, es posible utilizar parámetros
de la aplicación para administrar varias configuraciones de la aplicación. En el ejemplo
siguiente se muestra el uso de los parámetros de la aplicación:

XML

<?xml version='1.0' encoding='UTF-8'?>

<ApplicationManifest ApplicationTypeName='TestAppTC1'
ApplicationTypeVersion='vTC1'
xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric
ServiceFabricServiceModel.xsd'
xmlns='http://schemas.microsoft.com/2011/01/fabric'
xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>

<Parameters>
<Parameter Name="CpuCores" DefaultValue="4" />
<Parameter Name="CpuSharesA" DefaultValue="512" />
<Parameter Name="CpuSharesB" DefaultValue="512" />
<Parameter Name="MemoryA" DefaultValue="2048" />
<Parameter Name="MemoryB" DefaultValue="2048" />
</Parameters>

<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName='ServicePackageA'
ServiceManifestVersion='v1'/>
<Policies>
<ServicePackageResourceGovernancePolicy CpuCores="[CpuCores]"/>
<ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="
[CpuSharesA]" MemoryInMB="[MemoryA]" />
<ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="
[CpuSharesB]" MemoryInMB="[MemoryB]" />
</Policies>
</ServiceManifestImport>

En este ejemplo, se establecen los valores de los parámetros predeterminados para el

entorno de producción, donde cada paquete de servicio obtendría 4 núcleos y 2 GB de
memoria. Es posible cambiar los valores predeterminados con los archivos de
parámetros de la aplicación. En este ejemplo se puede utilizar un archivo de parámetros
para probar la aplicación localmente, donde obtendría menos recursos que en
producción:

XML

<!-- ApplicationParameters\Local.xml -->

<Application Name="fabric:/TestApplication1"
xmlns="http://schemas.microsoft.com/2011/01/fabric">
<Parameters>
<Parameter Name="CpuCores" DefaultValue="2" />
<Parameter Name="CpuSharesA" DefaultValue="512" />
<Parameter Name="CpuSharesB" DefaultValue="512" />
<Parameter Name="MemoryA" DefaultValue="1024" />
<Parameter Name="MemoryB" DefaultValue="1024" />
</Parameters>
</Application>

） Importante

La especificación de la gobernanza de recursos con parámetros de la aplicación

está disponible a partir de Service Fabric versión 6.1.

Cuando se usan parámetros de la aplicación para especificar la gobernanza de

recursos, Service Fabric no se puede degradar a una versión anterior a la versión
6.1.

Aplicación de los límites de recursos para los

servicios de usuario
Si bien la aplicación de la gobernanza de recursos a los servicios de Service Fabric
garantiza que esos servicios gobernados por los recursos no pueden exceder la cuota
de recursos, muchos usuarios todavía tienen que ejecutar algunos de sus servicios de
Service Fabric en modo no controlado. Cuando se usan los servicios de Service Fabric sin
control, es posible que surjan situaciones donde los servicios "descontrolados"
consuman todos los recursos disponibles en los nodos de Service Fabric, lo que puede
generar problemas graves como:

El colapso de los recursos de otros servicios que se ejecutan en los nodos

(incluidos los servicios de sistema de Service Fabric)
Nodos que terminan en un estado incorrecto
API de administración de clústeres de Service Fabric sin capacidad de respuesta
Para evitar que se produzcan estas situaciones, Service Fabric le permite aplicar los
límites de recursos para todos los servicios de usuario de Service Fabric que se ejecutan en
el nodo (tanto controlados como no controlados) para garantizar que los servicios de
usuario nunca usen más que la cantidad de recursos especificada. Para ello, el valor de
la configuración EnforceUserServiceMetricCapacities de la sección
PlacementAndLoadBalancing de ClusterManifest se establece en true. De manera
predeterminada, esta configuración está desactivada.

XML

<SectionName="PlacementAndLoadBalancing">
<ParameterName="EnforceUserServiceMetricCapacities" Value="false"/>
</Section>

Comentarios adicionales:

La aplicación de límites para los recursos solo se aplica a las métricas de recursos
servicefabric:/_CpuCores y servicefabric:/_MemoryInMB .

La aplicación de límites para los recursos solo funciona si las capacidades de nodo
para las métricas de recursos están disponibles para Service Fabric, ya sea a través
de un mecanismo de detección automática como mediante usuarios que
especifican de manera manual las capacidades de nodo (tal como se explicó en la
sección Configuración del clúster para habilitar la gobernanza de recursos). Si las
capacidades de nodo no están configuradas, no se puede usar la funcionalidad de
aplicación de límites para los recursos ya que Service Fabric no puede saber
cuántos recursos reservar para los servicios de usuario. Service Fabric emitirá una
advertencia de estado si el valor de "EnforceUserServiceMetricCapacities" es true,
pero las capacidades de nodo no están configuradas.

Otros recursos para los contenedores

Además de la CPU y de la memoria, es posible especificar otros límites de recursos para
los contenedores. Estos límites se especifican en el nivel del paquete de código y se
aplican cuando se inicia el contenedor. A diferencia de con la CPU y la memoria, Cluster
Resource Manager no tiene en cuenta estos recursos y no realiza ninguna
comprobación de capacidad ni de equilibrio de carga para ellos.

MemorySwapInMB: la cantidad total de memoria de intercambio que puede

utilizarse, en MB. Debe ser un entero positivo.
MemoryReservationInMB: límite flexible (en MB) para la gobernanza de memoria
que se aplica únicamente cuando se detecta contención de la memoria en el nodo.
Debe ser un entero positivo.
 CpuPercent: porcentaje que se puede utilizar de las CPU disponibles (solo para
Windows). Debe ser un entero positivo. No se puede usar con CpuShares,
CpuCores o CpuCoresLimit.
CpuShares: peso relativo de CPU. Debe ser un entero positivo. No se puede usar
con CpuPercent, CpuCores o CpuCoresLimit.
MaximumIOps: máxima tasa de E/S (lectura y escritura) en términos de IOPS que se
puede usar. Debe ser un entero positivo.
MaximumIOBandwidth: máximo de E/S (bytes por segundo) que se puede usar
(lectura y escritura). Debe ser un entero positivo.
BlockIOWeight: peso de E/S en bloque, en relación con otros paquetes de código.
Debe ser un entero positivo comprendido entre 10 y 1000.
DiskQuotaInMB: cuota de disco para contenedores. Debe ser un entero positivo.
KernelMemoryInMB: límites de memoria del kernel en bytes. Debe ser un entero
positivo. Tenga en cuenta que esto es específico de Linux, y Docker en Windows
generará un error si se establece.
ShmSizeInMB: tamaño de /dev/shm en bytes. Si se omite, el sistema usa 64 MB.
Debe ser un entero positivo. Tenga en cuenta que esto es específico de Linux, pero
Docker solo ignorará (y no generará un error) si se especifica.

Estos recursos se pueden combinar con la CPU y la memoria. Este es un ejemplo de

cómo se especifican recursos adicionales para los contenedores:

XML

<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="FrontendServicePackage"
ServiceManifestVersion="1.0"/>
<Policies>
<ResourceGovernancePolicy CodePackageRef="FrontendService.Code"
CpuPercent="5"
MemorySwapInMB="4084" MemoryReservationInMB="1024"
MaximumIOPS="20" />
</Policies>
</ServiceManifestImport>

Pasos siguientes
Para más información sobre Cluster Resource Manager, consulte Presentación de
Cluster Resource Manager de Service Fabric.
Para más información sobre el modelo de aplicación, paquetes de servicio,
paquetes de código y cómo las réplicas los asignan, lea Modelar una aplicación en
Service Fabric.
Comentarios
¿Le ha resultado útil esta página?  Sí  No

Proporcionar comentarios sobre el producto | Obtener ayuda en Microsoft Q&A

Introducción al modo enjambre
Artículo • 23/01/2025

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

¿Qué es el “modo enjambre”?

El modo enjambre es una característica de Docker que proporciona funciones de
orquestación de contenedores integradas, lo que incluye la agrupación en clústeres de
hosts de Docker y la programación de cargas de trabajo de contenedores. Un grupo de
hosts de Docker forman un clúster “enjambre” cuando sus motores de Docker se
ejecutan juntos en “modo enjambre”. Para obtener contexto adicional respecto al modo
enjambre, consulta el sitio de documentación principal del Docker .

Nodos de administrador y nodos de trabajo

Un enjambre se compone de dos tipos de hosts de contenedor: nodos de administrador
y nodos de trabajo. Cada enjambre se inicializa a través de un nodo de administrador y
todos los comandos de la CLI de Docker para el control y la supervisión de un enjambre
se deben ejecutar desde uno de sus nodos de administrador. Los nodos de
administrador se pueden ver como “guardianes” del estado del enjambre; en conjunto,
forman un grupo de consenso que mantiene el conocimiento del estado de los servicios
que se ejecutan en el enjambre, y su trabajo es garantizar que el estado real del
enjambre siempre coincide con el estado pretendido, según lo que hayan definido el
desarrollador o el administrador.

７ Nota

Cualquier enjambre puede tener varios nodos de administrador, pero siempre debe
tener al menos uno.

Los nodos de trabajo los organiza el enjambre de Docker a través de los nodos de
administrador. Para unirse a un enjambre, un nodo de trabajo debe usar un “token de
unión” que genera el nodo de administrador al inicializa el enjambre. Los nodos de
trabajo simplemente reciben tareas desde los nodos de administrador y las ejecutan,
por lo que no requieren (ni poseen) ningún conocimiento del estado del enjambre.
Requisitos del sistema para el modo enjambre
Al menos un sistema de equipo físico o virtual (para usar la funcionalidad completa de
enjambre, se recomienda al menos dos nodos) que ejecute Windows 10 Creators
Update o Windows Server 2016con todas las últimas actualizaciones*, configurado
como un host de contenedor (consulta el tema Contenedores de Windows en Windows
10 o Contenedores de Windows en Windows Server para obtener más información
sobre cómo empezar a usar contenedores de Docker en Windows 10).

*Nota: El enjambre de Docker en Windows Server 2016 requiere KB4015217 .

Docker Engine v1.13.0 o posterior

Puertos abiertos: Los siguientes puertos deben estar disponibles en todos los host. En
algunos sistemas, estos puertos están abiertos de manera predeterminada.

Puerto TCP 2377 para las comunicaciones de administración de clústeres.

Puerto TCP y UDP 7946 para la comunicación entre los nodos.
Puerto UDP 4789 para el tráfico de redes superpuestas

Inicialización de un clúster enjambre

Para inicializar un enjambre, solo tienes que ejecutar el comando siguiente desde uno
de los hosts de contenedor (sustituyendo <HOSTIPADDRESS> por la dirección IPv4 local
del equipo host):

PowerShell

# Initialize a swarm
C:\> docker swarm init --advertise-addr=<HOSTIPADDRESS> --listen-addr
<HOSTIPADDRESS>:2377

Cuando este comando se ejecuta desde un host de contenedor, el Docker Engine de

dicho host comienza a ejecutarse en modo enjambre como un nodo de administrador.

Agregar nodos a un enjambre

No son necesarios varios nodos para aprovechar las características del modo enjambre y
las redes superpuestas. Todas las características de enjambre/superposición pueden
usarse con un único host que se ejecute en modo enjambre (es decir, un nodo de
administrador situado en modo enjambre con el comando docker swarm init ).
Agregar nodos de trabajo a un enjambre
Una vez que se ha inicializado un enjambre desde un nodo de administrador, pueden
agregarse otros hosts al enjambre como nodos de trabajo con otro sencillo comando:

PowerShell

C:\> docker swarm join --token <WORKERJOINTOKEN> <MANAGERIPADDRESS>

Aquí, <MANAGERIPADDRESS> es la dirección IP local de un nodo de administrador

enjambre, y <WORKERJOINTOKEN> es el token de unión de nodo de trabajo
proporcionado como salida por el comando docker swarm init ejecutado desde el
nodo de administrador. El token de unión también se puede obtener si se ejecuta uno
de los siguientes comandos desde el nodo de administrador después de inicializar el
enjambre:

PowerShell

# Get the full command required to join a worker node to the swarm
C:\> docker swarm join-token worker

# Get only the join-token needed to join a worker node to the swarm
C:\> docker swarm join-token worker -q

Agregar nodos de administrador a un enjambre

Pueden agregarse nodos de administrador adicionales a un clúster enjambre con el
siguiente comando:

PowerShell

C:\> docker swarm join --token <MANAGERJOINTOKEN> <MANAGERIPADDRESS>

De nuevo, <MANAGERIPADDRESS> es la dirección IP local de un nodo de administrador

enjambre. El token de unión <MANAGERJOINTOKEN>, es un token de unión de nodo
de administrador para el enjambre, que puede obtenerse mediante la ejecución de uno
de los siguientes comandos desde un nodo de administrador existente:

PowerShell

# Get the full command required to join a **manager** node to the swarm
C:\> docker swarm join-token manager
 # Get only the join-token needed to join a **manager** node to the swarm
C:\> docker swarm join-token manager -q

Creación de una red superpuesta

Una vez que se ha configurado un clúster enjambre, se pueden crear redes superpuestas
en el enjambre. Es posible crear una red superpuesta mediante la ejecución del
siguiente comando desde un nodo de administrador enjambre:

PowerShell

# Create an overlay network

C:\> docker network create --driver=overlay <NETWORKNAME>

Aquí, <NETWORKNAME> es el nombre que quieras dar a la red.

Implementación de servicios para un enjambre

Una vez que se ha creado una red superpuesta, pueden crearse servicios y adjuntarlos a
dicha red. Para crear un servicio, se emplea la sintaxis siguiente:

PowerShell

# Deploy a service to the swarm

C:\> docker service create --name=<SERVICENAME> --endpoint-mode dnsrr --
network=<NETWORKNAME> <CONTAINERIMAGE> [COMMAND] [ARGS…]

Aquí, <SERVICENAME> es el nombre que quieres darle al servicio; es el nombre que

usarás para hacer referencia al servicio a través de la detección de servicios (que usa el
servidor DNS nativo de Docker). <NETWORKNAME> es el nombre de la red a la que
quieres conectar este servicio (por ejemplo, "myOverlayNet"). <CONTAINERIMAGE> es
el nombre de la imagen de contenedor que definirá el servicio.

７ Nota

El segundo argumento de este comando, --endpoint-mode dnsrr , es necesario para

especificar a Docker Engine que se usará la directiva de round robin de DNS para
equilibrar el tráfico de red en los puntos de conexión del contenedor de servicios.
Actualmente, round robin de DNS es la única estrategia de equilibrio de carga
compatible en Windows Server 2016. La malla de enrutamiento para hosts de
Windows Docker se admite en Windows Server 2019 (y versiones posteriores), pero
 no en Windows Server 2016. Los usuarios que actualmente quieran una estrategia
de equilibrio de carga alternativa en Windows Server 2016 pueden configurar un
equilibrador de carga externo (como NGINX) y usar el modo de publicar puerto
del enjambre para exponer los puertos del host de contenedor para los cuales
equilibrar la carga.

Escalado de un servicio
Una vez que un servicio se ha implementado en un clúster enjambre, se implementan en
todo el clúster las instancias de contenedor que componen ese servicio. De manera
predeterminada, el número de instancias de contenedor que respaldan un servicio (el
número de “réplicas” o “tareas” para un servicio) es uno. Sin embargo, se puede crear un
servicio con varias tareas mediante la opción --replicas para el comando docker
service create o mediante el escalado del servicio después de haberlo creado.

La escalabilidad del servicio es una de las ventajas clave que ofrece el modo enjambre
de Docker y, además, se puede aprovechar con un solo comando de Docker:

PowerShell

C:\> docker service scale <SERVICENAME>=<REPLICAS>

Aquí, <SERVICENAME> es el nombre del servicio que se escala, y <REPLICAS> es el

número de tareas, o instancias del contenedor, al que se escala el servicio.

Visualización el estado del enjambre

Existen varios comandos útiles para ver el estado de un enjambre y los servicios que se
ejecutan en él.

Mostrar lista de nodos enjambre

Usa el siguiente comando para ver una lista de los nodos unidos a un enjambre en estos
momentos, incluida información sobre el estado de cada uno de dichos nodos. Este
comando debe ejecutarse desde un nodo de administrador.

PowerShell

C:\> docker node ls

En el resultado de este comando, verás que uno de los nodos está marcado con un
asterisco (*); este asterisco indica simplemente el nodo actual: el nodo desde el que el
se ha ejecutado el comando docker node ls .

Mostrar lista de redes

Usa el siguiente comando para ver una lista de las redes que se encuentran en un nodo
determinado. Para ver las redes superpuestas, este comando debe ejecutarse desde un
nodo de administrador que se ejecute en modo enjambre.

PowerShell

C:\> docker network ls

Mostrar lista de servicios

Usa el siguiente comando para ver una lista de los servicios que se están ejecutando
actualmente en un enjambre, incluida información sobre su estado.

PowerShell

C:\> docker service ls

Mostrar lista de las instancias de contenedor que definen

un servicio
Usa el siguiente comando para ver los detalles de las instancias de contenedor que se
ejecutan para un servicio determinado. El resultado de este comando incluye los
identificadores y los nodos en los que se ejecuta cada contenedor, así como información
sobre el estado de los contenedores.

PowerShell

C:\> docker service ps <SERVICENAME>

Clústeres de sistemas operativos combinados

Windows + Linux
Recientemente, un miembro de nuestro equipo publicó una demo breve de tres partes
sobre cómo configurar una aplicación con sistemas operativos combinados Windows y
Linux con el enjambre de Docker. Es un lugar excelente para empezar si no estás
familiarizado con el enjambre de Docker o para utilizarlo para ejecutar aplicaciones con
sistemas operativos combinados. Echa un vistazo ahora:

Usar enjambre de Docker para ejecutar una aplicación en contenedores de

Windows + Linux (parte 1/3)
Usar enjambre de Docker para ejecutar una aplicación en contenedores de
Windows + Linux (parte 2/3)
Usar enjambre de Docker para ejecutar una aplicación en contenedores de
Windows + Linux (parte 3/3)

Inicialización de un clúster con sistemas operativos

combinados Linux+Windows
La inicialización de un clúster enjambre con sistemas operativos combinados es fácil:
siempre y cuando las reglas de firewall estén correctamente configuradas y los hosts
tengan acceso unos a otros, lo único que necesitas para agregar un host de Linux a un
conjunto es el comando docker swarm join estándar:

PowerShell

C:\> docker swarm join --token <JOINTOKEN> <MANAGERIPADDRESS>

```powershell
You can also initialize a swarm from a Linux host using the same command
that you would run if initializing the swarm from a Windows host:

```powershell
# Initialize a swarm
C:\> docker swarm init --advertise-addr=<HOSTIPADDRESS> --listen-addr
<HOSTIPADDRESS>:2377

Agregar etiquetas a nodos enjambre

Para iniciar un servicio de Docker para un clúster enjambre de sistemas operativos
combinados, debe haber una forma de distinguir qué nodos enjambre ejecutan el
sistema operativo para el que se ha diseñado ese servicio y cuáles no. Las etiquetas de
objeto de Docker proporcionan una forma útil de etiquetar nodos, de forma que los
servicios pueden crearse y configurarse para ejecutarse solamente en los nodos que
coincidan con su sistema operativo.
 ７ Nota

Las etiquetas de objeto de Docker pueden usarse para aplicar los metadatos a
diversos objetos de Docker (incluidas imágenes de contenedor, contenedores,
volúmenes y redes) y para diversos fines (por ejemplo, pueden usarse etiquetas
para separar componentes de "front-end" y "back-end" de una aplicación, al
permitir la programación de microservicios front-end únicamente en nodos
etiquetados como "front-end", y programar microservicios back-end solo en nodos
etiquetados como "back-end"). En este caso, usamos etiquetas en nodos para
distinguir entre nodos con sistema operativo Windows y nodos con sistema
operativo Linux.

Para etiquetar los nodos enjambre existente, usa la sintaxis siguiente:

PowerShell

C:\> docker node update --label-add <LABELNAME>=<LABELVALUE> <NODENAME>

Aquí, <LABELNAME> es el nombre de la etiqueta que se crea: por ejemplo, en este caso
distinguimos nodos por su sistema operativo, por lo que un nombre lógico de la
etiqueta podría ser "so". <LABELVALUE> es el valor de la etiqueta, en este caso, puedes
usar los valores "windows" y "linux". (Por supuesto, puedes elegir los nombres que
quieras para la etiqueta y los valores de la etiqueta, siempre que mantengas la
coherencia). <NODENAME> es el nombre del nodo que se etiqueta; puedes recordarte los
nombres de los nodos ejecutando docker node ls .

Por ejemplo, si tienes cuatro nodos enjambre en el clúster, incluidos dos nodos
Windows y dos nodos Linux, los comandos de actualización de la etiquetas pueden
tener el siguiente aspecto:

PowerShell

# Example -- labeling 2 Windows nodes and 2 Linux nodes in a cluster...

C:\> docker node update --label-add os=windows Windows-SwarmMaster
C:\> docker node update --label-add os=windows Windows-SwarmWorker1
C:\> docker node update --label-add os=linux Linux-SwarmNode1
C:\> docker node update --label-add os=linux Linux-SwarmNode2

Implementación de servicios para un enjambre con

sistemas operativos combinados
Con etiquetas para los nodos enjambre, implementar servicios en el clúster es fácil; solo
tienes que usar la opción --constraint para el comando docker service create :

PowerShell

# Deploy a service with swarm node constraint

C:\> docker service create --name=<SERVICENAME> --endpoint-mode dnsrr --
network=<NETWORKNAME> --constraint node.labels.<LABELNAME>=<LABELVALUE>
<CONTAINERIMAGE> [COMMAND] [ARGS…]

Por ejemplo, si usas la nomenclatura de etiqueta y valor de etiqueta del ejemplo

anterior, un conjunto de comandos de creación de servicios (uno para un servicio
basado en Windows y otro para un servicio basado en Linux) podría tener el siguiente
aspecto:

PowerShell

# Example -- using the 'os' label and 'windows'/'linux' label values,

service creation commands might look like these...

# A Windows service
C:\> docker service create --name=win_s1 --endpoint-mode dnsrr --network
testoverlay --constraint 'node.labels.os==windows'
microsoft/nanoserver:latest powershell -command { sleep 3600 }

# A Linux service
C:\> docker service create --name=linux_s1 --endpoint-mode dnsrr --network
testoverlay --constraint 'node.labels.os==linux' redis

Limitaciones
Actualmente, el modo enjambre en Windows tiene las siguientes limitaciones:

No se admite el cifrado del plano de datos (es decir, el tráfico de contenedor a

contenedor mediante la opción --opt encrypted ).
La malla de enrutamiento no se admite para hosts de Windows Docker en
Windows Server 2016, sino desde Windows Server 2019 en adelante únicamente.
Los usuarios que deseen una estrategia de equilibrio de carga alternativa en estos
momentos pueden configurar un equilibrador de carga externo (como NGINX) y
usar el modo de publicar puerto del enjambre para exponer los puertos de host
del contenedor para los que equilibrar la carga. Encontrarás más información sobre
este tema más adelante.
Publicar puertos para los puntos de conexión
de servicio
Los usuarios que quieran publicar los puertos para los puntos de conexión de servicios
pueden hacerlo ya con el modo de publicar puerto o con la característica de malla de
enrutamiento del enjambre de Docker.

Para hacer que los puertos de host se publiquen para cada uno de los puntos de
conexión de tareas o contenedores que definen un servicio, usa el argumento --publish
mode=host,target=<CONTAINERPORT> para el comando docker service create :

PowerShell

# Create a service for which tasks are exposed via host port
C:\ > docker service create --name=<SERVICENAME> --publish mode=host,target=
<CONTAINERPORT> --endpoint-mode dnsrr --network=<NETWORKNAME>
<CONTAINERIMAGE> [COMMAND] [ARGS…]

Por ejemplo, el siguiente comando crear un servicio, 's1', para el que cada tarea se
mostrará a través del puerto 80 del contenedor y un puerto del host seleccionado de
forma aleatoria.

PowerShell

C:\ > docker service create --name=s1 --publish mode=host,target=80 --

endpoint-mode dnsrr web_1 powershell -command {echo sleep; sleep 360000;}

Tras crear un servicio con el modo de publicar puerto, el servicio puede consultarse para
ver la asignación de puertos correspondiente a cada tarea de servicio:

PowerShell

C:\ > docker service ps <SERVICENAME>

El comando anterior devolverá los detalles sobre cada instancia de contenedor en

ejecución para el servicio (en todos los hosts enjambre). Una columna de la salida, la
columna "ports", incluye información de puerto para cada host con la forma
<HOSTPORT>-><CONTAINERPORT>/tcp. Los valores de <HOSTPORT> serán diferentes
para cada instancia de contenedor, ya que cada contenedor se publica en su propio
puerto del host.

Recomendaciones y conclusiones
La red transparente existente puede bloquear la inicialización de enjambres o la
creación de redes de superposición En Windows, tanto los controladores de red de
superposición como los transparentes necesitan que haya un conmutador virtual
(vSwitch) externo vinculado a un adaptador de red de host (virtual). Cuando se crea una
red superpuesta, también se crea un nuevo conmutador y después se conecta a un
adaptador de red abierto. El modo de redes transparentes también usa un adaptador de
red de host. Al mismo tiempo, cualquier adaptador de red solo se puede enlazar a un
único conmutador a la vez; si un host tiene un solo adaptador de red, puede conectarse
a un único vSwitch externo en cada momento, tanto si ese vSwitch es para una red
superpuesta como si es para una red transparente.

Por lo tanto, si un host de contenedor tiene solamente un adaptador de red, es posible

encontrarse el problema de que una red transparente bloquee la creación de una red
superpuesta (o viceversa), porque la red transparente está ocupando actualmente la
única interfaz de red virtual del host.

Existen dos maneras de solventar este problema:

Opción 1: Eliminar la red transparente existente. Antes de inicializar un enjambre,

asegúrate de que no haya ninguna red transparente existente en el host del
contenedor. Elimina las redes transparentes para asegurarte de que hay un
adaptador de red virtual libre en el host para usarlo para la creación de la red
superpuesta.
Opción 2: Crear un adaptador de red (virtual) adicional en el host. En lugar de quitar
las redes transparentes que haya en el host, puedes crear un adaptador de red
adicional en el host y utilizarlo para la creación de la red superpuesta. Para ello,
simplemente crea un nuevo adaptador de red externo (mediante PowerShell o el
administrador de Hyper-V); con la nueva interfaz creada, cuando se inicialice el
enjambre, el servicio de red de host (HNS) la reconocerá automáticamente en el
host y la usará para enlazar el vSwitch externo para la creación de la red
superpuesta.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Proteger los contenedores de Windows
Artículo • 30/04/2024

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

Los contenedores deben su tamaño de imagen reducido al hecho de que se basan en el

host para proporcionar acceso limitado a varios recursos. Si el contenedor sabe que el
host podrá proporcionar la funcionalidad necesaria para realizar un conjunto específico
de acciones, el contenedor no necesita incluir el software pertinente en su imagen base.
Sin embargo, el grado del uso compartido de los recursos que tiene lugar puede afectar
de manera significativa al rendimiento y la seguridad del contenedor. Si se comparten
demasiados recursos, es posible que la aplicación también se ejecute como un proceso
en el host. Si los recursos se comparten demasiado poco, el contenedor no se distingue
de una VM. Ambas configuraciones son aplicables a muchos escenarios, pero la mayoría
de las personas que usan contenedores suelen optar por algo intermedio.

La seguridad de un contenedor de Windows se deriva del grado de uso compartido que

tiene lugar en el host. El límite de seguridad de un contenedor se establece mediante
los mecanismos de aislamiento que separan el contenedor del host. Más importante
aún, estos mecanismos de aislamiento definen qué procesos del contenedor pueden
interactuar con el host. Si el diseño de un contenedor permite que un proceso con
privilegios elevados (de administración) interactúe con el host, Microsoft no
considera que este contenedor tenga un límite de seguridad sólido.

Contenedores de Windows Server frente a

contenedores de Linux
Los contenedores de Windows Server y los contenedores de Linux aislados por procesos
comparten grados similares de aislamiento. Para ambos tipos de contenedor, el
desarrollador debe suponer que cualquier ataque que se pueda realizar a través de un
proceso con privilegios elevados en el host también se puede realizar a través de un
proceso con privilegios elevados en el contenedor. Ambos funcionan a través de las
funcionalidades primitivas que ofrecen sus respectivos kernels de host. Las imágenes de
contenedor se crean de modo que incluyen archivos binarios en modo de usuario que
usan las API proporcionadas por el kernel del host. El kernel del host proporciona las
mismas funcionalidades de administración y aislamiento de recursos a cada contenedor
que se ejecuta en el espacio de usuarios. Si el kernel está en peligro, también lo está
cada contenedor que comparte ese kernel.
El diseño fundamental de los contenedores de Linux y Windows Server canjea seguridad
por flexibilidad. Los contenedores de Windows Server y Linux se construyen sobre los
componentes primitivos proporcionados por el sistema operativo. Esto brinda la
flexibilidad para compartir recursos y espacios de nombres entre contenedores, pero
agrega complejidad adicional que abre la puerta a vulnerabilidades. En términos
generales, no consideramos que el kernel sea un límite de seguridad suficiente para
cargas de trabajo multiinquilino hostiles.

Aislamiento del kernel con contenedores

aislados por el hipervisor
Los contenedores aislados por el hipervisor ofrecen un mayor grado de aislamiento que
los contenedores de Windows Server o Linux con aislamiento de procesos, y se
consideran límites de seguridad sólidos. Los contenedores aislados por el hipervisor
constan de un contenedor de Windows Server encapsulado en una VM ultraligera y, a
continuación, se ejecutan junto con el sistema operativo host a través del hipervisor de
Microsoft. El hipervisor proporciona aislamiento a nivel del hardware, que incluye un
límite de seguridad muy sólido entre el host y otros contenedores. Incluso si una
vulnerabilidad traspasara el contenedor de Windows Server, quedaría contenida dentro
de la VM aislada por el hipervisor.

Ni los contenedores de Windows Server ni los contenedores de Linux brindan lo que

Microsoft considera un límite de seguridad sólido, y no deben usarse en escenarios
multiinquilino hostiles. Un contenedor debe limitarse a una VM dedicada para evitar que
un proceso de contenedor no autorizado interactúe con el host u otros inquilinos. El
aislamiento del hipervisor permite este grado de separación, a la vez que ofrece varias
mejoras de rendimiento frente a las VM tradicionales. Por lo tanto, se recomienda
encarecidamente que, en escenarios multiinquilino hostiles, los contenedores aislados
por el hipervisor sean los contenedores de elección.

Criterios de mantenimiento de la seguridad de

los contenedores
Microsoft se compromete a aplicar revisiones a todas las vulnerabilidades de seguridad
y fugas que traspasen el límite de aislamiento establecido de cualquier tipo de
contenedor de Windows. Sin embargo, solo las vulnerabilidades de seguridad que
traspasan un límite de seguridad se abordan a través del proceso del Centro de
respuestas de seguridad de Microsoft (MSRC). Solo los contenedores aislados por el
hipervisor logran un límite de seguridad, los contenedores aislados por procesos no.
La única manera de generar un error en caso de escape de un contenedor aislado por
procesos es si un proceso no administrativo puede acceder al host. Si una vulnerabilidad
de seguridad usa un proceso de administración para escapar el contenedor, Microsoft lo
considera un error que no es de seguridad y le aplicará una revisión según el proceso de
mantenimiento normal. Si una vulnerabilidad de seguridad usa un proceso no
administrativo para realizar una acción que infringe un límite de seguridad, Microsoft lo
investigará según los criterios de mantenimiento de seguridad establecidos .

¿Qué hace que una carga de trabajo

multiinquilino sea hostil?
Existen entornos multiinquilino cuando varias cargas de trabajo funcionan en recursos e
infraestructura compartidos. Si no se puede confiar en una o varias cargas de trabajo
que se ejecutan en una infraestructura, el entorno multiinquilino se considera hostil. Los
contenedores de Windows Server y Linux comparten el kernel del host, por lo que
cualquier vulnerabilidad de seguridad en un solo contenedor puede afectar a todas las
demás cargas de trabajo que se ejecutan en la infraestructura compartida.

Puede adoptar medidas para reducir la posibilidad de que se produzca una

vulnerabilidad de seguridad, por ejemplo, mediante directivas de seguridad de pods,
AppArmor y el control de acceso basado en roles (RBAC), pero no garantizan la
protección frente a un atacante. Se recomienda seguir nuestros procedimientos
recomendados para el aislamiento de clústeres en cualquier escenario multiinquilino.

Cuándo usar cuentas de usuario

ContainerAdmin y ContainerUser
Los contenedores de Windows Server ofrecen dos cuentas de usuario predeterminadas,
ContainerUser y ContainerAdministrator, cada una con su propio propósito específico.
La cuenta ContainerAdministrator permite usar el contenedor con fines administrativos:
instalar servicios y software (por ejemplo, habilitar IIS dentro de un contenedor), hacer
cambios de configuración y crear nuevas cuentas. Estas tareas son importantes para
distintos escenarios de TI que pueden ejecutarse en entornos de implementación locales
personalizados.

La cuenta ContainerUser existe para todos los demás escenarios en los que no se
necesitan privilegios de administrador en Windows. Por ejemplo, en Kubernetes si el
usuario es ContainerAdministrator y se permite montar volúmenes de host en el pod, el
usuario podría montar la carpeta .ssh y agregar una clave pública. Como ContainerUser,
este ejemplo no sería posible. Se trata de una cuenta de usuario restringida diseñada
exclusivamente para aplicaciones que no tienen que interactuar con el host. Se
recomienda encarecidamente que, al implementar un contenedor de Windows Server
en cualquier entorno multiinquilino, la aplicación se ejecute a través de la cuenta
ContainerUser. En un entorno multiinquilino, siempre es mejor seguir el principio del
mínimo de privilegios, ya que si un atacante pone en peligro la carga de trabajo, el
recurso compartido y las cargas de trabajo vecinas tendrán una menor probabilidad de
verse también afectados. La ejecución de contenedores con la cuenta ContainerUser
reduce considerablemente la posibilidad de que el entorno se vea en peligro en su
conjunto. Sin embargo, esto sigue sin brindar un límite de seguridad sólido, por lo que
cuando la seguridad sea una inquietud, debe usar contenedores aislados por el
hipervisor.

Para cambiar la cuenta de usuario, puede usar la instrucción USER en el dockerfile:

Dockerfile

USER ContainerUser

Como alternativa, puede crear un nuevo usuario.

Dockerfile

RUN net user username ‘<password>’ /ADD

USER username

Servicios de Windows
Los servicios de Microsoft Windows, anteriormente conocidos como servicios NT, le
permiten crear aplicaciones de larga ejecución que se ejecutan en sesiones propias de
Windows. Estos servicios se pueden iniciar automáticamente cuando se inicia el sistema
operativo, se pueden pausar y reiniciar y no mostrar ninguna interfaz de usuario.
También puede ejecutar servicios en el contexto de seguridad de una cuenta de usuario
específica que sea diferente del usuario conectado o de la cuenta de equipo
predeterminada.

Al incluir en contenedores y proteger una carga de trabajo que se ejecuta como servicio
de Windows, hay algunas consideraciones adicionales que debe tener en cuenta. En
primer lugar, el ENTRYPOINT del contenedor no va a ser la carga de trabajo, ya que el
servicio se ejecuta como un proceso en segundo plano, normalmente la ENTRYPOINT será
una herramienta como monitor de servicio ) o monitor de registro ). En segundo
lugar, la cuenta de seguridad en la que opera la carga de trabajo se configurará
mediante el servicio y no mediante la directiva USER en el dockerfile. Puede comprobar
en qué cuenta se ejecutará el servicio ejecutando Get-WmiObject win32_service -filter
"name='<servicename>'" | Format-List StartName .

Por ejemplo, al hospedar una aplicación web de IIS mediante la imagen de ASP.NET
(Registro de artefactos Microsoft ), el ENTRYPOINT del contenedor es
"C:\\ServiceMonitor.exe", "w3svc" . Esta herramienta se puede usar para configurar el

servicio IIS y, a continuación, supervisa el servicio para asegurarse de que permanece en

ejecución y sale, deteniendo así el contenedor, si el servicio se detiene por cualquier
motivo. De forma predeterminada, el servicio IIS y, por tanto, la aplicación web se
ejecuta con una cuenta con pocos privilegios dentro del contenedor, pero la
herramienta de supervisión de servicios requiere privilegios administrativos para
configurar y supervisar el servicio.
Creación de gMSA para contenedores
de Windows
Artículo • 05/02/2025

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

Las redes basadas en Windows suelen usar Active Directory (AD) para facilitar la
autenticación y autorización entre usuarios, equipos y otros recursos de red. Los
desarrolladores de aplicaciones empresariales suelen diseñar sus aplicaciones para que
se integren en AD y se ejecuten en servidores unidos a un dominio para aprovechar la
autenticación integrada de Windows, lo que facilita a los usuarios y otros servicios iniciar
sesión automáticamente y de forma transparente en la aplicación con sus identidades.
En este artículo se explica cómo empezar a usar cuentas de servicio administradas de
grupo de Active Directory con contenedores de Windows.

Aunque los contenedores de Windows no pueden estar unidos a un dominio, todavía

pueden usar identidades de dominio de Active Directory para admitir varios escenarios
de autenticación. Para ello, puede configurar un contenedor de Windows para que se
ejecute con una cuenta de servicio administrada de grupo (gMSA), que es un tipo
especial de cuenta de servicio introducida en Windows Server 2012 y diseñada para
permitir que varios equipos compartan una identidad sin necesidad de conocer su
contraseña. Los contenedores de Windows no se pueden unir a un dominio, pero
muchas aplicaciones de Windows que se ejecutan en contenedores de Windows todavía
necesitan autenticación de AD. Para usar la autenticación de AD, puede configurar un
contenedor de Windows para que se ejecute con una cuenta de servicio administrada
de grupo (gMSA).

Cuando se introdujo gMSA para contenedores de Windows inicialmente, requería que el

host de contenedor estuviera unido a un dominio, lo que creó una gran sobrecarga para
que los usuarios unan manualmente nodos de trabajo de Windows a un dominio. Esta
limitación se ha solucionado con la compatibilidad de gMSA para contenedores de
Windows con hosts de contenedor no unidos a un dominio. Continuaremos admitiendo
la funcionalidad de gMSA original para usar un host de contenedor unido a un dominio.

Entre las mejoras de gMSA al usar un host de contenedor no unido a un dominio se

incluyen:

El requisito de unir manualmente nodos de trabajo de Windows a un dominio se

elimina porque provocó una gran sobrecarga para los usuarios. Para escenarios de
 escalado, el uso de un host de contenedor no unido a un dominio simplifica el
proceso.
En escenarios de actualización gradual, los usuarios ya no deben volver a unir el
nodo a un dominio.
La administración de las cuentas de máquina del nodo de trabajo para recuperar
contraseñas de cuenta de servicio gMSA es un proceso más sencillo.
La configuración de gMSA con Kubernetes es un proceso de un extremo a otro
menos complicado.

７ Nota

Para obtener información sobre cómo la comunidad de Kubernetes admite el uso

de gMSA con contenedores de Windows, consulte configuración de gMSA .

Arquitectura y mejoras de gMSA

Para abordar las limitaciones de la implementación inicial de gMSA para contenedores
de Windows, la nueva compatibilidad con gMSA para hosts de contenedor no unidos a
un dominio usa una identidad de usuario portátil en lugar de una cuenta de equipo host
para recuperar las credenciales de gMSA. Por lo tanto, la unión manual de nodos de
trabajo de Windows a un dominio ya no es necesaria, aunque todavía se admite. La
identidad o credenciales de usuario se almacenan en un almacén de secretos accesible
para el host de contenedor (por ejemplo, como un secreto de Kubernetes) donde los
usuarios autenticados pueden recuperarlo.
La compatibilidad de gMSA con hosts de contenedor no unidos a un dominio
proporciona la flexibilidad de crear contenedores con gMSA sin unir el nodo host al
dominio. A partir de Windows Server 2019, se admite ccg.exe que permite que un
mecanismo de complemento recupere las credenciales de gMSA de Active Directory.
Puede usar esa identidad para iniciar el contenedor. Para obtener más información
sobre este mecanismo de complemento, consulte la interfaz
ICcgDomainAuthCredentials.

７ Nota

En Azure Kubernetes Service en Azure Stack HCI, puede usar el complemento para
comunicarse desde ccg.exe a AD y, a continuación, recuperar las credenciales de
gMSA. Para más información, vea Configuración de cuentas de servicio
administrado de grupo con AKS en Azure Stack HCI.

Vea el diagrama siguiente para seguir los pasos del proceso de Container Credential
Guard:

1. Con un archivo CredSpec como entrada, el proceso de ccg.exe se inicia en el host

del nodo.

2. ccg.exe usa información del archivo CredSpec para iniciar un complemento y,

después, recuperar las credenciales de la cuenta en el almacén de secretos
asociado al complemento.

3. ccg.exe usa las credenciales de cuenta recuperadas para recuperar la contraseña

de gMSA de AD.

4. ccg.exe hace que la contraseña de gMSA esté disponible para un contenedor que
haya solicitado credenciales.

5. El contenedor se autentica en el controlador de dominio usando la contraseña

gMSA para obtener un ticket Kerberos Ticket-Granting (TGT).

6. Las aplicaciones que se ejecutan como servicio de red o sistema local en el

contenedor ahora pueden autenticarse y acceder a recursos de dominio, como
gMSA.
 diagrama de

Prerrequisitos
Para ejecutar un contenedor de Windows con una cuenta de servicio administrada de
grupo, necesitará lo siguiente:

Un dominio de Active Directory con al menos un controlador de dominio que

ejecute Windows Server 2012 o posterior. No hay ningún requisito de nivel
funcional de bosque o dominio para usar gMSAs, pero las contraseñas de gMSAs
solo pueden ser distribuidas por controladores de dominio que ejecuten Windows
Server 2012 o una versión posterior. Para más información, vea Requisitos de
Active Directory para gMSA.
Permiso para crear una cuenta de gMSA. Para crear una cuenta de gMSA, deberá
ser Administrador de Dominios o usar una cuenta a la que se le haya delegado el
permiso Crear objetos msDS-GroupManagedServiceAccount.
Acceso a Internet para descargar el módulo de PowerShell CredentialSpec. Si
trabaja en un entorno desconectado, puede guardar el módulo en un equipo con
acceso a Internet y copiarlo en el equipo de desarrollo o host del contenedor.

Preparación única de Active Directory

Si aún no ha creado una gMSA en el dominio, deberá generar la clave raíz del Servicio
de distribución de claves (KDS). KDS es responsable de crear, rotar y liberar la
contraseña de gMSA a hosts autorizados. Cuando un host de contenedor necesite usar
la gMSA para ejecutar un contenedor, se pondrá en contacto con el KDS para recuperar
la contraseña actual.

Para comprobar si ya se ha creado la clave raíz de KDS, ejecute el siguiente cmdlet de

PowerShell como administrador de dominio en un controlador de dominio o miembro
de dominio con las herramientas de PowerShell de AD instaladas:

PowerShell

Get-KdsRootKey

Si el comando devuelve un identificador de clave, todos están configurados y pueden ir

directamente a la sección crear una cuenta de servicio administrada de grupo. De lo
contrario, continúe para crear la clave raíz de KDS.

） Importante

Solo debe crear una clave raíz de KDS por bosque. Si se crean varias claves raíz de
KDS, se empezarán a producir errores en la gMSA después de cambiar su
contraseña.

En un entorno de producción o en un entorno de prueba con varios controladores de

dominio, ejecute el siguiente cmdlet en PowerShell como administrador de dominio
para crear la clave raíz de KDS.

PowerShell

# For production environments

Add-KdsRootKey -EffectiveImmediately

Aunque el comando implica que la clave será efectiva inmediatamente, deberá esperar
10 horas antes de que se replique la clave raíz KDS y esté disponible para su uso en
todos los controladores de dominio.

Si solo tiene un controlador de dominios en su dominio, puede agilizar el proceso

estableciendo que la clave sea efectiva desde hace 10 horas.

） Importante

No use esta técnica en un entorno de producción.

 PowerShell

# For single-DC test environments only

Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

Creación de una cuenta de servicio

administrada de grupo
Cada contenedor que usa autenticación integrada de Windows necesita al menos una
gMSA. La gMSA principal se usa cada vez que las aplicaciones que se ejecutan como un
sistema o un servicio de red acceden a los recursos de la red. El nombre de la gMSA se
convertirá en el nombre del contenedor en la red, independientemente del nombre de
host asignado al contenedor. Los contenedores también se pueden configurar con
gMSA adicionales, en caso de que quiera ejecutar un servicio o una aplicación en el
contenedor como una identidad diferente de la cuenta de equipo contenedor.

Al crear una gMSA, también se crea una identidad compartida que se puede usar
simultáneamente en muchas máquinas diferentes. El acceso a la contraseña de gMSA
está protegido por una lista de control de acceso de Active Directory. Se recomienda
crear un grupo de seguridad para cada cuenta de gMSA y agregar los hosts de
contenedor pertinentes al grupo de seguridad para limitar el acceso a la contraseña.

Por último, dado que los contenedores no registran automáticamente ningún Service
Principal Name (SPN), deberá crear manualmente al menos un SPN de host para la
cuenta de gMSA.

Normalmente, el host o el SPN http se registran con el mismo nombre que la cuenta de
gMSA, pero es posible que tenga que usar otro nombre de servicio si los clientes
acceden a la aplicación contenedorizada desde detrás de un equilibrador de carga o un
nombre DNS distinto del nombre de gMSA.

Por ejemplo, si la cuenta gMSA se llama "WebApp01", pero los usuarios acceden al sitio
en mysite.contoso.com , debe registrar un SPN de http/mysite.contoso.com en la cuenta
gMSA.

Algunas aplicaciones pueden requerir SPN adicionales para sus protocolos únicos. Por
ejemplo, SQL Server requiere el SPN de MSSQLSvc/hostname .

En la tabla siguiente se enumeran los atributos necesarios para crear una gMSA.

ﾉ Expandir tabla
 Propiedad gMSA Valor Ejemplo
obligatorio

Nombre Cualquier WebApp01

nombre de
cuenta válido.

DnsHostName Nombre de WebApp01.contoso.com

dominio
anexado al
nombre de
cuenta.

ServicePrincipalNames Establezca al 'host/WebApp01',

menos el SPN 'host/WebApp01.contoso.com'
de host y
agregue otros
protocolos
según sea
necesario.

PrincipalsAllowedToRetrieveManagedPassword El grupo de WebApp01Hosts

seguridad que
contiene los
hosts de
contenedor.

Una vez que haya decidido el nombre de la gMSA, ejecute los siguientes cmdlets en
PowerShell para crear el grupo de seguridad y gMSA.

 Sugerencia

Tendrá que usar una cuenta que pertenezca al grupo de seguridad de

administradores de dominio o que tenga delegado el permiso Crear objetos
msDS-GroupManagedServiceAccount para ejecutar los siguientes comandos. El
cmdlet New-ADServiceAccount forma parte de las herramientas de PowerShell de
AD de Herramientas de administración remota del servidor.

Se recomienda crear cuentas de gMSA independientes para los entornos de desarrollo,

prueba y producción.

Caso de uso para crear una cuenta de gMSA para hosts

de contenedor unidos a un dominio
PowerShell
 # Replace 'WebApp01' and 'contoso.com' with your own gMSA and domain names,
respectively.

# To install the AD module on Windows Server, run Install-WindowsFeature

RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-
WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-
LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see
https://aka.ms/rsat

# Create the security group

New-ADGroup -Name "WebApp01 Authorized Hosts" -SamAccountName
"WebApp01Hosts" -GroupScope DomainLocal

# Create the gMSA

New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.contoso.com" -
ServicePrincipalNames "host/WebApp01", "host/WebApp01.contoso.com" -
PrincipalsAllowedToRetrieveManagedPassword "WebApp01Hosts"

# Add your container hosts to the security group

Add-ADGroupMember -Identity "WebApp01Hosts" -Members "ContainerHost01$",
"ContainerHost02$", "ContainerHost03$"

Caso de uso para crear una cuenta de gMSA para hosts

de contenedor no unidos a un dominio
Al usar gMSA para contenedores con hosts no unidos a un dominio, en lugar de agregar
hosts de contenedor al grupo de seguridad WebApp01Hosts , cree y agregue una cuenta
de usuario estándar.

PowerShell

# Replace 'WebApp01' and 'contoso.com' with your own gMSA and domain names,
respectively.

# To install the AD module on Windows Server, run Install-WindowsFeature

RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-
WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-
LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see
https://aka.ms/rsat

# Create the security group

New-ADGroup -Name "WebApp01 Authorized Accounts" -SamAccountName
"WebApp01Accounts" -GroupScope DomainLocal

# Create the gMSA

New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.contoso.com" -
 ServicePrincipalNames "host/WebApp01", "host/WebApp01.contoso.com" -
PrincipalsAllowedToRetrieveManagedPassword "WebApp01Accounts"

# Create the standard user account. This account information needs to be

stored in a secret store and will be retrieved by the ccg.exe hosted plug-in
to retrieve the gMSA password. Replace 'StandardUser01' and 'p@ssw0rd' with
a unique username and password. We recommend using a random, long, machine-
generated password.
New-ADUser -Name "StandardUser01" -AccountPassword (ConvertTo-SecureString -
AsPlainText "p@ssw0rd" -Force) -Enabled 1

# Add your container hosts to the security group

Add-ADGroupMember -Identity "WebApp01Accounts" -Members "StandardUser01"

Preparación del host de contenedor

Caso de uso para preparar el host de contenedor para un

host de contenedor unido a un dominio
Cada host de contenedor que ejecutará un contenedor de Windows con una gMSA
debe estar unido a un dominio y tener acceso para recuperar la contraseña de gMSA.

1. Une el equipo al dominio de Active Directory.

2. Asegúrese de que el host pertenece al grupo de seguridad que controla el acceso

a la contraseña de gMSA.

3. Reinicie el equipo para obtener su nueva pertenencia al grupo.

4. Configure Docker Desktop para Windows 10 o Docker Desktop para

Windows Server .

5. (Recomendado) Compruebe que el host puede usar la cuenta de gMSA ejecutando

Test-ADServiceAccount. Si el comando devuelve False, siga las instrucciones de
solución de problemas de .

PowerShell

# To install the AD module on Windows Server, run Install-

WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run
Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-
LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see
https://aka.ms/rsat
 Test-ADServiceAccount WebApp01

Caso de uso para preparar el host de contenedor para un

host de contenedor que no esté unido a un dominio
Al usar gMSA para contenedores de Windows en hosts de contenedor no unidos a un
dominio, cada host de contenedor debe tener un complemento para ccg.exe instalado,
que se usará para recuperar la cuenta de usuario portátil y las credenciales especificadas
en el paso anterior. Los complementos son exclusivos del almacén de secretos utilizado
para proteger las credenciales de cuentas de usuario portátiles. Por ejemplo, se
necesitarían complementos diferentes para almacenar las credenciales de cuenta en
Azure Key Vault frente a en un almacén de secretos de Kubernetes.

Windows no ofrece actualmente un complemento predeterminado integrado. Las

instrucciones de instalación de los complementos serán específicas de la
implementación. Para obtener más información sobre cómo crear y registrar
complementos para ccg.exe, consulte interfaz ICcgDomainAuthCredentials.

Creación de una especificación de credenciales

Un archivo de especificación de credenciales es un documento JSON que contiene
metadatos sobre las cuentas de gMSA que desea que use un contenedor. Al mantener
la configuración de identidad independiente de la imagen de contenedor, puede
cambiar qué gMSA usa el contenedor simplemente intercambiando el archivo de
especificación de credenciales, no es necesario realizar ningún cambio en el código.

El archivo de especificación de credenciales se crea mediante el módulo de PowerShell

credentialSpec de en una máquina unida a un dominio. Una vez creado el archivo,
puede copiarlo en otros hosts de contenedor o en el orquestador de contenedores. El
archivo de especificación de credenciales no contiene ningún secreto, como la
contraseña de gMSA, ya que el host del contenedor recupera la gMSA en nombre del
contenedor.

Docker espera encontrar el archivo de especificación de credenciales en el directorio

CredentialSpecs en el directorio de datos de Docker. En una instalación
predeterminada, encontrará esta carpeta en C:\ProgramData\Docker\CredentialSpecs .

Para crear un archivo de especificación de credenciales en el host de contenedor:

1. Instalación de las herramientas de PowerShell de RSAT AD

 Para Windows Server, ejecute Install-WindowsFeature RSAT-AD-PowerShell.
Para Windows 10, versión 1809 o posterior, ejecute Add-WindowsCapability
-Online -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~0.0.1.0".
Para versiones anteriores de Windows 10, consulta https://aka.ms/rsat .

2. Ejecute el siguiente cmdlet para instalar la versión más reciente del módulo
CredentialSpec de PowerShell :

PowerShell

Install-Module CredentialSpec

Si no tiene acceso a Internet en el host de contenedor, ejecute Save-Module

CredentialSpec en un equipo conectado a Internet y copie la carpeta del módulo

en C:\Program Files\WindowsPowerShell\Modules o en otra ubicación en

$env:PSModulePath en el host del contenedor.

3. Ejecute el siguiente cmdlet para crear el nuevo archivo de especificación de

credenciales:

PowerShell

# Replace 'WebApp01' with your own gMSA

New-CredentialSpec -AccountName WebApp01

De forma predeterminada, el cmdlet creará una especificación de credenciales con

el nombre de gMSA proporcionado como la cuenta de equipo del contenedor. El
archivo se guardará en el directorio CredentialSpecs de Docker, utilizando el
dominio gMSA y el nombre de cuenta como nombre de archivo.

Si desea guardar el archivo en otro directorio, use el parámetro -Path :

PowerShell

New-CredentialSpec -AccountName WebApp01 -Path

"C:\MyFolder\WebApp01_CredSpec.json"

También puede crear una especificación de credenciales que incluya cuentas de

gMSA adicionales si ejecuta un servicio o proceso como una gMSA secundaria en
el contenedor. Para ello, use el parámetro -AdditionalAccounts :

PowerShell
 New-CredentialSpec -AccountName WebApp01 -AdditionalAccounts
LogAgentSvc, OtherSvc

Para obtener una lista completa de los parámetros admitidos, ejecute Get-Help
New-CredentialSpec -Full .

4. Puede mostrar una lista de todas las especificaciones de credenciales y su ruta de

acceso completa con el siguiente cmdlet:

PowerShell

Get-CredentialSpec

Este es un ejemplo de una especificación de credenciales:

JSON

{
"CmsPlugins": [
"ActiveDirectory"
],
"DomainJoinConfig": {
"Sid": "S-1-5-21-702590844-1001920913-2680819671",
"MachineAccountName": "webapp01",
"Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
"DnsTreeName": "contoso.com",
"DnsName": "contoso.com",
"NetBiosName": "CONTOSO"
},
"ActiveDirectoryConfig": {
"GroupManagedServiceAccounts": [
{
"Name": "webapp01",
"Scope": "contoso.com"
},
{
"Name": "webapp01",
"Scope": "CONTOSO"
}
]
}
}

Configuración adicional de la especificación de

credenciales para el caso de uso del host de contenedor
no unido a un dominio
Al usar gMSA con hosts de contenedor no unidos a un dominio, es necesario agregar
información sobre el complemento de ccg.exe que va a usar a la especificación de
credenciales. Esto se agregará a una sección de la especificación de credenciales
denominada HostAccountConfig. La sección hostAccountConfig tiene tres campos que
deben rellenarse:

PortableCcgVersion: debe establecerse en "1".

PluginGUID: CLSID COM para el complemento ccg.exe. Esto es único para el
complemento que se está usando.
PluginInput: entrada específica del complemento para recuperar la información de
la cuenta de usuario del almacén de secretos.

Este es un ejemplo de una especificación de credenciales con la sección

hostAccountConfig agregada:

JSON

{
"CmsPlugins": [
"ActiveDirectory"
],
"DomainJoinConfig": {
"Sid": "S-1-5-21-702590844-1001920913-2680819671",
"MachineAccountName": "webapp01",
"Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
"DnsTreeName": "contoso.com",
"DnsName": "contoso.com",
"NetBiosName": "CONTOSO"
},
"ActiveDirectoryConfig": {
"GroupManagedServiceAccounts": [
{
"Name": "webapp01",
"Scope": "contoso.com"
},
{
"Name": "webapp01",
"Scope": "CONTOSO"
}
],
"HostAccountConfig": {
"PortableCcgVersion": "1",
"PluginGUID": "{GDMA0342-266A-4D1P-831J-20990E82944F}",
"PluginInput": "contoso.com:gmsaccg:<password>"
}
}
}
Pasos siguientes
Ahora que ha configurado la cuenta de gMSA, puede usarla para:

Configurar aplicaciones
Ejecución de contenedores
Gestionar contenedores

Si tiene algún problema durante la instalación, consulte nuestra guía de solución de

problemas de para ver posibles soluciones.

Recursos adicionales
Para más información sobre las gMSA, vea la Información general de las cuentas
de servicio administradas de grupo.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Configuración de una aplicación para
usar una gMSA
Artículo • 21/03/2023

Se aplica a: Windows Server 2022, Windows Server 2019

En la configuración típica, un contenedor solo recibe una cuenta de servicio

administrada de grupo (gMSA) que se usa siempre que la cuenta de equipo del
contenedor intenta autenticarse en los recursos de red. Es decir, la aplicación tendrá que
ejecutarse como sistema local o servicio de red si tiene que usar la identidad de la
gMSA. Los contenedores también se pueden configurar con gMSA adicionales, en caso
de que quieras ejecutar un servicio o una aplicación en el contenedor con una identidad
diferente de la cuenta de equipo del contenedor.

Ejecución un grupo de aplicaciones de IIS como

servicio de red
Si hospedas un sitio web de IIS en el contenedor, lo único que tienes que hacer para
aprovechar la gMSA es establecer la identidad del grupo de aplicaciones en Servicio de
red. Puedes hacerlo en el Dockerfile agregando el comando siguiente:

Dockerfile

RUN %windir%\system32\inetsrv\appcmd.exe set AppPool DefaultAppPool -

'processModel.identityType':NetworkService

Si anteriormente usaste credenciales de usuario estáticas para el grupo de aplicaciones

de IIS, considera la gMSA como el reemplazo de esas credenciales. Puedes cambiar la
gMSA entre los entornos de desarrollo, pruebas y producción, e IIS recogerá
automáticamente la identidad actual sin tener que cambiar la imagen del contenedor.

Ejecución de un servicio de Windows como

servicio de red
Si la aplicación en contenedor se ejecuta como servicio de Windows, puedes configurar
el servicio para que se ejecute como Servicio de red en Dockerfile:

Dockerfile
 RUN sc.exe config "YourServiceName" obj= "NT AUTHORITY\NETWORK SERVICE"
password= ""

Ejecución de aplicaciones de consola arbitrarias

como servicio de red
En el caso de las aplicaciones de consola genéricas que no se hospedan en IIS ni en
Service Manager, a menudo es más fácil ejecutar el contenedor como Servicio de red,
por lo que la aplicación hereda automáticamente el contexto de la gMSA. Esta
característica está disponible a partir de Windows Server, versión 1709.

Agrega la siguiente línea a Dockerfile para que se ejecute como servicio de red de forma
predeterminada:

Dockerfile

USER "NT AUTHORITY\NETWORK SERVICE"

También puedes conectarte a un contenedor como servicio de red de forma única con
docker exec . Esto es especialmente útil si estás solucionando problemas de

conectividad en un contenedor en ejecución cuando el contenedor no se ejecuta

normalmente como servicio de red.

PowerShell

# Opens an interactive PowerShell console in the container (id = 85d) as the

Network Service account
docker exec -it --user "NT AUTHORITY\NETWORK SERVICE" 85d powershell

Pasos siguientes
Además de la configuración de aplicaciones, también puedes usar las gMSA para lo
siguiente:

Ejecución de contenedores
Orquestación de contenedores

Si tienes problemas durante la instalación, consulta nuestra guía de solución de

problemas para ver las posibles soluciones.
Ejecución de un contenedor con una gMSA
Artículo • 14/04/2025

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

Para ejecutar un contenedor con una cuenta de servicio administrada de grupo (gMSA),
proporcione el archivo de especificación de credenciales al parámetro --security-opt de
docker run :

PowerShell

docker run --security-opt "credentialspec=file://contoso_webapp01.json" --hostname

webapp01 -it mcr.microsoft.com/windows/server:ltsc2022 powershell

） Importante

En las versiones 1709 y 1803 de Windows Server 2016, el nombre de host del contenedor
debe coincidir con el nombre corto de gMSA.

En el ejemplo anterior, el nombre de cuenta sam de gMSA es webapp01, por lo que el nombre
de host del contenedor también se denomina webapp01.

En Windows Server 2019 y versiones posteriores, el campo nombre de host no es necesario,

pero el contenedor se seguirá identificando por el nombre de gMSA en lugar del nombre de
host, incluso si se proporciona explícitamente otro.

Para comprobar si la gMSA funciona correctamente, ejecute el siguiente cmdlet en el

contenedor:

PowerShell

# Replace contoso.com with your own domain

PS C:\> nltest /sc_verify:contoso.com

Flags: b0 HAS_IP HAS_TIMESERV

Trusted DC Name \\dc01.contoso.com
Trusted DC Connection Status Status = 0 0x0 NERR_Success
Trust Verification Status = 0 0x0 NERR_Success
The command completed successfully

Si Trusted DC Connection Status y Trust Verification Status no son NERR_Success , sigue las
instrucciones de solución de problemas para depurar el problema.
Para comprobar la identidad de gMSA desde el contenedor, ejecute el comando siguiente y
compruebe el nombre del cliente:

PowerShell

PS C:\> klist get webapp01

Current LogonId is 0:0xaa79ef8

A ticket to krbtgt has been retrieved successfully.

Cached Tickets: (2)

#0> Client: webapp01$ @ CONTOSO.COM

Server: krbtgt/webapp01 @ CONTOSO.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent
name_canonicalize
Start Time: 3/21/2019 4:17:53 (local)
End Time: 3/21/2019 14:17:53 (local)
Renew Time: 3/28/2019 4:17:42 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: dc01.contoso.com

[...]

Para abrir PowerShell u otra aplicación de consola como la cuenta de gMSA, puede pedir al
contenedor que se ejecute en la cuenta de servicio de red en lugar de la cuenta normal
ContainerAdministrator (o ContainerUser para NanoServer):

PowerShell

# NOTE: you can only run as Network Service or SYSTEM on Windows Server 1709 and
later
docker run --security-opt "credentialspec=file://contoso_webapp01.json" --hostname
webapp01 --user "NT AUTHORITY\NETWORK SERVICE" -it
mcr.microsoft.com/windows/servercore:ltsc2019 powershell

Cuando se ejecuta como servicio de red, puede probar la autenticación de red como gMSA
intentando conectarse a SYSVOL en un controlador de dominio:

PowerShell

# This command should succeed if you're successfully running as the gMSA

PS C:\> dir \\contoso.com\SYSVOL

Directory: \\contoso.com\sysvol
 Mode LastWriteTime Length Name
---- ------------- ------ ----
d----l 2/27/2019 8:09 PM contoso.com

Contenido relacionado
Además de ejecutar contenedores, también puede usar gMSA para:

Configurar aplicaciones
Orquestación de contenedores
Con gMSA en el Servicio de Kubernetes de Azure

Si tiene algún problema durante la instalación, consulte nuestra guía de solución de problemas
de para ver posibles soluciones.
Orquestación de contenedores con una
gMSA
Artículo • 05/02/2025

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

En entornos de producción, a menudo usará un orquestador de contenedores, como el

servicio de Kubernetes hospedado, Azure Kubernetes Service (AKS), para implementar y
administrar las aplicaciones y los servicios de clúster. Cada orquestador tiene sus
propios paradigmas de administración y es responsable de aceptar especificaciones de
credenciales para proporcionar a la plataforma de contenedor de Windows.

Al orquestar contenedores con Cuentas de Servicio Administradas de Grupo (gMSAs),

asegúrese de que:

＂ Todos los hosts de contenedor que se pueden programar para ejecutar

contenedores con gMSA están unidos a un dominio
＂ Los anfitriones de contenedores tienen acceso para recuperar las contraseñas de
todos los gMSA utilizados por los contenedores.
＂ Los archivos de especificación de credenciales se crean y cargan en el orquestador
o se copian en cada host de contenedor, en función de cómo prefiera el
orquestador controlarlos.
＂ Las redes de contenedores permiten que los contenedores se comuniquen con los
controladores de dominio de Active Directory para obtener tickets gMSA.

Uso de gMSA con Kubernetes

Puede usar gMSA con AKS y también con AKS en Azure Stack HCI, que es la
implementación local del orquestador de AKS. Para más información sobre cómo usar
gMSA con Kubernetes, consulte Uso de gMSA en Azure Kubernetes Service en
contenedores de Windows y Configuración de una cuenta de servicio administrada de
grupo con AKS en Azure Stack HCI.

Para leer la información más reciente del sector sobre esta característica, vea
Configuración de gMSA para contenedores y pods de Windows .

Uso de gMSA con Service Fabric

Service Fabric admite la ejecución de contenedores de Windows con una gMSA al
especificar la ubicación de especificación de credenciales en el manifiesto de aplicación.
Deberá crear el archivo de especificación de credenciales y colocarlo en el
CredentialSpecs subdirectorio del directorio de datos de Docker en cada host para que
Service Fabric pueda localizarlo. Puede ejecutar el cmdlet Get-CredentialSpec, parte del
módulo de PowerShell CredentialSpec , para comprobar si la especificación de
credenciales está en la ubicación correcta.

Consulte Inicio rápido: Implementación de contenedores de Windows en Service Fabric

y Configuración de gMSA para contenedores de Windows que se ejecutan en Service
Fabric para obtener más información sobre cómo configurar la aplicación.

Uso de gMSA con Docker Swarm

Para usar una gMSA con contenedores administrados por Docker Swarm, ejecute el
comando docker service create con el parámetro --credential-spec :

PowerShell

docker service create --credential-spec "file://contoso_webapp01.json" --

hostname "WebApp01" <image name>

Consulte el ejemplo de Docker Swarm para obtener más información sobre cómo usar
las especificaciones de credenciales con los servicios de Docker.

Contenido relacionado
Además de orquestar contenedores, también puede usar gMSA para:

Configurar aplicaciones
Ejecución de contenedores

Si tiene algún problema durante la instalación, consulte nuestra guía de solución de

problemas de para ver posibles soluciones.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Configuración de cuentas de servicio
administradas de grupo (gMSA) para
contenedores de Windows con Azure
Kubernetes Service en Windows Server
Artículo • 23/04/2025

Se aplica a: AKS en Windows Server

Para usar la autenticación de AD, puede configurar cuentas de servicio administradas de grupo
(gMSA) para contenedores Windows para que se ejecuten con un host que no está unido a un
dominio. Una cuenta de servicio administrada de grupo es un tipo especial de cuenta de
servicio que se introdujo en Windows Server 2012 y se ha diseñado para que varios equipos
compartan una identidad sin conocer la contraseña. Los contenedores de Windows no pueden
unirse a un dominio, pero muchas aplicaciones de Windows que se ejecutan en contenedores
de Windows siguen necesitando autenticación de AD.

７ Nota

Para información sobre cómo la comunidad de Kubernetes admite el uso de gMSA con
contenedores de Windows, consulte Configuración de gMSA .

Arquitectura de gMSA para contenedores con un

host no unido a un dominio
gMSA para contenedores con un host no unido a un dominio usa una identidad de usuario
portable en lugar de una identidad de host para recuperar las credenciales de gMSA. Por lo
tanto, ya no es necesario unir manualmente los nodos de trabajo de Windows a un dominio. La
identidad del usuario se guarda como un secreto en Kubernetes. En el diagrama siguiente se
muestra el proceso para configurar gMSA para contenedores con un host no unido a un
dominio:
gMSA para contenedores con un host no unido a un dominio proporciona flexibilidad para
crear contenedores con gMSA sin unir el nodo de host al dominio. A partir de Windows Server
2019, se admite ccg.exe, lo que permite que un mecanismo de complemento recupere las
credenciales de gMSA de Active Directory. Puede usar esa identidad para iniciar el contenedor.
Para más información sobre ccg.exe, vea Interfaz ICcgDomainAuthCredentials.

Comparación de gMSA para contenedores con un

host no unido a un dominio y un host unido a un
dominio
Cuando se introdujo gMSA, era necesario unir el host contenedor a un dominio, lo que
generaba una importante sobrecarga para unir los nodos de trabajo de Windows a un
dominio. Esta limitación se ha solucionado con gMSA para contenedores con un host no unido
a un dominio, por lo que los usuarios ahora pueden usar gMSA con hosts no unidos a un
dominio. Otras mejoras de gMSA incluyen las siguientes características:

Eliminación del requisito de unir manualmente nodos de trabajo de Windows a un

dominio, que suponía una importante sobrecarga. Para escenarios de escalado, esto
simplifica el proceso.
En escenarios de actualización gradual, los usuarios ya no tienen que volver a unir el
nodo a un dominio.
Un proceso más sencillo para administrar la máquina de nodos de trabajo consiste en
recuperar las contraseñas de las cuentas de servicio gMSA.
Un proceso integral menos complicado para configurar cuentas gMSA con Kubernetes.
Antes de empezar
Para ejecutar un contenedor de Windows con una cuenta de servicio administrada de grupo,
necesita los siguientes requisitos previos:

Un dominio de Active Directory con al menos un controlador de dominio que ejecute

Windows Server 2012 o posterior. No existen requisitos de nivel funcional de bosque o
dominio para utilizar los gMSA, pero solo los controladores de dominio que ejecutan
Windows Server 2012 o posterior pueden distribuir contraseñas de gMSA. Para más
información, consulta Requisitos de Active Directory para gMSA.
Permiso para crear una cuenta gMSA. Para crear una cuenta de gMSA, debe ser
administrador de dominio o usar una cuenta que tenga permisos para crear objetos
msDS-GroupManagedServiceAccount .
Acceda a Internet para descargar el módulo CredentialSpec de PowerShell. Si trabajas
en un entorno desconectado, puedes guardar el módulo en un equipo con acceso a
Internet y copiarlo en la máquina de desarrollo o en el host de contenedor.
Para garantizar que la autenticación de gMSA y AD funcione, asegúrese de que los nodos
del clúster de Windows Server están configurados para sincronizar su tiempo con un
controlador de dominio u otro origen de hora. También debe asegurarse de que Hyper-V
está configurado para sincronizar la hora con cualquier máquina virtual.

Preparación de la cuenta de gMSA en el

controlador de dominio
Siga estos pasos para preparar la gMSA en el controlador de dominio:

1. En el controlador de dominio, prepare Active Directory y cree la cuenta de gMSA.

2. Cree una cuenta de usuario de dominio. Estas credenciales de contraseña o cuenta de

usuario se guardan como un secreto de Kubernetes y se usan para recuperar la
contraseña de gMSA.

3. Para crear una cuenta de GMSA y conceder permiso de lectura de la contraseña para la
cuenta de gMSA creada en el paso 2, ejecute el siguiente comando New-
ADServiceAccount de PowerShell:

PowerShell

New-ADServiceAccount -Name "<gmsa account name>" -DnsHostName "<gmsa account

name>.<domain name>.com" -ServicePrincipalNames "host/<gmsa account name>",
"host/<gmsa account name>.<domain name>.com" -
PrincipalsAllowedToRetrieveManagedPassword <username you created earlier>
 Para -PrincipalsAllowedToRetrieveManagedPassword , especifique el nombre de usuario de
dominio que creó anteriormente como se muestra en el ejemplo siguiente:

PowerShell

New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.akshcitest.com"

-ServicePrincipalNames "host/WebApp01", "host/WebApp01.akshcitest.com" -
PrincipalsAllowedToRetrieveManagedPassword "testgmsa"

Preparación del archivo JSON de especificación de

credenciales de gMSA
Para preparar el archivo JSON de especificación de credenciales de gMSA, siga los pasos sobre
la creación de una especificación de credenciales.

Configurar gMSA para pods y contenedores de

Windows en el clúster
La comunidad de Kubernetes ya admite los nodos de trabajo de Windows unidos a un dominio
para gMSA . Aunque no es necesario unir a dominio un nodo de trabajador de Windows en
AKS en Windows Server, hay otros pasos de configuración necesarios. Estos pasos incluyen la
instalación del webhook, la definición de recursos personalizados (CRD) y la especificación de
credenciales y la habilitación del control de acceso basado en rol (rol RBAC). En los pasos
siguientes se usan comandos de PowerShell que se han creado para ayudar a simplificar el
proceso de configuración.

Antes de completar los pasos siguientes, asegúrese de que el módulo de PowerShell de

AksHci está instalado y kubectl puede conectarse al clúster.

1. Para instalar el webhook, ejecute el siguiente comando Install-AksHciGmsaWebhook de

PowerShell:

PowerShell

Install-AksHciGMSAWebhook -Name <cluster name>

Para comprobar que el pod de webhook se está ejecutando correctamente, utilice el

comando siguiente:

PowerShell
 kubectl get pods -n kube-system | findstr gmsa

Deberías ver un pod con el prefijo gmsa-webhook que se está ejecutando.

2. Cree el objeto secreto que almacena la credencial de usuario de Active Directory.

Complete los siguientes datos de configuración y guarde la configuración en un archivo
denominado secret.yaml.

YAML

apiVersion: v1
kind: Secret
metadata:
name: <secret-name>
namespace: <secret under namespace other than the default>
type: Opaque
stringData:
domain: <FQDN of the domain, for example: akshcitest.com>
username: <domain user who can retrieve the gMSA password>
password: <password>

Después ejecute el siguiente comando para crear el objeto de secreto:

PowerShell

kubectl apply -f secret.yaml

７ Nota

Si crea un secreto en un espacio de nombres distinto al predeterminado, no olvide

establecer el espacio de nombres de la implementación en el mismo espacio de
nombres.

3. Utilice el cmdlet de PowerShell Add-AksHciGMSACredentialSpec para crear el CRD de

gMSA, activar el control de acceso basado en funciones (RBAC) y, a continuación, asignar
la función a las cuentas de servicio para utilizar un archivo específico de especificaciones
de credenciales de gMSA. Estos pasos se describen con más detalle en el artículo de
Kubernetes Configuración de gMSA para contenedores y pods de Windows .

Use la especificación de credenciales JSON como entrada para el siguiente comando de

PowerShell (los parámetros con asteriscos * son obligatorios):

PowerShell
 Add-AksHciGMSACredentialSpec -Name <cluster name>*
-credSpecFilePath <path to JSON credspec>*
-credSpecName <name for credspec as the k8s GMSACredentialSpec object>*
-secretName <name of secret>*
-secretNamespace <namespace of secret>
-serviceAccount <name of service account to bind to clusterrole>
-clusterRoleName <name of clusterrole to use the credspec>*
-overwrite

Para ver un ejemplo, consulte el código siguiente:

PowerShell

Add-AksHciGMSACredentialSpec -Name mynewcluster

-credSpecFilePath .\credspectest.json
-credSpecName credspec-mynewcluster
-secretName mysecret
-clusterRoleName clusterrole-mynewcluster

Implementación de la aplicación
Cree el archivo YAML de implementación con la siguiente configuración de ejemplo. Las
entradas necesarias incluyen serviceAccountName , gmsaCredentialSpecName , volumeMounts y
dnsconfig .

1. Agregue la cuenta de servicio:

YAML

serviceAccountName: default
securityContext:
windowsOptions:
gmsaCredentialSpecName:

2. Agregue el objeto de especificación de credenciales:

YAML

securityContext:
windowsOptions:
gmsaCredentialSpecName: <cred spec name>

3. Instale el secreto para la implementación:

YAML
 volumeMounts:
- name: <volume name>
mountPath: <vmount path>
readOnly: true
volumes:
- name: <volume name>
secret:
secretName: <secret name>
items:
- key: username
path: my-group/my-username

4. Agregue la dirección IP del controlador de dominio y el nombre de dominio en

dnsConfig:

YAML

dnsConfig:
nameservers:
- <IP address for domain controller>
searches:
- <domain>

Comprobación del funcionamiento del contenedor

con gMSA
Después de implementar el contenedor, compruebe su funcionamiento mediante los pasos
siguientes:

1. Obtenga el id. de contenedor para la implementación mediante la ejecución del siguiente

comando:

Consola

kubectl get pods

2. Abra PowerShell y ejecute el siguiente comando:

PowerShell

kubectl exec -it <container id> powershell

3. Una vez que esté en el contenedor, ejecute el siguiente comando:

 Consola

Nltest /parentdomain
Nltest /sc_verify:<domain>

Resultados

Connection Status = 0 0x0 NERR_Success The command completed successfully.

Esta salida muestra que un controlador de dominio ha autenticado el equipo y existe un

canal seguro entre el equipo cliente y el controlador de dominio.

4. Compruebe si el contenedor puede obtener un servicio de concesión de vales (TGT) de

Kerberos válido.

Consola

klist get krbtgt

Resultados

A ticket to krbtgt has been retrieved successfully

Limpieza de la configuración de gMSA del clúster

Si necesita limpiar la configuración de gMSA, siga estos pasos de desinstalación.

Desinstalación de la especificación de credenciales

Para desinstalarla, ejecute el siguiente comando Remove-AksHcigmsaCredentialSpec de
PowerShell:

PowerShell

Remove-AksHciGMSACredentialSpec -Name <cluster name> -credSpecName <cred spec

object name> -clusterRoleName <clusterrole object name> -serviceAccount
<serviceaccount object name> -secretNamespace <namespace of the secret object>

Desinstalación de webhook
Para desinstalar el webhook, ejecute el siguiente comando Uninstall-AksHciGMSAWebhook de
PowerShell:

PowerShell

Uninstall-AksHciGMSAWebhook -Name <cluster name>

Pasos siguientes
Uso del volumen persistente en un clúster de Kubernetes
Supervisión de AKS en clústeres de Windows Server
Solución de problemas de gMSA para
contenedores de Windows
Artículo • 06/03/2025

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

Problemas conocidos

El nombre de host del contenedor debe coincidir con el

nombre de gMSA para Windows Server 2016 y Windows
10, versiones 1709 y 1803
Si ejecuta Windows Server 2016, versión 1709 o 1803, el nombre de host del contenedor
debe coincidir con el nombre de cuenta sam de gMSA.

Cuando el nombre de host no coincide con el nombre de gMSA, se producirá un error

en las solicitudes de autenticación NTLM entrantes y la traducción de nombre/SID (que
usan muchas bibliotecas, como el proveedor de roles de pertenencia ASP.NET). Kerberos
seguirá funcionando normalmente aunque el nombre de host y el nombre de gMSA no
coincidan.

Esta limitación se corrigió en Windows Server 2019, donde el contenedor ahora siempre
usará su nombre gMSA en la red independientemente del nombre de host asignado.

No puede usar gMSA con contenedores aislados Hyper-V

en las versiones 1703, 1709 y 1803 de Windows 10
La inicialización del contenedor se bloqueará o producirá un error al intentar usar una
gMSA con un contenedor aislado de Hyper-V en Windows 10 y Windows Server
versiones 1703, 1709 y 1803.

Este error se corrigió en Windows Server 2019 y Windows 10, versión 1809. También
puede ejecutar contenedores aislados Hyper-V con gMSA en Windows Server 2016 y
Windows 10, versión 1607.

Guía general de solución de problemas

Si se producen errores al ejecutar un contenedor con una gMSA, las instrucciones
siguientes pueden ayudarle a identificar la causa principal.

Hosts unidos a un dominio: asegúrese de que el host

puede usar gMSA
1. Compruebe que el host está unido a un dominio y puede acceder al controlador
de dominio.

2. Instale las herramientas de PowerShell de AD desde RSAT y ejecute Test-

ADServiceAccount para ver si el equipo tiene acceso para recuperar la gMSA. Si el
cmdlet devuelve False, el equipo no tiene acceso a la contraseña de gMSA.

PowerShell

# To install the AD module on Windows Server, run Install-

WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run
Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-
LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see
https://aka.ms/rsat

Test-ADServiceAccount WebApp01

3. Si test-ADServiceAccount devuelve False, compruebe que el host pertenece a un

grupo de seguridad que pueda acceder a la contraseña de gMSA.

PowerShell

# Get the current computer's group membership

Get-ADComputer $env:computername | Get-ADPrincipalGroupMembership |
Select-Object DistinguishedName

# Get the groups allowed to retrieve the gMSA password

# Change "WebApp01" for your own gMSA name
(Get-ADServiceAccount WebApp01 -Properties
PrincipalsAllowedToRetrieveManagedPassword).PrincipalsAllowedToRetrieve
ManagedPassword

4. Si tu host pertenece a un grupo de seguridad autorizado para recuperar la

contraseña de gMSA, pero sigue fallando en la prueba Test-ADServiceAccount, es
posible que debas reiniciar el ordenador para obtener un nuevo ticket que refleje
sus membresías actuales de grupo.
Hosts no unidos a un dominio: asegúrese de que el host
está configurado para recuperar la cuenta de gMSA.
Compruebe que un complemento para usar gMSA con un host de contenedor no unido
a un dominio esté instalado correctamente en el host. Windows no incluye un
complemento integrado y requiere que proporcione un complemento que implemente
la interfaz ICcgDomainAuthCredentials. Los detalles de instalación serán específicos del
complemento.

Revisa el archivo de especificación de credenciales

1. Ejecute Get-CredentialSpec desde el módulo de PowerShell CredentialSpec para
buscar todas las especificaciones de credenciales en la máquina. Las
especificaciones de credenciales deben almacenarse en el directorio
"CredentialSpecs" en el directorio raíz de Docker. Para encontrar el directorio raíz
de Docker, ejecute docker info -f "{{.DockerRootDir}}".

2. Abra el archivo CredentialSpec y asegúrese de que los campos siguientes se

rellenan correctamente:

a. Para hosts de contenedor unidos a un dominio:

sid: el SID del dominio

MachineAccountName: gMSA SAM Account Name (no incluya el nombre
de dominio completo ni el signo de dólar).
DnsTreeName: FQDN del bosque de Active Directory
DnsName: el FQDN del dominio al que pertenece la gMSA
NetBiosName: nombre NETBIOS para el dominio al que pertenece la
gMSA
GroupManagedServiceAccounts/Name: el nombre de la cuenta SAM de
gMSA (no incluya el nombre de dominio completo ni el signo de dólar).
GroupManagedServiceAccounts/Scope: una entrada para el FQDN del
dominio y otra para NETBIOS

La entrada debe tener un aspecto similar al ejemplo siguiente de una

especificación de credenciales completa:

JSON

{
"CmsPlugins": [
"ActiveDirectory"
],
"DomainJoinConfig": {
 "Sid": "S-1-5-21-702590844-1001920913-2680819671",
"MachineAccountName": "webapp01",
"Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
"DnsTreeName": "contoso.com",
"DnsName": "contoso.com",
"NetBiosName": "CONTOSO"
},
"ActiveDirectoryConfig": {
"GroupManagedServiceAccounts": [
{
"Name": "webapp01",
"Scope": "contoso.com"
},
{
"Name": "webapp01",
"Scope": "CONTOSO"
}
]
}
}

b. Para hosts no unidos a un dominio: Además de todos los campos host de

contenedor no unidos a un dominio, asegúrese de que la sección
"HostAccountConfig" está presente y de que los campos siguientes se definen
correctamente.

PortableCcgVersion: debe establecerse en "1".

PluginGUID: CLSID COM para el complemento ccg.exe. Esto es único para
el complemento que se está usando.
PluginInput: entrada específica del complemento para recuperar la
información de la cuenta de usuario del almacén de secretos.

La entrada debe tener un aspecto similar al ejemplo siguiente de una

especificación de credenciales completa:

JSON

{
"CmsPlugins": [
"ActiveDirectory"
],
"DomainJoinConfig": {
"Sid": "S-1-5-21-702590844-1001920913-2680819671",
"MachineAccountName": "webapp01",
"Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
"DnsTreeName": "contoso.com",
"DnsName": "contoso.com",
"NetBiosName": "CONTOSO"
},
"ActiveDirectoryConfig": {
 "GroupManagedServiceAccounts": [
{
"Name": "webapp01",
"Scope": "contoso.com"
},
{
"Name": "webapp01",
"Scope": "CONTOSO"
}
],
"HostAccountConfig": {
"PortableCcgVersion": "1",
"PluginGUID": "{GDMA0342-266A-4D1P-831J-20990E82944F}",
"PluginInput": "contoso.com:gmsaccg:<password>"
}
}
}

3. Compruebe que la ruta de acceso al archivo de especificación de credenciales es

correcta para la solución de orquestación. Si usa Docker, asegúrese de que el
comando container run incluye --security-
opt="credentialspec=file://NAME.json" , donde "NAME.json" se reemplaza por el

nombre de salida por Get-CredentialSpec. El nombre es un nombre de archivo

plano, en relación con la carpeta CredentialSpecs en el directorio raíz de Docker.

Comprobación de la configuración de red

Comprobación de la configuración del firewall

Si usa una directiva de firewall estricta en el contenedor o la red host, puede bloquear
las conexiones necesarias al controlador de dominio de Active Directory o al servidor
DNS.

ﾉ Expandir tabla

Protocolo y puerto Propósito

TCP y UDP 53 DNS (Sistema de Nombres de Dominio)

TCP y UDP 88 Kerberos

TCP 139 NetLogon

TCP y UDP 389 LDAP

TCP 636 LDAP SSL

Es posible que tenga que permitir el acceso a puertos adicionales en función del tipo de
tráfico que envía el contenedor a un controlador de dominio. Vea Requisitos de puertos
de Active Directory y Active Directory Domain Services para obtener una lista completa
de los puertos usados por Active Directory.

Comprobación de la configuración dns del host de contenedor

Si usa gMSA con un host de contenedor unido a un dominio, DNS debe configurarse
automáticamente en el host para que pueda resolver y establecer correctamente una
conexión con el dominio. Si usa gMSA con un host no unido a un dominio, esta
configuración no se establecerá automáticamente. Debe comprobar que la red host está
configurada para que pueda resolver el dominio. Puede comprobar que el dominio se
puede resolver desde el host mediante:

PowerShell

nltest /sc_verify:contoso.com

Comprobación del contenedor

1. Si ejecuta una versión de Windows anterior a Windows Server 2019 o Windows 10,
versión 1809, el nombre de host del contenedor debe coincidir con el nombre de
gMSA. Asegúrese de que el parámetro --hostname coincide con el nombre corto
de gMSA (sin componente de dominio; por ejemplo, "webapp01" en lugar de
"webapp01.contoso.com").

2. Compruebe la configuración de red del contenedor para comprobar que el

contenedor puede resolver y acceder a un controlador de dominio para el dominio
de gMSA. Los servidores DNS mal configurados en el contenedor son un culpable
común de los problemas de identidad.

3. Compruebe si el contenedor tiene una conexión válida al dominio mediante la

ejecución del siguiente cmdlet en el contenedor (mediante docker exec o un
equivalente):

PowerShell

nltest /sc_verify:contoso.com

La comprobación de confianza debe devolver NERR_SUCCESS si la gMSA está

disponible y la conectividad de red permite al contenedor comunicarse con el
 dominio. Si se produce un error, compruebe la configuración de red del host y el
contenedor. Ambos deben poder comunicarse con el controlador de dominio.

4. Compruebe si el contenedor puede obtener un vale de concesión de vales (TGT) de

Kerberos válido:

PowerShell

klist get <myapp>

Este comando debe devolver "Se ha recuperado correctamente un ticket a krbtgt"

y enumerar el controlador de dominio usado para recuperar el ticket. Si puede
obtener un TGT pero se produce un error en nltest del paso anterior, esto podría
ser una indicación de que la cuenta gMSA está mal configurada. Consulte y revise
la cuenta de gMSA para obtener más información.

Si no puede obtener un TGT dentro del contenedor, esto puede indicar problemas
de conectividad de red o DNS. Asegúrese de que el contenedor puede resolver un
controlador de dominio mediante el nombre DNS de dominio y que el controlador
de dominio es enrutable desde el contenedor.

5. Asegúrese de que la aplicación está configurada para usar la gMSA. La cuenta de

usuario dentro del contenedor no cambia cuando se usa una gMSA. En su lugar, la
cuenta del sistema usa la gMSA cuando se comunica con otros recursos de red.
Esto significa que la aplicación tendrá que ejecutarse como servicio de red o
sistema local para aprovechar la identidad de gMSA.

 Sugerencia

Si ejecutas whoami o utilizas otra herramienta para identificar tu contexto de

usuario actual en el contenedor, no verás el nombre del gMSA en sí. Esto se
debe a que siempre inicia sesión en el contenedor como un usuario local en
lugar de una identidad de dominio. La cuenta de computadora usa la gMSA
cada vez que se comunica con los recursos de red, por lo que la aplicación
debe ejecutarse como Servicio de Red o Sistema Local.

Comprobación de la cuenta de gMSA

1. Si el contenedor parece estar configurado correctamente, pero los usuarios u otros
servicios no se pueden autenticar automáticamente en la aplicación en
contenedor, compruebe los SPN en la cuenta de gMSA. Los clientes localizarán la
 cuenta de gMSA mediante el nombre con el que acceden a su aplicación. Esto
puede significar que necesitarán más host SPNs para su gMSA si, por ejemplo, los
clientes se conectan a su aplicación a través de un balanceador de carga o un
nombre DNS diferente.

2. Para usar gMSA con un host de contenedor unido a un dominio, asegúrese de que
la gMSA y el host de contenedor pertenecen al mismo dominio de Active
Directory. El host del contenedor no podrá recuperar la contraseña de gMSA si la
gMSA pertenece a un dominio diferente.

3. Asegúrese de que solo haya una cuenta en el dominio con el mismo nombre que
la gMSA. Los objetos gMSA tienen signos de dólar ($) anexados a sus nombres de
cuenta SAM, por lo que es posible que una gMSA se llame "myaccount$" y una
cuenta de usuario no relacionada denominada "myaccount" en el mismo dominio.
Esto puede causar problemas si el controlador de dominio o la aplicación tiene
que buscar la gMSA por nombre. Puede buscar en AD objetos con nombre similar
con el siguiente comando:

PowerShell

# Replace "GMSANAMEHERE" with your gMSA account name (no trailing

dollar sign)
Get-ADObject -Filter 'sAMAccountName -like "GMSANAMEHERE*"'

4. Si ha habilitado la delegación sin restricciones en la cuenta de gMSA, asegúrese de

que el atributo UserAccountControl todavía tiene habilitada la marca
WORKSTATION_TRUST_ACCOUNT . Esta bandera es necesaria para que NETLOGON del

contenedor se comunique con el controlador de dominio, como es el caso cuando

una aplicación tiene que resolver un nombre en un SID o viceversa. Puede
comprobar si la marca está configurada correctamente con los siguientes
comandos:

PowerShell

$gMSA = Get-ADServiceAccount -Identity 'yourGmsaName' -Properties

UserAccountControl
($gMSA.UserAccountControl -band 0x1000) -eq 0x1000

Si los comandos anteriores devuelven False , use lo siguiente para agregar la

marca WORKSTATION_TRUST_ACCOUNT a la propiedad UserAccountControl de la cuenta
de gMSA. Este comando también borrará las marcas NORMAL_ACCOUNT ,
INTERDOMAIN_TRUST_ACCOUNT y SERVER_TRUST_ACCOUNT de la propiedad

UserAccountControl.
 PowerShell

Set-ADObject -Identity $gMSA -Replace @{ userAccountControl =

($gmsa.userAccountControl -band 0x7FFFC5FF) -bor 0x1000 }

Hosts de contenedor no unidos a un dominio: use

registros de eventos para identificar problemas de
configuración.
El registro de eventos para usar gMSA con hosts de contenedor no unidos a un dominio
se puede usar para identificar problemas de configuración. Los eventos se registran en
el archivo de registro microsoft-Windows-Containers-CCG y se pueden encontrar en el
Visor de eventos en Registros de aplicaciones y
servicios\Microsoft\Windows\Containers-CCG\Admin. Si exporta este archivo de registro
desde el host de contenedor para leerlo, debe tener habilitada la característica de
contenedores en el dispositivo donde está intentando leer el archivo de registro y debe
estar en una versión de Windows que admita el uso de gMSA con hosts de contenedor
no unidos a dominio.

Eventos y descripciones

ﾉ Expandir tabla

Número Texto del evento Descripción

de
evento

1 Container Credential Guard ha Este evento indica que el complemento

instanciado el complemento especificado en la especificación de credenciales se
instaló y se pudo cargar. No es necesario realizar
ninguna acción.

2 Container Credential Guard ha Se trata de un evento informativo que indica que

capturado las credenciales de las credenciales de gMSA se capturaron
gMSA para %1 mediante el correctamente de AD. No es necesario realizar
complemento: %2 ninguna acción.

3 Container Credential Guard no Este evento indica un problema con la

pudo analizar la especificación especificación de credenciales. Esto puede ocurrir
de credenciales. Error: %1 si el GUID del complemento es incorrecto o si hay
otros campos con formato incorrecto. Revise el
manual de resolución de problemas de la
 Número Texto del evento Descripción
de
evento

especificación de credenciales para comprobar el

formato y el contenido de la misma.

4 Container Credential Guard no Este evento indica que no se pudo cargar el

pudo crear una instancia del complemento. Debe comprobar que el
complemento: %1. Error: %2 complemento se instaló correctamente en el host.

6 Container Credential Guard no Este evento indica que el complemento ha sido

pudo capturar las credenciales cargado pero no pudo recuperar las credenciales
del complemento: %1. Error: necesarias para obtener la contraseña de gMSA de
%2 AD. Debe comprobar que la entrada del
complemento tiene el formato correcto en la
especificación de credenciales y que el host del
contenedor tiene los permisos necesarios para
acceder al almacén de secretos usado por el
complemento.

7 Container Credential Guard Se trata de un evento informativo. Este evento se

captura de nuevo las genera cuando la contraseña de gMSA ha expirado
credenciales mediante el y debe actualizarse mediante las credenciales
complemento: %1 capturadas por el complemento.

8 Container Credential Guard no Este evento indica que no se pudieron usar las
pudo capturar las credenciales credenciales capturadas mediante el complemento
de gmsa para %1 mediante el para capturar las credenciales de gMSA de AD.
complemento %2. Motivo del Debe comprobar que la cuenta que se captura
error: %3 desde el complemento tiene permisos en AD para
recuperar las credenciales de gMSA.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
gMSA en Azure Kubernetes Service
Artículo • 05/02/2025

Las cuentas de servicio administradas de grupo (gMSA) se pueden usar en Azure

Kubernetes Service (AKS) para admitir aplicaciones que requieren Active Directory con
fines de autenticación. La configuración de gMSA en AKS requiere que configure
correctamente los siguientes servicios y opciones: AKS, Azure Key Vault, Active Directory,
especificaciones de credenciales, etc. Para simplificar este proceso, puede usar el
módulo de PowerShell siguiente. Este módulo se ha personalizado para simplificar el
proceso de configuración de gMSA en AKS mediante la eliminación de la complejidad
de la configuración de diferentes servicios.

Requisitos del entorno

Para implementar gMSA en AKS, necesitará lo siguiente:

Un clúster de AKS con nodos de Windows en funcionamiento. Si no tiene un

clúster de AKS listo, consulte la documentación de Azure Kubernetes Service.
El clúster debe estar autorizado para la gMSA en AKS. Para obtener más
información, consulte Habilitar cuentas de servicio administradas de grupo
(GMSA) para los nodos de Windows Server en el clúster de Azure Kubernetes
Service (AKS).
Un entorno de Active Directory configurado correctamente para gMSA. A
continuación se proporcionan detalles sobre cómo configurar el dominio.
Los nodos de Windows en AKS deben poder conectarse a los controladores de
dominio de Active Directory.
Credenciales de dominio de Active Directory con autorización delegada para
configurar la gMSA y un usuario de dominio estándar. Esta tarea se puede delegar
a personas autorizadas (si es necesario).

Instalación de gMSA en el módulo de

PowerShell de AKS
Para empezar, descargue el módulo de PowerShell desde la galería de PowerShell:

PowerShell

Install-Module -Name AksGMSA -Repository PSGallery -Force

 ７ Nota

El módulo gMSA en AKS PowerShell se actualiza constantemente. Si ejecutó los

pasos de este tutorial antes y ahora vuelve a comprobar las nuevas
configuraciones, asegúrese de actualizar el módulo a la versión más reciente. Puede
encontrar más información sobre el módulo en la página del PowerShell Gallery .

Requisitos del módulo

El módulo gMSA en AKS PowerShell se basa en diferentes módulos y herramientas. Para
instalar estos requisitos, ejecute lo siguiente en una sesión con privilegios elevados:

PowerShell

Install-ToolingRequirements

Inicio de sesión con la credencial de Azure

Tendrá que iniciar sesión en Azure con sus credenciales para el módulo gMSA en AKS
PowerShell para configurar correctamente el clúster de AKS. Para iniciar sesión en Azure
mediante PowerShell, ejecute lo siguiente:

PowerShell

Connect-AzAccount -DeviceCode -Subscription "<SUBSCRIPTION_ID>"

También debe iniciar sesión con la CLI de Azure, ya que el módulo de PowerShell
también lo usa en segundo plano:

PowerShell

az login --use-device-code
az account set --subscription "<SUBSCRIPTION_ID>"

Configuración de entradas necesarias para

gMSA en el módulo de AKS
A lo largo de la configuración de gMSA en AKS, se necesitarán muchas entradas, como:
el nombre del clúster de AKS, el nombre del grupo de recursos de Azure, la región para
implementar los recursos necesarios, el nombre de dominio de Active Directory y
mucho más. Para simplificar el proceso siguiente, creamos un comando de entrada que
recopilará todos los valores necesarios y lo almacenará en una variable que se usará en
los comandos siguientes.

Para empezar, ejecute lo siguiente:

PowerShell

$params = Get-AksGMSAParameters

Después de ejecutar el comando, proporcione las entradas necesarias hasta que finalice
el comando. Desde ahora, puede copiar y pegar los comandos como se muestra en esta
página.

Conexión al clúster de AKS

Al usar la gMSA en el módulo de PowerShell de AKS, se conectará al clúster de AKS que
desea configurar. La gMSA en el módulo de PowerShell AKs se basa en la conexión de
kubectl. Para conectar el clúster, ejecute lo siguiente: (Tenga en cuenta que, dado que
proporcionó las entradas anteriores, puede simplemente copiar y pegar el comando
siguiente en la sesión de PowerShell).

PowerShell

Import-AzAksCredential -Force `
-ResourceGroupName $params["aks-cluster-rg-name"] `
-Name $params["aks-cluster-name"]

Paso siguiente
Configure gMSA en AKS con el módulo de PowerShell

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Configuración de gMSA en Azure
Kubernetes Service con el módulo de
PowerShell
Artículo • 02/02/2025

En esta sección se explica cómo configurar gMSA en Azure Kubernetes Service mediante
la gMSA en el módulo de PowerShell de AKS. En los pasos siguientes se da por supuesto
que ha instalado la gMSA en el módulo de PowerShell de AKS, conectado a los clústeres
de AKS y ha proporcionado los parámetros necesarios. Si aún no lo ha hecho, asegúrese
de seguir los pasos de la sección primera de este tutorial.

Confirmación de que el clúster de AKS tiene la

característica gMSA configurada correctamente
Puede que su clúster de AKS ya esté configurado para gMSA o no. Para validar que el
clúster está listo para el uso de gMSA, ejecute el siguiente comando:

PowerShell

Confirm-AksGMSAConfiguration `
-AksResourceGroupName $params["aks-cluster-rg-name"] `
-AksClusterName $params["aks-cluster-name"] `
-AksGMSADomainDnsServer $params["domain-dns-server"] `
-AksGMSARootDomainName $params["domain-fqdn"]

Después de configurar el clúster, puede configurar la infraestructura restante necesaria

para que la gMSA funcione.

Configuración del entorno de Active Directory

El primer paso para preparar Active Directory es asegurarse de que el sistema de
distribución de claves está configurado. Para este paso, los comandos deben ejecutarse
con credenciales con la delegación adecuada, en un controlador de dominio. Esta tarea
se puede delegar a personas autorizadas.

Desde un controlador de dominio, ejecute lo siguiente para habilitar la clave raíz:

Para entornos de producción:

 PowerShell

# You will need to wait 10 hours before the KDS root key is
# replicated and available for use on all domain controllers.
Add-KdsRootKey -EffectiveImmediately

Para entornos de prueba:

PowerShell

# For single-DC test environments ONLY.

Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

Para los siguientes comandos, puede ejecutarlos en el controlador de dominio o en una

sesión remota de PowerShell. Si se ejecuta desde el controlador de dominio, quite los
parámetros "DomainControllerAddress", "DomainUser" y "DomainPassword" del
comando.

Si se ejecuta de forma remota, asegúrese de que el controlador de dominio está

configurado para la administración remota.

Creación del usuario de dominio estándar

PowerShell

# Creates the standard domain user.

New-GMSADomainUser `
-Name $params["gmsa-domain-user-name"] `
-Password $params["gmsa-domain-user-password"] `
-DomainControllerAddress $params["domain-controller-address"] `
-DomainAdmin "$($params["domain-fqdn"])\$($params["domain-admin-user-
name"])" `
-DomainAdminPassword $params["domain-admin-user-password"]

Creación de la gMSA
PowerShell

# Creates the gMSA account, and it authorizes only the standard domain
user.
New-GMSA `
-Name $params["gmsa-name"] `
-AuthorizedUser $params["gmsa-domain-user-name"] `
-DomainControllerAddress $params["domain-controller-address"] `
-DomainAdmin "$($params["domain-fqdn"])\$($params["domain-admin-user-
 name"])" `
-DomainAdminPassword $params["domain-admin-user-password"]

Configuración de Azure Key Vault y identidad

administrada asignada por el usuario de Azure
Azure Key Vault (AKV) se usará para almacenar las credenciales usadas por los nodos de
Windows en AKS para comunicarse con los controladores de dominio de Active
Directory. Se usará una identidad administrada (MI) para proporcionar acceso adecuado
a AKV para los nodos de Windows.

Creación del almacén de claves de Azure

PowerShell

# The Azure key vault will have a secret with the credentials of the
standard
# domain user authorized to fetch the gMSA.
New-GMSAAzureKeyVault `
-ResourceGroupName $params["aks-cluster-rg-name"] `
-Location $params["azure-location"] `
-Name $params["akv-name"] `
-SecretName $params["akv-secret-name"] `
-GMSADomainUser "$($params["domain-fqdn"])\$($params["gmsa-domain-user-
name"])" `
-GMSADomainUserPassword $params["gmsa-domain-user-password"]

Creación de la identidad administrada asignada por el

usuario de Azure
PowerShell

New-GMSAManagedIdentity `
-ResourceGroupName $params["aks-cluster-rg-name"] `
-Location $params["azure-location"] `
-Name $params["ami-name"]

Concesión de acceso de AKV a los hosts de Windows de

AKS
PowerShell
 # Appends the user-assigned managed identity to the AKS Windows agent pools
given as input parameter.
# Configures the AKV read access policy for the user-assigned managed
identity.
Grant-AkvAccessToAksWindowsHosts `
-AksResourceGroupName $params["aks-cluster-rg-name"] `
-AksClusterName $params["aks-cluster-name"] `
-AksWindowsNodePoolsNames $params["aks-win-node-pools-names"] `
-VaultResourceGroupName $params["aks-cluster-rg-name"] `
-VaultName $params["akv-name"] `
-ManagedIdentityResourceGroupName $params["aks-cluster-rg-name"] `
-ManagedIdentityName $params["ami-name"]

Configuración de la especificación de credenciales de

gMSA utilizando los recursos de RBAC
PowerShell

# Creates the gMSA credential spec.

# Configures the appropriate RBAC resources (ClusterRole and RoleBinding)
for the spec.
# Executes AD commands to get the appropriate domain information for the
credential spec.
New-GMSACredentialSpec `
-Name $params["gmsa-spec-name"] `
-GMSAName $params["gmsa-name"] `
-ManagedIdentityResourceGroupName $params["aks-cluster-rg-name"] `
-ManagedIdentityName $params["ami-name"] `
-VaultName $params["akv-name"] `
-VaultGMSASecretName $params["akv-secret-name"] `
-DomainControllerAddress $params["domain-controller-address"] `
-DomainUser "$($params["domain-fqdn"])\$($params["gmsa-domain-user-name"])"
`
-DomainUserPassword $params["gmsa-domain-user-password"]

En esta fase, se completa la configuración de gMSA en AKS. Ahora puede desplegar su

carga de trabajo en los nodos de Windows.

Paso siguiente
Validación de gMSA en AKS con el módulo de PowerShell

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Validación de gMSA en AKS con el
módulo de PowerShell
Artículo • 05/02/2025

Una vez configurado gMSA en AKS con el módulo de PowerShell, la aplicación está lista
para implementarse en los nodos de Windows en AKS. Sin embargo, si desea validar
aún más que la configuración está configurada correctamente, puede usar las
instrucciones siguientes para confirmar si la implementación está configurada
correctamente.

Validación
El módulo gMSA en AKS PowerShell proporciona un comando para validar si la
configuración del entorno está configurada correctamente. Compruebe que la
especificación de credenciales de gMSA funciona con el siguiente comando:

PowerShell

Start-GMSACredentialSpecValidation `
-SpecName $params["gmsa-spec-name"] `
-AksWindowsNodePoolsNames $params["aks-win-node-pools-names"]

Recopilación de registros de gMSA de los

nodos de Windows
El comando siguiente se puede usar para extraer registros de los hosts de Windows:

PowerShell

# Extracts the following logs from each Windows host:

# - kubelet logs.
# - CCG (Container Credential Guard) logs (as a .evtx file).
Copy-WindowsHostsLogs -LogsDirectory $params["logs-directory"]

Los registros se copiarán de cada host de Windows en el directorio local $params["logs-

directory"] . El directorio de registros tendrá un subdirectorio denominado después de

cada host del agente de Windows. El archivo de registro .evtx de CCG (Container
Credential Guard) se puede inspeccionar correctamente en el Visor de eventos, solo
después de cumplir los siguientes requisitos:
 La característica Contenedores de Windows está instalada. Se puede instalar a
través de PowerShell mediante el siguiente comando:

PowerShell

# Needs computer restart

Install-WindowsFeature -Name Containers

El archivo de manifiesto de registro CCGEvents.man se registra mediante lo

siguiente:

PowerShell

wevtutil im CCGEvents.man

７ Nota

Microsoft debe proporcionar el archivo de manifiesto de registro.

Configuración de una aplicación de ejemplo

mediante gMSA
Además de simplificar la configuración de gMSA en AKS, el módulo de PowerShell
también proporciona una aplicación de ejemplo que puede usar con fines de prueba.
Para instalar la aplicación de ejemplo, ejecute lo siguiente:

PowerShell

Get-GMSASampleApplicationYAML `
-SpecName $params["gmsa-spec-name"] `
-AksWindowsNodePoolsNames $params["aks-win-node-pools-names"] | kubectl
apply -f -

Validación del acceso del grupo de agentes de

AKS a Azure Key Vault
Los grupos de nodos de AKS deben poder acceder al secreto de Azure Key Vault para
poder usar la cuenta que puede recuperar la gMSA en Active Directory. Es importante
que haya configurado este acceso correctamente para que los nodos puedan
comunicarse con el controlador de dominio de Active Directory. No acceder a los
secretos significa que la aplicación no podrá autenticarse. Por otro lado, es posible que
quiera asegurarse de que no se proporciona acceso a los grupos de nodos que no lo
necesiten necesariamente.

El módulo gMSA en AKS PowerShell permite validar qué grupos de nodos tienen acceso
a qué secretos de Azure Key Vault.

PowerShell

Get-AksAgentPoolsAkvAccess `
-AksResourceGroupName $params["aks-cluster-rg-name"] `
-AksClusterName $params["aks-cluster-name"] `
-VaultResourceGroupNames $params["aks-cluster-rg-name"]

Compartir comentarios
Para obtener comentarios, preguntas y sugerencias sobre la gMSA en el módulo de
PowerShell en AKS, visite el repositorio de contenedores de Windows en GitHub .

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Red de contenedores de Windows
Artículo • 30/01/2025

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

） Importante

Consulte Docker Container Networking para comandos, opciones y sintaxis

generales de Docker. A excepción de los casos descritos en características y
opciones de red no compatibles, todos los comandos de red de Docker se admiten
en Windows con la misma sintaxis que en Linux. Sin embargo, las pilas de red de
Windows y Linux son diferentes y, como tal, verá que algunos comandos de red de
Linux (por ejemplo, ifconfig ) no se admiten en Windows.

Arquitectura de red básica

En este tema se proporciona información general sobre cómo Docker crea y administra
redes host en Windows. Los contenedores de Windows funcionan de forma similar a las
máquinas virtuales en lo que respecta a las redes. Cada contenedor tiene un adaptador
de red virtual (vNIC) que se conecta a un conmutador virtual Hyper-V (vSwitch).
Windows admite cinco controladores o modos de red diferentes que se pueden crear a
través de Docker: nat, overlay, transparent, l2bridge y l2tunnel. En función de la
infraestructura de red física y de los requisitos de red de un solo host o de varios hosts,
debes elegir el controlador de red que mejor se adapte a tus necesidades.
La primera vez que se ejecuta docker Engine, crea una red NAT predeterminada, "nat",
que usa un vSwitch interno y un componente de Windows denominado WinNAT . Si hay
vSwitches externos preexistentes en el host que se crearon a través de PowerShell o el
Administrador de Hyper-V, también estarán disponibles para Docker mediante el
controlador de red transparente y se pueden ver al ejecutar el docker network ls
comando.

Un vSwitch interno es uno que no está conectado directamente a un adaptador de

red en el host del contenedor.
Un vSwitch externo es uno que está conectado directamente a un adaptador de
red en el host de contenedor.
La red "nat" es la red predeterminada para los contenedores que se ejecutan en
Windows. Los contenedores que se ejecutan en Windows sin marcas ni argumentos
para implementar configuraciones de red específicas se asociarán a la red "nat"
predeterminada y se asignará automáticamente una dirección IP desde el intervalo IP
interno de la red "nat". El prefijo IP interno predeterminado usado para "nat" es
172.16.0.0/16.

Administración de redes de contenedores con

el servicio de red host
El servicio de redes de host (HNS) y el servicio de proceso de host (HCS) funcionan
conjuntamente para crear contenedores y conectar puntos de conexión a una red.
Puede interactuar con HNS a través del módulo auxiliar de PowerShell de HNS.

Creación de red
HNS crea un conmutador virtual de Hyper-V para cada red.
HNS crea grupos de DIRECCIONES IP y NAT según sea necesario.

Creación de puntos de conexión

HNS crea un espacio de nombres de red por punto de conexión de contenedor
HNS/HCS coloca v(m)NIC dentro del espacio de nombres de red
HNS crea puertos (vSwitch)
HNS asigna la dirección IP, la información de DNS, las rutas, etc. (sujeto al modo
de red) al punto de conexión.

Creación de directivas
Para la red predeterminada de traducción de direcciones de red (NAT), HNS crea
las reglas de reenvío de puertos WinNAT y las asignaciones con las reglas ALLOW
de Firewall de Windows correspondientes.
Para todas las demás redes, HNS utiliza la Plataforma de filtrado virtual (VFP) para
la creación de directivas que incluye equilibrio de carga, ACL y encapsulación. Para
más información sobre las API de HNS y el esquema, consulte Api de servicio de
red de proceso de host (HCN) para máquinas virtuales y contenedores.
Características no admitidas y opciones de red
Actualmente no se admiten las siguientes opciones de red en Windows:

Desde Windows Server 2022 y versiones posteriores, los contenedores de

Windows tienen la siguiente compatibilidad con las redes IPv6:
Los contenedores conectados a redes l2bridge admiten la pila IPv6.
Los contenedores conectados a redes transparentes admiten la comunicación
mediante IPv6 con direcciones IP autoasignadas, pero no admiten la asignación
de direcciones IP proporcionadas por HNS y otros servicios de red, como
equilibrio de carga y ACL.
Los contenedores de Windows conectados a redes NAT y de superposición no
admiten la comunicación a través de la pila IPv6.
Comunicación de contenedor cifrada a través de IPsec.
Redes en modo host.
Redes en la infraestructura de Azure virtualizada a través del controlador de red
transparente.

ﾉ Expandir tabla
 Comando Opción no admitida

docker run --ip6 , --dns-option

docker network --aux-address , --internal , --ip-range , --ipam-driver , --ipam-opt , , --

create ipv6 --opt encrypted

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Controladores de red de contenedores
de Windows
Artículo • 05/02/2025

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

Además de aprovechar la red "nat" predeterminada creada por Docker en Windows, los
usuarios pueden definir redes de contenedor personalizadas. Las redes definidas por el
usuario se pueden crear mediante el comando docker network create -d <NETWORK
DRIVER TYPE> <NAME> de la CLI de Docker. En Windows, están disponibles los
siguientes tipos de controladores de red:

Controlador de red NAT

Los contenedores conectados a una red creada con el controlador "nat" se conectarán a
un conmutador de Hyper-V interno de y recibirán una dirección IP del prefijo IP
especificado por el usuario ( --subnet ). Se admite el reenvío o asignación de puertos
desde el host del contenedor a los puntos finales del contenedor.

 Sugerencia

Es posible personalizar la subred utilizada por la red "nat" predeterminada

mediante el valor fixed-cidr del archivo de configuración del demonio de
Docker .

７ Nota

Las redes NAT creadas en Windows Server 2019 (o superior) ya no se conservan

después del reinicio.

Creación de una red NAT

Para crear una nueva red NAT con subred 10.244.0.0/24 :

PowerShell
 docker network create -d "nat" --subnet "10.244.0.0/24" my_nat

Controlador de red transparente

Los contenedores conectados a una red creada con el controlador "transparente" se
conectarán directamente a la red física a través de un conmutador de Hyper-V externo.
Las direcciones IP de la red física se pueden asignar estáticamente (requiere la opción -
-subnet especificada por el usuario) o dinámicamente mediante un servidor DHCP

externo.

７ Nota

Debido al siguiente requisito, no se admite la conexión de los hosts de contenedor

a través de una red transparente en máquinas virtuales de Azure.

Obligatorio: cuando este modo se usa en un escenario de virtualización (el host de

contenedor es una máquina virtual) la suplantación de direcciones MAC es
obligatoria.

Creación de una red transparente

Para crear una nueva red transparente con subred 10.244.0.0/24 , puerta de enlace
10.244.0.1 , servidor DNS 10.244.0.7 e id. de VLAN 7 :

PowerShell

docker network create -d "transparent" --subnet 10.244.0.0/24 --gateway

10.244.0.1 -o com.docker.network.windowsshim.vlanid=7 -o
com.docker.network.windowsshim.dnsservers="10.244.0.7" my_transparent

Superponer controlador de red

Utilizados habitualmente por orquestadores como Docker Swarm y Kubernetes, los
contenedores conectados a una red de superposición pueden comunicarse con otros
contenedores conectados a la misma red en varios hosts de contenedores. Cada red de
superposición se crea con su propia subred IP, definida por un prefijo IP privado. El
controlador de red superpuesta utiliza la encapsulación VXLAN para lograr el
aislamiento del tráfico de red entre redes de contenedores de distintos inquilinos y
permite reciclar direcciones IP entre redes superpuestas.
 Requiere: Asegúrese de que su entorno cumpla estos requisitos previos para crear
redes de superposición.

Requiere: En Windows Server 2019, esto requiere KB4489899 .

Requiere: En Windows Server 2016, esto requiere KB4015217 .

７ Nota

En Windows Server 2019 y versiones posteriores, las redes de superposición

creadas por Docker Swarm aprovechan las reglas NAT de VFP para la conectividad
saliente. Esto significa que un contenedor determinado recibe 1 dirección IP.
También significa que las herramientas basadas en ICMP, como ping o Test-
NetConnection , deben configurarse mediante sus opciones TCP/UDP en situaciones

de depuración.

Creación de una red superpuesta

Para crear una nueva red de superposición con subred 10.244.0.0/24 , servidor DNS
168.63.129.16 y VSID 4096 :

PowerShell

docker network create -d "overlay" --attachable --subnet "10.244.0.0/24" -o

com.docker.network.windowsshim.dnsservers="168.63.129.16" -o
com.docker.network.driver.overlay.vxlanid_list="4096" my_overlay

Controlador de red L2bridge

Los contenedores conectados a una red creada con el controlador "l2bridge" se
conectarán a la red física a través de un conmutador de Hyper-V externo. En l2bridge, el
tráfico de red del contenedor tendrá la misma dirección MAC que el host debido a la
operación de traducción de direcciones de capa 2 (reescritura MAC) de entrada y salida.
En los centros de datos, esto ayuda a aliviar el estrés en los conmutadores que tienen
que aprender direcciones MAC de contenedores a veces de corta duración. Las redes
L2bridge se pueden configurar de dos maneras diferentes:

1. La red L2bridge está configurada con la misma subred IP que el host de

contenedor.
 2. La red L2bridge está configurada con una nueva subred IP personalizada

En la configuración 2, los usuarios deberán agregar un punto de conexión en el

compartimiento de red host que actúa como puerta de enlace y configurar las
funcionalidades de enrutamiento para el prefijo designado.

Creación de una red l2bridge

Para crear una nueva red l2bridge con subred 10.244.0.0/24 , puerta de enlace
10.244.0.1 , servidor DNS 10.244.0.7 e id. de VLAN 7:

PowerShell

docker network create -d "l2bridge" --subnet 10.244.0.0/24 --gateway

10.244.0.1 -o com.docker.network.windowsshim.vlanid=7 -o
com.docker.network.windowsshim.dnsservers="10.244.0.7" my_l2bridge

 Sugerencia

Las redes L2bridge son altamente programables; Puede encontrar más detalles
sobre cómo configurar l2bridge aquí .

Controlador de red L2tunnel

La creación es idéntica a l2bridge, pero este controlador solo se debe usar en una pila de
Microsoft Cloud (Azure). La única diferencia con respecto a l2bridge es que todo el
tráfico de contenedor se envía al host de virtualización donde se aplica la directiva de
SDN, lo que permite características como las de grupos de seguridad de red de Azure
para los contenedores.

Topologías de red e IPAM

En la tabla siguiente se muestra cómo se proporciona conectividad de red para
conexiones internas (contenedor a contenedor) y externas para cada controlador de red.

Modos de red/controladores de Docker

ﾉ Expandir tabla
Controlador de Usos típicos Contenedor a Contenedor a Contenedor a
red de Windows contenedor externo (nodo único contenedor
de Docker (nodo único) + varios nodos) (varios nodos)

NAT Bueno para Misma Enrutado mediante la No se admite

(predeterminado) desarrolladores subred: vNIC de directamente: es
conexión administración necesario
con puente (enlazada a WinNAT) exponer puertos
desde el mediante el host
conmutador
virtual de
Hyper-V
Entre
subredes:
no
compatible
(solo un
prefijo
interno
NAT)

Transparente Bueno para Misma Enrutado a través del Enrutado a

desarrolladores o subred: host de contenedor través del host
implementaciones conexión con acceso directo al de contenedor
pequeñas con puente adaptador de red con acceso
desde el (físico) directo al
conmutador adaptador de
virtual de red (físico)
Hyper-V
Entre
subredes:
se enruta
mediante el
host de
contenedor

Superposición Bueno para varios Misma No se admite Misma subred o

nodos; subred: directamente: se entre subredes:
obligatorio para conexión necesita un segundo el tráfico de red
Docker Swarm, con puente punto de conexión de se encapsula
disponible en desde el contenedor mediante VXLAN
Kubernetes conmutador conectado a la red y se enruta a
virtual de NAT en través de mgmt
Hyper-V Windows Server 2016, vNIC
Subred o bien una regla NAT
cruzada: el de VFP en
tráfico de Windows Server 2019.
red se
 Controlador de Usos típicos Contenedor a Contenedor a Contenedor a
red de Windows contenedor externo (nodo único contenedor
de Docker (nodo único) + varios nodos) (varios nodos)

encapsula y
se enruta a
través de
mgmt vNIC

L2Bridge Se usa para Misma Dirección MAC del Misma

Kubernetes y subred: contenedor reescrita subred:
Microsoft SDN conexión en la entrada y a la conexión
con puente salida puenteda
desde el Entre
conmutador subredes:
virtual de se enruta
Hyper-V mediante
Entre la vNIC
subredes: la Mgmt en
dirección WSv1809 y
MAC del versiones
contenedor posteriores
se reescribe
durante la
entrada y la
salida, y se
enruta

L2Tunnel Solo Azure Misma subred o El tráfico debe pasar Misma subred o
entre subredes: por la puerta de entre subredes:
anclada al enlace de red virtual anclada al
conmutador de Azure conmutador
virtual de Hyper-V virtual de Hyper-
del host físico a V del host físico
donde se aplica la a donde se
directiva aplica la directiva

IPAM
Las direcciones IP se reparten y asignan de manera diferente para cada controlador de
red. Windows usa el Servicio de redes de host (HNS) para proporcionar IPAM para el
controlador NAT y funciona con el modo Docker Swarm (KVS interno) a fin de
proporcionar IPAM para la superposición. Todos los demás controladores de red usan
un IPAM externo.
 ﾉ Expandir tabla

Modo de IPAM
red/Controlador

NAT Asignación y asignación dinámica de IP por el Servicio de redes de host

(HNS) desde el prefijo de subred NAT interno

Transparente Asignación y distribución de direcciones IP estáticas o dinámicas

(mediante un servidor DHCP externo) a partir de direcciones IP dentro del
prefijo de red del host del contenedor

Superposición Asignación dinámica de IP desde prefijos gestionados por el modo Swarm

del motor Docker y asignación mediante HNS

L2Bridge Asignación dinámica de IP por el Servicio de Red de Host (HNS) a partir

del prefijo de subred proporcionado

L2Tunnel Solo para Azure: asignación y atribución dinámica de IP desde el

complemento

Detección de servicios
La detección de servicios solo se admite para determinados controladores de red de
Windows.

ﾉ Expandir tabla

Nombre del controlador Detección de servicios locales Detección de servicios globales

nat SÍ SÍ con Docker EE

superposición SÍ SÍ con Docker EE o kube-dns

transparente NO NO

l2bridge SÍ con kube-dns SÍ con kube-dns

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Compatibilidad con varias subredes en
el servicio de redes de host
Artículo • 05/02/2025

Se aplica a: Windows Server 2025, Windows Server 2022

Ahora se admite el uso de varias subredes por red en el servicio de redes de host (HNS)
para contenedores de Windows. Anteriormente, HNS restringía las configuraciones de
puntos de conexión de contenedores de Kubernetes para usar solo la longitud del
prefijo de la subred subyacente. HNS se ha mejorado para que pueda usar subredes
más restrictivas, como subredes con una longitud de prefijo más larga, así como varias
subredes por nodo de trabajo de Windows. La primera interfaz de red de contenedor
(CNI) que puede esta funcionalidad es Calico para Windows. Calico Network Policies es
una solución de seguridad de red y red de código abierto fundada por Tigera .

Puede utilizar varias subredes en HNS solo para los controladores de red l2bridge,
l2tunnel y overlay. Estos controladores de red pueden exponer varias subredes y, a
continuación, permitir que cada punto de conexión se enlace a una de estas subredes.

HNS y el servicio de computación del host (HCS) funcionan conjuntamente para crear
contenedores y conectar puntos de conexión a una red. Puede interactuar con HNS
mediante el módulo HNS PowerShell Helper .

Requisitos de Calico
La compatibilidad con varias subredes para el CNI de Calico requiere subdividir la
subred en bloques IP más pequeños. Todos los bloques IP deben compartir la misma
puerta de enlace, pero cada bloque IP puede tener su propio dominio de difusión
independiente. Para maximizar la asignación de IPV4 para que sea lo más eficaz posible,
Calico requiere crear bloques IP muy pequeños (tan pequeños como un bloque = cuatro
direcciones IP), además de establecer prefijos muy pequeños en los puntos de conexión
de contenedor (tan pequeños como /32).

Una implementación completa de la administración de direcciones IP (IPAM) de Calico

funciona de la siguiente manera:

La función IPAM de Calico está diseñada para asignar direcciones IP a cargas de trabajo
a petición. Calico también admite varios grupos de direcciones IP para la agrupación
administrativa. Al configurar una asignación para una carga de trabajo determinada, el
conjunto de grupos permitidos puede estar limitado por la configuración, lo que
permite varios casos de uso. Siga las instrucciones siguientes para diferentes casos de
uso:

Utilice varios grupos disjuntos para aumentar la capacidad.

Para las redes l2bridge dentro de un bastidor, configure un grupo de direcciones IP
por bastidor donde los hosts de un bastidor solo pueden realizar la asignación
desde un grupo determinado.
Use un grupo de IP por capa de pila donde los pods de front-end obtienen sus
direcciones de un grupo de front-end (que podría ser público), pero los pods de
back-end (potencialmente en el mismo host) reciben direcciones de otro intervalo.
Esto permite que Calico se ajuste a los exigentes requisitos de creación de
particiones de red (según sea necesario para trabajar con firewalls heredados).
Use micro grupos muy pequeños, uno para cada nivel de una pila. Dado que estos
grupos son tan pequeños, requieren que cada host admita cargas de trabajo de
varios grupos.

Las direcciones IP siempre se asignan desde bloques y esos bloques pueden ser afín a
un host determinado. Un host siempre intentará asignar direcciones IP desde uno de sus
propios bloques affine si hay espacio (y solo si el bloque procede de un grupo
permitido para la carga de trabajo determinada). Si ninguno de los bloques existentes
del host tiene espacio, este intentará reclamar un nuevo bloque de un grupo permitido.
Si no hay bloques vacíos disponibles, el host tomará prestado una dirección IP de
cualquier bloque de un grupo permitido que tenga espacio libre disponible, incluso si
ese bloque es afín a otro host.

Calico se basa en el de enrutamiento de coincidencias de prefijo más largo para admitir la

agregación. Cada host anuncia rutas para todos sus bloques afines y anuncia rutas /32
para cualquier IP que haya tomado prestada. Como una ruta /32 es más específica, los
hosts remotos que necesitan reenviar a /32 usarán la ruta /32 en lugar de la ruta /26
más amplia al host con el bloque afín.

Puesto que Calico es una red L3 enrutada, vale la pena señalar que las rutas /26 no
están pensadas para ser subredes. Por ejemplo, no hay ninguna dirección de red o
difusión; y las direcciones "0" y "255" de un bloque se usan como direcciones IP
normales.

Requisitos del plano de datos HNS de Calico

Hay varios requisitos de conectividad y directivas de Calico para habilitar varias
subredes en HNS:
 Todas las cargas de trabajo del mismo host deben tener conectividad entre sí y con
pods remotos.
Todas las rutas de paquetes entre pods deben cumplir lo siguiente, ya sea que el
remitente y el receptor estén ubicados en el mismo host o si se acceden
mutuamente, ya sea de forma directa o a través de la IP del clúster de servicios:
Las directivas de salida y entrada de la lista de control de acceso (ACL) deben
aplicarse.
Tanto la directiva de salida del pod de envío como la directiva de entrada del
pod receptor deben permitir el tráfico.
Todas las reglas de ACL programadas por Calico deben poder ver las
direcciones IP del pod.
Los hosts y pods deben poder comunicarse entre sí y llegar a pods en otros hosts
mediante rutas aprendidas por medio del Protocolo de puerta de enlace de borde
(BGP).

Requisitos para varios bloques IP por host

Para admitir varios bloques ip por host, revise los siguientes requisitos:

En el caso de un único grupo de IP determinado, el plano de datos debe permitir

que los pods se agreguen con IP de diferentes bloques de IP disjuntos. Por
ejemplo, el grupo de direcciones IP puede ser 10.0.0.0/16, pero un host puede
reclamar un par de bloques aleatorios: 10.0.123.0/26 y 10.0.200.0/26.
No es necesario conocer el grupo y el tamaño de los bloques antes de la primera
asignación. Esto es muy recomendable.
Otros bloques del mismo conjunto pueden estar presentes en otros servidores.
El prefijo común de los distintos bloques puede superponerse con la propia
dirección IP del host.

Requisitos para apoyar los préstamos de propiedad

intelectual.
Calico IPAM asigna direcciones IP para hospedar en bloques con fines de agregación. Si
el grupo de direcciones IP está lleno, los nodos también pueden tomar prestadas
direcciones IP del bloque de otro nodo. En términos de BGP, el prestatario anuncia
entonces una ruta más específica /32 para la dirección IP prestada y, a continuación, el
tráfico de esa dirección IP se enruta al host prestatario.

Los nodos de Windows no admiten este mecanismo de préstamo. No tomarán

prestadas direcciones IP incluso si el grupo de direcciones IP está lleno, y marcan sus
bloques para que los nodos de Linux tampoco los tomen prestados.
Requisitos para admitir microgrupos
Para usar micropools, se quita el requisito de reservar cuatro direcciones IP por bloque.
En el caso de uso de micropool, se usan grupos muy pequeños y bloques muy
pequeños, por lo que cuatro direcciones IP por bloque desperdician la mayoría de las
direcciones IP. Puede requerir un pequeño número de direcciones IP reservadas por
host o por grupo. Un procedimiento recomendado consiste en eliminar todas las
restricciones de compatibilidad de capa 2 (por ejemplo, no debe haber compatibilidad
con la difusión y no hay direcciones IP reservadas).

Creación de una subred y una subred de IP

mediante PowerShell
Antes de continuar, asegúrese de tener instalado el módulo HNS.V2.psm1 desde la
galería HNS de PowerShell .

En los pasos siguientes se explica cómo crear una subred y una subred IP mediante
ejemplos.

1. Para crear una red l2bridge con una subred 192.168.0.0/16 que contiene una
subred IP 192.168.1.0/24 y una subred IP 192.168.2.0/24, ejecute el siguiente
comando:

PowerShell

$net1 = New-HnsNetwork -Type L2Bridge -Name Test1 -AddressPrefix

"192.168.0.0/16" -Gateway "192.168.0.1" -Verbose -IPSubnets
@(@{"IpAddressPrefix"="192.168.1.0/24";"Flags"=0},@{"IpAddressPrefix"="
192.168.2.0/24";"Flags"=[IPSubnetFlags]::EnableBroadcast})

2. Para agregar una nueva subred 172.16.0.0/16 que contenga una subred IP
172.16.1.0/16 a la red l2bridge, ejecute el siguiente comando:

PowerShell

New-HnsSubnet -NetworkID $net1.ID -Subnets @{

"IpAddressPrefix"="172.16.0.0/16";

"Routes"=@(@{"NextHop"="172.16.0.1";"DestinationPrefix"="0.0.0.0"});
"IpSubnets"=@(@{"IpAddressPrefix"="172.16.1.0/24"})

3. Para agregar una nueva subred IP 172.16.2.0/24 a la subred 172.16.0.0/16, ejecute

el siguiente comando:
 PowerShell

New-HnsIPSubnet -NetworkID $net1.ID -SubnetID $net2.Subnets[1].ID -

IPSubnets @{"IpAddressPrefix"="172.16.2.0/24";"Flags"=0}

Para quitar las subredes IP, siga estos pasos:

1. Para quitar la subred IP 172.16.2.0/24, ejecute el siguiente comando:

PowerShell

$net2 = Get-HnsNetwork -ID $net1.ID

Remove-HnsIpSubnet -NetworkID $net1.ID -SubnetID $net2.Subnets[1].ID
-IPSubnets @{"ID"=$net2.Subnets[1].IPSubnets[1].ID}

2. Para quitar la subred 172.16.0.0/16, ejecute el siguiente comando:

PowerShell

Remove-HnsSubnet -NetworkID $net1.ID -Subnets

@{"ID"=$net2.Subnets[1].ID}

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Aislamiento y seguridad de red
Artículo • 05/02/2025

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

Aislamiento con espacios de nombres de red

Cada punto de conexión de contenedor se coloca en su propio espacio de nombres de
red. El adaptador de red virtual del host de administración y la pila de red del host se
encuentran en el espacio de nombres de red predeterminado. Para aplicar el aislamiento
de red entre contenedores en el mismo host, se crea un espacio de nombres de red
para cada contenedor de Windows Server y los contenedores se ejecutan bajo el
aislamiento Hyper-V, en el cual se instala el adaptador de red para el contenedor. Los
contenedores de Windows Server usan un adaptador de red virtual host para conectarse
al conmutador virtual. El aislamiento de Hyper-V utiliza un adaptador de red de
máquina virtual sintético (no expuesto a la máquina virtual de utilidad) para conectarse
al conmutador virtual.
Ejecute el siguiente cmdlet de PowerShell para obtener todos los compartimientos de
red en la pila de protocolos:

PowerShell

Get-NetCompartment

Seguridad de red
Según el contenedor y controlador de red que se use, las ACL de puerto se aplican
mediante una combinación del Firewall de Windows y Azure Virtual Filtering Platform
(VFP) .

Contenedores de Windows Server

Los siguientes valores utilizan el firewall de los hosts de Windows (habilitado con
espacios de nombres de red) y VFP:

Salida predeterminada: PERMITIR TODO

Entrada predeterminada: PERMITIR TODO (TCP, UDP, ICMP, IGMP) tráfico de red
no solicitado
Deniega todo el resto del tráfico de red que no proceda de estos protocolos

７ Nota

Antes de Windows Server versión 1709 y Windows 10 Fall Creators Update, la regla
de entrada predeterminada era DENY all. Los usuarios que ejecutan estas versiones
anteriores pueden crear reglas ALLOW entrantes con docker run -p (reenvío de
puertos).

Aislamiento de Hyper-V
Los contenedores que operan en aislamiento Hyper-V tienen su propio núcleo aislado y,
por tanto, ejecutan su propia instancia de Firewall de Windows con la siguiente
configuración:

Predeterminado PERMITIR TODO en el Firewall de Windows (que se ejecuta en la

VM de utilidad) y VFP.
aislamiento de

de firewall

Pods de Kubernetes
En un pod de Kubernetes , primero se crea un contenedor de infraestructura al que se
adjunta un punto de conexión. Los contenedores que pertenecen al mismo pod,
incluidos los contenedores de infraestructura y trabajo, comparten un espacio de
nombres de red común (como la misma dirección IP y espacio de puerto).
Personalización de ACL de puerto predeterminadas
Si quiere modificar las ACL de puerto predeterminadas, revise el tema Servicio de redes
de host antes de cambiar los puertos. Deberá actualizar las directivas dentro de los
siguientes componentes:

７ Nota

Para el aislamiento de Hyper-V en modo transparente y NAT, actualmente no se

pueden volver a configurar las ACL de puerto predeterminadas, lo que se indica
con una "X" en la tabla siguiente.

ﾉ Expandir tabla

Controlador de red Contenedores de Windows Server Aislamiento de Hyper-V

Transparente Windows Firewall X

NAT Windows Firewall X

L2Bridge Ambos VFP

L2Tunnel Ambos VFP

 Controlador de red Contenedores de Windows Server Aislamiento de Hyper-V

Superposición Ambos VFP

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Opciones avanzadas de red en Windows
Artículo • 17/01/2024

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

Se admiten varias opciones de controlador de red para aprovechar las funcionalidades y

características específicas de Windows.

Cambio de equipo insertado con redes de

Docker
Se aplica a todos los controladores de red

Puede aprovechar las ventajas de Switch Embedded Teaming al crear redes host de
contenedor para usarlas mediante Docker especificando varios adaptadores de red
(separados por comas) con la -o com.docker.network.windowsshim.interface opción .

C:\> docker network create -d transparent -o

com.docker.network.windowsshim.interface="Ethernet 2", "Ethernet 3"
TeamedNet

Establecer el identificador de VLAN para una

red
Se aplica a los controladores de red transparentes y l2bridge

Para establecer un identificador de VLAN para una red, use la opción para -o
com.docker.network.windowsshim.vlanid=<VLAN ID> el docker network create comando .

Por ejemplo, puede usar el siguiente comando para crear una red transparente con un
identificador de VLAN de 11:

C:\> docker network create -d transparent -o

com.docker.network.windowsshim.vlanid=11 MyTransparentNetwork
Al establecer el identificador de VLAN para una red, se establece el aislamiento de VLAN
para los puntos de conexión de contenedor que se asociarán a esa red.

Asegúrese de que el adaptador de red host (físico) está en modo troncal para
permitir que el vSwitch procese todo el tráfico etiquetado con el puerto vNIC (punto
de conexión de contenedor) en modo de acceso en la VLAN correcta.

Especificar la directiva OutboundNAT para una

red
Se aplica a las redes l2bridge

Normalmente, cuando se crea una l2bridge red de contenedor mediante docker

network create , los puntos de conexión de contenedor no tienen aplicada una directiva

outboundNAT de HNS, lo que provoca que los contenedores no puedan acceder al

mundo exterior. Si va a crear una red, puede usar la opción de aplicar la -o
com.docker.network.windowsshim.enable_outboundnat=<true|false> directiva de HNS

outboundNAT para conceder a los contenedores acceso al mundo exterior:

C:\> docker network create -d l2bridge -o

com.docker.network.windowsshim.enable_outboundnat=true MyL2BridgeNetwork

Si hay un conjunto de destinos (por ejemplo, se necesita un contenedor para la

conectividad de contenedor) para el lugar en el que no queremos que se produzca NAT,
también es necesario especificar una exceptionList:

C:\> docker network create -d l2bridge -o

com.docker.network.windowsshim.enable_outboundnat=true -o
com.docker.network.windowsshim.outboundnat_exceptions=10.244.10.0/24

Especificar el nombre de una red al servicio

HNS
Se aplica a todos los controladores de red
Normalmente, cuando se crea una red de contenedor mediante docker network create ,
el servicio de Docker usa el nombre de red que proporciona, pero no el servicio HNS. Si
va a crear una red, puede especificar el nombre proporcionado por el servicio HNS
mediante la opción , -o com.docker.network.windowsshim.networkname=<network name> en
el docker network create comando . Por ejemplo, puede usar el siguiente comando
para crear una red transparente con un nombre especificado en el servicio HNS:

C:\> docker network create -d transparent -o

com.docker.network.windowsshim.networkname=MyTransparentNetwork
MyTransparentNetwork

Enlace de una red a una interfaz de red

específica
Se aplica a todos los controladores de red excepto "nat"

Para enlazar una red (conectada a través del conmutador virtual de Hyper-V) a una
interfaz de red específica, use la opción para -o
com.docker.network.windowsshim.interface=<Interface> el docker network create

comando . Por ejemplo, puede usar el siguiente comando para crear una red
transparente que esté conectada a la interfaz de red "Ethernet 2":

C:\> docker network create -d transparent -o

com.docker.network.windowsshim.interface="Ethernet 2" TransparentNet2

Nota: El valor de com.docker.network.windowsshim.interface es el nombre del

adaptador de red, que se puede encontrar con:

PS C:\> Get-NetAdapter

Especificar el sufijo DNS o los servidores DNS

de una red
 Se aplica a todos los controladores de red

Use la opción para -o com.docker.network.windowsshim.dnssuffix=<DNS SUFFIX>

especificar el sufijo DNS de una red y la opción para -o
com.docker.network.windowsshim.dnsservers=<DNS SERVER/S> especificar los servidores

DNS de una red. Por ejemplo, puede usar el siguiente comando para establecer el sufijo
DNS de una red en "example.com" y los servidores DNS de una red en 4.4.4.4 y 8.8.8.8:8:

C:\> docker network create -d transparent -o

com.docker.network.windowsshim.dnssuffix=abc.com -o
com.docker.network.windowsshim.dnsservers=4.4.4.4,8.8.8.8
MyTransparentNetwork

VFP
Consulte este artículo para más información.

Recomendaciones y Ideas
Esta es una lista de sugerencias y conclusiones útiles, inspiradas en preguntas comunes
sobre redes de contenedores de Windows que escuchamos de la comunidad...

HNS requiere que IPv6 esté habilitado en máquinas host de

contenedor.
Como parte de KB4015217 HNS requiere que IPv6 esté habilitado en hosts de
contenedor de Windows. Si tiene un error como el siguiente, existe la posibilidad de que
IPv6 esté deshabilitado en el equipo host.

docker: Error response from daemon: container

e15d99c06e312302f4d23747f2dfda4b11b92d488e8c5b53ab5e4331fd80636d encountered
an error during CreateContainer: failure in a Windows system call: Element
not found.

Estamos trabajando en los cambios de la plataforma para detectar o evitar este

problema automáticamente. Actualmente, se puede usar la siguiente solución
alternativa para asegurarse de que IPv6 está habilitado en el equipo host:
 C:\> reg delete
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v
DisabledComponents /f

Contenedores de Linux en Windows

NUEVO: Estamos trabajando para que sea posible ejecutar contenedores de Linux y
Windows en paralelo sin la máquina virtual Moby Linux. Consulte esta entrada de blog
sobre contenedores de Linux en Windows (LCOW) para obtener más información.
Aquí se muestra cómo empezar.

NOTA: LCOW está en desuso en la máquina virtual Linux de Moby y usará el VSwitch
interno de HNS predeterminado.

Las máquinas virtuales Linux de Moby usan el conmutador

DockerNAT con Docker para Windows (un producto de Docker
CE )

Docker para Windows (el controlador de Windows para el motor de Docker CE) en
Windows 10 usará un vSwitch interno denominado "DockerNAT" para conectar
máquinas virtuales Linux de Moby al host de contenedor. Los desarrolladores que usan
máquinas virtuales Linux de Moby en Windows deben tener en cuenta que sus hosts
usan dockerNAT vSwitch en lugar del vSwitch "nat" creado por el servicio HNS (que es el
conmutador predeterminado que se usa para los contenedores de Windows).

Para usar DHCP para la asignación de IP en un host de contenedor

virtual, habilite MACAddressSpoofing
Si el host de contenedor está virtualizado y desea usar DHCP para la asignación de IP,
debe habilitar MACAddressSpoofing en el adaptador de red de la máquina virtual. De lo
contrario, el host de Hyper-V bloqueará el tráfico de red de los contenedores de la
máquina virtual con varias direcciones MAC. Puede habilitar MACAddressSpoofing con
este comando de PowerShell:

PS C:\> Get-VMNetworkAdapter -VMName ContainerHostVM | Set-VMNetworkAdapter

-MacAddressSpoofing On
Si ejecuta VMware como hipervisor, deberá habilitar el modo promiscuo para que
funcione. Los detalles se pueden encontrar aquí

Creación de varias redes transparentes en un único host de

contenedor
Si desea crear más de una red transparente, debe especificar a qué adaptador de red
(virtual) debe enlazar el conmutador virtual externo de Hyper-V. Para especificar la
interfaz de una red, use la sintaxis siguiente:

# General syntax:
C:\> docker network create -d transparent -o
com.docker.network.windowsshim.interface=<INTERFACE NAME> <NETWORK NAME>

# Example:
C:\> docker network create -d transparent -o
com.docker.network.windowsshim.interface="Ethernet 2" myTransparent2

No olvide especificar --subnet y --gateway al usar la asignación de

IP estática.

Al usar la asignación de IP estática, primero debe asegurarse de que los parámetros --

subnet y --gateway se especifican cuando se crea la red. La subred y la dirección IP de
puerta de enlace deben ser las mismas que la configuración de red para el host de
contenedor, es decir, la red física. Por ejemplo, este es el modo en que puede crear una
red transparente y, a continuación, ejecutar un punto de conexión en esa red mediante
la asignación de IP estática:

# Example: Create a transparent network using static IP assignment

# A network create command for a transparent container network corresponding
to the physical network with IP prefix 10.123.174.0/23
C:\> docker network create -d transparent --subnet=10.123.174.0/23 --
gateway=10.123.174.1 MyTransparentNet
# Run a container attached to MyTransparentNet
C:\> docker run -it --network=MyTransparentNet --ip=10.123.174.105
windowsservercore cmd

No se admite la asignación de IP DHCP con redes L2Bridge

Solo se admite la asignación de DIRECCIONES IP estáticas con redes de contenedor
creadas mediante el controlador l2bridge. Como se indicó anteriormente, recuerde usar
los parámetros --subnet y --gateway para crear una red configurada para la asignación
de IP estática.

Las redes que aprovechan vSwitch externo deben tener su propio

adaptador de red.
Tenga en cuenta que si se crean varias redes que usan un vSwitch externo para la
conectividad (por ejemplo, Transparente, Puente L2, L2 Transparente) en el mismo host
de contenedor, cada una de ellas requiere su propio adaptador de red.

Asignación de IP en contenedores detenidos frente a contenedores

en ejecución
La asignación de IP estática se realiza directamente en el adaptador de red del
contenedor y solo se debe realizar cuando el contenedor está en estado DETENIDO. No
se admite la "adición activa" de adaptadores de red de contenedor o cambios en la pila
de red (en Windows Server 2016) mientras se ejecuta el contenedor.

El vSwitch existente (no visible para Docker) puede bloquear la

creación de red transparente.
Si se produce un error al crear una red transparente, es posible que haya un vSwitch
externo en el sistema que Docker no detectó automáticamente y, por tanto, impide que
la red transparente esté enlazada al adaptador de red externo del host de contenedor.

Al crear una red transparente, Docker crea un vSwitch externo para la red y, a
continuación, intenta enlazar el conmutador a un adaptador de red (externo): el
adaptador podría ser un adaptador de red de máquina virtual o el adaptador de red
físico. Si ya se ha creado un vSwitch en el host de contenedor y es visible para Docker, el
motor de Docker de Windows usará ese modificador en lugar de crear uno nuevo. Sin
embargo, si el vSwitch que se creó fuera de banda (es decir, creado en el host de
contenedor mediante el Administrador de HYper-V o PowerShell) y aún no está visible
para Docker, el motor de Docker de Windows intentará crear un nuevo vSwitch y, a
continuación, no podrá conectar el nuevo conmutador al adaptador de red externo del
host de contenedor (ya que el adaptador de red ya estará conectado al conmutador que
se creó fuera de banda).

Por ejemplo, este problema surgiría si primero creara un nuevo vSwitch en el host
mientras se estaba ejecutando el servicio docker y, a continuación, intente crear una red
transparente. En este caso, Docker no reconocería el modificador que creó y crearía un
nuevo vSwitch para la red transparente.

Hay tres enfoques para resolver este problema:

Por supuesto, puede eliminar el vSwitch que se creó fuera de banda, lo que
permitirá a Docker crear un nuevo vSwitch y conectarlo al adaptador de red host
sin problema. Antes de elegir este enfoque, asegúrese de que el vSwitch fuera de
banda no está siendo utilizado por otros servicios (por ejemplo, Hyper-V).
Como alternativa, si decide usar un vSwitch externo que se creó fuera de banda,
reinicie los servicios docker y HNS para que el conmutador sea visible para Docker.

PS C:\> restart-service hns

PS C:\> restart-service docker

Otra opción es usar la opción "-o com.docker.network.windowsshim.interface" para

enlazar el vSwitch externo de la red transparente a un adaptador de red específico
que aún no está en uso en el host de contenedor (es decir, un adaptador de red
distinto del que usa el vSwitch que se creó fuera de banda). La opción "-o" se
describe más adelante en la sección Creación de varias redes transparentes en un
único host de contenedor de este documento.

Entornos de trabajo de Windows Server 2016

Aunque seguimos agregando nuevas características e impulsamos el desarrollo, algunas
de estas características no se migrarán a plataformas anteriores. En su lugar, el mejor
plan de acción es "ponerse en el tren" para las actualizaciones más recientes de
Windows 10 y Windows Server. En la sección siguiente se enumeran algunas soluciones
alternativas y advertencias que se aplican a Windows Server 2016 y versiones anteriores
de Windows 10 (es decir, antes de 1704 Creators Update)

Varias redes NAT en el host de contenedor WS2016

Las particiones de las nuevas redes NAT deben crearse en el prefijo de red NAT interno
más grande. El prefijo se puede encontrar ejecutando el siguiente comando desde
PowerShell y haciendo referencia al campo "InternalIPInterfaceAddressPrefix".
 PS C:\> Get-NetNAT

Por ejemplo, el prefijo interno de red NAT del host podría ser 172.16.0.0/16. En este
caso, Docker se puede usar para crear redes NAT adicionales siempre que sean un
subconjunto del prefijo 172.16.0.0/16. Por ejemplo, se podrían crear dos redes NAT con
los prefijos IP 172.16.1.0/24 (puerta de enlace, 172.16.1.1) y 172.16.2.0/24 (puerta de
enlace, 172.16.2.1).

C:\> docker network create -d nat --subnet=172.16.1.0/24 --

gateway=172.16.1.1 CustomNat1
C:\> docker network create -d nat --subnet=172.16.2.0/24 --
gateway=172.16.1.1 CustomNat2

Las redes recién creadas se pueden enumerar mediante:

C:\> docker network ls

Docker Compose
Docker Compose se puede usar para definir y configurar redes de contenedor junto
con los contenedores o servicios que usarán esas redes. La clave "networks" de
Compose se usa como clave de nivel superior para definir las redes a las que se
conectarán los contenedores. Por ejemplo, la sintaxis siguiente define la red NAT
preexistente creada por Docker para que sea la red "predeterminada" para todos los
contenedores o servicios definidos en un archivo compose determinado.

networks:
default:
external:
name: "nat"

Del mismo modo, se puede usar la sintaxis siguiente para definir una red NAT
personalizada.

Nota: La "red NAT personalizada" definida en el ejemplo siguiente se define como

una partición del prefijo interno NAT existente del host de contenedor. Consulte la
 sección anterior, "Varias redes NAT", para obtener más contexto.

networks:
default:
driver: nat
ipam:
driver: default
config:
- subnet: 172.16.3.0/24

Para obtener más información sobre cómo definir o configurar redes de contenedor
mediante Docker Compose, consulte la referencia de archivo de Compose.
Introducción a Container Storage
Artículo • 05/02/2025

En este tema se proporciona información general sobre las distintas formas en que los
contenedores usan el almacenamiento en Windows. Los contenedores se comportan de
forma diferente a las máquinas virtuales en lo que respecta al almacenamiento. Por
naturaleza, los contenedores están construidos para evitar que una aplicación que se
ejecute dentro de ellos registre el estado en todo el sistema de archivos del host. Los
contenedores usan un espacio "temporal" de manera predeterminada, pero Windows
también proporciona un medio para conservar el almacenamiento.

Espacio temporal
Los contenedores de Windows usan de forma predeterminada almacenamiento efímero.
Toda la E/S del contenedor se produce en un "espacio temporal" y cada contenedor
obtiene su propio espacio temporal. La creación de archivos y las escrituras de archivos
se registran en el espacio de temporal y no llegan al host. Cuando se detiene una
instancia de contenedor, se eliminan todos los cambios que se hayan producido en el
espacio temporal. Cuando se inicia una nueva instancia de contenedor, se le
proporciona un nuevo espacio de trabajo temporal.

Almacenamiento de capas
Como se describe en la información general de contenedores de , las imágenes de
contenedor son un conjunto de archivos expresados como una serie de capas. El
almacenamiento de capas es todos los archivos integrados en el contenedor. Cada vez
que docker pull , se aplica a docker run ese contenedor, es lo mismo.

Dónde se almacenan las capas y cómo cambiarla

En una instalación predeterminada, las capas se almacenan en C:\ProgramData\docker y
se dividen entre los directorios "image" y "windowsfilter". Puede cambiar dónde se
almacenan las capas mediante la configuración de docker-root , como se muestra en la
documentación del motor de Docker de en Windows.

７ Nota
 Solo se admite NTFS para el almacenamiento de capas. No se admiten ReFS y
volúmenes compartidos del clúster (CSV).

No debe modificar ningún archivo de los directorios de capa; se administran

cuidadosamente mediante comandos como:

docker images
docker rmi
docker pull
docker load
docker save

Operaciones admitidas en el almacenamiento en capas

Los contenedores en ejecución pueden utilizar la mayoría de las operaciones NTFS con
la excepción de las transacciones. Esto incluye la configuración de ACL y todas las ACL
se comprueban dentro del contenedor. Si desea ejecutar procesos como varios usuarios
dentro de un contenedor, puede crear usuarios en el Dockerfile con RUN net user
/create ... , establecer ACL de archivo y, a continuación, configurar procesos para que

se ejecuten con ese usuario mediante la directiva USER de Dockerfile .

Almacenamiento persistente
Los contenedores de Windows admiten mecanismos para proporcionar almacenamiento
persistente mediante montajes de enlace y volúmenes. Para más información, consulte
Almacenamiento Persistente en Contenedores.

Límites de almacenamiento
Un patrón común para las aplicaciones de Windows es consultar la cantidad de espacio
libre en disco antes de instalar o crear nuevos archivos o como desencadenador para
limpiar archivos temporales. Con el objetivo de maximizar la compatibilidad de
aplicaciones, la unidad C: en un contenedor de Windows representa un tamaño libre
virtual de 20 GB.

Es posible que algunos usuarios quieran invalidar este valor predeterminado y

configurar el espacio libre en un valor menor o mayor. Esto se puede lograr con la
opción "size" dentro de la configuración "storage-opt".

Ejemplo
Línea de comandos: docker run --storage-opt "size=50GB"
mcr.microsoft.com/windows/servercore:ltsc2019 cmd

O bien, puede cambiar el archivo de configuración de Docker directamente:

Docker

"storage-opts": [
"size=50GB"
]

 Sugerencia

Este método también funciona para la compilación de Docker. Consulte el

documento configuración de docker para obtener más información sobre cómo
modificar el archivo de configuración de Docker.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Almacenamiento persistente en
contenedores
Artículo • 23/01/2025

Puede haber casos en los que sea importante que una aplicación pueda conservar los
datos en un contenedor o en los que quieras mostrar los archivos en un contenedor que
no se incluyeron en el tiempo de compilación del contenedor. El almacenamiento
persistente se puede proporcionar a los contenedores de un par de maneras:

Enlazar montajes
Volúmenes con nombre

Docker tiene una excelente introducción de cómo usar volúmenes por lo que es mejor
leerla primero. El resto de esta página se centra en las diferencias entre Linux y Windows
y proporciona ejemplos en Windows.

Enlazar montajes
Enlazar montajes permite que un contenedor comparta un directorio con el host. Esto
es útil si quieres un lugar para almacenar archivos en la máquina local que están
disponibles si reinicias un contenedor o quieres compartirlos con varios contenedores.
Si quieres que el contenedor se ejecute en varias máquinas con acceso a los mismos
archivos, debe usarse en su lugar un volumen con nombre o el montaje SMB.

７ Nota

No se admite el montaje de enlace directamente en volúmenes compartidos de

clúster (CSV), las máquinas virtuales que funcionan como host de contenedores se
pueden ejecutar en un volumen CSV.

Permisos
El modelo de permiso utilizado para enlazar montajes varía según el nivel de
aislamiento de tu contenedor.

Los contenedores que usan el aislamiento de Hyper-V utilizan un modelo simple de

permisos de solo lectura o de lectura y escritura. Se acceden a los archivos en el host
mediante la cuenta LocalSystem . Si obtienes acceso denegado en el contenedor,
asegúrate de que LocalSystem tenga acceso a ese directorio en el host. Cuando se usa
la marca de solo lectura, los cambios realizados en el volumen dentro del contenedor no
se mostrarán ni permanecerán en el directorio del host.

Los contenedores de Windows con aislamiento de procesos son ligeramente diferentes,

ya que usan la identidad del proceso dentro del contenedor para acceder a datos, lo
que significa que se aceptan las ACL de archivos. La identidad del proceso que se
ejecuta en el contenedor ("ContainerAdministrator" en Windows Server Core y
"ContainerUser" en contenedores de Nano Server, de manera predeterminada) se
utilizará para tener acceso a los archivos y directorios en el volumen montado en lugar
de LocalSystem y necesitará tener acceso para usar los datos.

Dado que estas identidades solo existen en el contexto del contenedor, no en el host
donde se almacenan los archivos, debes usar un grupo de seguridad conocido, como
Authenticated Users al configurar las ACL para tener acceso a los contenedores.

２ Advertencia

No unas mediante enlace directorios confidenciales, como por ejemplo, C:\ en un

contenedor que no es de confianza. Esto le permitiría cambiar archivos en el host al
que normalmente no tendría acceso y podría crear una infracción de seguridad.

Ejemplo de uso:

docker run -v c:\ContainerData:c:\data:RO para acceso de solo lectura

docker run -v c:\ContainerData:c:\data:RW para acceso de lectura y escritura

docker run -v c:\ContainerData:c:\data para acceso de lectura y escritura (opción

predeterminada)

Symlinks
Symlinks se resuelven en el contenedor. Si unes mediante enlace una ruta de acceso de
host a un contenedor que es un symlink o incluye symlinks: el contenedor no podrá
tener acceso a ellos.

Montajes de SMB
En Windows Server, versión 1709 y posteriores, una característica denominada
"Asignación global de SMB" hace posible montar un recurso compartido de SMB en el
host y luego pasar los directorios del recurso compartido a un contenedor. El
contenedor no debe configurarse con un servidor, recurso compartido, nombre de
usuario o contraseña en concreto: todo se administra en el host en su lugar. El
contenedor funcionará de la misma forma que si tuviera el almacenamiento local.

Pasos de configuración

1. En el host de contenedor, asigna globalmente el recurso compartido SMB remoto:

$creds = Get-Credential
New-SmbGlobalMapping -RemotePath \\contosofileserver\share1 -Credential
$creds -LocalPath G:

Este comando usará las credenciales para autenticarse en el servidor SMB remoto.
Después asigna la ruta de acceso de recurso compartido remoto a la letra de
unidad G: (puede ser cualquier otra letra de unidad disponible). Los contenedores
creados en este host del contenedor ahora pueden tener sus volúmenes de datos
asignados a una ruta de acceso en la unidad G:.

７ Nota

Al usar la asignación global de SMB para contenedores, todos los usuarios en

el host del contenedor pueden acceder al recurso compartido remoto.
Cualquier aplicación que se ejecuta en el host del contenedor también tendrá
acceso al recurso compartido remoto asignado.

2. Cree contenedores con volúmenes de datos asignados a Docker de recurso

compartido de SMB montado globalmente. Ejecute -it --name demo -v
g:\ContainerData:c:\AppData1 mcr.microsoft.com/windows/servercore:ltsc2019
cmd.exe.

Dentro del contenedor, c:\AppData1 se asignará al directorio "ContainerData" del

recurso compartido remoto. Todos los datos almacenados en el recurso
compartido remoto asignado globalmente estarán disponibles para aplicaciones
dentro del contenedor. Varios contenedores pueden obtener acceso de lectura y
escritura a estos datos compartidos con el mismo comando.

Esta compatibilidad de asignación global de SMB es una característica de cliente de

SMB que puede funcionar en la parte superior de cualquier servidor SMB compatible,
entre los que se incluyen:
 Servidor de archivos de escalabilidad horizontal en la parte superior de Storage
Spaces Direct (S2D) o una SAN tradicional
Azure Files (recurso compartido de SMB)
Servidor de archivos tradicional
Implementación de terceros del protocolo SMB (ejemplo: dispositivos NAS)

７ Nota

La asignación global de SMB no admite carpetas de espacios de nombres DFS

(DFSN). Por ejemplo, si asigna un recurso compartido raíz DFSN con New-
SmbGlobalMapping -LocalPath Z: -RemotePath \\contoso.com\share1' , al leer los

destinos de carpeta de la raíz se devolverá el error "No se puede acceder a la

ubicación de red".

Volúmenes con nombre

Los volúmenes con nombre te permiten crear un volumen según el nombre, asignarle a
un contenedor y reutilizarlo más adelante con el mismo nombre. No tienes que realizar
un seguimiento de la ruta de acceso real de dónde se creó, solo el nombre. Docker
Engine en Windows tiene un complemento de volumen con nombre integrado que
puede crear volúmenes en la máquina local. Un complemento adicional es necesario si
quieres usar volúmenes con nombre en varias máquinas.

Pasos de ejemplo:

1. docker volume create unwound : Crear un volumen denominado "unwound"

2. docker run -v unwound:c:\data microsoft/windowsservercore : Iniciar un
contenedor con el volumen asignado a c:\data.
3. Escribir algunos archivos en c:\data en el contenedor y luego detener el
contenedor
4. docker run -v unwound:c:\data microsoft/windowsservercore : Iniciar un nuevo
contenedor
5. Ejecutar dir c:\data en el contenedor nuevo: los archivos siguen estando ahí

７ Nota

Windows Server convertirá los nombres de las rutas de acceso de destino (la ruta
de acceso dentro del contenedor) en minúsculas; es decir, -v unwound:c:\MyData , o
-v unwound:/app/MyData en contenedores de Linux, hará que se asigne (y se cree si
 no existe) un directorio dentro del contenedor de c:\mydata , o /app/mydata en
contenedores de Linux.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Dispositivos en contenedores en
Windows
Artículo • 05/02/2025

De forma predeterminada, los contenedores de Windows tienen acceso mínimo a los

dispositivos host, al igual que los contenedores de Linux. Hay ciertas cargas de trabajo
en las que es beneficioso, o incluso imperativo, tener acceso y comunicarse con
dispositivos de hardware host. En esta guía se tratan los dispositivos que se admiten en
contenedores y cómo empezar.

Prerrequisitos
Para que esta característica funcione, el entorno debe cumplir los siguientes requisitos:

El host de contenedor debe ejecutar Windows Server 2019 o Windows 10, versión
1809 o posterior.
La versión de la imagen base del contenedor debe ser 1809 o posterior.
Los contenedores deben ser contenedores de Windows que se ejecutan en modo
aislado del proceso.
El host de contenedor debe ejecutar Docker Engine 19.03 o posterior.

Ejecución de un contenedor con un dispositivo

Para iniciar un contenedor con un dispositivo, use el siguiente comando:

shell

docker run --isolation=process --device="class/{interface class GUID}"

mcr.microsoft.com/windows/servercore:1809

Debe reemplazar {interface class guid} por un GUID de clase de interfaz de

dispositivo adecuado, que se puede encontrar en la sección siguiente.

Para iniciar un contenedor con varios dispositivos, use el siguiente comando y encadene
varios argumentos de --device .

shell

docker run --isolation=process --device="class/{interface class GUID}" --

device="class/{interface class GUID}"
 mcr.microsoft.com/windows/servercore:1809

En Windows, todos los dispositivos declaran una lista de clases de interfaz que
implementan. Al pasar este comando a Docker, se asegurará de que todos los
dispositivos que se identifiquen como implementando la clase solicitada se integrarán
en el contenedor.

Esto significa que no va a asignar el dispositivo fuera del host. En su lugar, el anfitrión lo
comparte con el contenedor. Del mismo modo, dado que va a especificar un GUID de
clase, todos los dispositivos que implementan ese GUID se compartirán con el
contenedor.

Qué dispositivos son compatibles

Actualmente se admiten los siguientes dispositivos (y sus GUID de clase de interfaz de
dispositivo):

ﾉ Expandir tabla

Tipo de dispositivo GUID de clase de interfaz

GPIO 916EF1CB-8426-468D-A6F7-9AE8076881B3

Bus I2C A11EE3C6-8421-4202-A3E7-B91FF90188E4

Puerto COM 86E0D1E0-8089-11D0-9CE4-08003E301F73

Bus SPI DCDE6AF9-6610-4285-828F-CAAF78C424CC

Aceleración de DirectX por GPU Vea la documentación sobre aceleración de la GPU

） Importante

La compatibilidad con dispositivos depende del controlador. Intentar pasar los

GUIDs de clase no definidos en la tabla anterior puede dar lugar a un
comportamiento indefinido.

Compatibilidad con contenedores de Windows

aislados de Hyper-V
Actualmente no se admite la asignación de dispositivos y el uso compartido de
dispositivos para cargas de trabajo en contenedores de Windows aislados de Hyper-V.
Compatibilidad con contenedores Linux
aislados por Hyper-V
Actualmente no se admite la asignación de dispositivos y el uso compartido de
dispositivos para cargas de trabajo en contenedores de Linux aislados de Hyper-V.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Aceleración de GPU en contenedores de
Windows
Artículo • 05/02/2025

Para muchas cargas de trabajo en contenedor, los recursos de proceso de CPU

proporcionan un rendimiento suficiente. Sin embargo, para una determinada clase de
carga de trabajo, la potencia de proceso paralela masiva que ofrecen las GPU (unidades
de procesamiento de gráficos) puede acelerar las operaciones por órdenes de
magnitud, lo que reduce el costo y mejora enormemente el rendimiento.

Las GPU ya son una herramienta común para muchas cargas de trabajo populares,
desde la representación tradicional y la simulación hasta el entrenamiento e inferencia
del aprendizaje automático. Los contenedores de Windows admiten la aceleración de
GPU para DirectX y todos los marcos basados en él.

７ Nota

Esta característica está disponible en Docker Desktop, versión 2.1 y Motor de

Docker: Enterprise, versión 19.03 o posterior.

Prerrequisitos
Para que esta característica funcione, el entorno debe cumplir los siguientes requisitos:

El host de contenedor debe ejecutar Windows Server 2019 o Windows 10, versión
1809 o posterior.
La imagen base del contenedor debe ser mcr.microsoft.com/windows:1809 o
posterior. Actualmente no se admiten imágenes de contenedor de Windows Server
Core y Nano Server.
El host de contenedor debe ejecutar Docker Engine 19.03 o posterior.
El host de contenedor debe tener una GPU que ejecute controladores de pantalla
versión WDDM 2.5 o posterior.

Para comprobar la versión de WDDM de los controladores de pantalla, ejecute directX

Diagnostic Tool (dxdiag.exe) en el host del contenedor. En la pestaña "Pantalla" de la
herramienta, busque en la sección "Controladores" como se indica a continuación.
Ejecución de un contenedor con aceleración de
GPU
Para iniciar un contenedor con aceleración de GPU, ejecute el siguiente comando:

shell

docker run --isolation process --device class/5B45201D-F2F2-4F3B-85BB-

30FF1F953599 mcr.microsoft.com/windows:1809

） Importante

DirectX (y todos los marcos basados en él) son las únicas API que se pueden
acelerar con una GPU en la actualidad. No se admiten marcos de terceros.

Compatibilidad con contenedores de Windows

con aislamiento de Hyper-V
Actualmente no se admite la aceleración de GPU para cargas de trabajo en
contenedores de Windows aislados de Hyper-V.

Compatibilidad con contenedores de Linux con

aislamiento de Hyper-V
Actualmente no se admite la aceleración de GPU para cargas de trabajo en
contenedores de Linux aislados de Hyper-V.

Más información
Para obtener un ejemplo completo de una aplicación DirectX en contenedor que
aprovecha la aceleración de GPU, consulte ejemplo de contenedor de DirectX .

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Optimización antivirus para
contenedores de Windows
Artículo • 15/06/2023

La información de esta página se aplica a:

Windows 10, versiones 1607 y posteriores

Windows Server 2016 y versiones posteriores
Productos antivirus (AV) que se ejecutan en el host

En este tema se describen las optimizaciones que los productos av pueden usar para
evitar el examen redundante de los archivos de contenedor de Windows y ayudar a
mejorar el tiempo de inicio del contenedor.

Información general sobre contenedores

La característica Contenedor de Windows está diseñada para simplificar la distribución y
la implementación de aplicaciones. Para obtener más información, consulte la
introducción a los contenedores de Windows.

Los contenedores se construyen a partir de cualquier número de capas de paquete. El

paquete del sistema operativo base de Windows forma la primera capa.

Cada contenedor tiene un volumen aislado que representa el volumen del sistema en
ese contenedor. Un filtro de aislamiento de contenedor (wcifs.sys) proporciona una
superposición virtual de capas de paquete en este volumen de contenedor. La
superposición se logra mediante marcadores de posición (puntos de reanálisis). El
volumen se inicializa con marcadores de posición antes de que el contenedor acceda
primero a la ruta de acceso superpuesta. Las lecturas de los archivos de marcador de
posición se dirigen al archivo del paquete de respaldo. De este modo, varios volúmenes
de contenedor pueden acceder al mismo flujo de datos del archivo de paquete
subyacente.

Si un contenedor modifica un archivo, el filtro de aislamiento realiza la copia en escritura

y reemplaza el marcador de posición por el contenido del archivo de paquete. Esto
interrumpe la "vinculación" con el archivo de paquete para ese contenedor
determinado.

Redireccionamiento de lectura
El filtro de aislamiento redirige las lecturas de un archivo de marcador de posición a la
capa de paquete adecuada. El redireccionamiento se realiza en el nivel del filtro. Dado
que el filtro está debajo del intervalo de AV, los filtros av no verán el redireccionamiento
de lectura. AV tampoco verá las aperturas de los archivos de paquete realizados para
configurar el redireccionamiento.

Un filtro AV tiene una vista completa de todas las operaciones en el volumen del
sistema de contenedor. Ve las operaciones en los archivos de marcador de posición, así
como en las modificaciones del archivo o en las nuevas adiciones de archivos.

Problema de examen redundante

Es probable que haya muchos contenedores en función de las mismas capas de
paquete. El mismo flujo de datos de un archivo de paquete determinado proporcionará
los datos para los marcadores de posición en varios volúmenes del sistema de
contenedor. Como resultado, existe la posibilidad de realizar exámenes de AV
redundantes de los mismos datos en cada contenedor. Esto tiene un impacto negativo
innecesario en el rendimiento de los contenedores. Se trata de un costo significativo
dado que se espera que los contenedores se inicien rápidamente y que pueden ser de
corta duración.

Enfoque recomendado
Para evitar el examen redundante en contenedores, se recomienda que un producto av
modifique su comportamiento, como se describe a continuación. Es el producto av para
determinar el beneficio de riesgo y recompensa a sus clientes para este enfoque. Para
obtener más información sobre esto, consulte la sección Ventajas y riesgos en la parte
inferior de esta página.

1. Instalación del paquete

Durante la instalación del paquete, las herramientas de administración diseñarán
archivos en el paquete bajo la raíz de la capa. El filtro av debe continuar examinando los
archivos a medida que se colocan en la raíz del paquete y normalmente lo haría. Esto
garantiza que todos los archivos de las capas estén inicialmente limpios con respecto al
malware.

2. Inicio y ejecución del contenedor

Para el examen en tiempo real de un volumen de contenedor, los VV deben examinarse
de forma que evite la redundancia. Los archivos de marcador de posición necesitan
tener en cuenta especial. Los archivos modificados por el contenedor o los nuevos
archivos creados en el contenedor no se redirigen, por lo que el examen redundante no
es un problema.

Para evitar exámenes redundantes, el filtro AV primero debe identificar volúmenes de

contenedor y marcadores de posición en esos volúmenes. Por varias razones, no hay
ninguna manera directa de que un filtro av consulte si un volumen es un volumen de
contenedor o si un archivo determinado es un archivo de marcador de posición. El filtro
de aislamiento oculta el punto de reanálisis del marcador de posición por motivos de
compatibilidad de aplicaciones (algunas aplicaciones no se comportan correctamente si
reconocen que están accediendo a puntos de reanálisis). Además, un volumen es solo
un volumen de contenedor mientras se ejecuta un contenedor. El contenedor se puede
detener y el volumen puede permanecer remontado. En su lugar, en la creación previa,
el filtro av debe consultar el objeto de archivo para determinar si se abre en el contexto
de un contenedor. A continuación, puede adjuntar y ECP a la creación y recibir el estado
del marcador de posición al finalizar la creación.

Los siguientes cambios son necesarios en el producto av:

Durante la creación previa en un volumen de contenedor, adjunte un ECP a

Create CallbackData que recibirá la información del marcador de posición. Estas
creaciones se pueden identificar consultando los parámetros SILO desde el objeto
fileobject mediante IoGetSiloParameters. Tenga en cuenta que el filtro debe
especificar el tamaño en la estructura WCIFS_REDIRECTION_ECP_CONTEXT . Todos
los demás campos son campos out establecidos si se confirma el ECP.

En la creación posterior, si se confirma el ECP, examine las marcas de

redireccionamiento de ECP. Las marcas indicarán si se ha realizado el servicio
abierto desde la capa de paquete o desde la raíz temporal (archivos nuevos o
modificados). Las marcas también indicarán si la capa de paquete está registrada y
si es remota.

En el caso de las aperturas que se aparecen desde una capa remota, AV debe
omitir el examen del archivo. Esto se indica mediante las marcas de
redireccionamiento: WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_LAYER &&
WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_REMOTE_LAYER

Se puede suponer que las capas remotas se han examinado en el host remoto.
Los paquetes de contenedor de Hyper-V son remotos a la máquina virtual de la
utilidad que hospeda el contenedor. Esos paquetes se examinarán normalmente
en el host de Hyper-V cuando la máquina virtual de la utilidad acceda a ellos a
través del bucle de bucle SMB.

Dado que VolumeGUID y FileId no se aplican a través de remote, estos campos

no se establecerán.

En el caso de las aperturas que se aparecen desde una capa registrada, AV debe
omitir el examen del archivo. Esto se indica mediante las marcas de
redireccionamiento: WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_LAYER &&
WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_REGISTERED_LAYER

La capa registrada se debe examinar de forma asincrónica durante la instalación

del paquete y después de la actualización de la firma.

７ Nota

Es posible que el sistema no identifique las capas registradas en el futuro.

En este caso, los archivos de capa local deben identificarse individualmente
como se describe en la última viñeta.

Para las aperturas que se proporcionan desde una capa de paquete local, AV
debe usar volumeGUID y FileId proporcionados del archivo de capa para
determinar si el archivo debe examinarse. Esto probablemente requerirá av para
compilar una memoria caché de archivos examinados indexados por guid de
volumen y FileId. Esto se indica mediante la marca de redireccionamiento:
WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_LAYER

En el caso de los archivos nuevos o modificados en la ubicación temporal, el

producto av debe examinar los archivos y realizar su corrección normal. Esto se
indica mediante la marca de redireccionamiento:
WCIFS_REDIRECTION_FLAGS_CREATE_SERVICED_FROM_SCRATCH

Dado que no hay ningún archivo de capa en este caso, No se establecerá

VolumeGUID ni FileId.

No guarde "este archivo se envía desde la capa" como marcador permanente

en su contexto de flujo. Un archivo que se abastezó inicialmente desde la raíz
de la capa se puede modificar después de la creación. En este caso, una
creación posterior para el mismo archivo puede indicar que se está realizando el
servicio de creación desde el volumen del contenedor. El filtro av debe
comprender que esto puede ocurrir.
No use la clave del Registro
LayerRootLocations.
En el pasado, se recomienda usar la clave del LayerRootLocations Registro para obtener
la ubicación de la imagen base. Los productos av ya no deben usar esta clave del
Registro. En su lugar, use el enfoque recomendado en este tema para evitar el examen
redundante.

La ubicación del Registro que se había usado para registrar las capas de paquete:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows

NT\CurrentVersion\Virtualization\LayerRootLocations

Ventajas y riesgos
Tenga en cuenta las siguientes ventajas y riesgos para usar estas nuevas optimizaciones
para los productos av.

Ventajas
No afecta al inicio o tiempo de ejecución del contenedor (incluso para el primer
contenedor).
Evita el examen del mismo contenido en varios contenedores.
Funciona para contenedores de Windows Server. Para el contenedor de Hyper-V,
esto funciona para los paquetes, pero requiere trabajo adicional para ejecutar el
contenedor.

Riesgos
Si se inicia un contenedor en el tiempo entre la actualización de firma y el siguiente
examen antimalware proactivo programado, los archivos ejecutados en el contenedor
no se examinan con respecto a las firmas antimalware más recientes. Para mitigar este
riesgo, el producto av podría omitir los exámenes de los archivos redirigidos solo si no
ha habido una actualización de firma desde el último examen proactivo. Esto limitaría la
degradación del rendimiento del contenedor hasta que se complete un examen
proactivo con las firmas más recientes. Opcionalmente, el producto av puede
desencadenar un examen proactivo en esta situación para que los lanzamientos
posteriores de contenedores sean más eficaces.
Herramientas de plataforma de
contenedor en Windows
Artículo • 05/02/2025

La plataforma de contenedor de Windows se está expandiendo. Docker fue la primera

parte del recorrido del contenedor, ahora estamos creando otras herramientas de
plataforma de contenedor.

containerd/cri : novedad en Windows Server 2019 y Windows 10 1809.

runhcs : un host de contenedores de Windows equivalente a runc.
hcs: el Servicio de proceso de host y adaptadores útiles para facilitar el uso.
hcsshim
dotnet-computevirtualization

En este artículo se habla de la plataforma de contenedor Windows y Linux, así como de

cada herramienta de plataforma de contenedor.

Plataforma de contenedor de Windows y Linux

En entornos de Linux, las herramientas de administración de contenedores como Docker
se basan en un conjunto más granular de herramientas de contenedor: runc y
containerd .
arquitectura de Docker en Linux

runc es una herramienta de línea de comandos de Linux para crear y ejecutar

contenedores según la especificación de tiempo de ejecución del contenedor de OCI de

.

containerd es un demonio que administra el ciclo de vida del contenedor desde la

descarga y el desempaquetado de la imagen de contenedor a su ejecución y

supervisión.

En Windows, hemos tomado un enfoque diferente. Cuando empezamos a trabajar con

Docker para admitir contenedores de Windows, nos basamos directamente en el HCS
(Servicio de proceso de host). Esta entrada de blog está llena de información sobre
por qué creamos hcS y por qué tomamos este enfoque para los contenedores
inicialmente.
En este momento, Docker todavía llama directamente a HCS. Sin embargo, en el futuro,
las herramientas de administración de contenedores se expandirán para incluir
contenedores de Windows y el host de contenedor de Windows, y podrían llamar a
containerd y runhcs de la misma manera que llaman a containerd y runc en Linux.

runhcs
runhcs es una bifurcación de runc . Al igual que runc , runhcs es un cliente de línea de

comandos para ejecutar aplicaciones empaquetadas según el formato Open Container

Initiative (OCI) y es una implementación compatible de la especificación Open Container
Initiative.

Las diferencias funcionales entre runc y runhcs incluyen:

runhcs se ejecuta en Windows. Se comunica con el HCS para crear y administrar

contenedores.

runhcs puede ejecutar una variedad de tipos de contenedor diferentes.

Aislamiento de Hyper-V de Windows y Linux

Contenedores de procesos de Windows (la imagen de contenedor debe
coincidir con el host del contenedor)

Uso:
 Símbolo del sistema de Windows

runhcs run [ -b bundle ] <container-id>

<container-id> es el nombre de la instancia de contenedor que va a iniciar. El nombre

debe ser único en el host del contenedor.

El directorio de paquete (con -b bundle ) es opcional. Al igual que con runc, los
contenedores se configuran mediante agrupaciones. El paquete de un contenedor es el
directorio con el archivo de especificación OCI del contenedor, "config.json". El valor
predeterminado de "bundle" es el directorio actual.

El archivo de especificación OCI, "config.json", tiene que tener dos campos para
ejecutarse correctamente:

Ruta de acceso al espacio temporal del contenedor

Ruta de acceso al directorio de capa del contenedor

Los comandos de contenedor disponibles en runhcs incluyen:

Herramientas para crear y ejecutar un contenedor

run crea y ejecuta un contenedor
create crea un contenedor

Herramientas para administrar procesos que se ejecutan en un contenedor:

iniciar ejecuta el proceso definido por el usuario en un contenedor creado
exec ejecuta un nuevo proceso dentro del contenedor
pause suspende todos los procesos dentro del contenedor
reanudar reanuda todos los procesos que fueron pausados anteriormente
ps ps muestra los procesos que se ejecutan dentro de un contenedor

Herramientas para administrar el estado de un contenedor

estado muestra el estado de un contenedor
kill envía la señal especificada (valor predeterminado: SIGTERM) al proceso de
inicialización del contenedor
delete elimina los recursos mantenidos por el contenedor que a menudo se
usan con el contenedor desasociado

El único comando que se podría considerar multicontenedor es list. Enumera los

contenedores en ejecución o en pausa iniciados por runhcs con la raíz especificada.

HCS
Tenemos dos contenedores disponibles en GitHub para interactuar con HCS. Dado que
HCS es una API de C, los contenedores facilitan la llamada a HCS desde lenguajes de
nivel superior.

hcsshim - HCSShim está escrito en Go y es la base para runhcs. Toma la versión

más reciente de AppVeyor o céntela tú mismo.
dotnet-computevirtualization : es un contenedor de C# para HCS.

Si desea usar el HCS (ya sea directamente o a través de un contenedor), o desea hacer
un contenedor Rust/Haskell/InsertYourLanguage alrededor del HCS, deje un comentario.

Para un análisis más profundo de HCS, vea Presentación de DockerCon de John Stark .

containerd/cri

） Importante

La compatibilidad con CRI solo está disponible en Windows Server 2019/Windows

10 1809 y versiones posteriores.

Aunque las especificaciones de OCI definen un único contenedor, CRI (interfaz en

tiempo de ejecución de contenedor) describe los contenedores como cargas de trabajo
en un espacio compartido llamado pod. Los pods pueden contener una o más cargas de
trabajo de contenedor. Los pods permiten a los orquestadores de contenedores, como
Kubernetes y Service Fabric Mesh, controlar las cargas de trabajo agrupadas que deben
estar en el mismo host con algunos recursos compartidos, como memoria y vNET.

Aunque runHCS y containerd pueden administrarse en cualquier sistema Windows

Server 2016 o posterior, el soporte de Pods (grupos de contenedores) requirió cambios
significativos en las herramientas de contenedores en Windows. La compatibilidad con
CRI está disponible en Windows Server 2019/Windows 10 1809 y versiones posteriores.

Comentarios
¿Le ha resultado útil esta página?  Sí  No
LICENCIA COMPLEMENTARIA DE
SOFTWARE DE MICROSOFT PARA LA
IMAGEN BASE DE CONTENEDOR DE
WINDOWS
Artículo • 23/01/2025

Esta licencia complementaria es para la imagen base de contenedor de Windows

("Imagen de contenedor"). Si cumple los términos de esta licencia complementaria,
puede usar la imagen de contenedor como se describe a continuación.

IMAGEN SE SISTEMA OPERATIVO DE

CONTENEDOR
La imagen de contenedor solo se puede usar con una copia con licencia válida de:

Software windows Server Standard o Windows Server Datacenter (colectivamente

"Software de host de servidor") o software del sistema operativo Microsoft Windows
(versión 10) ("Software de host de cliente") o Windows 10 IoT Enterprise y Windows 10
IoT Core (colectivamente "Software de host de IoT"). El software host de servidor, el
software de host de cliente y el software de host de IoT se conocen colectivamente
como "software de host" y una licencia para el software host es una "licencia de host".

Es posible que no use la imagen de contenedor si no tiene una versión y edición

correspondientes de la licencia de host. Se pueden aplicar ciertas restricciones y
términos adicionales, que se describen en este documento. Si los términos de licencia
entran en conflicto con la licencia de host, esta licencia complementaria rige con
respecto a la imagen de contenedor. AL ACEPTAR ESTA LICENCIA COMPLEMENTARIA O
USAR LA IMAGEN DE CONTENEDOR, ACEPTA TODOS ESTOS TÉRMINOS. SI NO ACEPTA
NI CUMPLE ESTOS TÉRMINOS, ES POSIBLE QUE NO USE LA IMAGEN DE CONTENEDOR.

DEFINICIONES
Contenedor de Windows Server (sin aislamiento de Hyper-V) es una característica del
software de Microsoft Windows Server.

Contenedor de Windows Server con aislamiento de Hyper-V. La sección 2(k) de los

términos de licencia de Microsoft Windows Server se elimina en su totalidad y se
reemplaza por los términos revisados como se muestra en "ACTUALIZADO" a
continuación.

ACTUALIZADO: Contenedor de Windows Server con aislamiento de Hyper-V

(anteriormente conocido como contenedor de Hyper-V) es una tecnología de
contenedor en Windows Server que utiliza un entorno de sistema operativo virtual para
hospedar uno o varios contenedores de Windows Server. Cada instancia de aislamiento
de Hyper-V que se usa para hospedar uno o varios contenedores de Windows Server se
considera un entorno de sistema operativo virtual.

TÉRMINOS DE LICENCIA
Licencia de host. Los términos de licencia de host se aplican al uso de la imagen de
contenedor y los contenedores de Windows creados con la imagen de contenedor que
son distintas y independientes de una máquina virtual.

Derechos de uso. La imagen de contenedor se puede usar para crear un entorno de

sistema operativo Windows virtualizado aislado al que se agrega la funcionalidad
principal y significativa ("Imagen consolidada"). Puede usar la imagen de contenedor
para crear, compilar y ejecutar la imagen consolidada en el software host y distribuir la
imagen de contenedor solo como parte de la imagen consolidada. Novedades al
software host no puede actualizar la imagen de contenedor para que pueda volver a
crear contenedores de Windows basados en una imagen de contenedor actualizada.

Restricciones. Es posible que no quite este archivo de documento de licencia

complementaria de la imagen de contenedor. Es posible que no habilite el acceso
remoto a las aplicaciones que ejecute dentro del contenedor para evitar las tarifas de
licencia aplicables. No puede realizar ingeniería inversa, descompilar o desensamblar la
imagen de contenedor, o intentar hacerlo, excepto y solo en la medida en que requieran
los términos de licencia de terceros que rigen el uso de determinados componentes de
código abierto que se pueden incluir con el software. Se pueden aplicar restricciones
adicionales en la licencia de host.

TÉRMINOS ADICIONALES
Software de host de cliente. Al ejecutar una imagen de contenedor en el software host
de cliente, puede ejecutar cualquier número de la imagen de contenedor creada como
contenedores de Windows para fines de prueba o desarrollo únicamente. Es posible que
no use estos contenedores de Windows en un entorno de producción en software host
de cliente.
Software de host de IoT. Al ejecutar una imagen de contenedor en el software host de
IoT, puede ejecutar cualquier número de la imagen de contenedor creada como
contenedores de Windows para fines de prueba o desarrollo únicamente. Solo puede
usar la imagen de contenedor en un entorno de producción si ha acordado los Términos
de uso comerciales de Microsoft para Windows 10 imágenes principales en tiempo de
ejecución o la licencia de dispositivo de Windows 10 IoT Enterprise ("Contrato comercial
de Windows IoT"). Se aplican términos y restricciones adicionales en los contratos de IoT
Windows Commercial al uso de la imagen de contenedor en un entorno de producción.

Software de terceros. La imagen de contenedor puede incluir aplicaciones de terceros

con licencia bajo esta licencia complementaria o bajo sus propios términos. Los
términos de licencia, los avisos y las confirmaciones, si existen, para las aplicaciones de
terceros pueden ser accesibles en línea o https://aka.ms/thirdpartynotices en un
archivo de avisos adjuntos. Incluso si estas aplicaciones se rigen por otros acuerdos, la
declinación de responsabilidades, limitaciones y exclusiones de daños en la licencia de
host también se aplican en la medida permitida por la ley aplicable.

Componentes de código abierto. La imagen de contenedor puede contener software

con derechos de autor de terceros con licencia de código abierto licencias con
obligaciones de disponibilidad de código fuente. Las copias de esas licencias se incluyen
en el archivo ThirdPartyNotices u otro archivo de avisos adjuntos. Puede obtener el
código fuente correspondiente completo de Microsoft si y según sea necesario en la
licencia de código abierto pertinente mediante el envío de un pedido de dinero o un
cheque de $5.00 a: Equipo de cumplimiento del código fuente, Microsoft Corporation, 1
Microsoft Way, Redmond, WA 98052, EE. UU. Incluya el nombre "Licencia
complementaria de software de Microsoft para la imagen base de contenedor de
Windows", el nombre del componente de código abierto y el número de versión en la
línea de notas del pago. También puede encontrar una copia del origen en
https://aka.ms/getsource .

Comentarios
¿Le ha resultado útil esta página?  Sí  No
Solución de problemas
Artículo • 05/02/2025

¿Tiene problemas para configurar la máquina o ejecutar un contenedor? Hemos creado

un script de PowerShell para comprobar si hay problemas comunes. Inténtelo primero
para ver lo que encuentra y compartir los resultados.

PowerShell

Invoke-WebRequest https://aka.ms/Debug-ContainerHost.ps1 -UseBasicParsing |

Invoke-Expression

En el archivo Léame del script encontrará una lista de todas las pruebas que se
ejecutan, junto con soluciones comunes.

Si eso no ayuda a encontrar el origen del problema, publique la salida del script en el
foro de contenedores . Este es el mejor lugar para obtener ayuda de la comunidad,
incluidos los desarrolladores y windows Insider.

Búsqueda de registros
Hay varios servicios que se usan para administrar contenedores de Windows. En las
secciones siguientes se muestra dónde obtener registros para cada servicio.

Registros de contenedor de Docker

El comando docker logs captura los registros de un contenedor de STDOUT/STDERR,
las ubicaciones de depósito de registros de aplicaciones estándar para las aplicaciones
Linux. Normalmente, las aplicaciones de Windows no inician sesión en STDOUT/STDERR;
en su lugar, inician sesión en ETW, registros de eventos o archivos de registro, entre
otros.

Log Monitor , una herramienta de código abierto compatible con Microsoft, ya está
disponible en github. Log Monitor puentea los registros de aplicaciones de Windows a
STDOUT/STDERR. El Monitor de registro se configura a través de un archivo de
configuración.

Uso del monitor de registro

LogMonitor.exe y LogMonitorConfig.json deben incluirse en el mismo directorio de
LogMonitor.

El Monitor de registro se puede usar en un patrón de uso de SHELL:

Output

SHELL ["C:\\LogMonitor\\LogMonitor.exe", "cmd", "/S", "/C"]

CMD c:\windows\system32\ping.exe -n 20 localhost

O un patrón de uso de ENTRYPOINT.

Output

ENTRYPOINT C:\LogMonitor\LogMonitor.exe c:\windows\system32\ping.exe -n 20

localhost

Ambos usos de ejemplo encapsulan la aplicación ping.exe. Otras aplicaciones (como

IIS.ServiceMonitor ) se pueden anidar con Log Monitor de forma similar:

Output

COPY LogMonitor.exe LogMonitorConfig.json C:\LogMonitor\

WORKDIR /LogMonitor
SHELL ["C:\\LogMonitor\\LogMonitor.exe", "powershell.exe"]

# Start IIS Remote Management and monitor IIS

ENTRYPOINT Start-Service WMSVC; `
C:\ServiceMonitor.exe w3svc;

El Monitor de registro inicia la aplicación encapsulada como un proceso secundario y

supervisa la salida STDOUT de la aplicación.

Tenga en cuenta que, en el patrón de uso de SHELL, la instrucción CMD/ENTRYPOINT

debe especificarse en el formulario SHELL y no en forma exec. Cuando se usa la forma
exec de la instrucción CMD/ENTRYPOINT, SHELL no se inicia y la herramienta Log
Monitor no se iniciará dentro del contenedor.

Puede encontrar más información de uso en la wiki de Log Monitor . Puede encontrar
archivos de configuración de ejemplo para escenarios clave de contenedor de Windows
(IIS, etc.) en el repositorio de github de . Puede encontrar contexto adicional en esta
entrada de blog .

Motor de Docker
El motor de Docker registra en el registro de eventos "Aplicación" de Windows, en lugar
de hacerlo en un archivo. Estos registros se pueden leer, ordenar y filtrar fácilmente
mediante Windows PowerShell.

Por ejemplo, esto mostrará los registros del motor de Docker de los últimos 5 minutos a
partir del más antiguo.

Output

Get-EventLog -LogName Application -Source Docker -After (Get-

Date).AddMinutes(-5) | Sort-Object Time

Esto también podría canalizarse fácilmente a un archivo CSV para que lo lea otra
herramienta o hoja de cálculo.

Output

Get-EventLog -LogName Application -Source Docker -After (Get-

Date).AddMinutes(-30) | Sort-Object Time | Export-CSV ~/last30minutes.CSV

Habilitación del registro de depuración

También puede habilitar el registro en modo de depuración en el motor de Docker. Esto
puede resultar útil para solucionar problemas si los registros normales no tienen
suficientes detalles.

En primer lugar, abra un símbolo del sistema con privilegios elevados y ejecute el
comando sc.exe qc docker para obtener la línea de comandos actual del servicio
Docker. Ejemplo:

Output

C:\> sc.exe qc docker

[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: docker
TYPE : 10 WIN32_OWN_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : "C:\Program Files\Docker\dockerd.exe" --run-
service
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : Docker Engine
 DEPENDENCIES :
SERVICE_START_NAME : LocalSystem

Tome el BINARY_PATH_NAME actual y modifíquelo:

Agregar un -D al final
Aplique escape con \ a cada instancia de "
Incluya todo el comando en "

A continuación, ejecute sc.exe config docker binpath= seguido de la nueva cadena. Por
ejemplo:

Output

sc.exe config docker binpath= "\"C:\Program Files\Docker\dockerd.exe\" --

run-service -D"

Ahora, reinicie el servicio Docker.

Output

sc.exe stop docker

sc.exe start docker

Esto registrará muchos más detalles en el registro de eventos de la aplicación, por lo

que es mejor quitar la opción -D una vez que termines de solucionar problemas. Siga
los mismos pasos anteriores sin -D y reinicie el servicio para deshabilitar el registro de
depuración.

Una alternativa a lo anterior consiste en ejecutar el demonio docker en modo de

depuración desde un símbolo del sistema de PowerShell con privilegios elevados, y
capturar la salida directamente en un archivo.

PowerShell

sc.exe stop docker

<path\to\>dockerd.exe -D > daemon.log 2>&1

Obtención del volcado de pila

Por lo general, esto solo es útil si el soporte técnico de Microsoft lo solicita
explícitamente o los desarrolladores de Docker. Se puede usar para ayudar a
diagnosticar una situación en la que Docker parece haberse bloqueado.
Descargue docker-signal.exe .

Uso:

PowerShell

docker-signal --pid=$((Get-Process dockerd).Id)

El archivo de salida se ubicará en el directorio raíz de datos en el que se ejecuta docker.

El directorio predeterminado es C:\ProgramData\Docker . El directorio real se puede
confirmar ejecutando docker info -f "{{.DockerRootDir}}" .

El archivo será goroutine-stacks-<timestamp>.log .

Tenga en cuenta que goroutine-stacks*.log no contiene información personal.

Servicio de cómputo de host

El motor de Docker depende de un servicio de proceso de host específico de Windows.
Tiene registros independientes:

Microsoft-Windows-Hyper-V:Compute-Admin
Microsoft-Windows-Hyper-V:Compute-Operational

Son visibles en el Visor de eventos y también se pueden consultar con PowerShell.

Por ejemplo:

PowerShell

Get-WinEvent -LogName Microsoft-Windows-Hyper-V-Compute-Admin

Get-WinEvent -LogName Microsoft-Windows-Hyper-V-Compute-Operational

Captura de registros analíticos y de depuración de HCS

Para habilitar los registros analíticos y de depuración para el proceso de Hyper-V y
guardarlos en hcslog.evtx .

PowerShell

# Enable the analytic logs

wevtutil.exe sl Microsoft-Windows-Hyper-V-Compute-Analytic /e:true /q:true

# <reproduce your issue>

 # Export to an evtx
wevtutil.exe epl Microsoft-Windows-Hyper-V-Compute-Analytic <hcslog.evtx>

# Disable
wevtutil.exe sl Microsoft-Windows-Hyper-V-Compute-Analytic /e:false /q:true

Captura del seguimiento detallado de HCS

Por lo general, estos solo son útiles si el soporte técnico de Microsoft lo solicita.

Descargar hcsTraceProfile.wprp

PowerShell

# Enable tracing
wpr.exe -start HcsTraceProfile.wprp!HcsArgon -filemode

# <reproduce your issue>

# Capture to HcsTrace.etl
wpr.exe -stop HcsTrace.etl "some description"

Proporcione HcsTrace.etl al contacto de soporte técnico.

Comentarios
¿Le ha resultado útil esta página?  Sí  No