Cockpit, antarmuka grafis berbasis web untuk server

 (cockpit-project.org)
6 poin oleh GN⁺ 2023-10-17 | 2 komentar | Bagikan ke WhatsApp
  • Cockpit adalah antarmuka grafis untuk mengelola server Linux dari browser, memungkinkan pemula maupun administrator profesional dengan cepat memeriksa dan mengoperasikan status tiap sistem
  • Karena menggunakan API dan perintah sistem yang sama seperti command line, alur pengelolaan tidak bentrok meski Cockpit, CLI, Ansible, dan alat manajemen server yang sudah ada digunakan bersama
  • Jaringan, firewall, storage RAID·LUKS, mesin virtual, container, log, hardware, update, performa, akun pengguna, layanan systemd, dan terminal jarak jauh dapat ditangani dalam satu layar
  • Autentikasi default mengikuti login dan hak akses pengguna biasa pada sistem, juga mendukung single-sign-on serta metode autentikasi lain, dan hanya berjalan saat diperlukan melalui systemd socket activation
  • Setelah dipasang di distribusi Linux utama, Cockpit dapat digunakan dari browser pada sistem operasi termasuk Windows, MacOS, dan Android dengan mengakses port 9090 server

Mengelola server individual dari browser

  • Cockpit adalah antarmuka grafis terpadu berbasis web yang dibuat untuk server
  • Target penggunanya luas
    • Pemula Linux, termasuk administrator Windows
    • Pengguna yang sudah terbiasa dengan Linux tetapi ingin mengelola server dengan lebih mudah secara grafis
    • Administrator profesional yang terutama memakai alat lain, tetapi ingin melihat gambaran umum tiap sistem
  • Dirancang bukan untuk menggantikan cara pengelolaan yang sudah ada, melainkan agar sistem yang sama bisa dikelola dengan berbagai cara
    • Cockpit dan utilitas command line dapat digunakan bersama
    • Ansible dan alat lain yang sudah ada juga tetap bisa dimanfaatkan
    • Menyediakan terminal bawaan yang berguna saat mengakses dari perangkat non-Linux
  • Tanpa perlu menghafal perintah Linux, pengguna dapat melihat status server di browser web dan melakukan tugas dengan mouse
    • Menjalankan container
    • Mengelola storage
    • Mengatur jaringan
    • Memeriksa log
  • Cockpit dapat dipandang seperti “antarmuka desktop” grafis untuk server individual

Autentikasi, integrasi, dan cara ekstensi

  • Cockpit menggunakan API yang sudah ada di sistem, dan tidak membuat subsistem baru atau menambahkan lapisan alat miliknya sendiri
  • Secara default, Cockpit menggunakan login dan hak akses pengguna biasa pada sistem
  • Saat tidak digunakan, Cockpit tidak terus berjalan di background, melainkan dijalankan saat diperlukan melalui systemd socket activation
  • Tugas yang dapat dilakukan di setiap host Cockpit antara lain
    • Memeriksa dan mengubah pengaturan jaringan
    • Mengatur firewall
    • Mengelola storage, termasuk partisi RAID dan LUKS
    • Membuat dan mengelola mesin virtual
    • Mengunduh dan menjalankan container
    • Menelusuri dan mencari log sistem
    • Memeriksa hardware sistem
    • Upgrade software
    • Memeriksa performa
    • Mengelola akun pengguna
    • Memeriksa dan berinteraksi dengan layanan berbasis systemd
    • Menggunakan terminal server jarak jauh dari browser web lokal
    • Beralih antar beberapa server Cockpit
    • Memperluas fitur dengan memasang aplikasi dan add-on
    • Menulis modul kustom
  • Juga dapat dimanfaatkan untuk troubleshooting
    • Mendiagnosis masalah jaringan
    • Menemukan dan menangani mesin virtual yang bermasalah
    • Memeriksa log SELinux dan memperbaiki pelanggaran umum dengan sekali klik
    • Melihat metrik detail yang mengaitkan beban CPU, penggunaan memori, aktivitas jaringan, dan performa storage dengan journal sistem
  • Mendukung aplikasi opsional dan pihak ketiga
  • Desainnya diuji dan disesuaikan melalui studi kegunaan, dan setiap perubahan kode melewati pengujian yang harus lulus sebelum digabungkan
  • Dapat digunakan secara gratis dan tersedia di bawah GNU LGPL

Instalasi dan akses

  • Dapat dipasang di distribusi utama, dan setelah berjalan dapat diakses dari browser web utama di sistem operasi apa pun
  • Cockpit memiliki siklus rilis berbasis waktu, dengan versi baru dirilis setiap 2 minggu

Bacaan terkait

2 komentar

 
GN⁺ 2023-10-17
Opini Hacker News

  • Mencela antarmuka manajemen grafis dan hanya menyukai command line itu mirip sikap hanya melihat pohon, bukan hutannya
    Mengoperasikan server dengan klik memang bukan cara yang baik, tetapi jujur saja, ssh juga sama saja sebagai cara operasi
    Kondisi server produksi sebenarnya harus bisa direproduksi sejak awal, dan setelah instalasi OS, penambahan software, serta penerapan konfigurasi, sebaiknya tidak disentuh lagi
    Baik lewat ssh maupun Cockpit, kalau masuk langsung, kemungkinan merusak sesuatu cukup besar
    Satu-satunya saat perlu masuk langsung ke server adalah ketika melakukan pekerjaan eksploratif, dan pada saat itu keunggulan GUI vs command line tidak begitu jelas
    GUI punya discoverability dan visibilitas yang baik, sehingga membantu pada tahap eksperimen untuk mencari cara melakukan konfigurasi

    • Pernyataan seperti “operasi dengan klik bukan cara mengelola server” dan “kondisi server harus bisa direproduksi sejak awal” sering dipakai seolah-olah itu kebenaran yang terlalu jelas, padahal dalam praktiknya perlu kompromi rekayasa
      Perlu dijelaskan mengapa kondisi server harus bisa direproduksi sejak awal, apa arti “sejak awal”, dan mengapa operasi dengan klik tidak boleh
      Sulit juga mengatakan bahwa kondisi server sepenuhnya tertangkap hanya oleh instalasi OS, penambahan software, dan penerapan konfigurasi
      Level patch software, data aplikasi, dan data pengguna juga termasuk dalam kondisi server
      Kondisi server produksi dapat direproduksi secara tepat dengan memulihkannya dari backup, dan backup/restore juga cocok dengan operasi berbasis klik serta bisa lebih cepat dan lebih andal daripada instal ulang OS dan skrip konfigurasi
      Jika server menyimpan data non-volatil, setelah menerapkan server baru pun tetap diperlukan sistem backup untuk memulihkan data pengguna
    • Premis ini mengasumsikan lingkungan yang memperlakukan server bukan sebagai hewan peliharaan, melainkan seperti ternak
      Tidak semua orang menjalankan platform web berskala besar di atas platform orkestrasi
      Namun, meskipun server diperlakukan seperti hewan peliharaan, cara pemulihan atau pembangunan ulang tetap harus diketahui; kalau tidak, berarti tidak ada strategi disaster recovery yang layak
    • Untuk “mereproduksi kondisi server produksi sejak awal”, saya penasaran alat apa yang dibayangkan
      Di homelab saya memakai Ansible untuk konfigurasi Raspberry Pi, dan bagian instalasi OS tampaknya memungkinkan karena caranya menyalin image ke media boot secara bit-per-bit lalu melakukan beberapa konfigurasi pilihan
    • Dengan standar itu, rasanya berarti hanya memakai NixOS saja
    • Keduanya bagus karena alasan yang berbeda
      Saya lebih suka bekerja di terminal, tetapi menurut saya GUI lebih baik untuk visualisasi, dan itu bahkan bukan hal yang perlu diperdebatkan

  • Hal keren dari proyek ini adalah karena memakai aktivasi soket systemd, tidak diperlukan proses server yang terus berjalan
    Saat Cockpit tidak dipakai, tidak ada pemborosan resource, dan mengakses halaman pada dasarnya sama seperti menjalankan tool command line lalu menutupnya
    Desainnya benar-benar indah

    • Agar adil, sejak inetd di BSD4.3 pada 1986 sudah ada pendekatan serupa
      Detail implementasinya berbeda, tetapi ide besarnya sama; dulu sempat populer, lalu tren itu lewat tanpa alasan khusus
      Proses server yang baik seharusnya idle saat tidak ada pekerjaan dan penggunaan memori nyatanya sangat kecil sehingga mudah di-swap out
      Jika server tertentu memang memakai banyak memori karena sifat fungsinya, Anda juga tidak ingin startup on-demand menimbulkan tekanan memori sesekali
      Namun ini membantu performa boot, karena lebih mudah menghindari masalah boot awal yang tersendat karena menunggu service mulai
    • Saat mencari soal ini, sepertinya SSHD sejak Ubuntu 22.10 juga memakai aktivasi soket systemd
      Proses sshd tidak dimulai sampai ada seseorang yang tersambung lewat SSH
      https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-ac...
    • Saya jadi merasa harus belajar systemd lebih banyak
      Semakin dilihat, semakin banyak fitur keren dan berguna yang muncul
    • Cockpit sekitar 99% bisa dibilang “tidak berbeda dari melakukannya lewat command line”, dan cukup hebat karena menyediakan GUI terminal JavaScript kecil, user dan password native, riwayat monitoring ringan, sampai fitur penjelajahan konfigurasi yang biasanya menuntut kita mengingat perintah systemd yang rumit
      Bagus untuk dipasang di Raspberry Pi kecil-kecil
      Sangat berguna saat tidak sedang di depan terminal untuk meninjau status sekilas, atau ketika hanya ada browser web, kita bisa lewat web server tersambung SSH secara praktis seperti native dan menjalankan curl ...etc... di prompt perintah sungguhan
    • Meski begitu, sepertinya proses server yang menyediakan aset HTML/JS statis untuk webapp Cockpit tetap berjalan, bukan?
      Saya penasaran apakah maksudnya aktivasi soket systemd hanya dipakai ketika klien web pengguna akhir mengirim request REST/GQL seperti mengambil log

  • Ada nilai dalam “porcelain”
    Saya pernah melihat startup yang tutup karena, meski sudah punya backend siap pakai, tidak mampu mendorong pengembangan produk sampai ke UI/UX
    Di satu perusahaan, saya menunjukkan bahwa backend berupa orkestrator container yang sepenuhnya custom bisa diganti dengan AWS Lambda dan ECS dalam satu akhir pekan, tetapi UI/UX dan alat workflow akan memakan waktu jauh lebih lama
    Namun mereka tetap membuang uang dan waktu untuk membuat “cluster baru berbasis Raft”
    Di tengah itu saya mendapat tugas “menambahkan batch processing”, dan karena kami sudah memakai Go, saya memasang Nomad secara internal lalu lanjut
    Saya lebih suka bekerja di tim yang merilis fitur, bukan sekadar teknologi demi teknologi
    https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...

  • Semua tool di bidang ini seharusnya punya banner raksasa bertuliskan “ruang disk habis”
    Bahkan bagi orang yang men-debug server, ini kadang secara mengejutkan bukan pengetahuan umum

    • Entah kenapa, saya juga melihat hal yang sama

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

    • Jika proyeknya makin matang dan makin banyak orang mengetahuinya, tren seperti itu sampai batas tertentu bisa diperkirakan

  • Sepertinya saya tidak akan memakai ini
    Itu berarti satu port terbuka lagi, satu attack surface lagi untuk bot yang tanpa henti memindai kerentanan, dan satu layanan lagi yang harus terus dijaga tetap mutakhir
    Namun sepertinya ini bisa membantu membuat server Linux lebih mudah diakses
    Terutama berguna bagi orang yang pindah dari shared hosting berbasis PHP ke VPS penuh, tetapi tidak punya banyak pengetahuan server dan menginginkan sesuatu seperti cPanel atau DirectAdmin

    • Port tidak harus selalu dibuka; bisa pakai VPN atau tunnel SSH sebagai gantinya
      Saya tidak begitu tahu perbedaan keduanya

  • Saya benar-benar RHCE, dan thread ini terasa sangat dibuat-buat positifnya, sampai-sampai seperti click farm dari pihak Red Hat
    Cockpit lumayan, tetapi pada dasarnya lebih mirip Windows Server Manager versi Red Hat, dan kemungkinan besar dipengaruhi langsung oleh Server Manager
    Selama bertahun-tahun, laju pengembangan dan perbaikannya juga terasa menyakitkan karena sangat lambat
    Orang yang terbiasa dengan sesi SSH tidak akan memakai Cockpit, kecuali mungkin saat membuat VM baru, dan membandingkannya dengan Proxmox itu tidak masuk akal
    Fungsionalitas UI-nya bahkan tidak sampai seperempat Proxmox, fitur manajemen VM-nya juga baru masuk relatif belakangan, dan karena latensi serta keterbatasan lewat browser, Virtual Machine Manager masih lebih baik
    Ada banyak hal yang tidak bisa dilakukan dengan Cockpit, dan banyak juga yang tetap tidak akan bisa dilakukan ke depannya
    Ini lebih terasa seperti alat untuk orang yang ingin mengeklik, tidak bisa memakai loop Bash for/while, tidak memahami chaining pipe, dan membenci vim
    Dengan kata lain, ini webmin untuk Red Hat; memang agak keren, tetapi sudah terlalu tua, pengembangannya lambat, terlalu dibesar-besarkan, dan saya belum pernah memakainya selain untuk hal-hal yang diperlukan dalam ujian sertifikasi

    • Ini mirip mengatakan, “Filter Instagram dibuat untuk orang yang tidak tahu cara menangani layer Photoshop, tidak memahami komposisi warna dasar, dan hanya ingin swipe”
      Jadi ya, itu memang benar juga
    • Ada pedoman HN yang meminta agar sindiran seperti “astroturfing, akun promosi, mobilisasi massa, agen asing” tidak diposting karena menurunkan kualitas diskusi dan umumnya sering salah
      Jika khawatir ada penyalahgunaan, pedomannya mengatakan bisa mengirim email ke hn@ycombinator.com dan mereka akan melihat datanya
      https://news.ycombinator.com/newsguidelines.html
    • Apakah kita harus selalu siap menyediakan emulator terminal yang bisa SSH? Saya tidak melihat apa salahnya membuat tugas sederhana menjadi sederhana
      Saat keluarga bepergian, saya menjalankan beberapa kamera Raspberry Pi dengan modul kamera yang lebih baik untuk melihat hewan peliharaan
      Stream kamera RTSP dijalankan sebagai unit systemd di masing-masing perangkat, dan health check untuk memastikan apakah paket sedang di-stream juga dibuat sebagai unit systemd lain
      Setiap kamera mendapat IP privat di jaringan ZeroTier yang saya kelola
      Cockpit hanya dijalankan saat diperlukan, jadi tidak ada alasan untuk tidak memasangnya sebagai alat administrasi
      Kadang salah satu kamera mulai hanya mengirim frame kosong, dan saat sedang liburan, menanganinya lewat antarmuka web Cockpit di ponsel jauh lebih baik daripada mencari keyboard, masuk lewat SSH, lalu me-restart unit stream
      Saya juga bisa membuat health check yang mendeteksi frame kosong, tetapi untuk masalah yang hanya terjadi beberapa kali setahun, jauh lebih mudah me-restart dari Cockpit daripada menulis itu
    • Cockpit sangat berguna untuk mengelola libvirt + KVM dari jarak jauh tanpa harus menggali XML yang dokumentasinya buruk
      Bisa diakses dari platform apa pun, termasuk iPad, dan hampir tidak perlu konfigurasi selain memasang paket serta menambahkan sertifikat
      Saya memakai Cockpit alih-alih Proxmox di server Debian yang menjalankan VM, karena jauh lebih tidak invasif dan mesin-mesin itu juga mengerjakan hal lain seperti container Docker
      Saya memakainya untuk tujuan ini sejak sekitar 2019
      Layar statistiknya juga berguna, tetapi saya mungkin tidak akan memasangnya hanya untuk itu
      Hampir tidak ada opsi lain yang terpelihara baik yang memungkinkan membuat VM libvirt dari browser web pada satu mesin tanpa mengambil alih seluruh sistem
    • Saya melihatnya sebagai webmin yang setengah matang
      Ini hanya bisa dipakai dengan NetworkManager, padahal begitu konfigurasi jaringan untuk VM sedikit saja lebih kompleks, biasanya NetworkManager harus dimatikan, sehingga Cockpit praktis tidak bisa dipakai
      Untuk orang yang ingin mengelola VM lewat GUI, virt-manager jauh lebih kuat
      [1] https://virt-manager.org/

  • Kualitasnya cuma “biasa saja”
    Untuk sebagian kecil penggunaan yang sangat terbatas mungkin bisa dipakai, tetapi kalau menjalankan homeserver, saya akan menghindarinya
    Plugin antarmuka file server Cockpit sudah usang dan tidak bagus
    Saya tidak begitu tahu ini sebenarnya dipakai untuk apa; monitoring sederhana mungkin bisa, tetapi sebagai alat administrasi kurang bagus

    • Tepat sekali
      Saya tidak mengerti kenapa Red Hat mendorong proyek ini, dan kegunaan praktisnya tidak banyak
      Menampilkan daftar layanan systemd tidak lebih membantu daripada melihat semuanya lewat output command line

  • Saat meng-host NAS sendiri, menurut saya Cockpit jauh lebih baik daripada OMV

    • Ini bergantung pada penggunaan dan beberapa kondisi, dan saya memakai keduanya dengan puas di dua NAS yang berbeda
      OMV punya plugin Docker dengan dukungan Compose, jadi tidak perlu GUI Docker terpisah seperti Portainer, dan berbagi SMB dari klien Windows entah kenapa lebih stabil
      GUI dan pendekatannya ramah pemula sehingga mudah dibagikan dengan pengguna lain, dan juga punya fitur bawaan seperti fail2ban dan WireGuard
      Cockpit adalah warga kelas satu di distro EL/Fedora, mendukung Podman tetapi bukan Docker, dan juga tidak ada dukungan Compose/Quadlet
      Ada fitur kuat seperti manajemen VM dan terminal, tetapi ada bug terkait Samba
    • Saya penasaran kenapa begitu
      Saat ini saya memakai OMV untuk berbagi file di jaringan lokal dan menjalankan beberapa container Docker
      Berjalan dengan baik, tetapi 90% fiturnya tidak saya pakai
    • Saya penasaran bagaimana dengan Proxmox

  • Bagi yang penasaran, menurut https://github.com/cockpit-project/cockpit, Cockpit ditulis dalam beberapa bahasa, dengan C sebagai yang terbanyak, diikuti JavaScript dan Python
    src/cockpit tampaknya mungkin merupakan logika backend utama dan ditulis dalam Python

    • Sebagai pengembang Cockpit, web server-nya ditulis dalam C, dan bridge lama adalah “API” tempat JavaScript berkomunikasi dengan API sistem seperti systemd, podman, dbus melalui web server
      Bridge baru ditulis dengan Python, dan pada waktunya kami juga ingin menulis ulang web server dengan cara yang lebih modern
    • Saya penasaran seberapa besar orang peduli pada stack teknologi apa yang dipakai saat membuat produk yang akan berjalan di server
      Hal-hal seperti dependensi apa yang ada, apakah perlu memperhatikan pustaka logging atau kerentanan Curl, juga penting
      Menarik juga melihat apakah produk ditulis dengan satu stack yang jelas atau campuran beberapa teknologi