Cockpit, una interfaz gráfica web para servidores

 (cockpit-project.org)
6 puntos por GN⁺ 2023-10-17 | 2 comentarios | Compartir por WhatsApp
  • Cockpit es una interfaz gráfica para administrar servidores Linux desde el navegador, que permite a principiantes y administradores expertos revisar y operar rápidamente el estado de sistemas individuales
  • Como usa las mismas API y comandos del sistema que la línea de comandos, el flujo de administración no entra en conflicto aunque se utilicen juntos Cockpit, la CLI, Ansible y herramientas existentes de gestión de servidores
  • Permite manejar desde una sola pantalla la red, el firewall, el almacenamiento RAID y LUKS, máquinas virtuales, contenedores, registros, hardware, actualizaciones, rendimiento, cuentas de usuario, servicios de systemd y terminal remota
  • La autenticación predeterminada sigue el inicio de sesión y los permisos normales del sistema, también admite single-sign-on y otros métodos de autenticación, y solo se ejecuta cuando hace falta mediante systemd socket activation
  • Se puede instalar en las principales distribuciones de Linux y usarse accediendo al puerto 9090 del servidor desde navegadores en sistemas operativos como Windows, MacOS y Android

Administración de servidores individuales desde el navegador

  • Cockpit es una interfaz gráfica web unificada creada para servidores
  • Está dirigida a una amplia variedad de usuarios
    • Principiantes en Linux, incluidos administradores de Windows
    • Usuarios familiarizados con Linux que quieren administrar servidores fácilmente con una interfaz gráfica
    • Administradores expertos que usan principalmente otras herramientas, pero quieren ver un panorama general de sistemas individuales
  • Está diseñada para permitir administrar el mismo sistema de varias maneras, en lugar de reemplazar los métodos existentes
    • Se puede usar Cockpit junto con utilidades de línea de comandos
    • También se pueden seguir usando Ansible y otras herramientas existentes
    • Ofrece una terminal integrada útil para acceder desde dispositivos que no son Linux
  • Sin necesidad de memorizar comandos de Linux, se puede ver el estado del servidor y trabajar con el mouse desde el navegador web
    • Iniciar contenedores
    • Administrar almacenamiento
    • Configurar la red
    • Revisar registros
  • Cockpit puede verse como una “interfaz de escritorio” gráfica para servidores individuales

Autenticación, integración y forma de extensión

  • Cockpit usa las API que ya existen en el sistema y no crea subsistemas nuevos ni agrega su propia capa de herramientas
  • De forma predeterminada usa el inicio de sesión y los permisos normales del sistema
  • Cuando no se usa, no permanece ejecutándose en segundo plano, sino que se inicia cuando hace falta mediante systemd socket activation
  • En cada host con Cockpit se pueden realizar las siguientes tareas
    • Revisar y cambiar la configuración de red
    • Configurar el firewall
    • Administrar almacenamiento, incluidas particiones RAID y LUKS
    • Crear y administrar máquinas virtuales
    • Descargar y ejecutar contenedores
    • Explorar y buscar registros del sistema
    • Revisar el hardware del sistema
    • Actualizar software
    • Revisar el rendimiento
    • Administrar cuentas de usuario
    • Revisar e interactuar con servicios basados en systemd
    • Usar la terminal de un servidor remoto desde el navegador web local
    • Cambiar entre varios servidores con Cockpit
    • Ampliar funciones instalando aplicaciones y complementos
    • Escribir módulos personalizados
  • También puede usarse para resolución de problemas
    • Diagnosticar problemas de red
    • Detectar y responder a máquinas virtuales con fallas
    • Revisar registros de SELinux y corregir violaciones comunes con un clic
    • Ver métricas detalladas de carga de CPU, uso de memoria, actividad de red y rendimiento de almacenamiento vinculadas al journal del sistema
  • Admite aplicaciones opcionales y de terceros
  • Su diseño se prueba y ajusta mediante estudios de usabilidad, y todos los cambios de código pasan por pruebas obligatorias antes de fusionarse
  • Se puede usar gratis y se ofrece bajo GNU LGPL

Instalación y acceso

  • Se puede instalar en las principales distribuciones y, una vez en funcionamiento, se puede acceder desde los principales navegadores web de cualquier sistema operativo
  • Cockpit tiene un ciclo de lanzamientos por tiempo, y una nueva versión sale cada 2 semanas

Lecturas relacionadas

2 comentarios

 
GN⁺ 2023-10-17
Opiniones de Hacker News

  • Despotricar contra las interfaces gráficas de administración y preferir solo la línea de comandos se acerca a una actitud de no ver el bosque por mirar los árboles
    Operar servidores a clics no es una buena forma de hacerlo, pero, siendo honestos, ssh tampoco lo es
    El estado real de un servidor en producción debería poder reproducirse desde cero, y lo correcto es instalar el OS, agregar software, aplicar la configuración y luego no tocarlo
    Ya sea con ssh o con Cockpit, si entras directamente hay muchas posibilidades de romper algo
    Solo deberías entrar directamente a un servidor cuando haces trabajo exploratorio, y en ese caso la superioridad entre GUI y línea de comandos no es tan clara
    Una GUI tiene mejor descubribilidad y visibilidad, así que ayuda en la etapa experimental de ir encontrando cómo configurar algo

    • Frases como “operar a clics no es una forma de administrar servidores” o “el estado del servidor debe poder reproducirse desde cero” se usan como si fueran verdades demasiado evidentes, pero en la práctica hacen falta compromisos de ingeniería
      Hace falta explicar por qué el estado del servidor debe poder reproducirse desde cero, qué significa “desde cero” y por qué operar a clics no sirve
      Tampoco es fácil decir que el estado del servidor queda capturado por completo solo con instalar el OS, agregar software y aplicar configuración
      El nivel de parches del software, los datos de la aplicación y los datos de usuarios también forman parte del estado del servidor
      El estado de un servidor en producción puede reproducirse con exactitud restaurando desde un backup, y el backup/restauración también encaja bien con la operación a clics; además, puede ser más rápido y confiable que reinstalar el OS y correr scripts de configuración
      Si es un servidor que guarda datos no volátiles, de todos modos se necesita un sistema de backups para restaurar los datos de usuarios después de desplegar un servidor nuevo
    • Esa premisa asume un entorno donde los servidores se tratan como ganado y no como mascotas
      No todo el mundo opera una gran plataforma web sobre una plataforma de orquestación
      Aun así, incluso con servidores estilo mascota, deberías saber cómo recuperarlos o reconstruirlos; de lo contrario, no tienes una estrategia real de recuperación ante desastres
    • Me da curiosidad qué herramientas tienen en mente para “reproducir desde cero el estado de un servidor en producción”
      En mi homelab uso Ansible para configurar Raspberry Pi, y la parte de instalación del OS parece posible porque consiste en copiar una imagen bit a bit al medio de arranque y hacer algunas configuraciones opcionales
    • Con ese criterio, parecería que solo se puede usar NixOS
    • Ambas cosas son buenas por razones distintas
      Prefiero trabajar en la terminal, pero creo que ni siquiera es discutible que una GUI es mejor para la visualización

  • Lo genial de este proyecto es que usa activación por sockets de systemd, así que no necesita un proceso de servidor ejecutándose todo el tiempo
    Cuando no usas Cockpit no hay desperdicio de recursos, y acceder a la página es prácticamente lo mismo que ejecutar una herramienta de línea de comandos y luego cerrarla
    El diseño es realmente hermoso

    • Para ser justos, desde inetd de BSD4.3, en 1986, ya existía algo parecido
      Los detalles de implementación eran distintos, pero la idea general era la misma; en su momento fue popular, pero pasó de moda sin una razón especial
      Un buen proceso de servidor debería estar inactivo cuando no pasa nada, y su uso real de memoria debería ser muy pequeño para que sea fácil sacarlo a swap
      Si un servidor específico usa mucha memoria por la naturaleza de su función, probablemente tampoco querrás provocar presión de memoria intermitente iniciándolo bajo demanda
      Eso sí, ayuda al rendimiento de arranque porque facilita evitar quedar bloqueado esperando a que arranquen servicios durante el inicio inicial
    • Buscando esto, parece que SSHD en Ubuntu 22.10 y posteriores también usa activación por sockets de systemd
      El proceso sshd no se inicia hasta que alguien se conecta por SSH
      https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-ac...
    • Me dan ganas de aprender más sobre systemd
      Cuanto más lo reviso, más funciones geniales y útiles aparecen
    • Cockpit es, en un 99%, algo cercano a “no es distinto de hacerlo por línea de comandos”, y además ofrece una pequeña GUI de terminal en JavaScript, usuarios y contraseñas nativos, historial de monitoreo ligero y funciones de exploración de configuración para no tener que recordar comandos complejos de systemd, así que es bastante bueno
      Conviene instalarlo en Raspberry Pi pequeñas
      Es muy útil para echar un vistazo al estado cuando no estás frente a la terminal, o cuando solo tienes un navegador web y puedes conectarte por SSH de forma prácticamente nativa a través del servidor web y ejecutar curl ...etc... en un prompt real de comandos
    • Aun así, me pregunto si no hay de todos modos un proceso de servidor ejecutándose para servir los assets estáticos HTML/JS de la webapp de Cockpit
      Me pregunto si la activación por sockets de systemd significa que solo se usa cuando el cliente web del usuario final envía solicitudes REST/GQL, como consultar logs

  • El “porcelain” tiene valor
    He visto startups que cerraron porque, aun teniendo backends ya hechos, no lograron llevar el desarrollo del producto hasta la UI/UX
    En una empresa, demostramos que un backend con un orquestador de contenedores totalmente custom podía reemplazarse en un fin de semana por AWS Lambda y ECS, pero la UI/UX y las herramientas de flujo de trabajo iban a tomar mucho más tiempo
    Aun así, siguieron desperdiciando dinero y tiempo en crear un “nuevo clúster basado en Raft”
    En medio de eso me asignaron la tarea de “agregar procesamiento por lotes”, y como ya usábamos Go, simplemente conectamos Nomad internamente y seguimos adelante
    Es bueno trabajar en un equipo que lanza funcionalidades, no solo en tecnología por la tecnología
    https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...

  • Todas las herramientas de este rubro deberían tener un banner gigante que diga “poco espacio en disco”
    Incluso para gente que depura servidores, sorprendentemente esto a veces no es de sentido común

    • No sé por qué, pero vi lo mismo

  • En 2022, 81 comentarios: https://news.ycombinator.com/item?id=31439811
    En 2021, 128 comentarios: https://news.ycombinator.com/item?id=26197510
    En 2018, 149 comentarios: https://news.ycombinator.com/item?id=16445612

    • Cuando un proyecto madura y más gente lo conoce, esa tendencia es hasta cierto punto previsible

  • No creo que vaya a usar esto
    Es un puerto abierto más, una superficie de ataque más para bots que escanean vulnerabilidades sin descanso, y un servicio más que hay que mantener siempre actualizado
    Aun así, creo que puede ayudar a que los servidores Linux sean más accesibles
    Es especialmente útil para quienes se pasan de hosting compartido basado en PHP a un VPS completo, pero no tienen muchos conocimientos de servidores y quieren algo como cPanel o DirectAdmin

    • No necesariamente tienes que abrir un puerto; puedes usar una VPN o un túnel SSH en su lugar
      No estoy muy seguro de cuál es la diferencia entre ambos

  • Soy RHCE de verdad, y este hilo tiene un ambiente positivo tan artificial que casi parece una granja de clics del lado de Red Hat
    Cockpit está bien, pero en la práctica se parece más a la versión de Red Hat de Windows Server Manager, y es muy posible que haya recibido influencia directa de Server Manager
    Durante años, el ritmo de desarrollo y mejora también fue dolorosamente lento
    Quien esté acostumbrado a sesiones SSH no usa Cockpit salvo quizá al crear una VM nueva, y compararlo con Proxmox no tiene sentido
    No tiene ni una cuarta parte de las funciones de la UI de Proxmox, y las funciones de administración de VM llegaron hace relativamente poco; además, por la latencia y las limitaciones de pasar por el navegador, Virtual Machine Manager sigue siendo mejor
    Hay muchas cosas que no se pueden hacer con Cockpit y muchas que tampoco se podrán hacer en el futuro
    Es más bien una herramienta para gente que quiere hacer clics, no puede usar bucles for/while en Bash, no entiende el encadenamiento de pipes y odia vim
    Es decir, es un webmin para Red Hat; aunque se ve algo elegante, ya es demasiado viejo, su desarrollo fue lento y está tan sobrevalorado que nunca lo he usado salvo para lo necesario en exámenes de certificación

    • Es parecido a decir que “los filtros de Instagram son para gente que no sabe manejar capas de Photoshop, no entiende ni la composición básica de color y solo quiere deslizar el dedo”
      O sea, también es cierto
    • Las guías de HN dicen que no se publiquen insinuaciones como “astroturfing, cuentas promocionales, movilización coordinada, agentes extranjeros”, porque degradan la calidad de la discusión y suelen ser incorrectas
      También dicen que, si te preocupa un abuso, puedes escribir a hn@ycombinator.com y ellos revisarán los datos
      https://news.ycombinator.com/newsguidelines.html
    • ¿Tengo que estar siempre preparado para tener desplegado un emulador de terminal con SSH? No veo qué tiene de malo hacer simples las tareas simples
      Cuando mi familia viaja, uso varias cámaras con Raspberry Pi equipadas con mejores módulos de cámara para ver a las mascotas
      Los streams de cámara RTSP se ejecutan como unidades systemd en cada equipo, y también tengo health checks como otras unidades systemd para verificar si se están transmitiendo paquetes
      Cada cámara recibe una IP privada dentro de la red ZeroTier que administro
      Cockpit solo se ejecuta cuando hace falta, así que no veo razón para no dejarlo instalado para administración
      A veces una cámara empieza a emitir solo frames vacíos, y durante unas vacaciones es mucho mejor resolverlo desde la interfaz web de Cockpit en el teléfono que buscar un teclado, entrar por SSH y reiniciar la unidad del stream
      Podría crear un health check que detecte frames vacíos, pero para algo que pasa solo unas pocas veces al año, es mucho más fácil reiniciarlo desde Cockpit que escribir eso
    • Cockpit es muy útil para administrar libvirt + KVM de forma remota sin tener que hurgar en XML mal documentado
      Se puede acceder desde cualquier plataforma, incluido un iPad, y casi no requiere configuración más allá de instalar paquetes y agregar certificados
      Uso Cockpit en lugar de Proxmox en servidores Debian que ejecutan VMs, porque es mucho menos invasivo y esas máquinas también hacen otras cosas, como correr contenedores Docker
      Lo uso para esto desde alrededor de 2019
      La pantalla de estadísticas también es útil, pero no lo instalaría solo por eso
      Hay muy pocas alternativas bien mantenidas que permitan crear VMs de libvirt desde un navegador web en una sola máquina sin apoderarse de todo el sistema
    • Lo veo como un webmin a medio cocer
      Solo se puede usar con NetworkManager, pero en cuanto la configuración de red para VMs se vuelve un poco compleja, normalmente hay que desactivar NetworkManager, así que Cockpit se vuelve prácticamente inutilizable
      Para quien quiera administrar VMs con una GUI, virt-manager es mucho más potente
      [1] https://virt-manager.org/

  • La calidad es “mediocre”
    Sirve para algunos casos de uso muy pequeños, pero si administrara un servidor casero lo evitaría
    El plugin de interfaz de servidor de archivos de Cockpit es viejo y malo
    No tengo muy claro para qué se usaría; tal vez permita monitoreo básico, pero como herramienta de administración no me convence

    • Exactamente
      No sé por qué Red Hat impulsa este proyecto, y tiene pocos usos prácticos
      Mostrar una lista de servicios systemd no ayuda más que ver toda la salida en la línea de comandos

  • Al hospedar un NAS por cuenta propia, me parece que Cockpit es mucho mejor que OMV

    • Depende del uso y de algunas condiciones, y uso ambos con satisfacción en dos NAS distintos
      OMV tiene un plugin de Docker con soporte para Compose, así que no hace falta una GUI de Docker aparte como Portainer, y por alguna razón los recursos compartidos SMB son más estables desde clientes Windows
      Tiene una GUI y una actitud amigables para principiantes, por lo que también es fácil compartirlo con otros usuarios, e incluye funciones básicas como fail2ban y WireGuard
      Cockpit es ciudadano de primera clase en distribuciones EL/Fedora, y soporta Podman, pero no Docker, ni tampoco Compose/Quadlet
      Tiene funciones potentes como administración de VM y terminal, pero tiene bugs relacionados con Samba
    • Me pregunto por qué será
      Actualmente uso OMV para compartir archivos en la red local y correr algunos contenedores Docker
      Funciona bien, pero no uso el 90% de sus funciones
    • Me pregunto qué tal será Proxmox

  • Para quienes tengan curiosidad, según https://github.com/cockpit-project/cockpit, Cockpit está escrito en varios lenguajes; C es el principal, seguido por JavaScript y Python
    src/cockpit parece ser probablemente la lógica principal del backend, y está en Python

    • Hablando como desarrollador de Cockpit, el servidor web está escrito en C, y el bridge anterior era una “API” con la que JavaScript se comunicaba, a través del servidor web, con APIs del sistema como systemd, podman y dbus
      El bridge nuevo está escrito en Python, y cuando llegue el momento me gustaría reescribir también el servidor web de una forma más moderna
    • Me da curiosidad cuánto le importa a la gente qué stack tecnológico se usó al crear un producto que correrá en un servidor
      También son importantes cosas como qué dependencias tiene y si hay que preocuparse por vulnerabilidades en bibliotecas de logging o en Curl
      También resulta interesante ver si el producto está escrito con un único stack claro o si mezcla varias tecnologías