Personnalisation du logiciel sur des serveurs Linux - AWS Elastic Beanstalk

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.

Personnalisation du logiciel sur des serveurs Linux

Vous pouvez souhaiter personnaliser et configurer le logiciel dont dépend votre application. Vous pouvez ajouter des commandes à exécuter pendant le provisionnement de l’instance, définir des utilisateurs et des groupes Linux et télécharger ou créer directement des fichiers sur vos instances d'environnement. Ces fichiers peuvent être des dépendances requises par l'application (par exemple, des packages supplémentaires provenant du référentiel yum) ou des fichiers de configuration en remplacement d'un fichier de configuration de proxy par exemple, pour remplacer des paramètres spécifiques qui sont définis par défaut par Elastic Beanstalk.

Cette section décrit le type d'informations que vous pouvez inclure dans un fichier de configuration afin de personnaliser le logiciel sur vos instances EC2 exécutant Linux. Pour obtenir des informations générales sur la personnalisation et la configuration de vos environnements Elastic Beanstalk, veuillez consulter Configuration d'environnements Elastic Beanstalk. Pour plus d'informations sur la personnalisation des logiciels sur vos instances EC2 exécutant Windows, consultez Personnalisation du logiciel sur des serveurs Windows.

Remarques
  • Sur les plateformes Amazon Linux 2, au lieu de fournir des fichiers et des commandes dans des fichiers de configuration .ebextensions, nous vous recommandons vivement d'utiliser Buildfile, Profile et les hooks de plateforme dès que possible, pour configurer et exécuter du code personnalisé sur vos instances d'environnement pendant le provisionnement d'instance. Pour plus d'informations sur ces mécanismes, consultez Extension des plateformes Linux Elastic Beanstalk.

  • YAML utilise une mise en retrait cohérente. Respectez le niveau de retrait lorsque vous remplacez du contenu dans un exemple de fichier de configuration et veillez à ce que votre éditeur de texte utilise des espaces, et non des caractères de tabulation, pour la mise en retrait.

Les fichiers de configuration prennent en charge les clés suivantes qui affectent le serveur Linux sur lequel votre application s'exécute.

Les clés sont traitées dans l'ordre dans lequel elles sont répertoriées ici.

Observez les événements de votre environnement pendant le développement et les tests des fichiers de configuration. Elastic Beanstalk ignore un fichier de configuration qui contient des erreurs de validation, comme une clé non valide, et ne traite aucune autre clé dans le même fichier. Lorsque cela se produit, Elastic Beanstalk ajoute un événement d'avertissement dans le journal des événements.

Packages

Vous pouvez utiliser la clé packages pour télécharger et installer des applications et des composants prépackagés.

Syntaxe

packages: name of package manager: package name: version ... name of package manager: package name: version ... ...

Vous pouvez spécifier plusieurs packages sous chaque clé de gestionnaire de package.

Formats de packages pris en charge

Actuellement, Elastic Beanstalk prend en charge les gestionnaires de package suivants : yum, rubygems, python et rpm. Les packages sont traités dans l'ordre suivant : rpm, yum, puis rubygems et python. Il n'y a pas de classement entre rubygems et python. Au sein de chaque gestionnaire de packages, l'ordre des packages d'installation n'est pas garanti. Utilisez un gestionnaire de package pris en charge par votre système d'exploitation.

Note

Elastic Beanstalk prend en charge deux gestionnaires de package sous-jacents pour Python : pip et easy_install. Toutefois, dans la syntaxe du fichier de configuration, vous devez spécifier python comme nom du gestionnaire de package. Lorsque vous utilisez un fichier de configuration pour spécifier un gestionnaire de package Python, Elastic Beanstalk utilise Python 2.7. Si votre application repose sur une autre version de Python, vous pouvez indiquer que les packages doivent être installés dans un fichier requirements.txt. Pour de plus amples informations, veuillez consulter Spécification des dépendances à l'aide d'un fichier d'exigences sur Elastic Beanstalk.

Spécification des versions

Au sein de chaque gestionnaire de package, chaque package est spécifié sous la forme d'un nom de package et d'une liste de versions. La version peut être une chaîne, une liste de versions, ou une chaîne ou une liste vide. Une chaîne ou une liste vide indique que vous souhaitez la dernière version. Pour le gestionnaire rpm, la version est spécifiée sous la forme d'un chemin d'accès à un fichier sur disque ou d'une URL. Les chemins relatifs ne sont pas pris en charge.

Si vous spécifiez une version d'un package, Elastic Beanstalk tente d'installer cette version, même si une version plus récente du package est déjà installée sur l'instance. Si une version plus récente est déjà installée, le déploiement échoue. Certains gestionnaires de package prennent en charge plusieurs versions, mais pas tous. Veuillez vérifier la documentation de votre gestionnaire de package pour plus d'informations. Si vous ne spécifiez aucune version et qu'une version du package est déjà installée, Elastic Beanstalk n'installe pas une nouvelle version, car il part du principe que vous souhaitez conserver et utiliser la version existante.

Exemple d'extrait

L'extrait suivant spécifie une URL de la version pour rpm, demande la dernière version à yum et la version 0.10.2 de chef à rubygems.

packages: yum: libmemcached: [] ruby-devel: [] gcc: [] rpm: epel: http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm rubygems: chef: '0.10.2'

Groups

Vous pouvez utiliser la clé groups pour créer des groupes Linux/UNIX et pour attribuer des ID de groupe. Pour créer un groupe, ajoutez une nouvelle paire clé-valeur qui mappe un nouveau nom de groupe à un ID de groupe facultatif. La clé des groupes peut contenir un ou plusieurs noms de groupe. Le tableau suivant répertorie les clés disponibles.

Syntaxe

groups: name of group: {} name of group: gid: "group id"

Options

gid

Numéro d'identification d'un groupe.

Si un ID de groupe est spécifié et que le nom du groupe existe déjà, la création du groupe échoue. Si un autre groupe est associé à l'ID de groupe spécifié, le système d'exploitation peut refuser la création du groupe.

Exemple d'extrait

L'extrait suivant spécifie un groupe nommé groupOne sans attribuer d'ID de groupe, et un groupe nommé groupTwo ayant spécifié 45 comme valeur d'ID de groupe.

groups: groupOne: {} groupTwo: gid: "45"

Users

Vous pouvez utiliser la clé users pour créer des utilisateurs Linux/UNIX sur l'instance EC2.

Syntaxe

users: name of user: groups: - name of group uid: "id of the user" homeDir: "user's home directory"

Options

uid

ID d'un utilisateur. Le processus de création échoue si le nom d'utilisateur existe avec un autre ID d'utilisateur. Si l'ID d'utilisateur est déjà affecté à un utilisateur existant, le système d'exploitation peut refuser la demande de création.

groups

Liste de noms de groupes. L'utilisateur est ajouté à chaque groupe de la liste.

homeDir

Répertoire de base de l'utilisateur.

Les utilisateurs sont créés en tant qu'utilisateurs du système non interactif avec le shell /sbin/nologin. Ce paramètre est intégré à la conception et ne peut pas être modifié.

Exemple d'extrait

users: myuser: groups: - group1 - group2 uid: "50" homeDir: "/tmp"

Sources

Vous pouvez utiliser la clé sources pour télécharger un fichier d'archives à partir d'une URL publique et le décompresser dans un répertoire cible de l'instance EC2.

Syntaxe

sources: target directory: location of archive file

Formats pris en charge

Les formats pris en charge sont les suivants : tar, tar+gzip, tar+bz2 et zip. Vous pouvez faire référence à des emplacements externes tels qu'Amazon Simple Storage Service (Amazon S3) (par exemple, https://mybucket.s3.amazonaws.com/myobject) tant que l'URL est publiquement accessible.

Exemple d'extrait

L'exemple suivant télécharge un fichier .zip public à partir d'un compartiment Amazon S3 et le décompresse dans /etc/myapp:

sources: /etc/myapp: https://mybucket.s3.amazonaws.com/myobject
Note

Plusieurs extractions ne doivent pas réutiliser le même chemin cible. L'extraction d'une autre source vers le même chemin cible remplacera le contenu au lieu de l'ajouter.

Dépôt de

Vous pouvez utiliser la clé files pour créer des fichiers sur l'instance EC2. Le contenu peut être soit en ligne dans le fichier de configuration, ou bien le contenu peut être extrait d'une URL. Les fichiers sont écrits sur disque par ordre lexicographique.

Vous pouvez utiliser la clé files pour télécharger des fichiers privés depuis Amazon S3 en fournissant un profil d'instance pour l'autorisation.

Si le chemin d'accès au fichier que vous spécifiez existe déjà sur l'instance, le fichier existant est conservé avec l'extension .bak ajoutée à son nom.

Syntaxe

files: "target file location on disk": mode: "six-digit octal value" owner: name of owning user for file group: name of owning group for file source: URL authentication: authentication name: "target file location on disk": mode: "six-digit octal value" owner: name of owning user for file group: name of owning group for file content: | # this is my # file content encoding: encoding format authentication: authentication name:

Options

content

Contenu de la chaîne à ajouter dans le fichier. Spécifiez content ou source, mais pas les deux.

source

URL du fichier à télécharger. Spécifiez content ou source, mais pas les deux.

encoding

Format d'encodage de la chaîne spécifiée via l'option content.

Valeurs valides : plain | base64

group

Groupe Linux auquel appartient le fichier.

owner

Utilisateur Linux auquel appartient le fichier.

mode

Valeur octale à six chiffres qui représente le mode de ce fichier. Non pris en charge pour les systèmes Windows. Utilisez les trois premiers chiffres pour les liens symboliques et les trois derniers chiffres pour définir les autorisations. Pour créer un lien symbolique, spécifiez 120xxx, où xxx définit les autorisations du fichier cible. Pour définir des autorisations pour un fichier, utilisez les trois derniers chiffres, tels que 000644.

authentication

Le nom d'une méthode d'authentification AWS CloudFormation à utiliser. Vous pouvez ajouter des méthodes d'authentification aux métadonnées du groupe Auto Scaling via la clé Resources. Vous trouverez un exemple ci-dessous.

Exemple d'extrait

files: "/home/ec2-user/myfile" : mode: "000755" owner: root group: root source: http://foo.bar/myfile "/home/ec2-user/myfile2" : mode: "000755" owner: root group: root content: | this is my file content

Exemple d'utilisation d'un lien symbolique. Cela crée un lien /tmp/myfile2.txt qui renvoie vers le fichier existant /tmp/myfile1.txt.

files: "/tmp/myfile2.txt" : mode: "120400" content: "/tmp/myfile1.txt"

L'exemple suivant utilise la clé Resources pour ajouter une méthode d'authentification nommée S3Auth et l'utilise pour télécharger un fichier privé à partir d'un compartiment Amazon S3 :

Resources: AWSEBAutoScalingGroup: Metadata: AWS::CloudFormation::Authentication: S3Auth: type: "s3" buckets: ["elasticbeanstalk-us-west-2-123456789012"] roleName: "Fn::GetOptionSetting": Namespace: "aws:autoscaling:launchconfiguration" OptionName: "IamInstanceProfile" DefaultValue: "aws-elasticbeanstalk-ec2-role" files: "/tmp/data.json" : mode: "000755" owner: root group: root authentication: "S3Auth" source: https://elasticbeanstalk-us-west-2-123456789012.s3-us-west-2.amazonaws.com/data.json

Commandes

Vous pouvez utiliser la clé commands pour exécuter des commandes sur l'instance EC2. Les commandes exécutées avant l'application et le serveur web sont définies et le fichier de version de l'application est extrait.

Les commandes spécifiées s'exécutent en tant qu'utilisateur racine et sont traitées dans l'ordre alphabétique par nom. Commandes exécutées dans le répertoire racine (par défaut). Pour exécuter des commandes à partir d'un autre répertoire, utilisez l'option cwd.

Pour résoudre les problèmes associés à vos commandes, vous pouvez trouver leur sortie dans les journaux d'instance.

Syntaxe

commands: command name: command: command to run cwd: working directory env: variable name: variable value test: conditions for command ignoreErrors: true

Options

command

Tableau (collection de séquence de blocs en syntaxe YAML) ou chaîne spécifiant la commande à exécuter. Remarques importantes :

  • Si vous utilisez une chaîne, vous n'avez pas besoin de placer la totalité de la chaîne entre guillemets. Si vous utilisez des guillemets, utilisez des caractères d'échappement pour les occurrences littérales du même type de guillemets.

  • Si vous utilisez un tableau, vous n'avez pas besoin de caractères d'espacement ou d'inclure des paramètres de commande entre guillemets. Chaque élément de tableau est un argument de commande unique. N'utilisez pas un tableau pour spécifier plusieurs commandes.

Les exemples suivants sont tous équivalents :

commands: command1: command: git commit -m "This is a comment." command2: command: "git commit -m \"This is a comment.\"" command3: command: 'git commit -m "This is a comment."' command4: command: - git - commit - -m - This is a comment.

Pour spécifier plusieurs commandes, utilisez un bloc littéral scalaire, comme illustré dans l'exemple suivant.

commands: command block: command: | git commit -m "This is a comment." git push
env

(Facultatif) Définit des variables d'environnement pour la commande. Cette propriété remplace, plutôt que d'ajouter, l'environnement existant.

cwd

(Facultatif) Le répertoire de travail. Si cette option n'est pas spécifiée, les commandes sont exécutées à partir du répertoire racine (/).

test

(Facultatif) Commande qui doit renvoyer la valeur true (code de sortie 0) afin qu'Elastic Beanstalk traite la commande (par exemple, un script shell) contenue dans la clé command.

ignoreErrors

(Facultatif) Valeur booléenne qui détermine si les autres commandes doivent s'exécuter si la commande contenue dans la clé command échoue (renvoie une valeur non nulle). Définissez cette valeur sur true si vous voulez continuer à exécuter des commandes même si la commande échoue. Définissez-la sur false si vous souhaitez arrêter l'exécution des commandes si la commande échoue. La valeur par défaut est false.

Exemple d'extrait

L'exemple d'extrait suivant exécute un script Python.

commands: python_install: command: myscript.py cwd: /home/ec2-user env: myvarname: myvarvalue test: "[ -x /usr/bin/python ]"

Services

Vous pouvez utiliser la clé services pour définir les services qui doivent être démarrés ou arrêtés lors du lancement de l'instance. La clé services vous permet également de spécifier des dépendances sur des sources, des packages et des fichiers de sorte que si un redémarrage est nécessaire en raison d'une installation de fichiers, Elastic Beanstalk prenne en charge le redémarrage du service.

Syntaxe

services: sysvinit: name of service: enabled: "true" ensureRunning: "true" files: - "file name" sources: - "directory" packages: name of package manager: "package name[: version]" commands: - "name of command"

Options

ensureRunning

Définissez cette option sur true afin de garantir que le service s'exécute après qu'Elastic Beanstalk a terminé.

Définissez cette option sur false afin de garantir que le service ne s'exécute pas après qu'Elastic Beanstalk a terminé.

Ignorez cette clé pour n'apporter aucune modification à l'état du service.

enabled

Définissez cette option sur true afin de garantir que le service soit démarré automatiquement lors du démarrage.

Définissez cette option sur false afin de garantir que le service ne soit pas démarré automatiquement lors du démarrage.

Ignorez cette clé pour n'apporter aucune modification à cette propriété.

files

Liste de fichiers. Si Elastic Beanstalk en change un directement via le bloc de fichiers, le service est redémarré.

sources

Liste de répertoires. Si Elastic Beanstalk développe une archive dans l'un de ces répertoires, le service est redémarré.

packages

Une carte du gestionnaire de package sur une liste de noms de package. Si Elastic Beanstalk installe ou met à jour l'un de ces packages, le service est redémarré.

commands

Liste de noms de commandes. Si Elastic Beanstalk exécute la commande spécifiée, le service est redémarré.

Exemple d'extrait

Voici un exemple d'extrait :

services: sysvinit: myservice: enabled: true ensureRunning: true

Commandes de conteneur

Vous pouvez utiliser la clé container_commands pour exécuter des commandes qui affectent le code source de votre application. Les commandes de conteneur s'exécutent après que l'application et le serveur web ont été configurés et que l'archive de version d'application a été extraite, mais avant que la version d'application soit déployée. Les commandes non-conteneur et autres opérations de personnalisation sont effectuées avant le code source d'application en cours d'extraction.

Les commandes spécifiées s'exécutent en tant qu'utilisateur racine et sont traitées dans l'ordre alphabétique par nom. Les commandes de conteneur sont exécutées depuis le répertoire intermédiaire, où votre code source est extrait avant d'être déployé sur le serveur d'applications. Toutes les modifications apportées à votre code source dans le répertoire intermédiaire avec une commande conteneur seront incluses lorsque la source est déployée sur son emplacement final.

Note

La sortie de vos commandes de conteneur est enregistrée dans le journal d’instance cfn-init-cmd.log. Pour en savoir plus sur la récupération et l'affichage des journaux d'instance, consultez la section Affichage des journaux des instances Amazon EC2.

Vous pouvez utiliser leader_only pour exécuter uniquement la commande sur une seule instance, ou configurer un test pour exécuter uniquement la commande lorsqu'une commande test évalue sur true. Les commandes de conteneur principales uniquement sont exécutées uniquement au cours de la création et du déploiement de l'environnement, tandis que d'autres commandes et opérations de personnalisation de serveur sont effectuées chaque fois qu'une instance est mise en service ou mise à jour. Les commandes de conteneur principales uniquement ne sont pas exécutées pour lancer des modifications de configuration, par exemple, une modification d'ID d'AMI ou de type d'instance.

Syntaxe

container_commands: name of container_command: command: "command to run" leader_only: true name of container_command: command: "command to run"

Options

command

Une chaîne ou un tableau de chaînes à exécuter.

env

(Facultatif) Définissez les variables d'environnement avant d'exécuter la commande, en ignorant toute valeur existante.

cwd

(Facultatif) Le répertoire de travail. Par défaut, il s'agit du répertoire intermédiaire de l'application décompressée.

leader_only

(Facultatif) Exécutez uniquement la commande sur une seule instance choisie par Elastic Beanstalk. Les commandes de conteneur principales uniquement sont exécutées avant d'autres commandes de conteneur. Une commande peut être principale uniquement ou disposer d'un test, mais pas les deux (leader_only a la priorité).

test

(Facultatif) Exécutez une commande test qui doit renvoyer la valeur true afin d'exécuter la commande de conteneur. Une commande peut être principale uniquement ou disposer d'un test, mais pas les deux (leader_only a la priorité).

ignoreErrors

(Facultatif) Ne manquez pas les déploiements si la commande de conteneur renvoie une valeur différente de 0 (réussite). Définissez sur true pour activer.

Exemple d'extrait

Voici un exemple d'extrait :

container_commands: collectstatic: command: "django-admin.py collectstatic --noinput" 01syncdb: command: "django-admin.py syncdb --noinput" leader_only: true 02migrate: command: "django-admin.py migrate" leader_only: true 99customize: command: "scripts/customize.sh"