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. # 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).