Automating Deployment with GitHub Actions: แนวทางจัดการ CI/CD
เรียนรู้วิธีตั้งค่า CI/CD อัตโนมัติบน GitHub Actions และ AWS โดยไม่ต้องเปิดพอร์ต SSH หรือเก็บ AWS Access Keys ถาวร
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- หลีกเลี่ยงการเปิดพอร์ต 22 หรือเก็บ Static AWS Keys ใน GitHub Secrets
- ใช้ IAM OIDC แลกรับ Temporary Credentials อายุ 1 ชั่วโมงแทน
- สั่งการ EC2 ใน Private Subnet (10.0.10.0/24) ผ่าน AWS Systems Manager (SSM)
- จัดการ Docker Compose stack 4 บริการพร้อม health check ป้องกันข้อผิดพลาด
การเปลี่ยนโค้ดแบบเดิมที่ต้องมานั่งล็อกอิน รีโมท และบิวด์ Docker image ด้วยมือทีละตัว กลายเป็นเรื่องน่าเบื่อและเสี่ยงต่อความผิดพลาด บทความนี้จะพาทุกท่านไปดูแนวทางการทำ Automating Deployment ให้ครบวงจร ตั้งแต่การเขียนโค้ด เทสต์ คอนเทนเนอร์ไรเซชัน จนถึงการดีพอยต์ขึ้นเซิร์ฟเวอร์แบบอัตโนมัติทุกครั้งที่มีการ push โค้ด
จากสถาปัตยกรรมเดิมที่เราเคยตั้งค่าโครงสร้างเครือข่ายและทรัพยากรบน AWS EC2 instance ซึ่งถูกวางไว้ใน Private Subnet (10.0.10.0/24) เพื่อความปลอดภัย โดยมี Application Load Balancer คอยรับทราฟฟิกจากอินเทอร์เน็ต ทำให้เกิดโจทย์ปัญหาใหญ่ 3 ข้อหลักในการทำระบบอัตโนมัติ
- ปัญหาที่ 1: เซิร์ฟเวอร์เข้าถึงไม่ได้โดยตรง ไม่มี Public IP และ GitHub Actions ไม่สามารถ SSH เข้ามาได้เนื่องจากไม่มีพอร์ต 22 เปิดไว้และไม่มี Bastion Host
- ปัญหาที่ 2: ระบบไม่ได้มีแค่คอนเทนเนอร์เดียว แต่เป็น Stack ของ Docker Compose ที่ประกอบด้วย 4 เซอร์วิสพึ่งพิงกัน ได้แก่ PostgreSQL, Backend, Frontend และ Nginx ตามลำดับ health check
- ปัญหาที่ 3: ไม่มี Access Keys สะสมค้างไว้ใน GitHub Secrets ป้องกันความเสี่ยงเรื่องคีย์รั่วไหลแล้วใช้งานได้ตลอดไปอย่างไร้วันหมดอายุ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ทางออกของปัญหาทั้งหมดนี้คือการใช้บริการ AWS 3 ตัวประกอบด้วย IAM OIDC, Systems Manager (SSM) และ Terraform โดยขั้นตอนการทำงานของ CD workflow จะเริ่มต้นจากการขอ OIDC token จาก GitHub ไปยัง AWS STS จากนั้น AWS จะตรวจสอบและคืนค่า Temporary credentials ที่มีอายุเพียง 1 ชั่วโมงให้ เพื่อใช้ AWS CLI สั่ง SSM ไปที่ EC2 รันสคริปต์ git pull และ compose up ต่อไป
การใช้ IAM OIDC แทนการเก็บ AWS_ACCESS_KEY_ID ถือเป็นแนวทางความปลอดภัยระดับมาตรฐานสากล (Zero Trust) ที่นักพัฒนาควรนำไปปรับใช้ เพราะตัดความเสี่ยงเรื่อง Static Credentials หลุดรอดไปใน Log หรือซอร์สโค้ดสาธารณะ ช่วยยกระดับความปลอดภัยให้กับคลาวด์อินฟราสตรัคเจอร์ได้อย่างมีประสิทธิภาพ
ในส่วนของกระบวนการ Continuous Integration (CI) จะทำงานทุกครั้งที่มีการ push ไปยัง branch main หรือสร้าง pull request เพื่อตรวจสอบความสมบูรณ์ของโค้ดล่วงหน้า โดยมีการรัน Docker Buildx, ติดตั้ง Node.js v20 เพื่อบิวด์ฝั่ง Frontend (Vite) รวมไปถึงการรัน Python v3.12 และตรวจสอบโค้ดด้วย Flake8 สำหรับ Backend สถาปัตยกรรมนี้ช่วยให้มั่นใจได้ว่าโค้ดที่ถูกส่งขึ้นไปจะไม่พังระหว่างทาง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น