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.
# Plateformes Elastic Beanstalk
AWS Elastic Beanstalk fournit une variété de plateformes sur lesquelles vous pouvez créer vos applications. Vous concevez votre application web sur l'une de ces plateformes. Elastic Beanstalk déploie votre code sur la version de la plateforme que vous avez sélectionnée pour créer un environnement d'application actif.
Elastic Beanstalk propose des plateformes dans différents langages de programmation, serveurs d'applications, et conteneurs Docker. Certaines plateformes possèdent plusieurs versions prise en charge simultanément.
**Topics**
+ [Glossaire des plateformes Elastic Beanstalk](platforms-glossary.md)
+ [Modèle de responsabilité partagée pour la maintenance de la plateforme Elastic Beanstalk](platforms-shared-responsibility.md)
+ [Stratégie de prise en charge de la plateforme Elastic Beanstalk](platforms-support-policy.md)
+ [Calendrier de sortie de la plateforme Elastic Beanstalk](platforms-schedule.md)
+ [Plateformes prises en charge par Elastic Beanstalk](concepts.platforms.md)
+ [Plateformes Linux Elastic Beanstalk](platforms-linux.md)
+ [Extension des plateformes Linux Elastic Beanstalk](platforms-linux-extend.md)
# Glossaire des plateformes Elastic Beanstalk
Vous trouverez ci-dessous les principaux termes relatifs aux AWS Elastic Beanstalk plateformes et à leur cycle de vie.
**Environnement d’exécution**
Langage de programmation propre au logiciel d'environnement d'exécution (infrastructure, bibliothèques, interpréteur, VM, etc.) requis pour exécuter votre code d'application.
**Composants Elastic Beanstalk**
Composants logiciels qu'Elastic Beanstalk ajoute à une plateforme pour activer la fonctionnalité Elastic Beanstalk. Par exemple, l'agent amélioré pour l'état de santé est nécessaire pour recueillir et rapporter les données d'état de santé.
**Plateforme**
Combinaison entre un système d'exploitation (OS), un environnement d'exécution, un serveur web, un serveur d'applications et les composants Elastic Beanstalk. Les plateformes fournissent des composants qui sont disponibles pour exécuter votre application.
**Version de plateforme**
Combinaison entre les versions spécifiques d'un système d'exploitation (OS), un environnement d'exécution, un serveur web, un serveur d'applications et les composants Elastic Beanstalk. Vous créez un environnement Elastic Beanstalk basé sur une version de plateforme et déployez votre application sur cette dernière.
Une version de plateforme possède un numéro de version sémantique au format *X.Y.Z*, où *X* est la version majeure, *Y* est la version mineure et *Z* est la version de correctif.
Une version de plateforme peut se trouver dans l'un des états suivants :
+ *Recommandé* — La dernière version de la plateforme dans une branche de plateforme prise en charge. Cette version contient le plus grand nombre de up-to-date composants et est recommandée pour une utilisation dans les environnements de production. Lorsqu'Elastic Beanstalk publie une nouvelle version de plateforme, celle-ci remplace la version précédente et devient la version de plateforme recommandée pour la branche de plateforme correspondante.
+ *Non recommandé* — Toute version de plate-forme qui n'est pas la dernière version de sa branche de plate-forme. Bien que ces versions puissent rester fonctionnelles, nous vous recommandons vivement de passer à la dernière version de la plateforme. Vous pouvez utiliser les [mises à jour gérées de la plateforme](environment-platform-update-managed.md) pour vous aider à rester up-to-date automatique.
Vous pouvez vérifier si une version de plate-forme est recommandée à l'aide de la commande AWS CLI **[describe-platform-version](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/describe-platform-version.html)** et en vérifiant le `PlatformLifecycleState` champ.
**Branche de plateforme**
Une ligne de versions de plateforme partageant des versions spécifiques (généralement majeures) de certains de leurs composants, notamment le système d'exploitation (OS), l'exécution ou des composants Elastic Beanstalk. Par exemple : *Python 3.13 s'exécute sur Amazon Linux 2023 64* bits ; *IIS 10.0 s'exécute sur Windows Server 2025 64 bits*. Les succursales de la plateforme reçoivent des mises à jour sous la forme de nouvelles versions de la plateforme. Chaque version de plateforme successive dans une branche est une mise à jour de la précédente.
La version recommandée dans chaque branche de plate-forme prise en charge est disponible sans condition pour la création d'un environnement. Les versions précédentes de la plateforme restent accessibles aux comptes dotés d'environnements actifs ou résiliés qui les utilisaient au moment où elles ont été remplacées par une nouvelle version. Les versions précédentes de la plate-forme sont dépourvues de la plupart des up-to-date composants et leur utilisation n'est pas recommandée.
Si vous avez besoin d'accéder aux versions précédentes de la plateforme au-delà de la disponibilité standard décrite ci-dessus, vous pouvez contacter le [AWS Support Center](https://console.aws.amazon.com/support/home#/) pour obtenir de l'aide.
Une branche de plateforme peut se trouver dans l'un des états suivants :
+ *Prise en charge* – Branche de plateforme actuelle. Elle comprend uniquement des *composants pris en charge*. Les composants pris en charge n'ont pas atteint la fin de vie (EOL), comme indiqué par leurs fournisseurs. Elle bénéficie de mises à jour continues de la plateforme et est recommandée pour une utilisation dans les environnements de production. Pour obtenir une liste de branches de plateformes prises en charge, consultez [Plateformes Elastic Beanstalk prises en charge](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html) dans le guide *Plateformes AWS Elastic Beanstalk *.
+ *Bêta* – Version préliminaire, pré-version de la branche de plateforme. Elle est de nature expérimentale. Elle peut bénéficier des mises à jour continues de la plateforme pendant un certain temps, mais ne dispose pas d’une prise en charge à long terme. Une branche de plateforme bêta n'est pas recommandée pour une utilisation dans des environnements de production. Utilisez-la uniquement à des fins d’évaluation. Pour obtenir la liste des branches de plateforme bêta, consultez [Versions de plateformes Elastic Beanstalk en bêta publique](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-beta.html) dans le guide *Plateformes AWS Elastic Beanstalk *.
+ *Obsolète* : branche de plate-forme dans laquelle un ou plusieurs composants (tels que le moteur d'exécution ou le système d'exploitation) approchent de la fin de vie (EOL) ou ont atteint la fin de vie, comme indiqué par leurs fournisseurs. Alors qu'une branche de plateforme obsolète continue de recevoir de nouvelles versions de plate-forme jusqu'à sa date de retrait, les composants qui ont atteint la fin de leur durée de vie ne sont pas mis à jour. Par exemple, si une version d'exécution atteint la fin de vie, la branche de plate-forme sera marquée comme obsolète mais continuera à recevoir les mises à jour du système d'exploitation jusqu'à la date de mise hors service de la branche de plate-forme. La branche de la plateforme ne continuera pas à recevoir les mises à jour de la version d'exécution EOL. L'utilisation d'une branche de plateforme obsolète n'est pas recommandée.
+ *Retiré* : branche de la plateforme qui ne reçoit plus aucune mise à jour. Les branches de plateforme retirées ne sont pas disponibles pour créer de nouveaux environnements Elastic Beanstalk à l'aide de la console Elastic Beanstalk. Si votre environnement utilise une branche de plate-forme retirée, vous devez passer à une branche de plate-forme prise en charge pour continuer à recevoir des mises à jour. L'utilisation d'une branche de plateforme retirée n'est pas recommandée. Pour plus de détails sur les succursales de plateforme retirées, consultez[Stratégie de prise en charge de la plateforme Elastic Beanstalk](platforms-support-policy.md). Pour consulter la liste des succursales de la plateforme dont la mise à la retraite est prévue, consultez le [calendrier des succursales de la plateforme qui prennent leur retraite](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/platforms-schedule.html#platforms-support-policy.depracation). Pour consulter les anciennes succursales de la plateforme retirées, consultez l'[historique des succursales de la plateforme retirées](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/platforms-schedule.html#platforms-support-policy.retired).
Si votre environnement utilise une branche de plateforme obsolète ou hors service, nous vous recommandons de la mettre à jour vers une version de plateforme dans une branche de plateforme prise en charge. Pour en savoir plus, consultez [Mise à jour de la version de la plateforme de votre environnement Elastic Beanstalk](using-features.platform.upgrade.md).
Vous pouvez vérifier l'état d'une branche de plate-forme à l'aide de la commande AWS CLI **[describe-platform-version](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/describe-platform-version.html)** et en vérifiant le `PlatformBranchLifecycleState` champ.
**Mise à jour de plateforme**
Version d'une nouvelle version de la plateforme qui contient des mises à jour de certains composants de la plateforme : système d'exploitation, environnement d'exécution, serveur Web, serveur d'applications et composants Elastic Beanstalk. Lorsqu'Elastic Beanstalk publie une nouvelle version de plateforme, celle-ci remplace la version précédente et devient la version de plateforme recommandée pour la branche de plateforme correspondante. Les mises à jour de la plateforme suivent la taxonomie sémantique des versions et peuvent comporter trois niveaux :
+ *Mise à jour majeure* – Mise à jour contenant des modifications incompatibles avec les versions de plateforme existantes. Vous devrez peut-être modifier votre application pour qu'elle fonctionne correctement sur une nouvelle version majeure. Une mise à jour majeure a un nouveau numéro de version majeure de plateforme.
+ *Mise à jour mineure* : mise à jour dont les modifications sont rétrocompatibles avec les versions existantes de la plateforme dans la plupart des cas. En fonction de votre application, vous devrez peut-être modifier votre application pour qu'elle fonctionne correctement sur une nouvelle version mineure. Une mise à jour mineure a un nouveau numéro de version mineure de plateforme.
+ *Mise à jour corrective* – Mise à jour consistant en publications de maintenance (correctifs de bogues, mises à jour de sécurité et améliorations de performances) qui sont rétrocompatibles avec une version de plateforme existante. Une mise à jour de correctif a un nouveau numéro de correctif de version de plateforme.
**Mises à jour gérées**
Fonctionnalité Elastic Beanstalk qui applique automatiquement les mises à jour correctives et mineures au système d'exploitation (OS), à l'environnement d'exécution, au serveur web, au serveur d'applications et aux composants Elastic Beanstalk pour une version de plateforme prise en charge par Elastic Beanstalk. Une mise à jour gérée applique une version de plateforme plus récente dans la même branche de plateforme à votre environnement. Vous pouvez configurer les mises à jour gérées pour n'appliquer que les mises à jour correctives ou les mises à jour mineures et correctives. Vous pouvez également désactiver entièrement les mises à jour gérées.
Pour de plus amples informations, veuillez consulter [Mises à jour gérées de la plateforme](environment-platform-update-managed.md).
# Modèle de responsabilité partagée pour la maintenance de la plateforme Elastic Beanstalk
AWS et nos clients partagent la responsabilité d'atteindre un niveau élevé de sécurité et de conformité des composants logiciels. Ce modèle de responsabilité partagée permet de réduire votre charge opérationnelle.
Pour plus de détails, consultez le [modèle de responsabilité AWS partagée](https://aws.amazon.com/compliance/shared-responsibility-model/).
AWS Elastic Beanstalk vous aide à mettre en œuvre votre version du modèle de responsabilité partagée en fournissant une fonctionnalité de *mises à jour gérées*. Cette fonction applique automatiquement les mises à jour correctives et mineures correspondant à une version de plateforme prise en charge par Elastic Beanstalk. Si une mise à jour gérée échoue, Elastic Beanstalk vous informe de l'échec pour que vous en teniez compte et que vous preniez des mesures immédiates.
Pour de plus amples informations, veuillez consulter [Mises à jour gérées de la plateforme](environment-platform-update-managed.md).
De plus, Elastic Beanstalk effectue les opérations suivantes :
+ Publie sa [stratégie de prise en charge de la plateforme](platforms-support-policy.md) et son calendrier de mise hors service pour les 12 mois prochains.
+ Libère les mises à jour correctives, mineures et majeures des composants du système d'exploitation (OS), du moteur d'exécution, du serveur d'applications et du serveur Web généralement dans les 30 jours suivant leur disponibilité. Elastic Beanstalk est responsable de la création de mises à jour des composants Elastic Beanstalk présents sur ses versions de plateforme prises en charge. Toutes les autres mises à jour sont fournies directement par leurs fournisseurs (propriétaires ou communautés).
Nous annonçons toutes les mises à jour de nos plateformes prises en charge dans les [notes de mise à jour](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/relnotes.html) du guide *Notes de mise à jour AWS Elastic Beanstalk *. Nous fournissons également une liste de toutes les plateformes prises en charge et de leurs composants, ainsi qu'un historique des plateformes, dans le guide *Plateformes AWS Elastic Beanstalk *. Pour de plus amples informations, veuillez consulter [Plateformes prises en charge et historique des composants](concepts.platforms.md#concepts.platforms.list).
Vous êtes chargé d'effectuer les tâches suivantes :
+ Mettez à jour tous les composants que vous contrôlez (identifiés en tant que **client** dans le [modèle de responsabilité AWS partagée](https://aws.amazon.com/compliance/shared-responsibility-model/)). Il s'agit notamment d'assurer la sécurité de votre application, de vos données et de tous les composants dont votre application a besoin et que vous avez téléchargé.
+ Assurez-vous que vos environnements Elastic Beanstalk s'exécutent sur une version de plateforme prise en charge et migrez tout environnement exécuté sur une version de plateforme hors service vers une version prise en charge.
+ Si vous utilisez une image machine Amazon (AMI) personnalisée pour votre environnement Elastic Beanstalk, corrigez, gérez et testez votre AMI personnalisée afin qu'elle reste à jour et compatible avec une version prise en charge de la plateforme Elastic Beanstalk. Pour plus d'informations sur la gestion des environnements avec une AMI personnalisée, consultez[Utilisation d'une image machine Amazon (AMI) personnalisée dans votre environnement Elastic Beanstalk](using-features.customenv.md).
+ Résolvez tous les problèmes qui surviennent lors de l'échec des tentatives de mises à jour gérées et réessayez la mise à jour.
+ Appliquez vous-même un correctif au système d'exploitation, à l'environnement d'exécution et au serveur web si vous n'avez pas choisi les mises à jour gérées par Elastic Beanstalk. Pour cela, vous pouvez [appliquer les mises à jour de plateforme manuellement](using-features.platform.upgrade.md) ou appliquer directement les correctifs aux composants sur toutes les ressources d'environnement concernées.
+ [Gérez la sécurité et la conformité de tous les AWS services que vous utilisez en dehors d'Elastic Beanstalk conformément AWS au modèle de responsabilité partagée.](https://aws.amazon.com/compliance/shared-responsibility-model/)
# Stratégie de prise en charge de la plateforme Elastic Beanstalk
Elastic Beanstalk prend en charge les succursales de plateformes qui continuent de recevoir des mises à jour mineures et correctives de la part de leurs fournisseurs (propriétaires ou communauté). Pour obtenir une définition complète des termes associés, veuillez consulter [Glossaire des plateformes Elastic Beanstalk](platforms-glossary.md).
## Branches de plate-forme mises hors service
Lorsqu'un composant d'une branche de plateforme prise en charge est marqué comme étant en fin de vie (EOL) par son fournisseur, Elastic Beanstalk marque la branche de plateforme comme étant retirée. Les composants d'une branche de plate-forme sont les suivants : système d'exploitation (OS), version du langage d'exécution, serveur d'applications ou serveur Web.
Une fois qu'une branche de la plateforme est marquée comme supprimée, les règles suivantes s'appliquent :
+ Elastic Beanstalk cesse de fournir des mises à jour de maintenance, notamment des mises à jour de sécurité.
+ Elastic Beanstalk ne fournit plus de support technique aux branches de plateforme abandonnées.
+ Elastic Beanstalk ne met plus la branche plateforme à la disposition des nouveaux clients d'Elastic Beanstalk pour les déploiements dans de nouveaux environnements. Il existe une période de grâce de 90 jours à compter de la publication de la date de retrait pour les clients existants dont les environnements actifs s'exécutent sur des branches de plateforme retirées.
**Note**
Une branche de plateforme retirée ne sera pas disponible dans la console Elastic Beanstalk. Toutefois, il sera disponible via la AWS CLI CLI EB et l'API EB pour les clients disposant d'environnements existants basés sur la branche de plate-forme retirée. Les clients existants peuvent également utiliser les consoles de l'[environnement Clone](using-features.managing.clone.md) et de [l'environnement Rebuild](environment-management-rebuild.md).
Pour obtenir la liste des branches de la plateforme dont la mise hors service est prévue, consultez la rubrique [Calendrier de mise hors service des branches de plateforme](platforms-schedule.md#platforms-support-policy.depracation) suivante consacrée au calendrier de la plateforme *Elastic Beanstalk*.
Pour plus d'informations sur ce à quoi vous attendre en cas de retrait de la branche plateforme de votre environnement, consultez[FAQ sur le retrait de la plateforme](using-features.migration-al.FAQ.md).
## Au-delà de la période de grâce de 90 jours
Notre politique concernant les succursales de plateforme retirées ne supprime pas l'accès aux environnements ni les ressources. Toutefois, les clients existants qui exécutent un environnement Elastic Beanstalk sur une branche de plateforme abandonnée doivent être conscients des risques que cela comporte. De tels environnements peuvent se retrouver dans une situation imprévisible, car Elastic Beanstalk n'est pas en mesure de fournir des mises à jour de sécurité, un support technique ou des correctifs aux succursales de plateforme abandonnées, le fournisseur ayant marqué la fin de vie de leurs composants par le fournisseur.
Par exemple, une vulnérabilité de sécurité néfaste et critique peut apparaître dans un environnement exécuté sur une branche de plateforme retirée. Ou encore, une action de l'API EB peut cesser de fonctionner pour l'environnement si elle devient incompatible avec le service Elastic Beanstalk au fil du temps. La possibilité de ce type de risques augmente avec la durée d'activité d'un environnement basé sur une branche de plateforme retirée. Pour continuer à profiter des améliorations importantes proposées par les fournisseurs des composants en matière de sécurité, de performances et de fonctionnalités, nous vous encourageons vivement à mettre à jour tous vos environnements Elastic Beanstalk vers une version de plateforme prise en charge.
Si votre application rencontre des problèmes lors de son exécution sur une branche de plate-forme abandonnée et que vous ne parvenez pas à la migrer vers une plate-forme prise en charge, vous devrez envisager d'autres solutions. Les solutions de contournement consistent à encapsuler l'application dans une image Docker pour l'exécuter en tant que conteneur Docker. Cela permettrait à un client d'utiliser n'importe laquelle de nos solutions Docker, telles que nos plateformes AL2 Elastic AL2 Beanstalk 023/ Docker, ou d'autres services basés sur Docker tels qu'Amazon ECS ou Amazon EKS. Les alternatives autres que Docker incluent notre AWS CodeDeploy service, qui permet une personnalisation complète des environnements d'exécution que vous souhaitez.
# Calendrier de sortie de la plateforme Elastic Beanstalk
Outre la publication mensuelle en cadence des nouvelles versions des branches de la plateforme, notre maintenance des versions inclut également les processus suivants :
+ *Publication de nouvelles branches de plate-forme* : celles-ci introduisent généralement une nouvelle version majeure d'un langage d'exécution, d'un système d'exploitation ou d'un serveur d'applications.
+ *Retrait des succursales de la plateforme* — Nous devons retirer une succursale de la plateforme lorsque l'un de ses composants atteint la fin de vie (EOL). Pour plus d'informations sur notre politique à l'égard des succursales retirées, voir [Stratégie de prise en charge de la plateforme Elastic Beanstalk](platforms-support-policy.md)
**Topics**
+ [Ressources de planification](#platforms-support-policy.resources)
+ [Prochaines versions des branches de la plateforme](#platforms-support-policy.upcoming-releases)
+ [Calendrier de mise hors service des branches de plateforme](#platforms-support-policy.depracation)
+ [Historique des branches de plateforme retirées](#platforms-support-policy.retired)
+ [Historique du serveur et du système d'exploitation retirés](#platforms-support-policy.retired.components)
## Ressources de planification
Les ressources suivantes peuvent vous aider à planifier la maintenance et le support de votre application exécutée sur une plateforme Elastic Beanstalk.
+ [AWS Elastic Beanstalk Guide des plateformes](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/welcome.html) — Ce guide fournit une liste détaillée des composants pour chacune de nos branches de plateforme. Il fournit également un historique de la plateforme par date de sortie avec les mêmes détails. Ce guide peut vous informer lorsque des composants spécifiques de la branche de votre plateforme sont modifiés. Si votre application commence à se comporter différemment, vous pouvez également faire référence à la date de l'événement dans le guide des plateformes pour voir si des modifications de plate-forme ont pu affecter votre application.
+ [AWS Elastic Beanstalk Notes de version](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/relnotes.html) — Nos notes de publication annoncent toutes les versions mineures et majeures de notre plateforme. Cela inclut les mises à jour mensuelles de notre plateforme, les mises à jour de sécurité, les correctifs et les annonces de départ à la retraite. Vous pouvez vous abonner à nos flux RSS à partir de la documentation des notes de publication.
## Prochaines versions des branches de la plateforme
Le tableau suivant répertorie les prochaines filiales de la plateforme Elastic Beanstalk et leur date de sortie cible. Ces dates sont provisoires et sujettes à modification.
| Version d'exécution/branche de plate-forme | Système d’exploitation | Date de sortie cible |
| --- | --- | --- |
| Python 3.15 | Amazon Linux 2023 | Novembre 2026 |
| Node.js 26 | Amazon Linux 2023 | Novembre 2026 |
| .NET 11 | Amazon Linux 2023 | décembre 2026 |
| PHP 8.6 | Amazon Linux 2023 | janvier 2027 |
| Ruby 4.1 | Amazon Linux 2023 | février 2027 |
## Calendrier de mise hors service des branches de plateforme
Le tableau suivant répertorie les succursales de la plateforme Elastic Beanstalk dont la mise hors service est prévue, car certains de leurs composants atteignent leur fin de vie (EOL). Toutes les succursales AL2 basées sur des plateformes ont une date de départ à la retraite au plus tard le 30 juin 2026, date à laquelle Amazon Linux 2 atteindra sa fin de vie. Pour plus d'informations sur Amazon Linux 2, consultez [Amazon Linux 2 FAQs](https://aws.amazon.com/amazon-linux-2/faqs/).
Pour une liste plus détaillée des branches de plateforme retirées, y compris leurs composants spécifiques, voir les [versions de plate-forme retirées](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-retiring.html) dans le guide des *AWS Elastic Beanstalk plateformes*.
| Version d'exécution/branche de plate-forme | Date de départ à la retraite cible |
| --- | --- |
| PHP 8.1 AL2023 | 31 mars 2026 |
| PHP 8.1 AL2 | 31 mars 2026 |
| Docker AL2 | 30 juin 2026 |
| ECS AL2 | 30 juin 2026 |
| Go 1 AL2 | 30 juin 2026 |
| Corretto 8 AL2 | 30 juin 2026 |
| Corretto 11 AL2 | 30 juin 2026 |
| Corretto 17 AL2 | 30 juin 2026 |
| Corretto 8 with Tomcat 9 AL2 | 30 juin 2026 |
| Corretto 11 with Tomcat 9 AL2 | 30 juin 2026 |
| .NET Core AL2 | 30 juin 2026 |
| Python 3.9 AL2023 | 31 juillet 2026 |
| Ruby 3.2 AL2023 | 31 juillet 2026 |
| Node.js 20 AL2023 | 31 juillet 2026 |
| IIS 10.0 on Windows Server 2016 (& Core) | 30 septembre 2026 |
| PHP 8.2 AL2023 | 31 mars 2027 |
| .NET 9 AL2023 | 31 mars 2027 |
| .NET 8 AL2023 | 31 mars 2027 |
## Historique des branches de plateforme retirées
Les tableaux suivants répertorient les branches de la plateforme Elastic Beanstalk dont le statut est déjà retiré. Vous pouvez consulter un historique détaillé de ces branches de plateforme et de leurs composants dans le guide « [Historique](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history.html) des *AWS Elastic Beanstalk plateformes* ».
**Amazon Linux 2023 (AL2023)**
| Version d'exécution/branche de plate-forme | Date de retrait |
| --- | --- |
| .NET 6 AL2023 | 8 avril 2025 |
| Node.js 18 AL2023 | 11 août 2025 |
**Amazon Linux (2AL2)**
| Version d'exécution/branche de plate-forme | Date de retrait |
| --- | --- |
| Corretto 11 with Tomcat 8.5 AL2 | 10 octobre 2024 |
| Corretto 8 with Tomcat 8.5 AL2 | 10 octobre 2024 |
| Corretto 11 with Tomcat 7 AL2 | 29 juin 2022 |
| Corretto 8 with Tomcat 7 AL2 | 29 juin 2022 |
| Node.js 18 AL2 | 11 août 2025 |
| Node.js 16 AL2 | 10 octobre 2024 |
| Node.js 14 AL2 | 10 octobre 2024 |
| Node.js 12 AL2 | 23 décembre 2022 |
| Node.js 10 AL2 | 29 juin 2022 |
| PHP 8.0 AL2 | 10 octobre 2024 |
| PHP 7.4 AL2 | 9 juin 2023 |
| PHP 7.3 AL2 | 29 juin 2022 |
| PHP 7.2 AL2 | 29 juin 2022 |
| Python 3.8 AL2 | 8 avril 2025 |
| Python 3.7 AL2 | 10 octobre 2024 |
| Ruby 3.0 AL2 | 10 octobre 2024 |
| Ruby 2.7 AL2 | 10 octobre 2024 |
| Ruby 2.6 AL2 | 23 décembre 2022 |
| Ruby 2.5 AL2 | 29 juin 2022 |
**AMI Amazon Linux (AL1)**
| Version d'exécution/branche de plate-forme | Date de retrait |
| --- | --- |
| Single Container Docker | 18 juillet 2022 |
| Multicontainer Docker | 18 juillet 2022 |
| Preconfigured Docker - GlassFish 5.0 with Java 8 | 18 juillet 2022 |
| Go 1 | 18 juillet 2022 |
| Java 8 | 18 juillet 2022 |
| Java 7 | 18 juillet 2022 |
| Java 8 with Tomcat 8.5 | 18 juillet 2022 |
| Java 7 with Tomcat 7 | 18 juillet 2022 |
| Node.js | 18 juillet 2022 |
| PHP 7.2 - 7.3 | 18 juillet 2022 |
| Python 3.6 | 18 juillet 2022 |
| Ruby 2,4, 2.5, 2.6 with Passenger | 18 juillet 2022 |
| Ruby 2.4, 2.5, 2.6 with Puma | 18 juillet 2022 |
| Go 1.3–1.10 | 31 octobre 2020 |
| Java 6 | 31 octobre 2020 |
| Node.js 4.x–8.x | 31 octobre 2020 |
| PHP 5.4–5.6 | 31 octobre 2020 |
| PHP 7.0–7.1 | 31 octobre 2020 |
| Python 2.6, 2.7, 3.4 | 31 octobre 2020 |
| Ruby 1.9.3 | 31 octobre 2020 |
| Ruby 2.0–2.3 | 31 octobre 2020 |
**Note**
[Le 18 juillet 2022,](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-07-18-linux-al1-retire.html) **Elastic Beanstalk a défini le statut de toutes les branches de la plateforme sur la base de l'AMI AL1 Amazon Linux () comme étant supprimées.** Pour de plus amples informations, veuillez consulter [FAQ sur le retrait de la plateforme](using-features.migration-al.FAQ.md).
**Windows Server**
| Version d'exécution/branche de plate-forme | Date de retrait |
| --- | --- |
| IIS 8.5 s'exécutant sur Windows Server (et Core) 2012 R2 64 bits | 4 décembre 2023 |
| IIS 8.5 s'exécutant sur Windows Server (& Core) 2012 R2 64 bits version 0.1.0 | 29 juin 2022 |
| IIS 8.5 s'exécutant sur Windows Server (& Core) 2012 R2 64 bits version 1.2.0 | 29 juin 2022 |
| IIS 10.0 s'exécutant sur Windows Server 2016 (& Core) 64 bits version 1.2.0 | 29 juin 2022 |
| IIS 8 s'exécutant sur la branche de plateforme Windows Server 2012 R1 64 bits | 22 juin 2022 |
| IIS 8 s'exécutant sur Windows Server 2012 R1 64 bits version 0.1.0 | 22 juin 2022 |
| IIS 8 s'exécutant sur Windows Server 2012 R1 64 bits version 1.2.0 | 22 juin 2022 |
**Note**
Pour plus d'informations sur le retrait des branches de la plateforme *Windows 2012 R2*, voir [Mise hors service des branches de plateforme Windows Server 2012 R2](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2023-12-04-windows-2012-retire.html) dans les *Notes de mise à jour AWS Elastic Beanstalk *.
## Historique du serveur et du système d'exploitation retirés
Les tableaux suivants fournissent un historique des systèmes d'exploitation, des serveurs d'applications et des serveurs Web qui ne sont plus pris en charge par les plateformes Elastic Beanstalk. Toutes les branches de la plateforme qui utilisaient ces composants sont désormais supprimées. Les dates reflètent la date de retrait de la dernière branche de la plateforme Elastic Beanstalk qui incluait le composant.
**Systèmes d'exploitation**
| Version du système d'exploitation | Date de mise hors service de la plateforme |
| --- | --- |
| Windows Server 2012 R2 running IIS 8.5 | 4 décembre 2023 |
| Windows Server Core 2012 R2 running IIS 8.5 | 4 décembre 2023 |
| AMI Amazon Linux (AL1) | 18 juillet 2022 |
| Windows Server 2012 R1 | 22 juin 2022 |
| Windows Server 2008 R2 | 28 octobre 2019 |
**Serveurs d’applications**
| Version du serveur d'applications | Date de mise hors service de la plateforme |
| --- | --- |
| Tomcat 7 | 29 juin 2022 pour les plateformes Amazon Linux (2AL2) 18 juillet 2022 pour les plateformes Amazon Linux AMI (AL1) |
| Tomcat 8 | 31 octobre 2020 |
| Tomcat 6 | 31 octobre 2020 |
**Serveurs Web**
| Version du serveur web | Date de mise hors service de la plateforme |
| --- | --- |
| IIS 8 exécutant Windows Server 64 bits | 22 juin 2022 |
| Serveur HTTP Apache 2.2 | 31 octobre 2020 |
| Nginx 1.12.2 | 31 octobre 2020 |
# Plateformes prises en charge par Elastic Beanstalk
AWS Elastic Beanstalk fournit une variété de plateformes sur lesquelles vous pouvez créer vos applications. Vous concevez votre application web sur l'une de ces plateformes. Elastic Beanstalk déploie votre code sur la version de la plateforme que vous avez sélectionnée pour créer un environnement d'application actif.
Elastic Beanstalk fournit les ressources nécessaires pour exécuter votre application, y compris une ou plusieurs instances Amazon. EC2 La pile logicielle exécutée sur les EC2 instances Amazon dépend de la version de plateforme spécifique que vous avez sélectionnée pour votre environnement.
**Le nom de la pile de solutions pour une branche de plate-forme**
[Vous pouvez utiliser le *nom de la pile de solutions* pour une version de branche de plate-forme donnée afin de lancer un environnement avec l'[EB CLI](eb-cli3.md), l'API [Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/) ou la CLI.AWS](https://aws.amazon.com/cli/) [Le guide *AWS Elastic Beanstalk des plateformes* répertorie le *nom de la pile de solutions* sous la version de la branche de plate-forme dans les sections Plateformes prises en charge par [Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html) et historique de la plate-forme.](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history.html)
Pour récupérer tous les noms de pile de solutions que vous pouvez utiliser pour créer un environnement, utilisez l'[ListAvailableSolutionStacks](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_ListAvailableSolutionStacks.html)API ou [https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/list-available-solution-stacks.html](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/list-available-solution-stacks.html)la AWS CLI.
Vous pouvez personnaliser et configurer le logiciel dont dépend votre application dans votre plateforme. Pour en savoir plus, veuillez consulter [Personnalisation du logiciel sur des serveurs Linux](customize-containers-ec2.md) et [Personnalisation du logiciel sur des serveurs Windows](customize-containers-windows-ec2.md). Des notes de mise à jour détaillées sont disponibles pour les mises à jour récentes dans le document suivant : [AWS Elastic Beanstalk Notes de mise à jour](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/).
## Plateformes prises en charge et historique des composants
Le guide *AWS Elastic Beanstalk des plateformes* répertorie toutes les versions actuelles des branches de plate-forme dans la section Plateformes prises en charge par [Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html). Le guide *des plateformes* répertorie également un *historique* des plateformes pour chaque plate-forme, qui inclut une liste des versions précédentes de la plateforme des succursales. Pour consulter l'*historique* de chaque plateforme, sélectionnez l'un des liens suivants.
+ [Docker](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-docker.html)
+ [Go](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-go.html)
+ [Java SE](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-javase.html)
+ [Tomcat (exécutant Java SE)](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-java.html)
+ [.NET Core sous Linux](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-dotnetlinux.html)
+ [.NET sous Windows Server](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-dotnet.html)
+ [Node.js](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-nodejs.html)
+ [PHP](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-php.html)
+ [Python](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-python.html)
+ [Ruby](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platform-history-ruby.html)
# Plateformes Linux Elastic Beanstalk
Les plateformes Linux Elastic Beanstalk fournissent de nombreuses fonctionnalités prêtes à l'emploi. Vous pouvez étendre les plateformes de plusieurs façons pour prendre en charge votre application. Pour en savoir plus, consultez [Extension des plateformes Linux Elastic Beanstalk](platforms-linux-extend.md).
La plupart des plateformes prises en charge par Elastic Beanstalk se basent sur le système d'exploitation Linux. Plus précisément, ces plateformes sont basées sur Amazon Linux, une distribution Linux fournie par AWS. Les plateformes Linux Elastic Beanstalk utilisent des instances Amazon Elastic Compute Cloud EC2 (Amazon), qui exécutent Amazon Linux.
**Topics**
+ [Versions d'Amazon Linux prises en charge](#platforms-linux.versions)
+ [Liste des plateformes Linux Elastic Beanstalk](#platforms-linux.list)
+ [Flux de travail (workflow) de déploiement d'instance](platforms-linux-extend.workflow.md)
+ [Flux de déploiement d'instance pour ECS s'exécutant sur Amazon Linux 2 et versions ultérieures](platforms-linux-extend.workflow.ecs-al2.md)
+ [Outils de script de plateforme pour vos environnements Elastic Beanstalk](custom-platforms-scripts.md)
## Versions d'Amazon Linux prises en charge
AWS Elastic Beanstalk prend en charge les plateformes basées sur Amazon Linux 2 et Amazon Linux 2023.
Pour plus d'informations sur Amazon Linux 2 et Amazon Linux 2023, consultez :
+ **Amazon Linux 2** — [Amazon Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-ami-basics.html) dans le *guide de EC2 l'utilisateur Amazon*.
+ **Amazon Linux 2023** – [Qu'est-ce qu'Amazon Linux 2023 ?](https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-linux.html) dans le *Guide de l'utilisateur Amazon Linux 2023*
Pour de plus amples informations sur les versions de plateforme prises en charge, veuillez consulter [Plateformes prises en charge par Elastic Beanstalk](concepts.platforms.md).
**Note**
Vous pouvez migrer votre application depuis une branche AL1 Elastic AL2 Beanstalk ou une branche de plateforme vers AL2 une branche de plateforme 023 équivalente. Pour de plus amples informations, veuillez consulter [Migration de votre application Elastic Beanstalk Linux vers Amazon Linux 2023 ou Amazon Linux 2](using-features.migration-al.md).
### Amazon Linux 2023
AWS a annoncé la [disponibilité générale](https://aws.amazon.com//blogs/aws/amazon-linux-2023-a-cloud-optimized-linux-distribution-with-long-term-support/) d'Amazon Linux 2023 en mars 2023. Le *Guide de l'utilisateur Amazon Linux 2023* résume les principales différences entre Amazon Linux 2 et Amazon Linux 2023. Pour plus d'informations, consultez [Comparaison entre Amazon Linux 2 et Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) (français non garanti) dans le guide de l'utilisateur.
Il existe un degré élevé de compatibilité entre les plateformes Elastic Beanstalk Amazon Linux 2 et Amazon Linux 2023. Il y a cependant quelques différences à noter :
+ **Version 1 du service de métadonnées d'instance (IMDSv1)** : le paramètre de l'[IMDSv1option Disable](command-options-general.md#command-options-general-autoscalinglaunchconfiguration) est défini par défaut `true` sur les plateformes AL2 023. Par défaut, c'est `false` sur AL2 les plateformes.
+ outil d'**instance pkg-repo — L'[pkg-repo](custom-platforms-scripts.md#custom-platforms-scripts.pkg-repo)outil** n'est pas disponible pour les environnements exécutés sur AL2 les plateformes 023. Toutefois, vous pouvez toujours appliquer manuellement les mises à jour du package et du système d'exploitation à une instance AL2 023. Pour plus d'informations, consultez [Gestion des packages et des mises à jour du système d'exploitation](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html) (français non garanti) dans le *Guide de l'utilisateur Amazon Linux 2023*.
+ ** HTTPd Configuration Apache** — Le `httpd.conf` fichier Apache pour les plateformes AL2 023 comporte des paramètres de configuration différents de ceux des AL2 plateformes suivantes :
+ Interdire l'accès à l'ensemble du système de fichiers du serveur par défaut. Ces paramètres sont décrits dans la section *Protection par défaut des fichiers du serveur* de la page [Conseils sur la sécurité](https://httpd.apache.org/docs/2.4/misc/security_tips.html) du site web d'Apache.
+ Refusez l'accès à la configuration de `.htaccess` dans tous les annuaires, à l'exception de ceux spécifiquement activés. Ce paramètre est décrit dans la section *Protection de la configuration du système* de la page [Conseils sur la sécurité](https://httpd.apache.org/docs/2.4/misc/security_tips.html) du site web d'Apache. La page [Tutoriel du serveur HTTP Apache : fichiers .htaccess](https://httpd.apache.org/docs/2.4/howto/htaccess.html) indique que ce paramètre peut contribuer à améliorer les performances.
+ Refuser l'accès aux fichiers portant le modèle de nom `.ht*`. Ce paramètre empêche les clients web de visualiser les fichiers `.htaccess` et `.htpasswd`.
Vous pouvez modifier les paramètres de configuration ci-dessus en fonction de votre environnement. Pour de plus amples informations, veuillez consulter [Configuration d'Apache HTTPD](platforms-linux-extend.proxy.md#platforms-linux-extend.proxy.httpd).
+ **Prise en charge des variables d'environnement multilignes** — Les plateformes AL2 023 prennent en charge les valeurs multilignes pour les variables d'environnement et les secrets dans les configurations de service Systemd. Les plateformes Amazon Linux 2 ne prennent pas en charge les valeurs de variables d'environnement multilignes. Cette amélioration vous permet d'utiliser des secrets multilignes et des valeurs de configuration sur les plateformes AL2 023. Pour plus d'informations sur l'utilisation des variables d'environnement et des secrets, consultez[Valeurs multilignes dans les variables d'environnement Amazon Linux 2](AWSHowTo.secrets.env-vars.md#AWSHowTo.secrets.multiline).
+ **CloudWatch transfert de journal personnalisé** — L'agent CloudWatch Logs obsolète (`awslogs`package) n'est pas disponible sur les plateformes AL2 023. Si vous avez des configurations personnalisées de transfert de journal qui installent et utilisent l'`awslogs`agent obsolète, vous devez mettre à jour vos fichiers de configuration pour utiliser l' CloudWatch agent unifié lors de la migration d'Amazon Linux 2 vers 023. AL2 Pour de plus amples informations, veuillez consulter [Streaming de fichiers journaux personnalisés](AWSHowTo.cloudwatchlogs.md#AWSHowTo.cloudwatchlogs.streaming.custom).
**Différences spécifiques à la plateforme**
Outre les différences de système d'exploitation de base, il existe des différences spécifiques à la plate-forme entre les plateformes d'exécution Amazon Linux 2 et AL2 023 :
+ **Branchement de plate-forme .NET** — La stratégie de branchement de la plate-forme .NET diffère entre Amazon Linux 2 et AL2 023. Sur Amazon Linux 2, la plate-forme .NET Core gère une fenêtre rotative des versions principales de .NET au sein d'une seule branche de plate-forme. Le AL2 023, chaque branche de plate-forme est épinglée à une version majeure de .NET spécifique (par exemple, .NET 9, .NET 10).
Si vous déployez des applications dépendantes du framework (applications qui s'appuient sur le runtime .NET installé sur la plate-forme), vous devez sélectionner une branche de plate-forme correspondant à la version .NET cible de votre application. Si vous déployez des applications autonomes (applications qui regroupent leur propre environnement d'exécution .NET), vous pouvez utiliser n'importe quelle branche de la plate-forme .NET AL2 023, quelle que soit la version .NET de votre application, car celle-ci ne dépend pas du runtime installé sur la plate-forme. Pour de plus amples informations, veuillez consulter [Regroupement d'applications pour la plateforme .NET Core sur Linux Elastic Beanstalk](dotnet-linux-platform-bundle-app.md).
+ **Sélection de la version de Node.js** — La plateforme Node.js sur Amazon Linux 2 permet de spécifier une version Node.js dans le `package.json` fichier de votre application. La plateforme Node.js sur AL2 023 ne prend pas en charge cette fonctionnalité. Vous devez utiliser la version par défaut de Node.js fournie par la branche de plateforme. Pour plus d'informations sur la gestion des versions de Node.js, consultez[Configuration des dépendances de votre application sur Elastic Beanstalk](nodejs-platform-dependencies.md).
+ **Version du serveur Ruby Puma** — La plateforme Ruby sur Amazon Linux 2 ignore la version Puma spécifiée dans le `Gemfile.lock` fichier de votre application et utilise la version Puma par défaut de la plateforme. La plateforme Ruby du AL2 023 respecte la version Puma spécifiée dans le `Gemfile.lock` cas où elle est présente. Si aucune version n'est spécifiée, la plateforme installe la version Puma par défaut de la plateforme.
+ **Disponibilité des packages PHP** — Certains packages disponibles sur les plateformes PHP Amazon Linux 2 ne sont pas disponibles sur les plateformes PHP AL2 023 :
+ *Packages clients MySQL — Les packages clients* de ligne de `mysql-devel` commande `mysql` et de ligne de commande ne sont pas installés sur les plateformes PHP AL2 023. Si votre application nécessite une connectivité à une base de données MySQL, utilisez le PHP `mysqli` ou des `pdo_mysql` extensions, disponibles sur les deux plateformes.
+ *Outils Compass et Ruby* — Les `rubygems` packages `ruby-devel` et pour le support du framework CSS Compass ne sont pas installés sur les plateformes PHP AL2 023. Compass est obsolète. Envisagez d'utiliser des outils de prétraitement CSS modernes comme alternative.
+ **Outils de contrôle de version Go** — Le système de contrôle de version Bazaar (`bzr`) n'est pas disponible sur les plateformes AL2 023 Go. Bazaar est obsolète et n'est pas inclus dans le référentiel de packages AL2 023. Utilisez plutôt Git, Mercurial ou Subversion pour le contrôle de version, qui sont tous disponibles sur les plateformes AL2 023 Go.
## Liste des plateformes Linux Elastic Beanstalk
La liste suivante fournit les plateformes Linux prises en charge par Elastic Beanstalk pour les différents langages de programmation et les conteneurs Docker. Elastic Beanstalk propose des plateformes basées sur Amazon Linux 2 et Amazon Linux 2023 pour toutes ces plateformes. Pour en savoir plus sur une plateforme, sélectionnez le lien correspondant.
+ [Docker (et Docker ECS)](create_deploy_docker.md)
+ [Go](create_deploy_go.md)
+ [Tomcat (exécutant Java SE)](create_deploy_Java.md)
+ [Java SE](create_deploy_Java.md)
+ [.NET Core sous Linux](create-deploy-dotnet-core-linux.md)
+ [Node.js](create_deploy_nodejs.md)
+ [PHP](create_deploy_PHP_eb.md)
+ [Python](create-deploy-python-apps.md)
+ [Ruby](create_deploy_Ruby.md)
# Flux de travail (workflow) de déploiement d'instance
**Note**
Les informations de cette section ne s'appliquent pas aux branches de plateforme *ECS s'exécutant sur Amazon Linux 2 et Amazon Linux 2023*. Pour plus d'informations, voir la section suivante [Flux de déploiement d'instance pour ECS s'exécutant sur Amazon Linux 2 et versions ultérieuresFlux de travail de déploiement d'instances pour ECS AL2 à partir de](platforms-linux-extend.workflow.ecs-al2.md).
Avec de nombreuses façons d'étendre la plateforme de votre environnement, il est utile de savoir ce qui se passe chaque fois qu'Elastic Beanstalk alloue une instance ou exécute un déploiement sur une instance. Le diagramme suivant illustre l'ensemble du workflow de déploiement. Elles décrivent les différentes phases d'un déploiement et les étapes suivies par Elastic Beanstalk au cours de chaque phase.
**Remarques**
Le diagramme ne représente pas l'ensemble complet des étapes suivies par Elastic Beanstalk sur les instances d'environnement au cours du déploiement. Nous fournissons ce diagramme à titre d'illustration, pour vous indiquer l'ordre et le contexte de l'exécution de vos personnalisations.
Par souci de simplicité, le diagramme ne mentionne que les sous-répertoires hook `.platform/hooks/*` (pour les déploiements d'applications), et non les sous-répertoires hook `.platform/confighooks/*` (pour les déploiements de configuration). Les hooks dans ces derniers sous-répertoires s'exécutent exactement au cours des mêmes étapes que les hooks dans les sous-répertoires correspondants indiqués dans le diagramme.
![\[Flux de travail pour l'ordre d'exécution des extensions sur une instance d'environnement exécutée sur une plateforme Amazon Linux.\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/platforms-linux-extend-order.png)
La liste suivante détaille les phases et les étapes de déploiement.
1. **Étapes initiales**
Elastic Beanstalk télécharge et extrait votre application. Après chacune de ces étapes, Elastic Beanstalk exécute l'une des étapes d'extensibilité.
1. Exécute les commandes présentes dans la section [commands:](customize-containers-ec2.md#linux-commands) de tout fichier de configuration.
1. Exécute tous les fichiers exécutables trouvés dans le répertoire `.platform/hooks/prebuild` de votre bundle source (`.platform/confighooks/prebuild` pour un déploiement de configuration).
1. **Configuration**
Elastic Beanstalk configure votre application et le serveur proxy.
1. Exécute les commandes trouvées dans le bundle de fichiers source `Buildfile`.
1. Copie vos fichiers de configuration proxy personnalisés, le cas échéant, du répertoire `.platform/nginx` de votre bundle de fichiers source vers leur emplacement d'exécution.
1. Exécute les commandes de la section [container\$1commands:](customize-containers-ec2.md#linux-container-commands) de tout fichier de configuration.
1. Exécute tous les fichiers exécutables trouvés dans le répertoire `.platform/hooks/predeploy` de votre bundle source (`.platform/confighooks/predeploy` pour un déploiement de configuration).
1. **Déploiement**
Elastic Beanstalk déploie et exécute votre application et le serveur proxy.
1. Exécute la commande trouvée dans le fichier `Procfile` de votre bundle de fichiers source.
1. Exécute ou réexécute le serveur proxy avec vos fichiers de configuration proxy personnalisés, le cas échéant.
1. Exécute tous les fichiers exécutables trouvés dans le répertoire `.platform/hooks/postdeploy` de votre bundle source (`.platform/confighooks/postdeploy` pour un déploiement de configuration).
# Flux de déploiement d'instance pour ECS s'exécutant sur Amazon Linux 2 et versions ultérieures
La section précédente décrit les fonctions d'extensibilité prises en charge pendant les phases du flux de déploiement d'applications. Il existe certaines différences pour les branches de la plateforme Docker [*ECS s'exécutant sur Amazon Linux 2 et versions ultérieures*](create_deploy_docker_ecs.md). Cette section explique comment ces concepts s'appliquent à cette branche de plateforme spécifique.
Avec de nombreuses façons d'étendre la plateforme de votre environnement, il est utile de savoir ce qui se passe chaque fois qu'Elastic Beanstalk alloue une instance ou exécute un déploiement sur une instance. Le diagramme suivant illustre l'ensemble du flux de déploiement pour un environnement basé sur les branches de plateforme *ECS s'exécutant sur Amazon Linux 2* et *ECS s'exécutant sur Amazon Linux 2023*. Elles décrivent les différentes phases d'un déploiement et les étapes suivies par Elastic Beanstalk au cours de chaque phase.
Contrairement au flux décrit dans la section précédente, la phase de configuration du déploiement ne prend pas en charge les fonctions d'extensibilité suivantes : commandes `Buildfile`, commandes `Procfile`, configuration de proxy inverse.
**Remarques**
Le diagramme ne représente pas l'ensemble complet des étapes suivies par Elastic Beanstalk sur les instances d'environnement au cours du déploiement. Nous fournissons ce diagramme à titre d'illustration, pour vous indiquer l'ordre et le contexte de l'exécution de vos personnalisations.
Par souci de simplicité, le diagramme ne mentionne que les sous-répertoires hook `.platform/hooks/*` (pour les déploiements d'applications), et non les sous-répertoires hook `.platform/confighooks/*` (pour les déploiements de configuration). Les hooks dans ces derniers sous-répertoires s'exécutent exactement au cours des mêmes étapes que les hooks dans les sous-répertoires correspondants indiqués dans le diagramme.
![\[Flux de travail pour l'ordre d'exécution des extensions sur une instance d'environnement sur la plate-forme Docker basée sur ECS.\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/platform-ecs-al2-extended-order.png)
La liste suivante détaille les étapes du flux de déploiement.
1. Exécute tous les fichiers exécutables trouvés dans le répertoire `appdeploy/pre` sous `EBhooksDir`.
1. Exécute tous les fichiers exécutables trouvés dans le répertoire `.platform/hooks/prebuild` de votre bundle source (`.platform/confighooks/prebuild` pour un déploiement de configuration).
1. Exécute tous les fichiers exécutables trouvés dans le répertoire `.platform/hooks/predeploy` de votre bundle source (`.platform/confighooks/predeploy` pour un déploiement de configuration).
1. Exécute tous les fichiers exécutables trouvés dans le répertoire `appdeploy/enact` sous `EBhooksDir`.
1. Exécute tous les fichiers exécutables trouvés dans le répertoire `appdeploy/post` sous `EBhooksDir`.
1. Exécute tous les fichiers exécutables trouvés dans le répertoire `.platform/hooks/postdeploy` de votre bundle source (`.platform/confighooks/postdeploy` pour un déploiement de configuration).
La référence à `EBhooksDir` représente le chemin d'accès au répertoire des hooks de la plateforme. Pour récupérer le nom du chemin d'accès au répertoire, utilisez l'outil de script [get-config](custom-platforms-scripts.md#custom-platforms-scripts.get-config) sur la ligne de commande de votre instance d'environnement, comme illustré :
```
$ /opt/elasticbeanstalk/bin/get-config platformconfig -k EBhooksDir
```
# Outils de script de plateforme pour vos environnements Elastic Beanstalk
Cette rubrique décrit les outils AWS Elastic Beanstalk destinés aux environnements utilisant les plateformes Amazon Linux. Les outils se trouvent sur les EC2 instances Amazon des environnements Elastic Beanstalk.
## get-config
Utilisez l'`get-config`outil pour récupérer les valeurs des variables d'environnement en texte brut et d'autres informations relatives à la plate-forme et à l'instance. Cet outil est disponible dans `/opt/elasticbeanstalk/bin/get-config`.
### Commandes get-config
Chaque commande d'outil `get-config` renvoie un type spécifique d'informations. Utilisez la syntaxe suivante pour exécuter les commandes de n'importe quel outil.
```
$ /opt/elasticbeanstalk/bin/get-config command [ options ]
```
L'exemple suivant exécute uniquement la commande `environment`.
```
$ /opt/elasticbeanstalk/bin/get-config environment -k PORT
```
Selon la commande et les options que vous choisissez, l'outil renvoie un objet (JSON ou YAML) avec des paires clé-valeur, ou une seule valeur.
Vous pouvez effectuer un test `get-config` en utilisant SSH pour vous connecter à une EC2 instance de votre environnement Elastic Beanstalk.
**Note**
Lorsque vous exécutez `get-config` pour des tests, certaines commandes peuvent nécessiter des privilèges utilisateur root pour accéder aux informations sous-jacentes. Si vous obtenez une erreur d'autorisation d'accès, exécutez à nouveau la commande sous `sudo`.
Vous n'avez pas besoin d'ajouter `sudo` lorsque vous utilisez l'outil dans les scripts que vous déployez dans votre environnement. Elastic Beanstalk exécute tous vos scripts en tant qu'utilisateur racine.
Les sections suivantes décrivent les commandes des outils.
#### optionsettings – Options de configuration
La commande `get-config optionsettings` renvoie un objet répertoriant les options de configuration définies sur l'environnement et utilisées par la plateforme sur les instances d'environnement. Elles sont organisées par espace de noms.
```
$ /opt/elasticbeanstalk/bin/get-config optionsettings
{"aws:elasticbeanstalk:application:environment":{"JDBC_CONNECTION_STRING":""},"aws:elasticbeanstalk:container:tomcat:jvmoptions":{"JVM Options":"","Xms":"256m","Xmx":"256m"},"aws:elasticbeanstalk:environment:proxy":{"ProxyServer":"nginx","StaticFiles":[""]},"aws:elasticbeanstalk:healthreporting:system":{"SystemType":"enhanced"},"aws:elasticbeanstalk:hostmanager":{"LogPublicationControl":"false"}}
```
Pour renvoyer une option de configuration spécifique, utilisez l'option `--namespace` (`-n`) pour spécifier un espace de noms, et l'option `--option-name` (`-o`) pour spécifier un nom d'option.
```
$ /opt/elasticbeanstalk/bin/get-config optionsettings -n aws:elasticbeanstalk:container:php:phpini -o memory_limit
256M
```
#### environment – Propriétés de l'environnement
La `get-config environment` commande renvoie un objet contenant une liste de propriétés d'environnement, y compris celles configurées par l'utilisateur et fournies par Elastic Beanstalk. Les propriétés configurées par l'utilisateur sont définies dans la [console](environments-cfg-softwaresettings.md#environments-cfg-softwaresettings-console) sous forme de *texte brut* ou avec l'espace de noms [aws:elasticbeanstalk:application:environment](command-options-general.md#command-options-general-elasticbeanstalkapplicationenvironment) des options de configuration.
```
$ /opt/elasticbeanstalk/bin/get-config environment
{"JDBC_CONNECTION_STRING":"","RDS_PORT":"3306","RDS_HOSTNAME":"anj9aw1b0tbj6b.cijbpanmxz5u.us-west-2.rds.amazonaws.com","RDS_USERNAME":"testusername","RDS_DB_NAME":"ebdb","RDS_PASSWORD":"testpassword1923851"}
```
Par exemple, Elastic Beanstalk fournit des propriétés d'environnement pour la connexion à une instance de base de données Amazon RDS intégrée (par exemple, `RDS_HOSTNAME`). Ces propriétés de connexion RDS apparaissent dans la sortie de `get-config environment`. Cependant, ils n'apparaissent pas dans le rendu final de `get-config optionsettings`. Cela est dû au fait qu'ils n'étaient pas définis dans les options de configuration.
Pour renvoyer une propriété d'environnement spécifique, utilisez l'option `--key` (`-k`) pour spécifier une propriété clé.
```
$ /opt/elasticbeanstalk/bin/get-config environment -k TESTPROPERTY
testvalue
```
**Note**
L'`get-config`outil ne peut pas récupérer les [variables d'environnement qui stockent des secrets](AWSHowTo.secrets.env-vars.md). Pour plus d'informations sur la façon de récupérer par programmation des valeurs à partir de magasins secrets ou de paramètres, consultez [Utilisation de Secrets Manager](AWSHowTo.secrets.Secrets-Manager-and-Parameter-Store.md#AWSHowTo.secrets.Secrets-Manager) ou. [Utilisation du Systems Manager Parameter Store](AWSHowTo.secrets.Secrets-Manager-and-Parameter-Store.md#AWSHowTo.secrets.SSM-parmameter-store)
#### container – Valeurs de configuration sur instance
La commande `get-config container` renvoie un objet qui répertorie les valeurs de configuration de la plateforme et de l'environnement pour les instances d'environnement.
L'exemple suivant illustre la sortie de la commande dans un environnement Amazon Linux 2 Tomcat.
```
$ /opt/elasticbeanstalk/bin/get-config container
{"common_log_list":["/var/log/eb-engine.log","/var/log/eb-hooks.log"],"default_log_list":["/var/log/nginx/access.log","/var/log/nginx/error.log"],"environment_name":"myenv-1da84946","instance_port":"80","log_group_name_prefix":"/aws/elasticbeanstalk","proxy_server":"nginx","static_files":[""],"xray_enabled":"false"}
```
Pour renvoyer la valeur d'une clé spécifique, utilisez l'option `--key` (`-k`) pour spécifier la clé.
```
$ /opt/elasticbeanstalk/bin/get-config container -k environment_name
myenv-1da84946
```
#### addons – Valeurs de configuration du module complémentaire
La commande `get-config addons` renvoie un objet qui contient des informations de configuration des modules complémentaires d'environnement. Utilisez-la pour récupérer la configuration d'une base de données Amazon RDS qui est associée à l'environnement.
```
$ /opt/elasticbeanstalk/bin/get-config addons
{"rds":{"Description":"RDS Environment variables","env":{"RDS_DB_NAME":"ebdb","RDS_HOSTNAME":"ea13k2wimu1dh8i.c18mnpu5rwvg.us-east-2.rds.amazonaws.com","RDS_PASSWORD":"password","RDS_PORT":"3306","RDS_USERNAME":"user"}}}
```
Vous pouvez restreindre le résultat de deux façons. Pour récupérer les valeurs d'un module complémentaire spécifique, utilisez l'option `--add-on` (`-a`) pour spécifier le nom du module complémentaire.
```
$ /opt/elasticbeanstalk/bin/get-config addons -a rds
{"Description":"RDS Environment variables","env":{"RDS_DB_NAME":"ebdb","RDS_HOSTNAME":"ea13k2wimu1dh8i.c18mnpu5rwvg.us-east-2.rds.amazonaws.com","RDS_PASSWORD":"password","RDS_PORT":"3306","RDS_USERNAME":"user"}}
```
Pour renvoyer la valeur d'une clé spécifique dans un module complémentaire, ajoutez l'option `--key` (`-k`) pour spécifier la clé.
```
$ /opt/elasticbeanstalk/bin/get-config addons -a rds -k RDS_DB_NAME
ebdb
```
#### platformconfig – Valeurs de configuration constantes
La commande `get-config platformconfig` renvoie un objet qui contient des informations de configuration de la plateforme qui sont constantes pour la version de la plateforme. La sortie est la même dans tous les environnements qui s'exécutent la même version de plateforme. L'objet de sortie de la commande comporte deux objets incorporés :
+ `GeneralConfig` : contient des informations qui sont constantes sur les dernières versions de toutes les branches de plateforme Amazon Linux 2 et Amazon Linux 2023.
+ `PlatformSpecificConfig` – Contient des informations qui sont constantes pour la version de la plateforme et qui lui sont spécifiques.
L'exemple suivant montre la sortie de la commande sur un environnement qui utilise *Tomcat 8.5 exécutant la branche plateforme Corretto 11*.
```
$ /opt/elasticbeanstalk/bin/get-config platformconfig
{"GeneralConfig":{"AppUser":"webapp","AppDeployDir":"/var/app/current/","AppStagingDir":"/var/app/staging/","ProxyServer":"nginx","DefaultInstancePort":"80"},"PlatformSpecificConfig":{"ApplicationPort":"8080","JavaVersion":"11","TomcatVersion":"8.5"}}
```
Pour renvoyer la valeur d'une clé spécifique, utilisez l'option `--key` (`-k`) pour spécifier la clé. Ces clés sont uniques sur les deux objets incorporés. Vous n'avez pas besoin de spécifier l'objet qui contient la clé.
```
$ /opt/elasticbeanstalk/bin/get-config platformconfig -k AppStagingDir
/var/app/staging/
```
### Options de sortie get-config
Utilisez l'option `--output` pour spécifier le format de l'objet en sortie. Les valeurs valides sont `JSON` (par défaut) et `YAML`. Il s'agit d'une option globale. Vous devez le spécifier avant le nom de la commande.
L'exemple suivant renvoie des valeurs d'option de configuration au format YAML.
```
$ /opt/elasticbeanstalk/bin/get-config --output YAML optionsettings
aws:elasticbeanstalk:application:environment:
JDBC_CONNECTION_STRING: ""
aws:elasticbeanstalk:container:tomcat:jvmoptions:
JVM Options: ""
Xms: 256m
Xmx: 256m
aws:elasticbeanstalk:environment:proxy:
ProxyServer: nginx
StaticFiles:
- ""
aws:elasticbeanstalk:healthreporting:system:
SystemType: enhanced
aws:elasticbeanstalk:hostmanager:
LogPublicationControl: "false"
```
## pkg-repo
**Note**
L'outil `pkg-repo` n'est pas disponible pour les environnements basés sur les plateformes Amazon Linux 2023. Toutefois, vous pouvez appliquer manuellement les mises à jour du package et du système d'exploitation à une instance AL2 023. Pour plus d'informations, consultez [Gestion des packages et des mises à jour du système d'exploitation](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html) (français non garanti) dans le *Guide de l'utilisateur Amazon Linux 2023*
Dans certaines circonstances urgentes, vous devrez peut-être mettre à jour vos EC2 instances Amazon avec un correctif de sécurité Amazon Linux 2 qui n'a pas encore été publié avec les versions requises de la plateforme Elastic Beanstalk. Vous ne pouvez pas effectuer de mise à jour manuelle sur vos environnements Elastic Beanstalk par défaut. En effet, les versions de la plateforme sont verrouillées sur une version spécifique du référentiel Amazon Linux 2. Ce verrou garantit que les instances exécutent des versions logicielles compatibles et prises en charge. Pour les cas urgents, l'outil `pkg-repo` permet une solution de contournement pour mettre à jour manuellement les packages yum sur Amazon Linux 2 si vous devez les installer sur un environnement avant qu'ils ne soient publiés dans une nouvelle version de la plateforme Elastic Beanstalk.
L'outil `pkg-repo` sur les plateformes Amazon Linux 2 permet de déverrouiller le référentiels de paquets `yum`. Vous pouvez ensuite effectuer manuellement une commande **yum update** pour un correctif de sécurité. Inversement, vous pouvez suivre la mise à jour à l'aide de l'outil pour verrouiller les référentiels de paquets yum afin d'éviter d'autres mises à jour. L'`pkg-repo`outil est disponible dans le `/opt/elasticbeanstalk/bin/pkg-repo` répertoire de toutes les EC2 instances de vos environnements Elastic Beanstalk.
Les modifications effectuées à l'aide de l'`pkg-repo`outil sont effectuées uniquement sur l' EC2 instance sur laquelle l'outil est utilisé. Elles n'affectent pas d'autres instances et n'empêchent pas les futures mises à jour de l'environnement. Les exemples décrits plus loin dans cette rubrique expliquent comment appliquer les changements à toutes les instances en appelant les commandes `pkg-repo` à partir de scripts et de fichiers de configuration.
**Avertissement**
Nous vous déconseillons cet outil pour la plupart des utilisateurs. Toute modification manuelle appliquée à une version de plateforme déverrouillée est considérée hors bande. Cette option n'est viable que pour les utilisateurs dans des circonstances urgentes qui peuvent accepter les risques suivants :
Il n'est pas possible de garantir la cohérence des versions des packages dans l'ensemble des instances de vos environnements.
Le bon fonctionnement des environnements modifiés à l'aide de l'outil `pkg-repo` n'est pas garanti. Ceux-ci n'ont pas été testés et vérifiés sur les plateformes prises en charge par Elastic Beanstalk.
Nous recommandons vivement d'appliquer les meilleures pratiques, notamment des plans de test et de désinstallation. Pour faciliter les meilleures pratiques, vous pouvez utiliser la console Elastic Beanstalk et l'EB CLI pour cloner un environnement et échanger un environnement. URLs Pour en savoir plus sur l'utilisation de ces opérations, veuillez consulter la section [Déploiements bleu/vert](using-features.CNAMESwap.md) du chapitre *Gestion des environnements* de ce guide.
Si vous prévoyez de modifier manuellement les fichiers de configuration du référentiel yum, exécutez d'abord l'outil `pkg-repo`. L'outil `pkg-repo` peut ne pas fonctionner comme prévu dans un environnement Amazon Linux 2 avec des fichiers de configuration du référentiel yum modifiés manuellement. Cela est dû au fait que l'outil peut ne pas reconnaître les modifications de configuration.
Pour plus d'informations sur le référentiel de packages Amazon Linux, consultez la rubrique relative au [référentiel de packages](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-ami-basics.html#package-repository) dans le *guide de EC2 l'utilisateur Amazon*.
### Commandes pkg-repo
Utilisez la syntaxe suivante pour exécuter les commandes de l'outil `pkg-repo`.
```
$ /opt/elasticbeanstalk/bin/pkg-repo command [options]
```
Les commandes `pkg-repo` sont les suivantes :
+ **lock** – verrouille les référentiels de paquets `yum` vers une version spécifique
+ **unlock** – déverrouille les référentiels de paquets `yum` à partir d'une version spécifique
+ **status** – répertorie tous les référentiels de packages `yum` et leur état actuel de verrouillage
+ **help** – affiche une aide générale ou une aide pour une commande en particulier
Les options s'appliquent aux commandes comme suit :
+ `lock`, `unlock` et `status ` – options : `-h`, `--help` ou aucune (par défaut).
+ `help` – options : `lock`, `unlock`, `status` ou aucune (par défaut).
L'exemple suivant exécute uniquement la commande **unlock**.
```
$ sudo /opt/elasticbeanstalk/bin/pkg-repo unlock
Amazon Linux 2 core package repo successfully unlocked
Amazon Linux 2 extras package repo successfully unlocked
```
L'exemple suivant exécute uniquement la commande **lock**.
```
$ sudo /opt/elasticbeanstalk/bin/pkg-repo lock
Amazon Linux 2 core package repo successfully locked
Amazon Linux 2 extras package repo successfully locked
```
L'exemple suivant exécute uniquement la commande **status**.
```
$ sudo /opt/elasticbeanstalk/bin/pkg-repo status
Amazon Linux 2 core package repo is currently UNLOCKED
Amazon Linux 2 extras package repo is currently UNLOCKED
```
L'exemple suivant exécute uniquement la commande **help** pour la commande **lock**.
```
$ sudo /opt/elasticbeanstalk/bin/pkg-repo help lock
```
L'exemple suivant exécute uniquement la commande **help** pour l'outil `pkg-repo`.
```
$ sudo /opt/elasticbeanstalk/bin/pkg-repo help
```
Vous pouvez tester `pkg-repo` en utilisant SSH pour vous connecter à une instance dans votre environnement Elastic Beanstalk. Une option SSH est la commande [**eb ssh**](eb3-ssh.md) de l'interface de ligne de commande (CLI) EB.
**Note**
L'outil `pkg-repo` nécessite des privilèges d'utilisateur racine pour s'exécuter. Si vous obtenez une erreur d'autorisation d'accès, exécutez à nouveau la commande sous `sudo`.
Vous n'avez pas besoin d'ajouter `sudo` lorsque vous utilisez l'outil dans les scripts ou les fichiers de configuration que vous déployez dans votre environnement. Elastic Beanstalk exécute tous vos scripts en tant qu'utilisateur racine.
### Exemples pkg-repo
La section précédente fournit des exemples de ligne de commande pour les tests sur une EC2 instance individuelle d'un environnement Elastic Beanstalk. Cette approche peut être utile pour les tests. Cependant, elle ne met à jour qu'une seule instance à la fois, ce qui n'est pas pratique pour appliquer des changements à toutes les instances d'un environnement.
Une approche plus pragmatique consiste à utiliser des scripts de [hook de plateforme](platforms-linux-extend.hooks.md) scripts ou un fichier de configuration [`.ebextensions`](ebextensions.md) pour appliquer les modifications à toutes les instances de manière cohérente.
L'exemple suivant appelle `pkg-repo` à partir d'un fichier de configuration dans le dossier [`.ebextensions`](ebextensions.md). Elastic Beanstalk exécute les commandes du fichier `update_package.config` lorsque vous déployez votre groupe source d'application.
```
.ebextensions
└── update_package.config
```
Afin de recevoir la dernière version du package *docker*, cette configuration spécifie le package *docker* dans la commande **yum update**.
```
### update_package.config ###
commands:
update_package:
command: |
/opt/elasticbeanstalk/bin/pkg-repo unlock
yum update docker -y
/opt/elasticbeanstalk/bin/pkg-repo lock
yum clean all -y
rm -rf /var/cache/yum
```
Cette configuration ne spécifie aucun package dans la commande **yum update**. Toutes les mises à jour disponibles sont appliquées en conséquence.
```
### update_package.config ###
commands:
update_package:
command: |
/opt/elasticbeanstalk/bin/pkg-repo unlock
yum update -y
/opt/elasticbeanstalk/bin/pkg-repo lock
yum clean all -y
rm -rf /var/cache/yum
```
L'exemple suivant appelle `pkg-repo` à partir d'un script bash en tant que [hook de plateforme](platforms-linux-extend.hooks.md). Elastic Beanstalk exécute le fichier de script `update_package.sh` situé dans le sous-répertoire `prebuild`.
```
.platform
└── hooks
└── prebuild
└── update_package.sh
```
Afin de recevoir la dernière version du package *docker*, ce script spécifie le package *docker* dans la commande **yum update**. Si le nom du package est omis, toutes les mises à jour disponibles sont appliquées. L'exemple précédent du fichier de configuration le démontre.
```
### update_package.sh ###
#!/bin/bash
/opt/elasticbeanstalk/bin/pkg-repo unlock
yum update docker -y
/opt/elasticbeanstalk/bin/pkg-repo lock
yum clean all -y
rm -rf /var/cache/yum
```
## download-source-bundle (AMI Amazon Linux uniquement)
Sur les branches de plateforme de l'AMI Amazon Linux (précédemment Amazon Linux 2), Elastic Beanstalk fournit un outil supplémentaire, qui est `download-source-bundle`. Utilisez cet outil pour télécharger le code source de votre application lors du déploiement de votre plateforme. Cet outil est disponible dans `/opt/elasticbeanstalk/bin/download-source-bundle`.
L'exemple de script `00-unzip.sh` se trouve dans le dossier `appdeploy/pre` des instances d'environnement. Il montre la façon d'utiliser `download-source-bundle` pour télécharger le code source de l'application dans le dossier `/opt/elasticbeanstalk/deploy/appsource` pendant le déploiement.
# Extension des plateformes Linux Elastic Beanstalk
Cette rubrique explique comment étendre vos plateformes Linux avec vos propres commandes, scripts, logiciels et configurations. Vous devrez peut-être étendre votre plateforme pour modifier le serveur proxy par défaut et sa configuration. Vous pouvez également avoir besoin de personnaliser la façon dont la plateforme crée ou démarre votre application.
**Topics**
+ [Buildfile et Procfile](platforms-linux-extend.build-proc.md)
+ [Hooks de plateforme](platforms-linux-extend.hooks.md)
+ [Fichiers de configuration](platforms-linux-extend.config-files.md)
+ [Configuration du proxy inverse](platforms-linux-extend.proxy.md)
+ [Exemple d'application avec extensions](platforms-linux-extend.example.md)
# Buildfile et Procfile
Certaines plateformes vous permettent de personnaliser la façon dont vous créez ou préparez votre application, mais aussi de spécifier les processus qui exécutent votre application. Chaque sujet de plate-forme individuel mentionne spécifiquement *Buildfile and/or *Procfile** si la plate-forme les prend en charge. Recherchez votre plateforme spécifique sous [Plateformes Elastic Beanstalk](concepts-all-platforms.md).
Pour toutes les plateformes de prise en charge, la syntaxe et la sémantique sont identiques et sont décrites dans cette page. Chaque rubrique de plateforme mentionne l'utilisation spécifique de ces fichiers pour la création et l'exécution d'applications dans leurs langages respectifs.
## BuildFile
Pour spécifier une commande de génération et de configuration personnalisée pour votre application, placez un fichier nommé `Buildfile` dans le répertoire racine de votre source d'application. Le nom de fichier est sensible à la casse. Utilisez la syntaxe suivante pour votre `Buildfile`.
```
:
```
La commande dans votre fichier `Buildfile` doit correspondre à l'expression régulière suivante : `^[A-Za-z0-9_-]+:\s*[^\s].*$`.
Elastic Beanstalk ne surveille pas l'application exécutée avec un fichier `Buildfile`. Utilisez un `Buildfile` pour les commandes qui s'exécutent pendant de courtes durées et s'arrêtent après avoir terminé leurs tâches. Pour les processus d'applications de longue durée qui ne doivent pas se fermer, utilisez un [Procfile](#platforms-linux-extend.proc).
Tous les chemins d'accès dans le `Buildfile` sont par rapport à la racine du groupe source. Dans l'exemple suivant de fichier `Buildfile`, `build.sh` est un script shell qui se trouve à la racine du bundle de fichiers source.
**Example BuildFile**
```
make: ./build.sh
```
Si vous souhaitez fournir des étapes de construction personnalisées, nous vous recommandons d'utiliser des hooks de plateforme `predeploy` pour tout sauf les commandes les plus simples, plutôt qu'un `Buildfile`. Les hooks de plateforme permettent des scripts plus riches et une meilleure gestion des erreurs. Les hooks de plateforme sont décrits dans la section suivante.
## Procfile
Pour spécifier des commandes personnalisées pour démarrer et exécuter votre application, placez un fichier nommé `Procfile` dans le répertoire racine de votre source d'application. Le nom de fichier est sensible à la casse. Utilisez la syntaxe suivante pour votre `Procfile`. Vous pouvez spécifier une ou plusieurs commandes.
```
:
:
...
```
Chaque ligne de votre fichier `Procfile` doit correspondre à l'expression régulière suivante : `^[A-Za-z0-9_-]+:\s*[^\s].*$`.
Utilisez un fichier `Procfile` pour les processus d'application de longue durée qui ne doivent pas se fermer. Elastic Beanstalk s'attend à ce que les processus s'exécutant à partir du fichier `Procfile` le fassent en continu. Elastic Beanstalk surveille ces processus et redémarre tout processus qui s'arrête. Pour les processus de courte durée, utilisez un [Buildfile](#platforms-linux-extend.build).
Tous les chemins d'accès dans le `Procfile` sont par rapport à la racine du groupe source. L'exemple `Procfile` suivant définit trois processus. Le premier, appelé `web` dans l'exemple, est l'*application Web principale*.
**Example Procfile**
```
web: bin/myserver
cache: bin/mycache
foo: bin/fooapp
```
Elastic Beanstalk configure le serveur proxy de sorte à transférer les demandes vers votre application web principale sur le port 5000. Vous pouvez configurer ce numéro de port. Une utilisation courante pour un `Procfile` est de transmettre ce numéro de port à votre application en tant qu'argument de commande. Pour plus de détails sur la configuration du proxy, consultez[Configuration du proxy inverse](platforms-linux-extend.proxy.md).
Elastic Beanstalk capture les flux d'erreurs et de sortie standard à partir des processus `Procfile` dans les fichiers journaux. Elastic Beanstalk donne le nom du processus aux fichiers journaux et les stocke dans `/var/log`. Par exemple, le processus `web` dans l'exemple précédent génère des journaux nommés `web-1.log` et `web-1.error.log` pour `stdout` et `stderr`, respectivement.
# Hooks de plateforme
Les hooks de plateforme sont spécifiquement conçus pour étendre la plateforme de votre environnement. Il s'agit de scripts personnalisés et autres fichiers exécutables que vous déployez dans le cadre du code source de votre application et qui sont exécutés par Elastic Beanstalk au cours de différentes étapes de provisionnement d'instance.
**Note**
Les hooks de plateforme ne sont pas pris en charge sur les versions de plateforme de l'AMI Amazon Linux (précédemment Amazon Linux 2).
## Hooks de plateforme de déploiement d'applications
Un *déploiement d'application* se produit lorsque vous fournissez un nouveau bundle source pour le déploiement ou lorsque vous apportez une modification de configuration qui nécessite la résiliation et la récréation de toutes les instances d'environnement.
Pour fournir des hooks de plateforme qui s'exécutent pendant un déploiement d'application, placez les fichiers sous le répertoire `.platform/hooks` de votre bundle source, dans l'un des sous-répertoires suivants.
+ `prebuild` – Les fichiers s'exécutent après que le moteur de plateforme Elastic Beanstalk a téléchargé et extrait le bundle de fichiers source de l'application, et avant qu'il installe et configure l'application et le serveur web.
Les fichiers `prebuild` s'exécutent après l'exécution des commandes trouvées dans la section [commands](customize-containers-ec2.md#linux-commands) de tout fichier de configuration et avant l'exécution des commandes `Buildfile`.
+ `predeploy` – Les fichiers s'exécutent après que le moteur de plateforme Elastic Beanstalk a installé et configuré l'application et le serveur web, et avant qu'il les déploie dans leur emplacement d'exécution final.
Les fichiers `predeploy` s'exécutent après l'exécution des commandes trouvées dans la section [container\$1commands](customize-containers-ec2.md#linux-container-commands) de tout fichier de configuration et avant l'exécution des commandes `Procfile`.
+ `postdeploy` – Les fichiers s'exécutent après que le moteur de plateforme Elastic Beanstalk a déployé l'application et le serveur proxy.
Il s'agit de la dernière étape du workflow de déploiement.
## Hooks de plateforme de déploiement de configuration
Un *déploiement de configuration* se produit lorsque vous apportez des modifications de configuration qui mettent uniquement à jour les instances d'environnement sans les recréer. Les mises à jour des options suivantes provoquent une mise à jour de la configuration.
+ [Propriétés de l'environnement et paramètres spécifiques à la plateforme](environments-cfg-softwaresettings.md)
+ [Fichiers statiques](environment-cfg-staticfiles.md)
+ [AWS X-Ray démon](environment-configuration-debugging.md)
+ [Stockage des journaux et streaming](environments-cfg-logging.md)
+ Port de l'application (pour plus de détails, voir[Configuration du proxy inverse](platforms-linux-extend.proxy.md))
Pour fournir des hooks qui s'exécutent lors d'un déploiement de configuration, placez-les sous le répertoire `.platform/confighooks` de votre bundle source. Les trois mêmes sous-répertoires que pour les hooks de déploiement d'applications s'appliquent.
## En savoir plus sur les hooks de plateforme
Les fichiers hooks peuvent être des fichiers binaires ou des fichiers script commençant par une ligne `#!` et contenant leur chemin d'interpréteur, par exemple `#!/bin/bash`. Tous les fichiers doivent disposer d'une autorisation d'exécution. Utilisez la commande `chmod +x` pour définir l'autorisation d'exécution sur vos fichiers hook. Pour toutes les versions de plateforme basées sur Amazon Linux 2023 et Amazon Linux 2 publiées à partir du 29 avril 2022, Elastic Beanstalk accorde automatiquement des autorisations d'exécution à tous les scripts de hook de plateforme. Dans ce cas, vous n'avez pas besoin d'accorder manuellement les autorisations d'exécution. Pour obtenir la liste de ces versions de plateforme, consultez les notes de mise à jour de Linux du [29 avril 2022 ](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-04-29-linux.html#release-2022-04-29-linux.platforms) dans le *AWS Elastic Beanstalk Release Notes Guide* (Guide de notes de mise à jour ).
Elastic Beanstalk exécute les fichiers dans chacun de ces répertoires et dans l'ordre lexicographique des noms de fichier. Tous les fichiers sont exécutés en tant qu'utilisateur `root`. Le répertoire de travail en cours (cwd) pour les hooks de plateforme est le répertoire racine de l'application. Pour les fichiers `prebuild` et `predeploy`, il s'agit du répertoire intermédiaire de l'application ; pour les fichiers `postdeploy`, il s'agit du répertoire en cours de l'application. Si un des fichiers échoue (fin d'exécution avec un code de sortie différent de zéro), le déploiement échoue.
Un script de texte accroche une plate-forme peut échouer s'il contient des caractères de saut de ligne Windows *Carriage Retur/Line Feed* (CRLF). Si un fichier a été enregistré sur un hôte Windows, puis transféré vers un serveur Linux, il peut contenir des sauts de ligne Windows CRLF. Pour les plateformes publiées le [29 décembre 2022](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-12-29-linux.html) ou après cette date, Elastic Beanstalk convertit automatiquement les caractères Windows CRLF en caractères de saut de *ligne Linux Line Feed* (LF) dans les fichiers texte des hooks de plateforme. Si votre application s'exécute sur des plateformes Amazon Linux 2 publiées avant cette date, vous devez convertir les caractères Windows CRLF en caractères Linux LF. Pour cela, vous pouvez créer et enregistrer le fichier script sur un hôte Linux. Des outils permettant de convertir ces caractères sont également disponibles sur Internet.
Les fichiers hook ont accès à toutes les propriétés d'environnement que vous avez définies dans les options d'application, ainsi qu'aux variables d'environnement système `HOME`, `PATH` et `PORT`.
Pour obtenir des valeurs de variables d'environnement et d'autres options de configuration dans vos scripts de hook de plateforme, vous pouvez utiliser l'utilitaire `get-config` fourni par Elastic Beanstalk sur les instances d'environnement. Pour en savoir plus, consultez [Outils de script de plateforme pour vos environnements Elastic Beanstalk](custom-platforms-scripts.md).
# Fichiers de configuration
Vous pouvez ajouter des [fichiers de configuration](ebextensions.md) au répertoire `.ebextensions` du code source de votre application afin de configurer différents aspects de votre environnement Elastic Beanstalk. Entre autres choses, les fichiers de configuration vous permettent de personnaliser le logiciel et d'autres fichiers sur les instances de votre environnement, mais aussi d'exécuter des commandes d'initialisation sur les instances. Pour en savoir plus, consultez [Personnalisation du logiciel sur des serveurs Linux](customize-containers-ec2.md).
Vous pouvez également définir des [options de configuration](command-options.md) à l'aide de fichiers de configuration. De nombreuses options permettent de contrôler le comportement de la plateforme, et certaines d'entre elles sont [spécifiques à la plateforme](command-options-specific.md).
Pour les plateformes basées sur Amazon Linux 2 et Amazon Linux 2023, nous vous recommandons d'utiliser les *Buildfile*, *Procfile* et les *hooks de plateforme* pour configurer et exécuter du code personnalisé sur vos instances d'environnement pendant le provisionnement d'instance. Ces mécanismes sont décrits dans les sections précédentes de cette page. 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 difficile d'un point de vue syntaxique. Vous devez toujours utiliser des fichiers de `.ebextensions` configuration pour tout script nécessitant une référence à une AWS CloudFormation ressource.
# Configuration du proxy inverse
Toutes les versions de plateforme Amazon Linux 2 et Amazon Linux 2023 utilisent nginx comme serveur proxy inverse par défaut. Les plateformes Tomcat, Node.js, PHP et Python prennent également en charge Apache HTTPD comme alternative. Pour sélectionner Apache sur ces plateformes, définissez l'option `ProxyServer` dans l'espace de noms `aws:elasticbeanstalk:environment:proxy` sur `apache`. Toutes les plateformes permettent la configuration du serveur proxy de manière uniforme, comme décrit dans cette section.
**Note**
Sur les versions de la plateforme d'AMI Amazon Linux (précédemment Amazon Linux 2), vous devrez peut-être configurer les serveurs proxy différemment. Vous trouverez ces détails hérités dans les [rubriques respectives de la plateforme](concepts-all-platforms.md) dans ce guide.
Elastic Beanstalk configure le serveur proxy sur les instances de votre environnement pour transférer le trafic web vers l'application web principale sur l'URL racine de l'environnement ; par exemple, `http://my-env.elasticbeanstalk.com`.
Par défaut, Elastic Beanstalk configure le proxy pour transférer les demandes entrantes sur le port 80 vers votre application web principale sur le port 5000. Vous pouvez configurer ce numéro de port en définissant la propriété d'environnement `PORT` à l'aide de l'espace de noms [aws:elasticbeanstalk:application:environment](command-options-general.md#command-options-general-elasticbeanstalkapplicationenvironment) dans un fichier de configuration, comme illustré dans l'exemple suivant.
```
option_settings:
- namespace: aws:elasticbeanstalk:application:environment
option_name: PORT
value:
```
Pour plus d'informations sur la définition des variables d'environnement pour votre application, consultez [Paramètres d'option](ebextensions-optionsettings.md).
Votre application doit écouter sur le port configuré pour elle dans le proxy. Si vous modifiez le port par défaut à l'aide de la propriété d'environnement `PORT`, votre code peut y accéder en lisant la valeur de la variable d'environnement `PORT`. Par exemple, appelez `os.Getenv("PORT")` dans Go, ou `System.getenv("PORT")` dans Java. Si vous configurez votre proxy pour envoyer du trafic vers plusieurs processus d'application, vous pouvez configurer plusieurs propriétés d'environnement et utiliser leurs valeurs à la fois dans la configuration proxy et dans votre code d'application. Une autre option consiste à transmettre la valeur de port au processus en tant qu'argument de commande dans le `Procfile`. Pour de plus amples informations, veuillez consulter [Buildfile et Procfile](platforms-linux-extend.build-proc.md).
## Configuration de nginx
Elastic Beanstalk utilise nginx comme proxy inverse par défaut pour mapper votre application à votre équilibreur de charge Elastic Load Balancing. Elastic Beanstalk fournit une configuration nginx par défaut que vous pouvez étendre ou remplacer totalement par votre propre configuration.
**Note**
Lorsque vous ajoutez ou modifiez un fichier de configuration `.conf` nginx, veillez à l'encoder en UTF-8.
Pour étendre la configuration nginx par défaut d'Elastic Beanstalk, ajoutez les fichiers de configuration `.conf` à un dossier nommé `.platform/nginx/conf.d/` dans le bundle de fichiers source de votre application. La configuration nginx d'Elastic Beanstalk inclut automatiquement les fichiers `.conf` dans ce dossier.
```
~/workspace/my-app/
|-- .platform
| `-- nginx
| `-- conf.d
| `-- myconf.conf
`-- other source files
```
Les fichiers de configuration `.platform/nginx/conf.d/` sont inclus dans le `http` bloc de configuration nginx. Utilisez cet emplacement pour les configurations qui s'appliquent à l'échelle mondiale.
Pour étendre la configuration par défaut des blocs `server` nginx, `.conf` ajoutez des fichiers de configuration dans un dossier `.platform/nginx/conf.d/elasticbeanstalk/` nommé dans le bundle de sources de votre application. La configuration nginx d'Elastic Beanstalk inclut les fichiers de ce dossier au sein du bloc`.conf`. `server`
```
~/workspace/my-app/
|-- .platform
| `-- nginx
| `-- conf.d
| `-- elasticbeanstalk
| `-- server.conf
`-- other source files
```
Utilisez cet emplacement pour ajouter des configurations spécifiques au serveur, telles que des blocs d'emplacement supplémentaires, des pages d'erreur personnalisées ou des directives au niveau du serveur. L'exemple suivant ajoute un bloc de localisation personnalisé.
**Example . platform/nginx/conf.d/elasticbeanstalk/server.conf**
```
location /test {
return 200 "Hello World!";
add_header Content-Type text/plain;
}
```
Pour remplacer complètement la configuration nginx par défaut d'Elastic Beanstalk, incluez une configuration dans votre bundle de fichiers source à l'emplacement `.platform/nginx/nginx.conf` :
```
~/workspace/my-app/
|-- .platform
| `-- nginx
| `-- nginx.conf
`-- other source files
```
Si vous remplacez la configuration nginx d'Elastic Beanstalk, ajoutez la ligne suivante à votre fichier `nginx.conf` afin d'extraire les configurations d'Elastic Beanstalk pour la [Rapports et surveillance de l'état de santé améliorés dans Elastic Beanstalk](health-enhanced.md), les mappages d'application automatiques et les fichiers statiques.
```
include conf.d/elasticbeanstalk/*.conf;
```
## Configuration d'Apache HTTPD
Les plateformes Tomcat, Node.js, PHP et Python vous permettent de choisir le serveur proxy HTTPD Apache comme alternative à nginx. Ce n'est pas la valeur par défaut. L'exemple suivant montre comment configurer Elastic Beanstalk pour utiliser Apache HTTPD.
**Example .ebextensions/httpd-proxy.config**
```
option_settings:
aws:elasticbeanstalk:environment:proxy:
ProxyServer: apache
```
Vous pouvez étendre la configuration Apache Elastic Beanstalk par défaut avec vos fichiers de configuration supplémentaires. Sinon, vous pouvez remplacer complètement la configuration Apache Elastic Beanstalk par défaut.
Pour étendre la configuration Apache Elastic Beanstalk par défaut, ajoutez les fichiers de configuration `.conf` à un dossier nommé `.platform/httpd/conf.d` dans le bundle de fichiers source de votre application. La configuration Apache Elastic Beanstalk par défaut inclut automatiquement les fichiers `.conf` dans ce dossier.
```
~/workspace/my-app/
|-- .ebextensions
| -- httpd-proxy.config
|-- .platform
| -- httpd
| -- conf.d
| -- port5000.conf
| -- ssl.conf
-- index.jsp
```
Par exemple, la configuration Apache 2.4 suivante ajoute un écouteur sur le port 5000 :
**Example . platform/httpd/conf.d/port5000.conf**
```
listen 5000
Require all granted
ProxyPass / http://localhost:8080/ retry=0
ProxyPassReverse / http://localhost:8080/
ProxyPreserveHost on
ErrorLog /var/log/httpd/elasticbeanstalk-error_log
```
Pour remplacer complètement la configuration Apache Elastic Beanstalk par défaut, incluez une configuration dans votre bundle de fichiers source sur `.platform/httpd/conf/httpd.conf`.
```
~/workspace/my-app/
|-- .ebextensions
| -- httpd-proxy.config
|-- .platform
| `-- httpd
| `-- conf
| `-- httpd.conf
`-- index.jsp
```
Si vous remplacez la configuration Apache Elastic Beanstalk, ajoutez les lignes suivantes à votre fichier `httpd.conf` afin d'extraire les configurations Elastic Beanstalk pour la [Rapports et surveillance de l'état de santé améliorés dans Elastic Beanstalk](health-enhanced.md), les mappages d'application automatiques et les fichiers statiques.
```
IncludeOptional conf.d/elasticbeanstalk/*.conf
```
# Exemple d'application avec extensions
L'exemple suivant présente un bundle de fichiers source d'application avec plusieurs fonctionnalités d'extensibilité prises en charge par les plateformes Elastic Beanstalk Amazon Linux 2 et Amazon Linux 2023 : un fichier `Procfile`, des fichiers de configuration `.ebextensions`, des hooks personnalisés et des fichiers de configuration de proxy.
```
~/my-app/
|-- web.jar
|-- Procfile
|-- readme.md
|-- .ebextensions/
| |-- options.config # Option settings
| `-- cloudwatch.config # Other .ebextensions sections, for example files and container commands
`-- .platform/
|-- nginx/ # Proxy configuration
| |-- nginx.conf
| `-- conf.d/
| |-- custom.conf
| `-- elasticbeanstalk/
| `-- server.conf
|-- hooks/ # Application deployment hooks
| |-- prebuild/
| | |-- 01_set_secrets.sh
| | `-- 12_update_permissions.sh
| |-- predeploy/
| | `-- 01_some_service_stop.sh
| `-- postdeploy/
| |-- 01_set_tmp_file_permissions.sh
| |-- 50_run_something_after_app_deployment.sh
| `-- 99_some_service_start.sh
`-- confighooks/ # Configuration deployment hooks
|-- prebuild/
| `-- 01_set_secrets.sh
|-- predeploy/
| `-- 01_some_service_stop.sh
`-- postdeploy/
|-- 01_run_something_after_config_deployment.sh
`-- 99_some_service_start.sh
```
**Note**
Certaines de ces extensions ne sont pas prises en charge sur les versions de plateforme de l'AMI Amazon Linux (précédemment Amazon Linux 2).