การปรับใช้อย่างต่อเนื่องไปยัง Azure
ขยาย pipeline ด้วยขั้นตอนการปรับใช้ที่พุชอาร์ติแฟกต์การสร้างไปยังช่อง App Service เรียกใช้การทดสอบควัน และสลับไปยังระบบจริงเมื่อได้รับอนุมัติ
การปรับใช้อย่างต่อเนื่องไปยัง Azure เป็นบทเรียน Azure Fundamentals ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Azure Fundamentals และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Azure Fundamentals มีบทเรียนทั้งหมด 4 บทเรียน
การนำไปใช้งานอย่างต่อเนื่องคืออะไร
การนำไปใช้งานอย่างต่อเนื่อง (CD) จะเผยแพร่การเปลี่ยนแปลงทุกอย่างที่ผ่านการทดสอบ CI ไปยัง Production โดยอัตโนมัติโดยไม่ต้องมีการดำเนินการด้วยตนเอง การส่งมอบอย่างต่อเนื่องเป็นรูปแบบที่ผ่อนปรนกว่า โดยทำให้การนำไปใช้งานจนถึงสภาพแวดล้อม Staging เป็นอัตโนมัติ และต้องมีด่านการอนุมัติจากบุคคลก่อนนำไปใช้งานใน Production แนวปฏิบัติทั้งสองใช้โครงสร้างพื้นฐานของไปป์ไลน์เดียวกัน ใน Azure Pipelines จะใช้ CD โดยเพิ่มระยะการนำไปใช้งานหลังระยะ CI และกำหนดเป้าหมายเป็นสภาพแวดล้อม Azure ที่มีด่านการอนุมัติตามต้องการ
ไปป์ไลน์หลายระยะ: CI + CD
ไปป์ไลน์ CI/CD ที่สมบูรณ์มีอย่างน้อยสามระยะ ได้แก่ Build (คอมไพล์ ทดสอบ และเผยแพร่อาร์ติแฟกต์) Deploy to Staging (นำอาร์ติแฟกต์ไปใช้งานในสล็อตที่ไม่ใช่ Production) และ Deploy to Production (สลับสล็อตหรือนำไปใช้งานหลังได้รับการอนุมัติ) ระยะต่าง ๆ จะส่งต่ออาร์ติแฟกต์ผ่านที่จัดเก็บอาร์ติแฟกต์ของไปป์ไลน์ ระยะ Staging จะเรียกใช้การทดสอบการผสานรวมหรือการทดสอบเบื้องต้นโดยอัตโนมัติ ส่วนระยะ Production จะรอการอนุมัติด้วยตนเองก่อนดำเนินการต่อ
# azure-pipelines.yml: multi-stage CI/CD
trigger:
branches:
include: [main]
pool:
vmImage: ubuntu-latest
stages:
- stage: Build
jobs:
- job: BuildApp
steps:
- script: npm ci && npm run build
- task: PublishPipelineArtifact@1
inputs: {targetPath: dist, artifactName: webapp}
- stage: DeployStaging
dependsOn: Build
jobs:
- deployment: StagingDeploy
environment: Staging
strategy:
runOnce:
deploy:
steps:
- task: AzureWebApp@1
inputs: {appName: myapp-staging, package: '$(Pipeline.Workspace)/webapp'}
- stage: DeployProduction
dependsOn: DeployStaging
jobs:
- deployment: ProductionDeploy
environment: Production # Has manual approval gate
strategy:
runOnce:
deploy:
steps:
- task: AzureWebApp@1
inputs: {appName: myapp, package: '$(Pipeline.Workspace)/webapp'}งานการนำไปใช้งานและสภาพแวดล้อม
ใช้ งาน deployment (ไม่ใช่ job ปกติ) สำหรับระยะการนำไปใช้งาน งานการนำไปใช้งานรองรับกลยุทธ์การนำไปใช้งาน (runOnce, rolling, canary) ติดตามประวัติการนำไปใช้งานแยกตามสภาพแวดล้อม และจำเป็นต้องอ้างอิงสภาพแวดล้อมของ Azure DevOps สภาพแวดล้อมจะบันทึกว่าไปป์ไลน์ใดนำไปใช้งาน มีเวอร์ชันใดกำลังทำงานอยู่ และให้ข้อมูลด่านการอนุมัติ การตรวจสอบ และสถานะความสมบูรณ์ของทรัพยากรในแดชบอร์ดเดียว
# Deployment job with rolling strategy
- job: RollingDeploy
strategy:
rolling:
maxParallel: 2 # Deploy to 2 targets at a time
preDeploy:
steps:
- script: echo 'Pre-deploy checks'
deploy:
steps:
- task: AzureWebApp@1
inputs:
appName: myapp
package: '$(Pipeline.Workspace)/webapp'
postRouteDeploy:
steps:
- script: curl -f https://myapp.azurewebsites.net/healthการนำไปใช้งานใน Azure App Service
งาน AzureWebApp@1 จะนำเว็บแอปพลิเคชันไปใช้งานใน Azure App Service รองรับการนำไปใช้งานในสล็อตที่ระบุ (เช่น staging) การนำแพ็กเกจ ZIP อิมเมจ Docker หรือไฟล์ JAR/WAR ไปใช้งาน หลังจากนำไปใช้งานในสล็อต staging แล้ว ให้ใช้งาน AzureAppServiceManage@0 เพื่อสลับสล็อต staging ไปเป็น Production ซึ่งเป็นรูปแบบการนำไปใช้งานที่แนะนำสำหรับ App Service และไม่ทำให้บริการหยุดทำงาน
# Deploy to staging slot, then swap to production
steps:
- task: AzureWebApp@1
displayName: 'Deploy to staging slot'
inputs:
azureSubscription: 'AzureProductionSC'
appType: webAppLinux
appName: myUniqueWebApp
deployToSlotOrASE: true
resourceGroupName: MyRG
slotName: staging
package: '$(Pipeline.Workspace)/webapp/app.zip'
runtimeStack: 'NODE|18-lts'
- task: AzureAppServiceManage@0
displayName: 'Swap staging into production'
inputs:
azureSubscription: 'AzureProductionSC'
action: Swap Slots
webAppName: myUniqueWebApp
resourceGroupName: MyRG
sourceSlot: stagingการทดสอบเบื้องต้นในไปป์ไลน์ CD
หลังจากนำไปใช้งานใน staging แล้ว ให้เรียกใช้การทดสอบเบื้องต้น ซึ่งเป็นชุดการทดสอบขั้นต่ำที่ตรวจสอบว่าการนำไปใช้งานสำเร็จและแอปพลิเคชันตอบสนองอย่างถูกต้อง โดยทั่วไปการทดสอบเบื้องต้นจะเรียกจุดปลายทาง API สำคัญและตรวจสอบรหัสสถานะกับเนื้อหาการตอบกลับที่คาดไว้ หากการทดสอบเบื้องต้นล้มเหลว ไปป์ไลน์จะหยุดก่อนสลับไปยัง Production หรือขอการอนุมัติ เพื่อป้องกันไม่ให้รุ่นที่มีปัญหาไปถึงผู้ใช้
# Smoke test step after staging deployment
- script: |
MAX_RETRY=10
COUNT=0
until curl -sf https://myUniqueWebApp-staging.azurewebsites.net/health; do
COUNT=$((COUNT+1))
if [ $COUNT -ge $MAX_RETRY ]; then
echo 'Health check failed after $MAX_RETRY attempts'
exit 1
fi
echo 'Waiting for app to start... attempt '$COUNT
sleep 10
done
echo 'App is healthy'
displayName: 'Smoke test: health endpoint'ด่านการอนุมัติสภาพแวดล้อม
เพิ่มด่านการอนุมัติในสภาพแวดล้อม Azure DevOps เพื่อกำหนดให้ต้องอนุมัติด้วยตนเองก่อนดำเนินการนำไปใช้งาน ไปที่การตั้งค่าสภาพแวดล้อมและเพิ่ม Approvals จากนั้นระบุผู้ใช้หรือกลุ่มที่ต้องอนุมัติ เมื่อไปป์ไลน์มาถึงงานการนำไปใช้งานที่กำหนดเป้าหมายเป็นสภาพแวดล้อมนั้น ระบบจะหยุดชั่วคราวและส่งการแจ้งเตือนทางอีเมล ผู้อนุมัติสามารถดูรายละเอียดการนำไปใช้งาน และอนุมัติหรือปฏิเสธได้ในพอร์ทัล Azure DevOps หรือลิงก์ในอีเมลแจ้งเตือน
# Pipeline YAML: deployment to production environment
# (Approval configured in Azure DevOps portal on 'Production' environment)
- stage: DeployProduction
displayName: 'Deploy to Production'
dependsOn: DeployStaging
condition: succeeded('DeployStaging')
jobs:
- deployment: ProdDeploy
environment: Production # <-- Triggers approval gate configured in portal
strategy:
runOnce:
deploy:
steps:
- task: AzureWebApp@1
inputs:
appName: myapp-prod
package: '$(Pipeline.Workspace)/webapp/app.zip'การนำไปใช้งานใน Azure Kubernetes Service
นำแอปพลิเคชันแบบคอนเทนเนอร์ไปใช้งานใน AKS โดยใช้งาน KubernetesManifest@0 งานนี้ใช้แม니เฟสต์ YAML ของ Kubernetes กับคลัสเตอร์ และมีการรองรับ imagePullSecrets กับการนำไปใช้งานแบบ canary ในตัว เชื่อมต่อคลัสเตอร์ AKS โดยใช้การเชื่อมต่อบริการ Kubernetes ที่กำหนดค่าไว้ใน Azure DevOps งานนี้ใช้ kubectl apply อยู่เบื้องหลัง และรอให้การเปิดตัวเสร็จสมบูรณ์ก่อนทำเครื่องหมายว่าขั้นตอนสำเร็จ
# AKS deployment step in Azure Pipelines
- task: KubernetesManifest@0
displayName: 'Deploy to AKS'
inputs:
action: deploy
kubernetesServiceConnection: 'AKS-Production-SC'
namespace: production
manifests: |
k8s/deployment.yaml
k8s/service.yaml
containers: 'mycontainerregistry.azurecr.io/myapp:$(Build.BuildId)'
imagePullSecrets: acr-secretกลยุทธ์การติดแท็กอิมเมจ
ติดแท็กอิมเมจคอนเทนเนอร์ด้วยรหัสการสร้าง ($(Build.BuildId)) หรือSHA ของคอมมิต Git ($(Build.SourceVersion)) เพื่อให้คุณติดตามคอนเทนเนอร์ที่กำลังทำงานกลับไปยังรุ่นโค้ดที่แน่นอนซึ่งใช้สร้างคอนเทนเนอร์นั้นได้เสมอ หลีกเลี่ยงการใช้แท็ก latest ใน Production เพราะ Kubernetes จะแคชแท็กนี้และอาจไม่ดึงเวอร์ชันใหม่ จัดเก็บแท็กอิมเมจเฉพาะไว้เป็นตัวแปรไปป์ไลน์ และแทรกแท็กดังกล่าวลงในแม니เฟสต์ Kubernetes ขณะนำไปใช้งานโดยใช้ envsubst หรือ sed
# Tag and push image with build ID in CI stage
- script: |
IMAGE='mycontainerregistry.azurecr.io/myapp'
TAG='$(Build.BuildId)'
docker build -t $IMAGE:$TAG -t $IMAGE:latest .
az acr login --name mycontainerregistry
docker push $IMAGE:$TAG
docker push $IMAGE:latest
echo "##vso[task.setvariable variable=imageTag;isOutput=true]$TAG"
name: BuildImage
displayName: 'Build and push container image'กลยุทธ์การย้อนกลับ
กำหนดกลยุทธ์การย้อนกลับสำหรับการปรับใช้ในสภาพแวดล้อมจริง เพื่อให้สามารถกู้คืนได้อย่างรวดเร็วเมื่อรุ่นที่เผยแพร่มีปัญหา สำหรับ App Service การย้อนกลับหมายถึงการสลับช่องการใช้งานจริงกลับไปเป็นรุ่นก่อนหน้าในช่องเตรียมใช้งาน สำหรับ AKS ให้ใช้ kubectl rollout undo สร้างไปป์ไลน์การย้อนกลับโดยเฉพาะ หรือเพิ่มงานย้อนกลับด้วยตนเองที่สามารถเรียกใช้จากพอร์ทัล Azure DevOps ได้ จัดทำเอกสารขั้นตอนการย้อนกลับและฝึกปฏิบัติเป็นประจำ — การย้อนกลับที่ไม่เคยทดสอบไม่ถือว่าเป็นการย้อนกลับ
# Rollback job triggered manually
- job: Rollback
condition: and(failed(), eq(variables['Build.Reason'], 'Manual'))
steps:
# App Service rollback: swap production back to previous
- task: AzureAppServiceManage@0
inputs:
azureSubscription: 'AzureProductionSC'
action: Swap Slots
webAppName: myUniqueWebApp
resourceGroupName: MyRG
sourceSlot: production # Swap production back to staging version
targetSlot: stagingการแจ้งเตือนและการตรวจสอบการปรับใช้
หลังการปรับใช้ในสภาพแวดล้อมจริงแต่ละครั้ง ให้เรียกใช้การตรวจสอบระบบโดยอัตโนมัติเพื่อยืนยันว่ารุ่นใหม่ทำงานได้อย่างสมบูรณ์ ใช้การตรวจสอบไปป์ไลน์ AzureMonitor@1 เพื่อสอบถามเมตริกของ Azure Monitor — หากอัตราข้อผิดพลาดสูงขึ้นหลังการปรับใช้ ให้หยุดการดำเนินการของไปป์ไลน์ในขั้นถัดไปและเรียกใช้การย้อนกลับ ส่งการแจ้งเตือนการปรับใช้ไปยัง Microsoft Teams หรือ Slack ผ่านงานเว็บฮุก เพื่อให้ทีมทราบเมื่อการปรับใช้เสร็จสิ้นและทราบว่ารุ่นใดกำลังทำงานอยู่
# Send Teams notification on deployment completion
- task: InvokeRestAPI@1
displayName: 'Notify Teams channel'
inputs:
connectionType: connectedServiceName
serviceConnection: 'TeamsWebhookSC'
method: POST
body: '{
"text": "Deployed **$(Build.BuildId)** to Production. Committed by $(Build.RequestedFor). <br>View: https://myapp.contoso.com"
}'
waitForCompletion: falseแนวทางปฏิบัติที่ดีที่สุดสำหรับ CD
ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดสำหรับการปรับใช้อย่างต่อเนื่องดังนี้: ปรับใช้บ่อย ๆ (ชุดงานขนาดเล็กช่วยลดความเสี่ยง), ใช้แฟล็กฟีเจอร์ เพื่อแยกการปรับใช้ออกจากการเผยแพร่, ทำให้ด่านตรวจสอบคุณภาพทั้งหมดเป็นอัตโนมัติก่อนใช้งานจริง, ฝึกใช้สภาพแวดล้อมเตรียมใช้งานที่เหมือนสภาพแวดล้อมจริง เพื่อไม่ให้ความแตกต่างบดบังข้อบกพร่อง, ตรวจสอบช่วงเวลาการปรับใช้ด้วยการตรวจสอบสถานะอัตโนมัติ และต้องมี แผนการย้อนกลับที่ผ่านการทดสอบแล้วเสมอ ไปป์ไลน์ CD ที่มีวุฒิภาวะทำให้การปรับใช้กลายเป็นเหตุการณ์ที่แทบไม่ต้องให้ความสนใจ แทนที่จะเป็นการดำเนินงานที่สร้างความเครียดสูง
ตรวจสอบความเข้าใจ
ทดสอบความเข้าใจแนวคิด Microsoft Azure Fundamentals (AZ-900) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า ไปป์ไลน์ YAML แบบหลายระยะเชื่อมระยะ Build, Staging และ Production เข้าด้วยกันโดยส่งต่ออาร์ติแฟกต์, งานการปรับใช้ที่มี Environmentsช่วยให้มีด่านอนุมัติและติดตามการปรับใช้ได้ และ การทดสอบเบื้องต้นหลังการปรับใช้ใน Staging ช่วยป้องกันไม่ให้รุ่นที่มีปัญหาไปถึง Production บทถัดไปเราจะสำรวจ GitHub Actions บน Azure
เรียนรู้ Azure Fundamentals ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 30
- บทเรียน
- 120
คำถามที่พบบ่อย
บทเรียน “การปรับใช้อย่างต่อเนื่องไปยัง Azure” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การปรับใช้อย่างต่อเนื่องไปยัง Azure” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Azure Fundamentals ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Azure Fundamentals มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การปรับใช้อย่างต่อเนื่องไปยัง Azure”
ขยาย pipeline ด้วยขั้นตอนการปรับใช้ที่พุชอาร์ติแฟกต์การสร้างไปยังช่อง App Service เรียกใช้การทดสอบควัน และสลับไปยังระบบจริงเมื่อได้รับอนุมัติ คุณปฏิบัติ Azure Fundamentals ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Azure Fundamentals หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Azure Fundamentals บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน
บทเรียน “การปรับใช้อย่างต่อเนื่องไปยัง Azure” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Azure Fundamentals นี้ได้ไหม
ได้ บทเรียน Azure Fundamentals ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- ภาพรวมบริการ Azure DevOps
- การสร้าง CI Pipeline ด้วย Azure Pipelines
- การปรับใช้อย่างต่อเนื่องไปยัง Azure
- GitHub Actions บน Azure