Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Création d'un déploiement de version Canary

Vous créez un déploiement de version Canary lorsque vous déployez les paramètres API avec Canary en tant qu'entrée supplémentaire pour l'opération de création du déploiement.

Vous pouvez également créer un déploiement de version Canary à partir d'un déploiement non Canary existant en formulant une demande stage:update de façon à ajouter les paramètres Canary à l'étape.

Au moment de créer un déploiement de version non Canary, vous pouvez spécifier un nom d'étape qui n'existe pas. APIGateway en crée un si le stage spécifié n'existe pas. En revanche, nous ne pouvez pas spécifier le nom d'une étape qui n'existe pas au moment de créer un déploiement de version Canary. Vous recevrez un message d'erreur et API Gateway ne créera aucun déploiement de la version Canary.

Vous pouvez créer un déploiement de version Canary dans API Gateway à l'aide de la console API Gateway AWS CLI, du ou d'un AWS SDK.

Créez un déploiement Canary à l'aide de la console API Gateway

Pour utiliser la console API Gateway afin de créer un déploiement de la version Canary, suivez les instructions ci-dessous :

Une fois la version de Canary initialisée lors de la phase de déploiement, vous modifiez API et souhaitez tester les modifications. Vous pouvez le redéployer API vers la même étape afin que la version mise à jour et la version de base soient accessibles via la même étape. Les étapes suivantes expliquent comment procéder.

Par conséquent, la version de Canary pointe vers la dernière version tandis que la version de production pointe toujours vers la version initiale duAPI. Le canarySettingsnow a une nouvelle deploymentIdvaleur, tandis que le stage a toujours la deploymentIdvaleur initiale. En arrière-plan, la console appelle stage:update.

Créez un déploiement Canary à l'aide du AWS CLI

Dans un premier temps, créez un déploiement de base avec deux variables d'étape, mais sans Canary :

aws apigateway create-deployment \
    --variables sv0=val0,sv1=val1 \
    --rest-api-id abcd1234 \
    --stage-name 'prod' \

La commande renvoie une représentation de la ressource Deployment obtenue, comme dans l'exemple suivant :

{
    "id": "du4ot1", 
    "createdDate": 1511379050
}

Le déploiement qui en résulte id identifie un instantané (ou une version) duAPI.

À présent, créez un déploiement Canary au niveau de l'étape prod :

aws apigateway create-deployment  --rest-api-id abcd1234 \
    --canary-settings \ 
    '{
        "percentTraffic":10.5,
        "useStageCache":false,
        "stageVariableOverrides":{
            "sv1":"val2", 
            "sv2":"val3"
        } 
    }' \
    --stage-name 'prod'

Si l'étape spécifiée (prod) n'existe pas, la commande précédente renvoie une erreur. Dans le cas contraire, elle renvoie une représentation de la nouvelle ressource deployment créée comparable à l'exemple suivant :

{
    "id": "a6rox0", 
    "createdDate": 1511379433
}

Le déploiement qui en résulte id identifie la version de test de la version API for the Canary. En conséquence, l'étape associée est activée pour Canary. Vous pouvez afficher cette représentation d'étape en appelant la commande get-stage, comme dans l'exemple suivant :

aws apigateway get-stage --rest-api-id acbd1234 --stage-name prod

L'exemple suivant montre une représentation de Stage comme sortie de la commande :

{
    "stageName": "prod", 
    "variables": {
        "sv0": "val0", 
        "sv1": "val1"
    }, 
    "cacheClusterEnabled": false, 
    "cacheClusterStatus": "NOT_AVAILABLE", 
    "deploymentId": "du4ot1", 
    "lastUpdatedDate": 1511379433, 
    "createdDate": 1511379050, 
    "canarySettings": {
        "percentTraffic": 10.5, 
        "deploymentId": "a6rox0", 
        "useStageCache": false, 
        "stageVariableOverrides": {
            "sv2": "val3", 
            "sv1": "val2"
        }
    }, 
    "methodSettings": {}
}

Dans cet exemple, la version de base de API utilisera les variables d'étape de{"sv0":val0", "sv1":val1"}, tandis que la version de test utilise les variables d'étape de{"sv1":val2", "sv2":val3"}. La version de production et la version Canary utilisent toutes les deux la même variable d'étape sv1, mais avec des valeurs différentes : val1 et val2, respectivement. La variable d'étape sv0 est seulement utilisée dans la version de production, alors que la variable d'étape sv2 est utilisée dans la version Canary uniquement.

Vous pouvez créer un déploiement de version Canary à partir d'un déploiement standard existant en mettant à jour l'étape de façon à activer une version Canary. En guise de démonstration, créez d'abord un déploiement standard :

aws apigateway create-deployment \
    --variables sv0=val0,sv1=val1 \  
    --rest-api-id abcd1234 \
    --stage-name 'beta'

La commande renvoie une représentation du déploiement de la version de base :

{
    "id": "cifeiw", 
    "createdDate": 1511380879
}

L'étape bêta associée ne présente pas de paramètres Canary :

{
    "stageName": "beta", 
    "variables": {
        "sv0": "val0", 
        "sv1": "val1"
    }, 
    "cacheClusterEnabled": false, 
    "cacheClusterStatus": "NOT_AVAILABLE", 
    "deploymentId": "cifeiw", 
    "lastUpdatedDate": 1511380879, 
    "createdDate": 1511380879, 
    "methodSettings": {}
}

À présent, créez un déploiement de version Canary en attachant une version Canary au niveau de l'étape :

aws apigateway update-stage \
    --rest-api-id abcd1234 \
    --stage-name 'beta' \
    --patch-operations '[{
            "op": "replace",
            "value": "0.0",
            "path": "/canarySettings/percentTraffic"
        }, {
            "op": "copy",
            "from": "/canarySettings/stageVariableOverrides",
            "path": "/variables"
        }, {
            "op": "copy",
            "from": "/canarySettings/deploymentId",
            "path": "/deploymentId"
        }]'

Voici une représentation de l'étape mise à jour :

{
    "stageName": "beta", 
    "variables": {
        "sv0": "val0", 
        "sv1": "val1"
    }, 
    "cacheClusterEnabled": false, 
    "cacheClusterStatus": "NOT_AVAILABLE", 
    "deploymentId": "cifeiw", 
    "lastUpdatedDate": 1511381930, 
    "createdDate": 1511380879, 
    "canarySettings": {
        "percentTraffic": 10.5, 
        "deploymentId": "cifeiw", 
        "useStageCache": false, 
        "stageVariableOverrides": {
            "sv2": "val3", 
            "sv1": "val2"
        }
    }, 
    "methodSettings": {}
}

Comme nous venons d'activer un Canary sur une version existante duAPI, la version de production (Stage) et la version Canary (canarySettings) pointent vers le même déploiement, c'est-à-dire la même version (deploymentId) duAPI. Une fois que vous l'aurez API modifiée et que vous l'aurez redéployée à ce stade, la nouvelle version figurera dans la version Canary, tandis que la version de base restera dans la version de production. Cela se manifeste dans l'évolution de l'étape lorsque deploymentId est mis à jour dans la version Canary avec le nouvel id de déploiement et que deploymentId reste inchangé dans la version de production.