🔍 Auditoría técnica — WSL Container Center#

Fecha: 2026-07-06 Alcance: giro a contenedores con wslc — panel Node.js (:9092), motor WSLC, launcher Windows (Go), 12 casos portados de docker-labs Estado: los 12 casos verificados corriendo — ver registro más abajo

🎯 Objetivo#

wsl-labs giró de "servicios dentro de la distro" a contenedores reales con WSLC, el motor de contenedores nativo de WSL 2.9+ (preview). Esta auditoría documenta con honestidad qué se verificó al portar los 12 casos de docker-labs, cómo se comprobó cada uno y qué límites tiene el enfoque hoy.

🗺️ Esquema#

graph LR
    Cfg["containers.config.json"] --> Build["wslc build (custom)"]
    Cfg --> Net["red wslc (platform/obs)"]
    Build --> Up["wslc run -p host:container"]
    Net --> Up
    Up --> Verify["verificación HTTP + DB"]
    Verify --> Ok["12/12 corriendo"]

✅ Verificación de los 12 casos#

Cada caso se levantó con wslc y se comprobó desde Windows. El criterio de "sano" depende del servicio (no todo es HTTP 200):

🧩 Multi-contenedor + red wslc (verificado)#

Los cuatro casos platform y el de observabilidad no son un solo contenedor: son app + backend conectados por una red wslc creada para el caso. Se verificó que:

• La red se crea con wslc network create <red> antes de levantar los contenedores.
• El backend de datos se levanta sin publicar puerto (ports: []): solo es

accesible dentro de la red del caso.

• La app se conecta por nombre de contenedor (DNS interno de la red wslc), no

por IP ni por localhost.

Verificado: la resolución por nombre en la red wslc funciona — las apps alcanzan su base de datos y devuelven HTTP 200, lo que confirma que el backend está reachable a través de la red del contenedor.

🔨 wslc build desde Dockerfile (verificado)#

Las imágenes wsl-labs/* no son oficiales: se construyen con wslc build desde un Dockerfile propio en el contexto del caso.

Verificado: wslc build -t <imagen> containers/<caso> produce una imagen que aparece en wslc images y se levanta con wslc run. El caso 10-go-api confirma el soporte de builds multi-stage (compilar en una capa, copiar el binario a otra).

🌐 Mapa de puertos — verificado, sin conflictos#

Resultado verificado (v0.3.0): los 12 casos construidos/levantados con wslc y respondiendo desde Windows — 12/12 corriendo.

⚠️ Notas honestas y límites conocidos#

WSLC está en preview#

• wslc requiere WSL 2.9+ (preview): wsl --update --pre-release. El API y el

comportamiento del motor pueden cambiar entre builds de WSL.

• El binario vive en C:\Program Files\WSL\wslc.exe; el panel lo localiza ahí. Si tu

instalación lo tiene en otra ruta, el motor no se detecta.

• No existe (todavía) un wslc compose: el multi-contenedor se arma a mano con

una red wslc y varios wslc run. Es más verboso que un docker-compose.yml.

Casos pesados: Elasticsearch y Jenkins#

• 11-elasticsearch corre sobre JVM con ~512 MB de heap (más overhead): pesa

~1.2 GB en la práctica. No lo levantes con 4 GB de RAM.

• 12-jenkins también es JVM y tarda en arrancar; su primer GET / devuelve

403 (setup inicial) — es la señal de que está vivo, no un error.

• Levantar ES o Jenkins junto a varios casos platform puede saturar una máquina de

8 GB. Ver referencia de runtime.

Verificación manual, no en CI#

• La verificación 12/12 es manual: depende de wslc y de una WSL real, algo no

reproducible en los runners estándar de CI sin virtualización anidada.

• El launcher Go se compila y se comprueba que el binario exista en CI, pero no

hay tests unitarios de la detección de distro/motor.

📁 Alcance y límites de diseño#

• LOCAL únicamente — sin cloud, sin Kubernetes. Apunta a localhost de Windows

sobre WSL 2.9+, no a despliegue remoto.

• Sin firma digital en v0.x/v1.x — decisión intencional documentada en

windows-installer.md.

• Requiere WSL 2.9+ (preview) y Node.js preinstalados — el instalador no los

provee (ver windows-installer.md).

🔗 Documentos relacionados#

• windows-installer.md
• github-releases-distribution.md
• wslc-contenedores.md
• ../CHANGELOG.md