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
La création d'un déploiement de version Canary consiste à déployer l'API en ajoutant en entrée les paramètres Canary à 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. Dans ce cas, API Gateway crée l'étape. 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 obtenez dans ce cas une erreur et API Gateway ne crée pas le 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, de la AWS CLI ou d'un kit SDK AWS.
Rubriques
Création d'un déploiement Canary à l'aide de la console API Gateway
Pour créer un déploiement de version Canary à l'aide de la console API Gateway, suivez les instructions ci-dessous :
Pour créer le déploiement initial d'une version Canary
-
Connectez-vous à la console API Gateway.
-
Choisissez une API REST existante ou créez-en une.
-
Dans le volet de navigation principal, choisissez Resources, puis Déployer l'API. Suivez les instructions à l'écran dans Deploy API pour déployer l'API dans une nouvelle étape.
À ce stade, vous avez déployé l'API dans une étape de version de production. La prochaine étape va consister à configurer les paramètres Canary au niveau de l'étape et, si nécessaire, à activer la mise en cache, à définir des variables d'étape ou à configurer des journaux d'accès ou d'exécution d'API.
-
Pour activer la mise en cache de l'API ou associer une liste ACL web AWS WAF à l'étape, dans la section Détails de l'étape, choisissez Modifier. Pour plus d’informations, consultez Paramètres de cache pour les API REST dans API Gateway ou Pour associer une ACL AWS WAF Web à un stage d'API API Gateway à l'aide de la console API Gateway.
-
Pour configurer la journalisation d'exécution ou d'accès, dans la section Journaux et suivi, choisissez Modifier et suivez les instructions à l'écran. Pour de plus amples informations, veuillez consulter Configuration de la CloudWatch journalisation pour les API REST dans API Gateway.
-
Pour définir des variables d'étape, choisissez l'onglet Variables d'étape, puis suivez les instructions à l'écran pour ajouter ou modifier des variables d'étape. Pour de plus amples informations, veuillez consulter Utiliser des variables d'étape pour un REST API in API Gateway.
-
Choisissez l'onglet Canary, puis choisissez Créer Canary. Vous devrez peut-être choisir la flèche droite pour afficher l'onglet Canary.
-
Sous Paramètres Canary, pour Canary, entrez le pourcentage de demandes à renvoyer vers le canary.
-
Si vous le souhaitez, sélectionnez Cache d'étape pour activer la mise en cache pour la version canary. Le cache n'est pas accessible à la version Canary tant que la mise en cache d'API n'est pas activée.
-
Pour remplacer les variables d'étape existantes, pour Remplacement canary, entrez une nouvelle valeur de variable d'étape.
Une fois la version Canary initialisée dans l'étape de déploiement, vous pouvez modifier l'API et tester les modifications. Vous pouvez redéployer l'API dans la même étape pour pouvoir accéder à la version mise à jour et à la version de base via la même étape. Les étapes suivantes expliquent comment procéder.
Pour déployer la dernière version d'API dans une version Canary
-
À chaque mise à jour de l'API, choisissez Déployer l'API.
-
Dans Déployer l'API, choisissez l'étape qui contient un canary dans la liste déroulante Étape de déploiement.
-
(Facultatif) Entrez une description pour Description du déploiement.
-
Choisissez Deploy pour transférer (en mode push) la dernière version d'API vers la version Canary.
-
Si vous le souhaitez, reconfigurez les paramètres d'étape, les journaux ou les paramètres Canary, comme indiqué dans Pour créer le déploiement initial d'une version Canary.
En conséquence, la version Canary pointe vers la dernière version, alors que la version de production continue de pointer vers la version initiale de l'API. La propriété canarySettings affiche désormais une nouvelle valeur deploymentId, alors que l'étape présente toujours la valeur deploymentId initiale. En arrière-plan, la console appelle stage:update.
Création d'un déploiement Canary à l'aide de l 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 }
L'id de déploiement obtenu identifie un instantané (ou une version) de l'API.
À 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 }
L'id de déploiement obtenu identifie la version de test de l'API pour la version 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 l'API utilise les variables d'étape {"sv0":val0", "sv1":val1"}, tandis que la version de test utilise les variables d'étape {"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 une version Canary dans une version existante de l'API, la version de production (Stage) et la version Canary (canarySettings) pointent toutes les deux vers le même déploiement, c'est-à-dire la même version (deploymentId) de l'API. Une fois que vous avez modifié l'API et que vous l'avez redéployée dans cette étape, la nouvelle version se trouve dans la version Canary, alors que la version de base reste 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.
