Extension des plateformes Linux Elastic Beanstalk - AWS Elastic Beanstalk

Extension des plateformes Linux Elastic Beanstalk

Les plateformes Linux AWS Elastic Beanstalk fournissent de nombreuses fonctionnalités pour prendre en charge le développement et l'exécution de votre application. Si nécessaire, vous pouvez étendre les plateformes de plusieurs façons pour configurer des options, installer des logiciels, ajouter des fichiers et des commandes de démarrage, fournir des instructions de génération et d'exécution et ajouter des scripts d'initialisation s'exécutant au cours des différentes étapes de provisionnement des instances Amazon Elastic Compute Cloud (Amazon EC2) de votre environnement.

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 rubrique de plate-forme mentionne spécifiquement Buildfile et/ou Procfile si la plate-forme les prend en charge. Recherchez votre plateforme spécifique sous Plateformes Elastic Beanstalk.

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.

<process_name>: <command>

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.

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.

Exemple 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.

<process_name1>: <command1> <process_name2>: <command2> ...

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.

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.

Exemple 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 d'informations sur la configuration du proxy, développez la section Configuration du proxy inverse sur cette page.

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.

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 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_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.

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 exécutables 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 avoir l'autorisation d'exécution. Utilisez la commande chmod +x pour définir l'autorisation d'exécution sur vos fichiers exécutables.

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.

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 plus d'informations, consultez Outils de script de plateforme.

Vous pouvez ajouter des fichiers de configuration 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 de plus amples informations, veuillez consulter Personnalisation du logiciel sur des serveurs Linux.

Vous pouvez également définir des options de configuration à 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.

Sur les plateformes Amazon Linux 2, 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 configuration .ebextensions pour tout script nécessitant une référence à une ressource AWS CloudFormation.

Toutes les versions de plateforme Amazon Linux 2 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 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 dans un fichier de configuration, comme illustré dans l'exemple suivant.

option_settings: - namespace: aws:elasticbeanstalk:application:environment option_name: PORT value: <main_port_number>

Pour plus d'informations sur la définition des variables d'environnement pour votre application, consultez Paramètres d'option.

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 plus d'informations à ce sujet, développez la section Buildfile et Procfile sur cette page.

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

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 Surveillance et création de rapports d'intégrité améliorée, 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.

Exemple .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 :

Exemple .platform/httpd/conf.d/port5000.conf

listen 5000 <VirtualHost *:5000> <Proxy *> Require all granted </Proxy> ProxyPass / http://localhost:8080/ retry=0 ProxyPassReverse / http://localhost:8080/ ProxyPreserveHost on ErrorLog /var/log/httpd/elasticbeanstalk-error_log </VirtualHost>

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 Surveillance et création de rapports d'intégrité améliorée, les mappages d'application automatiques et les fichiers statiques.

IncludeOptional conf.d/elasticbeanstalk/*.conf

Si vous migrez votre application Elastic Beanstalk vers une plateforme Amazon Linux 2, assurez-vous de consulter également les informations de la section Migration de votre application Elastic Beanstalk Linux vers Amazon Linux 2.

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

Flux de travail (workflow) de déploiement d'instance

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. Il décrit les différentes phases d'un déploiement et les étapes suivies par Elastic Beanstalk au cours de chaque phase.

Notes
  • 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.


        Ordre d'exécution des extensions sur une instance dans un environnement utilisant une version de plateforme Amazon Linux 2

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: de tout fichier de configuration.

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

  2. Configuration

    Elastic Beanstalk configure votre application et le serveur proxy.

    1. Exécute les commandes trouvées dans le bundle de fichiers source Buildfile.

    2. 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.

    3. Exécute les commandes de la section container_commands: de tout fichier de configuration.

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

  3. 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.

    2. Exécute ou réexécute le serveur proxy avec vos fichiers de configuration proxy personnalisés, le cas échéant.

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