Construcción de contenedores en el navegador: cómo funciona y cuándo usarlo

Introducción

El ecosistema de contenedores es fascinante precisamente por su transparencia. A diferencia de otras tecnologías cerradas, Docker y el estándar OCI mantienen sus especificaciones públicas y su implementación accesible. Esto permite no solo entender cómo funcionan internamente, sino también construir herramientas personalizadas para casos de uso específicos. El problema no suele ser la falta de flexibilidad, sino la tendencia a limitarse a las herramientas estándar (docker build, Buildah, Kaniko) sin explorar alternativas que podrían resolver problemas concretos con mayor eficiencia.

El artículo original presenta una demo técnica: una aplicación web que construye imágenes de contenedores dentro del navegador, usando exclusivamente código del lado del cliente. El enfoque no es práctico para entornos de producción, pero sirve como ejercicio técnico para comprender los límites de los entornos de ejecución modernos y cómo pueden superarse. La clave está en entender que, aunque las herramientas estándar son suficientes para la mayoría de los casos, en ciertos escenarios —como optimización de tiempo de construcción, manipulación dinámica de capas o integración con flujos de CI/CD sin dependencias externas— construir soluciones propias puede marcar la diferencia.

Qué ocurrió

El 24 de mayo de 2026 se publicó una prueba de concepto que permite compilar imágenes de Docker directamente en el navegador, sin necesidad de un daemon local ni servicios externos. La aplicación, disponible como demo interactiva, descomprime imágenes existentes, manipula sus capas y genera nuevas imágenes usando solo JavaScript sin acceso a APIs del sistema. Esto es posible gracias a:

1. La especificación abierta de OCI: Las imágenes de contenedor son, en esencia, archivos .tar con una estructura definida por el estándar OCI Image Specification v1.1.0 (versión actual al momento de la publicación).
2. El sandbox del navegador: APIs como File System Access API y Compression Streams API permiten manipular archivos comprimidos en tiempo real.
3. WebAssembly (WASM): Para acelerar operaciones intensivas en CPU, como compresión/descompresión de capas, se utiliza WASM con implementaciones de algoritmos como gzip o zstd.

El código fuente de este «builder» está disponible en este repositorio y demuestra que, con suficiente conocimiento de los estándares, es posible recrear funcionalidades de docker build sin depender de herramientas externas. La demo incluye logs detallados de cada paso del proceso, desde la descarga de una imagen base hasta la construcción de una nueva capa personalizada.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e Infraestructura

El enfoque tiene tres implicancias principales:

1. Reducción de dependencias en CI/CD:

– GitHub Codespaces o GitLab Web IDE: Compilar imágenes directamente desde el editor web.

– Documentación interactiva: Mostrar ejemplos de construcción sin requerir que el usuario instale nada.

– Herramientas sin servidor (serverless): Construir imágenes en el frontend y subirlas a un registro como S3.

Ejemplo: Un equipo de DevOps podría usar esta técnica para construir imágenes de depuración «al vuelo» durante revisiones de código, sin necesidad de un pipeline completo.

1. Optimización de tiempo de construcción:

– Caching inteligente: Las capas se reconstruyen solo si cambian los archivos modificados.

– Arquitectura personalizada: Uso de índices personalizados para evitar el escaneo completo del sistema de archivos.

– Paralelismo controlado: Las operaciones en el navegador (como compresión) se ejecutan en Web Workers.

Esto es especialmente relevante para equipos que trabajan con imágenes grandes (ej.: contenedores de machine learning con modelos de 10+ GiB).

1. Seguridad y aislamiento:

– El código JavaScript se ejecuta en el contexto del usuario, por lo que podría inyectarse código malicioso si la aplicación no sanitiza las entradas.

– Las capas manipuladas podrían contener archivos con vulnerabilidades (ej.: binarios con CVE conocidas). La demo no incluye escaneo de seguridad integrado.

Detalles técnicos

¿Cómo funciona la construcción de capas en el navegador?

El proceso sigue estos pasos, basados en el estándar OCI:

1. Descarga de la imagen base:

– Usa la API fetch con streaming para manejar archivos grandes sin saturar la memoria.

1. Descompresión y montaje de capas:

– Las capas se montan en memoria como un sistema de archivos virtual usando File System Access API, que simula un árbol de directorios.

1. Manipulación de archivos:

– Ejemplo: Agregar un script personalizado en /usr/local/bin para un contenedor de Python.

1. Reempaquetado y firma:

– Se genera un nuevo índice de imagen (manifest) en formato OCI, incluyendo hashes SHA-256 de cada capa.

– La demo no implementa firma digital, pero en un entorno de producción sería necesario usar herramientas como cosign para evitar alteraciones maliciosas.

Limitaciones técnicas

1. Rendimiento:

– Ejemplo: Construir una imagen de Node.js con 500 MB de dependencias puede tardar 2-3 minutos en el navegador, vs. 10-15 segundos con Docker.

1. Compatibilidad:

– File System Access API (Chrome 86+, Edge 86+).

– Compression Streams API (Chrome 80+, Firefox 80+).

– WebAssembly (todos los navegadores modernos).

– No funciona en Safari ni en navegadores móviles sin ajustes.

1. Falta de características:

– No maneja variables de entorno ni volúmenes de manera nativa.

– No tiene integración con registros privados (requiere autenticación manual).

¿Qué pasa con la seguridad?

• Ventajas:

– No hay necesidad de instalar Docker ni permisos elevados en el sistema.

• Riesgos:

– Ataques a la cadena de suministro: Las imágenes construidas podrían contener vulnerabilidades conocidas (ej.: paquetes con CVE como CVE-2024-3094 en librerías incluidas).

– Falta de integridad: La demo no implementa firma digital, por lo que las imágenes podrían ser alteradas en tránsito.

Qué deberían hacer los administradores y equipos técnicos

Si están evaluando el enfoque para casos de uso específicos

1. Para entornos de desarrollo interactivo:

– Ejemplo práctico:

     # Descargar la imagen base (alpine:latest)
     curl -L https://registry-1.docker.io/v2/library/alpine/manifests/latest \
       -H "Accept: application/vnd.docker.distribution.manifest.v2+json" | jq .
     

– Limitación: No es escalable para equipos grandes.

1. Para optimizar pipelines de CI/CD:

– Si el objetivo es reducción de tiempo de construcción, implementar:

     # Ejemplo de Dockerfile optimizado para Buildx (multi-stage)
     FROM golang:1.21 as builder
     WORKDIR /app
     COPY . .
     RUN go build -o /app/myapp

     FROM alpine:latest
     COPY --from=builder /app/myapp /usr/local/bin/
     CMD ["myapp"]
     

– Herramientas alternativas:

– Earthly: Para builds reproducibles y cachés distribuidos.

– Bazel: Para builds incrementales en entornos grandes.

1. Para seguridad:

     # Usar Trivy para detectar vulnerabilidades
     trivy image my-custom-image:latest --severity CRITICAL,HIGH
     

– Implementar firmas digitales con cosign:

     cosign sign --key cosign.key my-custom-image:latest
     

1. Si quieren experimentar con el enfoque en el navegador:

     git clone https://github.com/ochagavia/oci-container-builder.git
     cd oci-container-builder
     npm install
     npm run dev
     

– Requisitos:

– Node.js 18+.

– Navegador con soporte para File System Access API (Chrome/Edge).

– Alternativa para producción: Usar WASM + Rust para compilar operaciones críticas y mejorar rendimiento.

Conclusión

La construcción de contenedores en el navegador es un ejercicio técnico valioso, pero no un reemplazo práctico para herramientas como docker build o Kaniko. Su mayor aporte es demostrar que, con suficiente conocimiento de los estándares (OCI, Dockerfile), es posible construir soluciones personalizadas que superen las limitaciones de las herramientas tradicionales. Para equipos que buscan optimizar flujos de CI/CD, la clave está en:

1. Entender el estándar OCI: Saber cómo funcionan las capas, manifiestos y hashes.
2. Evaluar casos de uso concretos: Donde las herramientas estándar fallen (ej.: builds en entornos sin Docker, manipulación dinámica de imágenes).
3. Combinar enfoques: Usar soluciones como Buildx para builds rápidos y complementar con herramientas personalizadas para casos específicos.
4. Priorizar seguridad: Escanear imágenes, firmarlas digitalmente y validar entradas en cualquier herramienta personalizada.

La demo es un recordatorio de que, en el mundo de los contenedores, no estamos limitados por las herramientas que usamos hoy, sino por nuestra imaginación para mejorarlas.

Fuentes

https://ochagavia.nl/blog/fully-in-browser-container-builds/

https://github.com/ochagavia/oci-container-builder

FIN