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, na esperança de encontrar o comando certo) e escrever -p 2222 -i ~/.ssh/other_key repetidamente. Custo de configuração: 15 minutos, uma única vez. O problema: sockets de multiplexagem obsoletos, tratados abaixo.

Neste tamanho, não precisa de software; precisa de configurar corretamente o cliente que já tem. ~/.ssh/config transforma cada servidor num nome de uma palavra e regista 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 o trabalho. ProxyJump encaminha as ligações através de um bastion num único salto. Assim, ssh db1 a partir de um café cria um túnel de forma transparente através de bastion, sem encaminhamento do agente, sem comandos ProxyCommand e sem que os servidores privados precisem de portas SSH públicas (mais sobre isto na secção transversal). ControlMaster auto com ControlPersist multiplexa as ligações através de uma única sessão TCP. Assim, 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 ação. Além disso, como scp, rsync e o Ansible leem o 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 comportam-se de forma diferente. 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 então bloqueado 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). Assim, a décima primeira sessão multiplexada para um host apresenta:

mux_client_request_session: session request failed: Session open refused

A correção é a mesma nos dois casos: ssh -O exit web1 termina a ligação principal e a ligação seguinte inicia uma nova. Também pode ver ocasionalmente ControlSocket ~/.ssh/cm-matt@web1-22 already exists, disabling multiplexing. É inofensivo: duas sessões tentaram iniciar-se ao mesmo tempo 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 situações como "não posso fechar o portátil, está a decorrer uma migração". Custo de configuração: sudo apt install -y tmux, dois minutos, além de memorizar tmux new -s work e tmux attach -t work. O problema é o aninhamento: o tmux dentro de outro tmux captura a tecla de prefixo. Por isso, execute-o no servidor ou no portátil, não nos dois. Se executar sessões de agentes de longa duração, isto é ainda mais importante. É o mesmo padrão de executar o Claude Code no tmux num VPS, em que a sessão tem de sobreviver à ligação SSH.

Um ficheiro de aliases partilhado substitui a reintrodução dos seus doze comandos favoritos em cada máquina. Mantenha um .bash_aliases num repositório git e descarregue-o para cada servidor. O problema é que o ficheiro fica desatualizado assim que o edita diretamente num servidor, em vez de o editar no repositório. Esta é também a primeira demonstração do motivo pelo qual existe o nível seguinte.

De 5 a 20 servidores: configuração como código ou a divergência vence

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

Ansible substitui o loop de shell sobre nomes de hosts, a página wiki intitulada “configuração de um servidor novo” que está três passos desatualizada e a preocupação de não saber se o web3 recebeu realmente a correção. Custo de configuração: 30 minutos até ter um primeiro playbook funcional, sudo apt install -y ansible no seu laptop ou numa máquina de gestão (o apt fornece uma release mais antiga do Ansible, suficiente para tudo o que é apresentado aqui; o método com pipx do tutorial obtém 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. O passo a passo completo está no tutorial do primeiro playbook Ansible; esta é a estrutura do inventário que permite fazê-lo funcionar:

[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. Um inventário com nomes simples, como web1, funcionaria sem quaisquer vars. As vars acima tornam o inventário autónomo. Isto é útil quando o executar a partir de uma máquina que não é o seu laptop.

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á tem 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 fiável quanto a camada subjacente. O único detalhe adicional é que o Ansible precisa de Python nos dois lados. Por isso, uma imagem verdadeiramente mínima pode responder /usr/bin/python3: not found, uma apt install python3, e o problema deixa de voltar a incomodá-lo.

unattended-upgrades substitui-o na aplicação de patches de segurança a N servidores. O Ubuntu Server 24.04 padrão inclui-o pré-instalado e normalmente já 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 imagens cloud são fornecidas com esta funcionalidade desativada. O sudo dpkg-reconfigure -plow unattended-upgrades reescreve esse ficheiro se for esse o seu caso. Custo de configuração: dois minutos para verificar cada servidor, ou uma tarefa Ansible para todos. O detalhe importante é que, por predefinição, nunca reinicia o servidor. Assim, as atualizações de segurança do kernel ficam parcialmente aplicadas até que faça o reboot. O guia dedicado ao unattended-upgrades explica como configurar reboots automáticos, escolher o que é atualizado e consultar os logs.

Monitorização centralizada substitui a descoberta através de um cliente, que é o sistema de monitorização mais caro alguma vez criado. Há duas ferramentas, com uma linha sobre quando usar cada uma: o Uptime Kuma responde “está disponível?”, com verificações HTTP, TCP e ping e alertas para qualquer destino. A instalação em Docker demora dez minutos. O Zabbix responde “está prestes a falhar?”, acompanhando tendências de disco, memória e CPU através de um agente em cada host. Sinceramente, a configuração demora uma tarde. Comece pelo Kuma. Adicione o Zabbix quando o estado “disponível, mas degradado” começar a custar-lhe dinheiro. O ponto crítico para ambas as ferramentas é a localização. É suficientemente importante para introduzir a secção de erros abaixo.

Um painel web, apenas se for necessário. O Webmin substitui a necessidade de se lembrar de onde o Ubuntu guarda cada configuração. Para uma equipa com diferentes níveis de experiência ou para um servidor em que mexe duas vezes por ano, é realmente útil. A configuração demora dez minutos. O problema é que se trata de uma aplicação web com privilégios equivalentes aos de root, a escutar na porta 10000. A Internet procura-a constantemente. Se o utilizar, 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 com 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.