Series ArgoCD Thực chiến #1: Kỷ nguyên GitOps – Khi Git trở thành "Chân lý tuyệt đối"

1. Tử huyệt của mô hình CI/CD truyền thống (Push Model)

Hãy tưởng tượng quy trình Deploy phổ biến mà nhiều công ty đang dùng:

1. Bạn viết code, push lên nhánh main.
2. GitLab CI/GitHub Actions nhận diện có code mới, bắt đầu chạy test, build ra Docker Image (ví dụ: afc-backend:v1.2).
3. Cuối cùng, GitLab CI chạy lệnh kubectl apply -f deployment.yaml để ép cụm Kubernetes trên server Production chạy bản cập nhật mới nhất.

Cách này gọi là mô hình Push (Đẩy). Nó có 2 điểm yếu chí mạng:

• Thảm họa bảo mật: Để GitLab CI có thể ra lệnh cho cụm K8s Production, bạn bắt buộc phải cấp cho nó một cái chìa khóa (Kubeconfig/Token) có quyền lực tối cao. Nếu hacker chiếm được GitLab, chúng chiếm luôn toàn bộ hạ tầng trạm Metro của bạn.
• Bóng ma "Configuration Drift" (Lệch cấu hình): Giả sử đêm qua lúc 2h sáng, hệ thống bị lỗi, một anh kỹ sư lén SSH thẳng vào server (hoặc dùng kubectl), gõ lệnh đổi số lượng Replicas của Nginx từ 2 lên 5 để cứu hệ thống. Lúc này, thực tế server đang chạy 5 con Nginx, nhưng cấu hình nằm trên Git vẫn ghi là 2! Sự sai lệch (Drift) này khiến những lần Deploy sau đó trở nên không thể lường trước.

2. Sự cứu rỗi mang tên GitOps và ArgoCD (Pull Model)

GitOps sinh ra để giải quyết triệt để 2 vấn đề trên bằng một nguyên tắc duy nhất: "Git là Chân lý tuyệt đối (Single Source of Truth)".

Thay vì để CI tool ở ngoài "đẩy" lệnh vào, chúng ta cài một phần mềm tên là ArgoCD nằm ngầm bên trong cụm Kubernetes. Cách hoạt động của mô hình Pull (Kéo):

1. GitLab CI vẫn build Docker Image, nhưng nhiệm vụ cuối cùng của nó chỉ là: Cập nhật file YAML trên Git Repository (đổi version ảnh từ v1.2 sang v1.3). GitLab CI hoàn toàn KHÔNG có quyền đụng vào server Production.
2. ArgoCD (đang ngồi túc trực bên trong cụm K8s) cứ mỗi 3 phút lại "nhìn" sang kho Git một lần.
3. Nó phát hiện: "Á à, bản vẽ trên Git (Desired State) yêu cầu chạy version 1.3, nhưng thực tế hệ thống (Actual State) đang chạy 1.2".
4. ArgoCD tự động giật lệnh bên trong K8s để "đồng bộ" (Sync) hệ thống cho giống hệt với Git.

3. Tại sao ArgoCD lại được giới Enterprise tôn sùng?

• Bảo mật vô đối: Cụm K8s của bạn giờ đây là một "pháo đài nội bất xuất, ngoại bất nhập". Không có bất kỳ cổng nào mở ra ngoài cho các CI tool chọc vào. Chỉ có ArgoCD nằm bên trong chủ động đi kéo dữ liệu về qua HTTPS.
• Tự động sửa sai (Self-Healing): Quay lại ví dụ anh kỹ sư lén sửa số Nginx lên 5. ArgoCD sẽ lập tức phát hiện ra sự lệch pha này (vì trên Git vẫn là 2). Nó sẽ tự động "vả" hệ thống về lại 2, ép mọi thành viên trong team phải làm đúng quy trình: Muốn sửa server thì phải sửa code trên Git và chờ ai đó Review duyệt (Pull Request)!
• Rollback trong 1 nốt nhạc: Nếu bản v1.3 bị lỗi và khiến tính năng quẹt vé bị sập, bạn chỉ cần lên Git, revert lại commit trước đó. ArgoCD sẽ lập tức kéo hệ thống trở về v1.2 một cách trơn tru, không cần phải chạy lại toàn bộ pipeline CI tốn thời gian.

Tổng kết Bài 1

GitOps không phải là một công cụ, nó là một hệ tư tưởng. Nó ép đội ngũ phát triển và vận hành phải minh bạch hóa toàn bộ hạ tầng thành dạng code (Infrastructure as Code) và lưu trữ tập trung trên Git.

ArgoCD chính là "kẻ thực thi" hoàn hảo nhất cho hệ tư tưởng đó. Nó luôn đảm bảo hệ thống thực tế (Live System) phản chiếu chính xác 100% những gì bạn định nghĩa trên kho lưu trữ.

Ở bài học đầu tiên này, chúng ta đã đả thông được tư duy. Ở Bài 2, chúng ta sẽ bắt tay vào thực hành: Cài đặt ArgoCD trực tiếp lên một cụm Kubernetes thực tế và cấu hình "cú bắt tay" đầu tiên giữa ArgoCD và một kho chứa Git (Git Repository) riêng tư để chuẩn bị Deploy các service lên đó!