ช่วงนี้ใน project จะเริ่มทำการพัฒนา CI/CD pipeline สำหรับ developer ทั้งองค์กรเพื่อ deploy application ขึ้น cloud อย่าง Microsoft Azure หนึ่งในจุดหมายของการ deploy คือ Azure Container Apps (ACA) เลยมาจดบันทึกแบบสรุปไว้สำหรับการแบ่งปันประสบการณ์ต่อไป

Azure Container Apps คืออะไร

ในการพัฒนา software ปัจจุบัน การ deploy application ส่วนใหญ่ก็มักจะอยู่ในลักษณะของ container เพื่อลดค่าใช้จ่ายและความซับซ้อนในการติดตั้ง dependencies ให้พร้อมสำหรับการ deploy เช่น ติดตั้ง operating system เนื่องจาก container จะมีเพียงแค่ dependencies ที่จำเป็นต่อการ run application เท่านั้น

ทีนี้บน cloud provider ก็จะมี service เพื่อรองรับการ deploy container ขึ้นแตกต่างกันไป ในส่วนของ Azure นั้นก็จะมีหลายอันเลย หนึ่งในนั้นคือ ACA นั่นเอง

ACA จะอยู่ตรงกลาง ๆ ในด้านของความซับซ้อนที่ต่ำลงมาเพราะ Microsoft จัดการเรื่องความซับซ้อนในการดูแล Kubernetes cluster แต่แลกมากับ feature ที่จำกัดตาม technology ที่มาทดแทน Kubernetes ซึ่งได้แก่

  • Dapr เป็น API ที่ติดตั้งในรูปแบบของ sidecar pattern ที่ช่วยลดความซับซ้อนในการพัฒนา feature ต่าง ๆ ตามแนวคิดของ distributed architecture เช่น state management, configuration and secret management, publish & subscribe (pub/sub), event notification (bindings), service-to-service communication

Dapr components

https://azure.github.io/aca-dotnet-workshop/aca/00-workshop-intro/3-dapr-integration/

  • KEDA เป็น platform ที่ช่วย scale application ตามจำนวนของ event ที่เกิดขึ้นตามแนวคิดของ event-driven architecture
  • Envoy เป็น HTTP proxy ช่วยทำเรื่อง ingress, DNS, traffic routing และ TLS termination

เมื่อเทียบกับ service คล้าย ๆ กัน (จะขอตัดพวก third party อย่าง Azure Red Hat Openshift หรือ Azure Spring Apps ออกไปเพื่อให้เห็นภาพมากขึ้น) ก็จะมีข้อดี-ข้อเสียต่างกันไปตามนี้

Azure computing choices

https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/compute-decision-tree

สิ่งที่ต้องพิจารณา / Service Azure Kubernetes Service (AKS) Azure Container Apps (ACA) Azure Container Instances (ACI) Azure App Service
ความซับซ้อน สูง ต้องอาศัยความรู้ในการดูแล Kubernetes cluster ปานกลาง ไม่ต้องมีความรู้เรื่อง Kubernetes แต่อาจจะต้องมีความรู้ใน tech ที่มาทดแทน ต่ำ ไม่ต้องมีความรู้เรื่อง Kubernetes และ technology ที่เกี่ยวข้อง ปานกลาง ไม่ต้องมีความรู้เรื่อง Kubernetes แต่อาจจะต้องมีความรู้ใน Azure service ที่เกี่ยวข้องกับ web application
การ scale สูง (ขึ้นอยู่กับ resource limit ที่กำหนดไว้) ปานกลาง (ขึ้นอยู่กับ resource limit ที่กำหนดไว้) ต่ำ ถ้าอยากจะ scale มา n instances จะต้องสร้าง ACI ใหม่เอง n ครั้ง ปานกลาง (ขึ้นอยู่กับ resource limit ที่กำหนดไว้)
ความอิสระในการเพิ่ม feature ต่าง ๆ สูง สามารถใช้ Kubernetes custom resource หรือ operator ได้หมด ปานกลาง จำกัดอยู่แค่ tech ที่มาทดแทน Kubernetes ต่ำ load balancing กับ certificates ก็ไม่มีให้ ปานกลาง จำกัดอยู่แค่ web, API เพราะมันถูกสร้างมาให้ใช้แค่นั้น
ค่าใช้จ่าย ปานกลาง-สูง (หากต้องการใช้ในระดับ production grade) ต่ำ-ปานกลาง (ขึ้นอยู่กับ resource limit ที่กำหนดไว้) ต่ำมาก-ต่ำ (ขึ้นอยู่กับ resource limit ที่กำหนดไว้) ต่ำ-ปานกลาง (ขึ้นอยู่กับ resource limit ที่กำหนดไว้)

ในส่วนของการออกแบบ CI/CD pipeline ก็จะต้องออกแบบให้รองรับ use case ที่ขึ้นอยู่กับแต่ละ service โดยที่คนนำ CI/CD pipeline ไปใช้จะต้องไม่ปวดหัวกับความซับซ้อนใน technology ที่กล่าวมาข้างต้น

ขั้นตอนการ deploy ล่ะทำยังไง

ในส่วนของการ deploy container ขึ้น ACA นอกจากตัว app ก็จะมีส่วนประกอบสำคัญดังนี้

  • Environments: เป็นสิ่งที่รวมกลุ่มของ ACA app ที่เกี่ยวข้องกันไว้ด้วยกัน ใช้สำหรับทำ service-to-service communication ภายใน environment กันเองได้หากมี Azure Virtual Network (VNet) นอกจากนั้นยังเอาไว้เก็บ log เพื่อส่งต่อให้ Azure Log Analytics Workspace
  • Log Analytics Workspace: ทำการเก็บ log ที่ส่งมาจาก ACA environment ใช้ Kusto Query Language (KQL) ในการค้นหา log
  • Dapr components: สำหรับระบุ configuration เพื่อใช้งาน feature ต่าง ๆ ใน Dapr

เราสามารถเลือกการ deploy ได้ 2 รุปแบบ (revision) ได้แก่

  • Single: เมื่อมีการ deploy version ใหม่ขึ้นมา ก็จะเก็บไว้ทั้ง version เก่าและใหม่ จากนั้น ACA จะทำการ deactivate version เก่าทิ้งให้โดยอัตโนมัติ ถ้าอยากได้ zero-downtime deployment จะต้องมี ingress เพื่อให้ traffic เข้า version เก่าจนกว่า version ใหม่จะ deploy เสร็จ
  • Multiple: เมื่อมีการ deploy version ใหม่ขึ้นมา ก็จะเก็บไว้ทั้ง version เก่าและใหม่ แต่จะไม่ deactivate version เก่าทิ้งจนกว่าเราจะตั้งค่า version ใหม่ว่าเป็น latestRevision เอง จุดประสงค์เพื่อเอาไว้ทำ blue-green deployment หรือ A/B testing

ACA lifecycle update

ACA lifecycle deactivate

https://learn.microsoft.com/en-us/azure/container-apps/application-lifecycle-management

วิธีการ deploy เลือกได้หลายแบบ เช่น Azure portal, command line, Infrastrutuce-as-a-Code (IaC) ถ้าพูดถึงในส่วนของการออกแบบ CI/CD pipeline ก็จะเลือกเป็น IaC เพื่อเก็บ version control ผ่าน Git และลดงาน manual (ClickOps) ลงไป ทีนี้ IaC ของ Azure ก็มีหลากหลายตัวให้เลือก โดย 2 ตัวหลัก ๆ ที่เลือกนำมาพิจารณาคือ Azure Bicep และ Terraform นอกจากความแตกต่างที่ได้อธิบายไว้ใน documentation นี้แล้ว ยังมีสิ่งที่ต้องพิจารณาเพิ่ม เช่น ความซับซ้อนในการสร้าง ACA เนื่องจากใน Terraform ขณะที่เขียนบทความนี้ ตัว Azure resource management (ARM) provider ยังไม่รองรับ ACA เต็มรูปแบบ เช่น Dapr binding configuration เป็นต้น จีงต้องหันไปใช้ Azure API (AZAPI) provider เพียงแค่ส่วนนั้นแทน (จริง ๆ แล้วเราสามารถใช้ AZAPI provider แทน ARM provider ได้หมดทุก resource เลยนะ แต่มันจะซับซ้อนดูแลยากกว่า)

Dependencies ของ ACA

ในการใช้งาน ACA ในระดับ production grade นั้น มีเพียงแค่ app คงไม่เพียงพอ เนื่องจาก Dapr มี feature มากมายที่มี integration กับ Azure service อื่น ๆ เช่น

จากนั้นพิจารณา use case ต่าง ๆ เหล่านี้เพื่อต่อยอดการพัฒนาปรับปรุงชิ้นงานให้ดีขึ้น ๆ ไป