Sync Waves และ Sync Phases ควบคุมลำดับการ Deploy ใน Argo CD

Categories

Sync Waves คืออะไร

Sync Waves เป็นกลไกใน Argo CD ที่ใช้ควบคุมลำดับการ deploy ของ resources ต่างๆ โดยแต่ละ resource สามารถกำหนด annotation ชื่อ argocd.argoproj.io/sync-wave เพื่อระบุลำดับการ deploy ได้

วิธีการทำงานของ Sync Waves นั้นง่ายมาก Argo CD จะจัดเรียง resources ตามค่า wave number และทำการ deploy ทีละ wave โดยรอให้ resources ในแต่ละ wave มีสถานะ Healthy ก่อนที่จะไปยัง wave ถัดไป

ค่า Wave Number

Wave number สามารถเป็นค่าจำนวนเต็มใดก็ได้ (positive, negative หรือ 0) ค่าที่ต่ำกว่าจะถูก deploy ก่อน ส่วนค่าที่สูงกว่าจะถูก deploy ทีหลัง Resources ที่ไม่มี annotation นี้จะถูกถือว่ามี wave number เป็น 0

Sync Phases คืออะไร

Sync Phases เป็นขั้นตอนต่างๆ ที่เกิดขึ้นระหว่างกระบวนการ sync ใน Argo CD มี 4 phases หลัก ได้แก่ PreSync, Sync, PostSync และ SyncFail

PreSync Phase

Phase นี้เกิดขึ้นก่อน sync ครั้งจริง มักใช้สำหรับการเตรียมข้อมูล เช่น database migration, backup ข้อมูลเก่า หรือการตั้งค่า dependencies ที่จำเป็น

Sync Phase

Phase หลักที่ Argo CD ทำการ deploy resources ตามปกติ Resources จะถูก apply ให้ cluster โดยใช้ kubectl

PostSync Phase

Phase ที่เกิดขึ้นหลังจาก sync เสร็จสิ้น มักใช้สำหรับการตรวจสอบ health check หรือการส่ง notification ให้ team

SyncFail Phase

Phase นี้จะทำงานเมื่อ sync ล้มเหลว มักใช้สำหรับการ rollback หรือแจ้งเตือน incident response team

Sync Waves และ Sync Phases ทำงานร่วมกันอย่างไร

Sync Waves ช่วยในการจัดลำดับ deployment ของ resources ต่างๆ ส่วน Sync Phases ช่วยในการกำหนดประเภทของ task ที่ต้องทำ

ลำดับการทำงาน:

  1. Argo CD เริ่ม PreSync phase – รันคำสั่ง hook หรือ jobs ที่ต้อง run ก่อน sync
  2. ทำการ deploy resources ในลำดับ wave ต่อไปนี้ – wave -1, 0, 1, 2 เป็นต้น
  3. รอให้ resources ในแต่ละ wave มี healthy status ก่อน deploy wave ถัดไป
  4. Argo CD เริ่ม PostSync phase – รันคำสั่ง verification หรือ notification tasks
  5. ถ้า error เกิดขึ้นในระหว่าง sync จะ trigger SyncFail phase

ตัวอย่างการใช้งาน: Database Migration ก่อน Application Deploy

มาดูตัวอย่างจริง สมมติว่าเรามี application ที่มี database migration เราต้องทำให้แน่ใจว่า migration สำเร็จก่อนที่ application จะ start ขึ้นมา

YAML สำหรับ Database Migration Job

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration
  annotations:
    argocd.argoproj.io/sync-wave: "0"
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
      - name: migration
        image: myapp:v1.0
        command: ["./migrate.sh"]
        env:
        - name: DB_HOST
          value: "postgres.default.svc.cluster.local"
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: username
      restartPolicy: Never
  backoffLimit: 3

YAML สำหรับ Application Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  annotations:
    argocd.argoproj.io/sync-wave: "1"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: myapp:v1.0
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5

ในตัวอย่างนี้ Database Migration Job มี sync-wave: 0 ส่วน Application Deployment มี sync-wave: 1 ซึ่งหมายความว่า migration จะ run ก่อน deployment ของ application

ตัวอย่างที่ 2: ConfigMap ก่อน Service Deploy

ConfigMap ด้วย sync-wave 0

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  annotations:
    argocd.argoproj.io/sync-wave: "0"
data:
  app.properties: |
    server.port=8080
    database.url=jdbc:postgresql://postgres:5432/mydb
    cache.ttl=3600

Service ด้วย sync-wave 1

apiVersion: v1
kind: Service
metadata:
  name: myapp
  annotations:
    argocd.argoproj.io/sync-wave: "1"
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: ClusterIP

Hook Delete Policies

Hook delete policy กำหนดว่า resources ที่ใช้เป็น hook (เช่น migration job) จะถูกลบออกหรือเก็บไว้เมื่อ sync สำเร็จ

HookSucceeded – ลบ hook resource ทันทีเมื่อมีสถานะ Succeeded เหมาะสำหรับ migration jobs ที่ไม่ต้องการเก็บ history

HookFailed – ลบ hook resource เมื่อมีสถานะ Failed

BeforeHookCreation – ลบ hook resource เมื่อมีการสร้าง hook ใหม่ ลบเวอร์ชันเก่าก่อนสร้างเวอร์ชันใหม่

การใช้งาน PreSync, Sync, และ PostSync ร่วมกัน

PreSync Hook – Database Backup

apiVersion: batch/v1
kind: Job
metadata:
  name: backup-database
  annotations:
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/sync-wave: "-1"
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
      - name: backup
        image: postgres:15
        command:
        - sh
        - -c
        - |
          pg_dump -h postgres -U dbuser mydb > /backup/db-backup-$(date +%s).sql
      restartPolicy: Never

PostSync Hook – Health Verification

apiVersion: batch/v1
kind: Job
metadata:
  name: health-check
  annotations:
    argocd.argoproj.io/hook: PostSync
    argocd.argoproj.io/sync-wave: "100"
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
      - name: health-check
        image: curlimages/curl:latest
        command:
        - sh
        - -c
        - |
          for i in $(seq 1 30); do
            curl -f http://myapp:80/health && exit 0
            sleep 2
          done
          exit 1
      restartPolicy: Never

การ Debug ปัญหา Sync Order

ดูข้อมูล Sync ผ่าน Argo CD UI

ไปที่ Argo CD dashboard และเลือก application ที่สนใจ สามารถเห็น resource graph ซึ่งแสดงลำดับการ deploy และ sync status

ใช้ kubectl describe

# ดูรายละเอียดของ resource
kubectl describe pod myapp-5d9f8c7b5-xxxxx -n default
# ดูเหตุการณ์
kubectl get events -n default | grep myapp

ดู Argo CD Logs

# ดู logs ของ application controller
kubectl logs -n argocd deployment/argocd-application-controller -f | grep myapp

Best Practices สำหรับ Sync Waves และ Phases

1. ใช้ Wave Numbers ที่เหมาะสม – แนะนำให้ใช้ negative numbers สำหรับ PreSync (เช่น -1, -2) ใช้ 0 สำหรับ resource หลัก และใช้ positive numbers สำหรับ PostSync (เช่น 100, 200)

2. ตั้งค่า Health Checks ให้ถูกต้อง – ควรตั้งค่า readinessProbe และ livenessProbe ให้ถูกต้อง เพื่อให้ Argo CD สามารถรู้ว่า resource พร้อมใช้งานแล้วหรือไม่

3. ใช้ Hook Delete Policy อย่างสมควร – ใช้ HookSucceeded สำหรับ jobs ที่ต้องการเก็บความสะอาด แต่อาจต้องเก็บ job สำหรับการ debug ถ้าจำเป็น

4. ทดสอบ Sync ในสภาพแวดล้อมที่ปลอดภัย – ควรทดสอบลำดับการ deploy ในสภาพแวดล้อม dev หรือ staging ก่อนนำไปใช้ใน production

5. ทำ Documentation ให้ชัดเจน – ควรเขียน comment ในไฟล์ YAML เพื่อให้เห็นชัดว่าทำไมถึงใช้ wave number นี้

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

หากคุณใช้ ผู้ให้บริการโฮสติ้ง Cloud VPS สามารถติดตั้ง Kubernetes cluster บน VPS เพื่อใช้งาน Argo CD ได้อย่างเต็มที่ ผู้ให้บริการโฮสติ้ง Cloud VPS มอบความยืดหยุ่นและประสิทธิภาพสูง ซึ่งเหมาะสำหรับการรัน Kubernetes cluster แบบ production-grade

ข้อดีของการใช้ ผู้ให้บริการโฮสติ้ง Cloud VPS

  • ความปลอดภัยระดับสูง – มี DDoS protection และ firewall
  • อัพสเกลได้ง่าย – เพิ่มลบ resources ได้ตามต้องการ
  • Support ที่ดี – ทีม support พร้อมช่วยเหลือ 24/7
  • ราคาที่แข่งขันได้ – มี package ที่เหมาะสำหรับต่างระดับความต้องการ

สรุป

Sync Waves และ Sync Phases เป็นคุณลักษณะที่มีประสิทธิภาพใน Argo CD ช่วยให้เราสามารถควบคุมลำดับการ deploy และเลือกประเภทของ task ที่ต้องทำ การใช้ features เหล่านี้อย่างถูกต้องจะช่วยให้กระบวนการ deployment เป็นไปอย่างเรียบร้อยและลดปัญหาจากการ deploy ที่ผิดลำดับ

หากต้องการรันสภาพแวดล้อม Kubernetes ที่มั่นคงและเสถียร โปรดพิจารณา ผู้ให้บริการโฮสติ้ง Cloud VPS สำหรับความปลอดภัยและประสิทธิภาพสูง