จัดโครงสร้าง Git Repository สำหรับ Argo CD แบบ Monorepo และ Multi-repo

Categories

จัดโครงสร้าง Git Repository สำหรับ Argo CD แบบ Monorepo และ Multi-repo

เมื่อใช้ Argo CD สำหรับจัดการ Kubernetes deployments ในสภาพแวดล้อม production หนึ่งในสิ่งที่สำคัญที่สุดคือการออกแบบโครงสร้าง Git Repository ให้เหมาะสม เพราะมันจะส่งผลกระทบต่อการจัดการ configurations, collaboration, และการ scale ของ DevOps workflows

บทความนี้จะนำเสนอเทคนิคการจัดโครงสร้าง Git Repository สองแบบที่นิยมใช้กับ Argo CD ได้แก่ Monorepo และ Multi-repo พร้อมตัวอย่างปฏิบัติ ข้อดี-ข้อเสีย และบทบาทของ ApplicationSet สำหรับการจัดการหลาย repositories

Monorepo Strategy: ทุกอย่างใน Repository เดียว

Monorepo คือการจัดเก็บ configurations และ manifests สำหรับ applications หลายตัวใน Git repository เดียว ซึ่งให้ความสะดวกในการบำรุงรักษาและจัดการ version control ที่เป็นส่วนกลาง

โครงสร้าง Monorepo แบบพื้นฐาน

argocd-monorepo/
├── apps/
│   ├── frontend/
│   │   ├── kustomization.yaml
│   │   └── deployment.yaml
│   ├── backend/
│   │   ├── kustomization.yaml
│   │   └── service.yaml
│   └── database/
│       ├── kustomization.yaml
│       └── statefulset.yaml
├── environments/
│   ├── dev/
│   │   ├── namespace.yaml
│   │   └── kustomization.yaml
│   ├── staging/
│   │   ├── namespace.yaml
│   │   └── kustomization.yaml
│   └── production/
│       ├── namespace.yaml
│       └── kustomization.yaml
├── clusters/
│   ├── cluster-1/
│   │   └── config.yaml
│   └── cluster-2/
│       └── config.yaml
└── argocd-apps/
    ├── frontend-app.yaml
    ├── backend-app.yaml
    └── database-app.yaml

ตัวอย่าง Argo CD Application สำหรับ Monorepo

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: frontend-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/company/argocd-monorepo
    targetRevision: HEAD
    path: apps/frontend
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

ข้อดีของ Monorepo

  • การจัดการ version control เป็นส่วนกลาง – ทุก applications มี version history เดียวกัน ทำให้ tracking changes ง่ายขึ้น
  • Atomic commits – สามารถ update multiple applications พร้อมกันในคำสั่ง commit เดียว
  • Code sharing – สามารถแบ่งปัน scripts, templates, หรือ base configurations ได้ง่ายขึ้น
  • Simplified branching strategy – ไม่ต้องจัดการ branches หลายตัวในหลาย repositories

ข้อเสียของ Monorepo

  • Repository size – repository จะใหญ่ขึ้นเมื่อมี applications เยอะ ส่งผลต่อ clone time
  • Merge conflicts – หลาย teams ทำงานกับไฟล์เดียวกันอาจเกิด conflicts บ่อยขึ้น
  • Access control ยุ่งยาก – ยากต่อการให้สิทธิ์เฉพาะส่วนของ applications บางตัว

Multi-repo Strategy: แยก Repository สำหรับแต่ละ Application

Multi-repo คือการแยก configurations สำหรับแต่ละ application หรือ team ไปยัง repositories ต่างๆ อย่างเป็นอิสระ ซึ่งมีความยืดหยุ่นและ scalability ที่สูง

โครงสร้าง Multi-repo

Organization/
├── argocd-config/  (Central repository)
│   ├── AppProject definitions
│   ├── RBAC policies
│   └── argocd-apps/
│       ├── frontend-app.yaml
│       ├── backend-app.yaml
│       └── database-app.yaml
│
├── frontend-gitops/  (Frontend team)
│   ├── environments/
│   │   ├── dev/
│   │   ├── staging/
│   │   └── production/
│   └── kustomization.yaml
│
├── backend-gitops/  (Backend team)
│   ├── environments/
│   │   ├── dev/
│   │   ├── staging/
│   │   └── production/
│   └── kustomization.yaml
│
└── database-gitops/  (Database team)
    ├── environments/
    ├── kustomization.yaml
    └── helm-values/

ตัวอย่าง Application สำหรับ Multi-repo

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: frontend-app
  namespace: argocd
spec:
  project: frontend-team
  source:
    repoURL: https://github.com/company/frontend-gitops
    targetRevision: main
    path: environments/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

ข้อดีของ Multi-repo

  • Team independence – แต่ละ team สามารถจัดการ repository ของตัวเองได้อย่างเป็นอิสระ
  • Granular access control – ควบคุมสิทธิ์เข้าถึง per repository ได้อย่างละเอียด
  • Smaller repositories – repositories มีขนาดเล็ก ทำให้ clone และ operations เร็วขึ้น
  • Clear separation of concerns – แต่ละ application มี responsibility ชัดเจน
  • Fewer merge conflicts – ไม่ต้องแบ่งปันไฟล์ configurations กัน

ข้อเสียของ Multi-repo

  • Repository management complexity – ต้องจัดการหลาย repositories ทำให้ซับซ้อนขึ้น
  • Distributed version history – ยากต่อการติดตาม changes ที่เกี่ยวข้องกันหลาย repositories
  • Code duplication – อาจต้องคัดลอก base configurations หลายครั้งข้าม repositories

ApplicationSet สำหรับ Multi-repo Management

เมื่อใช้ Multi-repo pattern ขนาดใหญ่ ApplicationSet คือโซลูชันที่ช่วยให้จัดการหลาย Applications ได้อัตโนมัติ แทนการสร้าง Application manifests ทีละตัว

ตัวอย่าง ApplicationSet สำหรับ Multi-repo

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: multi-app-set
  namespace: argocd
spec:
  generators:
  - git:
      repoURL: https://github.com/company/argocd-config
      revision: HEAD
      directories:
      - path: "app-configs/*"
  template:
    metadata:
      name: '{{path.basename}}'
    spec:
      project: default
      source:
        repoURL: 'https://github.com/company/{{path.basename}}-gitops'
        targetRevision: main
        path: environments/production
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{path.basename}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

ApplicationSet นี้จะสแกน directory ใน argocd-config repository และสร้าง Applications สำหรับแต่ละ app โดยอัตโนมัติ ทำให้การจัดการหลาย repositories กลายเป็นเรื่องง่ายขึ้น

เปรียบเทียบ Monorepo vs Multi-repo

เกณฑ์ Monorepo Multi-repo
Team Independence ต่ำ – ต้องประสานงานกัน สูง – เป็นอิสระ
Repository Size ใหญ่ – อาจช้า เล็ก – เร็ว
Merge Conflicts บ่อยขึ้น ไม่บ่อยนัก
Access Control ยุ่งยาก ง่าย – ต่อ repository
Code Sharing ง่าย ต้องใช้ shared repositories
Atomic Updates ง่าย – single commit ยากขึ้น

เลือกใช้ Monorepo หรือ Multi-repo เมื่อไร

ใช้ Monorepo เมื่อ:

  • มีจำนวน applications ไม่มาก (น้อยกว่า 10 ตัว) และมีความเกี่ยวข้องกันสูง
  • ต้องการ atomic updates ข้ามหลาย applications
  • มี single team หรือ teams ที่ทำงานใกล้ชิดกัน
  • ต้องการการแบ่งปัน base configurations หลาย applications

ใช้ Multi-repo เมื่อ:

  • มี applications จำนวนมาก และไม่เกี่ยวข้องกันมากนัก
  • มี multiple teams และแต่ละ team มี ownership ต่างกัน
  • ต้องการ fine-grained access control
  • ต้องการให้ teams สามารถเคลื่อนไหวได้เร็ว (fast-moving teams)

Best Practices สำหรับ Git Repository Structure

1. ใช้ Kustomize หรือ Helm เพิ่มความยืดหยุ่น

จัดเตรียม Kustomize bases หรือ Helm charts สำหรับสภาพแวดล้อมต่างๆ (dev, staging, production) เพื่อหลีกเลี่ยง YAML duplication

2. กำหนด GitOps Conventions

กำหนดชื่อ repository, branch naming, directory structure ให้มีความสอดคล้องกันทั้งองค์กร เพื่อให้ teams ใหม่เข้าใจง่ายขึ้น

3. ใช้ App of Apps Pattern

สำหรับ Monorepo ขนาดใหญ่ ให้ใช้ “app of apps” pattern – สร้าง Application หนึ่งตัวที่จัดการ Applications อื่นๆ

4. ควบคุม Secrets ให้ปลอดภัย

ไม่ควร commit secrets ไปยัง Git repositories ให้ใช้ sealed-secrets หรือ External Secrets Operator แทน

5. ตั้งค่า RBAC อย่างเหมาะสม

สำหรับ Multi-repo pattern ให้สร้าง AppProject ต่างๆ และมอบสิทธิ์ RBAC ให้กับ teams อย่างเหมาะสม

ปรับใช้ Argo CD บน ผู้ให้บริการโฮสติ้ง Cloud VPS

เพื่อให้ Argo CD ทำงานได้อย่างเต็มที่ คุณจะต้องมี infrastructure ที่สม่ำเสมอและเชื่อถือได้ ผู้ให้บริการโฮสติ้ง Cloud VPS นำเสนอโซลูชัน cloud infrastructure ที่เหมาะสมสำหรับการ deploy Kubernetes clusters และ Argo CD ด้วยบริการที่มั่นคง เร็ว และสามารถสเกลได้ตามความต้องการ

ด้วยแพลตฟอร์ม Cloud VPS ของ DE คุณสามารถ:

  • ตั้งค่า Kubernetes clusters หลายตัวข้ามหลาย regions
  • มั่นใจความพร้อมใช้งานสูง (High Availability) สำหรับ Argo CD server
  • ควบคุม resources อย่างมีประสิทธิภาพเพื่อเพิ่มประสิทธิภาพการ sync ของ Argo CD
  • บูรณาการกับระบบ monitoring และ logging ได้อย่างสมบูรณ์

สรุป

การเลือกระหว่าง Monorepo และ Multi-repo strategy นั้นขึ้นอยู่กับความต้องการและขนาดขององค์กร:

  • Monorepo เหมาะสำหรับ teams ขนาดเล็ก applications ที่มีความเกี่ยวข้องกัน และต้องการการแบ่งปันรหัสและการอัปเดตแบบ atomic
  • Multi-repo เหมาะสำหรับองค์กรใหญ่ที่มี teams หลายตัว applications จำนวนมาก และต้องการความเป็นอิสระของ teams
  • Hybrid approach มักเป็นตัวเลือกที่เหมาะสมที่สุดในทางปฏิบัติ

บริการ Cloud VPS ของ ผู้ให้บริการโฮสติ้ง พร้อมที่จะสนับสนุนการปรับใช้ Argo CD ของคุณในแบบที่ปลอดภัย เร็ว และสามารถจัดการได้