Distribuciones Linux inmutables en servidores: analisis

Qué es una distribución Linux inmutable

Una distribución Linux inmutable distribuye el sistema operativo como una única imagen, por lo que se reemplaza el sistema en lugar de parchearlo sobre la marcha. No existe la reescritura de archivos bajo apt upgrade en /usr en un equipo en ejecución. Usted construye o descarga una imagen nueva, la máquina la prepara junto a la que está ejecutando y el siguiente reinicio intercambia cuál está activa. La imagen anterior permanece en el disco, por lo que deshacer una actualización fallida es cuestión de reiniciar.

El término "inmutable" es exagerado. Nada impide físicamente que root escriba en el disco. Lo que hacen estos sistemas es montar los directorios del sistema como de solo lectura y asignar su propiedad a la imagen. Los datos persistentes residen en /var. La configuración específica de la máquina reside en /etc. Todo lo que está bajo /usr pertenece a la imagen, razón por la cual dos servidores que ejecutan la misma etiqueta de imagen contienen archivos de sistema idénticos.

Los nombres de Red Hat para los dos modelos son los más claros: modo paquete y modo imagen. El modo paquete es un sistema en ejecución más un gestor de paquetes que lo edita. El modo imagen es un paso de construcción realizado en otro lugar que produce un artefacto, y un servidor cuyo único trabajo es arrancar el artefacto al que usted lo apunta. Todo lo que sigue a continuación se deriva de esa única diferencia.

Por qué un sistema de solo lectura es más importante en un servidor

Un servidor que lleva dos años en funcionamiento tiene un historial que nadie documentó. Un make install realizado durante una noche de prisas. Un repositorio de terceros añadido para un solo paquete. Un archivo de configuración editado durante una caída y nunca devuelto a su gestión de configuración. Esto se denomina deriva de configuración, y es la razón por la que reconstruir "el mismo" servidor a partir de sus notas a menudo produce una máquina que se comporta de forma distinta. Las notas contienen la intención. El disco contiene la verdad.

El modo de imagen elimina el lugar donde se acumula la deriva. /usr es de solo lectura durante la ejecución, por lo que una instalación realizada manualmente falla directamente o se registra como una capa que puede listar con un solo comando. Esto hace que la diferencia entre dos máquinas sea visible en lugar de arqueológica. Es el mismo problema que una lista de verificación de mantenimiento de servidores Linux estándar ataca con disciplina, pero gestionado por el sistema de archivos.

Rollback es un reinicio, y ese es todo el argumento

El fallo para el que está diseñado este modelo es el que ya documentamos: un VPS que no arranca después de actualizar el kernel. En modo de paquetes, la recuperación se hace desde la consola de rescate del proveedor. Se monta el disco, se entra en un chroot y se elimina manualmente un paquete del kernel. Funciona porque el bootloader conserva los kernels antiguos, pero sólo el kernel tiene ese versionado. La actualización de glibc y los cambios de systemd incluidos en la misma transacción ya se aplicaron, y no existe un único comando que los revierta juntos.

En modo de imágenes, la unidad es el sistema completo. En un host bootc:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback vuelve a colocar el bootloader en el orden anterior, de modo que arranque la entrada previa, que corresponde a la imagen que se estaba ejecutando hace una hora, con el kernel y el espacio de usuario juntos. No se descarga ni se reconstruye nada porque la imagen anterior nunca salió del disco. Si ha habilitado el temporizador de actualización automática descrito más abajo, deténgalo primero: la documentación de bootc advierte que un agente que realiza actualizaciones automáticas puede revertir el rollback.

Fedora CoreOS hace lo mismo con nombres diferentes:

sudo systemctl stop zincati.service
sudo rpm-ostree rollback -r

Detenga Zincati primero. Zincati es el agente que mantiene una máquina Fedora CoreOS en la versión más reciente. No volverá a instalar el despliegue que acaba de revertir, pero seguirá buscando actualizaciones y actualizará el sistema a cualquier versión más nueva que aparezca. Por tanto, ejecute sudo systemctl disable --now zincati.service si la máquina debe permanecer en su estado actual hasta que se publique una corrección. -r reinicia el sistema cuando el rollback está preparado. Para evitar que se elimine mediante garbage collection un despliegue en el que confía:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status muestra los despliegues en el orden en que el bootloader los ofrecerá, marca el que está en ejecución con un punto y muestra Pinned: yes en el que ha fijado.

Talos lo hace mediante una única llamada a la API desde su workstation:

talosctl rollback --nodes 10.20.30.40

Flatcar mantiene dos particiones /usr y alterna entre ellas. Cada slot tiene una prioridad y un contador de intentos en la tabla de particiones. Si un slot nunca arranca correctamente, agota sus intentos y el bootloader selecciona el otro. Compruebe qué slot está activo y si se marcó como correcto:

sudo cgpt show "$(rootdev -s /usr)" | grep successful=1

Un slot activo en buen estado muestra una línea que contiene tries=0 successful=1. El número de prioridad de esa misma línea sólo determina qué slot prefiere el bootloader, por lo que puede ser 1 o 2 en una máquina perfectamente sana. Si no hay ninguna línea coincidente, el slot actual nunca se confirmó. Ese es el estado de una máquina entre una actualización y su primer arranque correcto.

Qué sustituye a "instalar un paquete": bootc y un Containerfile

bootc es la herramienta que generalizó este patrón. Se define como actualizaciones del sistema operativo transaccionales y en el mismo lugar utilizando imágenes de contenedor OCI (Open Container Initiative), y es un proyecto en el Sandbox de la CNCF. Su servidor se convierte en un Containerfile. A fecha de agosto de 2026, la imagen base de Fedora es quay.io/fedora/fedora-bootc:44 y la imagen base de CentOS Stream es quay.io/centos-bootc/centos-bootc:stream10.

FROM quay.io/fedora/fedora-bootc:44
RUN dnf -y install nginx && dnf clean all
RUN systemctl enable nginx

Construya y envíe la imagen como cualquier otra:

sudo podman build -t registry.example.com/edge/web:2026-08-19 .
sudo podman push registry.example.com/edge/web:2026-08-19

Luego, en el servidor:

sudo bootc upgrade --check
sudo bootc upgrade --apply

bootc upgrade consulta la fuente de la imagen y pone en cola la nueva imagen para el siguiente arranque. --check informa si hay una actualización disponible sin realizar cambios. --apply reinicia el sistema con la nueva imagen. bootc switch registry.example.com/edge/web:next apunta la máquina a una imagen diferente mientras preserva /etc y /var, que es la forma en que se migra un servidor entre flujos de imágenes sin necesidad de reinstalarlo.

Para actualizaciones desatendidas, habilite el temporizador que incluye el proyecto:

sudo systemctl enable --now bootc-fetch-apply-updates.timer

Esta es la respuesta del modo imagen a actualizaciones desatendidas en Ubuntu y a dnf-automatic en Rocky y Alma. La diferencia radica en lo que se aplica. Un temporizador en modo paquete aplica las versiones que el repositorio contenga esa noche, por lo que el conjunto resultante es ligeramente distinto en cada máquina. Un temporizador en modo imagen aplica un artefacto que usted ya ha probado previamente en otro lugar.

De ese Containerfile se derivan dos reglas de construcción. Los datos de escritura pertenecen a /var, por lo que el software que insiste en escribir dentro de su propio directorio de instalación requiere un enlace simbólico o una línea BindPaths= de systemd añadida durante la construcción. Además, /etc se fusiona de forma tripartita durante la actualización, lo que significa que un archivo que nunca modificó recibirá la nueva versión de la imagen, mientras que un archivo que usted editó localmente se mantendrá.

Cuando necesite una herramienta en un equipo en ejecución para una sesión de depuración:

sudo bootc usr-overlay
sudo dnf -y install strace

Esto añade una capa superpuesta (overlay) temporal de escritura en /usr que se descarta en el siguiente reinicio. Es para analizar un problema, no para corregirlo. No puede cambiar el kernel de esta manera, y todo lo que instale desaparece al reiniciar por diseño.

Fedora CoreOS: aprovisionado una vez, actualizado para siempre

Fedora CoreOS no tiene un instalador interactivo. Usted escribe un archivo YAML de Butane, lo transpila a JSON de Ignition y se lo entrega a la máquina en el primer arranque:

podman run --interactive --rm quay.io/coreos/butane:release \
       --pretty --strict < your_config.bu > transpiled_config.ign

Ignition se ejecuta en el initramfs solo durante el primer arranque. Esta es la parte que confunde a quienes vienen de cloud-init. Si la configuración no incluye una clave SSH, la máquina arranca sin forma de acceder a ella, y la solución es aprovisionarla de nuevo desde cero. Pruebe la configuración en una máquina desechable antes de aplicarla a un servidor importante.

Instalación en un disco desde un entorno live:

sudo coreos-installer install /dev/sda \
    --ignition-url https://example.com/example.ign

Las actualizaciones son automáticas por defecto. Usted controla cuándo, no si se realizan. Coloque un archivo TOML en /etc/zincati/config.d/55-updates-strategy.toml que seleccione la estrategia periódica:

[updates]
strategy = "periodic"

Bajo esa estrategia, usted añade una ventana de mantenimiento por cada entrada en la matriz de tablas, de modo que cada ventana se abre con el nombre updates.periodic.window escrito entre corchetes dobles como encabezado, seguido de tres claves:

• days, una lista de nombres de días, como "Sat" y "Sun".
• start_time, el momento en que se abre la ventana, escrito como "22:30".
• length_minutes, cuánto tiempo permanece abierta, como 60.

Esos horarios están en UTC. Para detener las actualizaciones por completo, ejecute sudo systemctl disable --now zincati.service y acepte que ahora usted es responsable del calendario de parches.

La estratificación de paquetes (package layering) existe como una vía de escape:

sudo rpm-ostree install --allow-inactive vim
sudo systemctl reboot

Esto construye un nuevo despliegue con el paquete añadido, y el cambio solo surte efecto después del reinicio. El coste llega más tarde. Su conjunto estratificado se vuelve a aplicar sobre cada nueva imagen base, por lo que un paquete que haya desaparecido del repositorio el día de una actualización hará que dicha actualización falle. La propia documentación de Fedora le orienta hacia el uso de contenedores para cualquier cosa sustancial, y hacia una imagen bootc cuando realmente necesite modificar el sistema operativo.

Flatcar Container Linux: sin gestor de paquetes

Flatcar es la continuación de CoreOS Container Linux y la opción de propósito general más estricta. No dispone de un gestor de paquetes al cual recurrir. Todo lo que se ejecuta es un contenedor. El aprovisionamiento se realiza mediante Ignition, igual que en Fedora CoreOS. Las actualizaciones utilizan las dos particiones A/B /usr descritas anteriormente, gestionadas por update_engine, mientras que locksmithd determina cuándo ocurre el reinicio.

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT significa que la ranura pasiva ya contiene la nueva imagen y solo queda pendiente el reinicio. La estrategia de reinicio predeterminada es reboot con un retraso de cinco minutos, por lo que un único VPS en producción se reiniciará según su propio calendario a menos que se indique lo contrario. Defina una ventana en /etc/flatcar/update.conf:

REBOOT_STRATEGY=reboot
LOCKSMITHD_REBOOT_WINDOW_START="Thu 04:00"
LOCKSMITHD_REBOOT_WINDOW_LENGTH=1h

REBOOT_STRATEGY=off deja el reinicio bajo su control. SERVER=disabled en el mismo archivo detiene por completo la comprobación de actualizaciones. Para un clúster, REBOOT_STRATEGY=etcd-lock combinado con locksmithctl set-max 4 limita cuántos nodos pueden reiniciarse a la vez, de modo que una actualización nunca deje fuera de servicio a toda la flota simultáneamente.

Talos Linux: sin shell, sin SSH, sin consola

Talos es el más limitado de los cuatro y el que define con mayor claridad su propósito. Ejecuta nodos de Kubernetes. No incluye un daemon SSH, un shell de inicio de sesión ni un inicio de sesión en la consola. La consola física muestra un panel para inspeccionar el estado de la máquina, no un indicador de inicio de sesión. Todas las operaciones son llamadas a una API gRPC realizadas con talosctl desde la estación de trabajo, contra una configuración de máquina que se mantiene en git.

talosctl upgrade --nodes 10.20.30.40 \
  --image factory.talos.dev/metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v1.14.2

Desde Talos 1.14, la imagen ghcr.io/siderolabs/installer ya no se publica y las imágenes del instalador proceden de Image Factory. El ID largo de esa ruta corresponde al schematic vacío para una máquina sin personalizaciones. Use el schematic con el que se instaló el nodo para conservar sus extensiones del sistema y sustituya el tag por la release a la que va a actualizar. La actualización usa un esquema A-B que conserva el kernel y la imagen del sistema anteriores. Si la nueva versión no arranca, Talos revierte automáticamente sin intervención. La depuración es diferente porque no hay un shell de inicio de sesión: use talosctl logs y talosctl dmesg en lugar de journalctl en el nodo. Cuando necesite herramientas en el nodo, talosctl debug inicia un contenedor con privilegios a partir de una imagen proporcionada por usted y le abre su shell. El contenedor se elimina al salir.

Si su carga de trabajo no es Kubernetes, Talos no es la opción adecuada. Si lo es, Talos elimina toda una categoría de incidentes, porque no hay ninguna forma de que ocurra que alguien inicie sesión en un nodo y cambie algo.

Lo que realmente cede un inquilino de VPS

Instalaciones ad-hoc en un sistema en ejecución. Este es el punto principal. sudo apt install htop a las 2 a. m. durante un incidente no está disponible. En bootc se obtiene una capa transitoria que desaparece al reiniciar. En Fedora CoreOS se obtiene un despliegue por capas que requiere un reinicio. En Flatcar y Talos no se obtiene nada.

Una canalización de compilación que antes no tenía. Añadir un paquete significa editar un Containerfile, compilar la imagen, enviarla a un registro y desplegar los servidores. Eso es económico cuando la canalización ya existe. Es un trabajo real configurarla cuando no existe, y requiere un registro al que los servidores puedan acceder, lo cual es otro servicio que ejecutar u otra factura que pagar.

Módulos del kernel. El kernel proviene de la imagen, por lo que un módulo compilado para el kernel en ejecución no sobrevive a la siguiente actualización. Los módulos fuera del árbol y los paquetes DKMS (dynamic kernel module support) deben compilarse dentro de la imagen, contra el kernel de dicha imagen. Cualquier cosa que necesite un módulo que la imagen base no incluya se convierte en un problema de compilación en lugar de un problema de instalación.

Agentes de proveedores y servicios. Los agentes de monitorización y copia de seguridad suelen distribuirse como un .deb o .rpm con un script de instalación que escribe en /usr y habilita una unidad. En un sistema de solo lectura, ese script falla. Algunos proveedores publican un contenedor o documentan una instalación en modo imagen. Muchos no lo hacen. Compruebe esto antes de comprometerse, porque una flota que no puede monitorizar es peor que una flota que se desvía de su configuración.

La imagen en sí. Casi ningún panel de control de VPS lista Fedora CoreOS, Flatcar o Talos junto a Ubuntu y Debian. Usted proporciona el disco, que es la siguiente sección.

Cómo instalar uno de estos en un VPS alquilado

Confirme primero dos aspectos con su proveedor: que tenga acceso a una consola fuera de banda, es decir, VNC o una consola serie, y que pueda arrancar un sistema de rescate. Sin una consola, una máquina que no vuelve a arrancar se convierte en un ticket para soporte en lugar de una reparación de cinco minutos.

Si el proveedor acepta imágenes personalizadas, cargue la imagen raw o qcow2 del proveedor, pero la carga por sí sola no le proporciona una máquina en la que pueda iniciar sesión. El usuario core de Fedora CoreOS no tiene una contraseña ni una clave SSH predeterminadas, por lo que todavía debe proporcionar una configuración de Ignition que contenga su clave o, en una plataforma cloud compatible con Afterburn, establecer una clave mediante la función de claves SSH del propio proveedor. De lo contrario, debe escribir el disco desde el sistema de rescate. Flatcar incluye un script independiente para este propósito, que se ejecuta desde cualquier sistema Linux:

curl -fsSLO https://raw.githubusercontent.com/flatcar/init/flatcar-master/bin/flatcar-install
chmod +x flatcar-install
sudo ./flatcar-install -d /dev/sda -i ignition.json

Ejecute el script desde el sistema de rescate, nunca desde el servidor que va a sustituir, porque el script vuelve a particionar el dispositivo de destino durante la operación. Necesita al menos 8 GB de espacio utilizable en el dispositivo, y el entorno de rescate debe proporcionar bash, bzip2 o lbzip2, lsblk, wget, udevadm, gpg y gawk. Su ignition.json debe contener una clave SSH; de lo contrario, el sistema instalado no tendrá ninguna forma de permitirle el acceso.

Fedora CoreOS sigue el mismo esquema y su instalador se ejecuta como un contenedor:

sudo podman run --pull=always --privileged --rm \
    -v /dev:/dev -v /run/udev:/run/udev -v .:/data -w /data \
    quay.io/coreos/coreos-installer:release \
    install /dev/vdb -i config.ign

Compruebe el nombre del dispositivo con lsblk antes de ejecutarlo. Escribir en el dispositivo equivocado destruye lo que hubiera en él y no aparece ninguna solicitud de confirmación.

bootc ofrece la única opción que evita el modo de rescate, porque convierte un sistema Linux en ejecución directamente:

sudo podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \
             --pid=host --security-opt label=type:unconfined_t \
             quay.io/fedora/fedora-bootc:44 \
             bootc install to-existing-root

Lea la documentación de la imagen base que utiliza antes de ejecutar el comando y pruébelo en un servidor que pueda descartar. Después de reiniciar, la máquina ejecutará la imagen y el conjunto de paquetes que tenía habrá desaparecido.

Quién debería utilizar un servidor inmutable y quién no

Le conviene si trata sus servidores como ganado. Muchas máquinas a partir de una misma receta. Ejecutores de CI (integración continua) que viven una hora. Nodos de k3s o Kubernetes que se reemplazan en lugar de repararse. Cualquier escenario donde la respuesta ante un equipo averiado sea "eliminarlo y crear otro". También es rentable cuando debe demostrar a un auditor qué se está ejecutando en una máquina, ya que la respuesta es un resumen (digest) de la imagen en lugar de una lista de paquetes.

No le conviene si tiene un VPS gestionado manualmente con tres servicios, instala cosas cuando las necesita y no tiene una canalización (pipeline) de compilación. El modo de imagen no elimina el trabajo. Traslada el trabajo del servidor a la compilación y le obliga a usar un registro y una canalización para realizar el cambio. Si tiene dónde alojar ese trabajo, obtendrá servidores idénticos y una reversión que consiste en un reinicio. Si no lo tiene, habrá añadido piezas móviles a un equipo que funcionaba bien y habrá complicado las guardias de madrugada.

El punto intermedio sigue siendo válido: una distribución normal con actualizaciones de seguridad automáticas, además de un proceso de reconstrucción que haya practicado realmente. Elegir esa base es una decisión propia, tratada en elegir qué SO ejecutar en su VPS. El modo de imagen es solo la última vuelta de una discusión muy antigua sobre cómo debe llegar el software a una máquina, y la historia de las distribuciones Linux es, en gran medida, esa misma discusión repitiéndose.

FAQ

¿Una distribución Linux inmutable es realmente inmutable?

No, y el nombre puede causar confusión. root todavía puede escribir en el disco. Lo que ocurre en realidad es que /usr se monta como de sólo lectura durante la ejecución y se reemplaza por completo con la siguiente imagen, mientras /etc y /var siguen siendo modificables y conservan los datos entre actualizaciones. Los cambios que haga en /usr se rechazan en ese momento o se descartan durante la siguiente actualización. Por tanto, en la práctica, los directorios del sistema sólo cambian cuando cambia la imagen.

¿Puedo ejecutar Fedora CoreOS o Flatcar en un VPS que no los ofrece?

Normalmente sí, si el proveedor le proporciona un sistema de rescate y acceso a la consola. Arranque el sistema de rescate, escriba la imagen de disco de la distribución en el dispositivo de bloques y reinicie. El script flatcar-install de Flatcar hace esto desde cualquier sistema Linux, y Fedora CoreOS incluye coreos-installer como un contenedor que puede ejecutar de la misma forma. Ambos necesitan un archivo de Ignition que contenga su clave SSH, porque no hay un aviso de contraseña durante el primer arranque. Sin acceso a la consola, no lo intente: si la máquina no vuelve a arrancar, no tendrá nada que pueda revisar.

¿Cómo instalo un paquete en un servidor inmutable?

Añádalo a la imagen y vuelva a desplegarla. En bootc, esto consiste en una línea RUN dnf -y install ... en el Containerfile, una recompilación, un push y después sudo bootc upgrade --apply en la máquina. En Fedora CoreOS puede añadirlo mediante sudo rpm-ostree install y reiniciar, pero el paquete se volverá a aplicar en cada actualización futura. En Flatcar y Talos no hay un gestor de paquetes, por lo que la respuesta es un contenedor. Para una herramienta de depuración temporal en un host bootc, sudo bootc usr-overlay proporciona un /usr modificable que desaparece durante el siguiente reinicio.

¿El modo de imagen corrige un VPS que no arranca después de una actualización del kernel?

Convierte la recuperación, que antes requería la consola de rescate, en un reinicio. La imagen, el kernel y el espacio de usuario anteriores siguen juntos en el disco, por lo que sudo bootc rollback o sudo rpm-ostree rollback -r le devuelve a esa versión. Talos y Flatcar van más allá y revierten automáticamente si la nueva ranura no arranca, porque una entrada de arranque sólo se convierte en la predeterminada después de un arranque correcto. Nada de esto impide una actualización defectuosa. Sólo hace que deshacerla sea sencillo.

¿Qué distribución inmutable debería elegir para un servidor?

Elija bootc si quiere un servidor Linux de propósito general que se construya como una imagen de contenedor y que pueda instalarse en una máquina que ya tenga. Elija Fedora CoreOS si quiere ese modelo con la construcción ya preparada y actualizaciones automáticas desde el principio. Elija Flatcar si quiere un host de contenedores mínimo, con un esquema de actualización A/B y sin un gestor de paquetes disponible. Elija Talos sólo cuando la máquina sea un nodo de Kubernetes, porque no tiene un shell de inicio de sesión ni ejecuta nada más.