Migration depuis AMI Amazon Linux (AL1) vers AL2 ou AL2023 - AWS Elastic Beanstalk
Différences et compatibilitéProcessus de migrationRéférences utilesConsidérations pour toutes les plateformes LinuxConsidérations spécifiques à la plateforme

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.

Migration depuis AMI Amazon Linux (AL1) vers AL2 ou AL2023

Si votre application Elastic Beanstalk est basée sur une branche de plateforme AMI Amazon Linux, utilisez cette section pour savoir comment migrer les environnements de votre application vers Amazon Linux 2 ou Amazon Linux 2023. Les branches de plateforme de génération précédente basées sur l'AMI Amazon Linux sont désormais retirées.

Nous vous recommandons vivement de migrer vers Amazon Linux 2023, car ce système d'exploitation est plus récent qu'Amazon Linux 2. Le système d'exploitation Amazon Linux 2 atteindra la fin de sa prise en charge avant Amazon Linux 2023. Vous bénéficierez donc d'une période de prise en charge plus longue si vous migrez vers Amazon Linux 2023.

Il est intéressant de noter qu'il existe un degré élevé de compatibilité entre les plateformes Elastic Beanstalk Amazon Linux 2 et Amazon Linux 2023. Il existe cependant des différences dans certains domaines : l'option par défaut du service des métadonnées d'instance Version 1 (IMDSv1), la prise en charge de l'outil d'instance pkg-repo et certaines configurations d'Apache HTTPD. Pour plus d'informations, consultez Amazon Linux 2023.

Différences et compatibilité

Les branches de plateforme basées sur AL2023/AL2 ne sont pas garanties comme étant rétrocompatibles avec votre application existante. Il est également important de savoir que même si votre code d'application se déploie avec succès sur la nouvelle version de plateforme, il peut se comporter ou fonctionner différemment en raison des différences de système d'exploitation et d'exécution.

Bien que l'AMI Amazon Linux et AL2023/AL2 partagent le même noyau Linux, ils diffèrent sur les aspects suivants : leur système d'initialisation, les versions libc, la chaîne d'outils du compilateur, et divers packages. Pour plus d'informations, consultez FAQ sur Amazon Linux 2.

Le service Elastic Beanstalk a également mis à jour des versions de l'environnement d'exécution, d'outils de génération et d'autres dépendances spécifiques à la plateforme.

Par conséquent, nous vous recommandons de prendre votre temps, de tester soigneusement votre application dans un environnement de développement et d'effectuer les ajustements nécessaires.

Processus général de migration

Lorsque vous êtes prêt à passer en production, Elastic Beanstalk nécessite un déploiement bleu/vert pour effectuer la mise à niveau. Vous trouverez ci-dessous les étapes générales des meilleures pratiques que nous recommandons pour la migration avec une procédure de déploiement bleu/vert.

Préparer le test de votre migration

Avant de déployer votre application et de commencer les tests, consultez les informations contenues dans Considérations pour toutes les plateformes Linux, qui figure plus loin dans cette rubrique. Consultez également les informations qui s'appliquent à votre plateforme dans la section Considérations spécifiques à la plateforme qui suit. Prenez note des informations spécifiques de ce contenu qui s'appliquent ou peuvent s'appliquer à votre application et à votre configuration.

Étapes de migration de haut niveau

  1. Créez un nouvel environnement basé sur une branche de plateforme AL2 ou AL2023. Nous vous recommandons de migrer vers une branche de plateforme AL2023.

  2. Déployez votre application dans l'environnement AL2023/AL2 cible.

    Votre environnement de production existant restera actif et non affecté, pendant que vous procédez à des tests et des ajustements du nouvel environnement.

  3. Testez votre application de manière approfondie dans le nouvel environnement.

  4. Lorsque votre environnement AL2023/AL2 de destination sera prêt à passer en production, échangez les CNAME des deux environnements afin de rediriger le trafic vers le nouvel environnement.

Étapes de migration plus détaillées et meilleures pratiques

Pour une procédure de déploiement bleu/vert plus détaillée, consultez Déploiements bleu/vert avec Elastic Beanstalk.

Pour des conseils plus spécifiques et des étapes détaillées des meilleures pratiques, consultez Blue/Green method.

Plus de références pour vous aider à planifier votre migration

Les références suivantes peuvent fournir des informations supplémentaires pour planifier votre migration.

Considérations pour toutes les plateformes Linux

Le tableau suivant présente les considérations que vous devez prendre en compte lors de la planification d'une migration d'application vers AL2023/AL2. Ces considérations s'appliquent à toutes les plateformes Linux Elastic Beanstalk, quels que soient les langages de programmation ou les serveurs d'applications spécifiques.

Area Modifications et informations

Fichiers de configuration

Sur les plateformes AL2023/AL2, vous pouvez utiliser les fichiers de configuration comme précédemment, et toutes les sections fonctionnent de la même manière. Cependant, des paramètres spécifiques peuvent ne pas fonctionner de la même manière que sur les plateformes AMI Amazon Linux précédentes. Par exemple :

  • Certains packages logiciels que vous installez à l'aide d'un fichier de configuration peuvent ne pas être disponibles sur AL2023/AL2, ou leur nom peut avoir changé.

  • Certaines options de configuration spécifiques à la plateforme ont vu leur espace de noms spécifique à la plate-forme être changé en un espace de noms différent et indépendant de la plateforme.

  • Les fichiers de configuration de proxy fournis dans le répertoire .ebextensions/nginx doivent être déplacés vers le répertoire des hooks de plateforme .platform/nginx. Pour plus d'informations, développez la section Reverse Proxy Configuration dans Extension des plateformes Linux Elastic Beanstalk.

Nous vous recommandons d'utiliser des hooks de plateforme pour exécuter du code personnalisé sur vos instances d'environnement. Vous pouvez toujours utiliser des commandes et des commandes de conteneur dans les fichiers de configuration .ebextensions, mais elles ne sont pas aussi simples à utiliser. Par exemple, écrire des scripts de commande dans un fichier YAML peut être lourd et difficile à tester.

Vous devez toujours utiliser des fichiers de configuration .ebextensions pour tout script nécessitant une référence à une ressource AWS CloudFormation.

Hooks de plateforme

Les plateformes AL2 ont introduit une nouvelle façon d'étendre la plateforme de votre environnement en ajoutant des fichiers exécutables aux répertoires de hooks sur les instances de l'environnement. Avec les versions précédentes de la plateforme Linux, vous avez peut-être utilisé des hooks de plateforme personnalisée. Ces hooks n'étaient pas conçus pour les plateformes gérées et n'étaient pas pris en charge, mais pouvaient fonctionner de manière utile dans certains cas. Avec les versions de plateforme AL2023/AL2, les hooks de plateforme personnalisée ne fonctionnent pas. Vous devez migrer tous les hooks vers les nouveaux hooks de plateforme. Pour plus de détails, développez la section Platform Hooks dans Extension des plateformes Linux Elastic Beanstalk.

Serveurs proxy pris en charge

Les versions de plateforme AL2023/AL2 prennent en charge les mêmes serveurs proxys inverses que chaque plateforme prise en charge dans ses versions de plateforme d'AMI Amazon Linux. Toutes les versions de plateforme AL2023/AL2 utilisent nginx comme serveur proxy inverse par défaut, à l'exception des plateformes ECS et Docker. Les plateformes Tomcat, Node.js, PHP et Python prennent également en charge Apache HTTPD comme alternative. Toutes les plateformes permettent la configuration du serveur proxy de manière uniforme, comme décrit dans cette section. Toutefois, la configuration du serveur proxy est légèrement différente de celle de l'AMI Amazon Linux. Voici les différences pour toutes les plateformes :

  • La valeur par défaut est nginx : le serveur proxy par défaut sur toutes les versions de plateforme AL2023/AL2 est nginx. Sur les versions de plateforme AMI Amazon Linux de Tomcat, PHP et Python, le serveur proxy par défaut était Apache HTTPD.

  • Espace de noms cohérent : toutes les versions de la plateforme AL2023/AL2 utilisent l'espace de noms aws:elasticbeanstalk:environment:proxy pour configurer le serveur proxy. Sur les versions de plateforme AMI Amazon Linux, il s'agissait d'une décision par plateforme, et Node.js utilisait un espace de noms différent.

  • Emplacement du fichier de configuration : vous devez placer les fichiers de configuration proxy dans les répertoires .platform/nginx et .platform/httpd sur toutes les versions de plateforme AL2023/AL2. Sur les versions de la plateforme AMI Amazon Linux, ces emplacements étaient .ebextensions/nginx et .ebextensions/httpd, respectivement.

Pour les modifications de configuration de proxy spécifiques à la plateforme, veuillez consulter Considérations spécifiques à la plateforme. Pour de plus amples informations sur la configuration de proxy sur AL2023/AL2, développez la section Configuration de proxy inverse dans Extension des plateformes Linux Elastic Beanstalk.

Modifications de la configuration du proxy

Il y a des modifications de configuration de proxy qui s'appliquent uniformément à toutes les plateformes, en plus des modifications de configuration de proxy spécifiques à chaque plateforme. Il est important de se référer aux deux pour configurer avec précision vos environnements.

Profil d'instance

Les plateformes AL2023/AL2 nécessitent la configuration d'un profil d'instance. La création de l'environnement peut aboutir temporairement sans profil d'instance, mais l'environnement peut afficher des erreurs rapidement après sa création lorsque des actions nécessitant un profil d'instance commencent à échouer. Pour plus de détails, veuillez consulter Gestion des profils d'instance Elastic Beanstalk.

Intégrité améliorée

Les versions de plateforme AL2023/AL2 permettent d'améliorer l'intégrité par défaut. Il s'agit d'un changement si vous n'utilisez pas la console Elastic Beanstalk pour créer vos environnements. La console active l'intégrité améliorée par défaut chaque fois que cela est possible, quelle que soit la version de la plateforme. Pour plus de détails, veuillez consulter Surveillance et création de rapports d'intégrité améliorée.

AMI personnalisée

Si votre environnement utilise une AMI personnalisée, créez une nouvelle AMI basée sur AL2023/AL2 pour votre nouvel environnement à l'aide d'une plateforme Elastic Beanstalk AL2023/AL2.

Plateformes personnalisées

Les AMI gérées des versions de plateforme AL2023/AL2 ne prennent pas en charge les plateformes personnalisées.

Considérations spécifiques à la plateforme

Cette section traite des considérations de migration spécifiques à certaines plateformes Linux Elastic Beanstalk.

La famille de branches de la plateforme Docker basée sur l'AMI Amazon Linux (AL1) comprend trois branches de plateforme. Nous recommandons un chemin de migration différent pour chacun d'entre eux.

Branche de la plateforme AL1 Chemin de migration vers AL2023/AL2

Docker multiconteneurs géré par Amazon ECS s'exécutant sur AMI Amazon Linux (AL1)
Branche de plateforme Docker AL2023/AL2 basée sur ECS

La branche de la plateforme Docker AL2023/AL2 basée sur ECS offre un chemin de migration simple pour les environnements exécutés sur la branche de plateforme Docker AL1 multiconteneurs.

  • De la même manière que la précédente branche Docker AL1 multiconteneurs, les branches de plateforme AL2023/AL2 utilisent Amazon ECS pour coordonner le déploiement de plusieurs conteneurs Docker dans un cluster Amazon ECS dans un environnement Elastic Beanstalk.

  • La branche de plateforme AL2023/AL2 prend en charge toutes les fonctionnalités de la branche Docker AL1 multiconteneurs précédente.

  • Les branches de plateforme AL2023/AL2 prennent également en charge le même fichier v2 Dockerrun.aws.json.

Pour plus d'informations sur la migration de vos applications exécutées sur la branche de plateforme Docker multiconteneur Amazon Linux vers une branche de plateforme Amazon ECS s'exécutant sur AL2023/AL2, consultez Migration de Docker multiconteneurs s'exécutant sur Amazon Linux vers ECS sur Amazon Linux 2023.

Docker s'exécutant sur AMI Amazon Linux (AL1)

Docker préconfiguré (Glassfish 5.0) s'exécutant sur AMI Amazon Linux (AL1)
Docker exécuté sur la branche de plateforme AL2023/AL2

Nous vous recommandons de migrer vos applications s'exécutant sur des environnements basés sur Docker préconfiguré (Glassfish 5.0) ou Docker s'exécutant sur AMI Amazon Linux (AL1) vers des environnements basés sur les branches de plateforme Docker s'exécutant sur Amazon Linux 2 ou Docker s'exécutant sur AL2023.

Si votre environnement repose sur la branche de plateforme Preconfigured Docker (Glassfish 5.0) (Docker préconfiguré [Glassfish 5.0]), consultez Déploiement d'une GlassFish application sur la plateforme Docker : une voie de migration vers Amazon Linux 2023.

Le tableau ci-dessous répertorie les informations de migration spécifique à la branche de plateforme Docker s'exécutant sur AL2023/AL2.

Area Modifications et informations

Stockage

Elastic Beanstalk configure Docker pour qu'il utilise des pilotes de stockage afin de stocker des images Docker et des données de conteneur. Sur l'AMI Amazon Linux, Elastic Beanstalk a utilisé le pilote de stockage Device Mapper. Pour améliorer les performances, Elastic Beanstalk a provisionné un volume Amazon EBS supplémentaire. Sur les versions de plateforme Docker AL2023/AL2, Elastic Beanstalk utilise le pilote de stockage OverlayFS, et améliore encore les performances tout en ne nécessitant plus de volume distinct.

Avec l'AMI Amazon Linux, si vous avez utilisé l'option BlockDeviceMappings de l'espace de noms aws:autoscaling:launchconfiguration pour ajouter des volumes de stockage personnalisés à un environnement Docker, nous vous conseillons d'ajouter également le volume /dev/xvdcz Amazon EBS prévu par Elastic Beanstalk. Elastic Beanstalk ne provisionne plus ce volume, vous devriez donc le supprimer de vos fichiers de configuration. Pour plus de détails, veuillez consulter Configuration Docker sur l'AMI Amazon Linux (antérieure à Amazon Linux 2).

Authentification du référentiel privé

Lorsque vous fournissez un fichier d'authentification généré par Docker pour vous connecter à un référentiel privé, vous n'avez plus besoin de le convertir dans l'ancien format requis par les versions de la plateforme AMI Docker Amazon Linux. Les versions de plateforme Docker AL2023/AL2 prennent en charge le nouveau format. Pour plus de détails, veuillez consulter Utilisation d'images à partir d'un référentiel privé.

Serveur proxy

Les versions de plateforme Docker AL2023/AL2 ne prennent pas en charge les conteneurs autonomes qui ne s'exécutent pas derrière un serveur proxy. Sur les versions de la plateforme AMI Docker Amazon Linux, cela était possible grâce à la valeur none de l'option ProxyServer dans l'espace de noms aws:elasticbeanstalk:environment:proxy.

Le tableau ci-dessous répertorie les informations de migration pour les versions de plateforme AL2023/AL2 dans la plateforme Go.

Area Modifications et informations

Transmission de port

Sur les plateformes AL2023/AL2, Elastic Beanstalk ne transmet pas une valeur de port à votre processus d'application via la variable d'environnement PORT. Vous pouvez simuler ce comportement pour votre processus en configurant vous-même une propriété d'environnement PORT. Cependant, si vous avez plusieurs processus et que vous comptez sur Elastic Beanstalk pour transmettre des valeurs de port incrémentielles à vos processus (5000, 5100, 5200, etc.), vous devez modifier votre implémentation. Pour plus d'informations, développez la section Configuration du proxy inverse dans Extension des plateformes Linux Elastic Beanstalk.

Le tableau ci-dessous répertorie les informations de migration pour les branches de plateforme Corretto dans la plateforme Java SE.

Area Modifications et informations

Corretto et OpenJDK

Pour implémenter la plateforme Java édition standard (Java SE), les branches de plateforme AL2023/AL2 utilisent Amazon Corretto, une distribution AWS de l'Open Java Development Kit (OpenJDK). Les branches précédentes de la plateforme Elastic Beanstalk Java SE utilisent les packages OpenJDK inclus avec l'AMI Amazon Linux.

Outils de génération

Les plateformes AL2023/AL2 disposent de versions d'outils de génération plus récentes : gradle, maven et ant.

Gestion des fichiers JAR

Sur les plateformes AL2023/AL2, si votre bundle de fichiers source (fichier ZIP) contient un seul fichier JAR et aucun autre fichier, Elastic Beanstalk ne renomme plus le fichier JAR application.jar. Le changement de nom se produit uniquement si vous soumettez un fichier JAR seul et non inclus dans un fichier ZIP.

Transmission de port

Sur les plateformes AL2023/AL2, Elastic Beanstalk ne transmet pas une valeur de port à votre processus d'application via la variable d'environnement PORT. Vous pouvez simuler ce comportement pour votre processus en configurant vous-même une propriété d'environnement PORT. Cependant, si vous avez plusieurs processus et que vous comptez sur Elastic Beanstalk pour transmettre des valeurs de port incrémentielles à vos processus (5000, 5100, 5200, etc.), vous devez modifier votre implémentation. Pour plus d'informations, développez la section Configuration du proxy inverse dans Extension des plateformes Linux Elastic Beanstalk.

Java 7

Elastic Beanstalk ne prend pas en charge une branche de plateforme AL2023/AL2 Java 7. Si vous avez une application Java 7, migrez vers Corretto 8 ou Corretto 11.

Le tableau ci-dessous répertorie les informations de migration pour les versions de plateforme AL2023/AL2 dans la plateforme Tomcat.

Area Modifications et informations

Options de configuration

Sur les versions de plateforme AL2023/AL2, Elastic Beanstalk ne prend en charge qu'un sous-ensemble des options de configuration et des valeurs d'option dans l'espace de noms aws:elasticbeanstalk:environment:proxy. Voici les informations de migration pour chaque option.

Option Informations sur la migration

GzipCompression

Non pris en charge sur les versions de plateformes AL2023/AL2.

ProxyServer

Les versions de plateforme AL2023/AL2 Tomcat prennent en charge à la fois les serveurs proxys nginx et Apache HTTPD version 2.4. Cependant, Apache version 2.2 n'est pas prise en charge.

Sur les versions de la plateforme AMI Amazon Linux, le proxy par défaut était Apache 2.4. Si vous avez utilisé le paramètre de proxy par défaut et ajouté des fichiers de configuration de proxy personnalisés, votre configuration de proxy doit toujours fonctionner sur AL2023/AL2. Cependant, si vous avez utilisé la valeur de l'option apache/2.2, vous devez maintenant migrer votre configuration proxy vers Apache version 2.4.

L'option XX:MaxPermSize de l'espace de noms aws:elasticbeanstalk:container:tomcat:jvmoptions n'est pas prise en charge sur les versions de plateforme AL2023/AL2. Le paramètre JVM permettant de modifier la taille de la génération permanente s'applique uniquement à Java 7 et versions antérieures et n'est donc pas applicable aux versions de plateforme AL2023/AL2.

Chemin d'accès de l'application

Sur les plateformes AL2023/AL2, le chemin d'accès au répertoire de l'application sur les instances Amazon EC2 de votre environnement est /var/app/current. C'était /var/lib/tomcat8/webapps sur les plateformes AMI Amazon Linux.

Le tableau ci-dessous répertorie les informations de migration pour les versions de plateforme AL2023/AL2 dans la plateforme Node.js.

Area Modifications et informations

Versions de Node.js installées

Sur les plateformes AL2023/AL2, Elastic Beanstalk conserve plusieurs branches de plateforme Node.js et installe uniquement la dernière version majeure de Node.js correspondant à la branche de plateforme sur chaque version de plateforme. Par exemple, chaque version de plateforme dans la branche de plateforme Node.js 12 n'a que Node.js 12.x.y installé par défaut. Sur les versions de plateforme AMI Amazon Linux, nous avons installé les versions multiples de plusieurs versions de Node.js sur chaque version de plateforme, et nous n'avons maintenu qu'une seule branche de plateforme.

Choisissez la branche de plateforme Node.js qui correspond à la version majeure de Node.js dont votre application a besoin.

Noms des fichiers journaux HTTPD Apache

Sur les plateformes AL2023/AL2, si vous utilisez le serveur proxy HTTPD Apache, les noms des fichiers journaux HTTPD sont access_log et error_log, ce qui est cohérent avec toutes les autres plateformes prenant en charge Apache HTTPD. Sur les versions de la plateforme d'AMI Amazon Linux, ces fichiers journaux étaient nommés access.log et error.log, respectivement.

Pour de plus amples informations sur les noms et les emplacements des fichiers journaux de toutes les plateformes, veuillez consulter Méthode de configuration de CloudWatch Logs par Elastic Beanstalk.

Options de configuration

Sur les plateformes AL2023/AL2, Elastic Beanstalk ne prend pas en charge les options de configuration de l'espace de noms aws:elasticbeanstalk:container:nodejs. Certaines options ont des solutions de rechange. Voici les informations de migration pour chaque option.

Option Informations sur la migration

NodeCommand

Utilisez un Procfile ou le mot-clé scripts dans un fichier package.json pour spécifier le script de démarrage.

NodeVersion

Utilisez le mot-clé engines dans un fichier package.json pour spécifier la version de Node.js. Sachez que vous ne pouvez spécifier qu'une version de Node.js qui correspond à votre branche de plateforme. Par exemple, si vous utilisez la branche de plateforme Node.js 12, vous ne pouvez spécifier qu'une version 12.x.y de Node.js. Pour plus de détails, veuillez consulter Spécification des dépendances Node.js avec un fichier package.json.

GzipCompression

Non pris en charge sur les versions de plateformes AL2023/AL2.

ProxyServer

Sur les versions de plateforme AL2023/AL2 Node.js, cette option a été déplacée vers l'espace de noms aws:elasticbeanstalk:environment:proxy. Vous pouvez choisir entre nginx (par défaut) et apache.

Les versions de plateforme AL2023/AL2 Node.js ne prennent pas en charge les applications autonomes qui ne s'exécutent pas derrière un serveur proxy. Sur les versions de la plateforme Node.js d'AMI Amazon Linux, cela était possible via la valeur none de l'option ProxyServer dans l'espace de noms aws:elasticbeanstalk:container:nodejs. Si votre environnement exécute une application autonome, mettez à jour votre code pour écouter le port vers lequel le serveur proxy (nginx ou Apache) transfère le trafic.

var port = process.env.PORT || 5000;

app.listen(port, function() {
  console.log('Server running at http://127.0.0.1:%s', port);
});

Le tableau ci-dessous répertorie les informations de migration pour les versions de plateforme AL2023/AL2 dans la plateforme PHP.

Area Modifications et informations

Traitement des fichiers PHP

Sur les plateformes AL2023/AL2, les fichiers PHP sont traités à l'aide de PHP-FPM (gestionnaire de processus CGI). Sur les plateformes AMI Amazon Linux, nous avons utilisé mod_php (un module Apache).

Serveur proxy

Les versions de plateforme AL2023/AL2 PHP prennent en charge à la fois les serveurs proxys nginx et Apache HTTPD. La valeur par défaut est nginx.

Les versions de la plateforme PHP AMI Amazon Linux prenaient uniquement en charge Apache HTTPD. Si vous avez ajouté des fichiers de configuration Apache personnalisés, vous pouvez définir l'option ProxyServer dans l'espace de noms aws:elasticbeanstalk:environment:proxy sur apache.

Le tableau ci-dessous répertorie les informations de migration pour les versions de plateforme AL2023/AL2 dans la plateforme Python.

Area Modifications et informations

Serveur WSGI

Sur les plateformes AL2023/AL2, Gunicorn est le serveur WSGI par défaut. Par défaut, Gunicorn écoute sur le port 8000. Le port peut être différent de celui utilisé par votre application sur la plateforme d'AMI Amazon Linux. Si vous définissez l'option WSGIPath de l'espace de noms aws:elasticbeanstalk:container:python, remplacez la valeur par la syntaxe de Gunicorn. Pour plus de détails, veuillez consulter Espaces de noms de la configuration Python.

Vous pouvez également utiliser un Procfile pour spécifier et configurer le serveur WSGI. Pour plus de détails, veuillez consulter Configuration du serveur WSGI avec un Procfile.

Chemin d'accès de l'application

Sur les plateformes AL2023/AL2, le chemin d'accès au répertoire de l'application sur les instances Amazon EC2 de votre environnement est /var/app/current. C'était /opt/python/current/app sur les plateformes AMI Amazon Linux.

Serveur proxy

Les versions de plateforme AL2023/AL2 Python prennent en charge à la fois les serveurs proxys nginx et Apache HTTPD. La valeur par défaut est nginx.

Les versions de plateforme AMI Python Amazon Linux prennent uniquement en charge Apache HTTPD. Si vous avez ajouté des fichiers de configuration Apache personnalisés, vous pouvez définir l'option ProxyServer dans l'espace de noms aws:elasticbeanstalk:environment:proxy sur apache.

Le tableau ci-dessous répertorie les informations de migration pour les versions de plateforme AL2023/AL2 dans la plateforme Ruby.

Area Modifications et informations

Versions de Ruby installées

Sur les plateformes AL2023/AL2, Elastic Beanstalk n'installe que la dernière version d'une seule version de Ruby, correspondant à la branche de plateforme, sur chaque version de plateforme. Par exemple, chaque version de plateforme de la branche de plateforme Ruby 2.6 dispose uniquement de Ruby 2.6.x installé. Sur les versions de la plateforme AMI Amazon Linux, nous avons installé les dernières versions de plusieurs versions de Ruby, par exemple 2.4.x, 2.5.x et 2.6.x.

Si votre application utilise une version de Ruby qui ne correspond pas à la branche de plateforme que vous utilisez, nous vous recommandons de basculer vers une branche de plateforme qui dispose de la version de Ruby correcte pour votre application.

Serveur d'application

Sur les plateformes AL2023/AL2, Elastic Beanstalk installe uniquement le serveur d'applications Puma sur toutes les versions de plateforme Ruby. Vous pouvez utiliser un Procfile pour démarrer un autre serveur d'applications et un Gemfile pour l'installer.

Sur la plateforme AMI Amazon Linux, nous avons pris en charge deux types de branches de plateforme pour chaque version Ruby : l'une avec le serveur d'applications Puma et l'autre avec le serveur d'applications Passenger. Si votre application utilise Passenger, vous pouvez configurer votre environnement Ruby pour installer et utiliser Passenger.

Pour plus d'informations et d'exemples, consultez Utilisation de la plateforme Elastic Beanstalk Ruby.