Thiết Kế Cấu Trúc Repo GitOps Dễ Bảo Trì Với Argo CD + Kro

🧨 Khi Repository GitOps Trở Nên Hỗn Loạn

Ban đầu, tôi quản lý tất cả các file YAML bằng tay. Mọi thứ trông ổn vì chỉ có vài dịch vụ – cho đến khi không còn ổn nữa.

File YAML được thêm thẳng vào thư mục gốc
Một người tạo thư mục deploy-prod/, người khác copy thẳng từ dev rồi sửa trên prod
Không có quy tắc đặt tên hay thư mục cụ thể

Và mỗi lần thay đổi lại hỏi nhau: “Ủa, file nào đang deploy thật vậy?”

Một hôm, tôi cập nhật nhầm và bản dev lên prod. Mất cả buổi chiều rollback.

Đó là lúc tôi hiểu: Cấu trúc Git cần đủ vững để sống sót trong thực tế.

⚙️ Mục Tiêu Của Tôi

Mô hình của tôi chạy trên MicroK8s tự quản lý, dùng các công cụ:

Kro: sinh ra YAML tự động từ instance.yaml
Argo CD: đồng bộ manifest từ Git vào cluster
Kargo: phát hiện Docker tag mới và đẩy ngược vào Git

Ba mục tiêu chính:

Tách biệt rõ ràng dev và prod
Mỗi service được cập nhật độc lập
Mỗi lần deploy đều truy vết được từ Git

📦 Tại Sao Tôi Chuyển Sang ApplicationSet

Tôi từng tạo mỗi Argo CD Application bằng tay:

Phải vào UI, copy-paste, dễ sai sót
Không có mẫu cố định, dễ lộn xộn

Sau đó tôi chuyển qua dùng ApplicationSet:

Mỗi môi trường 1 ApplicationSet
Tự generate Application dựa trên folder
Dùng annotations để liên kết Kargo stage

Ba lợi ích chính:

Không phải tạo Application bằng tay
Kết hợp với instance.yaml để auto deploy
Có thể liên kết service với stage cụ thể qua annotation

🗂 Cấu Trúc Repo Git Của Tôi

project/
├── argo-applications/
│   ├── develop-applicationset.yaml
│   └── production-applicationset.yaml
├── develop/
│   ├── frontend/
│   │   └── instance.yaml
│   └── backend/
│       └── instance.yaml
└── production/
    └── frontend/
        └── instance.yaml

Lưu ý:

RGD không lưu vào Git, mà quản lý tại platform Kro

✍️ Ví Dụ Thật develop-applicationset.yaml

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: develop-applicationset
  namespace: argocd
spec:
  generators:
    - git:
        repoURL: https://gitlab.com/your-name/your-repo.git
        revision: HEAD
        directories:
          - path: develop/*
  template:
    metadata:
      name: '{{path.basename}}-dev-app'
      annotations:
        kargo.akuity.io/authorized-stage: develop:{{path.basename}}-dev-stage
    spec:
      project: develop
      source:
        repoURL: https://gitlab.com/your-name/your-repo.git
        targetRevision: HEAD
        path: '{{path}}'
        directory:
          recurse: true
      destination:
        server: https://kubernetes.default.svc
        namespace: develop
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

👉 Tạo thư mục develop/backend/ là sẽ tự sinh Application backend-dev-app.

🌳 Cách Tôi Quản Lý Root App

Tôi không lưu root Application trong Git.

Tôi tạo nó 1 lần duy nhất trên UI ArgoCD, nó chỉ làm nhiệm vụ trỏ tới argo-applications/.

🧼 Tách Biệt Service và Môi Trường

Mỗi namespace Kubernetes:
- 1 Argo CD Project
- 1 ApplicationSet
- 1 Kargo Project
instance.yaml nằm trong thư mục ứng với môi trường

RGD dùng chung, nhưng giá trị thì khác nhau giữa dev và prod.

🛠 Lợi Ích Trong Công Việc Hàng Ngày

Xem cấu hình → vào folder tương ứng
Xem thay đổi → git log instance.yaml
Tạo dịch vụ mới → tạo folder + 1 file instance.yaml là xong

✅ `instance.yaml` Là Nguồn Duy Nhất

Lưu trong Git
ArgoCD tự sync
Kargo cập nhật tag Docker vào Git qua yaml-update

Một file duy nhất là trung tâm mọi thay đổi.

🧱 Đây Là Nền Tảng Cho Việc Promotion

Nếu không có cấu trúc thống nhất, Kargo không thể tự động hóa.

Dòng chảy:

Docker Tag → Freight → Update instance.yaml → Argo CD Sync → Kro Apply

Mọi thứ bắt đầu từ cấu trúc Git vững chắc.

🔜 Tiếp Theo: Tự Động Hóa Promotion Với Kargo

Ở phần tiếp theo, tôi sẽ chia sẻ:

Promotion từ image tag → instance.yaml → Kro như thế nào
Làm sao liên kết service với đúng Kargo Stage
Annotations trong ApplicationSet hỗ trợ nhắm mục tiêu chính xác

Nếu bạn đang thiết kế GitOps hoặc quản lý nhiều môi trường – bạn sẽ muốn xem tiếp phần 4.