AWS EKS Workload with CI/CD

Azure Pipeline:

Thread นี้ให้คำแนะนำเกี่ยวกับการ Deploy Private Workload บน Amazon EKS โดยใช้ Azure Pipeline การรวมกันระหว่าง Azure Pipeline และ AWS ช่วยให้สามารถ Deploy และจัดการ Kubernetes App ได้อย่างราบรื่นใน Private Environment ของ AWS

วัตถุประสงค์ของการใช้ Azure Pipeline สำหรับ Workload บน AWS คือการใช้ประโยชน์จาก Platform CI/CD ที่ทรงพลังและยืดหยุ่น ซึ่งรองรับการทำงานข้ามผู้ให้บริการ Cloud หลายราย ช่วยเพิ่มประสิทธิภาพในกระบวนการพัฒนาและ Deploy App ที่ทำงานบน AWS วิธีการนี้สอดคล้องกับหลักการของ DevOps ที่เน้นความร่วมมือ การทำงานอัตโนมัติ และการส่งมอบ Software อย่างรวดเร็ว

Thread นี้เป็นคู่มือแบบย่อสำหรับการนำ Azure Pipeline และการผสานรวมกับ AWS มาใช้งาน โดยมุ่งเน้นที่ Best Practice ด้าน CI/CD, คุณภาพของ Code และการ Deploy App บน Elastic Kubernetes Service (EKS)

ด้วยการผสานรวม Azure Pipeline กับ AWS EKS อย่างไร้รอยต่อ Solution นี้ช่วยให้งาน CI/CD เป็นไปโดยอัตโนมัติสำหรับการ Deploy ที่มีประสิทธิภาพและคุณภาพสูง นอกจากนี้ยังส่งเสริมความร่วมมือและเพิ่มประสิทธิภาพในการ Deploy บน EKS อีกด้วย



ผมจะใช้ Amazon Elastic Container Registry (ECR) แทน Docker Hub นะคับ ใช้ Free Tier น่าจะ Free สำหรับ Private Repo 500 MB, Data Transfer Out ภายใน Region เดียวกัน Free

มาเริ่มกันเลยคับ:

1. อันดับแรกสร้าง Organization ใน Azure DevOps กันก่อน:
   
   
   https://aex.dev.azure.com
   
   
2. สร้าง Project
3. ตัวอย่างนี้เราจะลองทำ Website Valentine กัน ก็ไป Import repository มา (https://github.com/goragodwiriya/valentine.git)
4. สร้าง Dockerfile (Azure DevOps จะทำ Version Control ให้เราโดยอัตโนมัติทุก File)
   
   Code:

   # ใช้ Nginx เป็น Base Image
   FROM nginx:latest
   
   # คัดลอก File HTML และ Folder ทั้งหมดไปยังตำแหน่งที่ Nginx ใช้เก็บ File
   COPY ./ /usr/share/nginx/html/
   
   # เปิด Port 80 สำหรับให้บริการ Web
   EXPOSE 80

   
   
5. ทำ Pipeline CI Push ไป AWS ECR
   
   
   
   
   Code:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "ListImagesInRepository",
               "Effect": "Allow",
               "Action": [
                   "ecr:ListImages"
               ],
               "Resource": "arn:aws:ecr:ap-southeast-7:381491935:repository/valentine"
           },
           {
               "Sid": "GetAuthorizationToken",
               "Effect": "Allow",
               "Action": [
                   "ecr:GetAuthorizationToken"
                   ],
               "Resource": "*"
           },
           {
               "Sid": "ManageRepositoryContents",
               "Effect": "Allow",
               "Action": [
                   "ecr:GetDownloadUrlForLayer",
                   "ecr:BatchGetImage",
                   "ecr:CompleteLayerUpload",
                   "ecr:DescribeImages",
                   "ecr:DescribeRepositories",
                   "ecr:UploadLayerPart",
                   "ecr:ListImages",
                   "ecr:InitiateLayerUpload",
                   "ecr:BatchCheckLayerAvailability",
                   "ecr:GetRepositoryPolicy",
                   "ecr:PutImage"
               ],
               "Resource": "arn:aws:ecr:ap-southeast-7:381491935:repository/valentine"
           }
       ]
   }

   Code:

   https://docs.aws.amazon.com/AmazonECR/latest/userguide/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-access-one-bucket

   
   
   
   
6. https://github.com/ThaiCPE/90DaysOfDevOps/blob/main/ci.yaml

---

EKS AutoMode vs. EKS Fargate vs. ECS: เลือก Solution Container AWS ที่ใช่สำหรับ Team DevOps



หากเคยจัดการ Container มาก่อน คงรู้ว่ามันเหมือนกับการพยายามหาที่นอนที่ 'พอดี': ไม่แข็งเกินไป ไม่นุ่มเกินไป และก็ “กำลังพอดี” AWS มีเครื่องมือหลายอย่างสำหรับจัดการ Container และล่าสุดได้เปิดตัว EKS AutoMode ซึ่งสัญญาว่าจะทำให้ Kubernetes ง่ายขึ้น แต่แล้วมันอยู่ตรงไหนเมื่อเทียบกับ EKS Fargate หรือ ECS ที่โด่งดังอยู่แล้ว? มาดูกันเลย

EKS AutoMode คืออะไร?

EKS AutoMode คือ Solution Kubernetes ที่ถูกบริหารอย่างเต็มรูปแบบโดย AWS — AWS ดูแลเรื่องการจัดเตรียมโครงสร้าง การปรับขนาด และการจัดการโครงสร้างเบื้องหลังของ Cluster พูดง่าย ๆ คือ ไม่ต้องมาคอยปรับ Node Group หรือกังวลเรื่องการจัดสรรมากเกินไป — ระบบจัดการให้ทั้งหมด

เหมือนมี ‘ระบบควบคุมอัตโนมัติ’ สำหรับ Cluster: ระบบจะเพิ่มทรัพยากรเมื่อมี Traffic สูง และลดระดับเมื่อไม่ต้องการเยอะ เปิด Mode Cruise Control ให้ Cluster เลย

ทำไม DevOps Team ถึงควรสนใจ AutoMode?

1. จัดการ Kubernetes ง่ายขึ้น
   Kubernetes แม้ทรงพลัง แต่ก็ซับซ้อน AutoMode ช่วยลดความยุ่งยาก เช่น การตั้งค่า Node หรือการวางแผนด้านขนาดของระบบ (Capacity Planning) — AWS จัดการให้ เรา Focus กับการส่งมอบ Feature แทน
   
   
2. รองรับ Traffic Spike ได้ฉับไว
   ไม่ว่าจะเป็นช่วง Black Friday หรือจู่ ๆ มีผู้ใช้งานพุ่ง ระบบจะปรับขนาดให้โดยอัตโนมัติ ไม่ต้องเร่งทำด้วยมือ
   
   
3. ช่วยประหยัดงบประมาณ
   การจัดสรรมากเกินไปกินงบประมาณ แต่ AutoMode จะปรับพอดีกับความต้องการจริง ๆ — ไม่ต้องจ่ายค่า Idle Resource
   
   
4. เหมาะกับคนไม่ชำนาญ Kubernetes
   ไม่ใช่ทุกคนจะเชี่ยวชาญ Kubernetes และนั่นไม่ใช่ปัญหา AutoMode มันช่วยให้ใช้งาน Kubernetes ได้ง่ายขึ้น

เปรียบเทียบ: EKS AutoMode vs. EKS Fargate vs. ECS เมื่อไหร่ควรใช้?

• EKS AutoMode > เหมาะเมื่อต้องการ Run Kubernetes แต่ AWS จัดการโครงสร้างให้ทั้งหมด เหมาะกับ App ที่ต้องปรับขนาดแบบ Dynamic และ Team ที่ต้องการควบคุมในระดับปานกลางแต่ต้องการความง่าย
  
  
• EKS Fargate > ถ้าชอบ Kubernetes แต่ไม่อยากจัดการ Node เลย Fargate คือคำตอบ เหมาะสำหรับ App ขนาดเล็กที่ Stateless และ Team ที่อยาก Focus แค่โค้ด
  
  
• ECS Fargate > ถ้าอยู่ในระบบ AWS อยู่แล้ว และไม่ต้องการ Kubernetes, ECS เป็นตัวเลือกที่ดีมาก รวมกับ AWS Services ได้ดี

สถานการณ์ในชีวิตจริง

EKS AutoMode: ตัวอย่างเช่น สตาร์ทอัปอีคอมเมิร์ซที่มีแอปแบบ microservices, คนเข้าเยอะ-น้อยไม่แน่นอน และไม่มีทีม ดูแลโครงสร้างเยอะ AutoMode จะช่วยให้คุณขยาย-ลดได้ตามต้องการ โดยคุมเรื่องงบเอง

EKS Fargate: ทีมเล็กที่ deploy แอปขนาดเบา ไม่อยากยุ่งเรื่องโครงสร้าง โฟกัสที่แอปอย่างเดียว Fargate คือคำตอบที่ใช่

ECS: บริษัทใหญ่ที่ใช้ AWS Services เยอะอยู่แล้ว และไม่จำเป็นต้องใช้ Kubernetes, ECS ก็เป็นทางเลือกที่ตอบโจทย์ เพราะเชื่อมกับ CloudWatch, IAM และอื่น ๆ ได้อย่างแนบสนิท

สรุป

AWS ไม่มีทางเลือกเดียวที่จะเหมาะกับทุกคน (one-size-fits-all) — คุณจะใช้ EKS AutoMode, EKS Fargate, หรือ ECS ขึ้นอยู่กับความต้องการของทีมและลักษณะแอปของคุณ