Contenedor Docker

Un contenedor Docker es un proceso iniciado a partir de una imagen Docker y aislado del resto de la máquina: tiene su propio sistema de archivos, su propia interfaz de red y su propia lista de procesos, pero comparte el kernel del host. La imagen es la plantilla de solo lectura (una capa base del sistema operativo, runtimes, tu app); el contenedor es una instancia en ejecución de ella. Puedes iniciar muchos contenedores a partir de una imagen y desecharlos cuando termines.

Ejemplo

Inicia un nodo desechable de Selenium con Chrome y una base de datos Postgres para ejecutar pruebas en local:

docker run --rm -d --name chrome -p 4444:4444 --shm-size=2g selenium/standalone-chrome:latest
docker run --rm -d --name db -p 5432:5432 -e POSTGRES_PASSWORD=test postgres:16-alpine

docker ps          # list running containers
docker logs db     # read a container's output
docker stop chrome db

--rm borra el contenedor cuando se detiene, -d lo ejecuta en segundo plano y -p host:container publica un puerto. En proyectos reales se fijan las etiquetas de imagen (por ejemplo postgres:16.4-alpine) en lugar de latest, para que una nueva versión publicada no cambie tu entorno de pruebas de la noche a la mañana.

Por qué los testers usan contenedores

• Entornos reproducibles. La misma imagen se ejecuta en cada portátil y en cada runner de CI, lo que elimina toda una categoría de fallos del tipo “en mi máquina funciona”.
• Dependencias desechables. Una base de datos nueva en cada ejecución significa que no quedan datos de la ejecución de ayer.
• Navegadores en paralelo. Selenium Grid y las imágenes de navegadores permiten aumentar o reducir nodos con un comando.
• Ejecutar la propia suite de pruebas. Playwright publica imágenes oficiales con los navegadores y las bibliotecas del sistema preinstalados, lo que evita errores por dependencias faltantes en los agentes de CI.

En qué se diferencia de una máquina virtual

Una máquina virtual emula una máquina completa con su propio kernel, así que es más pesada y tarda más en arrancar. Un contenedor comparte el kernel del host, arranca en segundos y usa mucha menos memoria. La contrapartida es un aislamiento más débil, algo que importa para las fronteras de seguridad, pero rara vez para los entornos de pruebas.

Errores comunes

Guardar datos de prueba dentro de un contenedor y esperar que sobrevivan a un reinicio (usa volúmenes), usar etiquetas latest y olvidar --shm-size en los contenedores de navegador, lo que hace que Chrome se caiga bajo carga.