Laboratorio práctico para aprender Docker construyendo un entorno de desarrollo reproducible. Playwright es el caso de uso; Docker es el protagonista.
Este repositorio muestra cómo empaquetar un entorno con Node.js, Playwright y sus navegadores, publicarlo como imagen, reutilizarlo desde otra computadora y ejecutarlo tanto localmente con Docker Compose como en GitHub Actions.
- 🐳 Entorno reproducible con Docker
- 🎭 Playwright ejecutándose dentro de contenedores Linux
- 🧩 Docker Compose para desarrollo local
- 🚀 Misma imagen utilizada en GitHub Actions
- 📊 Reportes Allure publicados con GitHub Pages
- 📦 Imagen compartida mediante Docker Hub
En muchos equipos de automatización, el entorno local del developer no coincide con el utilizado por el pipeline de integración continua. Diferencias de versión en Node.js, Playwright o sus dependencias pueden provocar que una prueba funcione localmente y falle en CI.
Este laboratorio nace para responder una pregunta muy simple:
¿Cómo consigo que el entorno local y el de CI sean el mismo?
La motivación surge de una experiencia real trabajando con Playwright sobre Windows mientras el pipeline utilizaba un entorno Linux basado en Docker.
Además, busca simplificar situaciones habituales de un equipo:
-
que un QA manual o un Product Owner puedan ejecutar únicamente las pruebas de su interés mediante tags y consultar un reporte sin la necesidad de instalar Node.js, Playwright browsers, y todas las dependencias necesarias para la ejecución;
-
que un nuevo integrante del equipo pueda comenzar a trabajar sin encontrarse con problemas de configuración derivados de diferencias de versión.
¿Ya trabajás con Docker y querés ir directo a la arquitectura y las decisiones? Consultá la guía técnica.
El laboratorio creció respondiendo preguntas pequeñas y concretas:
- ¿Cómo evito preparar Playwright manualmente en cada computadora?
Creamos una imagen reproducible mediante unDockerfile. - ¿Cómo comparte una persona ese entorno con el resto del equipo?
Etiquetamos la imagen y la publicamos en Docker Hub. - ¿Puede otro developer usarla sin instalar Node ni Playwright?
Montamos su copia del repositorio dentro de un contenedor. - ¿Cómo evitamos un comando
docker runlargo y difícil de recordar?
Describimos el entorno de desarrollo encompose.yml. - ¿Puede una aplicación del contenedor verse desde la computadora?
Publicamos el puerto de Playwright UI y accedemos desdelocalhost. - ¿Se puede usar la misma imagen en integración continua?
GitHub Actions ejecuta las pruebas dentro del entorno publicado. - ¿Qué ocurre con los resultados?
Los artefactos permanecen en el workspace y Allure se publica con GitHub Pages.
El resultado es un flujo parecido al que podría encontrar un developer al incorporarse a un equipo:
Clonar el repositorio
↓
Descargar la imagen del equipo
↓
Instalar dependencias en un volumen de Docker
↓
Editar el código desde la computadora
↓
Ejecutar Playwright dentro del contenedor
Para utilizar solamente el entorno Docker necesitás:
- Git.
- Docker Desktop con contenedores Linux.
- Docker Compose, incluido en las versiones actuales de Docker Desktop.
No necesitás instalar Node.js, Playwright ni navegadores en la computadora.
Cloná el repositorio:
git clone https://github.com/aldimhernandez/docker-playwright-lab.git
cd docker-playwright-labDescargá la imagen definida en compose.yml:
docker compose pullInstalá las dependencias del proyecto en el volumen administrado por Docker:
docker compose run --rm dev npm ciEjecutá las pruebas:
docker compose run --rm dev npm testIniciá la interfaz interactiva:
docker compose run --rm --service-ports dev npm run test:ui:dockerDespués abrí:
La terminal muestra también Listening on http://0.0.0.0:9323. No es la URL
que debe abrirse en Windows: 0.0.0.0 significa que Playwright escucha en todas
las interfaces de red dentro del contenedor. Docker publica ese servicio
como localhost:9323 en la computadora.
Navegador del developer
http://localhost:9323
↓
Puerto publicado por Docker
127.0.0.1:9323 → contenedor:9323
↓
Playwright UI
0.0.0.0:9323
Presioná Ctrl+C para detener Playwright UI. Como el comando utiliza --rm, el
contenedor temporal se elimina al finalizar.
El repositorio local se monta como /workspace dentro del contenedor. Por eso:
- Los cambios realizados en VS Code aparecen dentro del contenedor.
- Los tests siempre utilizan el código actual del developer.
- Los resultados generados bajo
/workspacepermanecen en la computadora. node_modulesse guarda en un volumen de Docker para no mezclar dependencias Linux con el filesystem de Windows.
Para abrir una terminal interactiva dentro del entorno:
docker compose run --rm devUna vez dentro:
npm test
npm run lint
npm run test:tagPara salir:
exitCada archivo responde una pregunta diferente:
| Archivo | Responsabilidad |
|---|---|
Dockerfile |
Cómo construir la imagen del entorno. |
.dockerignore |
Qué archivos no deben entrar en el build. |
compose.yml |
Cómo utiliza el entorno un developer. |
.github/workflows/ci.yml |
Cómo utiliza el entorno GitHub Actions. |
package.json |
Qué comandos ofrece el proyecto. |
La imagen publicada actualmente es:
aldimh/docker-playwright-demo:1.0.0
El nombre conserva temporalmente la etapa inicial del proyecto como demo. Una
versión futura podrá publicarse como aldimh/docker-playwright-lab.
Validar el archivo Compose:
docker compose configVer los contenedores del proyecto:
docker compose psVer también contenedores temporales activos:
docker psEliminar contenedores y la red creados por Compose:
docker compose downEliminar además el volumen de dependencias:
docker compose down --volumesDespués de borrar el volumen será necesario ejecutar nuevamente npm ci.
- Crear una imagen propia basada en Playwright.
- Publicar manualmente una versión en Docker Hub.
- Consumir la imagen desde un clon limpio.
- Estandarizar el entorno local con Docker Compose.
- Ejecutar Playwright UI mediante un puerto publicado.
- Usar la imagen desde GitHub Actions.
- Generar y publicar reportes Allure.
- Automatizar el build y la publicación de imágenes.
- Incorporar escaneo de vulnerabilidades.
- Evaluar ejecución con un usuario sin privilegios.
La guía técnica explica la arquitectura, los montajes, la red, el comportamiento en CI, las decisiones de seguridad y los próximos pasos del laboratorio.