Mises à jour propagées de la configuration de l'environnement Elastic Beanstalk

Lorsqu'une modification de configuration nécessite de remplacer les instances, Elastic Beanstalk peut effectuer la mise à jour par lots afin d'éviter les temps d'arrêt pendant que la modification est propagée. Pendant une mise à jour propagée, la capacité est réduite uniquement de la taille d'un seul lot, que vous pouvez configurer. Elastic Beanstalk prend un lot d'instances hors service, le résilie, puis lance un lot avec la nouvelle configuration. Une fois que le nouveau lot commence à traiter les demandes, Elastic Beanstalk passe au lot suivant.

Les lots de mise à jour de configuration peuvent être traités périodiquement (en fonction du temps), avec un délai entre chaque lot, ou sur selon l'intégrité. Pour les mises à jour propagées basées sur le temps, vous pouvez configurer la durée d'attente pour Elastic Beanstalk, après le lancement d'un lot d'instances avant de passer au lot suivant. Ce temps d'interruption permet à votre application d'amorcer et de commencer à traiter les demandes.

Avec des mises à jour propagées basées sur l'état, Elastic Beanstalk attend que des instances dans un lot transmettent des vérifications de l'état avant de passer au lot suivant. L'intégrité d'une instance est déterminée par le système de création de rapports d'intégrité, qui peut être de base ou améliorée. Avec l'état de base, un lot est considéré comme sain dès que toutes les instances qu'il contient passent les vérifications de l'état Elastic Load Balancing (ELB).

Avec la création de rapports d'état amélioré, toutes les instances dans un lot doivent réussir plusieurs vérifications de l'état consécutives avant qu'Elastic Beanstalk passe au lot suivant. Outre les vérifications de l'état ELB, qui ne vérifient que vos instances, les rapports améliorés sur l'état de santé surveillent les journaux d'application et l'état des autres ressources de votre environnement. Dans un environnement de serveur web à l'intégrité améliorée, toutes les instances doivent réussir 12 vérifications de l'état au cours des deux minutes (18 vérifications au cours des trois minutes pour les environnements de travail). Si une instance échoue à une vérification de l'état, le nombre se réinitialise.

Si un lot ne devient pas sain dans le délai de mise à jour propagée (la valeur par défaut est de 30 minutes), la mise à jour est annulée. L'expiration de la mise à jour propagée est une option de configuration qui est disponible dans l'espace de noms aws:autoscaling:updatepolicy:rollingupdate. Si votre application ne réussit pas les vérifications de l'état avec le statut Ok mais qu'elle est stable à un autre niveau, vous pouvez définir l'option HealthCheckSuccessThreshold dans l'espace de noms aws:elasticbeanstalk:healthreporting:system afin de modifier le niveau auquel Elastic Beanstalk considère une instance comme étant saine.

Si le processus de mise à jour propagée échoue, Elastic Beanstalk commence une autre mise à jour propagée pour restaurer la configuration précédente. Une mise à jour propagée peut échouer en raison de vérifications de l'état ayant échoué, ou si le lancement de nouvelles instances vous conduit à dépasser les quotas de votre compte. Si vous atteignez le quota du nombre d'instances Amazon EC2, par exemple, la mise à jour propagée peut échouer lorsqu'elle tente d'allouer un lot de nouvelles instances. Dans ce cas, la restauration échoue également.

Si la restauration échoue, le processus de mise à jour est interrompu et votre environnement reste défaillant. Les lots non traités continuent à exécuter des instances avec l'ancienne configuration, tandis que les lots qui ont été traités correctement disposent de la nouvelle configuration. Pour réparer un environnement après une restauration qui a échoué, commencez par résoudre le problème sous-jacent qui a provoqué l'échec de la mise à jour, puis lancez une autre mise à jour de l'environnement.

Une autre méthode consiste à déployer la nouvelle version de votre application dans un environnement différent, puis à effectuer une permutation CNAME pour rediriger le trafic sans interruption. Pour en savoir plus, consultez Déploiements bleu/vert avec Elastic Beanstalk.

Mises à jour propagées et déploiements propagés

Des mises à jour propagées se produisent lorsque vous modifiez des paramètres qui ont besoin que de nouvelles instances Amazon EC2 soient mises en service pour votre environnement. Cela inclut des modifications apportées à la configuration du groupe Auto Scaling, telles que le type d'instance et des paramètres de paire de clés et les modifications apportées aux paramètres VPC. Dans une mise à jour propagée, chaque lot d'instances est résilié avant l'allocation d'un nouveau lot pour le remplacer.

Les déploiements propagés se produisent lorsque vous déployez votre application, et peuvent généralement être effectués sans remplacer d'instances dans votre environnement. Elastic Beanstalk met chaque lot hors service, déploie la nouvelle version de l'application, puis le remet en service.

L'exception à cela est si vous modifiez les paramètres qui ont besoin de remplacement d'instance en même temps vous déployez une nouvelle version de l'application. Par exemple, si vous modifiez les paramètres de nom de clé dans un fichier de configuration dans votre bundle source et que vous les déployez dans votre environnement, vous déclenchez une mise à jour propagée. Au lieu de déployer votre nouvelle version de l'application dans chaque lot d'instances existantes, un nouveau lot d'instances est fourni avec la nouvelle configuration. Dans ce cas, aucun déploiement distinct ne se produit, car les nouvelles instances sont installées avec la nouvelle version de l'application.

Chaque fois que de nouvelles instances sont déployées dans le cadre d'une mise à jour de l'environnement, une phase de déploiement est effectuée, au cours de laquelle le code source de votre application est déployé dans les nouvelles instances et tous les paramètres de configuration modifiant le système d'exploitation ou le logiciel sur les instances sont appliqués. Les paramètres de vérification de l'état du déploiement (Ignorer la vérification de l'état, Seuil de bonne santé et Délai de commande) s'appliquent également aux mises à jour propagées basées sur l'intégrité et aux mises à jour immuables lors de la phase de déploiement.

Configuration des mises à jour propagées

Vous pouvez activer et configurer les mises à jour propagées dans la console Elastic Beanstalk.

Pour activer des mises à jour propagées

1. Ouvrez la console Elastic Beanstalk et, dans la liste Regions (Régions), sélectionnez votre Région AWS.

2. Dans le panneau de navigation, choisissez Environments (Environnements), puis choisissez le nom de votre environnement dans la liste.

   Note

   Si vous avez plusieurs environnements, utilisez la barre de recherche pour filtrer la liste des environnements.

3. Dans le panneau de navigation, choisissez Configuration.

4. Dans la catégorie de configuration Rolling updates and deployments (Propagation des mises à jour et déploiements), choisissez Edit (Modifier).

5. Dans la section Mises à jour de la configuration, pour Propagation du type de mises à jour, sélectionnez l'une des options Propagation.

   

6. Choisissez Taille de lot, Capacité minimale et les paramètres Temps d'interruption.

7. Pour enregistrer les modifications, cliquez sur Appliquer en bas de la page.

La section Mises à jour de la configuration de la page Propagation des mises à jour et déploiements propose les options suivantes pour la propagation des mises à jour :

• Rolling update type (Propagation du type de mise à jour) – Elastic Beanstalk attend la fin de la mise à jour d'un lot d'instances avant de passer au lot suivant, afin de permettre à ces instances de finaliser l'action d'amorçage et de commencer à traiter le trafic. Choisissez parmi les options suivantes :

  • Rolling based on Health (Propagation en fonction de la santé) – Patientez jusqu'à ce que les instances dans le lot actuel soient saines avant de mettre des instances en service et de démarrer le lot suivant.

  • Rolling based on Time(Propagation en fonction de la durée) – Spécifiez un laps de temps d'attente entre le lancement de nouvelles instances et leur mise en service avant de démarrer le lot suivant.

  • Immutable (Immuable) – Appliquez la modification de la configuration à un nouveau groupe d'instances en effectuant une mise à jour immuable.

• Batch size (Taille de lot) – Le nombre d'instances à remplacer dans chaque lot, entre 1 et 10000. Par défaut, cette valeur représente un tiers de la taille minimale du groupe Auto Scaling, arrondi au nombre entier.

• Minimum capacity (Capacité minimum) – Le nombre minimum d'instances à maintenir en cours d'exécution pendant que d'autres instances sont mises à jour, entre 0 et 9999. La valeur par défaut est soit la taille minimale du groupe Auto Scaling ou un niveau en dessous de la taille maximale du groupe Auto Scaling, le chiffre le plus bas prévalant.

• Pause time (Temps d'interruption) (basé sur le temps uniquement) – La durée d'attente après qu'un lot est mis à jour avant de passer au lot suivant, pour permettre à votre application de commencer à recevoir du trafic. Entre 0 seconde et 1 heure.

L'espace de noms aws:autoscaling:updatepolicy:rollingupdate

Vous pouvez également utiliser les options de configuration dans l'espace de noms aws:autoscaling:updatepolicy:rollingupdate pour configurer des mises à jour propagées.

Utilisez l'option RollingUpdateEnabled pour activer les mises à jour propagées, et RollingUpdateType pour choisir le type de mise à jour. Les valeurs suivantes sont prises en charge pour RollingUpdateType :

• Health – Patientez jusqu'à ce que les instances dans le lot actuel soient saines avant de mettre des instances en service et de démarrer le lot suivant.

• Time – Spécifie un laps de temps d'attente entre le lancement de nouvelles instances et leur mise en service avant de démarrer le lot suivant.

• Immutable – Appliquez la modification de la configuration à un nouveau groupe d'instances en effectuant une mise à jour immuable.

Lorsque vous activez les mises à jours propagées, définissez les options MaxBatchSize et MinInstancesInService afin de configurer la taille de chaque lot. Pour les mises à jour propagées basées sur l'intégrité et basées sur le temps, vous pouvez également configurer un PauseTime et Timeout, respectivement.

Par exemple, afin de lancer jusqu'à cinq instances à la fois, tout en conservant au moins deux instances en service, puis attendre cinq minutes et 30 secondes entre les lots, spécifiez les options et les valeurs suivantes.

Exemple .ebextensions/timebased.config

option_settings:
  aws:autoscaling:updatepolicy:rollingupdate:
    RollingUpdateEnabled: true
    MaxBatchSize: 5
    MinInstancesInService: 2
    RollingUpdateType: Time
    PauseTime: PT5M30S

Pour activer les mises à jour propagées basées sur l'intégrité, avec une expiration à 45 minutes pour chaque lot, spécifiez les valeurs et les options suivantes.

Exemple .ebextensions/healthbased.config

option_settings:
  aws:autoscaling:updatepolicy:rollingupdate:
    RollingUpdateEnabled: true
    MaxBatchSize: 5
    MinInstancesInService: 2
    RollingUpdateType: Health
    Timeout: PT45M

Les valeurs Timeout et PauseTime doivent être spécifiées au format de durée ISO8601 : PT#H#M#S, où chaque # correspond au nombre d'heures, de minutes ou de secondes, respectivement.

L'interface de ligne de commande (CLI) EB et la console Elastic Beanstalk appliquent les valeurs recommandées pour les options précédentes. Vous devez supprimer ces paramètres si vous voulez utiliser des fichiers de configuration pour configurer la même chose. Consultez Valeurs recommandées pour plus de détails.