Migration d'Amazon Linux AMI (AL1) vers AL2 ou AL2 023 - 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 d'Amazon Linux AMI (AL1) vers AL2 ou AL2 023

Si votre application Elastic Beanstalk est basée sur une branche de la plateforme AMI Amazon Linux, consultez cette section pour savoir comment migrer les environnements de votre application vers Amazon Linux 2 ou Amazon Linux 2023. Les branches de plate-forme de génération précédente basées sur Amazon Linux AMI 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. Certains domaines présentent toutefois des différences : l'option par défaut du service de métadonnées d'instance version 1 (IMDSv1), la prise en charge de l'outil d'instance pkg-repo et certaines configurations Apache. HTTPd Pour plus d’informations, consultez Amazon Linux 2023.

Différences et compatibilité

Il n'est pas garanti que les branches de la plateforme AL2 basées sur AL2 023/ soient 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 qu'Amazon Linux AMI et AL2 023/ AL2 partagent le même noyau Linux, ils diffèrent sur les points suivants : leur système d'initialisation, les libc versions, la chaîne d'outils du compilateur et les différents packages. Pour plus d'informations, consultez Amazon Linux 2 FAQs.

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 AL2 023. Nous vous recommandons de migrer vers une branche de la plateforme AL2 023.

  2. Déployez votre application dans l'environnement AL2 023/ 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 AL2 environnement AL2 023/ de destination est prêt à passer en production, échangez les CNAMEs deux environnements pour 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 décrit les points à prendre en compte lors de la planification de la migration d'une application vers AL2 023/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 AL2 plateformes AL2 023/, vous pouvez utiliser les fichiers de configuration comme avant, et toutes les sections fonctionnent de la même manière. Toutefois, certains paramètres peuvent ne pas fonctionner de la même manière que sur les AMI plateformes Amazon Linux précédentes. Par exemple :

  • Certains packages logiciels que vous installez à l'aide d'un fichier de configuration ne sont peut-être pas disponibles le AL2 023/ AL2 ou leur nom a peut-être 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 de détails, consultez Configuration du proxy inverse.

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, l'écriture de scripts de commande dans un YAML fichier peut s'avérer fastidieuse et difficile à tester.

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

Hooks de plateforme

AL2les plateformes ont introduit une nouvelle façon d'étendre la plateforme de votre environnement en ajoutant des fichiers exécutables pour connecter des répertoires aux 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 AL2 plate-forme AL2 023/, les crochets de plate-forme personnalisés ne fonctionnent pas. Vous devez migrer tous les hooks vers les nouveaux hooks de plateforme. Pour plus d'informations, consultez Hooks de plateforme.

Serveurs proxy pris en charge

AL2Les versions de AL2 plate-forme 023/ prennent en charge les mêmes serveurs proxy inverses que chaque plate-forme prise en charge dans ses versions de AMI plate-forme Amazon Linux. Toutes les versions de la plateforme AL2 023/ AL2 ; utilisent nginx comme serveur proxy inverse par défaut, à l'exception des plateformes et Docker. ECS Les plateformes TomcatPHP, Node.js et Python supportent également Apache HTTPD comme alternative. Toutes les plateformes permettent la configuration du serveur proxy de manière uniforme, comme décrit dans cette section. Cependant, la configuration du serveur proxy est légèrement différente de ce qu'elle était sur Amazon LinuxAMI. Voici les différences pour toutes les plateformes :

  • La valeur par défaut est nginx — Le serveur proxy par défaut sur AL2 toutes les versions de la plateforme AL2 023/ est nginx. Sur les versions de Tomcat et Python de la AMI plateforme Amazon Linux, le serveur proxy par défaut était ApacheHTTPD. PHP

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

  • Emplacement du fichier de configuration — Vous devez placer les fichiers de configuration du proxy dans les .platform/httpd répertoires .platform/nginx et sur toutes les versions de la AL2 plateforme AL2 023/. Sur les versions de AMI la plateforme 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 plus d'informations sur la configuration du proxy sur les AL2 plateformes AL2 023/, consultez. Configuration du proxy inverse

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

AL2Les AL2 plateformes 023/ 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, consultez Gestion des profils d'instance Elastic Beanstalk.

Intégrité améliorée

AL2Les versions de AL2 plate-forme 023/ permettent d'améliorer l'état de santé 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, consultez Elastic Beanstalk a amélioré les rapports et le suivi de l'état de santé.

Personnalisé AMI

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

Plateformes personnalisées

Les versions gérées AMIs de la AL2 plateforme AL2 023/ 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 Amazon Linux AMI (AL1) comprend trois branches de plate-forme. Nous recommandons un chemin de migration différent pour chacun d'entre eux.

AL1Branche de la plateforme Trajectoire de migration vers AL2 023/ AL2

Docker multi-conteneurs géré par Amazon et ECS exécuté sur Amazon Linux AMI () AL1
ECSbasé sur Docker AL2 AL2 023/ branches de la plateforme

Les branches ECSbasées sur la AL2 plate-forme Docker AL2 023/ offrent un chemin de migration simple pour les environnements exécutés sur la branche de plate-forme Docker multi-conteneurs. AL1

  • Comme la précédente AL1 branche Docker multi-conteneurs, les AL2 branches de la plateforme AL2 023/ utilisent Amazon ECS pour coordonner le déploiement de plusieurs conteneurs Docker sur un cluster Amazon dans un environnement Elastic ECS Beanstalk.

  • Les branches de la AL2 plateforme AL2 023/ prennent en charge toutes les fonctionnalités de la précédente branche Docker multi-conteneurs. AL1

  • Les branches de la AL2 plateforme AL2 023/ supportent également le même fichier Dockerrun.aws.json v2.

Pour plus d'informations sur la migration de vos applications exécutées sur la branche de la plateforme multi-conteneurs Docker Amazon Linux vers une branche ECSAmazon exécutée AL2 sur la branche AL2 023/ de la plateforme, consultez. Migration de votre ECS application Elastic Beanstalk d'un Docker multi-conteneurs géré vers Amazon Linux 2023 AL1 ECS

Docker exécuté sur Amazon Linux AMI () AL1

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

Nous vous recommandons de migrer vos applications exécutées dans des environnements basés sur Docker préconfiguré (Glassfish 5.0) ou Docker exécuté sur Amazon Linux AMI (AL1) vers des environnements basés sur le Docker exécuté sur Amazon Linux 2 ou Docker exécuté sur 023 branches de plate-forme. AL2

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 suivant répertorie les informations de migration spécifiques à la branche de plate-forme Docker Running on AL2 AL2 023/.

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 Amazon LinuxAMI, Elastic Beanstalk utilisait le pilote de stockage Device Mapper. Pour améliorer les performances, Elastic Beanstalk a provisionné un volume Amazon supplémentaire. EBS Dans les versions de la plateforme AL2 Docker AL2 023/, Elastic Beanstalk utilise le pilote de stockage OverlayFS et atteint des performances encore meilleures sans avoir besoin d'un volume séparé.

Avec Amazon LinuxAMI, si vous avez utilisé l'BlockDeviceMappingsoption de l'aws:autoscaling:launchconfigurationespace de noms pour ajouter des volumes de stockage personnalisés à un environnement Docker, nous vous conseillons d'ajouter également le EBS volume /dev/xvdcz Amazon approvisionné 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, consultez Configuration de Docker sur Amazon Linux AMI (antérieur à 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 Amazon Linux AMI Docker. AL2023/ Les versions de la plateforme AL2 Docker prennent en charge le nouveau format. Pour plus de détails, consultez Utilisation d'images provenant d'un dépôt privé dans Elastic Beanstalk.

Serveur proxy

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

Le tableau suivant répertorie les informations de migration pour les versions de AL2 plate-forme AL2 023/ de la plate-forme Go.

Area Modifications et informations

Transmission de port

Sur les AL2 plateformes AL2 023/, Elastic Beanstalk ne transmet pas de valeur de port à votre processus d'application par le biais de 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, consultez Configuration du proxy inverse.

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 contre Open JDK

Pour implémenter la plate-forme Java, édition standard (Java SE), les branches de la AL2 plateforme AL2 023/ utilisent Amazon Corretto, un AWS distribution du kit de développement Open Java (OpenJDK). Les anciennes branches de la plateforme Java SE d'Elastic Beanstalk utilisent les packages JDK Open inclus dans Amazon Linux. AMI

Outils de génération

AL2Les AL2 plateformes 023/ ont des versions plus récentes des outils de construction :gradle,maven, et. ant

JARgestion de fichiers

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

Transmission de port

Sur les AL2 plateformes AL2 023/, Elastic Beanstalk ne transmet pas de valeur de port à votre processus d'application par le biais de 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, consultez Configuration du proxy inverse.

Java 7

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

Le tableau suivant répertorie les informations de migration pour les versions de plate-forme AL2 023/ de la AL2 plate-forme Tomcat.

Area Modifications et informations

Options de configuration

Sur les versions de AL2 plate-forme AL2 023/, Elastic Beanstalk ne prend en charge qu'un sous-ensemble des options de configuration et des valeurs d'options de 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 AL2 plate-forme 023/AL2.

ProxyServer

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

Sur les versions de AMI la plateforme 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 devrait toujours fonctionner le AL2 023/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'XX:MaxPermSizeoption dans l'espace de aws:elasticbeanstalk:container:tomcat:jvmoptions noms n'est pas prise en charge sur les versions de AL2 plate-forme 023/AL2. Le JVM paramètre permettant de modifier la taille de la génération permanente s'applique uniquement à Java 7 et aux versions antérieures, et ne s'applique donc pas aux versions de AL2 plate-forme AL2 023/.

Chemin d'accès de l'application

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

Le tableau suivant répertorie les informations de migration pour les versions de AL2 plate-forme AL2 023/ de la plate-forme Node.js.

Area Modifications et informations

Versions de Node.js installées

Sur les AL2 plateformes AL2 023/, Elastic Beanstalk gère plusieurs branches de plate-forme Node.js et n'installe que la dernière version de la version majeure de Node.js correspondant à la branche de plate-forme de chaque version de plate-forme. 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 la AMI plateforme Amazon Linux, nous avons installé les multiples versions de plusieurs versions de Node.js sur chaque version de plate-forme, et nous n'avons maintenu qu'une seule branche de plate-forme.

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

Noms des fichiers HTTPD journaux Apache

Sur les AL2 plateformes AL2 023/, si vous utilisez le serveur HTTPD proxy Apache, les noms des fichiers HTTPD journaux sont access_log eterror_log, ce qui est cohérent avec toutes les autres plateformes supportant Apache. HTTPD Sur les versions de AMI la plateforme Amazon Linux, ces fichiers journaux étaient respectivement nommés access.log eterror.log.

Pour de plus amples informations sur les noms et les emplacements des fichiers journaux de toutes les plateformes, veuillez consulter Comment Elastic Beanstalk configure les journaux CloudWatch .

Options de configuration

Sur les AL2 plateformes AL2 023/, Elastic Beanstalk ne prend pas en charge les options de configuration dans 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, consultez Spécification Node.js dépendances avec un fichier package.json.

GzipCompression

Non pris en charge sur les versions de AL2 plate-forme 023/AL2.

ProxyServer

Dans les versions de plate-forme AL2 023/ AL2 Node.js, cette option a été déplacée vers l'aws:elasticbeanstalk:environment:proxyespace de noms. Vous pouvez choisir entre nginx (par défaut) et apache.

AL2Les versions de la plateforme 023/ 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 Amazon Linux AMI Node.js, cela était auparavant possible grâce à la none valeur de l'ProxyServeroption dans l'espace de aws:elasticbeanstalk:container:nodejs noms. 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 suivant répertorie les informations de migration pour les versions de plate-forme AL2 023/ de la AL2 PHP plate-forme.

Area Modifications et informations

PHPtraitement de fichiers

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

Serveur proxy

AL2Les versions de AL2 PHP plate-forme 023/ prennent en charge à la fois les serveurs proxy nginx et Apache. HTTPD La valeur par défaut est nginx.

Les versions de AMI PHP la plateforme Amazon Linux ne prenaient en charge qu'ApacheHTTPD. 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 suivant répertorie les informations de migration pour les versions de la AL2 plate-forme AL2 023/ dans la plate-forme Python.

Area Modifications et informations

WSGIserveur

Sur les AL2 plateformes AL2 023/, Gunicorn est le serveur par défaut. WSGI Par défaut, Gunicorn écoute sur le port 8000. Le port peut être différent de celui utilisé par votre application sur la AMI plateforme 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, consultez Espaces de noms de la configuration Python.

Vous pouvez également utiliser a Procfile pour spécifier et configurer le WSGI serveur. Pour plus de détails, consultez Configuration du WSGI serveur avec un Procfile sur Elastic Beanstalk.

Chemin d'accès de l'application

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

Serveur proxy

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

Les versions de la plateforme AMI Python d'Amazon Linux ne sont compatibles qu'avec ApacheHTTPD. 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 suivant répertorie les informations de migration pour les versions de la plate-forme AL2 023/ dans la AL2 plate-forme Ruby.

Area Modifications et informations

Versions de Ruby installées

Sur les AL2 plateformes AL2 023/, Elastic Beanstalk installe uniquement la dernière version d'une seule version de Ruby, correspondant à la branche de plate-forme, sur chaque version de plate-forme. 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 AMI plateforme 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 AL2 plateformes AL2 023/, Elastic Beanstalk installe le serveur d'applications Puma uniquement sur toutes les versions de la plateforme Ruby. Vous pouvez utiliser un Procfile pour démarrer un autre serveur d'applications et un Gemfile pour l'installer.

Sur la AMI plateforme Amazon Linux, nous avons pris en charge deux types de branches de plate-forme pour chaque version de 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.