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.

Configuration d'un déploiement de la version Canary de API Gateway

La version Canary est une stratégie de développement logiciel dans laquelle une nouvelle version d'un API (ainsi que d'autres logiciels) est déployée à des fins de test, tandis que la version de base reste déployée en tant que version de production pour les opérations normales au même stade. Dans le cadre de cette documentation, la version de base est désignée sous le nom de version de production. Même si cela est raisonnable, vous êtes libre d'appliquer une version Canary à une version hors production à des fins de test.

Lors du déploiement d'une version Canary, API le trafic total est séparé au hasard entre une version de production et une version Canary avec un ratio préconfiguré. Généralement, la version Canary reçoit un faible pourcentage du API trafic et la version de production absorbe le reste. Les API fonctionnalités mises à jour ne sont visibles que par le API trafic passant par le canari. Vous pouvez ajuster le pourcentage de trafic Canary pour optimiser la couverture ou les performances de test.

En maintenant le trafic Canary à un niveau limité et en conservant la sélection aléatoire, les utilisateurs ne sont pour la plupart jamais perturbés par les bogues éventuels de la nouvelle version, et aucun utilisateur n'est perturbé de façon permanente sur le plan individuel.

Dès lors que les métriques de test ont satisfait à vos exigences, vous pouvez promouvoir la version Canary en version de production et désactiver la Canary dans le déploiement. Les nouvelles fonctions deviennent alors disponibles dans l'étape de production.

Déploiement de la version Canary dans API Gateway

Dans API Gateway, un déploiement de version Canary utilise la phase de déploiement pour la version de production de la version de base d'unAPI, et associe à cette étape une version Canary pour les nouvelles versions, par rapport à la version de base, duAPI. L'étape est associée au déploiement initial et Canary aux déploiements suivants. Au début, la scène et le canari pointent vers la même API version. Tout au long de cette section, nous parlons indifféremment d'étape et de version de production, mais aussi de Canary et de version Canary.

Pour déployer une version API avec Canary, vous devez créer un déploiement de version Canary en ajoutant les paramètres Canary à l'étape d'un déploiement normal. Les paramètres Canary décrivent la version Canary sous-jacente et le stage représente la version de production de cette version au API sein de ce déploiement. Pour ajouter des paramètres Canary, définissez canarySettings pour l'étape de déploiement et spécifiez les éléments suivants :

Du moment qu'une version Canary est activée, l'étape de déploiement ne peut pas être associée à un autre déploiement de version non Canary tant que la version Canary n'est pas désactivée et que les paramètres Canary ne sont pas supprimés de l'étape.

Lorsque vous activez la journalisation des API exécutions, la version Canary possède ses propres journaux et métriques générés pour toutes les requêtes Canary. Ils sont signalés à un groupe de CloudWatch journaux Logs en phase de production ainsi qu'à un groupe de CloudWatch journaux Logs spécifique à Canary. Il en va de même pour la journalisation d'accès. Les journaux spécifiques à Canary sont utiles pour valider les nouvelles API modifications et décider d'accepter les modifications et de promouvoir la version de Canary au stade de production, ou de supprimer les modifications et de revenir à la version Canary depuis la phase de production.

Le groupe de journaux d'exécution s'intitule API-Gateway-Execution-Logs/{rest-api-id}/{stage-name} dans le cas de l'étape de production et API-Gateway-Execution-Logs/{rest-api-id}/{stage-name}/Canary dans le cas de la version Canary. Pour la journalisation d'accès, vous devez créer un groupe de journaux ou en choisir un existant. Le nom du groupe de journaux d'accès de la version Canary est assorti du suffixe /Canary, qui est ajouté au nom du groupe de journaux sélectionné.

Une version de Canary peut utiliser le cache de stage, s'il est activé, pour stocker les réponses et utiliser les entrées mises en cache pour renvoyer les résultats aux prochaines requêtes Canary, dans un délai préconfiguré time-to-live (TTL).

Dans un déploiement de version Canary, la version de production et la version Canary de la API peuvent être associées à la même version ou à des versions différentes. Lorsqu'elles sont associés à des versions différentes, les réponses concernant les demandes de production et Canary sont mises en cache séparément et le cache d'étape renvoie les résultats correspondant aux demandes de production et Canary. Lorsque la version de production et la version Canary sont associées à un même déploiement, le cache d'étape utilise une seule clé de cache pour les deux types de demande et renvoie la même réponse aux mêmes demandes de la version de production et de la version Canary.