Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Blue-Green Deployment to strategia wdrażania oprogramowania, która minimalizuje przestoje i zmniejsza ryzyko przy wdrażaniu nowych wersji aplikacji. W przypadku wdrożenia niebieski-zielony skonfigurujesz dwa identyczne środowiska o nazwie "niebieski" i "zielony". Jedno środowisko (niebieskie) uruchamia bieżącą wersję aplikacji, a drugie środowisko (zielone) uruchamia nową wersję aplikacji.
Po przetestowaniu środowiska zielonego kierujesz do niego ruch na żywo. Środowisko niebieskie służy do wdrażania nowej wersji aplikacji podczas następnego cyklu wdrażania.
Wdrożenie niebiesko-zielone w usłudze Azure Container Apps można włączyć, łącząc poprawki aplikacji kontenera, wagi ruchu i etykiety poprawek.
Użyj poprawek, aby utworzyć wystąpienia niebieskich i zielonych wersji aplikacji.
| Wersja | opis |
|---|---|
| Niebieska poprawka | Wersja oznaczona jako niebieska jest aktualnie uruchomiona i stabilna wersja aplikacji. Użytkownicy wchodzą w interakcję z tą wersją, a jest to obiekt ruchu produkcyjnego. |
| Zielona poprawka | Poprawka oznaczona jako zielona jest kopią niebieskiej poprawki, z wyjątkiem nowszej wersji kodu aplikacji i prawdopodobnie nowego zestawu zmiennych środowiskowych. Początkowo nie odbiera żadnego ruchu produkcyjnego, ale jest dostępny za pośrednictwem w pełni kwalifikowanej nazwy domeny (FQDN). |
Po przetestowaniu i zweryfikowaniu nowej wersji można skierować ruch produkcyjny do tej wersji. Jeśli wystąpią problemy, możesz łatwo przywrócić poprzednią wersję.
| Akcje | opis |
|---|---|
| Testowanie i weryfikacja | Dokładnie przetestuj i sprawdź zieloną poprawkę, aby upewnić się, że nowa wersja aplikacji działa zgodnie z oczekiwaniami. Te testy mogą obejmować różne zadania, w tym testy funkcjonalne, testy wydajnościowe i testy zgodności. |
| Przełącznik ruchu | Gdy zielona wersja przejdzie wszystkie niezbędne testy, możesz przełączyć ruch tak, aby zielona wersja zaczyna obsługiwać obciążenie produkcyjne. Dokonujesz tego przełączenia w kontrolowany sposób, zapewniając płynne przejście. |
| Wycofywanie | Jeśli wystąpią problemy w zielonej wersji, możesz przywrócić przełącznik ruchu, rozsyłając ruch z powrotem do stabilnej niebieskiej poprawki. Wycofanie zapewnia minimalny wpływ na użytkowników, jeśli występują problemy w nowej wersji. Zielona wersja jest nadal dostępna dla następnego wdrożenia. |
| Zmiana roli | Role niebieskich i zielonych poprawek zmieniają się po pomyślnym wdrożeniu do zielonej poprawki. W następnym cyklu wydania zielona poprawka reprezentuje stabilne środowisko produkcyjne podczas wdrażania i testowania nowej wersji kodu aplikacji w niebieskiej wersji. |
W tym artykule pokazano, jak zaimplementować wdrożenie niebiesko-zielone w aplikacji kontenera. Aby uruchomić poniższe przykłady, potrzebujesz środowiska aplikacji kontenera, w którym można utworzyć nową aplikację.
Uwaga
Dla pełnego przykładu przepływu pracy na GitHubie, który implementuje wdrożenie typu blue-green dla aplikacji kontenerowych, odwiedź repozytorium containerapps-blue-green.
Tworzenie aplikacji kontenera z włączonymi wieloma aktywnymi wersjami
Aby włączyć dzielenie ruchu, ustaw configuration.activeRevisionsMode właściwość na multiple. Aby uzyskać deterministyczne nazwy wersji, ustaw template.revisionSuffix ustawienie konfiguracji na wartość ciągową, która jednoznacznie identyfikuje wydanie. Można na przykład użyć numerów kompilacji lub krótkich skrótów zatwierdzeń Git.
Następujące polecenia używają zestawu skrótów zatwierdzeń.
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
Zapisz następujący kod w pliku o nazwie 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
Wdróż aplikację przy użyciu pliku Bicep przy użyciu tego polecenia:
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
Wdrażanie nowej poprawki i przypisywanie etykiet
Niebieska etykieta obecnie odwołuje się do poprawki, która pobiera ruch produkcyjny przychodzący do nazwy FQDN aplikacji. Zielona etykieta odnosi się do nowej wersji aplikacji, którą planujesz wdrożyć w środowisku produkcyjnym. Nowy skrót zatwierdzenia identyfikuje nową wersję kodu aplikacji. Następujące polecenie wdraża nową poprawkę dla tego skrótu zatwierdzenia i oznacza ją zieloną etykietą.
#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
W poniższym przykładzie pokazano, jak skonfigurowano sekcję ruchu. Wersja z niebieskimcommitId przyjmuje 100% ruchu produkcyjnego, podczas gdy nowo wdrożona wersja z zielonymcommitId nie obsługuje ruchu produkcyjnego.
{
"traffic": [
{
"revisionName": "<APP_NAME>--fb699ef",
"weight": 100,
"label": "blue"
},
{
"revisionName": "<APP_NAME>--c6f1515",
"weight": 0,
"label": "green"
}
]
}
Nowo wdrożoną poprawkę można przetestować przy użyciu nazwy FQDN specyficznej dla etykiety:
#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
Wysyłanie ruchu produkcyjnego do zielonej poprawki
Po potwierdzeniu, że kod aplikacji w zielonej wersji działa zgodnie z oczekiwaniami, wyślij 100% ruchu produkcyjnego do poprawki. Zielona poprawka staje się teraz poprawką produkcyjną.
# 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
W poniższym przykładzie pokazano, jak traffic sekcja jest skonfigurowana po tym kroku. Zielona poprawka z nowym kodem aplikacji pobiera cały ruch użytkownika, podczas gdy niebieska poprawka ze starą wersją aplikacji nie akceptuje żądań użytkowników.
{
"traffic": [
{
"revisionName": "<APP_NAME>--fb699ef",
"weight": 0,
"label": "blue"
},
{
"revisionName": "<APP_NAME>--c6f1515",
"weight": 100,
"label": "green"
}
]
}
Wycofywanie wdrożenia, jeśli wystąpiły problemy
Jeśli po uruchomieniu w środowisku produkcyjnym zostanie znaleziona nowa poprawka, możesz przywrócić poprzedni dobry stan. Po wycofaniu 100% ruchu jest wysyłanych do starej wersji w niebieskiej wersji i ta poprawka zostanie ponownie wyznaczona jako wersja produkcyjna.
# 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
# Roll back 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
Po naprawieniu usterek nowa wersja aplikacji zostanie ponownie wdrożona jako zielona poprawka. Zielona wersja ostatecznie stanie się wersją produkcyjną.
Następny cykl wdrażania
Teraz zielona etykieta oznacza poprawkę, która obecnie uruchamia stabilny kod produkcyjny.
W następnym cyklu wdrażania niebieski identyfikuje poprawkę z nową wersją aplikacji wdrażaną w środowisku produkcyjnym.
Poniższe polecenia pokazują, jak przygotować się do następnego cyklu wdrażania.
# 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