Return

Cockpit Cho VPS: Hướng Dẫn Quản Trị Toàn Diện Từ Cài Đặt Đến Vận Hành Production

Bài viết chuyên sâu về Cockpit: kiến trúc, cài đặt, hardening bảo mật, quản lý service, log, update, Podman và các thực hành vận hành VPS an toàn. Written by LocLT
LinuxVPSDevOpsCockpit

Nếu bạn từng ngồi SSH lúc 1-2 giờ sáng để lần log vì một service vừa chết, bạn sẽ hiểu cảm giác cần một cái nhìn tổng thể nhanh đến mức nào. Không phải để thay terminal, mà để đỡ mất thời gian chuyển ngữ cảnh.

Cockpit làm đúng phần đó. Nó cho bạn một bảng điều khiển web để nhìn CPU, RAM, service, log, update, user… nhưng vẫn bám theo cách vận hành Linux chuẩn. Không vẽ ra một thế giới mới.

Bài này không theo kiểu “cài xong là xong”, mà đi theo góc nhìn vận hành thật: dùng Cockpit ở production sao cho tiện mà vẫn an toàn.

Cockpit hợp với ai, và không hợp với ai?

Cockpit hợp khi bạn quản lý VPS chạy API, worker, cron, database nhỏ-vừa, hoặc vài chục máy cần theo dõi nhanh. Team nhỏ thường thấy hiệu quả rõ nhất vì giảm thao tác thủ công.

Ngược lại, nếu bạn kỳ vọng một panel hosting kiểu cPanel (quản lý domain/email/account khách hàng hàng loạt), Cockpit không phải công cụ đó.

Nói ngắn gọn: Cockpit là “bảng điều khiển vận hành Linux”, không phải “nền tảng hosting đa tenant”.

Vì sao Cockpit nhẹ dù làm được nhiều thứ?

Phần này đáng hiểu một chút, vì nó giải thích tại sao Cockpit không quá tốn tài nguyên.

  • cockpit.socket dùng cơ chế socket activation của systemd, nghĩa là nhàn thì rất nhẹ.
  • cockpit-ws phục vụ giao diện web ở cổng 9090.
  • cockpit-bridge là lớp trung gian để thao tác hệ thống theo quyền user đang đăng nhập.

Điểm mình đánh giá cao là Cockpit không phá permission model của Linux. Bạn login user nào thì thao tác theo quyền user đó. Không có cảm giác “panel toàn năng” khó kiểm soát. Bạn có thể hình dung nhanh mối quan hệ giữa các thành phần ở Hình 1.

Hình 1: Kiến trúc Cockpit trên VPS (browser -> cockpit-ws -> cockpit-bridge -> system services).

Cài Cockpit trên Ubuntu/Debian

sudo apt update
sudo apt install -y cockpit
sudo systemctl enable --now cockpit.socket
sudo systemctl status cockpit.socket

Mở cổng nếu dùng UFW:

sudo ufw allow 9090/tcp

Truy cập bằng trình duyệt:

https://<VPS-IP>:9090

Lần đầu bạn sẽ thấy cảnh báo chứng chỉ self-signed. Bình thường. Nếu chạy production, nên đặt Cockpit sau reverse proxy và TLS chuẩn.

Trước khi dùng thật: 5 việc bảo mật nên làm ngay

Phần này là thứ nhiều người bỏ qua nhất.

1) Đừng login root trực tiếp
Dùng một user vận hành riêng, cấp sudo theo nhu cầu. Việc này giúp audit dễ hơn và giảm rủi ro thao tác nhầm.

2) Đừng mở 9090 công khai cho cả Internet
Nếu có IP cố định, giới hạn luôn từ firewall:

sudo ufw allow from <YOUR_OFFICE_IP> to any port 9090 proto tcp
sudo ufw deny 9090/tcp

3) Đặt Cockpit sau Nginx/Caddy nếu truy cập thường xuyên
Mình thường cho Cockpit chỉ nghe nội bộ, public qua 443, gắn TLS của Let’s Encrypt. Cách này sạch hơn nhiều so với mở thẳng :9090.

4) Bật chống brute-force
fail2ban cho SSH và endpoint quản trị vẫn là lớp phòng thủ cơ bản nhưng rất hiệu quả.

5) Cập nhật định kỳ
Cockpit không phải thứ “cài một lần rồi quên”. Vẫn cần vá đều như các thành phần hệ thống khác. Mô hình triển khai tối thiểu an toàn được minh họa ở Hình 2.

Hình 2: Mô hình triển khai an toàn cho Cockpit với reverse proxy, TLS và giới hạn IP.

Một vòng vận hành hằng ngày với Cockpit

Đây là cách mình thường dùng khi trực hệ thống.

Bước 1: nhìn tổng quan trước khi xử lý

Mở tab Overview, xem CPU, RAM, disk I/O, network trong cùng một màn hình. Mục tiêu là tìm xu hướng, không phải nhìn một con số rồi kết luận ngay.

Ví dụ: CPU tăng nhưng RAM ổn và I/O thấp thì khả năng cao là tải xử lý thật. Nhưng CPU bình thường mà I/O tăng vọt thì thường là bottleneck disk hoặc log ghi quá mạnh.

Bước 2: kiểm tra service trong systemd

Ở tab Services, bạn thấy ngay service nào đang failed, activating, hay restart liên tục.
Khi deploy xong mà app không lên, mình thường bắt đầu từ đây thay vì SSH vào đoán mò.

Bước 3: bám timeline log

Tab Logs của Cockpit rất hữu ích khi bạn lọc theo unit (nginx.service, docker.service, your-api.service) và theo thời gian.
Kinh nghiệm thực tế: hãy bám mốc lúc alert nổ, đọc từ trước đó vài phút. Root cause thường nằm sớm hơn dòng lỗi cuối cùng.

Bước 4: cập nhật có kiểm soát

Cockpit giúp xem update trực quan, nhưng thao tác update vẫn nên theo cửa sổ bảo trì.
Nếu có kernel update, chuẩn bị phương án reboot và rollback trước khi bấm.

Nếu bạn dùng container: Cockpit có đủ không?

Với Podman hoặc nhu cầu container cơ bản, Cockpit khá tiện: xem container đang chạy, log, restart, dọn image cũ. Ví dụ giao diện quản lý Podman trong Cockpit như Hình 4 bên dưới.

Hình 4: Giao diện Cockpit Podman để quan sát và thao tác container.

Nhưng nếu đã chạy cụm lớn hoặc orchestration phức tạp, Cockpit nên là lớp quan sát phụ. Nó không thay thế CI/CD, IaC hay hệ giám sát chuyên dụng. Bạn có thể tham khảo thêm các màn hình thao tác thực tế ở Hình 5, Hình 6 và Hình 7.

Hình 5: Chi tiết pod/container trong Cockpit Podman (CPU, memory, port, volume).

Hình 6: Giao diện pull image trực tiếp từ Cockpit.

Hình 7: Tính năng dọn container không dùng (prune) trong Cockpit Podman.

Nguồn ảnh: Cockpit Project Blog (cockpit-project.org).

Quản lý nhiều VPS trong một nơi

Cockpit có thể thêm nhiều host, rất hợp với team đang quản lý vài máy đến vài chục máy.
Mẹo nhỏ nhưng hữu ích:

  • Đặt tên host nhất quán (api-prod-01, worker-prod-02)
  • Tách môi trường rõ (dev, staging, prod)
  • Không dùng chung tài khoản admin cho mọi môi trường

Những thứ này nghe cơ bản, nhưng giúp giảm nhầm lẫn rất nhiều khi có sự cố thật.

3 lỗi hay gặp khi mới triển khai Cockpit

1) Không vào được :9090

Chạy nhanh ba lệnh này:

sudo systemctl status cockpit.socket
sudo ss -lntp | grep 9090
sudo ufw status

Thường là một trong ba nguyên nhân: service chưa chạy, firewall chặn, hoặc security group trên cloud chưa mở.

2) Đăng nhập cứ báo sai

Kiểm tra user có bị lock không, shell có hợp lệ không, rồi đọc log xác thực:

sudo journalctl -u cockpit -u ssh --since "30 min ago"

Đừng đoán. Cứ đọc log, bạn sẽ thấy lý do cụ thể.

3) Service restart liên tục sau deploy

Đừng restart vô hạn. Đi lần lượt:

  1. Xem trạng thái bằng systemd
  2. Xem log đúng thời điểm crash
  3. Soát config/env/permission file
  4. Xác nhận tài nguyên (RAM/disk) có cạn không

Quy trình này nghe chậm, nhưng thực tế lại nhanh hơn vì tránh sửa sai hướng. Tóm tắt luồng phản ứng sự cố được minh họa ở Hình 3.

Hình 3: Luồng xử lý sự cố nhanh bằng Cockpit để giảm MTTR.

Kết lại

Cockpit đáng dùng vì nó cân bằng được hai thứ tưởng như mâu thuẫn: trực quan và đúng chuẩn Linux.
Bạn vẫn làm chủ hệ thống bằng quyền thật, log thật, service thật, chỉ là có thêm một lớp quan sát tốt hơn để ra quyết định nhanh hơn.

Nếu đang quản lý VPS một mình hoặc team nhỏ, Cockpit là nâng cấp rất “đáng tiền” dù nó miễn phí. Chỉ cần nhớ một điều: công cụ tốt chỉ phát huy tối đa khi đi cùng quy trình vận hành tốt.