Tóm tắt nhanh
- Uncloud triển khai ứng dụng dùng Docker Compose trên nhiều máy Linux, kết nối chúng qua mạng WireGuard mã hóa.
- Công cụ có service discovery, proxy Caddy và HTTPS tự động; image tự build có thể chuyển thẳng tới máy đích qua Unregistry.
- Uncloud chỉ hỗ trợ một phần Compose, không tự đồng bộ volume và không tự chuyển container sang máy khác khi máy đang chạy bị lỗi.
Uncloud đưa các máy chủ chạy Docker vào cùng một cụm để triển khai ứng dụng từ những tệp Compose quen thuộc, thay vì yêu cầu người dùng dựng Kubernetes chỉ để tận dụng thêm một máy trong homelab. Điểm đáng cân nhắc nằm ở giới hạn vận hành: công cụ giúp phân phối dịch vụ, nhưng không biến nhiều máy rời thành một hệ thống tự phục hồi hoàn toàn.
Tệp Compose cũ dùng lại được, nhưng không nguyên vẹn
Quản trị viên có thể thêm máy Linux qua SSH rồi chạy uc deploy tại thư mục chứa tệp Compose. Trước khi thay đổi hệ thống, Uncloud hiển thị kế hoạch triển khai, gồm container và volume sẽ được tạo hoặc cập nhật cùng máy dự kiến chạy chúng. Cách làm này cho phép kiểm tra thay đổi trước khi áp dụng, thay vì phải viết lại toàn bộ cấu hình cho một nền tảng mới.
Với ứng dụng tự build, Unregistry chuyển các lớp image còn thiếu trực tiếp tới những máy cần chạy chúng. Nhờ vậy, homelab không nhất thiết phải duy trì thêm một Docker registry riêng chỉ để phân phối image nội bộ.
Nhưng đây không phải bộ tương thích đầy đủ với đặc tả Compose. Uncloud không hỗ trợ custom network; muốn đưa dịch vụ web qua proxy tích hợp, cấu hình cần dùng phần mở rộng x-ports. Tên service cũng phải duy nhất trên toàn cụm, nên các stack độc lập cùng đặt tên db có thể cần đổi lại trước khi triển khai.
Mạng riêng và định tuyến được gom vào cùng một công cụ
Uncloud kết nối các Docker host bằng mạng WireGuard mã hóa và cung cấp phân giải tên dịch vụ. Container ở máy này có thể tìm dịch vụ ở máy khác bằng tên service thay vì phải quản lý thủ công từng địa chỉ IP. Mỗi máy được cấp một subnet riêng cho nó và các container: ví dụ trong tài liệu dự án, máy đầu dùng 10.210.0.0/24, máy thứ hai dùng 10.210.1.0/24. Nhờ các dải địa chỉ tách biệt, container trên những máy khác nhau có thể liên lạc qua mạng WireGuard.
Quản trị viên có thể chọn vị trí chạy dịch vụ bằng trường x-machines. Chẳng hạn, ứng dụng cần đọc thư viện media có thể đặt trên máy đang giữ dữ liệu; dịch vụ cần GPU thì được ghim vào host có phần cứng đó. Với ứng dụng hỗ trợ nhiều bản sao, Uncloud cho phép phân bố replicas qua các máy và phân phối lưu lượng giữa chúng.
Proxy Caddy tích hợp xử lý định tuyến dịch vụ web và cấp, gia hạn chứng chỉ TLS tự động qua Let’s Encrypt. Đây là phần giúp giảm các thao tác cấu hình mạng khi đưa ứng dụng ra ngoài, nhưng không đồng nghĩa mọi dịch vụ đều nên mở Internet: các bảng điều khiển quản trị và ứng dụng chứa dữ liệu riêng vẫn cần được giới hạn truy cập.
Volume không tự đi theo container sang máy khác
Mạng giữa các host chỉ giúp chúng liên lạc; nó không khiến Docker volume cục bộ tự xuất hiện trên máy khác. Nếu một ứng dụng phụ thuộc dữ liệu đang nằm trên một máy, cách đơn giản nhất là giữ ứng dụng ở đó. Muốn nhiều host truy cập cùng dữ liệu, người quản trị phải tự cấu hình lưu trữ chia sẻ như NFS hoặc SMB và lên kế hoạch sao lưu riêng.
Vì thế, phân tán container không tự giải quyết bài toán dữ liệu. Trước khi chuyển một service sang máy khác, cần biết volume nào chứa trạng thái quan trọng, cách đồng bộ hoạt động và quy trình khôi phục bản sao lưu. Nếu không, việc chạy được container ở nhiều nơi có thể tạo cảm giác dự phòng trong khi dữ liệu vẫn chỉ có một bản ở một máy.
Không cần quorum quản lý, nhưng máy hỏng vẫn cần người xử lý
Uncloud chia sẻ trạng thái cụm qua Corrosion, cơ sở dữ liệu SQLite phân tán dựa trên CRDT. Khác với Docker Swarm, nơi các manager dùng Raft và cần đa số node quản lý còn hoạt động để duy trì quorum, thiết kế phân tán của Uncloud không phụ thuộc vào nhóm manager trung tâm như vậy. Điều này giảm một lớp thành phần phải chăm sóc trong homelab; nó không loại bỏ mọi kiểu lỗi hay đảm bảo dịch vụ luôn sẵn sàng.
Nếu một máy chủ ngừng hoạt động, các bản sao khỏe mạnh trên máy khác có thể tiếp tục phục vụ. Tuy nhiên, Uncloud không tự tạo lại container bị mất ở host khác và cũng không tự tăng số lượng bản sao theo tải. Quản trị viên phải quyết định khi nào thay máy, chỉnh vị trí chạy hoặc triển khai lại. Đây là khác biệt quan trọng với kỳ vọng thường gắn với Kubernetes: Uncloud nhẹ hơn về vận hành cụm, nhưng đổi lại người dùng nhận ít tự động hóa phục hồi hơn.
Với người đã có nhiều máy Linux và các Compose file ổn định, Uncloud đáng thử khi mục tiêu là gom triển khai, mạng nội bộ và HTTPS vào một quy trình gọn. Nếu yêu cầu là tự động chuyển workload khi host hỏng, lưu trữ dùng chung sẵn có hoặc tương thích Compose gần như tuyệt đối, các giới hạn trên cần được tính vào thiết kế trước khi chuyển dịch vụ quan trọng.
Nguồn tham khảo: Tài liệu và mã nguồn Uncloud trên GitHub; XDA Developers
