Mise à jour de la version de la plateforme de votre environnement Elastic Beanstalk - AWS Elastic Beanstalk

Mise à jour de la version de la plateforme de votre environnement Elastic Beanstalk

Elastic Beanstalk publie régulièrement de nouvelles versions de plateforme pour mettre à jour toutes les plateformes basées sur Linux et sur Windows Server. Les nouvelles versions de plateforme fournissent des mises à jour des composants logiciels existants et prennent en charge de nouvelles fonctionnalités ainsi que des options de configuration. Pour en savoir plus sur les plateformes et les versions de plateforme, veuillez consulter Glossaire des plateformes Elastic Beanstalk.

Vous pouvez utiliser la console Elastic Beanstalk ou l'interface de ligne de commande EB pour mettre à jour la version de la plateforme de votre environnement. En fonction de la version de plateforme que vous souhaitez mettre à jour, Elastic Beanstalk recommande l'une des deux méthodes pour effectuer des mises à jour de la plateforme.

  • Méthode 1 – Mettre à jour la version de la plateforme de votre environnement. Nous vous recommandons d'utiliser cette méthode lorsque vous mettez à jour vers la dernière version de la plateforme dans une branche de plateforme : avec le même environnement d'exécution, le même serveur web, le même serveur d'application et le même système d'exploitation, et sans modifier la version de la plateforme principale. Il s'agit de la mise à jour de plateforme la plus courante et la plus régulière.

  • Méthode 2 – Effectuer un déploiement bleu/vert. Nous vous recommandons d'utiliser cette méthode lorsque vous effectuez une mise à jour vers une version de plateforme dans une autre branche de plateforme : avec un environnement d'exécution, un serveur web, un serveur d'applications ou un système d'exploitation différents, ou vers une autre version majeure de plateforme. Il s'agit d'une bonne approche lorsque vous voulez tirer parti des nouvelles fonctionnalités d'exécution ou des dernières fonctionnalités Elastic Beanstalk, ou encore lorsque vous voulez quitter une branche de plateforme obsolète ou hors service.

    La migration à partir d'une version de plateforme héritée nécessite un déploiement bleu/vert, car ces versions de plateforme sont incompatibles avec les versions actuellement prises en charge.

    La migration d'une application Linux vers Amazon Linux 2 nécessite un déploiement bleu/vert, car les versions de la plateforme Amazon Linux 2 sont incompatibles avec les versions précédentes de la plateforme AMI Amazon Linux.

Pour plus d'informations sur le choix de la meilleure méthode de mise à jour de la plateforme, développez la section pour la plateforme de votre environnement.

Utilisez la méthode 1 pour effectuer des mises à jour de la plateforme.

Utilisez la méthode 1 pour effectuer des mises à jour de la plateforme.

Considérons les cas suivants :

  • Si vous migrez votre application vers une autre plateforme, par exemple de Go 1.4 (Docker) vers Go 1.11 ou de Python 3.4 (Docker) vers Python 3.6, utilisez la méthode 2.

  • Si vous migrez votre application vers une autre version de conteneur Docker, par exemple de Glassfish 4.1 (Docker) vers Glassfish 5.0 (Docker), utilisez la méthode 2.

  • Si vous mettez à jour vers une version plus récente de la plateforme sans aucune modification de version majeure ou de conteneur, utilisez la méthode 1.

Utilisez la méthode 1 pour effectuer des mises à jour de la plateforme.

Considérons les cas suivants :

  • Si vous migrez votre application vers une autre version d'exécution Java, par exemple de Java 7 vers Java 8, utilisez la méthode 2.

  • Si vous mettez à jour vers une version plus récente de la plateforme, sans modification de la version d'exécution, utilisez la méthode 1.

Considérons les cas suivants :

  • Si vous migrez votre application vers une autre version d'environnement d'exécution Java ou version de serveur d'application Tomcat, par exemple de Java 7 avec Tomcat 7 vers Java 8 avec Tomcat 8.5, utilisez la méthode 2.

  • Si vous migrez votre application sur les versions majeures de Java avec la plateforme Tomcat (v1.x.x, v2.x.x et v3.x.x), utilisez la méthode 2.

  • Si vous mettez à jour vers une version plus récente de la plateforme, sans modifier la version d'exécution, la version du serveur d'application ou la version majeure, utilisez la méthode 1.

Considérons les cas suivants :

  • Si vous migrez votre application vers une autre version du système d'exploitation Windows, par exemple de Windows Server 2008 R2 vers Windows Server 2016, utilisez la méthode 2.

  • Si vous migrez votre application à travers les principales versions de plateforme Windows Server, veuillez consulter Migration à partir de versions majeures antérieures de la plateforme Windows Server, et utilisez la méthode 2.

  • Si votre application est en cours d'exécution sur une plateforme Windows Server V2.x.x et que vous mettez à jour vers une version plus récente de la plateforme, utilisez la méthode 1.

Note

Les versions de plateforme Windows Server antérieures à la version v2 ne sont pas sémantiquement versionnées. Vous ne pouvez lancer que la dernière version de ces versions de plateforme majeures Windows Server et vous ne pouvez pas restaurer après une mise à niveau.

Utilisez la méthode 2 pour effectuer des mises à jour de la plateforme.

Considérons les cas suivants :

  • Si vous migrez votre application vers une autre version d'exécution PHP, par exemple de PHP 5.6 vers PHP 7.2, utilisez la méthode 2.

  • Si vous migrez votre application sur les versions majeures de la plateforme PHP (v1.x.x et v2.x.x), utilisez la méthode 2.

  • Si vous mettez à jour vers une version plus récente de la plateforme, sans modifier la version d'exécution ou la version majeure, utilisez la méthode 1.

Considérons les cas suivants :

  • Si vous migrez votre application vers un autre environnement d'exécution Python, par exemple de Python 2.7 vers Python 3.6, utilisez la méthode 2.

  • Si vous migrez votre application sur les versions majeures de la plateforme Python (v1.x.x et v2.x.x), utilisez la méthode 2.

  • Si vous mettez à jour vers une version plus récente de la plateforme, sans modifier la version d'exécution ou la version majeure, utilisez la méthode 1.

Considérons les cas suivants :

  • Si vous migrez votre application vers une autre version d'exécution de Ruby ou une version de serveur d'application, par exemple de Ruby 2.3 avec Puma vers Ruby 2.6 avec Puma, utilisez la méthode 2.

  • Si vous migrez votre application sur les versions majeures de la plateforme Ruby (v1.x.x et v2.x.x), utilisez la méthode 2.

  • Si vous mettez à jour vers une version plus récente de la plateforme, sans modifier la version d'exécution, la version du serveur d'application ou la version majeure, utilisez la méthode 1.

Méthode 1 – Mettre à jour la version de la plateforme de votre environnement

Utilisez cette méthode pour mettre à jour vers la dernière branche de plateforme de votre environnement. Si vous avez préalablement créé un environnement à l'aide d'une version de plateforme antérieure ou mis à niveau votre environnement à partir d'une version plus ancienne, vous pouvez également utiliser cette méthode pour revenir à une version de plateforme précédente, à condition qu’elle se trouve dans la même branche de plateforme.

Pour mettre à jour la version de la plateforme de votre environnement

  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 la page de présentation de l'environnement, sous Platform (Plateforme), choisissez Change (Changer).

    
            Plateforme Elastic Beanstalk plus récente disponible
  4. Dans la boîte de dialogue Update platform version (Mettre à jour la version de la plateforme) sélectionnez une version de la plate-forme. La version de la plateforme la plus récente (recommandée) de la branche est sélectionnée automatiquement. Vous pouvez mettre à jour vers n'importe quelle version que vous avez utilisée dans le passé.

    
            Confirmation de la mise à jour de la version de la plateforme Elastic Beanstalk
  5. Choisissez Enregistrer.

Pour davantage simplifier les mises à jour des plateformes, Elastic Beanstalk peut les gérer pour vous. Vous pouvez configurer votre environnement pour appliquer automatiquement des mises à jour de versions mineures et de correctifs pendant un créneau de maintenance hebdomadaire configurable. Elastic Beanstalk applique des mises à jour gérées sans interruption ni réduction de capacité et annule la mise à jour immédiatement si les instances exécutant votre application sur la nouvelle version échouent aux vérifications de l'état. Pour plus d'informations, consultez Mises à jour gérées de la plateforme.

Méthode 2 – Effectuer un déploiement bleu/vert

Utilisez cette méthode pour effectuer une mise à jour vers une autre branche de plateforme : avec un environnement d'exécution, un serveur web, un serveur d'applications ou un système d'exploitation différents, ou vers une autre version principale de plateforme. Cela est généralement nécessaire lorsque vous souhaitez tirer parti des nouvelles fonctionnalités d'exécution ou des dernières fonctionnalités Elastic Beanstalk. Cela est également requis lorsque vous migrez hors d'une branche de plateforme obsolète ou hors service.

Lorsque vous migrez sur plusieurs versions de plate-forme majeures ou vers des versions de plate-forme avec des mises à jour de composants principaux composant, il y a plus de chances que votre application ou certains aspects de celle-ci peuvent ne pas fonctionner comme prévu sur la nouvelle version de la plateforme, et peuvent nécessiter des changements.

Avant de réaliser la migration, mettez à jour votre machine de développement local vers les dernières versions d'exécution et d'autres composants de la plateforme que vous prévoyez de migrer. Vérifiez que votre application fonctionne comme prévu et apportez toutes les modifications et les correctifs de code nécessaire. Ensuite, utilisez la procédure de bonnes pratiques suivantes pour migrer votre environnement en toute sécurité vers la nouvelle version de la plateforme.

Pour migrer votre environnement vers une version de plateforme avec des mises à jour majeures

  1. Créez un environnement en utilisant la nouvelle version de plateforme, puis déployez-y votre code d'application. Le nouvel environnement doit être dans l'application Elastic Beanstalk qui contient l'environnement que vous migrez. N'arrêtez pas encore l'environnement existant.

  2. Utilisez le nouvel environnement pour migrer votre code d'application. En particulier :

    • Trouvez et corrigez les problèmes de compatibilité de l'application que vous n’avez pas pu détecter au cours de la phase de développement.

    • Assurez-vous que toutes les personnalisations que votre application effectue en utilisant les fichiers de configuration fonctionnent correctement dans le nouvel environnement. Celles-ci peuvent inclure les paramètres d'options, les packages installés supplémentaires, les stratégies de sécurité personnalisées, et les fichiers de configuration ou de script installés sur les instances de l'environnement.

    • Si votre application utilise une Amazon Machine Image (AMI) personnalisée, créez une AMI personnalisée basée sur l'AMI de la nouvelle version de la plateforme. Pour en savoir plus, consultez la section Utilisation d'une Amazon Machine Image (AMI) personnalisée. Plus précisément, cette action est obligatoire si votre application utilise la plateforme Windows Server avec une AMI personnalisée, et que vous migrez vers une version de la plateforme Windows Server V2. Dans ce cas, veuillez consulter également Migration à partir de versions majeures antérieures de la plateforme Windows Server.

    Itérez les tests et déployer vos correctifs jusqu'à ce que vous soyez satisfait de l'application sur le nouvel environnement.

  3. Activez le nouvel environnement en tant qu'environnement de production en échangeant son CNAME avec le CNAME de l'environnement de production existant. Pour plus d'informations, consultez Déploiements bleu/vert avec Elastic Beanstalk.

  4. Lorsque vous êtes satisfait de l'état de votre nouvel environnement de production, arrêtez l'ancien environnement. Pour plus d'informations, consultez Arrêt d'un environnement Elastic Beanstalk.