Cockpit: uma interface gráfica baseada na web para servidores
(cockpit-project.org)- Cockpit é uma interface gráfica para gerenciar servidores Linux pelo navegador, permitindo que iniciantes e administradores experientes verifiquem e operem rapidamente o estado de sistemas individuais
- Como usa as mesmas APIs e comandos do sistema que a linha de comando, usar Cockpit, CLI, Ansible e ferramentas existentes de administração de servidores em conjunto não causa conflitos no fluxo de gerenciamento
- Permite lidar, em uma única tela, com rede, firewall, armazenamento RAID·LUKS, máquinas virtuais, contêineres, logs, hardware, atualizações, desempenho, contas de usuário, serviços systemd e terminal remoto
- A autenticação padrão segue o login e as permissões de usuários comuns do sistema, também oferece suporte a single-sign-on e outros métodos de autenticação, e é executado via systemd socket activation apenas quando necessário
- Após a instalação nas principais distribuições Linux, pode ser usado acessando a porta 9090 do servidor por um navegador em sistemas operacionais incluindo Windows, MacOS e Android
Administração de servidores individuais pelo navegador
- Cockpit é uma interface gráfica integrada baseada na web criada para servidores
- O público-alvo é amplo
- Iniciantes em Linux, incluindo administradores de Windows
- Usuários familiarizados com Linux, mas que querem administrar servidores com mais facilidade por meio de uma interface gráfica
- Administradores profissionais que usam principalmente outras ferramentas, mas querem verificar a visão geral de sistemas individuais
- Foi projetado para permitir administrar o mesmo sistema de várias formas, em vez de substituir os métodos existentes
- É possível usar o Cockpit junto com utilitários de linha de comando
- Ansible e outras ferramentas existentes também podem continuar sendo usadas
- Oferece um terminal integrado útil ao acessar a partir de dispositivos que não rodam Linux
- Mesmo sem memorizar comandos Linux, é possível ver o estado do servidor pelo navegador e executar tarefas com o mouse
- Iniciar contêineres
- Gerenciar armazenamento
- Configurar rede
- Verificar logs
- O Cockpit pode ser visto como uma “interface de desktop” gráfica para servidores individuais
Autenticação, integração e extensibilidade
- O Cockpit usa APIs já existentes no sistema e não cria novos subsistemas nem adiciona uma camada própria de ferramentas
- Por padrão, usa o login e as permissões de usuários comuns do sistema
- Logins em toda a rede são suportados por single-sign-on e outras técnicas de autenticação
- Quando não está em uso, não fica em execução contínua em segundo plano; é iniciado quando necessário por systemd socket activation
- As tarefas que podem ser realizadas em cada host Cockpit incluem:
- Verificar e alterar configurações de rede
- Configurar firewall
- Gerenciar armazenamento, incluindo partições RAID e LUKS
- Criar e gerenciar máquinas virtuais
- Baixar e executar contêineres
- Explorar e pesquisar logs do sistema
- Verificar o hardware do sistema
- Atualizar software
- Verificar desempenho
- Gerenciar contas de usuário
- Verificar e interagir com serviços baseados em systemd
- Usar o terminal de um servidor remoto em um navegador web local
- Alternar entre vários servidores Cockpit
- Expandir funcionalidades instalando aplicativos e add-ons
- Criar módulos personalizados
- Também pode ser usado para solução de problemas
- Diagnosticar problemas de rede
- Encontrar e responder a máquinas virtuais com mau funcionamento
- Verificar logs do SELinux e corrigir violações comuns com um clique
- Ver métricas detalhadas que correlacionam carga de CPU, uso de memória, atividade de rede e desempenho de armazenamento com o journal do sistema
- Oferece suporte a aplicações opcionais e de terceiros
- O design é testado e ajustado por meio de estudos de usabilidade, e toda alteração de código passa por testes obrigatórios antes da mesclagem
- Pode ser usado gratuitamente e é disponibilizado sob a GNU LGPL
Instalação e acesso
- Pode ser instalado nas principais distribuições e, após a execução, acessado pelos principais navegadores web em qualquer sistema operacional
- Incluindo Windows, MacOS e Android
- Após a instalação e ativação, acesse a porta 9090 do servidor
- Em um navegador na mesma máquina, é possível acessar
https://localhost:9090/
- O Cockpit tem um ciclo de lançamentos baseado em tempo, com novas versões lançadas a cada 2 semanas
2 comentários
Cockpit - interface web integrada para gerenciamento de servidores Linux
Opiniões no Hacker News
Criticar interfaces gráficas de administração e preferir apenas a linha de comando é uma atitude próxima de não enxergar a floresta por causa das árvores
Operar servidores por cliques não é uma boa abordagem, mas, para ser sincero,
sshé a mesma coisa como forma de operaçãoO estado de um servidor real em produção deveria ser reproduzível desde o início, e o certo é instalar o OS, adicionar software, aplicar configurações e depois não mexer
Seja com
sshou com Cockpit, ao entrar diretamente há uma grande chance de quebrar alguma coisaSó deveria ser necessário entrar diretamente no servidor ao fazer tarefas exploratórias, e nesse caso a superioridade entre GUI e linha de comando não é tão clara
A GUI tem boa descobribilidade e visibilidade, então ajuda na fase experimental de descobrir como configurar algo
É preciso explicar por que o estado do servidor deve ser reproduzível desde o início, o que é “desde o início” e por que operação por cliques não serve
Também é difícil dizer que o estado de um servidor seja capturado completamente só com instalação do OS, adição de software e aplicação de configurações
O nível de patches de software, os dados da aplicação e os dados dos usuários também fazem parte do estado do servidor
O estado de um servidor em produção pode ser reproduzido com precisão ao restaurar de um backup, e backup/restauração também combina bem com operação por cliques, podendo ser mais rápido e confiável do que reinstalar o OS e rodar scripts de configuração
Se for um servidor que armazena dados não voláteis, de qualquer forma será necessário um sistema de backup para restaurar os dados dos usuários depois de provisionar um novo servidor
Nem todo mundo opera grandes plataformas web sobre uma plataforma de orquestração
Ainda assim, mesmo com servidores no estilo pet, é preciso saber como recuperar ou reconstruir; caso contrário, não há uma estratégia adequada de recuperação de desastres
No homelab, uso Ansible para configurar Raspberry Pi, e a parte de instalação do OS parece viável porque é feita copiando uma imagem bit a bit para a mídia de boot e aplicando algumas configurações opcionais
Prefiro trabalhar no terminal, mas acho que nem é discutível que GUI é melhor para visualização
O ponto legal deste projeto é que ele usa ativação por socket do systemd, então não precisa de um processo de servidor rodando o tempo todo
Quando você não está usando o Cockpit, não há desperdício de recursos, e acessar uma página é praticamente como executar uma ferramenta de linha de comando e depois encerrá-la
O design é realmente bonito
inetddo BSD4.3A implementação detalhada era diferente, mas a grande ideia era a mesma; já foi popular por um tempo, mas saiu de moda sem nenhum motivo especial
Um bom processo de servidor deve ficar ocioso quando nada acontece e ter uso real de memória muito pequeno, para ser fácil fazer swap out
Se um servidor específico usa muita memória por natureza, você provavelmente também não vai querer causar pressão de memória intermitente iniciando-o sob demanda
Ainda assim, isso ajuda no desempenho de boot, pois fica mais fácil evitar bloqueios esperando serviços iniciarem no boot inicial
O processo
sshdnão é iniciado até alguém se conectar via SSHhttps://discourse.ubuntu.com/t/sshd-now-uses-socket-based-ac...
Quanto mais olho, mais aparecem recursos legais e úteis
É bom deixá-lo instalado em pequenos Raspberry Pis
É muito útil para dar uma olhada no estado quando você não está diante do terminal ou, numa situação em que só há um navegador web, para se conectar via SSH de forma praticamente nativa através do servidor web e executar
curl ...etc...no prompt de comando realFico curioso se a ativação por socket do systemd significa que ela é usada apenas quando o cliente web do usuário final envia requisições REST/GQL, como consulta de logs
Há valor em “porcelain”
Já vi startups fecharem porque, mesmo tendo um backend pronto, não conseguiram levar o desenvolvimento do produto até UI/UX
Em uma empresa, mostrei que o backend, feito como um orquestrador de contêineres totalmente customizado, poderia ser substituído por AWS Lambda e ECS em um fim de semana, mas UI/UX e ferramentas de workflow levariam muito mais tempo
Mesmo assim, continuaram desperdiçando dinheiro e tempo criando um “novo cluster baseado em Raft”
No meio disso, recebi a tarefa de “adicionar processamento em lote” e, como já usávamos Go, integrei o Nomad internamente e segui em frente
É bom trabalhar em uma equipe que lança funcionalidades, não apenas tecnologia pela tecnologia
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
Todas as ferramentas dessa área deveriam ter um banner gigante dizendo “pouco espaço em disco”
Surpreendentemente, isso também não é senso comum entre pessoas que depuram servidores
Em 2022, 81 comentários: https://news.ycombinator.com/item?id=31439811
Em 2021, 128 comentários: https://news.ycombinator.com/item?id=26197510
Em 2018, 149 comentários: https://news.ycombinator.com/item?id=16445612
Acho que eu não usaria isso
É mais uma porta aberta, mais uma superfície de ataque para bots que ficam escaneando vulnerabilidades sem parar, mais um serviço que precisa ser mantido sempre atualizado
Dito isso, acho que ajuda a tornar servidores Linux mais acessíveis
Especialmente para quem está saindo de hospedagem compartilhada baseada em PHP para um VPS completo, mas não tem muito conhecimento de servidores e quer algo como cPanel ou DirectAdmin
Não sei muito bem qual é a diferença entre os dois
Sou RHCE de verdade, e esta thread tem um clima positivo tão artificial que até parece uma click farm ligada à Red Hat
Cockpit é ok, mas na prática é mais ou menos a versão Red Hat do Windows Server Manager, e provavelmente foi diretamente influenciado pelo Server Manager
Ao longo dos anos, o ritmo de desenvolvimento e melhoria também foi dolorosamente lento
Quem está acostumado a sessões SSH não usa Cockpit, exceto talvez ao criar uma VM nova, e compará-lo com Proxmox não faz sentido
Ele não tem nem um quarto dos recursos da UI do Proxmox, e os recursos de gerenciamento de VMs chegaram relativamente há pouco tempo; além disso, por causa da latência e das limitações via navegador, o Virtual Machine Manager ainda é melhor
Há muita coisa que não dá para fazer com Cockpit, e muita coisa que continuará não dando
É mais uma ferramenta para pessoas que querem clicar, não sabem usar loops
for/whileem Bash, não entendem encadeamento de pipes e odeiamvimEm outras palavras, é o webmin para Red Hat; é até meio bonito, mas ficou antigo demais, o desenvolvimento foi lento e ele foi inflado demais — eu nunca o usei fora do que era necessário para exames de certificação
Ou seja, também é verdade
Se houver preocupação com abuso, dizem para enviar e-mail para hn@ycombinator.com, que eles analisam os dados
https://news.ycombinator.com/newsguidelines.html
Uso várias câmeras Raspberry Pi com módulos de câmera melhores para ver os animais de estimação quando a família viaja
Os streams RTSP das câmeras rodam como unidades systemd em cada equipamento, e também tenho health checks em outras unidades systemd para verificar se os pacotes estão sendo transmitidos
Cada câmera recebe um IP privado na rede ZeroTier que administro
Como o Cockpit só é executado quando necessário, não vejo motivo para não deixá-lo instalado para administração
Às vezes uma câmera começa a enviar só frames vazios; quando estou de férias, é muito melhor resolver isso pela interface web do Cockpit no celular do que procurar um teclado, entrar por SSH e reiniciar a unidade do stream
Eu poderia criar um health check que detectasse frames vazios, mas, para algo que acontece poucas vezes por ano, é muito mais fácil reiniciar pelo Cockpit do que escrever isso
Ele é acessível em qualquer plataforma, inclusive iPad, e quase não exige configuração além de instalar pacotes e adicionar certificados
Uso Cockpit em vez de Proxmox em servidores Debian que rodam VMs, porque ele é muito menos invasivo e essas máquinas também fazem outras coisas, como rodar contêineres Docker
Uso para esse fim desde mais ou menos 2019
A tela de estatísticas também é útil, mas eu não instalaria só por causa dela
Existem pouquíssimas outras opções bem mantidas que permitam criar VMs libvirt em uma única máquina via navegador sem tomar conta do sistema inteiro
Ele só funciona com NetworkManager, mas, quando a configuração de rede para VMs fica minimamente complexa, normalmente é preciso desativar o NetworkManager, então o Cockpit fica praticamente inutilizável
Para quem quer gerenciar VMs por GUI, virt-manager é muito mais poderoso
[1] https://virt-manager.org/
A qualidade é “mais ou menos”
Pode servir para alguns usos muito pequenos, mas, se eu estivesse operando um servidor doméstico, evitaria
O plugin de interface de servidor de arquivos do Cockpit é antiquado e ruim
Não sei bem para que ele serviria; talvez dê para fazer um monitoramento simples, mas como ferramenta de administração é fraco
Não sei por que a Red Hat impulsiona esse projeto, e ele tem poucos usos práticos
Mostrar uma lista de serviços systemd não ajuda mais do que ver tudo pela saída da linha de comando
Ao hospedar um NAS por conta própria, acho que o Cockpit é muito melhor que o OMV
O OMV tem um plugin do Docker com suporte a Compose, então não precisa de uma GUI separada para Docker, como o Portainer, e o compartilhamento SMB em clientes Windows parece ser mais estável por algum motivo
Ele tem uma GUI e uma postura amigáveis para iniciantes, o que também facilita compartilhar com outros usuários, e inclui recursos básicos como fail2ban e WireGuard
O Cockpit é cidadão de primeira classe nas distribuições EL/Fedora, e dá suporte ao Podman, mas não ao Docker, nem a Compose/Quadlet
Tem recursos poderosos como gerenciamento de VMs e terminal, mas há bugs relacionados ao Samba
Atualmente uso o OMV para compartilhamento de arquivos na rede local e para rodar alguns contêineres Docker
Funciona bem, mas não uso 90% dos recursos
Para quem tiver curiosidade, segundo https://github.com/cockpit-project/cockpit, o Cockpit é escrito em várias linguagens, sendo C a principal, seguida por JavaScript e Python
src/cockpitprovavelmente parece ser a lógica principal de backend, e é em PythonA nova bridge foi escrita em Python e, quando chegar a hora, também queremos reescrever o servidor web de uma forma mais moderna
Também são importantes pontos como quais dependências existem e se é preciso se preocupar com vulnerabilidades em bibliotecas de logging ou no Curl
Também é interessante ver se o produto foi escrito em uma única stack clara ou se mistura várias tecnologias