Distros Linux imutáveis em servidores: custos no VPS

O que é uma distribuição Linux imutável

Uma distribuição Linux imutável fornece o sistema operativo como uma imagem única. Em vez de aplicar patches no sistema existente, substitui a imagem inteira. Não há apt upgrade reescrita de ficheiros em /usr num servidor em execução. Cria ou obtém uma imagem nova. A máquina prepara-a ao lado da imagem em execução. No reboot seguinte, troca a imagem ativa. A imagem anterior continua no disco. Para desfazer uma atualização problemática, basta fazer reboot.

O termo "imutável" é demasiado abrangente. Nada impede fisicamente que root escreva no disco. Estes sistemas montam os diretórios do sistema como apenas de leitura e atribuem a sua gestão à imagem. Os dados persistentes ficam em /var. A configuração específica da máquina fica em /etc. Tudo em /usr pertence à imagem. Por isso, dois servidores que executem a mesma tag de imagem têm ficheiros de sistema idênticos.

Os nomes da Red Hat para os dois modelos são os mais claros: modo de pacotes e modo de imagem. O modo de pacotes é um sistema em execução com um gestor de pacotes que o modifica. O modo de imagem é uma etapa de build noutro local que produz um artefacto, e um servidor cuja única função é arrancar o artefacto que lhe for indicado. Tudo o que se segue resulta desta única diferença.

Por que um sistema somente para leitura é mais importante num servidor

Um servidor que está em execução há dois anos tem um histórico que ninguém registou. Um make install feito durante uma noite com pressa. Um repositório de terceiros adicionado para instalar um pacote. Um ficheiro de configuração editado durante uma indisponibilidade e nunca reposto no sistema de gestão de configurações. Isto chama-se desvio de configuração e explica por que motivo reconstruir “o mesmo” servidor a partir das suas notas produz frequentemente uma máquina com comportamento diferente. As notas registam a intenção. O disco contém a realidade.

O modo de imagem remove o local onde o desvio se acumula. /usr é somente para leitura durante a execução, por isso uma instalação manual falha imediatamente ou fica registada como uma camada que pode listar com um comando. Assim, a diferença entre duas máquinas fica visível, em vez de exigir uma investigação arqueológica. É o mesmo problema que uma lista de verificação normal de manutenção de servidores Linux resolve com disciplina, mas tratado pelo sistema de ficheiros.

Rollback é um reboot, e esse é todo o argumento

A falha para a qual este modelo foi concebido é a que já documentamos: uma VPS que não arranca depois de uma atualização do kernel. No modo baseado em pacotes, a recuperação é feita através da consola de rescue do fornecedor. Monte o disco, entre no chroot e remova manualmente um pacote do kernel. Isto funciona porque o bootloader mantém os kernels antigos, mas apenas o kernel é versionado dessa forma. A atualização do glibc e as alterações do systemd aplicadas na mesma transação já estão instaladas, e não existe um único comando que reverta tudo em conjunto.

No modo baseado em imagens, a unidade é o sistema completo. Num host bootc:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback repõe a ordem do bootloader para a entrada de arranque anterior, que corresponde à imagem que estava a executar há uma hora, com o kernel e o espaço de utilizador em conjunto. Nada é descarregado e nada é reconstruído, porque a imagem antiga nunca saiu do disco.

O Fedora CoreOS faz o mesmo com nomes diferentes:

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

Pare o Zincati primeiro. O Zincati é o agente que mantém uma máquina Fedora CoreOS na versão mais recente. Se o deixar em execução, ele vai preparar a atualização que acabou de reverter. -r faz reboot quando o rollback estiver preparado. Para impedir que uma implementação em que confia seja recolhida pelo garbage collector:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status lista as implementações pela ordem em que o bootloader as vai apresentar, marca a que está em execução com um ponto e mostra Pinned: yes na que foi fixada.

O Talos faz isto com uma única chamada à API a partir da sua workstation:

talosctl rollback --nodes 10.20.30.40

O Flatcar mantém duas partições /usr e alterna entre elas. Cada slot tem uma prioridade e um contador de tentativas na tabela de partições. Assim, quando um slot não arranca com sucesso e esgota as tentativas, o bootloader escolhe o outro. Verifique em que slot está e se foi marcado como válido:

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

Um slot em execução e saudável apresenta uma linha que contém priority=1 tries=0 successful=1. A ausência de uma linha correspondente significa que o slot atual nunca foi confirmado. Esse é o estado em que uma máquina permanece entre uma atualização e o primeiro arranque limpo.

O que substitui «instalar um pacote»: bootc e um Containerfile

bootc é a ferramenta que generalizou este padrão. Descreve-se como uma ferramenta para atualizações transacionais e no local do sistema operativo, usando imagens de contentores OCI (open container initiative), e é um projeto CNCF Sandbox. O seu servidor passa a ser um Containerfile. Em agosto de 2026, a imagem base do Fedora é quay.io/fedora/fedora-bootc:44 e a base do CentOS Stream é 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

Construa e envie a imagem como qualquer outra:

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

Depois, no servidor:

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

bootc upgrade consulta a origem da imagem e coloca a nova imagem na fila para o próximo arranque. --check indica se há uma atualização disponível e não altera nada. --apply reinicia o sistema para usar essa imagem. bootc switch registry.example.com/edge/web:next aponta a máquina para uma imagem diferente, preservando /etc e /var. É assim que se move um servidor entre streams de imagens sem o reinstalar.

Para atualizações não interativas, ative o timer fornecido pelo projeto:

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

Essa é a resposta do modo de imagem às atualizações não interativas no Ubuntu e ao dnf-automatic no Rocky e Alma. A diferença está no que é aplicado. Um timer do modo de pacotes aplica as versões que o repositório disponibiliza nessa noite. Por isso, o conjunto resultante é ligeiramente diferente em cada máquina. Um timer do modo de imagem aplica um artefacto que já arrancou noutro local.

Desse Containerfile resultam duas regras de compilação. Os dados graváveis devem ficar em /var. Por isso, o software que exige escrever dentro do seu próprio diretório de instalação precisa de um symlink ou de uma linha BindPaths= do systemd adicionada durante a compilação. Além disso, /etc é fundido em três vias durante a atualização. Isso significa que um ficheiro que nunca alterou recebe a nova versão da imagem, enquanto um ficheiro que editou localmente é preservado.

Quando precisar de uma ferramenta num sistema em execução para uma única sessão de depuração:

sudo bootc usr-overlay
sudo dnf -y install strace

Isto adiciona uma sobreposição gravável temporária em /usr, que é descartada no próximo reboot. Serve para analisar um problema, não para o corrigir. Não pode alterar o kernel desta forma, e tudo o que instalar desaparece no reboot por definição.

Fedora CoreOS: provisionado uma vez, atualizado para sempre

O Fedora CoreOS não tem um instalador interativo. Escreva um ficheiro YAML do Butane, converta-o para JSON do Ignition e forneça-o à máquina no primeiro arranque:

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

O Ignition é executado no initramfs apenas no primeiro arranque. Esta é a principal diferença para quem vem do cloud-init. Se a configuração não incluir uma chave SSH, a máquina arranca sem qualquer forma de acesso, e a correção consiste em provisioná-la novamente desde o início. Teste a configuração numa máquina descartável antes de a aplicar a um servidor importante.

Instalação num disco a partir de um ambiente live:

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

As atualizações são automáticas por predefinição. Você controla quando ocorrem, não se ocorrem. Coloque um ficheiro TOML em /etc/zincati/config.d/55-updates-strategy.toml para selecionar a estratégia periódica:

[updates]
strategy = "periodic"

Nessa estratégia, adicione uma janela de manutenção por cada entrada da tabela de tabelas. Cada janela começa com o nome updates.periodic.window escrito entre parênteses retos duplos como cabeçalho, seguido de três chaves:

• days, uma lista de nomes de dias, como "Sat" e "Sun".
• start_time, o momento em que a janela abre, escrito como "22:30".
• length_minutes, durante quanto tempo permanece aberta, como 60.

Esses horários estão em UTC. Para interromper totalmente as atualizações, execute sudo systemctl disable --now zincati.service e aceite que, a partir desse momento, a programação das correções fica sob a sua responsabilidade.

O layering de pacotes existe como mecanismo de exceção:

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

Isto cria uma nova implantação com o pacote adicionado, e a alteração só entra em vigor depois do reboot. O custo surge mais tarde. O conjunto de pacotes adicionados é reaplicado sobre cada nova imagem base. Por isso, se um pacote desaparecer do repositório no dia de uma atualização, essa atualização falha. A documentação do próprio Fedora recomenda usar contentores para alterações substanciais e uma imagem bootc quando for realmente necessário alterar o sistema operativo.

Flatcar Container Linux: sem gestor de pacotes

O Flatcar é a continuação do CoreOS Container Linux e a opção mais restritiva entre as distribuições de uso geral. Não existe um gestor de pacotes para utilizar como alternativa. Tudo o que executa é um contentor. O aprovisionamento é feito com Ignition, tal como no Fedora CoreOS. As atualizações são feitas através das duas partições A/B /usr descritas acima, geridas por update_engine, e locksmithd determina quando ocorre o reboot.

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT significa que a slot passiva já contém a nova imagem e que falta apenas o reboot. A estratégia de reboot predefinida é reboot, com um atraso de cinco minutos. Assim, um único VPS de produção será reiniciado automaticamente no horário definido, salvo indicação em contrário. Defina uma janela em /etc/flatcar/update.conf:

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

REBOOT_STRATEGY=off deixa o reboot a seu cargo. SERVER=disabled no mesmo ficheiro interrompe completamente a verificação de atualizações. Num cluster, REBOOT_STRATEGY=etcd-lock combinado com locksmithctl set-max 4 limita o número de nós que podem fazer reboot em simultâneo. Assim, uma atualização nunca deixa todo o conjunto de nós indisponível ao mesmo tempo.

Talos Linux: sem shell, sem SSH, sem consola

Talos é o mais restrito dos quatro e o mais claro quanto à sua finalidade. Executa nós Kubernetes. Não existe daemon SSH, shell nem início de sessão na consola. Todas as operações são chamadas à API gRPC feitas com talosctl a partir da sua estação de trabalho, usando uma configuração da máquina mantida no git.

talosctl upgrade --nodes 10.20.30.40 \
  --image ghcr.io/siderolabs/installer:v1.10.6

Substitua a tag pela release para a qual está a atualizar. A atualização usa um esquema A-B que mantém o kernel e a imagem do sistema operativo anteriores. Se a nova versão não arrancar, o Talos reverte automaticamente, sem intervenção. A depuração é diferente porque não existe shell: use talosctl logs e talosctl dmesg em vez de journalctl na máquina.

Se a sua carga de trabalho não for Kubernetes, Talos não é a escolha certa. Se for, o Talos elimina uma categoria inteira de incidentes, porque não existe forma de "alguém iniciar sessão num nó e alterar alguma coisa".

O que um tenant de VPS realmente abdica

Instalações ad hoc num sistema em execução. Este é o principal ponto. sudo apt install htop às 2am, durante um incidente, não está disponível. No bootc, obtém uma sobreposição temporária que desaparece no reboot. No Fedora CoreOS, obtém uma implantação em camadas que requer um reboot. No Flatcar e no Talos, não obtém nada.

Uma pipeline de build que antes não existia. Adicionar um pacote significa editar um Containerfile, criar a imagem, enviá-la para um registry e atualizar os servidores. Isto é simples quando a pipeline já existe. Criá-la do zero dá trabalho e requer um registry que os servidores consigam alcançar, o que implica executar outro serviço ou pagar outra fatura.

Módulos do kernel. O kernel vem da imagem, por isso um módulo compilado para o kernel em execução não sobrevive à atualização seguinte. Módulos externos e pacotes DKMS (dynamic kernel module support) têm de ser incorporados na imagem, compilados para o kernel dessa imagem. Tudo o que precisar de um módulo que a imagem base não inclua passa a ser um problema de build, e não de instalação.

Agentes de fornecedores e provedores. Os agentes de monitorização e backup normalmente são distribuídos como um .deb ou .rpm, com um script de instalação que escreve em /usr e ativa uma unidade. Num sistema só de leitura, esse script falha. Alguns fornecedores publicam um contentor ou documentam uma instalação em modo de imagem. Muitos não o fazem. Verifique isto antes de se comprometer, porque uma frota que não consegue monitorizar é pior do que uma frota que fica desatualizada.

A própria imagem. Quase nenhum painel de controlo de VPS lista Fedora CoreOS, Flatcar ou Talos ao lado de Ubuntu e Debian. É você quem fornece o disco. Essa é a próxima secção.

Como instalar uma destas imagens numa VPS alugada

Confirme primeiro duas coisas com o seu fornecedor: se tem acesso à consola out-of-band, ou seja, VNC ou uma consola série, e se pode arrancar um sistema de recuperação. Sem uma consola, uma máquina que não volta a arrancar transforma-se num pedido de suporte, em vez de uma correção de cinco minutos.

Se o fornecedor aceitar imagens personalizadas, carregue a imagem raw ou qcow2 do fabricante e o processo fica concluído. Caso contrário, escreva a imagem no disco a partir do sistema de recuperação. O Flatcar fornece um script autónomo para este fim, que pode ser executado em qualquer 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

Execute-o a partir do sistema de recuperação, nunca a partir do servidor que está a substituir, porque o script reparticiona o dispositivo de destino durante a execução. O dispositivo precisa de ter pelo menos 8 GB de espaço utilizável, e o ambiente de recuperação tem de fornecer bash, bzip2 ou lbzip2, lsblk, wget, udevadm, gpg e gawk. O seu ignition.json tem de conter uma chave SSH. Caso contrário, o sistema instalado não terá forma de permitir o seu acesso.

O Fedora CoreOS segue o mesmo modelo, e o instalador é executado como um contentor:

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

Confirme o nome do dispositivo com lsblk antes de executar o comando. Escrever no dispositivo errado destrói o conteúdo existente, e não é apresentada qualquer confirmação.

O bootc oferece a opção que dispensa o modo de recuperação, porque converte um sistema Linux em execução no próprio local:

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

Leia a documentação da imagem base que está a utilizar antes de executar o comando e teste-o num servidor que possa descartar. Depois do reboot, a máquina executará a imagem, e o conjunto de pacotes existente será removido.

Quem deve usar um servidor imutável e quem não deve

Use este modelo se os seus servidores forem descartáveis. Muitas máquinas criadas a partir da mesma receita. Executores de CI (integração contínua) que existem durante uma hora. Nós de k3s ou Kubernetes que são substituídos em vez de reparados. Qualquer sistema em que a resposta para uma máquina avariada já seja "eliminá-la e criar outra". Este modelo também é útil quando precisa de provar a um auditor o que está a executar numa máquina, porque a resposta é um digest de imagem, e não uma lista de pacotes.

Não use este modelo se tiver um único VPS mantido manualmente, com três serviços, instalar software quando precisa dele e não tiver um pipeline de build. O modo de imagem não elimina trabalho. Transfere o trabalho do servidor para o build e acrescenta um registry e um pipeline ao processo. Se tiver onde executar esse trabalho, obtém servidores idênticos e um rollback que consiste num reboot. Se não tiver, acrescentou componentes a uma máquina que funcionava bem e tornou as intervenções às 2am mais difíceis.

O meio-termo menos complexo continua a funcionar: uma distribuição normal com atualizações automáticas de segurança e um rebuild que tenha praticado efetivamente. Escolher essa base é uma decisão própria, abordada em como escolher o sistema operativo para executar no seu VPS. O modo de imagem é apenas o capítulo mais recente de uma discussão muito antiga sobre como o software deve chegar a uma máquina, e a história das distribuições Linux é, em grande parte, essa discussão a repetir-se.

FAQ

Uma distribuição Linux imutável é realmente imutável?

Não, e o nome causa confusão. root ainda pode escrever no disco. O que acontece de facto é que /usr é montado como somente leitura durante a execução e substituído integralmente pela imagem seguinte, enquanto /etc e /var continuam graváveis e persistem entre atualizações. As alterações feitas em /usr são recusadas no momento ou descartadas na atualização seguinte. Na prática, isso significa que os diretórios do sistema só mudam quando a imagem muda.

Posso executar Fedora CoreOS ou Flatcar numa VPS que não os disponibiliza?

Normalmente, sim, se o provedor disponibilizar um sistema de rescue e acesso à consola. Inicie o rescue, grave a imagem de disco da distribuição no dispositivo de bloco e reinicie. O script flatcar-install do Flatcar faz isso a partir de qualquer Linux, e o Fedora CoreOS disponibiliza coreos-installer como um contentor que pode executar da mesma forma. Ambos precisam de um ficheiro Ignition que contenha a sua chave SSH, porque não existe um pedido de palavra-passe no primeiro arranque. Sem acesso à consola, não tente fazer isto: se a máquina não voltar a arrancar, não terá forma de verificar o problema.

Como instalo um pacote num servidor imutável?

Adicione-o à imagem e faça um novo deploy. No bootc, isso corresponde a uma linha RUN dnf -y install ... no Containerfile, a uma nova compilação, a um push e depois a sudo bootc upgrade --apply na máquina. No Fedora CoreOS, pode criar uma camada com sudo rpm-ostree install e reiniciar, mas o pacote será reaplicado em todas as atualizações futuras. No Flatcar e no Talos não existe um gestor de pacotes, portanto a resposta é um contentor. Para uma ferramenta de depuração temporária num host bootc, sudo bootc usr-overlay disponibiliza um /usr gravável que desaparece no reinício seguinte.

O modo de imagem corrige uma VPS que não arranca depois de uma atualização do kernel?

Transforma a recuperação de uma tarefa na consola de rescue num reinício. A imagem, o kernel e o userspace anteriores continuam no disco. Por isso, sudo bootc rollback ou sudo rpm-ostree rollback -r permite regressar a essa versão. O Talos e o Flatcar vão mais longe e fazem rollback automaticamente quando o novo slot não arranca, porque uma entrada de arranque só se torna predefinida depois de um arranque bem-sucedido. Nada disso impede uma atualização problemática. Apenas torna barato desfazê-la.

Que distribuição imutável devo escolher para um servidor?

Escolha bootc se quiser um servidor Linux de uso geral, criado como uma imagem de contentor e instalável numa máquina que já possui. Escolha Fedora CoreOS se quiser esse modelo com a compilação já preparada e atualizações automáticas desde o início. Escolha Flatcar se quiser um host de contentores minimalista, com um esquema de atualização A/B e sem gestor de pacotes disponível. Escolha Talos apenas quando a máquina for um nó Kubernetes, pois não tem shell e não executa mais nada.