Homelab của tôi không cần bảo trì

• Để giảm gánh nặng vận hành Homelab cá nhân, tác giả tập trung vào cấu hình máy chủ đơn và cập nhật tự động, nhờ đó loại bỏ được hầu hết các việc phải can thiệp thường xuyên
• Sau khi hợp nhất nhiều máy chủ thành một, độ phức tạp của môi trường giảm xuống và khối lượng bảo trì tính theo số lượng máy chủ cũng giảm 75%
• Raspberry Pi 4 dùng Home Assistant OS, còn mạng thì giao cho cơ chế cập nhật tự động và theo lịch của UniFi, giúp giảm các điểm phải quản lý thủ công
• Các dịch vụ Docker được cập nhật bằng crontab chạy docker compose pull và docker compose up -d mỗi tuần một lần, còn root crontab chủ yếu được dùng cho sao lưu
• Nếu không có tình huống khẩn cấp, tổng thời gian bảo trì hàng tháng chỉ khoảng 15 phút, và ngay cả khi hoãn apt update hay khởi động lại thì dịch vụ cũng hầu như không bị ảnh hưởng ngay

---

Cấu trúc hạ tầng được đơn giản hóa

• Các dịch vụ Homelab đã được hợp nhất từ nhiều thiết bị về một máy chủ duy nhất
  • Trước đây dùng 4 máy chủ, nhưng hiện tại mọi dịch vụ được gom vào một máy chủ vật lý
  • Thay vì cluster, hypervisor hay hybrid cloud, tác giả vận hành bằng một thiết bị vật lý duy nhất trong tầng hầm
  • Việc đơn giản hóa này giúp lượng công việc bảo trì tính theo máy chủ giảm 75%
• Raspberry Pi 4 vẫn tồn tại riêng, nhưng Home Assistant OS tự xử lý cập nhật nên gánh nặng quản trị rất nhỏ
  • Về mặt kỹ thuật nó gần với một máy chủ, nhưng trải nghiệm sử dụng thực tế lại giống một thiết bị IoT tự vận hành hơn
• Thiết bị mạng được vận hành theo cấu hình UniFi trong một mini rack
  • Bao gồm UniFi Dream Machine Pro, switch và nhiều AP
  • Nhờ hỗ trợ cập nhật tự động và cập nhật theo lịch, thiết bị mạng cũng không cần bị can thiệp thủ công thường xuyên

Cập nhật phần mềm và sao lưu được tự động hóa

• Việc cập nhật các dịch vụ Docker được chạy hàng tuần bằng một mục crontab duy nhất trên máy chủ
  • 0 0 * * 0 docker-update
  • docker-update sẽ chạy sudo docker compose pull và sudo docker compose up -d trong từng thư mục dưới ~/docker/*/
• crontab của người dùng root chủ yếu phục vụ cho sao lưu
  • Tạo báo cáo hệ thống mỗi ngày
  • Tạo bản dump PostgreSQL cho Immich và Piped
  • Sao lưu Plex, web server, cấu hình Nginx, thư mục Docker và tệp SSH sang ZFS pool bằng rsync
  • Khi sao lưu thư mục Docker, tác giả loại trừ cơ sở dữ liệu, cache, tệp tạm và một số đường dẫn log
• Những việc thủ công còn lại chỉ là chạy apt update, apt upgrade, apt autoremove và khởi động lại khi cần
  • Phần việc này mất khoảng 60 giây
• Nếu không có tình huống khẩn cấp, thời gian bảo trì chỉ vào khoảng 15 phút mỗi tháng
  • Ngay cả khi không SSH vào để cập nhật suốt một tháng, các dịch vụ thực tế cũng không bị ảnh hưởng
  • Có thể để hơn 6 tháng không đụng tới mà vẫn không hỏng, nhưng tác giả không định cố tình thử
• Cấu hình hiện tại mang lại sự cân bằng giữa quyền riêng tư, bảo mật và tính tiện lợi ngay cả trong lịch trình bận rộn

[GN⁺]

Các ý kiến trên Lobste.rs

• Tôi cũng đang vận hành máy chủ ở nhà theo cách tương tự
  Bật nâng cấp bảo mật không giám sát trên Debian, mọi thứ chạy dưới dạng container rootless với phiên bản được ghim cố định, và systemd quản lý thông qua Podman Quadlet
  auto-update của Podman xử lý việc cập nhật container, còn timer của systemd đảm nhận các tác vụ lặp lại như sao lưu và dọn dẹp image
  Chỉ đăng nhập để khởi động lại khi có nâng cấp kernel hoặc khi tăng phiên bản image, và việc này do Ansible xử lý

  • Phần dùng cả “ghim phiên bản” lẫn “Podman auto-update” khiến tôi hơi bối rối
    Tôi hiểu ghim phiên bản nghĩa là không tự động lấy bản cập nhật, nhưng thực tế có vẻ vẫn đang cập nhật, nên không rõ có phải các đối tượng khác nhau đang được cập nhật hay không
  • Tôi đã dùng cấu hình gần như y hệt trong hơn 10 năm, và cứ hai năm một lần nâng lên bản stable mới nhất
    Thiết bị duy nhất tôi quản lý riêng là một router chạy OpenBSD, nên tôi nâng cấp mỗi khi có bản mới, khoảng 6 tháng một lần
    Cả hai đều ổn định đến mức nhàm chán

• Tương tự, nhưng tôi không cập nhật gì cho đến khi có tính năng mình muốn
  Điểm hay của phần mềm self-hosting là có thể cập nhật theo lịch của chính mình
  Nếu mọi thứ đang chạy tốt, chỉ truy cập qua Tailscale và không phơi trực tiếp ra Internet, thì trừ lỗi phần cứng, cứ để nguyên cũng ổn định

  • Tôi tò mò vì sao việc ứng dụng phơi trực tiếp ra Internet lại khác với phơi qua Tailscale
    Dữ liệu đến được ứng dụng rốt cuộc vẫn giống nhau, nên chẳng phải cùng một lỗ hổng vẫn có thể bị khai thác sao?

• Nếu ở trạng thái như vậy thì đó là một tình huống khá tốt
  Tôi cũng đang cố đạt đến đó nhưng vẫn chưa hoàn toàn làm được
  Nâng cấp major Debian vẫn cần thao tác thủ công mỗi 2 năm: "Issues to be aware of for trixie", "Obsolescence and deprecation", "Cleanup after the upgrade"
  Ansible cũ không xử lý được hệ thống Debian mới nhất, nên khi nâng máy chủ Debian thì cũng phải nâng phiên bản Ansible, và cuối cùng phải chỉnh playbook cho phù hợp với Ansible mới
  Hiện tôi đang cố giảm việc này bằng cách dùng nhiều Docker container hơn, nhưng có lẽ khó thay thế hoàn toàn Ansible
  Cũng có những dịch vụ trực tuyến tôi không muốn tự host như freeDNS, dynv6.net, và thỉnh thoảng chúng cũng đưa ra thay đổi gây hỏng tương thích
  Dù vậy, nhìn chung mọi thứ vẫn khá ổn
  Nói thật thì việc quản lý một homelab “không cần bảo trì” thực chất là giao cho các nhà phát triển mã nguồn mở trên toàn thế giới, những người đang duy trì phần mềm, gói và Docker image mà chúng ta dùng

• Tôi hơi ngần ngại gọi cấu hình của mình là “homelab”, nhưng đó là một NAS unRAID chạy nhiều Docker container
  Một trong những lý do tôi hài lòng dù phải trả tiền cho unRAID là hỗ trợ Docker khá tốt, có thể tự động cập nhật container bằng plugin, và các việc bảo trì khác cũng khá đơn giản

• Cá nhân tôi thấy hơi vướng ở chỗ “lab” giống nơi để thử nghiệm hơn, và bản thân thí nghiệm thì không cần bảo trì
  Việc dùng container có cả ưu lẫn nhược điểm
  Với một số dự án, container là phương thức phân phối hạng nhất, nên có thể nhận cập nhật đúng cách theo hướng đó
  Nhưng tôi nghĩ nhiều người đang chạy các container được duy trì không rõ ràng, và sẽ có nhiều vấn đề nảy sinh từ đó
  Cốt lõi là phải xác định được kênh chính thức để nhận cập nhật cho phần mềm mình dùng là gì
  Tôi chủ yếu vận hành các bản clone RHEL với cập nhật tự động, và nếu cần khởi động lại thì Nagios sẽ báo
  Phần lớn dịch vụ nằm trong RHEL hoặc EPEL nên việc bảo trì khá ít

• Với việc bảo trì homelab của tôi, pyinfra cho phép lười đúng mức
  Có thể ghi lại quy trình cấu hình bằng code, đặc biệt hữu ích với những thứ như file cấu hình, và nếu cần thì cứ gọi apt mà không phải băn khoăn kiểu xử lý việc này trong nix ra sao
  Nó không phải công cụ quá thông minh, nhưng tốt hơn một shell script đơn lẻ, và tôi muốn tiếp tục phát triển thêm
  Nếu dùng kiểu lập trình bằng agent, còn có điểm cộng là có thể đưa file pyinfra cho Claude xem và nhờ hỗ trợ debug cấu hình

• Tôi đang dùng NixOS trên máy chủ, và thỉnh thoảng cập nhật khi nhớ ra
  Phần lớn chỉ là nix flake update && nix run .#deploy, nên không phải bận tâm nhiều

• Tôi cũng ở tình huống rất tương tự, và dù không muốn thừa nhận, phần lớn là nhờ cấu hình rốt cuộc đã đơn giản hơn
  Trước đây tôi thích cả một observability stack đầy đủ với log xoay vòng, nhưng hơn 2 năm qua, các chuyện đau đầu gần đây đều là những vấn đề lặt vặt phát sinh từ sự phức tạp đó
  Kiểu như log và metric làm đầy đĩa
  Cách xử lý rất dễ, nhưng giờ tôi không còn muốn xử lý những việc như vậy nữa

• Tôi thích Watchtower để giữ cấu hình docker-compose luôn mới
  https://hub.docker.com/r/nickfedor/watchtower
  Các tùy chọn cấu hình cho phép liên tục nâng phiên bản mà vẫn phần nào tính đến các thay đổi lớn là khá tốt
  Hệ điều hành nền là Debian LTS, chỉ bật cập nhật không giám sát, và khi có kernel mới thì đăng nhập để khởi động lại
  Thực sự không tốn nhiều công, và tôi đồng ý với nhận định dưới 15 phút mỗi tháng