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 d’allocation des instances de votre environnement Amazon Elastic Compute Cloud (Amazon EC2).

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 qui est exécutée avec un 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 Procfile doit correspondre à l'expression régulière suivante : ^[A-Za-z0-9_-]+:\s*[^\s].*$.

Utilisez un Procfile pour les processus d'application à long terme qui ne doivent pas se terminer. Elastic Beanstalk s'attend à ce que les processus s'exécutent à partir du Procfile en continu. Elastic Beanstalk surveille ces processus et redémarre tout processus qui prend fin. 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 pour transférer les demandes à votre application Web principale sur le port 5000, et 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 de sortie et d'erreur standard des processus Procfile dans les fichiers journaux. Elastic Beanstalk nomme les fichiers journaux après le processus 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 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 d’allocation d'instance.

Note

Les hooks de plateforme ne sont pas pris en charge par les versions de plate-forme Amazon Linux AMI (antérieures à 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 des 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 sur 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 chmod +x pour définir l'autorisation d'exécution sur vos fichiers hook.

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 exécutés 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 que Elastic Beanstalk fournit 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 pour 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 plus d’informations, consultez 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 Buildfile. Profile 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 (antérieures à Amazon Linux 2), vous devrez peut-être configurer nginx 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 transmettre les demandes à votre application web principale sur le port 80. 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 vers votre équilibreur de charge Elastic Load Balancing. Elastic Beanstalk fournit une configuration nginx par défaut que vous pouvez étendre ou remplacer totalement avec 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 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 Elastic Beanstalk par défaut, incluez une configuration dans votre bundle de fichiers source dans .platform/nginx/nginx.conf :

~/workspace/my-app/ |-- .platform | `-- nginx | `-- nginx.conf `-- other source files

Si vous substituez la configuration nginx Elastic Beanstalk, ajoutez la ligne suivante à votre fichier nginx.conf pour extraire les configurations Elastic Beanstalk pour 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 nginx.

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 dans un dossier nommé .platform/httpd/conf.d dans le bundle source de votre application. La configuration Apache Elastic Beanstalk 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 source sur .platform/httpd/conf/httpd.conf.

~/workspace/my-app/ |-- .ebextensions | -- httpd-proxy.config |-- .platform | `-- httpd | `-- conf | `-- httpd.conf `-- index.jsp

Si vous substituez la configuration Apache Elastic Beanstalk, ajoutez la ligne suivante à votre fichier httpd.conf pour extraire les configurations Elastic Beanstalk pour 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 lire également les informations dans Migration de votre application Linux Elastic Beanstalk 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 Amazon Linux 2 Elastic Beanstalk : un Procfile, des fichiers de configuration .ebextensions, des hooks personnalisés et des fichiers de configuration 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 la plateforme Amazon Linux AMI (antérieures à Amazon Linux 2).

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

Avec de nombreuses façons d'étendre la plate-forme de votre environnement, il est utile de savoir ce qui se passe quand 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.

Remarques
  • Le diagramme ne représente pas l'ensemble complet des étapes que Elastic Beanstalk prend sur les instances d'environnement pendant le 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 à l'aide d'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 .platform/hooks/prebuild répertoire 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).