วิธีตั้งค่า GitLab CI/CD พร้อม Kubernetes สำหรับ Deployment Blue‑Green อย่างปลอดภัย

ภาพรวม — Overview

การทำ Deployment แบบ Blue‑Green บน Kubernetes ด้วย GitLab CI/CD ช่วยให้เราปล่อยฟีเจอร์ใหม่ได้โดยไม่มีเวลาหยุดทำงานของระบบ (Zero‑Downtime) และลดความเสี่ยงจากข้อผิดพลาดที่อาจเกิดขึ้นในขั้นตอนปล่อยเวอร์ชันใหม่ บทความนี้จะสอนวิธีตั้งค่า Pipeline ที่ปลอดภัยและเชื่อถือได้

เตรียมสภาพแวดล้อม — Setup

ก่อนเริ่มเขียน CI/CD pipeline เราต้องมีสิ่งต่อไปนี้พร้อมใช้งาน

• คลัสเตอร์ Kubernetes ที่รองรับการสร้าง Service แบบ LoadBalancer หรือ Ingress
• GitLab Runner ที่ติดตั้งบน Docker หรือ VM และสามารถเข้าถึง API ของ Kubernetes ได้
• Namespace, Deployment, Service สำหรับแอปพลิเคชันที่ต้องทำ Blue‑Green

**Tip: ควรใช้ Service Account ที่มีสิทธิ์จำกัด (RBAC) เพียงพอสำหรับการสร้าง/ลบ Deployments และ Services เท่านั้น

แนวคิดของ Blue‑Green Deployment — Concept

Blue‑Green คือการมีสภาพแวดล้อมสองชุดพร้อมทำงานพร้อมกัน

• Blue = เวอร์ชันปัจจุบันที่กำลังให้บริการผู้ใช้
• Green = เวอร์ชันใหม่ที่จะทดสอบและเปลี่ยนเส้นทางทราฟิกเมื่อพร้อม

ขั้นตอนหลักคือ

• Deploy เวอร์ชัน Green ไปยังคลัสเตอร์โดยไม่กระทบ Blue
• ตรวจสอบสุขภาพ (Health Check) ของ Green ผ่าน Readiness Probes และ Liveness Probes
• สลับ Service หรือ Ingress ให้ชี้ไปที่ Green
• ถ้าเกิดปัญหาให้ย้อนกลับไปใช้ Blue ได้ทันที

ออกแบบไฟล์ `.gitlab-ci.yml` — CI/CD Pipeline

ขั้นตอนแรก: กำหนด Stage

```yaml stages:

• build
• test
• deploy_green
• switch_traffic
• cleanup

```

• build สร้าง Docker Image และอัปโหลดไปยัง Registry
• test รัน Unit Test / Integration Test บน Image ที่สร้างขึ้น
• deploy_green ใช้ `kubectl` หรือ Helm Deploy Green เวอร์ชันใหม่
• switch_traffic สลับ Service ไปที่ Green หลังจากตรวจสอบสุขภาพสำเร็จ
• cleanup ลบ Blue เวอร์ชันเก่าหากต้องการ

ขั้นตอนที่ 2: สร้าง Image

```yaml build_job: stage: build script:

• docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
• docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

```

• ใช้ตัวแปร `$CI_COMMIT_SHA` เพื่อทำให้ Tag เป็นเอกลักษณ์ของแต่ละคอมมิต

ขั้นตอนที่ 3: Deploy Green

```yaml deploy_green_job: stage: deploy_green script:

• export KUBECONFIG=$KUBE_CONFIG
• kubectl set image deployment/my-app my-container=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --record
• kubectl rollout status deployment/my-app

```

• คำสั่ง `set image` จะอัปเดต Deployment ชื่อ `my-app-green` (ต้องตั้งชื่อแยกจาก Blue)
• ใช้ `--record` เพื่อบันทึกประวัติการเปลี่ยนแปลงใน Kubernetes

ขั้นตอนที่ 4: ตรวจสอบสุขภาพ

```yaml health_check_job: stage: switch_traffic script:

• export KUBECONFIG=$KUBE_CONFIG
• |

if kubectl get pods -l app=my-app-green -o jsonpath='{.items[*].status.containerStatuses[0].ready}' | grep false; then echo "Green pods not ready" exit 1 fi ```

• ถ้า Pods ของ Green ไม่พร้อม ระบบจะหยุด pipeline ก่อนขั้นตอนสลับทราฟิก

ขั้นตอนที่ 5: สลับ Traffic

```yaml switch_traffic_job: stage: switch_traffic script:

• export KUBECONFIG=$KUBE_CONFIG
• kubectl patch service my-app-service -p '{"spec":{"selector":{"appmy-app-green"}}}'

```

• การแก้ไข `selector` ของ Service ทำให้ผู้ใช้ทั้งหมดเริ่มรับทราฟิกจาก Green ทันที

ขั้นตอนที่ 6: Cleanup (เลือกทำ)

```yaml cleanup_job: stage: cleanup when: manual # ให้ผู้ดูแลยืนยันก่อนลบ Blue script:

• export KUBECONFIG=$KUBE_CONFIG
• kubectl delete deployment my-app-blue

```

• คำสั่ง `when: manual` ทำให้ขั้นตอนนี้ต้องกดปุ่มบน GitLab UI ก่อนดำเนินการ

**Tip: หากต้องการย้อนกลับเร็ว ๆ นี้ ให้เก็บไฟล์ Manifest ของ Blue ไว้ใน Repository เพื่อทำ Rollback ด้วย `kubectl apply -f blue.yaml`

การตรวจสอบและมอนิเตอร์ — Monitoring

การตั้งค่า CI/CD เพียงอย่างเดียวไม่พอ ต้องมีระบบมอนิเตอร์เพื่อรับรู้สถานะจริงของแอปพลิเคชัน

• ใช้ Prometheus รวบรวมเมตริกส์จาก Pods ทั้ง Blue และ Green
• ตั้ง Alertmanager ให้ส่งการแจ้งเตือนเมื่อ `readyReplicas` ของ Green ต่ำกว่า 100 % เป็นเวลาต่อเนื่องเกิน 2 นาที
• เชื่อมต่อ Grafana Dashboard เพื่อดูกราฟเปรียบเทียบ Latency, Error Rate ระหว่างสองเวอร์ชัน

การเปรียบเทียบ Blue‑Green กับ Rolling Update — Comparison Table

แนวทางปฏิบัติที่ดีที่สุด — Best Practices

• เก็บ Manifest ของ Blue และ Green แยกไฟล์ (`blue.yaml`, `green.yaml`) ในโฟลเดอร์ `k8s/` เพื่อความชัดเจน
• ใช้ Helm Chart พร้อมค่า `values-green.yaml` / `values-blue.yaml` ทำให้การสลับค่าต่าง ๆ เป็นเรื่องง่ายโดยไม่ต้องแก้ไฟล์หลายไฟล์
• ตั้งค่า Readiness Probe ที่ตรวจสอบ endpoint จริงของแอป (เช่น `/healthz`) เพื่อหลีกเลี่ยงกรณี Pods ถูกบ่งชี้ว่า Ready แต่ยังทำงานผิดพลาดอยู่
• เปิดใช้ PodDisruptionBudget เพื่อให้ Kubernetes รักษาจำนวน Replicas ขั้นต่ำขณะทำการสลับหรืออัปเดต

**Tip: ควรทดสอบ Pipeline บนคลัสเตอร์ Staging ก่อน Deploy ไป Production ทุกครั้ง เพื่อลดโอกาสเกิดข้อผิดพลาดที่ไม่คาดคิด

สรุป — Summary

การตั้งค่า GitLab CI/CD เพื่อทำ Blue‑Green Deployment บน Kubernetes ให้ได้ผลลัพธ์ปลอดภัยและไม่มี downtime ต้องรวมขั้นตอนสำคัญต่อไปนี้

• เตรียมคลัสเตอร์, Runner, Service Account ที่มีสิทธิ์จำกัด
• ออกแบบ Pipeline ด้วย Stage: build test deploy_green health_check switch_traffic cleanup
• ใช้ `kubectl set image` หรือ Helm เพื่อ Deploy เวอร์ชัน Green โดยแยกจาก Blue อย่างชัดเจน
• ตรวจสอบสุขภาพของ Pods ก่อนสลับ Traffic ผ่าน Service selector
• ตั้งระบบ Monitoring (Prometheus, Grafana) และ Alert เพื่อติดตามสถานะจริง
• มีขั้นตอน Cleanup หรือ Rollback ที่ง่ายและเร็ว

สิ่งที่ควรจำ

• Zero‑Downtime เริ่มจากการแยกสภาพแวดล้อม Blue/Green อย่างสมบูรณ์
• ใช้ Readiness/Liveness Probes ตรวจสุขภาพก่อนให้ผู้ใช้เข้าถึงเวอร์ชันใหม่
• เก็บ Manifest ของแต่ละเวอร์ชันใน Repository เพื่อทำ Rollback ได้ทันที
• ตั้งค่า Alert และ Dashboard เพื่อตรวจจับปัญหาเร็วที่สุด

ด้วยแนวทางเหล่านี้ ทีม DevOps สามารถปล่อยฟีเจอร์ใหม่ได้อย่างมั่นใจ ลดความเสี่ยงต่อระบบ Production อย่างมีประสิทธิภาพ.