Distribuciones Linux inmutables para servidores: costes

Qué es una distribución Linux inmutable

Una distribución Linux inmutable entrega el sistema operativo como una sola imagen. Por eso, se reemplaza el sistema en lugar de aplicar parches directamente sobre él. No se apt upgrade reescriben archivos bajo /usr en un servidor en ejecución. Se crea o se descarga una imagen nueva. La máquina la prepara junto a la imagen que está ejecutando. En el siguiente reinicio, cambia cuál de las dos está activa. La imagen anterior sigue en el disco. Por tanto, deshacer una actualización defectuosa sólo requiere reiniciar.

El término «inmutable» exagera sus propiedades. Nada impide físicamente que root escriba en el disco. Estos sistemas montan los directorios del sistema en modo de solo lectura y asignan su propiedad a la imagen. Los datos persistentes se almacenan en /var. La configuración específica de la máquina se almacena en /etc. Todo lo que está bajo /usr pertenece a la imagen. Por eso, 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 de paquetes y modo de imagen. El modo de paquetes es un sistema en ejecución junto con un gestor de paquetes que lo modifica. El modo de imagen consiste en un proceso de compilación que se ejecuta en otro lugar y produce un artefacto, y en un servidor cuya única función es arrancar el artefacto que se le indique. Todo lo que sigue 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 ejecución tiene un historial que nadie documentó. Un make install de una tarde con prisas. Un repositorio de terceros añadido para instalar un paquete. Un archivo de configuración editado durante una interrupción del servicio y que nunca se volvió a incluir en la gestión de configuración. Esto se denomina deriva de configuración y explica por qué reconstruir «el mismo» servidor a partir de las notas suele producir un equipo que se comporta de otra manera. Las notas contienen la intención. El disco contiene la realidad.

Image mode elimina el lugar donde se acumula la deriva. /usr es de solo lectura durante la ejecución, por lo que una instalación manual falla directamente o queda registrada como una capa que se puede enumerar con un solo comando. Así, la diferencia entre dos máquinas queda visible en lugar de tener que reconstruirla a partir de indicios. Es el mismo problema que aborda una lista de comprobación normal de mantenimiento de Linux con disciplina, pero gestionado desde el sistema de archivos.

El rollback consiste en reiniciar; esa es toda la propuesta

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 el modo basado en paquetes, la recuperación se realiza desde la consola de rescate del proveedor. Se monta el disco, se entra con chroot y se elimina manualmente un paquete del kernel. Esto funciona porque el gestor de arranque conserva los kernels anteriores, pero sólo el kernel se versiona de esa forma. 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 conjuntamente.

En el modo basado en 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 establecer el orden anterior del gestor de arranque. Esa entrada corresponde a la imagen que estaba en ejecución 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.

Fedora CoreOS hace lo mismo con otros nombres:

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. Si lo deja en ejecución, preparará la actualización que acaba de revertir. -r reinicia el sistema una vez preparado el rollback. Para evitar que se elimine mediante la recolección de basura 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 gestor de arranque los ofrecerá, marca el que está en ejecución con un punto y muestra Pinned: yes en el que fijó.

Talos lo hace mediante una sola llamada a la API desde su estación de trabajo:

talosctl rollback --nodes 10.20.30.40

Flatcar mantiene dos particiones /usr y alterna entre ellas. Cada ranura tiene una prioridad y un contador de intentos en la tabla de particiones. Por ello, una ranura que nunca arranca correctamente agota sus intentos y el gestor de arranque selecciona la otra. Compruebe qué ranura está usando y si se marcó como correcta:

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

Una ranura en ejecución y en buen estado muestra una línea que contiene priority=1 tries=0 successful=1. Si no hay ninguna línea coincidente, la ranura actual nunca se confirmó. Ese es el estado en el que permanece una máquina entre una actualización y su primer arranque correcto.

Qué sustituye a «install a package»: bootc y un Containerfile

bootc es la herramienta que generalizó este patrón. Se describe como una herramienta para realizar actualizaciones transaccionales del sistema operativo en el mismo lugar mediante imágenes de contenedor OCI (open container initiative), y es un proyecto de CNCF Sandbox. El servidor se convierte en un Containerfile. En agosto de 2026, la imagen base de Fedora es quay.io/fedora/fedora-bootc:44 y la 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

Constrúyala y publíquela como cualquier otra imagen:

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

Después, en el servidor:

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

bootc upgrade consulta el origen de la imagen y pone la nueva imagen en cola para el siguiente arranque. --check informa de si hay una actualización disponible y no cambia nada. --apply reinicia el sistema para usarla. bootc switch registry.example.com/edge/web:next cambia la imagen asignada al equipo y conserva /etc y /var. Así puede mover un servidor entre flujos de imágenes sin reinstalarlo.

Para las actualizaciones desatendidas, habilite el temporizador que proporciona el proyecto:

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

Esta es la respuesta del modo de imagen a las actualizaciones desatendidas en Ubuntu y a dnf-automatic en Rocky y Alma. La diferencia está en lo que se instala. Un temporizador del modo de paquetes aplica las versiones que el repositorio contiene esa noche, por lo que el conjunto resultante es ligeramente distinto en cada equipo. Un temporizador del modo de imagen aplica un artefacto que ya ha arrancado en otro lugar.

De ese Containerfile se derivan dos reglas de compilación. Los datos modificables deben estar en /var. Por tanto, el software que exige escribir dentro de su propio directorio de instalación necesita un enlace simbólico o una línea BindPaths= de systemd añadida durante la compilación. Además, /etc se combina mediante una fusión de tres vías durante la actualización. Esto significa que un archivo que nunca modificó recibe la nueva versión de la imagen, mientras que se conserva un archivo que editó localmente.

Cuando necesite una herramienta en un sistema activo para una sesión de depuración:

sudo bootc usr-overlay
sudo dnf -y install strace

Esto añade una superposición modificable temporal en /usr que se descarta en el siguiente reinicio. Sirve para analizar un problema, no para solucionarlo. No puede cambiar el kernel de esta forma, y todo lo que instale desaparece al reiniciar por diseño.

Fedora CoreOS: se aprovisiona una vez y se actualiza para siempre

Fedora CoreOS no tiene un instalador interactivo. Escriba un archivo YAML de Butane, transpílelo a JSON de Ignition y entréguelo a la máquina durante 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 únicamente durante el primer arranque. Esta es la diferencia que suele causar problemas a quienes vienen de cloud-init. Si la configuración no incluye una clave SSH, la máquina arranca sin ningún acceso y la solución consiste en 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 de forma predeterminada. Usted controla cuándo se aplican, no si se aplican. Cree un archivo TOML en /etc/zincati/config.d/55-updates-strategy.toml para seleccionar la estrategia periódica:

[updates]
strategy = "periodic"

Con esa estrategia, añada una ventana de mantenimiento por cada entrada de la matriz de tablas. Cada ventana comienza 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.

Esas horas están expresadas en UTC. Para detener completamente las actualizaciones, ejecute sudo systemctl disable --now zincati.service y asuma la responsabilidad del calendario de parches.

El uso de capas de paquetes existe como mecanismo de excepción:

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

Esto crea un nuevo despliegue con el paquete añadido, pero el cambio sólo se aplica después de reiniciar. El coste aparece más adelante. El conjunto de capas se vuelve a aplicar sobre cada nueva imagen base. Por tanto, si un paquete desaparece del repositorio el día de una actualización, esa actualización falla. La documentación de Fedora recomienda usar contenedores para todo lo que sea sustancial y 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 más estricta entre las de propósito general. No hay ningún gestor de paquetes disponible como alternativa. Todo lo que se ejecuta es un contenedor. El aprovisionamiento se realiza con Ignition, igual que en Fedora CoreOS. Las actualizaciones utilizan las dos particiones A/B /usr descritas anteriormente. update_engine las ejecuta y locksmithd determina cuándo se realiza 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 que sólo falta reiniciar. La estrategia de reinicio predeterminada es reboot, con un retraso de cinco minutos. Por tanto, un único VPS de producción se reiniciará según su propia programación si no se indica 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. En un clúster, REBOOT_STRATEGY=etcd-lock combinado con locksmithctl set-max 4 limita cuántos nodos pueden reiniciarse a la vez. Así, una actualización nunca deja fuera de servicio a todo el conjunto de nodos simultáneamente.

Talos Linux: sin shell, sin SSH, sin consola

Talos es la opción más limitada de las cuatro y la que define con mayor claridad su propósito. Ejecuta nodos de Kubernetes. No incluye un daemon SSH, shell ni inicio de sesión en la consola. 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 ghcr.io/siderolabs/installer:v1.10.6

Sustituya la etiqueta por la versión a la que va a actualizar. La actualización utiliza un esquema A-B que conserva el kernel y la imagen del sistema operativo anteriores. Si la nueva versión no puede arrancar, Talos revierte automáticamente sin intervención. La depuración es diferente porque no hay shell: se utilizan talosctl logs y talosctl dmesg en lugar de journalctl en el equipo.

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

Lo que realmente cede quien usa un VPS

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

Una canalización de compilación que antes no necesitaba. Añadir un paquete implica editar un Containerfile, compilar la imagen, subirla a un registro y actualizar los servidores. Esto es sencillo cuando la canalización ya existe. Configurarla desde cero requiere trabajo real cuando no existe. Además, necesita un registro al que los servidores puedan llegar, lo que implica ejecutar otro servicio o pagar otra factura.

Módulos del kernel. El kernel procede 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 externos y los paquetes DKMS (dynamic kernel module support) deben compilarse dentro de la imagen y para el kernel de esa imagen. Todo lo que necesite un módulo que la imagen base no incluya se convierte en un problema de compilación, no de instalación.

Agentes del proveedor y del fabricante. Los agentes de monitorización y copias 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 fabricantes publican un contenedor o documentan una instalación en modo de imagen. Muchos no lo hacen. Compruébelo antes de comprometerse, porque una flota que no puede monitorizar es peor que una flota que presenta desviaciones.

La propia imagen. Casi ningún panel de control de VPS muestra Fedora CoreOS, Flatcar o Talos junto a Ubuntu y Debian. Usted proporciona el disco. Esta es la siguiente sección.

Obtener uno de estos sistemas 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 requiere abrir un ticket de soporte en lugar de una reparación de cinco minutos.

Si el proveedor acepta imágenes personalizadas, cargue la imagen raw o qcow2 del fabricante y habrá terminado. De lo contrario, debe escribir el disco desde el sistema de rescate. Flatcar incluye un script autocontenido para este fin, y 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 reemplazar, porque reparticiona el dispositivo de destino durante la ejecució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 enfoque, 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 todo lo que contenía, 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 va a utilizar antes de ejecutarlo, y pruébelo en un servidor que pueda desechar. Después de reiniciar, la máquina ejecutará la imagen y desaparecerá el conjunto de paquetes que tenía.

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

Use este modelo si sus servidores son ganado. Es decir, si tiene muchas máquinas creadas a partir de una misma receta. También es adecuado para runners de CI (integración continua) que sólo existen durante una hora. Lo mismo se aplica a los nodos de k3s o Kubernetes que se reemplazan en lugar de repararse. En general, sirve cuando la respuesta a un equipo averiado ya es «elimínelo y cree otro». También resulta útil cuando debe demostrar a un auditor qué se está ejecutando en una máquina, porque la respuesta es el digest de una imagen y no una lista de paquetes.

No use este modelo si tiene un único VPS administrado manualmente con tres servicios, instala componentes cuando los necesita y no dispone de una canalización de compilación. El modo de imagen no elimina el trabajo. Traslada el trabajo del servidor al proceso de compilación y añade el coste de un registry y una canalización. Si dispone de un lugar donde realizar ese trabajo, obtiene servidores idénticos y una reversión que consiste en reiniciar. Si no dispone de él, habrá añadido componentes a un equipo que funcionaba bien y habrá complicado las tareas de las 2am.

El punto medio más sencillo sigue funcionando: una distribución normal con actualizaciones de seguridad automáticas y una reconstrucción que haya practicado realmente. Elegir esa base es una decisión independiente, explicada en cómo elegir el sistema operativo para su VPS. El modo de imagen sólo es la versión más reciente de un debate muy antiguo sobre cómo debe llegar el software a una máquina, y la historia de las distribuciones de Linux consiste en gran medida en repetir ese debate.

FAQ

¿Una distribución Linux inmutable es realmente inmutable?

No, y el nombre causa confusión. root todavía puede escribir en el disco. Lo que ocurre realmente es que /usr se monta como de sólo lectura durante la ejecución y se reemplaza por completo con la siguiente imagen, mientras que /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 del mismo modo. Ambos necesitan un archivo Ignition que contenga su clave SSH, porque no hay una solicitud de contraseña durante el primer arranque en la que pueda apoyarse. Sin acceso a la consola, no lo intente: si la máquina no vuelve a arrancar, no tendrá nada que revisar.

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

Añádalo a la imagen y vuelva a desplegarla. En bootc, es una línea RUN dnf -y install ... en el Containerfile, seguida de una recompilación, un push y después sudo bootc upgrade --apply en la máquina. En Fedora CoreOS puede añadirlo mediante capas con 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 del sistema de rescate, en un reinicio. La imagen anterior, con el kernel y el espacio de usuario juntos, sigue en el disco, por lo que sudo bootc rollback o sudo rpm-ostree rollback -r le devuelve a ella. Talos y Flatcar van más allá y revierten automáticamente cuando 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 evita una actualización defectuosa. 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 compile 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 compilación ya preparada y actualizaciones automáticas desde el principio. Elija Flatcar si quiere un host de contenedores minimalista con un esquema de actualización A/B y sin gestor de paquetes al que recurrir. Elija Talos sólo cuando la máquina sea un nodo de Kubernetes, porque no tiene shell ni ejecuta ninguna otra cosa.