การจัดการสภาพแวดล้อมและเวอร์ชันที่ผ่านการอนุมัติ

การทำ Deployment อัตโนมัติบน AWS

Dunieski Otano

Amazon Web Services Solutions Architect

โค้ดเดียวกัน สามสภาพแวดล้อม

• เลื่อนเวอร์ชันของ Lambda จาก staging ไปยัง prod
• อาร์ติแฟกต์เดียวกัน ไม่ต้องสร้างใหม่
• เรียก API ครั้งเดียวก็อัปเดต alias ของ prod ได้ โดยโค้ดไม่เปลี่ยนแปลง
• นี่คือแนวคิด "build once, deploy many"

เวอร์ชันที่ผ่านการอนุมัติ แยกตามบริการ

• Lambda: alias ชี้ไปยังเวอร์ชันของฟังก์ชัน
• ECR + ECS: แท็กของอิมเมจ + revision ของ task-definition
• API Gateway: stage พร้อมการ deploy
• S3: เวอร์ชันของอ็อบเจ็กต์ในบัคเก็ตที่เปิดใช้งาน versioning

การทำงานของ Lambda alias

• เวอร์ชันคือ สแนปช็อตที่เปลี่ยนแปลงไม่ได้ ของฟังก์ชัน
• alias คือ พอยน์เตอร์ที่มีชื่อ ซึ่งชี้ไปยังเวอร์ชันหนึ่ง
• อัปเดต alias เพื่อ เลื่อนระดับ เวอร์ชัน
• alias รองรับ การจัดสรรทราฟฟิกแบบถ่วงน้ำหนัก สำหรับ canary release

แท็กของ ECR และ task definition ของ ECS

• อิมเมจของ ECR เปลี่ยนแปลงไม่ได้ตาม digest
• แท็กคือ ป้ายชื่อที่เคลื่อนย้ายได้ บน digest
• task definition ของ ECS อ้างอิงด้วย image:tag หรือ @digest
• สำหรับ production ให้ ระบุตาม digest เพื่อล็อกบิตที่แน่นอน

stage ของ API Gateway แบบสั้นๆ

• stage คือ การ deploy ของ API
• แต่ละ stage มี URL และ ประวัติการ deploy ของตัวเอง
• เลื่อนระดับด้วยการ deploy API ไปยัง stage ถัดไป
• ตัวแปรของ stage เก็บ ค่ารันไทม์เฉพาะของแต่ละสภาพแวดล้อม

การเลื่อนระดับเวอร์ชัน

• สร้างอาร์ติแฟกต์ ครั้งเดียว
• ตรวจสอบใน dev จากนั้นเป็น staging
• อัปเดต alias หรือแท็กของ prod โดย ไม่ต้องสร้างใหม่
• อาร์ติแฟกต์เดียวกันทำงานได้ในทุกสภาพแวดล้อม

แยกการกำหนดค่าออกจากโค้ด

• โค้ดเหมือนกัน ในทุกสภาพแวดล้อม
• การกำหนดค่า เก็บความแตกต่างระหว่าง dev กับ prod
• ตัวแปรของ stage, env vars, Parameter Store, Secrets Manager
• ห้าม hardcode ค่าของสภาพแวดล้อมไว้ในอาร์ติแฟกต์

มาฝึกกันเถอะ!

การทำ Deployment อัตโนมัติบน AWS