View a markdown version of this page

Modèles de déploiement - AWS Lambda

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.

Modèles de déploiement

Pour publier une nouvelle version de votre application AWS Lambda Web Function, vous devez créer une nouvelle révision. Les points de terminaison sont autoDeploymentMode configurés pour LatestRevisionacheminer tout le trafic vers celui-ci une fois qu'il est devenu actif. Les points de terminaison autoDeploymentMode définis sur Désactivé continuent de diffuser leurs révisions actuelles jusqu'à ce que vous mettiez à jour les pondérations de révision. Vous contrôlez la manière dont le trafic passe de la révision actuelle à la nouvelle à l'aide du mode de déploiement automatique du terminal et des pondérations de révision. Les sections suivantes expliquent à la fois les modes de déploiement automatique, les modèles de déploiement courants (canari, bleu-vert et rollback) et les règles qui régissent les pondérations de révision.

Les modifications apportées aux points autoDeploymentMode de terminaison revisionWeights sont des mises à jour asynchrones. Attendez updateStatus de devenir Successful avant d'évaluer le déploiement ou de soumettre une autre mise à jour du terminal. En cas d'échec d'une mise à jour, updateStatusReason décrit la cause.

Le schéma suivant montre un déploiement Canary sur un terminal dont le mode de déploiement automatique est désactivé. Chaque modification de poids est une mise à jour asynchrone du point de terminaison.

  1. La révision 1 commence avec 100 % du trafic.

  2. Vous acheminez 10 % du trafic vers la révision 2 et vous le surveillez.

  3. Si la révision 2 passe avec succès vos vérifications, vous acheminez tout le trafic vers elle.

  4. Si la révision 2 échoue, vous redéfinissez les pondérations sur la révision 1 à 100 %.

Déploiement de Canary qui déplace le trafic de la révision 1 à la révision 2, avec un chemin de restauration vers la révision 1.

Auto-deployment modes

Le autoDeploymentMode paramètre d'un point de terminaison contrôle si Lambda achemine automatiquement le trafic vers les nouvelles révisions lors du déploiement. Vous le définissez lorsque vous créez le point de terminaison, et vous pouvez le modifier sur un point de terminaison existant.

Si vous omettezautoDeploymentMode, la valeur par défaut est. Disabled LatestRevisionn'est pris en charge que pour les HomeRegion points de terminaison, donc MultiRegion et les PerRegion points de terminaison l'utilisent toujours. Disabled Lors de l'utilisationDisabled, vous le définissez revisionWeights sur le point de terminaison, comme décrit dansPondérations de révision.

LatestRevision

Chaque fois qu'une nouvelle révision devient active, Lambda achemine 100 % du trafic du point de terminaison vers celle-ci. Vous n'avez pas besoin de mettre à jour les pondérations de révision et vous ne pouvez pas définir de pondérations de révision lorsque le point final est dans ce mode. Utilisez ce mode pour les environnements de développement et de préparation dans lesquels vous souhaitez un déploiement automatique sans intervention manuelle.

Désactivé

Lambda ne modifie pas le routage du trafic lorsque vous créez une nouvelle révision. Vous contrôlez le routage du trafic manuellement en définissant des pondérations de révision. Utilisez ce mode pour les environnements de production dans lesquels vous souhaitez contrôler le déploiement de nouvelles révisions à l'aide de modèles de déploiement Canary ou Blue-Green.

Pour modifier le mode de déploiement automatique (AWS CLI)
  1. Utilisez le AWS Command Line Interface (AWS CLI) pour mettre à jour le point de terminaison et désactiver le déploiement automatique.

    aws lambda-web update-web-function-endpoint \ --function-name my-web-app \ --endpoint-name my-endpoint \ --auto-deployment-mode Disabled
  2. Attendez que la mise à jour du terminal soit terminée.

    aws lambda-web wait web-function-endpoint-updated \ --function-name my-web-app \ --endpoint-name my-endpoint

Basculement entre les modes

Lorsque vous passez de Disabled LatestRevisionà Disabled sans spécifier de pondération de révision, le routage actuel du trafic reste inchangé une fois la mise à jour réussie. La révision vers laquelle le terminal acheminait le trafic avant la mise à jour continue de recevoir 100 % du trafic, même après que vous ayez créé de nouvelles révisions. Il conserve ce trafic jusqu'à ce que vous mettiez à jour les pondérations de révision. Vous pouvez également changer de mode et définir les poids de révision dans la même UpdateWebFunctionEndpoint demande.

Lorsque vous passez de Disabled à LatestRevision, Lambda met à jour le point de terminaison pour acheminer 100 % du trafic vers la dernière révision. La dernière révision doit être active. Si elle est en attente ou en échec, la demande échoue avec une erreur de conflit. Une fois la mise à jour réussie, les pondérations de révision précédemment configurées ne s'appliquent plus.

Pondérations de révision

Lorsque le mode de déploiement automatique est désactivé, vous contrôlez le routage du trafic en attribuant des pondérations aux révisions. Lambda répartit le trafic entre les révisions proportionnellement à leur pondération.

Les pondérations de révision sont un paramètre du point de terminaison (la revisionWeights propriété), que vous pouvez modifierUpdateWebFunctionEndpoint. Ils ne constituent pas un paramètre de révision.

Les pondérations de révision suivent les règles suivantes :

  • Chaque poids est un entier compris entre 1 et 100.

  • La somme des poids d'une demande doit être exactement égale à 100.

  • Chaque révision ne peut apparaître qu'une seule fois dans les pondérations.

  • Chaque révision des pondérations doit être à l'état Actif lorsque vous définissez les pondérations. Dans le cas contraire, l'API rejette la demande.

  • Un point de terminaison achemine le trafic vers un maximum de deux révisions en même temps.

  • Aucun poids n'a de valeur par défaut. Pour acheminer tout le trafic vers une seule révision, spécifiez uniquement cette révision avec une pondération de 100. Une révision qui ne figure pas dans les pondérations ne reçoit aucun trafic en provenance de ce point de terminaison.

Les identifiants de révision sont générés par Lambda lorsque vous créez une révision. Pour trouver les identifiants de révision de votre fonction Web, utilisez la commande suivante :

aws lambda-web list-web-function-revisions \ --function-name my-web-app

La réponse répertorie les révisions du plus récent au plus ancien, y compris leurs identifiants, leurs horodatages de création et leur état actuel.

Modèles de déploiement

Les modèles de déploiement suivants utilisent des pondérations de révision pour contrôler le transfert du trafic entre votre révision actuelle et une nouvelle révision. Ces modèles nécessitent que le mode de déploiement automatique du point de terminaison (le paramètre du point de autoDeploymentMode terminaison) soit désactivé. Le point de terminaison créé par la aws lambda-web deploy commande utilise LatestRevision. Pour utiliser ces modèles sur ce point de terminaison, basculez-le d'abord sur Disabled, comme indiqué dansAuto-deployment modes.

Déploiement Canary

Un déploiement de Canary envoie un faible pourcentage du trafic vers la nouvelle révision afin que vous puissiez détecter les erreurs avant d'acheminer tout le trafic. Si la nouvelle révision présente des problèmes, seule une petite partie des demandes est affectée.

Pour effectuer un déploiement Canary (AWS CLI)
  1. Créez une nouvelle révision avec votre code mis à jour.

    aws lambda-web create-web-function-revision \ --function-name my-web-app \ --build-config '{ "codeConfig": { "s3Object": { "bucket": "my-bucket", "key": "my-app-v2.zip" } }, "runtimeConfig": { "runtime": "nodejs24.x" } }' \ --service-config '{ "executionRoleArn": "arn:aws:iam::111122223333:role/my-web-function-role" }'

    Notez l'identifiant de révision dans la réponse.

    Une nouvelle révision ne copie pas les paramètres de la révision actuelle. Tout serviceConfig paramètre que vous omettez prend sa valeur par défaut, par exemple 30 et aucune variable timeoutSeconds d'environnement. Incluez tous les paramètres utilisés par la révision en coursenvironmentVariables, tels quetimeoutSeconds,maxConcurrencyPerEnvironment, ettelemetryConfig. Pour voir la configuration de la révision actuelle, exécutezaws lambda-web get-web-function-revision.

  2. Patientez jusqu'à ce que la nouvelle révision soit active. L'API rejette les pondérations de révision qui font référence à une révision qui n'est pas active.

    aws lambda-web wait web-function-revision-active \ --function-name my-web-app \ --revision-id rev-def45
  3. Acheminez 10 % du trafic vers la nouvelle révision et 90 % vers la révision actuelle.

    aws lambda-web update-web-function-endpoint \ --function-name my-web-app \ --endpoint-name my-endpoint \ --revision-weights '[{"revisionId": "rev-abc12", "weight": 90}, {"revisionId": "rev-def45", "weight": 10}]'
  4. Attendez que la mise à jour du terminal soit terminée.

    aws lambda-web wait web-function-endpoint-updated \ --function-name my-web-app \ --endpoint-name my-endpoint
  5. Surveillez la nouvelle révision via les journaux des applications ou des métriques personnalisées. Incluez-y un identifiant de construction ou de révision que vous contrôlez. Les métriques des fonctions Web n'incluent pas de dimension de révision. Par conséquent, ils ne peuvent pas séparer les erreurs Canary des erreurs de la révision en cours. Pour plus de détails, consultez Utilisation de CloudWatch métriques avec les fonctions Web Lambda. Si le canari atteint les seuils d'erreur et de latence que vous avez définis avant le déploiement, augmentez son poids.

    aws lambda-web update-web-function-endpoint \ --function-name my-web-app \ --endpoint-name my-endpoint \ --revision-weights '[{"revisionId": "rev-abc12", "weight": 50}, {"revisionId": "rev-def45", "weight": 50}]'
  6. Attendez que la mise à jour du terminal soit terminée.

    aws lambda-web wait web-function-endpoint-updated \ --function-name my-web-app \ --endpoint-name my-endpoint
  7. Lorsque vous êtes certain que la nouvelle révision est saine, acheminez tout le trafic vers celle-ci.

    aws lambda-web update-web-function-endpoint \ --function-name my-web-app \ --endpoint-name my-endpoint \ --revision-weights '[{"revisionId": "rev-def45", "weight": 100}]'
  8. Attendez que la mise à jour du terminal soit terminée.

    aws lambda-web wait web-function-endpoint-updated \ --function-name my-web-app \ --endpoint-name my-endpoint

Blue-green déploiement

Un déploiement bleu-vert conserve le trafic de la révision actuelle pendant que vous validez la nouvelle révision, puis fait passer tout le trafic vers la nouvelle révision dans une seule mise à jour du point de terminaison. La procédure suivante permet de valider avec une répartition uniforme du trafic. Pour valider sans trafic de production, utilisez un point de terminaison de test distinct, comme décrit dansConsidérations relatives au déploiement.

Pour effectuer un déploiement bleu-vert (AWS CLI)
  1. Créez une nouvelle révision avec votre code mis à jour et attendez qu'elle soit active. Utilisez les mêmes commandes que celles indiquées dans la procédure de déploiement de Canary précédente.

  2. Répartissez le trafic de manière égale entre les deux révisions.

    aws lambda-web update-web-function-endpoint \ --function-name my-web-app \ --endpoint-name my-endpoint \ --revision-weights '[{"revisionId": "rev-abc12", "weight": 50}, {"revisionId": "rev-def45", "weight": 50}]'
  3. Attendez que la mise à jour du terminal soit terminée.

    aws lambda-web wait web-function-endpoint-updated \ --function-name my-web-app \ --endpoint-name my-endpoint
  4. Surveillez les deux révisions via les journaux des applications ou des métriques personnalisées. Incluez-y un identifiant de construction ou de révision que vous contrôlez. Lorsque la nouvelle révision répond aux critères d'intégrité que vous avez définis avant le déploiement, acheminez tout le trafic vers celle-ci.

    aws lambda-web update-web-function-endpoint \ --function-name my-web-app \ --endpoint-name my-endpoint \ --revision-weights '[{"revisionId": "rev-def45", "weight": 100}]'
  5. Attendez que la mise à jour du terminal soit terminée.

    aws lambda-web wait web-function-endpoint-updated \ --function-name my-web-app \ --endpoint-name my-endpoint

Faire marche arrière

Si vous détectez des problèmes liés à une nouvelle révision (taux d'erreur élevés, latence accrue), vous pouvez revenir en arrière avec une seule mise à jour du point de terminaison qui achemine tout le trafic vers la révision précédente, dont le fonctionnement a été vérifié.

Revenir en LatestRevision mode

Lorsque le mode de déploiement automatique d'un point de terminaison est activé LatestRevision, une demande qui définit uniquement les pondérations de révision échoue. La procédure suivante définit le mode de déploiement automatique sur Désactivé et les pondérations de révision dans la même demande, afin que cela fonctionne dans les deux modes.

Le point de terminaison reste ensuite en mode désactivé jusqu'à ce que vous le modifiiez.

Pour revenir à une révision précédente (AWS CLI)
  1. Mettez à jour le point de terminaison pour acheminer 100 % du trafic vers la version dont le fonctionnement a été vérifié et définissez le mode de déploiement automatique sur Disabled.

    aws lambda-web update-web-function-endpoint \ --function-name my-web-app \ --endpoint-name my-endpoint \ --auto-deployment-mode Disabled \ --revision-weights '[{"revisionId": "rev-abc12", "weight": 100}]'
  2. Attendez que la mise à jour du terminal soit terminée.

    aws lambda-web wait web-function-endpoint-updated \ --function-name my-web-app \ --endpoint-name my-endpoint

Une fois la mise à jour réussie, Lambda arrête d'acheminer les nouvelles demandes vers la révision problématique. In-flight les demandes relatives à cette révision se terminent normalement. Pour plus d'informations sur l'état de mise à jour des terminaux, consultezÉtats de point de terminaison.

Si la révision à laquelle vous revenez ne comporte que peu ou pas d'environnements d'exécution en cours d'exécution, Lambda la fait évoluer au fur et à mesure que le trafic s'y déplace. Les demandes peuvent attendre l'initialisation des environnements d'exécution, ce qui augmente le temps de latence. Les demandes peuvent toujours échouer en raison d'échecs de démarrage, de la limite de débit ou du nombre maximal d'environnements du point de terminaison, ou du quota de vCPU du compte. Certains de ces échecs renvoient des réponses HTTP 429.

Considérations relatives au déploiement

Qu'est-ce qui déclenche une nouvelle révision ?

Lambda crée une nouvelle révision lorsque vous appelez. CreateWebFunctionRevision Cela inclut le déploiement d'un nouveau code d'application et la modification des paramètres de configuration tels que le délai d'expiration, la simultanéité ou les variables d'environnement. Chaque modification produit une révision immuable.

Puis-je tester une nouvelle révision avant d'y acheminer le trafic de production ?

Oui. Vous ne pouvez appeler une révision que par le biais d'un point de terminaison. Il existe donc deux approches :

  • Point de terminaison de test dédié : créez un point de terminaison distinct pour les tests. Acheminez d'abord le trafic vers la nouvelle révision sur le point de terminaison de test (en définissant les poids de révision du point de terminaison de test), validez-le, puis mettez à jour les poids du point de terminaison de production pour inclure la nouvelle révision.

  • Poids minimal : attribuez à la nouvelle révision une pondération de 1 % sur le point final de production. Cela envoie une petite fraction du trafic de production vers la nouvelle révision afin que vous puissiez surveiller les erreurs avec un impact minimal sur le client.

Qu'arrive-t-il aux révisions qui ne sont pas incluses dans les pondérations de révision ?

Une révision qui ne figure pas dans les pondérations de révision d'un point de terminaison ne reçoit aucun trafic en provenance de ce point de terminaison. Un autre point de terminaison de la même fonction Web peut toujours y accéder. La révision reste active jusqu'à ce que vous la supprimiez ou jusqu'à ce qu'un nettoyage automatique la supprime. Il passe au statut Failed si Lambda perd l'accès à son objet Amazon S3. Pour le nettoyage automatique, voirLimites de révision et nettoyage automatique.

Comment puis-je identifier la révision la plus récente ?

Appelez ListWebFunctionRevisions. La réponse répertorie les révisions par ordre décroissant decreatedAt, de sorte que la première révision de la liste est la plus récente.

Puis-je supprimer un point de terminaison pendant qu'il achemine du trafic ?

Oui. Lorsque vous supprimez un point de terminaison, Lambda arrête d'acheminer les nouvelles demandes vers ce point de terminaison et les demandes adressées au nom de domaine du point de terminaison sont rejetées une fois que la suppression prend effet. Les révisions elles-mêmes ne sont pas affectées et peuvent toujours être utilisées par d'autres points de terminaison.

Puis-je supprimer une révision alors qu'elle reçoit du trafic ?

Non Si un point de terminaison achemine le trafic vers la révision, y compris lorsque la regionalEndpoints propriété d'un point de PerRegion terminaison MultiRegion ou d'un point de terminaison fait référence à la révision, la DeleteWebFunctionRevision demande échoue avec une erreur de conflit. Pour supprimer la révision, mettez d'abord à jour les poids de révision du point de terminaison afin de le supprimer du routage du trafic sur chaque point de terminaison, puis supprimez-le. Comme Lambda bloque la suppression alors qu'une pondération est attribuée à une révision, la suppression d'une révision ne modifie jamais la distribution du trafic d'un point de terminaison.