Ferramentas para gerenciar vários servidores Linux

O que está a construir

Não é uma ferramenta, mas uma pequena stack, escolhida com base no número real de servidores que tem. Esse número é o único dado relevante, e é precisamente o que todos os guias de “ferramentas de gestão de servidores Linux” ignoram. O erro clássico é adotar uma solução para 200 servidores quando se tem 4 VPS e passar um mês a alimentar a ferramenta em vez de gerir os servidores. O segundo erro clássico é continuar a aceder manualmente por SSH a cada servidor quando se tem 18 servidores, aplicando “a mesma” alteração de 18 formas ligeiramente diferentes.

Por isso, este guia está organizado por dimensão da frota: 2 a 5 servidores, 5 a 20 e mais de 20, além da camada transversal aplicável a qualquer dimensão e que ninguém documenta: um inventário, boas práticas para chaves, um único ponto de entrada e backups que tenha efetivamente restaurado. Para cada ferramenta, encontra três informações: o que substitui, quanto tempo demora a configurar, em minutos, e o único problema que costuma causar dificuldades reais. Administro um host de VPS há 15 anos; a lista abaixo é composta pelo que funciona durante uma interrupção às 2 da manhã, não pelo que fica bem numa demonstração.

Pré-requisitos e limitações importantes

É necessário que o acesso SSH baseado em chaves já funcione em todos os servidores. Se ainda introduz palavras-passe, resolva isso primeiro. Demora dez minutos e tudo o que se segue pressupõe o uso de chaves. Também precisa de um utilizador sudo que não seja root e de servidores com software atual. Os comandos deste tutorial pressupõem Ubuntu 24.04, mas nada é específico do Ubuntu, exceto apt.

Antes das ferramentas, há dois avisos importantes. Primeiro, a proliferação de ferramentas é um problema de gestão por si só. Cada agente instalado é mais um daemon para atualizar em todos os servidores. Por isso, o critério para adicionar um agente deve ser: "isto substitui trabalho manual que fiz esta semana", e não: "isto parece útil". Segundo, todo o software apresentado é gratuito, mas o custo real está no tempo de configuração. Por isso, cada ferramenta inclui uma estimativa em minutos. Quando a estimativa indicar uma tarde, acredite nela.

2 a 5 servidores: ~/.ssh/config é a ferramenta mais subestimada que já tem

O que substitui: o ficheiro de texto com endereços IP, a arqueologia do histórico da shell (ssh 203.0 e depois Ctrl-R, com esperança) e escrever -p 2222 -i ~/.ssh/other_key para sempre. Custo de configuração: 15 minutos, uma vez. O problema: sockets de multiplexagem obsoletos, abordados abaixo.

Neste tamanho, não precisa de software; precisa de configurar o cliente que já tem para fazer exatamente o que pretende. ~/.ssh/config transforma cada servidor num nome de uma palavra e codifica o encaminhamento para nunca mais ter de pensar nele:

Host *
    ServerAliveInterval 30
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h-%p
    ControlPersist 10m

Host bastion
    HostName 10.0.0.10
    User matt

Host web1
    HostName 10.8.0.11
    User matt
    ProxyJump bastion

Host db1
    HostName 10.8.0.12
    User matt
    Port 2222
    ProxyJump bastion

Três definições fazem todo o trabalho. ProxyJump encaminha as ligações através de um bastion num único salto, por isso ssh db1 a partir de um café cria um túnel transparente através de bastion, sem encaminhamento de agentes, sem invocações de ProxyCommand, e os servidores privados nem precisam de portas SSH públicas (há mais informação sobre isto na secção transversal). ControlMaster auto com ControlPersist multiplexa as ligações através de uma única sessão TCP, por isso a segunda e todas as ssh, scp ou rsync seguintes para o mesmo host ligam-se instantaneamente em vez de renegociarem a ligação. A diferença torna-se significativa quando o Ansible entra em cena. Como scp, rsync e o Ansible leem todos este mesmo ficheiro, todos os nomes definidos aqui funcionam em todo o lado.

O problema é que a ligação principal pode continuar ativa depois de deixar de ser útil, e os dois modos de falha são diferentes. Quando o servidor reinicia ou a ligação Wi-Fi cai, o processo principal fica com uma sessão TCP interrompida que ainda não detetou o problema. O ssh web1 seguinte fica pendurado silenciosamente num socket que não conduz a lado nenhum. Separadamente, o sshd limita a 10 o número de sessões por ligação (MaxSessions em sshd_config), por isso a décima primeira sessão multiplexada para um host apresenta:

mux_client_request_session: session request failed: Session open refused by peer

Ambos os problemas têm a mesma correção: ssh -O exit web1 termina a ligação principal, e a ligação seguinte inicia uma nova. Também pode ver ocasionalmente ControlSocket /home/matt/.ssh/cm-matt@10.8.0.11-22 already exists, disabling multiplexing. É inofensivo: duas sessões iniciaram-se em simultâneo, e a ligação continua a funcionar, apenas sem multiplexagem.

Há dois complementos úteis neste tamanho. O tmux em cada servidor substitui nohup, evita perder trabalho quando a ligação Wi-Fi cai e elimina o problema de não poder fechar o portátil enquanto uma migração está em execução. Custo de configuração: sudo apt install -y tmux, dois minutos, mais a memória muscular de tmux new -s work e tmux attach -t work. O problema é o aninhamento: um tmux dentro de outro tmux captura a tecla de prefixo. Por isso, execute-o no servidor ou no portátil, não em ambos. Se executar sessões de agentes de longa duração, isto é ainda mais importante. É o mesmo padrão de executar o Claude Code num tmux num VPS, em que a sessão tem de sobreviver à ligação SSH.

Um ficheiro de aliases partilhado substitui a repetição dos seus doze one-liners favoritos em cada máquina. Mantenha um .bash_aliases num repositório git e faça pull para cada servidor. O problema é que o ficheiro fica dessincronizado assim que o edita diretamente num servidor em vez de o editar no repositório. Essa é também a primeira indicação do motivo pelo qual existe o nível seguinte.

5 a 20 servidores: configuração como código ou o drift vence

A partir de cerca de cinco servidores, “faço isto em cada máquina” deixa de ser um método e passa a ser uma ilusão. Todas as ferramentas deste nível combatem o mesmo problema: drift.

Ansible substitui o ciclo de shell sobre os nomes dos hosts, a página wiki intitulada “configuração de um servidor novo” que está desatualizada há três passos e a incerteza de não saber se o web3 recebeu realmente a correção. Custo de configuração: 30 minutos até ao primeiro playbook funcional, sudo apt install -y ansible no seu portátil ou numa máquina de gestão (o apt fornece uma versão mais antiga do Ansible, o que é suficiente para tudo neste tutorial; o percurso com pipx fornece versões atuais), sem agentes nos servidores e com tudo a funcionar através da configuração SSH que já criou. É a maior melhoria individual desta página, e o percurso completo está no tutorial do primeiro playbook do Ansible; esta é a estrutura do inventário necessária:

[web]
web1 ansible_host=10.8.0.11
web2 ansible_host=10.8.0.12

[db]
db1 ansible_host=10.8.0.21 ansible_port=2222

[all:vars]
ansible_user=matt
ansible_ssh_common_args='-o ProxyJump=bastion'

Como o Ansible executa o binário OpenSSH, o ~/.ssh/config que escreveu na secção anterior já se aplica, e um inventário com nomes simples como web1 funcionaria sem variáveis. As variáveis acima tornam o inventário autónomo, o que é útil no dia em que o executar a partir de uma máquina que não seja o seu portátil.

Teste com ansible all -i inventory.ini -m ping; um resultado correto apresenta "ping": "pong" para cada host, a verde. A primeira falha que encontrará terá este aspeto:

web1 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: matt@10.8.0.11: Permission denied (publickey).",
    "unreachable": true
}

Isto não é um problema do Ansible; o ssh matt@10.8.0.11 simples falha da mesma forma. Corrija primeiro o SSH, sempre; o Ansible só é tão saudável quanto a camada subjacente. O único problema adicional é que o Ansible precisa de Python na sua máquina e, para quase todos os módulos, incluindo ping, também no servidor. Por isso, uma imagem realmente mínima pode responder /usr/bin/python3: not found. Execute um apt install python3 e o problema não volta a incomodá-lo; numa frota inteira de imagens básicas, o módulo raw, um dos poucos que não precisa de Python no sistema remoto, pode fazer essa instalação.

unattended-upgrades substitui-o na aplicação de patches de segurança a N servidores. O Ubuntu Server 24.04 padrão já o inclui e normalmente já o tem ativado para atualizações de segurança. Por isso, o trabalho aqui é verificar, não instalar:

cat /etc/apt/apt.conf.d/20auto-upgrades

Ambas as linhas devem terminar em "1". Algumas imagens mínimas e de cloud são fornecidas com esta funcionalidade desativada, e sudo dpkg-reconfigure -plow unattended-upgrades reescreve esse ficheiro se for o seu caso. Custo de configuração: dois minutos para verificar cada servidor ou uma tarefa do Ansible para todos. O problema é que, por predefinição, nunca reinicia o servidor. Assim, as atualizações de segurança do kernel ficam parcialmente aplicadas até o fazer. O guia dedicado do unattended-upgrades explica os reinícios automáticos, a escolha do que deve ser atualizado e a leitura dos logs.

Monitorização centralizada substitui a descoberta de um problema através de um cliente, que é o sistema de monitorização mais dispendioso alguma vez criado. Duas ferramentas, uma linha sobre quando usar cada uma: Uptime Kuma responde a “está ativo?”, com verificações HTTP, TCP e ping e alertas para qualquer destino, e demora dez minutos com Docker; Zabbix responde a “está prestes a falhar?”, acompanhando as tendências de disco, memória e CPU através de um agente em cada host, e demora realisticamente uma tarde. Comece pelo Kuma; adicione o Zabbix quando o estado “ativo, mas degradado” começar a custar-lhe dinheiro. O problema comum às duas ferramentas é a localização da monitorização, e é importante o suficiente para ser abordado na secção de erros abaixo.

Um painel web, apenas se for necessário. Webmin substitui a necessidade de saber onde o Ubuntu guarda cada configuração e é realmente útil para uma equipa com diferentes níveis de experiência ou para um servidor em que só toca duas vezes por ano; a configuração demora dez minutos. O problema é que é uma aplicação web com privilégios equivalentes aos de root, à escuta na porta 10000, e a Internet procura-a constantemente. Se o executar, associe-o a localhost ou a um endereço de VPN, nunca a 0.0.0.0 numa interface pública. E, se estiver a procurar um painel porque o SSH parece lento, releia primeiro a secção anterior; ~/.ssh/config juntamente com o Ansible é mais rápido do que qualquer painel depois de configurado.

Mais de 20 servidores: onde este guia termina honestamente

Acima de 20 servidores, já está a gerir uma frota, e a cadeia de ferramentas muda: Terraform ou OpenTofu para tornar os próprios servidores reproduzíveis; cloud-init ou imagens base para que uma máquina possa ser descartada em vez de reparada; configuração baseada em pull ou pipelines de CI que executam o seu Ansible, porque o push a partir de um portátil deixa de escalar; e uma gestão de secrets adequada. O Ansible não deixa de funcionar com 20 servidores; muitas equipas utilizam-no com centenas de nós. No entanto, as práticas que o envolvem têm de ser reforçadas, e isso exigiria um artigo diferente do que este site publica. Se já está nessa escala, a secção abaixo também se aplica a si, porque as ferramentas de gestão de frotas partem precisamente do princípio de que já tem inventário, chaves e disciplina de acesso.

A camada que ninguém documenta

Quatro práticas aplicam-se a qualquer dimensão da frota. Ignorá-las é o motivo pelo qual a quantidade de servidores parece mais pesada do que realmente é.

Um ficheiro de inventário, mesmo que seja um ficheiro de texto. Assim que tiver três servidores, registe: nome, IP, fornecedor, o que é executado nele e por que existe. Um servers.md num repositório git é suficiente; o inventário do Ansible acima é melhor porque também funciona como documentação executável. O que substitui: a pergunta das 2 da manhã: "espera, o que é 10.0.0.40?" Custo de configuração: dez minutos. O problema: só funciona se criar o servidor e adicionar a linha forem o mesmo ato, nunca dois atos separados.

Higiene das chaves: faça a rotação agora; use uma CA SSH quando começar a ser necessário. Enumere onde as suas chaves estão armazenadas (cat ~/.ssh/*.pub do seu lado, ~/.ssh/authorized_keys do lado de cada servidor), remova computadores antigos e antigos colegas e faça a rotação de tudo o que seja suficientemente antigo para já não conseguir dizer por onde passou. Uma autoridade de certificação SSH, com certificados assinados de curta duração em vez de chaves estáticas, é a solução adequada. Mas o conselho honesto é que, abaixo de dez servidores, uma gestão disciplinada de authorized_keys através do Ansible proporciona 90% do benefício com 10% da complexidade operacional.

Uma forma de entrar, não vinte. Cada porta SSH pública aumenta a superfície de ataque, multiplicada por N. O padrão que escala é: um bastion host ou, melhor ainda, uma VPN WireGuard num VPS que controla, com o SSH de todos os outros servidores associado apenas ao respetivo endereço privado. As linhas ProxyJump da configuração acima já partem deste modelo. Tudo o que tiver de permanecer público deve ter fail2ban por predefinição. Custo de configuração: uma hora, uma única vez. O problema: confirme que o acesso alternativo, através da consola do fornecedor, funciona antes de fechar a porta 22 em todo o lado, não depois.

Backups testados através de uma restauração. Um backup não testado é apenas uma hipótese. Independentemente do mecanismo utilizado, snapshots do fornecedor, restic ou rsync para um segundo servidor, a ferramenta que realmente importa é a entrada no calendário que agenda a restauração de um servidor num VPS novo e confirma que ele arranca e disponibiliza o serviço. Todas as histórias de horror sobre backups que ouvi em quinze anos de alojamento incluem a frase "tínhamos backups".

Os erros

Os modos de falha em ambientes com vários servidores não resultam de falhas das ferramentas. Resultam de hábitos. Quatro deles explicam quase todos os problemas.

Servidores snowflake. Cada máquina foi configurada manualmente, é ligeiramente diferente das outras e ninguém consegue recriá-la. Isto só fica evidente quando ocorre uma falha de disco. A solução é pouco interessante, mas eficaz: todas as alterações passam pelo Ansible ou, no mínimo, são acrescentadas à secção desse servidor no documento de inventário. Qualquer servidor que não consiga recriar a partir das notas ainda hoje é dívida técnica com uma data de vencimento que não pode escolher.

Exceções de firewall "temporárias". Usa ufw allow 5432 para resolver um problema e, 18 meses depois, o Postgres continua exposto à internet. Faça uma auditoria com sudo ufw status numbered em cada máquina ou, de uma só vez, com ansible all -i inventory.ini -a "ufw status numbered" --become. Elimine tudo para o que não consiga indicar um motivo atual. Se uma regra for realmente temporária, o ufw delete correspondente deve ser executado na mesma janela do tmux antes de a fechar.

Monitorização alojada numa máquina monitorizada. Se o Uptime Kuma for executado no servidor que monitoriza, o alerta que indica "está tudo indisponível" também fica indisponível. Terá criado uma versão menor e mais absurda de o datacenter menos eficiente do mundo. A monitorização deve ficar num domínio de falha diferente: um VPS barato noutro fornecedor é a opção clássica. No mínimo, use uma verificação externa gratuita que monitorize o monitor.

SSH root em todo o lado. Uma única chave root partilhada em toda a frota significa que um só portátil comprometido dá acesso a tudo. Além disso, não existe uma trilha de auditoria que indique quem fez cada ação. Crie utilizadores individuais, configure sudo e use PermitRootLogin no em /etc/ssh/sshd_config em cada host. Mais uma vez, isto é uma tarefa Ansible de três linhas, não uma noite inteira a escrever comandos.

Quando a frota crescer para além de algumas máquinas, o seu primeiro playbook Ansible automatiza as tarefas repetitivas.

FAQ

Qual é a melhor ferramenta gratuita para gerir vários servidores Linux?

Para 2 a 5 servidores, um ~/.ssh/config bem escrito em conjunto com tmux supera qualquer ferramenta que possa instalar. A partir de aproximadamente cinco servidores, Ansible é a resposta padrão: não requer agentes, é gratuito, funciona através do SSH que já tem e transforma a configuração dos servidores em ficheiros num repositório git. Adicione Uptime Kuma para alertas de disponibilidade; todas as ferramentas referidas neste guia são software livre.

Posso gerir vários servidores Linux sem Ansible?

Sim. Abaixo de aproximadamente cinco servidores, uma boa configuração do SSH, um ficheiro de aliases partilhado e disciplina são suficientes, e muitas pessoas trabalham assim durante anos. Acima desse número, a alternativa ao Ansible não é "nada", mas sim uma divergência de configuração não documentada: dezoito servidores, cada um configurado manualmente de forma ligeiramente diferente. Se Ansible parecer demasiado complexo, comece com um playbook que gira apenas authorized_keys e unattended-upgrades; isso, por si só, compensa a curva de aprendizagem.

Como executo o mesmo comando simultaneamente em vários servidores Linux?

ansible all -i inventory.ini -a "uptime" é a solução adequada e não requer playbooks, apenas o ficheiro de inventário. Para trabalho interativo lado a lado, tmux pode transmitir as teclas premidas para todos os painéis com setw synchronize-panes on, mas considere isto apenas uma demonstração, porque transmitir comandos interativos para servidores de produção é uma forma de transformar um erro de digitação numa indisponibilidade multiplicada pelo número de servidores.

Preciso de um painel de controlo como o Webmin para gerir servidores Linux?

Não. Tudo o que um painel faz pode ser feito de forma mais reproduzível com SSH e Ansible. O Webmin é útil quando pessoas com diferentes níveis de experiência administram os mesmos servidores ou quando acede a um servidor com pouca frequência e redescobrir os caminhos de configuração consome tempo significativo. Se executar o Webmin, trate-o como a aplicação Web com privilégios equivalentes a root que ele é: associe-o a localhost ou a um endereço de VPN, nunca a uma interface pública.

Quantos servidores Linux uma pessoa consegue gerir realisticamente?

Com administração manual, a qualidade começa a diminuir algures abaixo de dez servidores. Com configuração como código, aplicação automática de patches e monitorização centralizada, uma pessoa cuidadosa consegue gerir 20 a 50 servidores como trabalho a tempo parcial. A limitação passa a ser a frequência com que algo inesperado falha, e não a manutenção de rotina. O número relevante não é o de servidores por administrador, mas o de servidores com configurações únicas por administrador: mantenha esse número próximo de zero e o limite será elevado.