La lección anterior te dio aislamiento fuerte a un precio alto: cada máquina virtual lleva su propio kernel, tarda medio minuto en arrancar, ocupa gigabytes en disco y reserva memoria solo por existir. Para un entorno de pruebas es razonable. Para desplegar una aplicación y poder recrearla en segundos, es carísimo.

Esta lección construye la alternativa, y empieza por la idea que hay que tener clara antes de escribir el primer docker run, porque adquirirla mal condiciona todo lo que viene después:

Un contenedor no es una máquina pequeña. Es un proceso aislado.

No hay un sistema operativo dentro. No hay un kernel. No hay un arranque. Hay un proceso normal del anfitrión, ejecutándose con una vista restringida del sistema de ficheros, de la red y de la tabla de procesos, y con un límite de recursos. Todo lo que verás —las imágenes, los volúmenes, las redes, Compose— es maquinaria alrededor de esa idea.

Y las tres piezas del kernel que la hacen posible ya las conoces por separado: los cgroups son literalmente los del MemoryMax=512M que pusiste en 05-05, las capabilities son las de 05-02, y los namespaces de montaje son la evolución del chroot con el que reparaste GRUB en 07-01.

1. Las tres primitivas: namespaces, cgroups y capabilities
2. Namespaces de usuario y el sysctl que dejaste comentado
3. Instalar Docker, y por qué el grupo docker equivale a root
4. Imágenes, contenedores y registros
5. docker run y las opciones que importan
6. Dockerfile: construir la imagen de Tramontana
7. Construcción en varias etapas y elección de imagen base
8. Datos: volúmenes, bind mounts y tmpfs
9. Red y publicación de puertos
10. Docker Compose
11. Seguridad de contenedores
12. Alternativas, y cuándo no usar contenedores

Un contenedor no es una función del kernel. No existe una llamada al sistema crear_contenedor(). Es una convención: un proceso lanzado con ciertas restricciones activadas a la vez. Verlo directamente, sin Docker de por medio, es lo que hace que todo lo demás encaje.

Un namespace aísla una clase de recurso global del kernel, de modo que los procesos dentro de él vean su propia instancia. Hay siete:

Todos los procesos comparten los mismos namespaces, porque no hay ningún contenedor en marcha. Vamos a crear uno a mano, sin Docker:

Ahí está el efecto: bash es el PID 1 y solo ve dos procesos. Desde fuera, el mismo proceso tiene un PID normal:

El proceso es el mismo. Lo único que cambia es lo que ve. Y esto explica por qué un contenedor arranca en milisegundos: no hay nada que arrancar, solo un clone() con unas banderas.

El namespace de red es especialmente ilustrativo, porque el aislamiento es total:

Ni enp0s3, ni IP, ni rutas, ni un solo socket. Y lo está DOWN. Ese es el punto de partida de cualquier contenedor de Docker antes de que se le conecte una interfaz virtual.

En 07-01 usaste chroot para entrar en un sistema instalado y reparar GRUB. chroot cambia la raíz del sistema de ficheros para un proceso — es decir, hace una parte de lo que hace un namespace de montaje.

Pero solo esa parte, y por eso chroot no es un mecanismo de seguridad:

Un proceso con privilegios dentro de un chroot puede salir de él con relativa facilidad —hay técnicas conocidas y documentadas— y, aunque no saliera, tiene acceso completo a la red, a los procesos y a los dispositivos del anfitrión. El namespace de montaje resuelve el escape; los otros seis namespaces resuelven el resto.

Los namespaces controlan lo que un proceso ve; los cgroups controlan lo que consume. Y esto ya lo has usado:

Es exactamente la misma tecnología. Cuando en 05-05 pusiste MemoryMax=512M en la unidad de systemd, estabas creando un cgroup con memory.max. Docker hace lo mismo con --memory 512m. La diferencia es el envoltorio, no el mecanismo.

De 05-02: en lugar de «root o no root», el kernel divide los privilegios en unas cuarenta capacidades independientes.

Esto es lo que permite que el proceso principal de un contenedor pueda ser «root» y aun así no pueda hacer casi nada peligroso: se le retiran casi todas las capacidades. Docker, por defecto, deja unas catorce de las cuarenta.

Y con las tres primitivas juntas, ya puedes definir qué es un contenedor sin ninguna magia:

Un contenedor es un proceso lanzado con namespaces propios, dentro de un cgroup con límites, con un conjunto reducido de capabilities, y con la raíz del sistema de ficheros apuntando a la imagen.

El namespace de usuario es el más reciente y el que más consecuencias de seguridad tiene. Permite que un UID dentro se corresponda con un UID distinto fuera:

Léelo despacio, porque es contraintuitivo: id dice uid=0(root), pero no puede escribir en /etc. El uid_map explica por qué — el UID 0 dentro es el UID 1000 fuera. Es root de su propio namespace y nadie más.

Eso es lo que hace posibles los contenedores sin privilegios (rootless): un usuario normal puede crear namespaces, montar sistemas de ficheros dentro y ser root dentro de su contenedor, sin ser root en el anfitrión.

Y ahora, el parámetro que dejaste comentado en 06-06:

La tensión es real y merece entenderse en ambos sentidos:

La decisión para srv-tramontana: dejarlo activo, porque va a ejecutar contenedores. Y la nota que se añade al fichero, porque el criterio es lo que hay que documentar:

Un endurecimiento descartado con su motivo escrito es conocimiento; descartado en silencio es una omisión.

Docker no está en los repositorios de Ubuntu con la versión actual, así que se instala desde el repositorio oficial aplicando lo de 05-03: clave en /etc/apt/keyrings/ y signed-by.

Fíjate en que añadir un repositorio de terceros es una decisión de seguridad, como se dijo en 05-03: a partir de ahora, quien controle ese repositorio puede instalar paquetes en tu servidor. signed-by limita la clave a ese repositorio concreto, que es lo mínimo exigible.

Ese comando aparece en todos los tutoriales como una comodidad, y su implicación real casi nunca se explica:

Pertenecer al grupo docker es equivalente a tener root sin contraseña, y sin dejar el rastro que deja sudo.

No es una exageración. La demostración cabe en una línea:

El demonio de Docker corre como root, y -v /:/anfitrion le pide montar la raíz del anfitrión dentro del contenedor. Cualquiera del grupo docker puede leer /etc/shadow, escribir en /etc/sudoers.d/, o modificar /etc/tramontana/secretos/. Y lo hace sin aparecer en auth.log.

Las consecuencias prácticas, que hay que aplicar:

1. El grupo docker se trata como el grupo sudo, con el mismo control de quién entra y por qué. En srv-tramontana solo operador, y consta en la checklist de 06-06.
2. Nunca se añade a una cuenta de servicio ni a un usuario de aplicación. Si svc-tramontana estuviera en docker, un compromiso de la aplicación sería root inmediato.
3. La alternativa correcta cuando hay varias personas es sudo docker, con una regla en sudoers.d que registre quién ejecuta qué — coherente con lo que hiciste en 05-02 con desplegar-seguro.
4. O usar podman, que no tiene demonio con privilegios y resuelve el problema de raíz. Se ve al final de la lección.

Tres conceptos que se confunden y que conviene separar de una vez:

La propiedad más importante de una imagen es que está formada por capas, cada una un conjunto de cambios sobre la anterior, identificada por su suma criptográfica:

Las capas se comparten entre imágenes: si diez imágenes se basan en alpine:3.20, esos 7,8 MB se almacenan una sola vez. Es la misma idea que los discos de respaldo de qcow2 en 07-04, aplicada al sistema de ficheros.

Y la implicación de seguridad de las capas, que hay que tener presente al escribir un Dockerfile: una capa nunca desaparece. Si en una capa copias un fichero con una contraseña y en la siguiente lo borras, el fichero sigue estando en la imagen y se puede extraer. Volveremos a ello.

Y ahora la comprobación que cierra el primer apartado. Desde el anfitrión:

El proceso de nginx está en la tabla de procesos del anfitrión, con un PID normal, y pgrep lo encuentra. Solo tiene namespaces propios y un cgroup. No hay ninguna máquina, ningún kernel, ningún arranque. Es un proceso.

Las opciones de docker run que se usan de verdad:

Las de gestión del ciclo de vida:

docker stop envía SIGTERM, espera 10 segundos y luego SIGKILL — exactamente la disciplina de señales de 03-06. Si tu aplicación necesita más tiempo para cerrar limpiamente, --time 30.

Un Dockerfile es la receta de una imagen. Cada instrucción que modifica el sistema de ficheros crea una capa.

Las instrucciones y lo que hay que saber de cada una:

Docker reutiliza una capa si la instrucción y su contexto no han cambiado. En cuanto una capa se invalida, todas las siguientes se reconstruyen. De ahí la regla:

Ordena las instrucciones de menos a más frecuentemente cambiante.

En la primera versión, cambiar una línea de código obliga a volver a descargar todas las dependencias: minutos en cada construcción. En la segunda, segundos.

Y la otra regla de capas, la de encadenar:

El rm en un RUN posterior no reduce el tamaño: la capa anterior ya contiene los ficheros, y las capas son inmutables. Es el mismo motivo por el que un secreto copiado y luego borrado sigue siendo extraíble de la imagen.

.dockerignore importa por dos motivos: velocidad —el contexto se envía entero al demonio— y seguridad, porque sin él un COPY . . puede meter en la imagen el directorio .git con todo el historial, o un .env con credenciales.

19,4 MB. La comparación con una construcción de una sola etapa explica de dónde viene:

Y el beneficio no es solo el disco. La imagen de 850 MB contiene el compilador de Go, git, make y decenas de bibliotecas: cada una es superficie de ataque y una fuente potencial de CVE. La de 19 MB no tiene nada de eso. Es el principio de superficie mínima de 06-06 aplicado a una imagen.

Las bases habituales:

Alpine, que se mencionó en 01-03 al hablar de distribuciones, tiene una peculiaridad que hay que conocer: usa musl en lugar de glibc. Un binario compilado contra glibc no funciona en Alpine, y algunas aplicaciones —notablemente en Python con extensiones nativas— tienen problemas sutiles de rendimiento con el asignador de memoria de musl. Con Go y CGO_ENABLED=0 no hay problema, porque el binario es estático.

Las imágenes distroless van un paso más allá: no tienen shell, ni ls, ni gestor de paquetes. Un atacante que consiga ejecución no tiene con qué operar. A cambio, depurar exige docker debug o una imagen paralela con herramientas.

El sistema de ficheros de un contenedor es efímero: al borrarlo, la capa de escritura desaparece. Los datos que deben sobrevivir se montan desde fuera, y hay tres formas:

Ese noexec,nosuid del tmpfs es el mismo criterio que aplicaste a /tmp en 06-06.

La preferencia por volúmenes frente a bind mounts para datos tiene motivos concretos: Docker los gestiona (creación, permisos, respaldo con docker run --volumes-from), son portables entre anfitriones, y no dependen de que exista una ruta concreta. Los bind mounts son mejores para configuración —porque quieres editarla desde el anfitrión con tus herramientas— y para desarrollo.

Y la advertencia de permisos, que es la fuente número uno de frustración con volúmenes: los UID son numéricos y no se traducen. Un fichero propiedad del UID 997 en el anfitrión pertenece al UID 997 dentro del contenedor, se llame como se llame ese usuario allí. Por eso el Dockerfile de Tramontana crea svc-tramontana con el UID 997 y el grupo con el GID 1002: para que coincidan con el servidor.

La diferencia entre la red bridge por defecto y una red de usuario es la que decide el diseño:

Eso es lo que permite que app.conf diga db_host=bd en lugar de una IP que cambia en cada arranque. En la red bridge por defecto no funciona.

Y la publicación de puertos, con un detalle de seguridad importante:

Aviso serio: Docker escribe reglas en nftables y se salta ufw. Un -p 8080:8080 inserta una regla en la cadena DOCKER que se evalúa antes que las de ufw, así que el puerto queda accesible desde Internet aunque ufw status diga que está bloqueado.

Se comprueba, y hay que comprobarlo:

Las dos soluciones: publicar siempre con 127.0.0.1: delante —que es lo correcto cuando hay un proxy inverso delante, como habrá en 08-01—, o desactivar la manipulación de reglas de Docker:

Cuidado: con "iptables": false los contenedores pierden la salida a Internet salvo que escribas tú las reglas de NAT. La opción práctica en la mayoría de los casos es la primera.

Fíjate también en "log-driver": "journald": envía la salida de los contenedores al journal, así que journalctl y el logrotate de 05-06 se aplican también a ellos. Por defecto, Docker escribe a ficheros JSON que crecen sin límite y son una causa habitual de discos llenos.

Un compose.yaml describe el conjunto de servicios, redes y volúmenes en un fichero versionable:

depends_on con condition: service_healthy es la pieza que resuelve un problema real: sin ella, depends_on solo espera a que el contenedor exista, no a que el servicio de dentro esté listo. La aplicación arrancaría, no encontraría la base de datos y moriría. Con la condición, Compose espera al healthcheck.

Ese -v merece el aviso: docker compose down -v borra los volúmenes, es decir, la base de datos. Es un rm -rf con otro nombre, y la disciplina de 02-04 se aplica igual.

El aislamiento de un contenedor es más débil que el de una VM, así que las medidas importan más. Las que hay que aplicar siempre:

Sobre los secretos, la demostración de por qué ENV es mala idea:

Es exactamente el problema que resolviste en 06-05 con LoadCredentialEncrypted. El equivalente en Docker es la sección secrets del compose.yaml, que monta el fichero en un tmpfs dentro del contenedor:

Y el escaneo de imágenes:

Fíjate en un detalle que ilustra la advertencia del grupo docker: ese comando monta /var/run/docker.sock dentro de un contenedor, lo que le da control completo del demonio de Docker y por tanto del anfitrión. Se hace con imágenes en las que confías, y con conciencia de lo que implica.

Dos medidas más que cierran el círculo con módulos anteriores:

El perfil docker-default de AppArmor y el filtro seccomp por defecto bloquean unas cuarenta llamadas al sistema peligrosas. Desactivarlos con --privileged o --security-opt seccomp=unconfined es lo que convierte un contenedor en un proceso con acceso casi total al anfitrión, y --privileged no debe aparecer nunca en producción.

Podman merece atención por lo que resuelve:

podman no tiene demonio: cada contenedor es un proceso hijo del que lo lanza. En modo rootless usa namespaces de usuario, así que no existe el problema del grupo docker. Sus comandos son compatibles (alias docker=podman funciona casi siempre) y se integra con systemd generando unidades, lo que encaja bien con todo lo del Módulo 5. Para un servidor donde varias personas ejecutan contenedores, es la opción más defendible.

LXC es distinto en concepto: contenedores de sistema, con init completo dentro, varios procesos y sesiones. Se parece más a una VM ligera que a un proceso aislado.

La honestidad que falta en la mayoría de las guías:

Ese cuarto punto se aplica a Tramontana ahora mismo: srv-tramontana funciona, está endurecido, monitorizado y documentado. Contenerizarlo hoy añadiría complejidad sin resolver ningún problema pendiente. Los contenedores brillan cuando hay varios servicios, varios entornos o varios servidores — que es justo el terreno de las dos lecciones siguientes.

• Pensar en un contenedor como en una VM pequeña. Lleva a meter systemd, sshd y cron dentro, y a tratar el contenedor como una máquina que se administra. Un contenedor ejecuta un proceso y se reemplaza, no se administra.
• Añadir a alguien al grupo docker sin entender lo que implica. Es root sin contraseña y sin traza. Trátalo como el grupo sudo.
• Usar latest. La imagen cambia sin avisar, y una reconstrucción de la semana que viene no produce lo mismo. Fija la versión, y en producción el digest.
• Poner secretos en ENV o en una capa. Quedan en la imagen para siempre, aunque los borres después: las capas son inmutables. Usa secrets o un fichero montado.
• Copiar el código antes de las dependencias en el Dockerfile. Invalida la caché en cada cambio y convierte una construcción de segundos en una de minutos.
• rm en un RUN posterior para reducir tamaño. No funciona: la capa anterior ya contiene los ficheros. Encadena con && dentro del mismo RUN.
• Olvidar .dockerignore. Un COPY . . puede meter .git entero, o un .env con credenciales, en la imagen.
• Ejecutar como root dentro del contenedor. Es el valor por defecto y es lo primero que hay que cambiar con USER.
• Publicar con -p 8080:8080 y creer que ufw protege. Docker escribe reglas que se evalúan antes. Usa -p 127.0.0.1:8080:8080 y verifícalo desde fuera con nmap.
• Dejar el controlador de registro por defecto. Los ficheros JSON crecen sin límite. "log-driver": "journald" los integra con journalctl y logrotate.
• docker compose down -v sin pensarlo. Borra los volúmenes, es decir, los datos.
• --privileged para «que funcione». Desactiva seccomp, AppArmor y las capabilities de golde. Nunca en producción; busca la capability concreta que falta.
• Consejo de método. Un contenedor debe poder morir y renacer sin que se pierda nada. Si el tuyo tiene estado dentro de su capa de escritura, algo está mal montado: todo lo que importa va en un volumen.

Demuestra, sin usar Docker, que un contenedor es un proceso aislado. Crea un «contenedor» a mano con unshare que tenga su propio nombre de máquina, su propia tabla de procesos y su propia red, y comprueba desde el anfitrión que sigue siendo un proceso normal. Explica qué le falta a tu construcción para ser un contenedor de verdad.

Revisa este Dockerfile que ha escrito Luis y corrígelo, explicando cada problema:

Marta pregunta si conviene migrar Tramontana Reservas a contenedores. Redacta el análisis, teniendo en cuenta el estado real del servidor y lo que se ha visto en las dos últimas lecciones.

Solución 1

Antes hace falta una raíz mínima, que es justo lo que hace una imagen:

Y ahora, dentro:

Nombre propio, PID 1, dos procesos visibles, sin red, y una distribución distinta a la del anfitrión — todo sin arrancar ningún kernel.

La línea NSpid: 10415 1 es la demostración exacta: el mismo proceso tiene el PID 10415 en el anfitrión y el PID 1 dentro de su namespace. Y uname -r da el mismo kernel en ambos lados:

Qué le falta para ser un contenedor de verdad:

La conclusión que se pide: Docker no aporta ninguna primitiva nueva. El aislamiento ya está en el kernel desde hace más de una década. Lo que aporta es el empaquetado: un formato de imagen con capas compartidas, un registro donde publicarlas, una forma reproducible de construirlas, y la aplicación coherente de las ocho restricciones de la tabla, que a mano serían un guion largo y fácil de equivocar. Entender esto explica por qué existen alternativas compatibles como podman: si las primitivas son del kernel, cualquiera puede orquestarlas.

Solución 2

Once problemas. La versión corregida, y después el porqué de cada uno:

Y el .dockerignore que faltaba por completo:

Los once problemas, en orden de gravedad:

El resultado medido:

684 MB frente a 142, y la contraseña recuperable con un solo comando por cualquiera que tenga acceso a la imagen.

La nota que hay que darle a Luis: la contraseña que aparece en ese Dockerfile es la de producción, así que —siguiendo la regla de 06-05— se considera comprometida desde el momento en que se escribió, y hay que rotarla con el procedimiento crear-aplicar-verificar-retirar. No basta con corregir el fichero.

Solución 3

Análisis: migrar Tramontana Reservas a contenedores Para: Marta Vidal · De: Operaciones de sistemas · 18 de agosto de 2026

Recomendación breve: no todavía, pero sí prepararlo. Contenerizar hoy srv-tramontana añadiría complejidad sin resolver ningún problema pendiente. Propongo un camino intermedio con beneficio inmediato y sin riesgo.

---

El punto de partida importa. No estamos ante una aplicación desplegada de cualquier manera. srv-tramontana tiene despliegue atómico con rollback automático, servicio de systemd endurecido con la mejor puntuación de seguridad que da la herramienta, secretos cifrados, registros centralizados en el journal con rotación, copias con restauración probada, detección de cambios y un firewall de lista blanca. Funciona, está documentado y está medido. Esa es la referencia contra la que hay que comparar.

Qué ganaríamos

1. Despliegues reproducibles bit a bit. Hoy desplegar.sh mueve un enlace simbólico a un directorio nuevo, y el entorno —bibliotecas del sistema, versiones— es el que haya en la máquina. Con una imagen, lo que se prueba es exactamente lo que se despliega. Recuerda que el release 3.3.0 falló en julio y no supimos por qué hasta esta semana: un fallo de ese tipo es menos probable con imágenes, porque el entorno viaja con la aplicación.
2. Rollback aún más rápido. Volver a la imagen anterior es cambiar una etiqueta.
3. Paridad entre entornos. La misma imagen en pruebas y en producción, sin la deriva que aparece cuando se configuran dos máquinas por separado.
4. Aislamiento adicional de la aplicación. Un compromiso quedaría más contenido: sin shell útil, sin acceso al resto del sistema de ficheros, sin capabilities.
5. Preparación para crecer. Si en algún momento hacen falta dos o tres instancias detrás de un balanceador, con contenedores es cuestión de minutos.

Qué costaría

1. Rehacer trabajo que ya está hecho y validado. El endurecimiento de systemd, el perfil de AppArmor, la gestión de secretos y la integración con el journal habría que reconstruirlos con el equivalente de contenedores. No es imposible, pero es semanas de trabajo para llegar donde ya estamos.
2. Una capa más que aprender y mantener. Imágenes, registros, redes virtuales, volúmenes, y sus modos de fallo propios — que son distintos y menos conocidos que los del sistema.
3. Un riesgo de seguridad nuevo y concreto. El demonio de Docker corre como root, y pertenecer al grupo docker equivale a tener root sin dejar traza. Además, Docker escribe reglas de cortafuegos que se saltan ufw: un puerto publicado queda abierto aunque el firewall diga lo contrario. Lo he verificado en el laboratorio. Habría que gestionarlo explícitamente.
4. La base de datos es el punto difícil. PostgreSQL en contenedor es posible, pero el almacenamiento persistente añade complejidad y no aporta nada en un único servidor. Mi recomendación sería dejarla fuera en cualquier caso.
5. No resuelve nuestro problema real. Nuestro problema abierto es que srv-tramontana es un único punto de fallo. Los contenedores no lo resuelven: si la máquina cae, caen los contenedores. Eso es redundancia, y es el tema del que te traeré una propuesta.

---

Lo que propongo, en tres pasos

Paso 1 — Ahora: contenerizar solo el entorno de pruebas. Beneficio inmediato, riesgo nulo. Permite levantar la aplicación y una base de datos limpia en segundos para probar un cambio, y aprender la herramienta sin exponer producción. Ya está funcionando en srv-tramontana-pruebas.

Paso 2 — Después: construir la imagen en cada release, sin desplegarla. Cada versión produce además una imagen versionada y escaneada. Ganamos reproducibilidad y detección de vulnerabilidades en las dependencias, sin cambiar nada en producción. Es un paso reversible.

Paso 3 — Cuando se cumpla alguna condición: migrar. Las condiciones que lo justificarían:

Condición	Por qué cambia la decisión
Hacen falta dos o más instancias de la aplicación	Es donde los contenedores empiezan a rendir de verdad
Aparecen más servicios (una API, un procesador de tareas)	Gestionar cinco servicios a mano es donde Compose gana
Hay más de un entorno que mantener sincronizado	La paridad deja de ser un lujo
Volvemos a tener un fallo por diferencias de entorno	Sería la segunda vez; una es casualidad

Y una observación sobre la alternativa. Si damos el paso, propongo evaluar podman en lugar de Docker: no tiene demonio con privilegios, funciona sin root, resuelve de raíz el problema del grupo docker, y se integra con systemd generando unidades — es decir, encaja con todo lo que ya tenemos montado en vez de sustituirlo. Sus comandos son compatibles, así que lo aprendido no se pierde.

Resumen. Los contenedores son la respuesta correcta a un problema de escala y reproducibilidad entre entornos. Hoy tenemos un servidor, un entorno y una aplicación que funciona, así que el beneficio no compensa el coste. Empezamos por pruebas y por construir las imágenes, que es donde el beneficio es inmediato, y reevaluamos cuando cambie alguna de las condiciones de la tabla.

Tienes la idea correcta, que es lo que más vale de esta lección: un contenedor es un proceso aislado, no una máquina pequeña. Lo has visto sin intermediarios —un bash que es PID 1 dentro y tiene un PID normal fuera, con NSpid: 10415 1 en /proc como prueba— y sabes que Docker no inventa ninguna primitiva: los namespaces, los cgroups y las capabilities están en el kernel, y son literalmente los mismos que el MemoryMax=512M de 05-05 y el chroot de 07-01. Lo que Docker aporta es el empaquetado: imágenes en capas compartidas, un registro, construcción reproducible, y la aplicación coherente de ocho restricciones que a mano serían un guion largo y frágil.

Sabes construir una imagen que pese 19 MB en lugar de 850, ordenando las instrucciones para aprovechar la caché y usando dos etapas para que el compilador no llegue a producción — que es el principio de superficie mínima de 06-06 aplicado a una imagen. Sabes que un secreto en una capa no se borra nunca, que -p 8080:8080 se salta ufw y hay que verificarlo desde fuera con nmap, que USER no es opcional, y que docker compose down -v destruye los datos. Y has resuelto el kernel.unprivileged_userns_clone que dejaste comentado en 06-06: se queda activo, con la decisión y su motivo escritos, porque la contención que aportan los contenedores vale más que la superficie que cierra.

Fíjate ahora en dónde estás. Tienes srv-tramontana en producción, srv-tramontana-pruebas recreable con cloud-init, y contenedores que levantan la aplicación y su base de datos con un comando. Tres formas de crear máquinas y servicios. Y las tres comparten un problema: la configuración de producción sigue siendo un runbook en prosa y la memoria del administrador. Cada usuario, cada regla de sudoers, cada unidad de systemd, cada línea de ufw, cada sysctl y cada perfil de AppArmor de los módulos 5 y 6 se aplicó a mano. El RTO de 8 horas que Marta aprobó depende enteramente de que alguien recuerde el orden correcto, y la regla de 06-04 —«un servidor comprometido se reinstala, no se limpia»— es fácil de decir y cara de cumplir.

En la lección 07-06: Automatización con Ansible eso se convierte en código. Verás la diferencia entre un script imperativo como desplegar.sh y un estado deseado idempotente, entenderás por qué Ansible no necesita agente —trabaja sobre el SSH que endureciste en 06-02— y escribirás inventarios, playbooks con handlers y etiquetas, plantillas Jinja2 que generan app.conf con variables por entorno, y roles que organizan todo en piezas reutilizables. Usarás --check y --diff, que son el --dry-run del curso llevado a la configuración entera, guardarás los secretos con Vault junto a tu pass, y probarás cada cambio contra srv-tramontana-pruebas antes de tocar producción. Y al final harás la medición que importa: cuánto tarda en reconstruirse el servidor desde cero. Ese número —de ocho horas a menos de una— es lo que convierte una regla de seguridad en un procedimiento que de verdad se puede cumplir.