WSL 3.0 Containers: la apuesta de Microsoft por el territorio de Docker

Microsoft quiere que olvides que Docker Desktop existe

Microsoft anunció la disponibilidad general de WSL 3.0 el 29 de septiembre, y la característica destacada no es un ajuste del kernel ni una mejora del sistema de archivos. Son los contenedores.

La compañía ahora está posicionando el Subsistema de Windows para Linux como un entorno de ejecución completo de contenedores, compitiendo directamente con Docker Desktop, la herramienta a la que recurren la mayoría de los desarrolladores de Windows cuando necesitan contenedores de Linux. Después de una vista previa pública que comenzó en junio, ya no hay bandera --pre-release. Ejecuta wsl --update o descarga la versión desde GitHub, y tienes un motor de contenedores funcionando dentro de WSL.

Esto no es una mejora incremental. Es un reposicionamiento estratégico.

Por qué esto importa para los desarrolladores de Windows

Durante años, ejecutar contenedores en Windows significaba instalar Docker Desktop, pagar por una licencia Pro si tu organización superaba el límite de asientos, y aceptar un backend de Hyper-V o WSL 2 que ocasionalmente se sentía un paso por detrás del toolchain de Linux que intentabas emular.

Los contenedores de WSL reducen esa distancia. El entorno de ejecución vive dentro de WSL mismo. No hay un daemon de Docker separado que administrar, sin barreras de licenciamiento, sin una capa de máquina virtual entre tu contenedor y el anfitrión. La CLI (wslc.exe) y su alias (container.exe) exponen comandos que replican la interfaz de Docker: build, run, restart, cp, network connect y disconnect, health checks, eventos en streaming.

También hay una capa de API disponible a través del paquete NuGet Microsoft.WSL.Containers, compatible con C, C++ y C#. Montajes de archivos, acceso a GPU, E/S estándar, todo programático. Un desarrollador que construye una herramienta nativa de Windows que necesita orquestar contenedores de Linux ya no tiene que recurrir a la CLI o la API REST de Docker Desktop.

El conjunto de comandos se ha ampliado más allá de la fase de vista previa. wslc system info muestra el estado del entorno. wslc events transmite la actividad de los contenedores en tiempo real. Las redes pueden crearse con opciones de controlador personalizadas. Los contenedores ahora admiten --stop-timeout (incluyendo un valor de -1 para períodos de gracia indefinidos) y --mount. La sesión por defecto de wslc te permite designar qué unidad almacena los contenedores, un detalle práctico que importa cuando ejecutas imágenes en múltiples volúmenes.

Funcionalidades empresariales que anuncian una apuesta seria

Microsoft no solo está cortejando a desarrolladores individuales. El ángulo empresarial es donde esto podría inclinar la balanza.

Dos nuevas políticas de Microsoft Intune dan a los departamentos de TI control sobre el uso: una gobierna si los contenedores WSL pueden ejecutarse en absoluto, y la otra restringe desde cuáles registros de contenedores se pueden extraer las imágenes. Para organizaciones que han tenido dificultades para hacer cumplir las licencias de Docker Desktop o regular las fuentes de imágenes de contenedores, este es un modelo de aplicación más limpio.

Microsoft Defender for Endpoint ahora tiene un plugin para WSL que rastrea procesos de contenedores, operaciones de archivos y actividad de red, correlacionándolos con eventos del lado del anfitrión. Los equipos de seguridad obtienen visibilidad sin desplegar una pila de monitoreo de contenedores separada. Eso representa una reducción significativa en la proliferación de herramientas para entornos dominados por Windows.

La comunidad de desarrolladores japonesa ya lo está probando

El reporte inicial de contenedores WSL emergió de medios tecnológicos japoneses, y la señal de adopción allí es notable. Estudios de desarrollo japoneses, particularmente en gaming y sistemas embebidos, han dependido históricamente de Docker Desktop para flujos de trabajo de contenedores multiplataforma. Los costos de licenciamiento y la sobrecarga de mantener una pila de VMs Linux separada han sido puntos de fricción persistentes.

Ya aparecen herramientas comunitarias. Lazywslc y WSL Container Desktop están siendo construidas por voluntarios. Aspire, la plantilla de aplicación open source de ASP.NET Core, ahora trata los contenedores WSL como un entorno de ejecución soportado. La extensión Container Tools para Visual Studio Code ha agregado soporte, y los Dev Containers de VS Code ahora pueden especificar wslc como el controlador por defecto.

La función más solicitada, wslc compose, aún no se ha lanzado. Microsoft dice que es su prioridad número uno. La compatibilidad con Docker Compose es lo único que separa una migración fluida para la mayoría de los equipos de un período de reescritura de flujos de trabajo locales de desarrollo.

Mejoras de rendimiento que benefician más allá de los contenedores

WSL 3.0 incluye dos cambios de infraestructura que benefician cualquier carga de trabajo que se ejecute dentro de WSL, no solo contenedores.

Virtiofs reemplaza el antiguo intercambio de archivos Plan 9. Microsoft reporta aproximadamente el doble de throughput para el acceso a archivos entre sistemas operativos. Para contenedores que leen y escriben大量(grandes cantidades de) archivos — artefactos de compilación, volcados de bases de datos, rotación de logs — esto es una mejora real, no una curiosidad de benchmarks.

Consomme redirige el tráfico de red de la VM de Linux a través de procesos de Windows en modo usuario en lugar de pasar por la pila de red virtual. El efecto es mejor compatibilidad con VPN y firewalls de Windows, herramientas que han sido durante mucho tiempo fuente de frustración para desarrolladores que ejecutan contenedores en Windows.

Estas mejoras beneficiarán a distribuciones de WSL y otras plataformas de contenedores que se ejecuten sobre WSL, no solo al nuevo entorno de ejecución nativo.

Lo que pierde Docker

El claro perdedor en este cambio es la diferenciación de Docker Desktop en Windows. El punto de venta más fuerte del producto nunca fue su tecnología, era la conveniencia. Lo instalas y los contenedores simplemente funcionaban.

WSL containers ofrece la misma conveniencia a costo cero de licenciamiento, con mayor integración en Windows y sin daemon de terceros. Docker Desktop todavía tiene ventajas en paridad multiplataforma, implementación madura de Compose y una gran base existente de herramientas construidas alrededor de su API. Pero esas ventajas se reducen rápidamente si wslc compose llega y ofrece paridad.

Para organizaciones que ya pagan por licencias Docker Pro o Business, WSL containers ofrece una vía para reducir gastos. Para nuevos equipos, ofrece una razón para saltarse Docker Desktop por completo.

Qué sigue

La pregunta crítica es cuánto tarda Microsoft en lanzar wslc compose y qué tan cerca de la compatibilidad con Docker Compose llega. Compose es el pegamento que sostiene la mayoría de los flujos de trabajo de desarrollo local. Sin él, WSL containers es un entorno de ejecución — útil, pero incompleto para equipos que dependen de pilas multi-servicio definidas en YAML.

El historial de Microsoft en herramientas para desarrolladores ha mejorado significativamente en los últimos tres años. La adquisición de VS Code, la compra de GitHub, la inversión en .NET en Linux, todas señalan a una empresa que se toma en serio la experiencia del desarrollador. WSL containers se ajusta a ese patrón.

Lo que es menos claro es si Microsoft abrirá suficiente la API para que el ecosistema se construya alrededor de ella, como lo hizo Docker. El paquete NuGet y la CLI son un comienzo. Pero el paisaje de herramientas de contenedores prospera con extensiones, plugins e integraciones, y eso requiere una interfaz abierta, no solo bien documentada.

Por ahora, los desarrolladores de Windows que necesitan contenedores de Linux tienen por primera vez una opción nativa creíble. Si llega a ser la opción por defecto depende de qué venga después.