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

Cette section décrit le type d'informations que vous pouvez inclure dans un fichier de configuration pour personnaliser le logiciel sur vos EC2 instances 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 du logiciel sur vos EC2 instances exécutant Windows, consultezPersonnalisation du logiciel sur des serveurs Windows.

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.

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.

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 forme de chemin d'accès à un fichier sur le disque ou un fichierURL. 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 version URL 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 groups clé pour créer des UNIX groupes Linux/ et pour assigner un groupe. IDs 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

Exemple d'extrait

L'extrait suivant indique un groupe nommé groupOne sans attribuer d'ID de groupe et un groupe nommé groupTwo qui a spécifié une valeur d'ID de groupe de 45.

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

Users

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

Syntaxe

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

Options

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 sources clé pour télécharger un fichier d'archive à partir d'un fichier public URL et le décompresser dans un répertoire cible de l'EC2instance.

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 sites externes tels qu'Amazon Simple Storage Service (Amazon S3) (par exemple)https://amzn-s3-demo-bucket.s3.amazonaws.com/myobject, à condition qu'ils soient accessibles URL au public.

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://amzn-s3-demo-bucket.s3.amazonaws.com/myobject

Dépôt de

Vous pouvez utiliser la files clé pour créer des fichiers sur l'EC2instance. Le contenu peut être soit intégré dans le fichier de configuration, soit extrait d'un URL fichier. 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

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: ["amzn-s3-demo-bucket2"]
          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 commands touche pour exécuter des commandes sur l'EC2instance. 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

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

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.

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 réservées au leader ne sont pas exécutées en raison de modifications de configuration de lancement, telles qu'une modification de l'AMIidentifiant ou du 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

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"