Freigeben über

Blau-Grün-Bereitstellung in Azure-Container-Apps

Blau-Grün-Bereitstellung ist eine Softwareherausgabestrategie, die Downtime minimiert und das Risiko verringert, das mit der Bereitstellung neuer Versionen einer Anwendung verbunden ist. In einer blaugrünen Bereitstellung richten Sie zwei identische Umgebungen ein, die als "blau" und "grün" bezeichnet werden. Eine Umgebung (blau) führt die aktuelle Anwendungsversion aus, und die andere Umgebung (grün) führt die neue Anwendungsversion aus.

Nachdem Sie die grüne Umgebung getestet haben, leiten Sie den Live-Datenverkehr zur grünen Umgebung weiter. Sie verwenden die blaue Umgebung, um während des nächsten Bereitstellungszyklus eine neue Anwendungsversion bereitzustellen.

Sie können die Blau-Grün-Bereitstellung in Azure Container Apps aktivieren, indem Sie Container Apps-Überarbeitungen, Datenverkehrsgewichte und Überarbeitungsbezeichnungen kombinieren.

Screenshot der Azure Container Apps: Blau-Grün-Bereitstellung.

Verwenden Sie Revisionen, um Instanzen der blauen und grünen Version der Anwendung zu erzeugen.

Version BESCHREIBUNG
Blaue Überarbeitung Die als blau bezeichnete Überarbeitung ist die derzeit ausgeführte und stabile Version der Anwendung. Benutzer und Benutzerinnen interagieren mit dieser Revision, und sie ist das Ziel des Produktionsdatenverkehrs.
Grüne Überarbeitung Die als grün bezeichnete Überarbeitung ist eine Kopie der blauen Revision, mit der Ausnahme, dass sie eine neuere Version des App-Codes und möglicherweise einen neuen Satz von Umgebungsvariablen verwendet. Er empfängt zunächst keinen Produktionsdatenverkehr, ist aber über einen beschrifteten vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) zugänglich.

Nachdem Sie die neue Revision getestet und überprüft haben, können Sie den Produktionsdatenverkehr auf die neue Revision verweisen. Wenn Probleme auftreten, können Sie problemlos ein Rollback auf die vorherige Version ausführen.

Aktionen BESCHREIBUNG
Testen und Überprüfen Testen Sie die Revision der grünen Version gründlich, um sicherzustellen, dass die neue Version der Anwendung erwartungsgemäß funktioniert. Dieser Test kann verschiedene Aufgaben umfassen, einschließlich Funktionstests, Leistungstests und Kompatibilitätsprüfungen.
Datenverkehrswechsel Sobald die grüne Überarbeitung alle erforderlichen Tests bestanden hat, können Sie den Datenverkehr umstellen, sodass die grüne Revision die Produktionslast bedient. Sie machen diesen Wechsel in kontrollierter Weise, um einen reibungslosen Übergang sicherzustellen.
Rollback Wenn Probleme in der grünen Überarbeitung auftreten, können Sie den Datenverkehrswechsel wiederherstellen und den Datenverkehr zurück an die stabile blaue Überarbeitung weiterleiten. Dieses Rollback sorgt für minimale Auswirkungen auf Benutzer, wenn Probleme in der neuen Version auftreten. Die grüne Überarbeitung ist für die nächste Bereitstellung weiterhin verfügbar.
Rollenänderung Die Rollen der blauen und grünen Überarbeitungen ändern sich nach einer erfolgreichen Bereitstellung in der grünen Überarbeitung. Während des nächsten Releasezyklus stellt die grüne Revision die stabile Produktionsumgebung dar, während Sie die neue Version des Anwendungscodes in der blauen Revision bereitstellen und testen.

In diesem Artikel erfahren Sie, wie Sie die Blau-Grün-Bereitstellung in einer Container-App implementieren. Zum Ausführen der folgenden Beispiele benötigen Sie eine Container-App-Umgebung, in der Sie eine neue App erstellen können.

Hinweis

Ein vollständiges Beispiel für einen GitHub-Workflow, der blaugrüne Bereitstellung für Container-Apps implementiert, finden Sie unter containerapps-blue-green repository.

Erstellen einer Container-App mit mehreren aktiven Überarbeitungen

Um Traffic-Splitting zu aktivieren, legen Sie die configuration.activeRevisionsMode-Eigenschaft auf multiple fest. Um deterministische Revisionsnamen zu erhalten, legen Sie die Konfigurationseinstellung template.revisionSuffix auf einen Zeichenfolgenwert fest, der eine Version eindeutig identifiziert. Sie können z. B. Buildnummern oder Git commit short hashes verwenden.

Die folgenden Befehle verwenden einen Satz von Commit-Hashes.

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

Speichern Sie den folgenden Code in einer Datei namens 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

Stellen Sie die App mit der Bicep-Datei mit diesem Befehl bereit:

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

Bereitstellen einer neuen Überarbeitung und Zuweisen von Bezeichnungen

Die blaue Bezeichnung bezieht sich derzeit auf eine Überarbeitung, die den Produktionsdatenverkehr auf den FQDN der App aufnimmt. Die grüne Bezeichnung bezieht sich auf eine neue Version einer App, die Sie in der Produktion bereitstellen möchten. Ein neuer Commit-Hash identifiziert die neue Version des App-Codes. Der folgende Befehl stellt eine neue Überarbeitung für diesen Commit-Hash bereit und kennzeichnet sie mit der Bezeichnung grün.

#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

Das folgende Beispiel zeigt, wie der Datenverkehrsbereich konfiguriert ist. Die Überarbeitung mit dem blauencommitId übernimmt 100% des Produktionsdatenverkehrs, während die neu bereitgestellte Revision mit grüncommitId keinen Produktionsdatenverkehr übernimmt.

{ 
  "traffic": [
    {
      "revisionName": "<APP_NAME>--fb699ef",
      "weight": 100,
      "label": "blue"
    },
    {
      "revisionName": "<APP_NAME>--c6f1515",
      "weight": 0,
      "label": "green"
    }
  ]
}

Sie können die neu bereitgestellte Revision mithilfe des bezeichnungsspezifischen FQDN testen:

#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

Senden des Produktionsdatenverkehrs an die grüne Überarbeitung

Nachdem Sie bestätigt haben, dass der App-Code in der grünen Revision erwartungsgemäß funktioniert, senden Sie 100% des Produktionsdatenverkehrs an die Revision. Die grüne Überarbeitung wird nun zur Produktionsversion.

# 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

Das folgende Beispiel zeigt, wie der traffic-Abschnitt nach diesem Schritt konfiguriert wird. Die grüne Überarbeitung mit dem neuen Anwendungscode nimmt den gesamten Benutzerdatenverkehr auf, während die blaue Überarbeitung mit der alten Anwendungsversion keine Benutzeranforderungen akzeptiert.

{ 
  "traffic": [
    {
      "revisionName": "<APP_NAME>--fb699ef",
      "weight": 0,
      "label": "blue"
    },
    {
      "revisionName": "<APP_NAME>--c6f1515",
      "weight": 100,
      "label": "green"
    }
  ]
}

Zurücksetzen der Bereitstellung, wenn Probleme aufgetreten sind

Wenn nach der Ausführung in der Produktion die neue Überarbeitung Fehler enthält, können Sie einen Rollback auf den vorherigen funktionstüchtigen Zustand durchführen. Nach dem Rollback werden 100 % des Datenverkehrs in der blauen Überarbeitung an die alte Version gesendet und diese Überarbeitung wird erneut als Produktionsüberarbeitung festgelegt.

# 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

Nachdem die Fehler behoben wurden, wird die neue Version der Anwendung erneut als grüne Überarbeitung bereitgestellt. Die grüne Überarbeitung wird schließlich zur Produktionsversion.

Nächster Bereitstellungszyklus

Nun markiert die grüne Bezeichnung die Überarbeitung, die derzeit den stabilen Produktionscode ausführt.

Während des nächsten Bereitstellungszyklus kennzeichnet blau die Überarbeitung mit der neuen Anwendungsversion, die für die Produktion bereitgestellt wird.

Die folgenden Befehle veranschaulichen, wie Sie sich auf den nächsten Bereitstellungszyklus vorbereiten.

# 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

Nächste Schritte

Datenverkehrsgewichtungen

  • Last updated on