Linux imutável em servidor: vale a pena usar?

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

Uma distribuição Linux imutável fornece o sistema operativo como uma imagem única. Por isso, substitui o sistema em vez de aplicar correções diretamente no local. Não há apt upgrade reescrita de ficheiros em /usr num servidor em execução. Cria ou obtém uma nova imagem, o computador prepara-a ao lado da imagem em execução e, 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" é excessivo. Nada impede fisicamente o root de escrever no disco. Estes sistemas montam os diretórios do sistema como somente 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 o que está 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 altera. O modo de imagem é uma etapa de compilação noutro local que produz um artefacto, e um servidor cuja única função é arrancar o artefacto indicado. Tudo o que se segue resulta desta única diferença.

Por que um sistema somente de 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 criado numa noite com pressa. Um repositório de terceiros adicionado para instalar um pacote. Um ficheiro de configuração editado durante uma interrupção e nunca reposto na gestão de configuração. Isto chama-se desvio de configuração e é por isso que reconstruir "o mesmo" servidor a partir das suas notas produz tantas vezes uma máquina com comportamento diferente. As notas registam a intenção. O disco contém a realidade.

O modo de imagem elimina o local onde o desvio se acumula. /usr é somente de leitura durante a execução, pelo que uma instalação feita manualmente falha imediatamente ou fica registada como uma camada que pode listar com um único comando. Assim, a diferença entre duas máquinas fica visível em vez de exigir uma investigação histórica. É o mesmo problema que uma lista de verificação regular de manutenção de Linux resolve com disciplina, mas tratado pelo sistema de ficheiros.

Rollback é reinicialização, 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 de pacotes, a recuperação é feita a partir da consola de rescue do fornecedor. Monta o disco, faz chroot e remove 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 que chegaram na mesma transação já foram aplicadas, e não existe um único comando que as reverta em conjunto.

No modo de imagem, a unidade é o sistema inteiro. Num host bootc:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback repõe a ordem anterior do bootloader, usando a entrada de boot anterior, que corresponde à imagem executada há uma hora, com o kernel e o espaço de utilizador em conjunto. Nada é transferido e nada é reconstruído, porque a imagem antiga nunca saiu do disco. Se tiver ativado o temporizador de atualização automática descrito mais abaixo, pare-o primeiro: a documentação do bootc avisa que um agente que execute atualizações automáticas pode reverter o rollback.

O Fedora CoreOS faz o mesmo com nomes diferentes:

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

Pare primeiro o Zincati. O Zincati é o agente que mantém uma máquina Fedora CoreOS na versão mais recente. Ele não reinstala o deployment que acabou de reverter, mas continua a procurar atualizações e atualiza para qualquer versão mais recente que apareça. Por isso, execute sudo systemctl disable --now zincati.service se a máquina tiver de permanecer no estado atual até ser lançada uma correção. -r reinicializa a máquina quando o rollback estiver preparado. Para impedir que um deployment em que confia seja recolhido pelo garbage collector:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status lista os deployments pela ordem em que o bootloader os apresentará, marca o deployment em execução com um ponto e mostra Pinned: yes no deployment fixado.

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 nunca arranca com sucesso e esgota as tentativas, o bootloader escolhe o outro slot. Verifique em que slot está e se ele foi marcado como válido:

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

Um slot em execução saudável apresenta uma linha que contém tries=0 successful=1. O número da prioridade na mesma linha apenas define a ordem de preferência do bootloader, por isso pode ser 1 ou 2 numa máquina perfeitamente saudável. A ausência de uma linha correspondente significa que o slot atual nunca foi confirmado. Esse é o estado em que a máquina fica 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 imagem 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

Crie e publique 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 existe uma atualização disponível e não altera nada. --apply reinicia o sistema usando a nova 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 fluxos de imagens sem o reinstalar.

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

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

Esta é a resposta do modo de imagem para atualizações não interativas no Ubuntu e para dnf-automatic no Rocky e Alma. A diferença está no que é aplicado. Um temporizador do modo de pacotes aplica as versões existentes no repositório nessa noite, pelo que o conjunto resultante é ligeiramente diferente em cada máquina. Um temporizador do modo de imagem aplica um artefacto que já foi iniciado noutro local.

Deste Containerfile resultam duas regras de compilação. Os dados graváveis devem ficar em /var. Por isso, o software que insiste em escrever dentro do seu próprio diretório de instalação precisa de um link simbólico ou de uma linha systemd BindPaths= adicionada durante a compilação. Além disso, /etc é fundido a três vias durante a atualização. Isto 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 numa máquina 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 reinício. Serve para investigar um problema, não para o corrigir. Não pode alterar o kernel desta forma, e tudo o que instalar desaparece no reinício por definição.

Fedora CoreOS: provisionamento inicial, atualizações contínuas

O Fedora CoreOS não tem um instalador interativo. Escreva um ficheiro YAML do Butane, transponha-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 diferença que costuma surpreender 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 fazer novamente o provisionamento 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. Pode controlar quando ocorrem, mas 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 dentro de 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, a duração da janela, como 60.

Esses horários estão em UTC. Para interromper completamente as atualizações, execute sudo systemctl disable --now zincati.service e aceite que passa a ser responsável pelo calendário de aplicação de patches.

A sobreposição de pacotes existe como mecanismo de exceção:

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

Isto cria uma nova implementaçã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 sobrepostos é 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 o uso de contentores para componentes substanciais e de 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 ao qual recorrer. Tudo o que é executado é um contentor. O aprovisionamento é feito com Ignition, tal como no Fedora CoreOS. As atualizações são feitas nas duas partições A/B /usr descritas acima, através de 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 o slot passivo já contém a nova imagem e que falta apenas reiniciar. A estratégia de reboot predefinida é reboot, com um atraso de cinco minutos. Assim, uma única VPS de produção será reiniciada 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 ao seu critério. SERVER=disabled no mesmo ficheiro desativa 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 reiniciar em simultâneo. Assim, uma atualização nunca interrompe toda a frota ao mesmo tempo.

Talos Linux: sem shell, sem SSH, sem consola

Talos é a opção mais restrita das quatro e a que define com maior clareza a sua finalidade. Executa nós do Kubernetes. Não existe daemon SSH, shell de login nem login pela consola. A consola física apresenta um painel para consultar o estado da máquina, não um prompt de login. Todas as operações são chamadas à API gRPC feitas com talosctl a partir da sua workstation, utilizando uma configuração de máquina mantida no git.

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

Desde o Talos 1.14, a imagem ghcr.io/siderolabs/installer deixou de ser publicada, e as imagens do instalador passaram a vir da Image Factory. O ID longo nesse caminho é o schematic vazio para uma máquina sem personalizações. Use o schematic a partir do qual o seu nó foi instalado, para incluir as extensões de sistema, e 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 anteriores. Se a nova versão falhar ao arrancar, o Talos faz rollback automaticamente, sem intervenção. A depuração é diferente porque não existe shell de login: use talosctl logs e talosctl dmesg em vez de journalctl na máquina. Quando precisar de ferramentas no nó, talosctl debug inicia um contentor privilegiado a partir de uma imagem fornecida por si e abre o shell desse contentor. O contentor é removido quando sair.

Se a sua carga de trabalho não for Kubernetes, Talos não é a escolha correta. Se for, o Talos elimina uma categoria inteira de incidentes, porque não há como ocorrer a situação em que alguém inicia sessão num nó e altera alguma coisa.

O que um tenant de VPS realmente deixa de ter

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 implementação em camadas que requer um reboot. No Flatcar e no Talos, não obtém nada.

Um pipeline de build que antes não existia. Adicionar um pacote significa editar um Containerfile, fazer o build da imagem, enviá-la para um registry e atualizar os servidores. Isto é simples quando o pipeline já existe. Criá-lo de raiz exige trabalho e requer um registry ao qual os servidores consigam aceder, o que significa 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. Os módulos externos e os pacotes DKMS (dynamic kernel module support) têm de ser integrados na imagem, compilados para o kernel dessa imagem. Tudo o que exigir 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 providers. 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 avançar, 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 juntamente com Ubuntu e Debian. O disco fica a seu cargo. Essa é a próxima secção.

Como instalar um destes sistemas numa VPS alugada

Confirme primeiro duas condições junto do fornecedor: que tem acesso à consola out-of-band, ou seja, VNC ou uma consola série, e que 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 fornecedor, mas o carregamento, por si só, não lhe dá uma máquina na qual possa iniciar sessão. O utilizador core do Fedora CoreOS não tem palavra-passe predefinida nem chave SSH. Por isso, ainda tem de fornecer uma configuração Ignition com a sua chave ou, numa plataforma cloud compatível com Afterburn, uma chave definida através da funcionalidade SSH key do próprio fornecedor. Caso contrário, escreva o disco a partir do sistema de recuperação. O Flatcar fornece um script autónomo para este fim, que pode ser executado a partir de 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 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, não haverá forma de iniciar sessão no sistema instalado.

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 nenhuma 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 eliminar. Depois do reboot, a máquina executará a imagem, e o conjunto de pacotes existente anteriormente terá desaparecido.

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

Use isto se os seus servidores forem tratados como gado. Muitas máquinas criadas a partir da mesma receita. Agentes 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". Isto também é útil quando precisa de provar a um auditor o que está em execução numa máquina, porque a resposta é um digest de imagem e não uma lista de pacotes.

Não use isto se tiver um único VPS administrado manualmente, com três serviços, instalar coisas conforme precisa 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 os custos de um registry e de um pipeline. 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 tarefas das 2am mais difíceis.

A solução intermédia e simples continua a funcionar: uma distribuição normal com atualizações de segurança automáticas, além de um rebuild que tenha realmente praticado. Escolher essa base é uma decisão própria, abordada em escolher qual OS executar no seu VPS. O modo de imagem é apenas a versão 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 consiste em grande parte na repetição dessa discussão.

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 na prática é que /usr é montado como somente leitura durante a execução e substituído integralmente pela imagem seguinte, enquanto /etc e /var permanecem graváveis e persistem entre atualizações. As alterações feitas em /usr são recusadas no momento da escrita ou descartadas na atualização seguinte. Na prática, os diretórios do sistema só mudam quando a imagem muda.

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

Normalmente, sim, se o provedor disponibilizar um sistema de rescue e acesso à consola. Arranque 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á como a investigar.

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 recompilação, a um push e, depois, a sudo bootc upgrade --apply na máquina. No Fedora CoreOS, pode adicioná-lo 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 gestor de pacotes, por isso a resposta é um contentor. Para uma ferramenta de debugging usada uma única vez num host bootc, sudo bootc usr-overlay disponibiliza um /usr gravável que desaparece no reinício seguinte.

O image mode 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 voltar a utilizá-los. 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 com problemas. 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 que seja criado como uma imagem de contentor e possa ser instalado numa máquina que já possui. Escolha Fedora CoreOS se quiser esse modelo com a criação da imagem tratada automaticamente e atualizações automáticas desde o início. Escolha Flatcar se quiser um host de contentores mínimo, com um esquema de atualização A/B e sem gestor de pacotes que alguém possa utilizar. Escolha Talos apenas quando a máquina for um nó Kubernetes, porque não tem uma shell de login e não executa mais nada.