Penyebaran Biru-Hijau di Azure Container Apps
Penyebaran Blue-Green adalah strategi rilis perangkat lunak yang bertujuan untuk meminimalkan waktu henti dan mengurangi risiko yang terkait dengan penyebaran versi baru aplikasi. Dalam penyebaran biru-hijau, dua lingkungan yang identik, disebut sebagai "biru" dan "hijau," disiapkan. Satu lingkungan (biru) menjalankan versi aplikasi saat ini dan satu lingkungan (hijau) menjalankan versi aplikasi baru.
Setelah lingkungan hijau diuji, lalu lintas langsung diarahkan ke lingkungan tersebut, dan lingkungan biru digunakan untuk menyebarkan versi aplikasi baru selama siklus penyebaran berikutnya.
Anda dapat mengaktifkan penyebaran biru-hijau di Azure Container Apps dengan menggabungkan revisi aplikasi kontainer, bobot lalu lintas, dan label revisi.
Anda menggunakan revisi untuk membuat instans versi biru dan hijau aplikasi.
Revisi | Deskripsi |
---|---|
Revisi biru | Revisi berlabel biru adalah versi aplikasi yang sedang berjalan dan stabil. Revisi ini adalah salah satu yang berinteraksi dengan pengguna, dan itu adalah target lalu lintas produksi. |
Revisi hijau | Revisi berlabel hijau adalah salinan revisi biru kecuali menggunakan versi kode aplikasi yang lebih baru dan mungkin set variabel lingkungan yang baru. Ini tidak menerima lalu lintas produksi awalnya tetapi dapat diakses melalui nama domain berlabel sepenuhnya memenuhi syarat (FQDN). |
Setelah menguji dan memverifikasi revisi baru, Anda kemudian dapat mengarahkan lalu lintas produksi ke revisi baru. Jika Mengalami masalah, Anda dapat dengan mudah kembali ke versi sebelumnya.
Tindakan | Deskripsi |
---|---|
Pengujian dan verifikasi | Revisi hijau diuji dan diverifikasi secara menyeluruh untuk memastikan bahwa versi baru dari aplikasi berfungsi seperti yang diharapkan. Pengujian ini mungkin melibatkan berbagai tugas, termasuk pengujian fungsi, pengujian performa, dan pemeriksaan kompatibilitas. |
Pengalihan lalu lintas | Setelah revisi hijau melewati semua pengujian yang diperlukan, sakelar lalu lintas dilakukan sehingga revisi hijau mulai melayani beban produksi. Sakelar ini dilakukan dengan cara yang terkontrol, memastikan transisi yang lancar. |
Pemulihan | Jika masalah terjadi dalam revisi hijau, Anda dapat mengembalikan pengalihan lalu lintas, merutekan lalu lintas kembali ke revisi biru yang stabil. Pembatalan ini memastikan dampak minimal pada pengguna jika ada masalah dalam versi baru. Revisi hijau masih tersedia untuk penyebaran berikutnya. |
Perubahan peran | Peran revisi biru dan hijau berubah setelah penyebaran berhasil ke revisi hijau . Selama siklus rilis berikutnya, revisi hijau mewakili lingkungan produksi yang stabil sementara versi baru kode aplikasi disebarkan dan diuji dalam revisi biru . |
Artikel ini memperlihatkan kepada Anda cara menerapkan penyebaran biru-hijau di aplikasi kontainer. Untuk menjalankan contoh berikut, Anda memerlukan lingkungan aplikasi kontainer tempat Anda dapat membuat aplikasi baru.
Catatan
Lihat repositori containerapps-blue-green untuk contoh lengkap alur kerja GitHub yang mengimplementasikan penyebaran biru-hijau untuk Container Apps.
Membuat aplikasi kontainer dengan beberapa revisi aktif diaktifkan
Aplikasi kontainer harus mengatur configuration.activeRevisionsMode
properti ke multiple
untuk mengaktifkan pemisahan lalu lintas. Untuk mendapatkan nama revisi deterministik, Anda dapat mengatur template.revisionSuffix
pengaturan konfigurasi ke nilai string yang secara unik mengidentifikasi rilis. Misalnya Anda dapat menggunakan nomor build, atau git menerapkan hash pendek.
Untuk perintah berikut, satu set hash penerapan digunakan.
export APP_NAME=<APP_NAME>
export APP_ENVIRONMENT_NAME=<APP_ENVIRONMENT_NAME>
export RESOURCE_GROUP=<RESOURCE_GROUP>
# A commitId that is assumed to correspond to the app code currently in production
export BLUE_COMMIT_ID=fb699ef
# A commitId that is assumed to correspond to the new version of the code to be deployed
export GREEN_COMMIT_ID=c6f1515
# create a new app with a new revision
az containerapp create --name $APP_NAME \
--environment $APP_ENVIRONMENT_NAME \
--resource-group $RESOURCE_GROUP \
--image mcr.microsoft.com/k8se/samples/test-app:$BLUE_COMMIT_ID \
--revision-suffix $BLUE_COMMIT_ID \
--env-vars REVISION_COMMIT_ID=$BLUE_COMMIT_ID \
--ingress external \
--target-port 80 \
--revisions-mode multiple
# Fix 100% of traffic to the revision
az containerapp ingress traffic set \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--revision-weight $APP_NAME--$BLUE_COMMIT_ID=100
# give that revision a label 'blue'
az containerapp revision label add \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--label blue \
--revision $APP_NAME--$BLUE_COMMIT_ID
Simpan kode berikut ke dalam file bernama main.bicep
.
targetScope = 'resourceGroup'
param location string = resourceGroup().location
@minLength(1)
@maxLength(64)
@description('Name of containerapp')
param appName string
@minLength(1)
@maxLength(64)
@description('Container environment name')
param containerAppsEnvironmentName string
@minLength(1)
@maxLength(64)
@description('CommitId for blue revision')
param blueCommitId string
@maxLength(64)
@description('CommitId for green revision')
param greenCommitId string = ''
@maxLength(64)
@description('CommitId for the latest deployed revision')
param latestCommitId string = ''
@allowed([
'blue'
'green'
])
@description('Name of the label that gets 100% of the traffic')
param productionLabel string = 'blue'
var currentCommitId = !empty(latestCommitId) ? latestCommitId : blueCommitId
resource containerAppsEnvironment 'Microsoft.App/managedEnvironments@2022-03-01' existing = {
name: containerAppsEnvironmentName
}
resource blueGreenDeploymentApp 'Microsoft.App/containerApps@2022-11-01-preview' = {
name: appName
location: location
tags: {
blueCommitId: blueCommitId
greenCommitId: greenCommitId
latestCommitId: currentCommitId
productionLabel: productionLabel
}
properties: {
environmentId: containerAppsEnvironment.id
configuration: {
maxInactiveRevisions: 10 // Remove old inactive revisions
activeRevisionsMode: 'multiple' // Multiple active revisions mode is required when using traffic weights
ingress: {
external: true
targetPort: 80
traffic: !empty(blueCommitId) && !empty(greenCommitId) ? [
{
revisionName: '${appName}--${blueCommitId}'
label: 'blue'
weight: productionLabel == 'blue' ? 100 : 0
}
{
revisionName: '${appName}--${greenCommitId}'
label: 'green'
weight: productionLabel == 'green' ? 100 : 0
}
] : [
{
revisionName: '${appName}--${blueCommitId}'
label: 'blue'
weight: 100
}
]
}
}
template: {
revisionSuffix: currentCommitId
containers:[
{
image: 'mcr.microsoft.com/k8se/samples/test-app:${currentCommitId}'
name: appName
resources: {
cpu: json('0.5')
memory: '1.0Gi'
}
env: [
{
name: 'REVISION_COMMIT_ID'
value: currentCommitId
}
]
}
]
}
}
}
output fqdn string = blueGreenDeploymentApp.properties.configuration.ingress.fqdn
output latestRevisionName string = blueGreenDeploymentApp.properties.latestRevisionName
Sebarkan aplikasi dengan templat Bicep menggunakan perintah ini:
export APP_NAME=<APP_NAME>
export APP_ENVIRONMENT_NAME=<APP_ENVIRONMENT_NAME>
export RESOURCE_GROUP=<RESOURCE_GROUP>
# A commitId that is assumed to belong to the app code currently in production
export BLUE_COMMIT_ID=fb699ef
# A commitId that is assumed to belong to the new version of the code to be deployed
export GREEN_COMMIT_ID=c6f1515
# create a new app with a blue revision
az deployment group create \
--name createapp-$BLUE_COMMIT_ID \
--resource-group $RESOURCE_GROUP \
--template-file main.bicep \
--parameters appName=$APP_NAME blueCommitId=$BLUE_COMMIT_ID containerAppsEnvironmentName=$APP_ENVIRONMENT_NAME \
--query properties.outputs.fqdn
Menyebarkan revisi baru dan menetapkan label
Label biru saat ini mengacu pada revisi yang mengambil lalu lintas produksi yang tiba di FQDN aplikasi. Label hijau mengacu pada versi baru aplikasi yang akan diluncurkan ke dalam produksi. Hash penerapan baru mengidentifikasi versi baru kode aplikasi. Perintah berikut menyebarkan revisi baru untuk hash penerapan tersebut dan menandainya dengan label hijau .
#create a second revision for green commitId
az containerapp update --name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--image mcr.microsoft.com/k8se/samples/test-app:$GREEN_COMMIT_ID \
--revision-suffix $GREEN_COMMIT_ID \
--set-env-vars REVISION_COMMIT_ID=$GREEN_COMMIT_ID
#give that revision a 'green' label
az containerapp revision label add \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--label green \
--revision $APP_NAME--$GREEN_COMMIT_ID
#deploy a new version of the app to green revision
az deployment group create \
--name deploy-to-green-$GREEN_COMMIT_ID \
--resource-group $RESOURCE_GROUP \
--template-file main.bicep \
--parameters appName=$APP_NAME blueCommitId=$BLUE_COMMIT_ID greenCommitId=$GREEN_COMMIT_ID latestCommitId=$GREEN_COMMIT_ID productionLabel=blue containerAppsEnvironmentName=$APP_ENVIRONMENT_NAME \
--query properties.outputs.fqdn
Contoh berikut menunjukkan bagaimana bagian lalu lintas dikonfigurasi. Revisi dengan warna biru commitId
mengambil 100% lalu lintas produksi sementara revisi yang baru disebarkan dengan warna hijau commitId
tidak mengambil lalu lintas produksi apa pun.
{
"traffic": [
{
"revisionName": "<APP_NAME>--fb699ef",
"weight": 100,
"label": "blue"
},
{
"revisionName": "<APP_NAME>--c6f1515",
"weight": 0,
"label": "green"
}
]
}
Revisi yang baru disebarkan dapat diuji dengan menggunakan FQDN khusus label:
#get the containerapp environment default domain
export APP_DOMAIN=$(az containerapp env show -g $RESOURCE_GROUP -n $APP_ENVIRONMENT_NAME --query properties.defaultDomain -o tsv | tr -d '\r\n')
#Test the production FQDN
curl -s https://$APP_NAME.$APP_DOMAIN/api/env | jq | grep COMMIT
#Test the blue label FQDN
curl -s https://$APP_NAME---blue.$APP_DOMAIN/api/env | jq | grep COMMIT
#Test the green label FQDN
curl -s https://$APP_NAME---green.$APP_DOMAIN/api/env | jq | grep COMMIT
Mengirim lalu lintas produksi ke revisi hijau
Setelah mengonfirmasi bahwa kode aplikasi dalam revisi hijau berfungsi seperti yang diharapkan, 100% lalu lintas produksi dikirim ke revisi. Revisi hijau sekarang menjadi revisi produksi.
# set 100% of traffic to green revision
az containerapp ingress traffic set \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--label-weight blue=0 green=100
# make green the prod revision
az deployment group create \
--name make-green-prod-$GREEN_COMMIT_ID \
--resource-group $RESOURCE_GROUP \
--template-file main.bicep \
--parameters appName=$APP_NAME blueCommitId=$BLUE_COMMIT_ID greenCommitId=$GREEN_COMMIT_ID latestCommitId=$GREEN_COMMIT_ID productionLabel=green containerAppsEnvironmentName=$APP_ENVIRONMENT_NAME \
--query properties.outputs.fqdn
Contoh berikut menunjukkan bagaimana bagian dikonfigurasi traffic
setelah langkah ini. Revisi hijau dengan kode aplikasi baru mengambil semua lalu lintas pengguna sementara revisi biru dengan versi aplikasi lama tidak menerima permintaan pengguna.
{
"traffic": [
{
"revisionName": "<APP_NAME>--fb699ef",
"weight": 0,
"label": "blue"
},
{
"revisionName": "<APP_NAME>--c6f1515",
"weight": 100,
"label": "green"
}
]
}
Gulung balik penyebaran jika ada masalah
Jika setelah berjalan dalam produksi, revisi baru ditemukan memiliki bug, Anda dapat kembali ke keadaan baik sebelumnya. Setelah pembatalan, 100% lalu lintas dikirim ke versi lama dalam revisi biru dan revisi tersebut ditetapkan sebagai revisi produksi lagi.
# set 100% of traffic to green revision
az containerapp ingress traffic set \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--label-weight blue=100 green=0
# rollback traffic to blue revision
az deployment group create \
--name rollback-to-blue-$GREEN_COMMIT_ID \
--resource-group $RESOURCE_GROUP \
--template-file main.bicep \
--parameters appName=$APP_NAME blueCommitId=$BLUE_COMMIT_ID greenCommitId=$GREEN_COMMIT_ID latestCommitId=$GREEN_COMMIT_ID productionLabel=blue containerAppsEnvironmentName=$APP_ENVIRONMENT_NAME \
--query properties.outputs.fqdn
Setelah bug diperbaiki, versi baru aplikasi disebarkan sebagai revisi hijau lagi. Versi hijau akhirnya menjadi revisi produksi.
Siklus penyebaran berikutnya
Sekarang label hijau menandai revisi yang saat ini menjalankan kode produksi yang stabil.
Selama siklus penyebaran berikutnya, biru mengidentifikasi revisi dengan versi aplikasi baru yang diluncurkan ke produksi.
Perintah berikut menunjukkan cara mempersiapkan siklus penyebaran berikutnya.
# set the new commitId
export BLUE_COMMIT_ID=ad1436b
# create a third revision for blue commitId
az containerapp update --name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--image mcr.microsoft.com/k8se/samples/test-app:$BLUE_COMMIT_ID \
--revision-suffix $BLUE_COMMIT_ID \
--set-env-vars REVISION_COMMIT_ID=$BLUE_COMMIT_ID
# give that revision a 'blue' label
az containerapp revision label add \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--label blue \
--revision $APP_NAME--$BLUE_COMMIT_ID
# set the new commitId
export BLUE_COMMIT_ID=ad1436b
# deploy new version of the app to blue revision
az deployment group create \
--name deploy-to-blue-$BLUE_COMMIT_ID \
--resource-group $RESOURCE_GROUP \
--template-file main.bicep \
--parameters appName=$APP_NAME blueCommitId=$BLUE_COMMIT_ID greenCommitId=$GREEN_COMMIT_ID latestCommitId=$BLUE_COMMIT_ID productionLabel=green containerAppsEnvironmentName=$APP_ENVIRONMENT_NAME \
--query properties.outputs.fqdn