Deploy Web App ด้วย Azure App Service

Azure App Service คือบริการ Host Web Application และ Web Application ซึ่งเราจะสนใจเฉพาะตัว Application ส่วน Infrastructrure ด้านล่างจะปล่อยให้เป็นหน้าที่ของ Azure

ทำไมต้องใช้ Azure App Service

สิ่งที่เราจะได้จากการนำ Web Application ไป Deploy ลงใน Azure App Service คือ

1. Multiple-Languages สามารถพัฒนาด้วย Asp.net, Dotnet core, Javascript, Ruby, Python, PHP, Java หรือจะเป็น Powershell ก็ได้
2. Auto-Scaling รองรับการ Scale โดยอัตโนมัติ เมื่อมีผู้ใช้งานในปริมาณมากๆ
3. Easy to Deployment รองรับการ Deploy หลายรูปแบบทั้ง FTP, Azure DevOps, Github และ Bitbucket
4. Deployment Slots สามารถสร้าง Deployment สำหรับหลายๆ Environment เช่น Staging, Pre-Production และ Production
5. App Service on Linux Support การใช้ Linux เป็น OS สำหรับ Application(นำ App ไป run บน Linux)

Deploy to Azure App Service

เราสามารถ Deploy Web Application ของเราลงใน Azure App Service ได้ด้วยทางเลือกต่างๆ ดังนี้

1. Automated Deployment

• Azure DevOps
• GitHub
• Bitbucket

2. Manual Deployment

• Git
• CLI
• Zip deploy
• FTP/FTPs

ในการ Deploy App Service เราต้องเลือก Service Plan เพื่อที่จะได้ Features และ Limit ของการใช้งานดังตารางด้านล่าง

โดยเราจะแบ่ง Service Plan ออกเป็น 4 กลุ่มหลักๆดังนี้

1. Shared Computed
2. Dedicated Computed
3. Isolated
4. Consumption

ใน Free Plan(F1) และ Shared Plan(D1) แต่ละ Application จะได้รับ CPU Minutes บน VM ที่ใช้ร่วมกันหลายๆคน(Shared ตามชื่อ Plan) และไม่สามารถขยายขนาดได้ ส่วนใน Plan อื่น ๆ Application จะสามารถขยายขนาดได้

• Application จะทำงานบนเครื่อง VM ของตัวเอง
• หากมีหลาย Application หลายตัวอยู่ใน App Service Plan เดียวกัน Application ทั้งหมดจะใช้ VM ร่วมกัน
• หากคุณมีหลาย Deployment Slot แต่ละ Slot ก็จะทำงานบนเครื่อง VM เดียวกัน
• หากคุณเปิดใช้ Diagnostic Logs, Backup หรือ WebJobs เครื่องมือเหล่านี้ก็จะใช้ CPU และหน่วยความจำบนเครื่อง VM ด้วยเหมือนกัน

คุณควรแยกแอปออกไปอยู่ใน App Service Plan ใหม่ เมื่อ:

• Application ใช้ทรัพยากรจำนวนมาก
• คุณต้องการขยายขนาด Application โดยไม่กระทบกับแอปอื่น ๆ ใน Plan เดิม
• Application ต้องใช้ทรัพยากรในประเทศอื่นๆ

3. Deployment Slots

นอกจากการ Deploy App Service ขึ้นไปบน Azure ตรงๆแล้ว เรายังสามารถแยก Production และ Staging Environment ออกจากกัน เพื่อใช้ทดสอบ Application ก่อนที่จะทำการ Deploy ลงไปบน Production เพื่อใช้งานจริง ดังรูป

การนำแอปของคุณไป Deploy ใน Slot ที่ไม่ใช่ Production มีข้อดีดังต่อไปนี้

• คุณสามารถตรวจสอบการเปลี่ยนแปลงของแอปใน Slot ที่เป็น Staging ก่อนที่จะสลับไปเป็น Production
• การ Deploy แอปไปยัง Slot ก่อน แล้วค่อยสลับเข้าสู่ Production จะช่วยให้มั่นใจได้ว่า Slot นั้นถูก Warm Up(ทุก Instance ถูกเรียกขึ้นมาใช้งานแล้ว)
• หลังจากการ Swap, Slot ที่เคยเป็น Staging จะกลายเป็น Application ที่เคยอยู่ใน Production ก่อนหน้านั้น

จำนวน Deployment Slots จะมีผลต่อการเลือก Plan ด้วย เนื่องจากแต่ละ Plan จะรองรับจำนวน Deployment Slot ไม่เท่ากัน ดังนั้นหากคุณมีจำนวน Slot เกินกว่าที่ Plan นั้นรองรับ คุณจะไม่สามารถเปลี่ยนไปใช้ Plan ดังกล่าวได้ เช่น หากคุณมีมากกว่า 5 Slots คุณจะไม่สามารถเปลี่ยนไปใช้ Standard Plan ได้ เพราะ Standard Plan รองรับสูงสุดเพียง 5 Slots เท่านั้น

Authentication and Authorization

Azure App Service จะมีวิธีการ Authen และ Authorize ที่ Built-in มาให้เราอยู่แล้ว ซึ่งจะช่วยให้เราเขียน Code ในส่วนนี้น้อย และไปให้ความสำคัญกับส่วนที่เป็น Business Logic มากๆ

Azure App Service สามารถเลือกใช้วิธีการ Authen ผ่าน Identity Provider ต่างๆเหล่านี้

• Microsoft Identity Platform
• Facebook
• Google
• Twitter

Authentication Flow

ขั้นตอนการยืนยันตัวตน (Authentication Flow) จะเหมือนกันทุกเจ้า แต่จะแตกต่างกันตรงที่คุณเลือกใช้ SDK ของผู้ให้บริการหรือไม่

Without SDK(ไม่ใช้ SDK)

หากเราไม่ใช้ SDK ของผู้ให้บริการ Application จะ Dedicate หรือ Redirect การ Authentication ของ App Service ไปที่ผู้ให้บริการ(Authenticator) โดยตรง ซึ่งมักจะใช้ในกรณีของ Application ที่รันบน Browser ซึ่งสามารถแสดงหน้า Login ของผู้ให้บริการให้ผู้ใช้ดูได้ กระบวนการ Authentication นี้ถูกจัดการโดยโค้ดฝั่ง Server จึงเรียกอีกชื่อหนึ่งว่า Server-directed flow หรือ Server flow

With SDK(ใช้ SDK)

หากเราใช้ SDK ของผู้ให้บริการ Application จะลงชื่อเข้าใช้กับผู้ให้บริการ(Authenticator)ด้วยตนเอง หลังจากนั้นผู้ให้บริการจะส่ง Token ไปยัง App Service เพื่อตรวจสอบความถูกต้อง ซึ่งมักใช้ในกรณีของ Application ที่ไม่มี Browser และไม่สามารถแสดงหน้า Login เข้าสู่ระบบของผู้ให้บริการโดยตรงได้ กระบวนการ Authen นี้จะถูกจัดการโดยโค้ดใน Application เอง จึงเรียกอีกชื่อหนึ่งว่า Client-directed flow หรือ Client flow

กรณีนี้ใช้กับแอปพลิเคชันประเภท REST API, Azure Functions, เว็บแอปที่ใช้ JavaScript, และแอปมือถือแบบ Native ที่ใช้ SDK ของผู้ให้บริการในการลงชื่อเข้าใช้ผู้ใช้