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.
# Führen Sie die schrittweise Bereitstellung von State-Machine-Versionen in Step Functions durch
Eine fortlaufende Bereitstellung ist eine Bereitstellungsstrategie, bei der frühere Versionen einer Anwendung langsam durch neue Versionen einer Anwendung ersetzt werden. Um eine fortlaufende Bereitstellung einer State-Machine-Version durchzuführen, müssen Sie schrittweise eine zunehmende Menge an Ausführungsdatenverkehr an die neue Version weiterleiten. Die Menge des Datenverkehrs und die Steigerungsrate sind Parameter, die Sie konfigurieren.
Sie können die fortlaufende Bereitstellung einer Version mit einer der folgenden Optionen durchführen:
+ [Step Functions Functions-Konsole](https://console.aws.amazon.com/states/home?region=us-east-1#/) — Erstellen Sie einen Alias, der auf zwei Versionen derselben Zustandsmaschine verweist. Für diesen Alias konfigurieren Sie die Routing-Konfiguration so, dass der Verkehr zwischen den beiden Versionen umgeleitet wird. Weitere Informationen zur Verwendung der Konsole zum Rollout von Versionen finden Sie unter [Versionen](concepts-state-machine-version.md) und[Aliase](concepts-state-machine-alias.md).
+ **Skripts für AWS CLI und SDK** — Erstellen Sie ein Shell-Skript mit dem AWS CLI oder dem AWS SDK. Weitere Informationen finden Sie in den folgenden Abschnitten zur Verwendung von AWS CLI AWS SDK.
+ **AWS CloudFormation Vorlagen** — Verwenden Sie die `[AWS::StepFunctions::StateMachineAlias](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-stepfunctions-statemachine.html)` Ressourcen `[AWS::StepFunctions::StateMachineVersion](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-stepfunctions-statemachine.html)` und, um mehrere State-Machine-Versionen zu veröffentlichen und einen Alias zu erstellen, der auf eine oder zwei dieser Versionen verweist.
## Verwenden Sie die AWS CLI , um eine neue State-Machine-Version bereitzustellen
Das Beispielskript in diesem Abschnitt zeigt, wie Sie den verwenden können, AWS CLI um den Datenverkehr schrittweise von einer früheren State-Machine-Version auf eine neue State-Machine-Version zu verlagern. Sie können dieses Beispielskript entweder verwenden oder es entsprechend Ihren Anforderungen aktualisieren.
Dieses Skript zeigt eine Canary-Bereitstellung für die Bereitstellung einer neuen State-Machine-Version unter Verwendung eines Alias. In den folgenden Schritten werden die Aufgaben beschrieben, die das Skript ausführt:
1. Wenn der `publish_revision` Parameter auf true gesetzt ist, veröffentlichen Sie die neueste Version [revision](concepts-cd-aliasing-versioning.md#statemachinerev) als nächste Version der Zustandsmaschine. Diese Version wird zur neuen Live-Version, wenn die Bereitstellung erfolgreich ist.
Wenn Sie den `publish_revision` Parameter auf false setzen, stellt das Skript die zuletzt veröffentlichte Version des State Machine bereit.
1. Erstellen Sie einen Alias, falls er noch nicht existiert. Wenn der Alias nicht existiert, leiten Sie 100 Prozent des Datenverkehrs für diesen Alias auf die neue Version weiter und beenden Sie dann das Skript.
1. Aktualisieren Sie die Routing-Konfiguration des Alias, um einen kleinen Prozentsatz des Datenverkehrs von der vorherigen Version auf die neue Version zu verlagern. Sie legen diesen kanarischen Prozentsatz mit dem `canary_percentage` Parameter fest.
1. Überwachen Sie die konfigurierbaren CloudWatch Alarme standardmäßig alle 60 Sekunden. Wenn einer dieser Alarme ausgelöst wird, setzen Sie die Bereitstellung sofort zurück, indem Sie 100 Prozent des Datenverkehrs auf die vorherige Version weiterleiten.
Fahren Sie nach jedem in definierten Zeitintervall in Sekunden mit der `alarm_polling_interval` Überwachung der Alarme fort. Setzen Sie die Überwachung fort, bis das in definierte Zeitintervall `canary_interval_seconds` abgelaufen ist.
1. Wenn währenddessen keine Alarme ausgelöst wurden`canary_interval_seconds`, verlagern Sie 100 Prozent des Datenverkehrs auf die neue Version.
1. Wenn die neue Version erfolgreich bereitgestellt wurde, löschen Sie alle Versionen, die älter sind als die im `history_max` Parameter angegebene Anzahl.
```
#!/bin/bash
#
# AWS StepFunctions example showing how to create a canary deployment with a
# State Machine Alias and versions.
#
# Requirements: AWS CLI installed and credentials configured.
#
# A canary deployment deploys the new version alongside the old version, while
# routing only a small fraction of the overall traffic to the new version to
# see if there are any errors. Only once the new version has cleared a testing
# period will it start receiving 100% of traffic.
#
# For a Blue/Green or All at Once style deployment, you can set the
# canary_percentage to 100. The script will immediately shift 100% of traffic
# to the new version, but keep on monitoring the alarms (if any) during the
# canary_interval_seconds time interval. If any alarms raise during this period,
# the script will automatically rollback to the previous version.
#
# Step Functions allows you to keep a maximum of 1000 versions in version history
# for a state machine. This script has a version history deletion mechanism at
# the end, where it will delete any versions older than the limit specified.
#
# For an example that also demonstrates linear (or rolling) deployments, see the following:
# https://github.com/aws-samples/aws-stepfunctions-examples/blob/main/gradual-deploy/sfndeploy.py
set -euo pipefail
# ******************************************************************************
# you can safely change the variables in this block to your values
state_machine_name="my-state-machine"
alias_name="alias-1"
region="us-east-1"
# array of cloudwatch alarms to poll during the test period.
# to disable alarm checking, set alarm_names=()
alarm_names=("alarm1" "alarm name with a space")
# true to publish the current revision as the next version before deploy.
# false to deploy the latest version from the state machine's version history.
publish_revision=true
# true to force routing configuration update even if the current routing
# for the alias does not have a 100% routing config.
# false will abandon deploy attempt if current routing config not 100% to a
# single version.
# Be careful when you combine this flag with publish_revision - if you just
# rerun the script you might deploy the newly published revision from the
# previous run.
force=false
# percentage of traffic to route to the new version during the test period
canary_percentage=10
# how many seconds the canary deployment lasts before full deploy to 100%
canary_interval_seconds=300
# how often to poll the alarms
alarm_polling_interval=60
# how many versions to keep in history. delete versions prior to this.
# set to 0 to disable old version history deletion.
history_max=0
# ******************************************************************************
#######################################
# Update alias routing configuration.
#
# If you don't specify version 2 details, will only create 1 routing entry. In
# this case the routing entry weight must be 100.
#
# Globals:
# alias_arn
# Arguments:
# 1. version 1 arn
# 2. version 1 weight
# 3. version 2 arn (optional)
# 4. version 2 weight (optional)
#######################################
function update_routing() {
if [[ $# -eq 2 ]]; then
local routing_config="[{\"stateMachineVersionArn\": \"$1\", \"weight\":$2}]"
elif [[ $# -eq 4 ]]; then
local routing_config="[{\"stateMachineVersionArn\": \"$1\", \"weight\":$2}, {\"stateMachineVersionArn\": \"$3\", \"weight\":$4}]"
else
echo "You have to call update_routing with either 2 or 4 input arguments." >&2
exit 1
fi
${aws} update-state-machine-alias --state-machine-alias-arn ${alias_arn} --routing-configuration "${routing_config}"
}
# ******************************************************************************
# pre-run validation
if [[ (("${#alarm_names[@]}" -gt 0)) ]]; then
alarm_exists_count=$(aws cloudwatch describe-alarms --alarm-names "${alarm_names[@]}" --alarm-types "CompositeAlarm" "MetricAlarm" --query "length([MetricAlarms, CompositeAlarms][])" --output text)
if [[ (("${#alarm_names[@]}" -ne "${alarm_exists_count}")) ]]; then
echo All of the alarms to monitor do not exist in CloudWatch: $(IFS=,; echo "${alarm_names[*]}") >&2
echo Only the following alarm names exist in CloudWatch:
aws cloudwatch describe-alarms --alarm-names "${alarm_names[@]}" --alarm-types "CompositeAlarm" "MetricAlarm" --query "join(', ', [MetricAlarms, CompositeAlarms][].AlarmName)" --output text
exit 1
fi
fi
if [[ (("${history_max}" -gt 0)) && (("${history_max}" -lt 2)) ]]; then
echo The minimum value for history_max is 2. This is the minimum number of older state machine versions to be able to rollback in the future. >&2
exit 1
fi
# ******************************************************************************
# main block follows
account_id=$(aws sts get-caller-identity --query Account --output text)
sm_arn="arn:aws:states:${region}:${account_id}:stateMachine:${state_machine_name}"
# the aws command we'll be invoking a lot throughout.
aws="aws stepfunctions"
# promote the latest revision to the next version
if [[ "${publish_revision}" = true ]]; then
new_version=$(${aws} publish-state-machine-version --state-machine-arn=$sm_arn --query stateMachineVersionArn --output text)
echo Published the current revision of state machine as the next version with arn: ${new_version}
else
new_version=$(${aws} list-state-machine-versions --state-machine-arn ${sm_arn} --max-results 1 --query "stateMachineVersions[0].stateMachineVersionArn" --output text)
echo "Since publish_revision is false, using the latest version from the state machine's version history: ${new_version}"
fi
# find the alias if it exists
alias_arn_expected="${sm_arn}:${alias_name}"
alias_arn=$(${aws} list-state-machine-aliases --state-machine-arn ${sm_arn} --query "stateMachineAliases[?stateMachineAliasArn==\`${alias_arn_expected}\`].stateMachineAliasArn" --output text)
if [[ "${alias_arn_expected}" == "${alias_arn}" ]]; then
echo Found alias ${alias_arn}
echo Current routing configuration is:
${aws} describe-state-machine-alias --state-machine-alias-arn "${alias_arn}" --query routingConfiguration
else
echo Alias does not exist. Creating alias ${alias_arn_expected} and routing 100% traffic to new version ${new_version}
${aws} create-state-machine-alias --name "${alias_name}" --routing-configuration "[{\"stateMachineVersionArn\": \"${new_version}\", \"weight\":100}]"
echo Done!
exit 0
fi
# find the version to which the alias currently points (the current live version)
old_version=$(${aws} describe-state-machine-alias --state-machine-alias-arn $alias_arn --query "routingConfiguration[?weight==\`100\`].stateMachineVersionArn" --output text)
if [[ -z "${old_version}" ]]; then
if [[ "${force}" = true ]]; then
echo Force setting is true. Will force update to routing config for alias to point 100% to new version.
update_routing "${new_version}" 100
echo Alias ${alias_arn} now pointing 100% to ${new_version}.
echo Done!
exit 0
else
echo Alias ${alias_arn} does not have a routing config entry with 100% of the traffic. This means there might be a deploy in progress, so not starting another deploy at this time. >&2
exit 1
fi
fi
if [[ "${old_version}" == "${new_version}" ]]; then
echo The alias already points to this version. No update necessary.
exit 0
fi
echo Switching ${canary_percentage}% to new version ${new_version}
(( old_weight = 100 - ${canary_percentage} ))
update_routing "${new_version}" ${canary_percentage} "${old_version}" ${old_weight}
echo New version receiving ${canary_percentage}% of traffic.
echo Old version ${old_version} is still receiving ${old_weight}%.
if [[ ${#alarm_names[@]} -eq 0 ]]; then
echo No alarm_names set. Skipping cloudwatch monitoring.
echo Will sleep for ${canary_interval_seconds} seconds before routing 100% to new version.
sleep ${canary_interval_seconds}
echo Canary period complete. Switching 100% of traffic to new version...
else
echo Checking if alarms fire for the next ${canary_interval_seconds} seconds.
(( total_wait = canary_interval_seconds + $(date +%s) ))
now=$(date +%s)
while [[ ((${now} -lt ${total_wait})) ]]; do
alarm_result=$(aws cloudwatch describe-alarms --alarm-names "${alarm_names[@]}" --state-value ALARM --alarm-types "CompositeAlarm" "MetricAlarm" --query "join(', ', [MetricAlarms, CompositeAlarms][].AlarmName)" --output text)
if [[ ! -z "${alarm_result}" ]]; then
echo The following alarms are in ALARM state: ${alarm_result}. Rolling back deploy. >&2
update_routing "${old_version}" 100
echo Rolled back to ${old_version}
exit 1
fi
echo Monitoring alarms...no alarms have triggered.
sleep ${alarm_polling_interval}
now=$(date +%s)
done
echo No alarms detected during canary period. Switching 100% of traffic to new version...
fi
update_routing "${new_version}" 100
echo Version ${new_version} is now receiving 100% of traffic.
if [[ (("${history_max}" -eq 0 ))]]; then
echo Version History deletion is disabled. Remember to prune your history, the default limit is 1000 versions.
echo Done!
exit 0
fi
echo Keep the last ${history_max} versions. Deleting any versions older than that...
# the results are sorted in descending order of the version creation time
version_history=$(${aws} list-state-machine-versions --state-machine-arn ${sm_arn} --max-results 1000 --query "join(\`\"\\n\"\`, stateMachineVersions[].stateMachineVersionArn)" --output text)
counter=0
while read line; do
((counter=${counter} + 1))
if [[ (( ${counter} -gt ${history_max})) ]]; then
echo Deleting old version ${line}
${aws} delete-state-machine-version --state-machine-version-arn ${line}
fi
done <<< "${version_history}"
echo Done!
```
## Verwenden Sie das AWS SDK, um eine neue State-Machine-Version bereitzustellen
Das Beispielskript unter [aws-stepfunctions-examples](https://github.com/aws-samples/aws-stepfunctions-examples/tree/main/gradual-deploy)zeigt, wie das AWS SDK für Python verwendet wird, um den Verkehr schrittweise von einer früheren Version auf eine neue Version einer State Machine zu verlagern. Sie können dieses Beispielskript entweder verwenden oder es entsprechend Ihren Anforderungen aktualisieren.
Das Skript zeigt die folgenden Bereitstellungsstrategien:
+ **Canary** — Verschiebt den Verkehr in zwei Schritten.
Im ersten Schritt wird ein kleiner Prozentsatz des Datenverkehrs, beispielsweise 10 Prozent, auf die neue Version umgestellt. Im zweiten Schritt, bevor ein bestimmtes Zeitintervall in Sekunden abgelaufen ist, wird der verbleibende Verkehr auf die neue Version umgestellt. Die Umstellung auf die neue Version für den verbleibenden Verkehr erfolgt nur, wenn während des angegebenen Zeitintervalls keine CloudWatch Alarme ausgelöst wurden.
+ **Linear oder fortlaufend** — Verschiebt den Verkehr in gleichen Schritten auf die neue Version, wobei zwischen den einzelnen Schritten die gleiche Anzahl von Sekunden liegt.
Wenn Sie beispielsweise die Prozentzahl als **20** Prozentwert für **600** Sekunden angeben, erhöht diese Bereitstellung den Datenverkehr alle 600 Sekunden um 20 Prozent, bis die neue Version 100 Prozent des Datenverkehrs empfängt. `--interval`
Bei dieser Bereitstellung wird die neue Version sofort zurückgesetzt, wenn CloudWatch Alarme ausgelöst werden.
+ **Alles auf einmal oder Blau/Grün** — 100 Prozent des Datenverkehrs werden sofort auf die neue Version umgestellt. Diese Bereitstellung überwacht die neue Version und setzt sie automatisch auf die vorherige Version zurück, wenn CloudWatch Alarme ausgelöst werden.
## Wird verwendet AWS CloudFormation , um eine neue State Machine-Version bereitzustellen
Im folgenden CloudFormation Vorlagenbeispiel werden zwei Versionen einer Zustandsmaschine mit dem Namen veröffentlicht`MyStateMachine`. Es erstellt einen Alias mit dem Namen`PROD`, der auf diese beiden Versionen verweist, und stellt dann die Version `2` bereit.
In diesem Beispiel werden 10 Prozent des Datenverkehrs `2` alle fünf Minuten auf die Version umgestellt, bis diese Version 100 Prozent des Datenverkehrs empfängt. Dieses Beispiel zeigt auch, wie Sie CloudWatch Alarme einstellen können. Wenn einer der von Ihnen eingestellten Alarme in den `ALARM` Status wechselt, schlägt die Bereitstellung fehl und wird sofort zurückgesetzt.
```
MyStateMachine:
Type: AWS::StepFunctions::StateMachine
Properties:
Type: STANDARD
StateMachineName: MyStateMachine
RoleArn: arn:aws:iam::account-id:role/myIamRole
Definition:
StartAt: PassState
States:
PassState:
Type: Pass
Result: Result
End: true
MyStateMachineVersionA:
Type: AWS::StepFunctions::StateMachineVersion
Properties:
Description: Version 1
StateMachineArn: !Ref MyStateMachine
MyStateMachineVersionB:
Type: AWS::StepFunctions::StateMachineVersion
Properties:
Description: Version 2
StateMachineArn: !Ref MyStateMachine
PROD:
Type: AWS::StepFunctions::StateMachineAlias
Properties:
Name: PROD
Description: The PROD state machine alias taking production traffic.
DeploymentPreference:
StateMachineVersionArn: !Ref MyStateMachineVersionB
Type: LINEAR
Percentage: 10
Interval: 5
Alarms:
# A list of alarms that you want to monitor. If any of these alarms trigger, rollback the deployment immediately by pointing 100 percent of traffic to the previous version.
- !Ref CloudWatchAlarm1
- !Ref CloudWatchAlarm2
```