1. ArgoCD là gì? Ưu và nhược điểm – Khi nào cần dùng và khi nào không nên dùng
ArgoCD vs Jenkins: Không phải Đối thủ mà là Đồng đội
Khi xây dựng một hệ thống CI/CD cho Kubernetes, một câu hỏi “Tôi đang dùng Jenkins rồi, sao phải cần thêm ArgoCD?”
Câu trả lời đơn giản là: Chúng làm hai việc khác nhau và bổ trợ cho nhau.
Đơn giản thế này:
Jenkins (Imperative – Mệnh lệnh): Giống như bạn đưa cho một người giúp việc một danh sách hướng dẫn chi tiết (Bước 1: Quyét nhà, Bước 2: Lau nhà, Bước 3: Rửa bát). Bạn chỉ đạo từng bước một.
ArgoCD (Declarative – Khai báo): Giống như bạn đưa cho một người trợ lý một bức ảnh căn phòng sạch sẽ và nói: “Tôi muốn căn phòng trông y hệt như thế này”. Bạn không quan tâm họ làm thế nào, chỉ cần kết quả cuối cùng phải đúng như ảnh.
Kết hợp cả hai, chúng ta sẽ có một quy trình tự động hóa “chuẩn” DevOps hiện đại.
ArgoCD là gì?
ArgoCD ra đời vào năm 2018 để chuyên quản lý và triển khai ứng dụng trên Kubernetes. ArgoCD là một công cụ Continuous Delivery (CD) theo triết lý GitOps, được thiết kết chuyên biệt cho Kubernetes (k8s).
Hãy tưởng tượng ArgoCD như một người giám sát (supervisor) hoặc “cảnh sát” (police officer) mẫn cán, được cài ngay bên trong cụm k8s. Nhiệm vụ duy nhất của nó là liên tục giám sát hai thứ:
- Trạng thái mong muốn (Desired State): Là “bản thiết kế” của bạn được lưu trong một repo của Git (chính là các file cấu hình – manifest – yaml).
- Trạng thái thực tế (Actual State): Là những gì đang thực sự chạy bên trong cụm k8s
Ngay khi phát hiện có sự khác biệt (gọi là “Driff hay “trôi” cấu hình), ArgoCD sẽ báo cho bạn (qua giao diện WebUI của nó) bằng trạng thái OutofSync.
Sau đó, ArgoCD (tùy bạn cài đặt) sẽ tự động sửa lại cụm k8s cho đúng với cấu hình trong Git. Nó sẽ kéo (Pull) bản thiết kế chuẩn từ Git về và áp dụng lại, đảm bảo k8s chạy đúng y hết như những gì bạn đã khai báo.
Đây chính là triết ký GitOps: Kho Git là nguồn chân lý duy nhất. ArgoCD sử dụng phương pháp GitOps để đồng bộ cấu hình Kubernetes từ kho lưu trữ Git với cơ sở hạ tầng hiện có.
Hiện nay, ArgoCD là một dự án thuộc quyền quản lý của Cloud Native Computing Foudation (CNCF).
2. So sánh “Người Xây Dựng” và “Người Giám Sát”
| 2816_7fa2d8-03> |
🚀 Jenkins (Người Xây Dựng) 2816_4a7156-70> |
🐙 Argo CD (Người Giám Sát) 2816_2e2948-3f> |
|
Vai trò: 2816_56024f-e8> |
Giống như một đội xây dựng đa năng. 2816_187eb2-75> |
Giống như một người giám sát an toàn, mẫn cán, ngồi ngay bên trong nhà máy. 2816_16b394-a9> |
|
Triết lý: 2816_6b8d27-ba> |
Mệnh lệnh (Imperative), Bạn phải chỉ đạo chi tiết: “Bước 1: |
Khai báo (Declarative), Bạn “khai báo” trạng thái mong muốn trong Git, Argo CD tự “sửa” K8s cho khớp. 2816_3fead9-8d> |
|
Cách làm: 2816_2219ab-6d> |
Đẩy (Push), Jenkins (từ bên ngoài) chủ động đẩy file config vào K8s. 2816_6e0625-7a> |
Kéo (Pull), Argo CD (từ bên trong K8s) kéo thay đổi từ Git về. 2816_f7108a-c2> |
|
Phạm vi: 2816_9c05e2-56> |
Rất rộng. Có thể build và deploy cho bất cứ đâu (VMs, Docker, K8s, mobile…). 2816_b6a48c-b7> |
Chuyên biệt (K8s-native). Nó hoạt động với mọi cụm K8s, bất kể là on-premise (như lab của chúng ta) hay trên cloud (như Azure AKS, Google GKE, Amazon EKS). 2816_992773-21> |
|
Trọng tâm: 2816_14d854-8b> |
Cực kỳ mạnh ở CI (Build, Test, Scan). 2816_3d61ea-45> |
Cực kỳ mạnh ở CD (Sync, Audit, Drift Detection). 2816_6e4035-aa> |
3. Tại sao phải dùng ArgoCD khi đã có Jenkins?|
Trong mô hình CI/CD truyền thống, Jenkins đang giữ file kubeconfig và có quyền admin để chạy kubectl apply.
Mô hình hay hoạt động, nhưng không an toàn và không “chuẩn” GitOps. ArgoCD giải quyết 3 vấn đề sau:
- Git là Nguồn Chân lý (Single Source of Truth – SSoT): Đây là khái niệm quan trọng nhất của GitOps. Hãy nghĩ về SSoT như “một bản vẽ thiết kế” (blueprint) duy nhất cho toàn bộ hệ thống.
- Ví dụ thực tế: Thay vì 10 người cùng sửa 10 bản copy khác nhau của một file Word, cả nhóm thống nhất chỉ làm việc trên một file Google Doc duy nhất. Mọi thay đổi, mọi bình luận, đều diễn ra ở đó. File Google Doc đó chính là Nguồn chân lý.
- Trong GitOps: Repo Git chứa file yaml chính là nguồn chân lý. Nếu muốn thay đổi (ví dụ: nâng cấp từ 3 lên 5 replica), bạn không chạy
kubectl edit(thay đổi bản gi cục bộ), mà bạn tạo một Pull Request (đề xuất thay đổi bản vẽ thiết kế) - Phát hiện “Trôi” (Driff) và Tự chữa lành: Nếu có ai đó vào Rancher và sửa một
Deployment, ArgoCD sẽ phát hiện (báo “OutOfSync”) và (nếu bạn bật) tự động sửa lại k8s cho khớp với code trong Git. - Bảo mật (Tách biệt vai trò): Jenkins không cần giữ (biết)
kubeconfigcủa k8s nữa. Việc của Jenkins giờ chỉ là build image và push code lên một repo Git thứ hai.
Chỉ ArgoCD mới có quyền thay đổi k8s.
4. Workflow chuẩn: Jenkins (CI) + ArgoCD (CD)

Đây là mô hình nâng cấp chuẩn mà chúng ta hướng tới.
- Developer: Push code app lên Github hoặc Gitlab.
- Jenkins (CI): Tự động build, test, push image
- Jenkins (CI): Hoàn thành vai trò CI, checkout một repo khác (repo GitOps) và chỉ sửa 1 dòng
image:...latestthànhimage:....v1.1.0rồi push lên. - ArgoCD (CD): Đang theo dõi repo GitOps. Nó thấy có commit mới (image tag đã đổi).
- ArgoCD (CD): Tự động kéo (pull) file YAML mới và
applyvà Kubernetes để hoàn tất công việc
4. Khi nào không cần ArgoCD
- Khi không sử dụng kubernetes
- Khi lab của bạn cực kỳ nhỏ (1-2 app) và bạn thấy thoải mái với việc
kubectl applybằng tay hoặc jenkins
Đối với một hệ thống production (hoặc một lab phức tạp) đang phát triển, việc tích hợp ArgoCD là bước tiếp theo rất hợp lý.