Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Schrittweise Bereitstellung serverloser Anwendungen mit AWS SAM
AWS Serverless Application Model (AWS SAM) ist integriert CodeDeploy, um schrittweise AWS Lambda Bereitstellungen zu ermöglichen. AWS SAM Erledigt mit nur wenigen Konfigurationszeilen Folgendes für Sie:
-
Stellt neue Versionen Ihrer Lambda-Funktion bereit und erstellt automatisch Aliase, die auf die neue Version verweisen.
-
Leitet den Kundenverkehr schrittweise auf die neue Version um, bis Sie überzeugt sind, dass sie wie erwartet funktioniert. Wenn ein Update nicht ordnungsgemäß funktioniert, können Sie die Änderungen rückgängig machen.
-
Definiert Testfunktionen vor und nach dem Datenverkehr, um zu überprüfen, ob der neu bereitgestellte Code korrekt konfiguriert ist und ob Ihre Anwendung erwartungsgemäß funktioniert.
-
Macht die Bereitstellung automatisch rückgängig, wenn CloudWatch Alarme ausgelöst werden.
Anmerkung
Wenn Sie schrittweise Bereitstellungen über Ihre AWS SAM Vorlage aktivieren, wird automatisch eine CodeDeploy Ressource für Sie erstellt. Sie können die CodeDeploy Ressource direkt über die AWS Management Console anzeigen.
Beispiel
Das folgende Beispiel zeigt die Verwendung von CodeDeploy , um Kunden schrittweise auf Ihre neu bereitgestellte Version der Lambda-Funktion umzustellen:
Resources: MyLambdaFunction: Type: AWS::Serverless::Function Properties: Handler: index.handler Runtime: nodejs12.x CodeUri: s3://bucket/code.zip AutoPublishAlias: live DeploymentPreference: Type: Canary10Percent10Minutes Alarms: # A list of alarms that you want to monitor - !Ref AliasErrorMetricGreaterThanZeroAlarm - !Ref LatestVersionErrorMetricGreaterThanZeroAlarm Hooks: # Validation Lambda functions that are run before & after traffic shifting PreTraffic: !Ref PreTrafficLambdaFunction PostTraffic: !Ref PostTrafficLambdaFunction
Diese Überarbeitungen der AWS SAM Vorlage haben folgende Auswirkungen:
-
AutoPublishAlias: Durch Hinzufügen dieser Eigenschaft und Angabe eines Aliasnamens: AWS SAM-
Erkennt, wenn neuer Code bereitgestellt wird, basierend auf Änderungen am Amazon S3 URI der Lambda-Funktion.
-
Erstellt und veröffentlicht eine aktualisierte Version dieser Funktion mit dem neuesten Code.
-
Erstellt einen Alias mit einem von Ihnen angegebenen Namen (sofern nicht bereits ein Alias vorhanden ist) und verweist auf die aktualisierte Version der Lambda-Funktion. Funktionsaufrufe sollten den Alias-Qualifizierer verwenden, um dies zu nutzen. Wenn Sie mit der Versionierung und Aliasnamen von Lambda-Funktionen nicht vertraut sind, finden Sie weitere Informationen unter AWS Lambda Funktionsversionierung und Aliase.
-
-
Deployment Preference Type: Im vorherigen Beispiel werden 10 Prozent Ihres Kundenverkehrs sofort auf Ihre neue Version umgestellt. Nach 10 Minuten wird der gesamte Verkehr auf die neue Version umgestellt. Wenn Ihre Tests vor oder nach dem Datenverkehr jedoch fehlschlagen oder wenn ein CloudWatch Alarm ausgelöst wird, wird Ihre Bereitstellung CodeDeploy zurückgesetzt. Sie können auf folgende Weise angeben, wie der Datenverkehr zwischen den Versionen verlagert werden soll:-
Canary: Der Datenverkehr wird in zwei Inkrementen verschoben. Sie können aus vordefinierten Canary-Optionen wählen. Die Optionen geben den Prozentsatz des Datenverkehrs an, der im ersten Schritt auf Ihre aktualisierte Lambda-Funktionsversion umgestellt wurde, und das Intervall in Minuten, bevor der verbleibende Verkehr in der zweiten Stufe verschoben wird. -
Linear: Der Datenverkehr wird in gleichmäßigen Inkrementen um die gleiche Anzahl von Minuten zwischen den einzelnen Inkrementen verschoben. Sie können aus vordefinierten linearen Optionen wählen, die den Prozentsatz des Datenverkehrs angeben, der in jedem Inkrement verschoben wird, und die Anzahl der Minuten zwischen den einzelnen Schritten. -
AllAtOnce: Der gesamte Datenverkehr wird gleichzeitig von der ursprünglichen Lambda-Funktion auf die aktualisierte Lambda-Funktionsversion umgestellt.
In der folgenden Tabelle sind weitere Optionen zur Verkehrsverlagerung aufgeführt, die über die im Beispiel verwendete hinaus verfügbar sind.
Bereitstellungspräferenztyp Canary10Percent30Minutes
Canary10Percent5Minutes
Canary10Percent10Minutes
Canary10Percent15Minutes
Linear 10 10 Minuten PercentEvery
Linear 10 1 Minute PercentEvery
Linear 10 2 Minuten PercentEvery
Linear 10 3 Minuten PercentEvery
AllAtOnce
-
-
Alarms: Dies sind CloudWatch Alarme, die durch alle Fehler ausgelöst werden, die bei der Bereitstellung ausgelöst wurden. Wenn sie auftreten, wird Ihre Bereitstellung automatisch rückgängig gemacht. Dies ist beispielsweise der Fall, wenn der aktualisierte Code, den Sie bereitstellen, Fehler in der Anwendung verursacht. Ein anderes Beispiel ist, wenn einige AWS Lambdaoder benutzerdefinierte CloudWatch Messwerte, die Sie angegeben haben, den Alarmschwellenwert überschritten haben. -
Hooks: Dabei handelt es sich um Testfunktionen vor und nach dem Verkehr, die Prüfungen durchführen, bevor die Verkehrsverlagerung auf die neue Version beginnt und nachdem die Verkehrsverlagerung abgeschlossen ist.-
PreTraffic: Ruft vor Beginn der Verkehrsverlagerung die CodeDeploy Lambda-Funktion Pre-Traffic Hook auf. Diese Lambda-Funktion muss zurückrufen CodeDeploy und deren Erfolg oder Misserfolg anzeigen. Wenn die Funktion fehlschlägt, wird sie abgebrochen und ein Fehler wird an gemeldet. AWS CloudFormation Wenn die Funktion erfolgreich ist, wird mit der CodeDeploy Verkehrsverlagerung fortgefahren. -
PostTraffic: Ruft nach Abschluss der Verkehrsverlagerung die CodeDeploy Lambda-Funktion nach dem Traffic Hook auf. Dies ähnelt dem Pre-Traffic-Hook, bei dem die Funktion erneut aufrufen muss, um einen Erfolg oder CodeDeploy Misserfolg zu melden. Verwenden Sie Post-Traffic-Hooks für Integrationstests oder andere Validierungsaktivitäten.
Weitere Informationen finden Sie unter SAMReferenz zu sicheren Bereitstellungen
. -
Schrittweise erstmalige Bereitstellung einer Lambda-Funktion
Bei der schrittweisen Bereitstellung einer Lambda-Funktion CodeDeploy ist eine zuvor bereitgestellte Funktionsversion erforderlich, von der der Datenverkehr verlagert werden soll. Daher sollte Ihre erste Bereitstellung in zwei Schritten durchgeführt werden:
-
Schritt 1: Stellen Sie Ihre Lambda-Funktion bereit und erstellen Sie automatisch Aliase mit.
AutoPublishAlias -
Schritt 2: Führen Sie Ihre schrittweise Bereitstellung mit durch.
DeploymentPreference
Wenn Sie Ihre erste schrittweise Bereitstellung in zwei Schritten durchführen, erhalten Sie CodeDeploy eine frühere Lambda-Funktionsversion, von der aus Sie den Datenverkehr verlagern können.
Schritt 1: Stellen Sie Ihre Lambda-Funktion bereit
Resources: MyLambdaFunction: Type: AWS::Serverless::Function Properties: Handler: index.handler Runtime: nodejs12.x CodeUri: s3://bucket/code.zip AutoPublishAlias: live
Schritt 2: Führen Sie Ihre schrittweise Bereitstellung durch
Resources: MyLambdaFunction: Type: AWS::Serverless::Function Properties: Handler: index.handler Runtime: nodejs12.x CodeUri: s3://bucket/code.zip AutoPublishAlias: live DeploymentPreference: Type: Canary10Percent10Minutes Alarms: # A list of alarms that you want to monitor - !Ref AliasErrorMetricGreaterThanZeroAlarm - !Ref LatestVersionErrorMetricGreaterThanZeroAlarm Hooks: # Validation Lambda functions that are run before and after traffic shifting PreTraffic: !Ref PreTrafficLambdaFunction PostTraffic: !Ref PostTrafficLambdaFunction
Weitere Informationen
Ein praktisches Beispiel für die Konfiguration einer schrittweisen Bereitstellung finden Sie in Modul 5 — Bereitstellungen auf Canary
