Cockpit, giao diện đồ họa dựa trên web cho máy chủ

 (cockpit-project.org)
6 điểm bởi GN⁺ 2023-10-17 | 2 bình luận | Chia sẻ qua WhatsApp
  • Cockpit là giao diện đồ họa để quản lý máy chủ Linux từ trình duyệt, giúp cả người mới bắt đầu lẫn quản trị viên chuyên nghiệp nhanh chóng kiểm tra trạng thái và thao tác trên từng hệ thống
  • Vì sử dụng API và lệnh hệ thống giống như dòng lệnh, nên có thể dùng Cockpit cùng với CLI, Ansible và các công cụ quản trị máy chủ hiện có mà không làm xung đột quy trình quản lý
  • Có thể xử lý mạng, tường lửa, lưu trữ RAID·LUKS, máy ảo, container, nhật ký, phần cứng, cập nhật, hiệu năng, tài khoản người dùng, dịch vụ systemd và terminal từ xa trên một màn hình
  • Xác thực mặc định tuân theo đăng nhập và quyền của người dùng thông thường trên hệ thống, đồng thời hỗ trợ single-sign-on và các phương thức xác thực khác, và chỉ chạy khi cần thông qua systemd socket activation
  • Sau khi cài trên các bản phân phối Linux phổ biến, có thể truy cập qua cổng 9090 của máy chủ từ trình duyệt trên nhiều hệ điều hành, bao gồm Windows, MacOS và Android

Quản lý từng máy chủ ngay trong trình duyệt

  • Cockpit là giao diện đồ họa tích hợp dựa trên web được tạo ra cho máy chủ
  • Đối tượng người dùng rất rộng
    • Người mới làm quen với Linux, kể cả quản trị viên Windows
    • Người đã quen với Linux nhưng muốn quản lý máy chủ dễ dàng bằng giao diện đồ họa
    • Quản trị viên chuyên nghiệp chủ yếu dùng công cụ khác nhưng vẫn muốn xem nhanh tổng quan của từng hệ thống
  • Công cụ này được thiết kế không phải để thay thế cách quản trị hiện có mà để cho phép quản lý cùng một hệ thống theo nhiều cách
    • Có thể dùng Cockpit cùng với tiện ích dòng lệnh
    • Vẫn có thể tiếp tục dùng Ansible và các công cụ hiện có khác
    • Cung cấp terminal tích hợp hữu ích khi truy cập từ thiết bị không phải Linux
  • Không cần ghi nhớ lệnh Linux, vẫn có thể xem trạng thái máy chủ và thao tác bằng chuột trong trình duyệt web
    • Khởi động container
    • Quản lý lưu trữ
    • Cấu hình mạng
    • Kiểm tra nhật ký
  • Có thể xem Cockpit như một “giao diện desktop” đồ họa cho từng máy chủ

Cách xác thực, tích hợp và mở rộng

  • Cockpit sử dụng các API đã có sẵn trong hệ thống, không tạo thêm hệ thống con mới hay một lớp công cụ riêng
  • Mặc định, nó sử dụng đăng nhập và quyền của người dùng thông thường trên hệ thống
  • Khi không sử dụng, nó không chạy nền liên tục mà được kích hoạt khi cần bằng systemd socket activation
  • Các thao tác có thể thực hiện trên mỗi máy chủ Cockpit gồm
    • Kiểm tra và thay đổi cấu hình mạng
    • Thiết lập tường lửa
    • Quản lý lưu trữ, bao gồm phân vùng RAID và LUKS
    • Tạo và quản lý máy ảo
    • Tải về và chạy container
    • Duyệt và tìm kiếm nhật ký hệ thống
    • Kiểm tra phần cứng hệ thống
    • Nâng cấp phần mềm
    • Theo dõi hiệu năng
    • Quản lý tài khoản người dùng
    • Kiểm tra và tương tác với các dịch vụ dựa trên systemd
    • Sử dụng terminal của máy chủ từ xa trong trình duyệt web cục bộ
    • Chuyển đổi giữa nhiều máy chủ Cockpit
    • Mở rộng tính năng bằng cách cài ứng dụng và addon
    • Viết mô-đun tùy chỉnh
  • Cũng có thể dùng để xử lý sự cố
    • Chẩn đoán sự cố mạng
    • Phát hiện và xử lý máy ảo hoạt động lỗi
    • Kiểm tra nhật ký SELinux và sửa các vi phạm phổ biến chỉ với một cú nhấp
    • Xem các chỉ số chi tiết về tải CPU, mức dùng bộ nhớ, hoạt động mạng và hiệu năng lưu trữ, được liên kết với system journal
  • Hỗ trợ các ứng dụng tùy chọn và của bên thứ ba
  • Thiết kế được kiểm thử và điều chỉnh thông qua nghiên cứu tính khả dụng, và mọi thay đổi mã đều phải vượt qua các bài kiểm thử trước khi được hợp nhất
  • Có thể dùng miễn phí và được cung cấp theo GNU LGPL

Cài đặt và truy cập

  • Có thể cài trên các bản phân phối chính, và sau khi chạy thì có thể truy cập từ các trình duyệt web phổ biến trên bất kỳ hệ điều hành nào
  • Cockpit có chu kỳ phát hành theo thời gian, với phiên bản mới ra mắt mỗi 2 tuần

Bài viết liên quan

2 bình luận

 
GN⁺ 2023-10-17
Ý kiến trên Hacker News

  • Việc chê bai giao diện quản trị đồ họa và chỉ chuộng dòng lệnh gần như là thái độ chỉ thấy cây mà không thấy rừng
    Vận hành máy chủ bằng cách bấm chuột không phải là cách hay, nhưng nói thật thì ssh với tư cách một cách vận hành cũng tương tự vậy
    Trạng thái của máy chủ production thực tế phải có khả năng tái lập từ đầu, và tốt nhất là sau khi cài OS, thêm phần mềm, áp dụng cấu hình thì không đụng vào nữa
    Dù là ssh hay Cockpit, cứ trực tiếp đăng nhập vào là rất dễ làm hỏng thứ gì đó
    Chỉ nên trực tiếp vào máy chủ khi làm các việc mang tính thăm dò, và lúc đó ưu thế giữa GUI và dòng lệnh không rõ ràng đến thế
    GUI có khả năng khám phá và tính trực quan tốt, nên hữu ích trong giai đoạn thử nghiệm để tìm ra cách cấu hình

    • Những câu như “vận hành bằng cách bấm chuột không phải là cách vận hành máy chủ”, “trạng thái máy chủ phải có thể tái lập từ đầu” thường được nói như chân lý hiển nhiên, nhưng thực tế cần đánh đổi kỹ thuật
      Cần giải thích vì sao trạng thái máy chủ phải có thể tái lập từ đầu, “từ đầu” là gì, và vì sao vận hành bằng cách bấm chuột là không được
      Cũng khó nói rằng chỉ cài OS, thêm phần mềm và áp dụng cấu hình là đã nắm bắt đầy đủ trạng thái máy chủ
      Mức bản vá phần mềm, dữ liệu ứng dụng, dữ liệu người dùng cũng là một phần của trạng thái máy chủ
      Trạng thái máy chủ production có thể được tái lập chính xác bằng cách khôi phục từ bản sao lưu; sao lưu/khôi phục cũng rất hợp với vận hành bằng cách bấm chuột, và có thể nhanh hơn, đáng tin cậy hơn so với cài lại OS và chạy script cấu hình
      Nếu là máy chủ lưu dữ liệu không bay hơi, thì sau khi triển khai máy chủ mới, đằng nào cũng cần hệ thống sao lưu để khôi phục dữ liệu người dùng
    • Tiền đề này giả định một môi trường đối xử với máy chủ như gia súc chứ không phải thú cưng
      Không phải ai cũng vận hành nền tảng web quy mô lớn trên một nền tảng orchestration
      Tuy vậy, ngay cả với máy chủ kiểu thú cưng, cũng phải biết cách phục hồi hoặc dựng lại; nếu không thì coi như không có chiến lược khôi phục sau thảm họa đúng nghĩa
    • Tôi tò mò khi nói “tái lập trạng thái máy chủ production từ đầu” thì đang nghĩ tới công cụ nào
      Ở homelab tôi đang dùng Ansible để cấu hình Raspberry Pi, và phần cài OS có vẻ khả thi vì chỉ là chép ảnh bit-for-bit vào boot media rồi chỉnh một số thiết lập tùy chọn
    • Theo tiêu chí đó thì có phải là chỉ dùng NixOS không nhỉ
    • Cả hai đều tốt vì những lý do khác nhau
      Tôi thích làm việc trên terminal, nhưng GUI tốt hơn cho trực quan hóa thì tôi nghĩ chẳng có gì phải tranh cãi

  • Điểm hay của dự án này là vì dùng kích hoạt socket của systemd, nên không cần một tiến trình server chạy thường trực
    Khi không dùng Cockpit thì không lãng phí tài nguyên, và việc truy cập trang về cơ bản giống như chạy một công cụ dòng lệnh rồi thoát
    Thiết kế thật sự đẹp

    • Công bằng mà nói, từ inetd của BSD4.3 năm 1986 đã có cách tương tự rồi
      Chi tiết triển khai khác nhau, nhưng ý tưởng lớn thì giống; nó từng phổ biến một thời rồi hết mốt mà không có lý do đặc biệt nào
      Một tiến trình server tốt nên ở trạng thái idle khi không có việc gì, mức dùng bộ nhớ thực tế cũng rất nhỏ để dễ bị swap out
      Nếu một server nào đó do tính chất sử dụng mà ngốn nhiều bộ nhớ, có lẽ bạn cũng không muốn việc khởi động theo nhu cầu thỉnh thoảng gây áp lực bộ nhớ
      Tuy nhiên, nó giúp dễ tránh việc bị chặn trong lúc chờ dịch vụ khởi động ở giai đoạn boot ban đầu, nên có lợi cho hiệu năng khởi động
    • Tìm hiểu vụ này thì có vẻ SSHD trên Ubuntu 22.10 trở về sau cũng dùng kích hoạt socket của systemd
      Tiến trình sshd sẽ không khởi động cho đến khi có ai đó kết nối qua SSH
      https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-ac...
    • Tôi thấy mình cần học thêm về systemd
      Càng xem kỹ càng liên tục thấy những tính năng hay và hữu ích
    • Cockpit khoảng 99% là gần với “không khác gì làm bằng dòng lệnh”, lại cung cấp một GUI terminal JavaScript nhỏ, người dùng và mật khẩu native, lịch sử giám sát nhẹ, cùng khả năng khám phá cấu hình để khỏi phải nhớ các lệnh systemd phức tạp, nên khá tuyệt
      Cài sẵn nó trên các Raspberry Pi nhỏ là một ý hay
      Nó rất hữu ích khi không ngồi trước terminal mà muốn lướt qua trạng thái, hoặc trong tình huống chỉ có trình duyệt web, có thể SSH qua webserver gần như native và chạy curl ...etc... ở prompt lệnh thật
    • Dù vậy, tôi vẫn nghĩ phải có một tiến trình server đang chạy để phục vụ các tài nguyên HTML/JS tĩnh của webapp Cockpit chứ
      Tôi thắc mắc kích hoạt socket của systemd có nghĩa là chỉ được dùng khi web client của người dùng cuối gửi các yêu cầu REST/GQL như truy vấn log hay không

  • “Porcelain” có giá trị riêng
    Tôi từng thấy các startup thất bại vì dù có backend làm sẵn nhưng không thể đẩy việc phát triển sản phẩm tới tận UI/UX
    Ở một công ty, tôi đã chứng minh rằng backend là một container orchestrator tùy biến hoàn toàn có thể được thay thế bằng AWS Lambda và ECS trong một cuối tuần, nhưng UI/UX và công cụ workflow thì sẽ mất lâu hơn nhiều
    Vậy mà họ vẫn tiếp tục lãng phí tiền bạc và thời gian để làm “cụm mới dựa trên Raft”
    Trong lúc đó, tôi được giao việc “thêm xử lý theo lô”, và vì đã dùng Go nên tôi gắn Nomad vào nội bộ rồi cho qua
    Tôi thích làm trong một đội phát hành tính năng, chứ không chỉ làm công nghệ vì công nghệ
    https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...

  • Mọi công cụ trong lĩnh vực này nên có một banner khổng lồ ghi “hết dung lượng đĩa”
    Ngay cả với những người debug server, điều này đôi khi cũng bất ngờ không phải là kiến thức phổ thông

    • Không hiểu vì sao, nhưng tôi cũng từng thấy điều tương tự

  • Năm 2022, 81 bình luận: https://news.ycombinator.com/item?id=31439811
    Năm 2021, 128 bình luận: https://news.ycombinator.com/item?id=26197510
    Năm 2018, 149 bình luận: https://news.ycombinator.com/item?id=16445612

    • Khi dự án trưởng thành và được nhiều người biết đến hơn, xu hướng như vậy phần nào có thể dự đoán được

  • Tôi không nghĩ mình sẽ dùng cái này
    Lại thêm một cổng mở, thêm một bề mặt tấn công cho các bot không ngừng quét lỗ hổng, thêm một dịch vụ phải liên tục giữ ở trạng thái mới nhất
    Dù vậy, có vẻ nó sẽ giúp máy chủ Linux dễ tiếp cận hơn
    Đặc biệt hữu ích cho những người chuyển từ shared hosting dựa trên PHP sang VPS đầy đủ, nhưng không có nhiều kiến thức về server và muốn có thứ như cPanel hoặc DirectAdmin

    • Không nhất thiết phải mở cổng; thay vào đó có thể dùng VPN hoặc tunnel SSH
      Tôi không rõ hai cách đó khác nhau thế nào

  • Tôi thực sự là RHCE, nhưng thread này có bầu không khí tích cực giả tạo đến mức giống như click farm phía Red Hat
    Cockpit cũng ổn, nhưng về cơ bản nó gần giống Windows Server Manager phiên bản Red Hat, và rất có thể chịu ảnh hưởng trực tiếp từ Server Manager
    Trong nhiều năm, tốc độ phát triển và cải tiến cũng chậm đến mức khó chịu
    Người đã quen với phiên SSH sẽ không dùng Cockpit, trừ khi có lẽ lúc tạo VM mới; còn so sánh với Proxmox thì vô lý
    Nó không có nổi một phần tư tính năng UI của Proxmox, chức năng quản lý VM cũng chỉ mới được thêm tương đối gần đây, và do độ trễ cùng hạn chế khi đi qua trình duyệt, Virtual Machine Manager vẫn tốt hơn
    Có nhiều việc Cockpit không làm được, và về sau cũng sẽ có nhiều việc không làm được
    Nó gần như là công cụ dành cho những người muốn bấm chuột, không dùng được vòng lặp Bash for/while, không hiểu chaining bằng pipe, và ghét vim
    Nói cách khác, nó là webmin cho Red Hat; trông cũng khá ngầu, nhưng đã quá cũ, phát triển chậm, được thổi phồng quá mức, nên tôi chưa từng dùng ngoài những gì cần cho kỳ thi chứng chỉ

    • Điều này giống như nói “bộ lọc Instagram là dành cho những người không biết xử lý layer trong Photoshop, không hiểu cả phép tổng hợp màu cơ bản, và chỉ muốn vuốt thôi”
      Vậy nên nó cũng là nhận định đúng
    • HN có guideline nói không nên đăng những ám chỉ như “astroturfing, tài khoản PR, huy động tập thể, đặc vụ nước ngoài” vì chúng làm giảm chất lượng thảo luận và thường là sai
      Nếu lo ngại bị lạm dụng, có thể gửi email tới hn@ycombinator.com; họ nói sẽ xem dữ liệu
      https://news.ycombinator.com/newsguidelines.html
    • Có phải lúc nào cũng phải chuẩn bị sẵn terminal emulator có SSH để triển khai không? Tôi không hiểu việc làm cho các tác vụ đơn giản trở nên đơn giản thì có vấn đề gì
      Khi gia đình đi du lịch, tôi chạy nhiều camera Raspberry Pi có module camera tốt hơn để trông thú cưng
      Các stream camera RTSP chạy dưới dạng systemd unit trên từng thiết bị, và health check để xác nhận có stream packet hay không cũng là một systemd unit khác
      Mỗi camera nhận một IP riêng trong mạng ZeroTier mà tôi quản lý
      Cockpit chỉ chạy khi cần, nên không có lý do gì để không cài sẵn cho việc quản trị
      Thỉnh thoảng một camera bắt đầu chỉ gửi khung hình trống; xử lý bằng giao diện web Cockpit trên điện thoại tốt hơn nhiều so với việc đang đi nghỉ mà phải kiếm bàn phím, SSH vào rồi restart stream unit
      Cũng có thể viết health check để phát hiện khung hình trống, nhưng với việc chỉ xảy ra vài lần mỗi năm, restart từ Cockpit dễ hơn nhiều so với viết cái đó
    • Cockpit rất hữu ích để quản lý libvirt + KVM từ xa mà không phải lục lọi XML được tài liệu hóa kém
      Có thể truy cập từ bất kỳ nền tảng nào, kể cả iPad, và gần như không cần cấu hình ngoài cài package và thêm chứng chỉ
      Tôi dùng Cockpit thay vì Proxmox trên các server Debian chạy VM, vì nó ít xâm lấn hơn nhiều và các máy đó còn làm việc khác như chạy Docker container
      Tôi dùng cho mục đích này từ khoảng năm 2019
      Màn hình thống kê cũng hữu ích, nhưng có lẽ tôi sẽ không cài chỉ vì phần đó
      Hầu như không có lựa chọn thay thế được bảo trì tốt nào khác cho phép tạo VM libvirt bằng trình duyệt web trên một máy đơn lẻ mà không chiếm quyền kiểm soát toàn bộ hệ thống
    • Tôi xem nó như một webmin nửa sống nửa chín
      Chỉ dùng được với NetworkManager, nhưng cấu hình mạng cho VM chỉ cần phức tạp hơn một chút là thường phải tắt NetworkManager, khiến Cockpit gần như không dùng được
      Với người muốn quản lý VM bằng GUI, virt-manager mạnh hơn nhiều
      [1] https://virt-manager.org/

  • Chất lượng chỉ ở mức “tàm tạm”
    Nó dùng được cho một số rất ít mục đích nhỏ, nhưng nếu vận hành homeserver thì tôi sẽ tránh
    Plugin giao diện file server của Cockpit đã cũ và không tốt
    Tôi không rõ rốt cuộc nên dùng nó vào việc gì; có thể dùng để giám sát đơn giản, nhưng làm công cụ quản trị thì không ổn

    • Chính xác là vậy
      Tôi không hiểu vì sao Red Hat lại thúc đẩy dự án này, và nó không có nhiều công dụng thực tế
      Việc hiển thị danh sách service systemd cũng không hữu ích hơn so với xem toàn bộ bằng output dòng lệnh

  • Khi tự host NAS, tôi thấy Cockpit tốt hơn OMV rất nhiều

    • Còn tùy mục đích sử dụng và một vài điều kiện; tôi đang dùng cả hai trên hai NAS khác nhau và đều hài lòng
      OMV có plugin Docker hỗ trợ Compose nên không cần GUI Docker riêng như Portainer, và chia sẻ SMB với client Windows không hiểu sao ổn định hơn
      Nó có GUI và cách tiếp cận thân thiện với người mới, nên cũng dễ chia sẻ với người dùng khác; ngoài ra còn có các tính năng tích hợp sẵn như fail2ban và WireGuard
      Cockpit là công dân hạng nhất trên các bản phân phối EL/Fedora, hỗ trợ Podman nhưng không hỗ trợ Docker, cũng không có hỗ trợ Compose/Quadlet
      Có các tính năng mạnh như quản lý VM và terminal, nhưng có lỗi liên quan đến Samba
    • Tôi tò mò vì sao lại như vậy
      Hiện tôi đang dùng OMV để chia sẻ tệp trong mạng nội bộ và chạy vài container Docker
      Hoạt động tốt, nhưng 90% tính năng thì tôi không dùng đến
    • Không biết Proxmox thì thế nào

  • Với những ai tò mò, theo https://github.com/cockpit-project/cockpit, Cockpit được viết bằng nhiều ngôn ngữ, trong đó C chiếm nhiều nhất, tiếp theo là JavaScript và Python
    src/cockpit có lẽ là logic backend chính và được viết bằng Python

    • Với tư cách là nhà phát triển Cockpit, tôi có thể nói rằng web server được viết bằng C, còn bridge cũ là một “API” để JavaScript giao tiếp với các API hệ thống như systemd, podman, dbus thông qua web server
      Bridge mới được viết bằng Python, và khi đến lúc, chúng tôi cũng muốn viết lại web server theo cách hiện đại hơn
    • Tôi tò mò mọi người quan tâm đến tech stack được dùng khi làm một sản phẩm chạy trên server đến mức nào
      Những phần như có những dependency nào, có cần để ý đến các lỗ hổng trong thư viện logging hay Curl hay không cũng quan trọng
      Việc xem sản phẩm được viết bằng một stack rõ ràng duy nhất hay pha trộn nhiều công nghệ cũng khá thú vị