Mỗi lần push lại là đúng một nghi thức: SSH vào máy, kéo repo về, dựng lại stack Compose, hy vọng không có gì hỏng, rồi cố nhớ xem đã chạy migration chưa. Vòng lặp thủ công đó vẫn ổn cho đến khi bạn cần triển khai lặp lại được, cần biết rõ cái gì đang chạy, hoặc cần khôi phục khi trạng thái bị lệch.
Doco CD là một câu trả lời trực tiếp. Đó là một dịch vụ Go nhỏ theo dõi repo Git của bạn và áp dụng thay đổi Compose mỗi khi bạn push: webhook hay polling là tùy bạn. ArgoCD và Flux làm điều này cho Kubernetes, nhưng Doco CD bỏ qua Kubernetes vì nó không cần control plane.
Bài đánh giá này nói về những gì Doco CD làm được, những gì không, và nó so ra sao với Komodo, chế độ GitOps của Portainer, Dokploy và một script GitHub Actions + SSH thuần túy. Đọc xong bạn sẽ biết nó có hợp với hệ thống của mình không, và nên chọn gì nếu không hợp.
Tóm tắt nhanh
- Doco CD là một agent GitOps tí hon, sinh ra cho Compose: nó theo dõi repo Git (GitHub, GitLab, Gitea, Forgejo và các nền tảng khác) rồi đồng bộ lại stack của bạn mỗi khi có thay đổi.
- Hỗ trợ sẵn các nhà cung cấp secret bên ngoài, cộng thêm mã hóa dựa trên SOPS, chính là điểm khác biệt so với việc tự viết script triển khai.
- Theo README của chính nó, dự án tự định vị là "một lựa chọn đơn giản thay cho Portainer hoặc ArgoCD dành cho Docker". Cách đóng khung đó gần đúng.
- Giới hạn thực sự: chỉ một người sở hữu mã nguồn, đánh phiên bản trước 1.0, không có giao diện quản lý cụm máy, và trạng thái đối chiếu chỉ được dựng lại sau lần polling hoặc sự kiện webhook kế tiếp.
- Hãy chọn nó khi bạn chạy một hoặc vài host Compose và muốn lấy Git làm nguồn chân lý mà không cần giao diện. Chọn Komodo cho cụm nhiều máy, Portainer khi bạn muốn có giao diện, Dokploy để có cảm giác PaaS, hoặc GitHub Actions + SSH khi thật sự chỉ có một dịch vụ trên một host.
Khoảng trống mà Doco CD muốn lấp
Ai chạy Docker Compose vào năm 2026 cũng rơi vào một vùng giữa kỳ lạ. Các công cụ GitOps lớn như Argo CD và Flux nhắm vào Kubernetes, còn mô hình polling registry của Watchtower thì phản ứng theo thay đổi image thay vì áp dụng trạng thái Compose có phiên bản. kho lưu trữ của Watchtower đã được lưu trữ vào ngày 17 tháng 12 năm 2025 và hiện thông báo rằng dự án không còn được duy trì.
GitHub Actions cộng thêm một bước deploy qua SSH vẫn chạy tốt. Với một dịch vụ trên một host, đó là lựa chọn đúng. Rắc rối xuất hiện khi bạn thêm host thứ hai, thêm stack thứ hai, hoặc muốn biết commit nào đang được triển khai. Bạn vẫn có log của workflow, nhưng không có đối chiếu kiểu Compose, không có khôi phục khi lệch trạng thái, và không có góc nhìn thường trực về việc host còn khớp với repo hay không.
Lời giới thiệu của Doco CD, trích thẳng từ README, là "một lựa chọn đơn giản thay cho Portainer hoặc ArgoCD dành cho Docker". Chính cách đóng khung đó mới là điểm mấu chốt: nhỏ gọn, thuần Compose, không Kubernetes, không có giao diện phải bảo trì, không có control plane trung tâm phải trông chừng. Nếu bạn không chạy K8s và cũng chẳng muốn, đây đúng là loại công cụ bạn đang tìm.
Doco CD thực sự hoạt động thế nào
Doco CD là một binary Go duy nhất chạy trong container Docker, theo dõi một repository Git và áp dụng các thay đổi Compose khi trạng thái repo thay đổi. Toàn bộ ý tưởng chỉ có vậy. Phần thú vị nằm ở các giá trị mặc định và khả năng tích hợp.
Cơ chế kích hoạt. Có hai chế độ: webhook hoặc polling. Webhook gần như tức thì nhưng cần mở một cổng, hoặc thực tế hơn là đặt một reverse proxy trước Doco CD. Polling là việc lấy dữ liệu định kỳ: chậm hơn một chút nhưng không cần cổng vào. Polling là mặc định đơn giản hơn, và theo tài liệu chính thức cả hai đều là lựa chọn hạng nhất. Hãy chọn dựa trên việc host của bạn có endpoint công khai truy cập được hay không và bạn cần triển khai nhanh đến mức nào.
Cấu hình theo từng repo. Một tệp .doco-cd.yaml (hoặc .doco-cd.yml) nằm ở thư mục gốc của repo, ngay cạnh tệp Compose của bạn. Trường bắt buộc duy nhất là tên của deployment. Một cấu hình tối giản trông như sau:
# .doco-cd.yaml
name: my-stack
# Everything below is optional. These are the defaults.
timeout: 180 # seconds
remove_orphans: true
prune_images: true
force_recreate: falseĐó là các giá trị mặc định được ghi trong tài liệu: thời gian chờ 180 giây, xóa container mồ côi, dọn image không dùng và không ép tạo lại.
Tự động phát hiện. Khi bật tự động phát hiện, Doco CD sẽ quét các thư mục con để tìm tệp Compose, nên một repo có thể chứa nhiều stack. Nó cũng hỗ trợ nhiều cấu hình triển khai trong cùng một tệp, viết dưới dạng các tài liệu YAML ngăn cách bằng dòng ba dấu gạch ngang. Các giá trị mặc định cho việc dọn dẹp khá thận trọng, và bạn nên đọc kỹ trước khi dựa vào chúng:
| Cài đặt | Mặc định | Ý nghĩa |
|---|---|---|
delete | false | Một deployment lỗi thời vẫn được giữ nguyên khi ứng dụng của nó biến mất khỏi thư mục làm việc. |
remove_volumes | false | Các volume vẫn còn khi một stack được tự động phát hiện bị xóa. |
remove_images | true | Các image không dùng đến sẽ bị xóa khi một stack được tự động phát hiện bị xóa. |
Nói cách khác, không có gì bị dỡ bỏ sau lưng bạn cho tới khi chính bạn bật tính năng xóa, và ngay cả khi đó thì các volume dữ liệu vẫn là thứ cuối cùng ra đi.
Các nhà cung cấp Git được hỗ trợ. GitHub, GitLab, Gitea, Forgejo, Gogs và Azure DevOps đều được hỗ trợ. Azure DevOps là ngoại lệ ở phần webhook, vì Azure Service Hooks không được hỗ trợ. Việc hỗ trợ Gitea và Forgejo sẽ quan trọng nếu bạn tự vận hành nền tảng quản lý mã nguồn.
Docker Swarm. Được hỗ trợ như một đích triển khai. Điều mà trang cài đặt triển khai nêu rõ là: khi ở chế độ Swarm, quá trình đối chiếu không kiểm tra việc khởi động lại container hay trạng thái health, và Swarm cũng không hỗ trợ dọn image. Nếu đích của bạn là Swarm, bạn có được việc triển khai chứ không có đối chiếu health đầy đủ.
Đối chiếu trạng thái. Mặc định có giới hạn 5 lần khởi động lại trong cửa sổ 300 giây, nhằm ngăn các health check chập chờn lặp vô tận. Cùng repo nhưng khác ref thì chạy tuần tự; cùng repo và cùng ref thì chạy song song. Chi tiết cuối này khá tinh tế nhưng hữu ích: nhiều lần triển khai cùng một ref sẽ không phải xếp hàng chờ nhau.
Các nhà cung cấp secret bên ngoài tích hợp sẵn. Đây là một trong những lý do mạnh nhất để chọn Doco CD thay vì một script triển khai thuần túy: nó hỗ trợ AWS Secrets Manager, Bitwarden Secrets Manager, Bitwarden Vault / Vaultwarden, 1Password, 1Password Connect, Infisical, OpenBao và Webhook. Bên cạnh đó, nó còn hỗ trợ mã hóa dựa trên SOPS cho dữ liệu triển khai nhạy cảm. Nhờ vậy bạn có một lối thoát gọn gàng khỏi các tệp env dạng văn bản thuần trong Git, mà không phải tự dựng toàn bộ quy trình phân giải secret.
Phần còn lại. Doco CD cung cấp số liệu Prometheus, lập lịch tác vụ, thông báo, một image container distroless và giấy phép Apache-2.0. Theo lịch sử phát hành, tính đến ngày 20 tháng 8 năm 2026, v0.109.2 là bản ổn định mới nhất và v0.110.0-rc.1 là bản tiền phát hành mới nhất.
Nhiệm vụ của Doco CD dừng lại ở chỗ "áp dụng manifest"; từ đó trở đi là Docker thông thường. Các lệnh xem log của chính Compose là thứ bạn dùng để xem cái gì đang chạy.
Mẹo về secret. Nếu repo riêng của bạn vẫn còn các tệp env dạng văn bản thuần, hãy ưu tiên dùng các nhà cung cấp secret bên ngoài của Doco CD hoặc phần hỗ trợ SOPS. Mục tiêu rất đơn giản: đưa secret dạng thuần ra khỏi Git nhưng vẫn để quá trình triển khai lấy được giá trị lúc chạy.
Xây dựng trên VPS Linux với quyền root, NVMe và sức mạnh AMD EPYC.
Xem các gói LinuxDoco CD còn thiếu ở đâu
Công cụ nào cũng có giới hạn, và giới hạn của Doco CD đáng để bạn biết trước khi dành cả cuối tuần để cài đặt nó.
Chỉ một người sở hữu mã nguồn. Tệp CODEOWNERS của repository gán toàn bộ đường dẫn cho kimdre. Nhịp phát hành vẫn dày, nhưng quyền điều hành tập trung vào một người.
Trước 1.0. Doco CD vẫn dùng cách đánh phiên bản 0.x, nên hãy ghim một bản đã kiểm chứng và đọc ghi chú nâng cấp trước khi triển khai. issue GitHub #851 đã đóng cho thấy lý do: Docker v29 buộc dự án phải rời bỏ các module Go của Docker đã ngừng hỗ trợ.
Không có shell bên trong container Doco CD. Vì lý do bảo mật, Doco CD không cung cấp môi trường shell và cũng không chạy script tùy ý trên host. Các tác vụ trước và sau khi triển khai phải đi qua init container, sidecar hoặc lifecycle hook của Compose, tức là thêm phần cấu hình so với những công cụ chạy thẳng một script triển khai.
Mất trạng thái khi khởi động lại. Trạng thái đối chiếu nằm trong bộ nhớ. Khi Doco CD khởi động lại, trạng thái đó chỉ được dựng lại sau lần polling hoặc sự kiện webhook kế tiếp, nên khoảng trống dài bao lâu là tùy vào chu kỳ polling của bạn hoặc thời điểm webhook tiếp theo tới.
Không có giao diện quản lý cụm máy. Chạy nhiều host không còn đòi hỏi mỗi host một agent. Từ v0.102.0, các cấu hình triển khai có thể trỏ tới các Docker context từ xa, kể cả context qua SSH, và một repository có thể khai báo nhiều đích triển khai. Chạy mỗi host một instance Doco CD vẫn là cách hợp lệ, nhưng giờ một instance trung tâm đã có thể triển khai tới các host Docker ở xa. Thứ Doco CD vẫn còn thiếu là giao diện quản lý cụm máy như của Komodo và danh mục host tập trung.
Mức tiêu thụ RAM và CPU không được ghi thành con số cụ thể. Tài liệu chính thức mô tả yêu cầu tài nguyên là "rất nhỏ" nhưng không công bố con số nền nào. Hãy chọn kích thước VPS theo các ứng dụng sẽ chạy trên đó, chừa dư địa vận hành, và tự đo mức tiêu thụ thực tế của Doco CD trong môi trường của bạn.
Mẹo cho nhiều host. Hãy dùng Docker context và đích triển khai riêng cho từng host, siết chặt quyền truy cập SSH, và giữ cho secret của webhook hay API không trùng nhau. Nếu bạn thích các agent tách biệt, cách chạy mỗi host một instance Doco CD vẫn hoàn toàn hợp lệ.
Doco CD so với các lựa chọn khác
Bốn công cụ còn lại mà tôi đưa vào danh sách rút gọn đều cố giải cùng một bài toán "tự động triển khai Compose từ Git", nhưng với những đánh đổi rất khác nhau. Câu hỏi không phải là có nên làm hay không, vì bạn đã quyết rồi. Câu hỏi là dạng công cụ nào hợp với hệ thống của bạn. Đây là bảng đối chiếu.
| Công cụ | Kích hoạt | Mô hình đa host | Quản lý secret | Giao diện web | Giấy phép |
|---|---|---|---|---|---|
| Doco CD | Webhook hoặc polling | Docker context từ xa, không có giao diện cụm máy | Nhà cung cấp bên ngoài cộng SOPS | Không gì | Apache-2.0 |
| Komodo | Webhook cộng đồng bộ theo lịch | Dịch vụ Core trung tâm cộng các agent Periphery | Quản lý biến và secret | Có | GPL-3.0 |
| Portainer (CE/BE) | Webhook hoặc polling | Agent của Portainer | Hạn chế, nhiều tùy chọn hơn ở BE | Có | Zlib, điều khoản thương mại cho BE |
| Dokploy | Kích hoạt khi push | Nhiều máy chủ hoặc Docker Swarm | Quản lý môi trường tích hợp sẵn | Có | Apache-2.0, kèm một số thành phần độc quyền |
| GitHub Actions + SSH | Kích hoạt khi push | Tùy bạn viết script thế nào | Tùy bạn viết script thế nào | Không gì | Không áp dụng |
Vài dòng về từng công cụ, vì bảng cho thấy hình dáng còn phần bình luận nói lý do:
Komodo. Lựa chọn nghiêm túc cho nhiều host. Một dịch vụ Core trung tâm cùng agent Periphery trên mỗi máy, một giao diện nhìn thấy tất cả, build do Git điều khiển bên cạnh việc triển khai, và hỗ trợ Docker Swarm. Cài đặt nặng hơn vì bạn phải chạy cả cơ sở dữ liệu lẫn control plane, nhưng đây là hình dáng phù hợp nếu bạn có nhiều máy. Komodo hợp hơn khi việc kiểm soát tập trung cả cụm là điều quan trọng.
Portainer (CE hoặc BE) kèm GitOps. Một giao diện đồ họa đầy đủ đặt trên cơ chế đồng bộ với Git. Đây là lựa chọn đúng khi cả nhóm muốn quản lý container bằng chuột song song với CD. Nếu đằng nào cũng có người vào giao diện xem log và khởi động lại container, thì để CD ở luôn chỗ đó cũng hợp lý. Mức tiêu thụ tài nguyên nặng hơn Doco CD. OIDC/SSO và RBAC chi tiết bị khóa sau bản Business Edition trả phí. hướng dẫn về các lựa chọn thay thế Portainer của chúng tôi bao quát bức tranh quản lý Docker rộng hơn.
Dokploy. Kiểu PaaS. Nó có quan điểm riêng rõ ràng, tự động triển khai khi bạn push, có giao diện web cho mọi thứ, và dựng sẵn Traefik cùng đường dẫn URL gọn gàng ngay từ đầu. Hợp hơn với những nhóm muốn cảm giác Heroku và sẵn sàng đánh đổi sự linh hoạt thô của Compose. Nếu bạn dị ứng với YAML, đây là con đường nhẹ nhàng nhất tới cảnh "git push là ứng dụng lên".
GitHub Actions + SSH. Không cần thêm hạ tầng nào. Công việc triển khai nằm ngay trong workflow bạn đã có. Bạn có log của workflow, nhưng không có đối chiếu kiểu Compose, không có khôi phục khi lệch trạng thái, và không có góc nhìn thường trực về trạng thái host, trừ khi bạn tự dựng những mảnh đó. Ổn với một dịch vụ trên một host. Nó gãy ngay khi bạn thêm đích thứ hai hoặc muốn biết cái gì đang chạy ở đâu mà không phải SSH vào. Với nhóm độc giả có nhu cầu đơn giản nhất, GitHub Actions + SSH vẫn là câu trả lời đúng.
Còn có một cái tên mới hơn là stackd , tự mô tả bằng thứ ngôn ngữ tương tự: "GitOps mà không phải trả thuế Kubernetes". Đáng để biết rằng nhóm công cụ này vẫn sôi động, nhưng chưa đáng để tung đồng xu chọn nó thay cho Doco CD lúc này.
Khi nào Doco CD là lựa chọn đúng (và khi nào không)
Hãy chọn Doco CD khi:
- Bạn chạy một hoặc vài host Docker Compose và muốn lấy Git làm nguồn chân lý.
- Bạn thích sửa YAML trong trình soạn thảo hơn là bấm loanh quanh trong giao diện.
- Bạn muốn có hỗ trợ nhà cung cấp secret bên ngoài và mã hóa dựa trên SOPS mà không phải tự dựng toàn bộ quy trình.
- Bạn chấp nhận một dự án chỉ có một người duy trì, chưa tới 1.0 nhưng vẫn phát triển tích cực.
Komodo. Hãy chọn nó khi bạn quản lý nhiều host và muốn kiểm soát tập trung, hoặc khi bạn cần cả build do Git điều khiển chứ không chỉ triển khai, dưới cùng một mái nhà.
Portainer (CE hoặc BE). Hãy chọn nó khi cả nhóm muốn có giao diện cho công việc container hằng ngày bên cạnh CD, tức là khi lớp giao diện mới thật sự là lý do bạn cân nhắc công cụ này.
Dokploy. Hãy chọn nó khi bạn muốn trải nghiệm triển khai kiểu PaaS và không cần kiểm soát Compose ở mức thô.
GitHub Actions + SSH. Hãy cứ dùng cách này khi chỉ có một dịch vụ trên một host và bạn không cần đối chiếu hay khôi phục khi lệch trạng thái.
Với những ai đang ở khoảng giữa hậu Watchtower và tiền Kubernetes, Doco CD là một lựa chọn nhẹ mà chắc tay. Ý tôi là: với một homelab mới hoặc một SaaS nhỏ, tôi sẽ bắt đầu bằng Doco CD chừng nào cách làm ưu tiên Git và không cần giao diện vẫn phù hợp, rồi chuyển sang Komodo khi danh mục tập trung, phân quyền và tầm nhìn toàn cụm trở thành yêu cầu bắt buộc.
Dù chọn công cụ nào, hãy chạy nó trên một Linux VPS có cấu hình vừa với khối lượng công việc Compose mà nó sẽ gánh. Linux VPS của Cloudzy là một nơi hợp lý cho việc này, mặc định có quyền root. Còn nếu muốn bỏ qua màn cài đặt bằng apt, bạn cũng có thể triển khai Docker chỉ bằng một cú nhấp từ marketplace của chúng tôi.
Marketplace của chúng tôi cũng có sẵn image một cú nhấp cho Gitea, công cụ mà Doco CD tích hợp sẵn. Ngoài ra còn có image cho Komodo nữa, và cả Portainer, phòng khi bạn thấy một trong số đó mới là thứ mình cần.
Câu hỏi thường gặp
Doco CD đã sẵn sàng cho môi trường production chưa?
Doco CD có thể dùng trong production nếu mức rủi ro của nó phù hợp với khối lượng công việc của bạn. Dự án được phát triển tích cực, nhưng vẫn dùng cách đánh phiên bản trước 1.0 và tệp CODEOWNERS giao toàn bộ dự án cho một người. Hãy ghim một bản đã kiểm chứng, thử nâng cấp trước khi triển khai, và cân nhắc một mô hình quản trị rộng hơn nếu đây là hạ tầng trọng yếu.
Quản lý nhiều host bằng Doco CD như thế nào?
Hãy dùng Docker context và đích triển khai riêng cho từng host. Một instance Doco CD có thể triển khai tới nhiều host Docker ở xa qua SSH hoặc TCP; cách chạy mỗi host một instance vẫn là một mô hình cách ly tùy chọn. Chọn Komodo nếu bạn cần danh mục tập trung, phân quyền và tầm nhìn toàn cụm.
Chế độ webhook và chế độ polling khác nhau ra sao?
Chế độ webhook triển khai gần như tức thì khi có push lên Git, nhưng đòi hỏi một cổng truy cập được từ internet, hoặc một reverse proxy đặt trước Doco CD. Chế độ polling kiểm tra repo theo lịch, nên việc triển khai chậm hơn một chút nhưng không cần mở cổng nào. Polling là mặc định đơn giản hơn; webhook đáng dùng khi bạn push thường xuyên hoặc cần vòng phản hồi nhanh.
Doco CD so với Komodo thì thế nào?
Doco CD nhẹ hơn và không có giao diện, đồng thời có thể quản lý nhiều host thông qua các Docker context từ xa. Komodo dùng một dịch vụ Core trung tâm cùng các agent Periphery, và bổ sung giao diện quản lý cụm cùng khả năng build do Git điều khiển. Chọn Doco CD để triển khai Compose không cần giao diện; chọn Komodo khi việc kiểm soát tập trung cả cụm là điều quan trọng.
Doco CD có thay thế được Watchtower không?
Với nhu cầu mà phần lớn người dùng Watchtower thật sự muốn, tức là "triển khai những gì có trong Git, mỗi khi Git thay đổi", thì có, đó đúng là việc Doco CD làm. Còn với mô hình đúng nghĩa của Watchtower, tức là dò registry rồi kéo image mỗi khi có tag mới, thì không; Doco CD được kích hoạt bởi Git chứ không phải registry. Với bất cứ thứ gì vượt quá mức dịch vụ đồ chơi, mô hình kích hoạt bằng Git là lựa chọn an toàn hơn và dễ kiểm toán hơn.
