Si trabajas con servidores Linux, tarde o temprano te toca elegir entre Docker y LXC. Los dos crean contenedores y los dos usan las mismas piezas del kernel, pero están pensados para cosas muy distintas. En esta entrada explico qué los diferencia, cómo se usan y cuándo conviene cada uno.

¿Qué es un contenedor?
Un contenedor no es una máquina virtual. No hay hipervisor ni un kernel propio: todos los contenedores comparten el kernel del host. El aislamiento lo consigue el propio Linux con dos mecanismos:
- Namespaces: cada contenedor tiene su propia vista de los procesos (PID), la red, los puntos de montaje, los usuarios y el hostname.
- cgroups: limitan y contabilizan los recursos que puede usar (CPU, memoria, E/S de disco).
Por eso un contenedor arranca en segundos y consume mucho menos que una VM. La contrapartida es que solo puede ejecutar Linux, porque el kernel es el del anfitrión.
LXC: contenedores de sistema
LXC (Linux Containers) crea contenedores que se comportan como un sistema operativo completo: tienen su systemd como PID 1, servicios, usuarios, cron, SSH… En la práctica es como una máquina virtual muy ligera. Lo creas una vez y lo administras como cualquier servidor, actualizándolo con apt y manteniendo su estado.
sudo apt install lxc
sudo lxc-create -n web -t download -- -d debian -r trixie -a amd64
sudo lxc-start -n web
sudo lxc-attach -n web -- apt install -y nginx
sudo lxc-ls -f
Con lxc-attach entras en el contenedor sin necesidad de SSH, y con lxc.cgroup2.memory.max o lxc.cgroup2.cpuset.cpus en su fichero de configuración puedes limitar la memoria y las CPU que usa.
Docker: contenedores de aplicación
Docker sigue otra filosofía: un proceso por contenedor. El contenedor no es un servidor que se mantiene, sino una instancia desechable de una imagen. Si hay que cambiar algo, se modifica la imagen, se reconstruye y se vuelve a lanzar. Los datos que deben sobrevivir se guardan en volúmenes.
docker run -d --name web -p 8080:80 nginx
docker ps
docker exec -it web bash
docker stop web && docker rm web
Las imágenes se construyen por capas a partir de un Dockerfile, lo que las hace reproducibles y fáciles de versionar junto al código:
FROM debian:trixie-slim
RUN apt-get update && apt-get install -y nginx && rm -rf /var/lib/apt/lists/*
COPY index.html /var/www/html/
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
Como curiosidad, las primeras versiones de Docker usaban LXC por debajo. A partir de la 0.9 (2014) pasó a usar su propia librería, libcontainer, que hoy es la base de runc.
Comparativa
| Aspecto | LXC | Docker |
|---|---|---|
| Tipo | Contenedor de sistema | Contenedor de aplicación |
| Proceso principal | Init completo (systemd) | Un único proceso (nginx, python…) |
| Ciclo de vida | Persistente, se administra como una VM | Efímero: se destruye y se recrea desde la imagen |
| Imágenes | Plantillas de distribución (rootfs) | Imágenes por capas construidas con Dockerfile |
| Distribución | Servidor de imágenes de LXC | Docker Hub y registros privados |
| Configuración | /var/lib/lxc/<nombre>/config | Dockerfile y compose.yaml |
| Uso típico | Laboratorios, servicios clásicos, alternativa ligera a una VM | Microservicios, CI/CD, despliegue de aplicaciones |
¿Cuál elegir?
- Elige LXC si necesitas un “servidor” completo con varios servicios, quieres montar un laboratorio de prácticas o buscas sustituir VMs por algo más ligero (por ejemplo, el proxy y el balanceador de un escenario de red).
- Elige Docker si vas a desplegar aplicaciones, quieres que el entorno sea reproducible en cualquier máquina o vas a trabajar con pipelines de integración continua.
- Y no son excluyentes: es muy habitual ejecutar Docker dentro de un contenedor LXC para separar entornos en un mismo host.
Conclusión
Docker y LXC comparten tecnología, pero no objetivo. LXC virtualiza un sistema; Docker empaqueta una aplicación. Entender esa diferencia es lo que te permite elegir bien la herramienta para cada escenario.
Deja una respuesta