Contenedores de sistema LXC/Incus: qué son y cuándo elegirlos en lugar de un contenedor de aplicación

Qué es

Incus, documentado en linuxcontainers.org y bifurcado (fork) de LXD en 2023, es un gestor de contenedores de sistema y máquinas virtuales, ambos tratados mediante la misma abstracción de «instancia» y el mismo conjunto de comandos. Su documentación describe un contenedor de sistema como aquel que ejecuta un sistema operativo completo, con su sistema init y varios servicios, y no una sola aplicación; es el modelo que popularizó LXC y que Incus continúa. Los contenedores de aplicación (el modelo habitual de Docker/Podman), en cambio, empaquetan un único proceso y sus dependencias, normalmente sin un sistema init dentro.

Por qué importa

Cada modelo se adapta a tareas distintas. Un contenedor de sistema se comporta como una VM ligera y de arranque rápido: se puede entrar con ssh (o por su consola), ejecutar varios servicios de larga duración, aplicar actualizaciones de paquetes del sistema operativo dentro de él y tratarlo casi como una pequeña máquina dedicada. Al mismo tiempo comparte el kernel del host, por lo que normalmente arranca en segundos y tiene menos sobrecarga que una VM completa. (Para iniciar sesión por SSH hace falta tener un servidor SSH instalado dentro, como en cualquier máquina.) Un contenedor de aplicación está pensado para una sola tarea por contenedor, que se orquesta y se reemplaza como una unidad, con el estado almacenado fuera de él. Elegir un contenedor de sistema para ejecutar un único proceso de servidor web añade una complejidad que un contenedor de Podman/Docker resolvería de forma más sencilla; elegir un motor de contenedores de aplicación para alojar un entorno heredado completo con varios servicios va en contra de los supuestos de la herramienta.

Cómo aplicarlo

• Acceso: el cliente incus requiere root o pertenecer al grupo incus-admin para tener control total del servidor local (el grupo incus da acceso a un proyecto restringido por usuario).
• Crear e inspeccionar una instancia: incus launch images:debian/12 mycontainer inicia un contenedor de sistema a partir de una imagen publicada (con --vm se crea una máquina virtual); incus list muestra todas las instancias con su tipo, estado y direcciones.
• Obtener una shell: incus exec mycontainer -- bash ejecuta un comando dentro de la instancia; incus console mycontainer se conecta a la consola de la instancia (útil antes de que la red esté activa; se sale con Ctrl+a q), y incus console mycontainer --show-log muestra el registro de la consola.
• Crear una instantánea antes de un cambio arriesgado: incus snapshot create mycontainer before-upgrade; después, incus snapshot restore mycontainer before-upgrade para revertir. Como toda instantánea, reside en el pool de almacenamiento de la propia instancia y no es una copia de seguridad independiente; para eso, incus export mycontainer /backup/mycontainer.tar.gz genera un tarball que se puede mover a otro almacenamiento.
• Usar Incus (o LXC directamente) cuando se quiere un entorno persistente, similar a un sistema operativo y con varios servicios, que comparta el kernel del host; usar Podman/Docker cuando la unidad de despliegue es un único proceso construido a partir de una imagen.

Trampas

• Suponer que un contenedor de sistema es un límite de seguridad equivalente a una VM: comparte el kernel del host, de modo que las vulnerabilidades del kernel afectan al aislamiento igual que en cualquier tecnología de contenedores. Los contenedores son no privilegiados (con mapeo de UID) por defecto; establecer security.privileged=true elimina ese mapeo y debe evitarse con cargas de trabajo no confiables.
• Ejecutar actualizaciones automáticas de paquetes dentro de muchos contenedores de sistema sin aplicar la misma disciplina de parches que se usa en el host: cada uno es un pequeño sistema operativo que necesita su propio mantenimiento.