Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Anpassen von Software auf Linux-Servern

In diesem Abschnitt wird beschrieben, welche Art von Informationen Sie in eine Konfigurationsdatei aufnehmen können, um die Software auf Ihren EC2 Linux-Instances anzupassen. Allgemeine Informationen zum Anpassen und Konfigurieren der Elastic Beanstalk-Umgebungen finden Sie unter Konfigurieren von Elastic-Beanstalk-Umgebungen. Informationen zum Anpassen der Software auf Ihren EC2 Instanzen, auf denen Windows ausgeführt wird, finden Sie unterAnpassen von Software auf Windows-Servern.

Möglicherweise muss die Software, von der Ihre Anwendung abhängig ist, angepasst und konfiguriert werden. Sie können Befehle hinzufügen, die während der Instance-Bereitstellung ausgeführt werden sollen, Linux-Benutzer und -Gruppen definieren und Dateien auf Ihre Umgebungs-Instances herunterladen oder dort direkt erstellen. Bei diesen Dateien kann es sich entweder um von der Anwendung benötigte Abhängigkeiten (z. B. zusätzliche Pakete aus dem yum-Repository) oder um Konfigurationsdateien handeln (wie z. B. ein Ersatz für eine Proxykonfigurationsdatei zum Überschreiben bestimmter Standardeinstellungen von Elastic Beanstalk).

Konfigurationsdateien unterstützen die folgenden Schlüssel, die sich auf die Linux-Server auswirken, auf denen die Anwendung ausgeführt wird.

Schlüssel werden in der hier aufgeführten Reihenfolge verarbeitet.

Beobachten Sie die Ereignisse in der Umgebung, während Sie Konfigurationsdateien entwickeln und testen. Elastic Beanstalk ignoriert eine Konfigurationsdatei, die Validierungsfehler enthält, z. B. einen ungültigen Schlüssel, und verarbeitet keinen der in der betreffenden Datei enthaltenen Schlüssel. Wenn dies geschieht, fügt Elastic Beanstalk eine Warnung in das Ereignisprotokoll ein.

Pakete

Mit dem Schlüssel packages können Sie vorgefertigte Anwendungen und Komponenten herunterladen und installieren.

Syntax

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

Sie können unter jedem Paketmanager-Schlüssel mehrere Pakete angeben.

Unterstützte Paketformate

Elastic Beanstalk unterstützt derzeit die folgenden Paketmanager: yum, rubygems, python und rpm. Pakete werden in der folgenden Reihenfolge verarbeitet: rpm, yum und dann rubygems und python. Es gibt keine Reihenfolge zwischen rubygems und python. Innerhalb jedes Paketmanagers ist die Reihenfolge der Paketinstallation nicht garantiert. Verwenden Sie einen Paketmanager, der vom Betriebssystem unterstützt wird.

Angeben von Versionen

Innerhalb jedes Paketmanagers ist jedes Paket als ein Paketname und eine Liste der Versionen angegeben. Die Version kann eine Zeichenfolge, eine Liste von Versionen oder eine leere Zeichenfolge oder Liste sein. Eine leere Zeichenfolge oder Liste gibt an, dass Sie die neueste Version verwenden möchten. Für den RPM-Manager wird die Version als Pfad zu einer Datei auf der Festplatte oder als URL angegeben. Relative Pfade werden nicht unterstützt.

Wenn Sie eine Version eines Pakets angeben, versucht Elastic Beanstalk, diese Version zu installieren, auch wenn auf der Instance bereits eine neuere Version des Pakets installiert ist. Wenn eine neuere Version bereits installiert ist, schlägt die Bereitstellung fehl. Einige Paketmanager unterstützen mehrere Versionen, andere wiederum nicht. In der Dokumentation zu Ihrem Paketmanager finden Sie weitere Informationen. Wenn Sie keine Version angeben und bereits eine Version des Pakets installiert ist, installiert Elastic Beanstalk keine neue Version. Es wird angenommen, dass Sie die bestehende Version behalten und verwenden möchten.

Beispielausschnitt

Der folgende Ausschnitt spezifiziert eine Version URL für rpm, fordert die neueste Version von Yum und Version 0.10.2 von Chef von Rubygems an.

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'

Gruppen

Sie können den groups Schlüssel verwenden, um UNIX Linux/-Gruppen zu erstellen und Gruppen zuzuweisen. IDs Um eine Gruppe zu erstellen, fügen Sie ein neues Schlüssel-Wert-Paar hinzu, das einer optionalen Gruppen-ID einen neuen Gruppennamen zuordnet. Der Gruppenschlüssel kann einen oder mehrere Gruppennamen enthalten. In der folgenden Tabelle werden die verfügbaren Schlüssel aufgeführt.

Syntax

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

Optionen

Beispielausschnitt

Der folgende Ausschnitt spezifiziert eine Gruppe mit dem Namen groupOne ohne Zuweisung einer Gruppen-ID und eine Gruppe mit dem Namen groupTwo , die einen Gruppen-ID-Wert von 45 angegeben hat.

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

Benutzer

Sie können den users Schlüssel verwenden, um UNIX Linux/-Benutzer auf der Instanz zu erstellen. EC2

Syntax

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

Optionen

Benutzer werden als nicht interaktive Systembenutzer mit der Shell /sbin/nologin erstellt. Dies ist beabsichtigt und kann nicht geändert werden.

Beispielausschnitt

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

Quellen

Sie können den sources Schlüssel verwenden, um eine Archivdatei von einer öffentlichen Datei herunterzuladen URL und sie in ein Zielverzeichnis auf der EC2 Instanz zu entpacken.

Syntax

sources:
  target directory: location of archive file

Unterstützte Formate

Unterstützte Formate sind tar, tar+gzip, tar+bz2 und zip. Sie können externe Standorte wie Amazon Simple Storage Service (Amazon S3) (z. B.https://amzn-s3-demo-bucket.s3.amazonaws.com/myobject) referenzieren, solange der öffentlich zugänglich URL ist.

Beispielausschnitt

Im folgenden Beispiel wird eine öffentliche ZIP-Datei von einem Amazon S3-Bucket heruntergeladen und in /etc/myapp entpackt:

sources:  
  /etc/myapp: https://amzn-s3-demo-bucket.s3.amazonaws.com/myobject

Dateien

Sie können den files Schlüssel verwenden, um Dateien auf der EC2 Instance zu erstellen. Der Inhalt kann entweder direkt in der Konfigurationsdatei enthalten sein, oder der Inhalt kann aus einer abgerufen werdenURL. Die Dateien werden in lexikalischer Reihenfolge auf den Datenträger geschrieben.

Wenn private Dateien mit dem Schlüssel files von Amazon S3 heruntergeladen werden sollen, stellen Sie ein Instance-Profil für die Autorisierung bereit.

Wenn der von Ihnen angegebene Dateipfad bereits auf der Instance vorhanden ist, wird die vorhandene Datei beibehalten, wobei die Erweiterung .bak an ihren Namen angehängt wird.

Syntax

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:

Optionen

Beispielausschnitt

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

Beispiel mit einem Symlink. Dies erzeugt einen Link /tmp/myfile2.txt, der auf die Datei /tmp/myfile1.txt verweist.

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

In dem folgenden Beispiel wird der Ressourcenschlüssel zum Hinzufügen einer Authentifizierungsmethode mit dem Namen S3Auth und zum Herunterladen einer privaten Datei aus einem Amazon S3-Bucket verwendet:

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

Befehle

Sie können den commands Schlüssel verwenden, um Befehle auf der EC2 Instanz auszuführen. Die Befehle werden ausgeführt, bevor die Anwendung und der Webserver eingerichtet sind und die Anwendungsversionsdatei extrahiert wird.

Die angegebenen Befehle werden als Root-Benutzer ausgeführt und in alphabetischer Reihenfolge dem Namen nach verarbeitet. Befehle werden standardmäßig im Stammverzeichnis ausgeführt. Um die Befehle aus einem anderen Verzeichnis auszuführen, verwenden Sie die cwd-Option.

Um Probleme mit Befehlen zu beheben, schlagen Sie deren Ausgabe in den Instance-Protokollen nach.

Syntax

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

Optionen

Beispielausschnitt

Der folgende Beispielausschnitt führt ein Python-Skript aus.

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

Services

Mit dem Schlüssel services definieren Sie, welche Services beim Start der Instance gestartet oder gestoppt werden sollen. Zudem lassen sich mit dem Schlüssel services auch Abhängigkeiten von Quellen, Paketen und Dateien angeben, sodass Elastic Beanstalk im Falle eines Neustarts aufgrund von installierten Dateien den Service neu startet.

Syntax

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"

Optionen

Beispielausschnitt

Es folgt ein Beispiel für einen Ausschnitt:

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

Container-Befehle

Mit dem Schlüssel container_commands können Sie Befehle ausführen, die sich auf den Anwendungsquellcode auswirken. Container-Befehle werden ausgeführt, nachdem die Anwendung und der Webserver eingerichtet sind und die Anwendungsversionsdatei extrahiert wurde, aber bevor die Anwendungsversion bereitgestellt wird. Nicht-Container-Befehle und andere Anpassungen werden vor der Extraktion des Anwendungsquellcodes ausgeführt.

Die angegebenen Befehle werden als Root-Benutzer ausgeführt und in alphabetischer Reihenfolge dem Namen nach verarbeitet. Container-Befehle werden aus dem Staging-Verzeichnis ausgeführt, aus dem der Quellcode vor der Bereitstellung auf dem Anwendungsserver extrahiert wird. Alle Änderungen, die Sie mithilfe eines Container-Befehls am Quellcode im Staging-Verzeichnis vornehmen, werden bei der Bereitstellung der Quelle am endgültigen Speicherort einbezogen.

Verwenden Sie den Befehl leader_only, wenn der Befehl nur auf einer einzelnen Instance ausgeführt werden soll, oder konfigurieren Sie test so, dass der Befehl nur ausgeführt wird, sofern der Testbefehl den Wert true ergibt. Die Ausführung von Container-Befehlen des Leader-only-Typs erfolgt nur während der Umgebungserstellung und -bereitstellung, wohingegen andere Befehle und Serveranpassungen bei jeder Instance-Bereitstellung oder -Aktualisierung ausgeführt werden. Container-Befehle, die nur für Leader vorgesehen sind, werden aufgrund von Änderungen der Startkonfiguration, wie z. B. einer Änderung der AMI ID oder des Instance-Typs, nicht ausgeführt.

Syntax

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

Optionen

Beispielausschnitt

Es folgt ein Beispiel für einen Ausschnitt.

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"