Hướng Dẫn Chuyển Đổi Toàn Diện Từ GitHub Actions sang ArgoCD theo Phương Pháp GitOps

Chuyển đổi từ một pipeline CI/CD truyền thống sử dụng GitHub Actions sang workflow GitOps với ArgoCD không đơn giản chỉ là đổi công cụ, mà là một bước chuyển đổi tư duy từ phương pháp triển khai mệnh lệnh sang mô hình khai báo (declarative). Bài viết này tổng hợp kinh nghiệm thực tế với quá trình migrataion ba lần, cung cấp hướng dẫn từng bước cách thiết lập ArgoCD chuẩn production, cấu hình đa cluster đa nhóm, cập nhật tự động image, và chiến lược rollback an toàn.

Đánh giá pipeline GitHub Actions hiện tại

Trước khi áp dụng GitOps, cần hiểu rõ pipeline hiện tại:

• Triển khai đang gắn chặt với quá trình CI, không tách biệt rõ ràng
• Cách deploy theo kiểu thực thi lệnh (imperative) bằng kubectl apply trực tiếp
• Không có cơ chế đồng bộ/trái soát trạng thái (state reconciliation)

Mục tiêu không phải sao chép y chang mà phải chuyển sang cách tiếp cận khai báo, nơi Git trở thành nguồn duy nhất xác thực trạng thái mong muốn của hệ thống.

Cài đặt ArgoCD chuẩn production với Helm

Một cài đặt ArgoCD mặc định thường thiếu các cấu hình bảo mật và giới hạn tài nguyên quan trọng. Khi deploy cho môi trường production:

• Cấu hình ingress với chứng thực và hostname cố định
• Bật Redis để cải thiện hiệu năng
• Thiết lập RBAC phân quyền theo vai trò
• Giới hạn CPU, RAM cho controller để tránh tài nguyên quá tải

Ví dụ file values.yaml cho Helm cài đặt ArgoCD với các cấu hình trên sẽ đảm bảo hệ thống ổn định và bảo mật.

Xây dựng cấu trúc kho GitOps chuẩn

Kho GitOps phải chứa các thư mục phân chia rõ ràng theo đối tượng: ứng dụng, môi trường (dev, staging, prod), hạ tầng chung. Ví dụ:

gitops-repo/
├── apps/
│   ├── payments/
│   ├── auth/
├── environments/
│   ├── dev/
│   ├── staging/
│   └── prod/
└── infrastructure/
    ├── ingress/
    └── monitoring/

Các manifest Kubernetes cho từng ứng dụng cần theo chuẩn Application của ArgoCD, định nghĩa rõ repo nguồn, namespace đích, và chính sách tự động sync.

ApplicationSet cho quản lý đa đội nhóm

Khi có nhiều nhóm phát triển và đa ứng dụng, việc tạo Application thủ công trở nên phức tạp. ApplicationSet hỗ trợ tự động hóa bằng cách sinh các Application dựa trên cấu trúc thư mục hoặc nguồn Git. Nhóm chỉ cần thêm thư mục ứng dụng, ArgoCD sẽ tự động quản lý deploy.

Migrataion dịch vụ đầu tiên với kế hoạch rollback

Bắt đầu với dịch vụ không quan trọng:

• Loại bỏ bước deploy trong pipeline GitHub Actions, chỉ giữ build và push image
• Đẩy manifest Kubernetes lên repo GitOps
• ArgoCD tự động đồng bộ trạng thái cluster với manifest mới
  Việc rollback chỉ đơn giản là revert commit trên Git, không cần can thiệp thủ công phức tạp.

Image Updater – Cầu nối giữa CI và GitOps

CI vẫn build và đẩy image mới lên registry, trong khi ArgoCD chịu trách nhiệm deploy. ArgoCD Image Updater tự động sửa manifest trong repo khi có image mới, giúp quá trình rollout image hoàn toàn tự động và không gián đoạn.

RBAC và cấu hình đa tenant

Khi có nhiều team, phân quyền chặt chẽ bằng RBAC là cần thiết:

• Định nghĩa vai trò với các quyền đọc, đồng bộ ứng dụng cụ thể
• Phân vùng namespace riêng biệt để cô lập tài nguyên
  Giúp từng nhóm thao tác độc lập mà vẫn đảm bảo tuân thủ chính sách an ninh.

Giám sát và quan sát pipeline GitOps

Để tránh GitOps thành hộp đen khó hiểu, cần bật tính năng metrics trong ArgoCD để thu thập số liệu như đồng bộ thành công, thời gian tái đồng bộ, phát hiện drift trạng thái. Kết hợp Prometheus để theo dõi và log để điều tra sự cố.

Những bài học quan trọng ít ai đề cập

• Git có thể trở thành nút thắt cổ chai nếu nhiều commit được đẩy liên tục, cần tối ưu chiến lược nhánh.
• Drift hiện tượng trạng thái cluster bị lệch khỏi Git là phổ biến, ArgoCD khắc phục nhưng không phải ngay lập tức.
• Quản lý secrets vẫn là thách thức lớn, nên tích hợp các công cụ chuyên biệt như sealed secrets.
• ApplicationSet nếu không thiết kế template kỹ lại gây hỗn loạn phức tạp.
• Vấn đề lớn nhất là con người, cần đào tạo và thay đổi tư duy để chấp nhận GitOps.

Migrating sang ArgoCD là bước chuyển toàn diện về phương pháp và công cụ, đem lại sự ổn định, minh bạch và tự tin vận hành cho hệ thống Kubernetes của tổ chức. Nhưng hành trình này đòi hỏi kỷ luật, tính kiên nhẫn, và sự sẵn sàng từ bỏ cách làm cũ lạc hậu.

---