Contenedores en Windows 11: guía completa de opciones y escenarios

W11 » Aplicaciones para Windows 11 » Contenedores en Windows 11: guía completa de opciones y escenarios

Si trabajas con Windows 11 y quieres subir el nivel en desarrollo, pruebas o administración de sistemas, tarde o temprano te vas a topar con los contenedores. Son una forma tremendamente práctica de empaquetar aplicaciones, aislarlas del sistema y moverlas entre máquinas sin volverte loco con las dependencias. Y sí, se pueden usar tanto en equipos de escritorio con Windows 11 como en servidores Windows Server e incluso en la nube.

Lo interesante es que en el ecosistema Microsoft conviven varias opciones: Docker Desktop sobre Windows 11 y Windows 10, contenedores nativos en Windows Server, orquestación con Kubernetes y servicios gestionados en Azure. Incluso existen proyectos curiosos como dockur/windows que permiten levantar un escritorio completo de Windows 11 dentro de un contenedor apoyándose en virtualización. Vamos a verlo todo con calma, pero sin rodeos, para que tengas claro qué puedes hacer y cómo montarlo.

Qué es un contenedor en Windows 11 y cómo encaja Docker

Un contenedor en Windows es, básicamente, un paquete ligero y aislado que incluye una aplicación y todo el software que necesita para funcionar (librerías, runtimes, ficheros de configuración, etc.), ejecutándose sobre el kernel del sistema operativo anfitrión. A diferencia de una máquina virtual tradicional, no arranca un sistema operativo completo, sino que comparte el núcleo de Windows con el resto del sistema.

Esto tiene varias consecuencias muy jugosas: los contenedores se inician y detienen en segundos, consumen muchos menos recursos que una VM y permiten aumentar la densidad de aplicaciones por servidor. De cara al día a día, te da igual si desarrollas, administras sistemas o llevas temas de ciberseguridad: poder lanzar, destruir y recrear entornos en cuestión de instantes cambia las reglas del juego.

Docker ha sido la plataforma que ha popularizado este modelo. En Windows 11, Docker Desktop actúa como la capa que te permite crear, gestionar y ejecutar contenedores ya sean basados en Linux (a través de WSL 2) o contenedores nativos de Windows. La gran diferencia respecto a una VM es que Docker no virtualiza todo el sistema operativo, sino procesos aislados con su propio filesystem y configuración.

Si lo piensas en términos de logística, cada imagen de Docker es como un contenedor físico de transporte: dentro va exactamente lo que la aplicación necesita para funcionar y nada más, lo que hace que sea compacto, portable y fácil de mover entre entornos (local, on‑premise, nube, etc.).

Requisitos y entornos compatibles para contenedores en Windows

Antes de ponerte creativo con imágenes y docker compose, necesitas tener claro qué requisitos pide Windows para poder ejecutar contenedores y qué diferencias hay entre usar Windows 11 y Windows Server. No es lo mismo el escenario de un portátil de desarrollo que un clúster de producción en Azure.

En Microsoft, la compatibilidad actual de contenedores cubre Windows Server 2016, 2019, 2022, 2025, Windows 10 (desde la versión 1607) y Windows 11. Sobre todos estos sistemas puedes montar un entorno listo para contenedores, aunque los pasos concretos cambian según sea un equipo cliente o un servidor.

Requisitos para contenedores en Windows 10 y Windows 11

En equipos cliente, como tu sobremesa o portátil con Windows 10/11, los requisitos mínimos para trabajar con contenedores de forma cómoda son:

• Windows 11 o Windows 10 con la actualización de aniversario (1607) o posterior.
• Edición Professional o Enterprise para disponer de las funciones de virtualización necesarias.
• Hyper‑V habilitado o, en la práctica actual con Docker Desktop, WSL 2 configurado para contenedores Linux.

En Windows 10 y Windows 11, los contenedores de Windows Server suelen ejecutarse con aislamiento de Hyper‑V. Esto significa que, aunque sigas estando en el mundo de los contenedores, cada uno de ellos se apoya en una pequeña VM optimizada que replica el kernel de Windows Server que se usa en producción. Es una forma de garantizar que el entorno de desarrollo y el de producción se parezcan mucho, evitando sorpresas al desplegar.

Requisitos para contenedores en Windows Server

Si lo que tienes es un entorno de servidor, cambia el enfoque. Para ejecutar contenedores de Windows Server en desarrollo o producción necesitas un servidor físico o una máquina virtual que ejecute Windows Server en alguna de sus versiones modernas. Para pruebas rápidas, Microsoft ofrece ISO de evaluación de Windows Server 2025 o builds del programa Windows Server Insider.

Sobre ese sistema podrás instalar un entorno de ejecución de contenedores compatible, como Moby, Mirantis Container Runtime o containerd. En muchos escenarios corporativos, estos servidores se orquestan con Kubernetes (AKS, AKS on Azure Stack HCI, etc.) o forman parte de un conjunto de escalado de máquinas virtuales en Azure.

Opciones para preparar un entorno listo para contenedores

Montar un entorno “container‑ready” en Windows no es cuestión de un único camino. La estrategia a seguir depende del sistema operativo, del nivel de complejidad que estás dispuesto a asumir y del coste operativo que tu organización puede encajar. No es lo mismo un único servidor on‑premise que una granja de VMs en Azure.

En estaciones de trabajo con Windows 10/11 Professional o Enterprise, la ruta sencilla y directa es instalar Docker Desktop. En servidores Windows Server, el panorama es más variado: puedes construir tus propias imágenes de máquina virtual con el runtime de contenedores preinstalado, usar extensiones de script para prepararlas en el arranque o delegar buena parte del trabajo en un servicio gestionado como Azure Kubernetes Service.

Windows 10 y Windows 11: Docker Desktop y WSL 2

En equipos cliente la receta recomendada es clara: Docker Desktop + WSL 2. Docker Desktop se encarga de todo lo necesario para ejecutar contenedores Linux sobre el subsistema de Windows para Linux y también proporciona soporte para contenedores nativos de Windows cuando lo configuras para ello.

Docker puede funcionar también con Hyper‑V, pero en la práctica WSL 2 es el backend preferido en Windows 11 porque ofrece un kernel Linux real, mejor rendimiento en I/O y una integración bastante limpia con el sistema. Eso sí, para escenarios concretos en los que necesitas contenedores Windows puros, Hyper‑V sigue estando en la ecuación, ya que se emplea para el aislamiento de estos contenedores.

Windows Server: máquinas virtuales personalizadas y Azure

En Windows Server la película es otra. Con la transición del entorno de ejecución de contenedores de Windows hacia Mirantis, Microsoft ya no distribuye imágenes de VM “listas para contenedores” directamente desde el Marketplace de Azure. En lugar de eso, te toca construir esas VMs a medida con el runtime que te interese.

Para facilitar esa tarea, Microsoft sugiere dos caminos principales cuando trabajas en Azure: Azure VM Image Builder o extensiones de script personalizadas. Ambos métodos te permiten automatizar la creación de máquinas virtuales listas para ejecutar contenedores, pero con matices importantes en complejidad, coste y tiempos.

Azure VM Image Builder

El servicio Azure VM Image Builder te permite definir cómo debe ser tu imagen de Windows Server en tiempo de compilación: se parte de una imagen base, se aplican pasos (instalar runtimes, configurar servicios, aplicar políticas, etc.) y el resultado es una imagen personalizada que luego se usa en tus conjuntos de escalado o máquinas virtuales individuales.

La gran ventaja es que todo el trabajo pesado se hace antes de que la VM se ejecute. Cuando arrancas una nueva instancia de máquina virtual desde esa imagen, ya está preparada para ejecutar contenedores sin procesos extra de configuración, lo que reduce el tiempo de provisionado en escenarios de escalado automático.

Como contrapartida, VM Image Builder es más complejo de desplegar que un simple script y aunque el servicio como tal no tiene coste directo, sí pagas por el cómputo, el almacenamiento y la red utilizados durante el proceso de construcción de la imagen. Para configurarlo, normalmente se emplean plantillas JSON y scripts de PowerShell (por ejemplo, los que instala Moby, Mirantis o containerd).

Extensiones de script personalizadas

La otra alternativa, más directa, son las Custom Script Extensions de Azure. Con ellas, configuras tu conjunto de escalado o VM para que, nada más aprovisionarse, se descargue y ejecute un script (por ejemplo, desde Azure Storage o GitHub) que instala y configura el entorno de contenedores.

Este enfoque es más fácil de poner en marcha y prácticamente solo pagas por el almacenamiento del script, pero tiene una desventaja obvia: la instalación del runtime sucede después de que la máquina arranca, de modo que debes contar con ese tiempo extra cada vez que creas una instancia nueva.

Con el material que aporta Microsoft, puedes configurar conjuntos de escalado para que automaticen la instalación de Moby o containerd mediante scripts de PowerShell. Es una forma rápida de dotar de soporte de contenedores a muchas VMs a la vez sin tener que mantener múltiples imágenes personalizadas.

Servicios gestionados de contenedores en Azure

Si tu objetivo no es tanto pelearte con la capa de infraestructura como desplegar aplicaciones en contenedores a escala con la mínima sobrecarga de administración, la opción lógica es tirar de servicios gestionados.

Azure sigue ofreciendo una experiencia muy completa a través de Azure Kubernetes Service (AKS), tanto en la nube pública como en entornos locales con Azure Stack HCI y AKS habilitado por Azure Arc. En estos servicios, la compatibilidad con el runtime de contenedores viene incluida en la propia oferta: tú te centras en los despliegues, no en configurar dockerd o containerd en cada nodo.

Para decidir qué camino tomar, conviene que la organización tenga claro qué factor es prioritario: complejidad de despliegue, coste o impacto en las cargas de trabajo en producción. A partir de ahí, se elige entre imágenes personalizadas, scripts, AKS u otras opciones híbridas.

Cómo instalar Docker en Windows 11 paso a paso

Lo primero es ir a la web oficial de Docker y descargar el instalador de Docker Desktop para Windows. A partir de ahí, el asistente te guía, pero hay un par de casillas que marcan la diferencia, sobre todo si optas por WSL 2 como backend de contenedores.

Paso 1: descarga de Docker Desktop

Desde la página de Docker eliges Docker Desktop para Windows, descargas el ejecutable y lo lanzas. Este paquete incluye tanto el motor de Docker como la interfaz gráfica y las integraciones con WSL 2 o Hyper‑V según lo configures.

Paso 2: instalación y elección de backend (WSL 2 vs Hyper‑V)

Durante el asistente de instalación, Docker recomienda de forma explícita usar WSL 2 como plataforma de virtualización en lugar de Hyper‑V, sobre todo en equipos de escritorio con Windows 11. Verás una casilla del estilo “Usar WSL 2 en lugar de Hyper‑V” que conviene dejar marcada para que instale y configure automáticamente el subsistema de Windows para Linux si aún no lo tienes.

Al terminar el asistente, tendrás que reiniciar el sistema para que Windows aplique los cambios (activación de características, integración con WSL, etc.). Tras el reinicio, se muestran las condiciones de la licencia de Docker Desktop: el uso es gratuito para uso personal y para pequeñas empresas, pero en organizaciones grandes conviene revisar las condiciones comerciales de la licencia.

Paso 3: completar la instalación de WSL 2

Si WSL 2 no estaba presente en tu sistema, Docker Desktop te indicará que aún falta completar su instalación. El propio programa ofrece un enlace al paquete más reciente de WSL 2 para Windows 11. Descargas el instalador, lo ejecutas y sigues los pasos que se muestran en el asistente.

Una vez instalado WSL 2, puede que te toque reiniciar otra vez para dejarlo todo listo. A partir de ese momento podrás desplegar distribuciones Linux (Ubuntu, Debian, etc.) sobre WSL y aprovecharlas como base de ejecución para contenedores Docker Linux.

Paso 4: ejecutar y verificar Docker Desktop

Con Docker Desktop instalado, al iniciar sesión en Windows 11 debería arrancar automáticamente la aplicación. Si no lo hace, puedes lanzarla desde el icono del escritorio o desde el menú de inicio. Cuando veas el icono de Docker en la bandeja del sistema, es señal de que el motor se está ejecutando.

Para comprobar que todo está en orden, abre PowerShell o una terminal y ejecuta un contenedor de prueba, por ejemplo la típica imagen Hello World. Docker descargará esa imagen desde Docker Hub y la ejecutará, mostrándote un mensaje de bienvenida. Con este simple paso verificas que puede descargar imágenes y levantarlas correctamente sobre tu sistema.

Paso 5: primeros comandos útiles de Docker

Una vez que Docker funciona, es buena idea familiarizarse con algunos comandos básicos de la CLI:

• docker: muestra una lista de comandos disponibles.
• docker <COMANDO> –help: enseña la ayuda detallada de un comando concreto.
• docker image ls –all: lista todas las imágenes que tienes en el host.
• docker container ls –all: muestra los contenedores existentes, incluidos los detenidos.
• docker ps -a: alternativa muy usada para ver todos los contenedores.
• docker info: ofrece información general sobre la instalación de Docker, el backend, recursos, etc.

Con estos comandos puedes inspeccionar rápidamente el estado de tu entorno, ver qué imágenes estás acumulando en disco, qué contenedores siguen vivos y cómo está configurado el daemon.

Cómo funcionan los contenedores en Windows: imágenes, aislamiento y modos

Para entender bien qué puedes y qué no puedes hacer con contenedores en Windows 11 conviene repasar cómo se construye un contenedor y qué papel juegan el kernel y las imágenes base. Muchos problemas de compatibilidad vienen precisamente de mezclar versiones o tipos de contenedor sin tener esto claro.

Un contenedor se apoya en el kernel del sistema operativo host. Ese kernel proporciona primitivas de aislamiento y recursos (memoria, CPU, red, etc.), mientras que la parte de “user space” (bibliotecas, servicios, herramientas del sistema) llega a través de la imagen base sobre la que se monta tu imagen.

En el mundo Windows, Microsoft ofrece varias imágenes base pensadas para diferentes escenarios:

• Windows: contiene el conjunto completo de API y servicios de Windows (excepto roles de servidor).
• Windows Server: trae las API y servicios de Windows Server a nivel completo.
• Windows Server Core: imagen más pequeña con un subconjunto de las API de Windows Server y la versión completa de .NET Framework; incluye la mayoría de roles de servidor habituales.
• Nano Server: la variante más ligera de Windows Server, compatible con .NET Core y pensada para servicios muy optimizados.

Sobre cualquiera de estas bases puedes construir tus propias imágenes añadiendo runtimes, dependencias y tu propia aplicación. Por ejemplo, el equipo de .NET publica imágenes ya preparadas con .NET Runtime o .NET SDK basadas en Nano Server, de modo que no tienes que repetir la instalación de .NET cada vez: simplemente heredas de ellas en tu Dockerfile.

Cada imagen está formada por capas. Cada vez que en tu Dockerfile añades un RUN, COPY, etc., se crea una capa nueva. Cuando lanzas un contenedor, todas esas capas se superponen formando un sistema de archivos. La capa superior es de escritura y las inferiores son de solo lectura. Esta estructura permite reutilizar capas entre imágenes, ahorrando espacio y tiempo de descarga.

Contenedores frente a máquinas virtuales

La comparación clásica es inevitable: una máquina virtual incluye un sistema operativo completo (con su propio kernel) encima de un hipervisor, mientras que un contenedor solo empaqueta la parte “user space” y comparte el kernel del host. Por eso una VM tarda más en arrancar y consume más memoria y CPU, pero también te da un nivel de aislamiento más fuerte.

En la práctica, contenerizar y virtualizar no son tecnologías rivales, sino complementarias. Es muy habitual que los nodos de un clúster de contenedores sean a su vez máquinas virtuales, especialmente en la nube. Así obtienes lo mejor de ambos mundos: aislamiento de infraestructura con VMs y agilidad de despliegue con contenedores.

Además, en Windows existe el concepto de aislamiento de Hyper‑V para contenedores, que combina ambas ideas: el contenedor corre en una pequeña VM altamente optimizada que comparte poco o nada con el host, lo que incrementa el aislamiento sin perder del todo la agilidad de los contenedores.

Ecosistema de contenedores en Microsoft: herramientas y orquestación

Más allá de lanzar contenedores sueltos, en el ecosistema Microsoft tienes un conjunto bastante completo de herramientas y servicios para desarrollar, publicar y orquestar aplicaciones en contenedores tanto en Windows 11 como en Windows Server.

Para el desarrollo local, puedes ejecutar contenedores Linux o Windows en Windows 10/11 usando Docker Desktop, aprovechando la funcionalidad de contenedores integrada en el propio sistema operativo. Si prefieres ir más “al metal”, en Windows Server también puedes ejecutar contenedores de forma nativa sin necesidad de Docker Desktop, instalando directamente el runtime compatible.

En el ámbito del desarrollo, Visual Studio y Visual Studio Code ofrecen una integración potente con contenedores: soporte para Dockerfiles, Docker Compose, Kubernetes, Helm, depuración dentro de contenedores, etc. Desde estas herramientas puedes crear, probar y desplegar imágenes con bastante comodidad.

Cuando llega el momento de compartir tu trabajo, lo normal es publicar las imágenes en un registro: puede ser Docker Hub (público) o un Azure Container Registry privado de tu organización. Desde ahí, los equipos pueden hacer push/pull de imágenes, integrarlas en pipelines de CI/CD y desplegarlas en clusters de Kubernetes u otros orquestadores.

Orquestadores de contenedores

Cuando pasas de unos pocos contenedores a decenas o cientos, gestionar todo a mano con Docker se vuelve inviable. Aquí entran en juego los orquestadores, con Kubernetes como opción predominante en el mundo Windows y Linux.

Un orquestador se encarga de tareas clave como:

• Desplegar contenedores a escala sobre múltiples nodos.
• Programar las cargas de trabajo según recursos disponibles, afinidades, etc.
• Monitorizar el estado de los pods y reiniciarlos si fallan.
• Gestionar el escalado automático (subir o bajar instancias según demanda).
• Configurar la red, balanceo de carga y descubrimiento de servicios.
• Coordinar actualizaciones y despliegues progresivos para minimizar riesgos.

Microsoft proporciona varias rutas para usar Kubernetes con contenedores Windows: AKS en Azure, AKS habilitado por Azure Arc en entornos híbridos, Kubernetes sobre Azure Stack Hub, o despliegues autogestionados en Windows Server. Además, se está trabajando en soporte de contenedores Windows dentro de Red Hat OpenShift.

Usos de los contenedores para desarrolladores y administradores

Para los equipos de desarrollo, los contenedores en Windows 11 son una herramienta muy potente para acelerar ciclos de entrega, garantizar que “funciona igual en mi máquina y en producción” y reducir la fricción con operaciones. Creas una imagen, la pruebas localmente y la despliegas tal cual en los distintos entornos.

Los contenedores permiten aislar versiones de librerías, runtimes y dependencias sin contaminar el sistema de desarrollo. Puedes tener varias versiones de la misma herramienta en paralelo, cada una dentro de su contenedor, sin interferencias. También facilitan compartir entornos completos entre equipos: un simple docker compose puede levantar toda una aplicación con su base de datos, caché, API, etc.

Para los administradores de TI, la ventaja está en poder ofrecer entornos estandarizados para desarrollo, QA y producción, aumentando el aprovechamiento de hardware y simplificando las actualizaciones. En lugar de máquinas con instalaciones “artesanales”, se despliegan imágenes de contenedores controladas y auditadas.

Además, los contenedores son muy útiles como entornos desechables para tareas de seguridad o pruebas de herramientas en conflicto. Puedes lanzar instancias interactivas para ejecutar utilidades específicas que no quieres instalar de forma permanente en el host, o levantar laboratorios efímeros para pruebas de penetración y análisis de malware.

Ejecutar Windows 11 completo dentro de un contenedor Docker (dockur/windows)

Un caso llamativo que suele generar dudas es la posibilidad de levantar un escritorio completo de Windows 11 dentro de Docker. A primera vista suena contradictorio, porque Docker comparte el kernel del host y, en principio, no debería poder ejecutar un sistema operativo con un kernel distinto (por ejemplo, Windows sobre un host Linux) como si fuera un contenedor normal.

Sin embargo, proyectos como dockur/windows demuestran que, combinando tecnologías, se pueden lograr cosas curiosas: en este caso, el contenedor hace de envoltorio para una máquina virtual QEMU/KVM que arranca Windows 11 (u otras versiones como Windows 10, Windows 7, XP o Windows Server 2022). Lo que gestionas con Docker no es el sistema operativo Windows en sí, sino la VM que lo contiene.

La “magia” se basa en que el host Linux soporte virtualización KVM. Al lanzar el contenedor, se pasa el dispositivo /dev/kvm para aprovechar aceleración por hardware y, opcionalmente, /dev/net/tun para las capacidades de red. El contenedor descarga la ISO de Windows desde los servidores de Microsoft, la instala de forma desatendida y deja el escritorio listo para usarse.

Con un simple docker compose up puedes tener en un par de minutos un Windows 11 limpio, accesible vía navegador (HTML5) y, si lo deseas, persistente gracias a un volumen montado en el host que almacena el disco virtual. Si no configuras ese volumen, cada vez que reinicies el contenedor la instalación se repetirá desde cero, lo que puede ser útil para escenarios de laboratorio desechable.

Entre los motivos para utilizar este enfoque destacan:

• Infraestructura como código: defines la máquina Windows en YAML y puedes versionarla.
• Automatización completa: la ISO se descarga y se instala sin intervención, sin ir clicando en asistentes.
• Portabilidad: te llevas el contenedor a cualquier servidor Linux con KVM.
• Sandbox muy aislado: ideal para análisis de malware o pruebas de software “peligroso”.

Para que el rendimiento sea razonable, la CPU debe tener soporte de virtualización habilitado en BIOS/UEFI (Intel VT‑x o AMD SVM) y KVM debe estar operativo en el host. Si al lanzar el contenedor obtienes errores relacionados con KVM, es lo primero que conviene comprobar.

Una vez desplegado, puedes aumentar CPU y RAM asignadas al Windows virtual mediante variables de entorno en el compose, o incluso habilitar escritorio remoto (RDP) para trabajar de forma más cómoda que con el visor web. También es posible compartir una carpeta del host con la VM montando volúmenes que aparecen como “Shared” dentro del escritorio Windows.

Este tipo de solución demuestra hasta qué punto Docker puede ir más allá de los microservicios clásicos. Aunque en este caso técnicamente estés ejecutando una VM dentro de un contenedor, desde el punto de vista operativo se integra en tus flujos de Docker y CI/CD, y puede ser un recurso valioso para pruebas, compatibilidad de software antiguo o entornos de seguridad muy controlados.

Con todo este ecosistema —desde Docker Desktop en Windows 11, pasando por contenedores nativos en Windows Server, hasta orquestación en AKS y experimentos como dockur/windows—, Windows se convierte en una plataforma muy flexible para trabajar con contenedores, capaz de cubrir desde el desarrollo local más sencillo hasta despliegues corporativos complejos en la nube o en entornos híbridos, siempre que planifiques bien requisitos, costes y el nivel de automatización que quieres alcanzar.