Extension des plateformes Linux Elastic Beanstalk - AWS Elastic Beanstalk
Exemple d'application avec extensionsFlux de travail (workflow) de déploiement d'instanceFlux de travail de déploiement d'instances pour une ECS exécution sur Amazon Linux 2 et versions ultérieures

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

Si nécessaire, vous pouvez étendre les plateformes de différentes manières pour configurer les options, installer des logiciels, ajouter des fichiers et des commandes de démarrage, fournir des instructions de compilation et d'exécution, et ajouter des scripts d'initialisation qui s'exécutent lors des différentes étapes de provisionnement des instances Amazon Elastic Compute Cloud EC2 (Amazon) 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 AMI la plateforme Amazon Linux (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 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 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 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 Platform Hooks 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é sur un serveur Linux, il peut contenir des sauts de CRLF ligne Windows. Pour les plateformes publiées le 29 décembre 2022 ou après cette date, Elastic Beanstalk CRLF convertit automatiquement les caractères Windows 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 une plate-forme Amazon Linux 2 publiée avant cette date, vous devez convertir les CRLF caractères Windows 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 plus de détails, consultez Outils de script de plateforme pour vos environnements Elastic Beanstalk.

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 en savoir plus, 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.

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, l'écriture de scripts de commande dans un YAML fichier peut s'avérer difficile du point de vue de la syntaxe. Vous devez toujours utiliser des fichiers de .ebextensions configuration pour tout script nécessitant une référence à une AWS CloudFormation ressource.

Toutes les versions de plateforme Amazon Linux 2 et Amazon Linux 2023 utilisent nginx comme serveur proxy inverse par défaut. Les plateformes TomcatPHP, Node.js et Python supportent également 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 AMI la plateforme Amazon Linux (antérieures à 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 située à la racine de l'environnement, par URL 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 à le coder sous la forme -8. UTF

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 Elastic Beanstalk a amélioré les rapports et le suivi de l'état de santé, les mappages d'application automatiques et les fichiers statiques.

 include conf.d/elasticbeanstalk/*.conf;

Configuration d'Apache HTTPD

Les plateformes TomcatPHP, Node.js et Python vous permettent de choisir le serveur HTTPD proxy Apache comme alternative à nginx. Ce n'est pas la valeur par défaut. L'exemple suivant configure 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
Note

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 Elastic Beanstalk a amélioré les rapports et le suivi de l'état de santé, les mappages d'application automatiques et les fichiers statiques.

IncludeOptional conf.d/elasticbeanstalk/*.conf
Note

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

Rubriques

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
    |-- 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 AMI la plateforme Amazon Linux (antérieures à Amazon Linux 2).

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

Note

Les informations contenues dans cette section ne s'appliquent pas à l'ECSexécution sur les branches des plateformes Amazon Linux 2 et Amazon Linux 2023. Pour plus d'informations, voir la section suivante Flux de travail de déploiement d'instances pour une ECS exécution sur Amazon Linux 2 et versions ultérieures.

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.

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

Flux de travail de déploiement d'instances pour une ECS exécution 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 entre les branches de la plateforme Docker ECSexécutées sur Amazon Linux 2 et versions ultérieures. 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 schéma suivant montre l'ensemble de ce flux de travail de déploiement pour un environnement basé sur les ECSbranches de la plate-forme Amazon Linux 2 et ECSsur les branches de la plate-forme 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 ECS basée sur la plateforme Docker.

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.

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

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

  4. Exécute tous les fichiers exécutables trouvés dans le répertoire appdeploy/enact sous EBhooksDir.

  5. Exécute tous les fichiers exécutables trouvés dans le répertoire appdeploy/post sous EBhooksDir.

  6. 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 sur la ligne de commande de votre instance d'environnement, comme illustré : 

$ /opt/elasticbeanstalk/bin/get-config platformconfig -k EBhooksDir