Benutzerdefinierte Elastic Beanstalk-Plattformen - AWS Elastic Beanstalk

Benutzerdefinierte Elastic Beanstalk-Plattformen

Anmerkung

Am 18. Juli 2022 stellte Elastic Beanstalk den Status aller Plattformzweige auf Basis von Amazon-Linux-AMI (AL1) auf außer Betrieb genommen. Dies schließt auch benutzerdefinierte Plattformen ein. Elastic Beanstalk unterstützt keine benutzerdefinierte Plattformen. Weitere Informationen über Elastic Beanstalks Einstellung von Amazon Linux AMI finden Sie unter Häufig gestellte Fragen zur Einstellung von Plattformen.

Dieses Thema verbleibt in diesem Dokument als Referenz für alle Kunden, die die benutzerdefinierte Plattformfunktion von Elastic Beanstalk vor ihrer Einstellung verwendet haben. Früher, unterstützten benutzerdefinierte Elastic-Beanstalk-Plattformen ausschließlich das Erstellen eines AMI über AMIs auf der Basis von Amazon Linux AMI, RHEL 7, RHEL 6 oder Ubuntu 16.04. Diese Betriebssysteme werden von Elastic Beanstalk nicht mehr unterstützt. Um mehr über die nicht länger unterstützte Funktion der benutzerdefinierten Plattformen zu erfahren, erweitern Sie das folgende Thema.

Eine benutzerdefinierte Plattform ist mehr eine erweiterte Anpassung als ein benutzerdefiniertes Image. Eine benutzerdefinierte Plattform gestattet Ihnen, eine ganze Plattform von Grund auf neu zu entwickeln, das Betriebssystem anzupassen sowie zusätzliche Software und Skripts hinzuzufügen, die Elastic Beanstalk auf Plattform-Instances ausführt. Diese Flexibilität ermöglicht Ihnen den Aufbau einer Plattform für eine Anwendung, die eine Sprache oder andere Infrastruktur-Software verwendet, für die Elastic Beanstalk keine verwaltete Plattform bietet. Vergleichen Sie dies mit benutzerdefinierten Abbildern, bei denen Sie ein Amazon Machine Image (AMI) für die Verwendung mit einer vorhandenen Elastic Beanstalk-Plattform ändern und Elastic Beanstalk weiterhin die Plattform-Skripts bereitstellt und den Software-Stack der Plattform steuert. Darüber hinaus verwenden Sie bei benutzerdefinierten Plattformen eine automatisierte, skriptgesteuerte Methode, Ihre Anpassung zu erstellen und zu verwalten, während Sie bei benutzerdefinierten Abbildern die Änderungen manuell über eine laufende Instance ausführen.

Um eine benutzerdefinierte Plattform zu erstellen, erzeugen Sie ein AMI aus einem der unterstützten Betriebssysteme – Ubuntu, RHEL oder Amazon Linux (die genauen Versionsnummern finden Sie im Eintrag flavor unter Platform.yaml-Dateiformat) – und fügen weitere Anpassungen hinzu. Sie erstellen Ihre eigene Elastic Beanstalk-Plattform mit Packer, einem Open Source-Tool zum Erstellen von Machine Images für zahlreiche Plattformen, darunter auch AMIs für Amazon Elastic Compute Cloud (Amazon EC2). Eine Elastic Beanstalk-Plattform umfasst ein AMI, das zur Ausführung der anwendungsunterstützenden Software konfiguriert ist, sowie Metadaten, die benutzerdefinierte Konfigurationsoptionen und Standardeinstellungen der Konfigurationsoptionen enthalten können.

Elastic Beanstalk verwaltet Packer als separate integrierte Plattform und Sie brauchen sich nicht um die Konfiguration und Versionen von Packer zu kümmern.

Sie erstellen eine Plattform, indem Sie eine Packer-Vorlage sowie die von der Vorlage aufgerufenen Skripts und Dateien für die AMI-Erstellung in Elastic Beanstalk bereitstellen. Diese Komponenten werden mit einer Plattformdefinitionsdatei, in der die Vorlage und die Metadaten spezifiziert werden, in ein ZIP-Archiv verpackt, das als Plattformdefinitionsarchiv bezeichnet wird.

Wenn Sie eine benutzerdefinierte Plattform erstellen, starten Sie eine Umgebung mit einer einzelnen Instance ohne eine Elastic IP, die Packer ausführt. Packer startet dann eine weitere Instance, um ein Image zu erstellen. Sie können diese Umgebung für mehrere Plattformen und verschiedene Versionen jeder Plattform einsetzen.

Anmerkung

Benutzerdefinierte Plattformen sind AWS-regionsspezifisch. Falls Sie Elastic Beanstalk in mehreren Regionen nutzen, müssen Sie die Plattformen in jeder Region separat erstellen.

In bestimmten Situationen werden vom Packer gestartete Instances nicht gelöscht und müssen manuell beendet werden. Informationen zum manuellen Bereinigen dieser Instances finden Sie unter Bereinigen von Instances durch Packer.

Die Benutzer in Ihrem Konto können die benutzerdefinierten Plattformen verwenden, indem sie während der Umgebungserstellung einen Plattform-ARN angeben. Diese ARNs werden vom Befehl eb platform create zurückgegeben, mit dem Sie die benutzerdefinierte Plattform erstellt haben.

Jedes Mal, wenn Sie eine benutzerdefinierte Plattform erstellen, generiert Elastic Beanstalk eine neue Plattformversion. Benutzer können den Namen einer Plattform angeben, damit nur die neueste Version der Plattform aufgerufen wird, oder eine Versionsnummer spezifizieren, um eine bestimmte Version zu erhalten.

Beispielsweise stellen Sie die benutzerdefinierte Plattform mit dem ARN MyCustomPlatformARN und der neuesten Version 3.0 mit folgendem EB CLI-Befehl bereit:

eb create -p MyCustomPlatformARN

Für die Bereitstellung von Version 2.1 sieht der EB CLI-Befehl wie folgt aus:

eb create -p MyCustomPlatformARN --version 2.1

Sie können eine benutzerdefinierte Plattformversion mit Tags markieren, wenn Sie sie erstellen, und Tags von vorhandenen benutzerdefinierten Plattformversionen bearbeiten. Details hierzu finden Sie unter Markieren von benutzerdefinierten Plattformversionen.

Erstellen einer benutzerdefinierten Plattform

Damit Sie eine benutzerdefinierte Plattform erstellen können, muss der Anwendungsstamm eine Plattformdefinitionsdatei enthalten, platform.yaml. Diese definiert den Builder-Typ, mit dem die benutzerdefinierte Plattform erstellt wird. Das Format dieser Datei ist in Platform.yaml-Dateiformat beschrieben. Sie können die benutzerdefinierte Plattform von Grund auf neu erstellen oder eines der benutzerdefinierten Plattformbeispiele als Ausgangspunkt verwenden.

Verwenden eines benutzerdefinierten Plattformbeispiels

Als Alternative zum Erstellen einer eigenen benutzerdefinierten Plattform können Sie eines der Plattformdefinitionsarchiv-Beispiele für den Bootstrap der benutzerdefinierten Plattform nutzen. Die einzigen Elemente, die Sie in den Beispielen konfigurieren müssen, bevor Sie sie verwenden können, sind ein Quell-AMI und eine Region.

Anmerkung

Verwenden Sie kein nicht abgeändertes Beispiel für eine benutzerdefinierte Plattform in der Produktion. Das Ziel der Beispiele besteht darin, einige verfügbare Funktionen für eine benutzerdefinierte Plattform zu veranschaulichen, sie sind jedoch nicht für den Einsatz in der Produktion gehärtet worden.

NodePlatform_Ubuntu.zip

Diese benutzerdefinierte Plattform basiert auf Ubuntu 16.04 und unterstützt Node.js 4.4.4. In den folgenden Beispielen wird diese benutzerdefinierte Plattform verwendet.

NodePlatform_RHEL.zip

Diese benutzerdefinierte Plattform basiert auf RHEL 7.2 und unterstützt Node.js 4.4.4.

NodePlatform_AmazonLinux.zip

Diese benutzerdefinierte Plattform basiert auf Amazon Linux 2016.09.1 und unterstützt Node.js 4.4.4.

TomcatPlatform_Ubuntu.zip

Diese benutzerdefinierte Plattform basiert auf Ubuntu 16.04 und unterstützt Tomcat 7/Java 8.

CustomPlatform_NodeSampleApp.zip

In diesem Node.js-Beispiel wird eine statische Webseite mithilfe von express und ejs angezeigt.

CustomPlatform_TomcatSampleApp.zip

In diesem Tomcat-Beispiel wird eine statische Webseite bei der Bereitstellung angezeigt.

Laden Sie das Plattformdefinitionsarchiv-Beispiel herunter: NodePlatform_Ubuntu.zip. Diese Datei enthält eine Plattformdefinitionsdatei, eine Packer-Vorlage, Skripts, die während der Image-Erstellung von Packer ausgeführt werden, sowie Skripts und Konfigurationsdateien, die von Packer im Rahmen der Plattformerstellung auf die Builder-Instance kopiert werden.

Beispiel NodePlatform_Ubuntu.zip
|-- builder Contains files used by Packer to create the custom platform |-- custom_platform.json Packer template |-- platform.yaml Platform definition file |-- ReadMe.txt Briefly describes the sample

Die Plattformdefinitionsdatei, platform.yaml, teilt Elastic Beanstalk den Namen der Packer-Vorlage mit, custom_platform.json.

version: "1.0" provisioner: type: packer template: custom_platform.json flavor: ubuntu1604

Mithilfe der Packer-Vorlage wird Packer angewiesen, die AMIs für die Plattform zu erstellen, und zwar mit einem Ubuntu-AMI als Basis für das Plattform-Image von HVM-Instance-Typen. Der Abschnitt provisioners weist Packer an, alle Dateien im Archiv-Ordner builder auf die Instance zu kopieren und das Skript builder.sh auf der Instance auszuführen. Nach Abschluss des Skripts erstellt Packer ein Image von der geänderten Instance.

Elastic Beanstalk erstellt drei Umgebungsvariablen, mit denen AMIs in Packer getaggt werden können:

AWS_EB_PLATFORM_ARN

Der ARN der benutzerdefinierten Plattform.

AWS_EB_PLATFORM_NAME

Der Name der benutzerdefinierten Plattform.

AWS_EB_PLATFORM_VERSION

Die Version der benutzerdefinierten Plattform.

Die Beispieldatei custom_platform.json nutzt diese Variablen, um die folgenden in den Skripts verwendeten Werte zu definieren:

  • platform_name, wird festgelegt von der Datei platform.yaml.

  • platform_version, wird festgelegt von der Datei platform.yaml.

  • platform_arn, wird festgelegt vom Build-Hauptskript builder.sh, das sich am Ende der Beispieldatei custom_platform.json befindet.

Die Datei custom_platform.json enthält zwei Eigenschaften, für die Sie Werte angeben müssen: source_ami und region. Weitere Informationen über die Auswahl der richtigen Werte für AMI und Region finden Sie unter Aktualisieren der Packer-Vorlage im GitHub-Repository eb-custom-platforms-samples.

Beispiel custom_platform.json
{ "variables": { "platform_name": "{{env `AWS_EB_PLATFORM_NAME`}}", "platform_version": "{{env `AWS_EB_PLATFORM_VERSION`}}", "platform_arn": "{{env `AWS_EB_PLATFORM_ARN`}}" }, "builders": [ { ... "region": "", "source_ami": "", ... } ], "provisioners": [ {...}, { "type": "shell", "execute_command": "chmod +x {{ .Path }}; {{ .Vars }} sudo {{ .Path }}", "scripts": [ "builder/builder.sh" ] } ] }

Die Skripts und andere Dateien, die Sie in das Plattformdefinitionsarchiv einbinden, sind je nach den Änderungen, die Sie an der Instance vornehmen möchten, sehr unterschiedlich. Das Plattformbeispiel enthält die folgenden Skripts:

  • 00-sync-apt.sh – Auskommentiert: apt -y update. Wir haben den Befehl auskommentiert, weil er den Benutzer zu einer Eingabe auffordert, die die automatische Paketaktualisierung unterbricht. Dies könnte ein Ubuntu-Problem sein. Als bewährte Methode empfehlen wir jedoch weiterhin, apt -y update auszuführen. Aus diesem Grund haben wir den Befehl zur Referenz im Beispiel-Skript beibehalten.

  • 01-install-nginx.sh – Installiert nginx.

  • 02-setup-platform.sh – Installiert wget, tree und git. Kopiert Hooks sowie Protokollierungskonfigurationen auf die Instance und erstellt die folgenden Verzeichnisse:

    • /etc/SampleNodePlatform – Gibt an, wohin die Container-Konfigurationsdatei während der Bereitstellung hochgeladen wird.

    • /opt/elasticbeanstalk/deploy/appsource/ – Gibt an, wohin der Anwendungsquellcode während der Bereitstellung vom 00-unzip.sh-Skript hochgeladen wird (weitere Informationen zu diesem Skript finden Sie im Abschnitt Plattform-Skript-Tools).

    • /var/app/staging/ – Gibt an, wo der Anwendungsquellcode während der Bereitstellung verarbeitet wird.

    • /var/app/current/ – Gibt an, wo der Anwendungsquellcode nach der Verarbeitung ausgeführt wird.

    • /var/log/nginx/healthd/ – Gibt an, wohin die Protokolle vom Agent für erweiterte Integritätsberichte geschrieben werden.

    • /var/nodejs – Gibt an, wohin die Node.js-Dateien während der Bereitstellung hochgeladen werden.

Verwenden Sie die EB CLI, um Ihre erste benutzerdefinierte Plattform mit dem Plattformdefinitionsarchiv-Beispiel zu erstellen.

So erstellen Sie eine benutzerdefinierte Plattform
  1. Installieren Sie die EB CLI.

  2. Erstellen Sie ein Verzeichnis, in welches das benutzerdefinierte Plattformbeispiel extrahiert wird.

    ~$ mkdir ~/custom-platform
  3. Extrahieren Sie NodePlatform_Ubuntu.zip in das Verzeichnis und wechseln Sie dann zu diesem Verzeichnis.

    ~$ cd ~/custom-platform ~/custom-platform$ unzip ~/NodePlatform_Ubuntu.zip ~/custom-platform$ cd NodePlatform_Ubuntu
  4. Bearbeiten Sie die Datei custom_platform.json und geben Sie Werte für die Eigenschaften region und source_ami an. Weitere Informationen finden Sie unter Aktualisieren der Packer-Vorlage.

  5. Führen Sie eb platform init aus und folgen Sie den Anweisungen, um ein Plattform-Repository zu initialisieren.

    Sie können eb platform zu ebp verkürzen.

    Anmerkung

    Windows PowerShell verwendet ebp als Befehls-Alias. Wenn Sie die EB CLI in Windows PowerShell ausführen, müssen Sie die Langform dieses Befehls verwenden eb platform.

    ~/custom-platform$ eb platform init

    Mit diesem Befehl wird zudem das Verzeichnis .elasticbeanstalk im aktuellen Verzeichnis erstellt, dann wird die Konfigurationsdatei config.yml zum Verzeichnis hinzugefügt. Diese Datei wird von Elastic Beanstalk zum Erstellen der benutzerdefinierten Plattform benötigt, daher darf sie weder geändert noch gelöscht werden.

    Standardmäßig verwendet eb platform init den Namen des aktuellen Ordners als Bezeichnung für die benutzerdefinierte Plattform, in diesem Beispiel also custom-platform.

  6. Führen Sie eb platform create aus, um die Packer-Umgebung zu starten und den ARN der benutzerdefinierten Plattform abzurufen. Diesen Wert benötigen Sie später zum Erstellen der Umgebung für die benutzerdefinierte Plattform.

    ~/custom-platform$ eb platform create ...

    Standardmäßig erstellt Elastic Beanstalk das Instance-Profil aws-elasticbeanstalk-custom-platform-ec2-role für benutzerdefinierte Plattformen. Wenn Sie stattdessen ein vorhandenes Instance-Profil nutzen möchten, fügen Sie die Option -ip INSTANCE_PROFILE zum Befehl eb platform create hinzu.

    Anmerkung

    Falls Sie das Instance-Standardprofil aws-elasticbeanstalk-ec2-role von Elastic Beanstalk nutzen, kann Packer die benutzerdefinierte Plattform nicht erstellen.

    In der EB CLI wird die Ereignisausgabe der Packer-Umgebung angezeigt, bis die Erstellung abgeschlossen ist. Sie können die Ereignisanzeige verlassen, indem Sie Strg+C drücken.

  7. Mit dem Befehl eb platform logs können Sie die Protokolle auf Fehler überprüfen.

    ~/custom-platform$ eb platform logs ...
  8. Mit eb platform events können Sie den Prozess später prüfen.

    ~/custom-platform$ eb platform events ...
  9. Überprüfen Sie den Status der Plattform mit eb platform status.

    ~/custom-platform$ eb platform status ...

Nach Abschluss des Vorgangs steht Ihnen eine Plattform zur Verfügung, auf der Sie eine Elastic Beanstalk-Umgebung starten können.

Sie können die benutzerdefinierte Plattform einsetzen, um eine neue Umgebung mit der Konsole zu erstellen. Siehe Der Assistent zum Erstellen einer neuen Umgebung.

So starten Sie eine Umgebung auf der benutzerdefinierten Plattform
  1. Erstellen Sie ein Verzeichnis für die Anwendung.

    ~$ mkdir custom-platform-app ~$ cd ~/custom-platform-app
  2. Initialisieren Sie ein Anwendungs-Repository.

    ~/custom-platform-app$ eb init ...
  3. Laden Sie die Beispielanwendung NodeSampleApp.zip herunter.

  4. Extrahieren Sie die Beispielanwendung.

    ~/custom-platform-app$ unzip ~/NodeSampleApp.zip
  5. Führen Sie eb create -p CUSTOM-PLATFORM-ARN aus (wobei CUSTOM-PLATFORM-ARN der vom Befehl eb platform create zurückgegebene ARN ist), um eine Umgebung zu starten, in der die benutzerdefinierte Plattform ausgeführt wird.

    ~/custom-platform-app$ eb create -p CUSTOM-PLATFORM-ARN ...

Inhalte des Plattformdefinitionsarchivs

Ein Plattformdefinitionsarchiv ist die Plattformentsprechung vom Quell-Bundle der Anwendung. Das Plattformdefinitionsarchiv ist eine ZIP-Datei und enthält eine Plattformdefinitionsdatei, eine Packer-Vorlage sowie die von der Packer-Vorlage verwendeten Skripts und Dateien für die Plattformerstellung.

Anmerkung

Wenn Sie die EB CLI zum Erstellen der benutzerdefinierten Plattform verwenden, generiert die EB CLI ein Plattformdefinitionsarchiv aus den Dateien und Ordnern im Plattform-Repository, daher muss das Archiv nicht manuell angelegt werden.

Die Datei Plattformdefinitionsdatei weist das YAML-Format auf, muss den Namen platform.yaml haben und im Plattformdefinitionsarchiv-Stamm sein. Unter Erstellen einer benutzerdefinierten Plattform finden Sie eine Liste der erforderlichen und optionalen Schlüssel, die in einer Plattformdefinitionsdatei unterstützt werden.

Die Packer-Vorlage muss nicht nach einer bestimmten Konvention benannt werden, jedoch muss dieser Dateiname mit der Provisioner-Vorlage, die in der Plattformdefinitionsdatei angegeben ist, übereinstimmen. Anleitungen zum Erstellen von Packer-Vorlagen finden Sie in der offiziellen Packer-Dokumentation.

Bei den anderen Dateien im Plattformdefinitionsarchiv handelt es sich um Skripts und Dateien, die von der Vorlage vor der AMI-Erstellung zur Instance-Anpassung verwendet werden.

Benutzerdefinierte Plattform-Hooks

Elastic Beanstalk verwendet eine standardisierte Verzeichnisstruktur für Hooks auf benutzerdefinierten Plattformen. Dies sind Skripts, die bei Lebenszyklusereignissen und als Reaktion auf Verwaltungsvorgänge ausgeführt werden, z. B. wenn Instances in der Umgebung gestartet werden oder wenn ein Benutzer eine Bereitstellung initiiert oder die Funktion für den Neustart des Anwendungsservers nutzt.

Platzieren Sie Skripts, die Hooks auslösen sollen, in einem der Unterordner des Ordners /opt/elasticbeanstalk/hooks/.

Warnung

Die Verwendung benutzerdefinierter Plattform-Hooks auf verwalteten Plattformen wird nicht unterstützt. Benutzerdefinierte Plattform-Hooks sind für benutzerdefinierte Plattformen bestimmt. Auf von Elastic Beanstalk verwalteten Plattformen funktionieren sie möglicherweise anders oder weisen Probleme auf und das Verhalten kann sich je nach Plattform unterscheiden. Auf Amazon Linux AMI-Plattformen (vor Amazon Linux 2) funktionieren sie möglicherweise immer noch auf nützliche Weise. Verwenden Sie sie jedoch mit Vorsicht.

Benutzerdefinierte Plattform-Hooks sind eine Legacy-Funktion auf Amazon Linux AMI-Plattformen. Auf Amazon Linux 2-Plattformen werden benutzerdefinierte Plattform-Hooks im Ordner /opt/elasticbeanstalk/hooks/ vollständig eingestellt. Elastic Beanstalk liest oder führt sie nicht aus. Amazon Linux 2-Plattformen unterstützen eine neue Art von Plattform-Hooks, die speziell zur Erweiterung von verwalteten Elastic Beanstalk-Plattformen entwickelt wurden. Sie können benutzerdefinierte Skripte und Programme direkt zu einem Hook-Verzeichnis in Ihrem Anwendungs-Quell-Bundle hinzufügen. Elastic Beanstalk führt sie während verschiedener Instance-Bereitstellungsphasen aus. Weitere Informationen erhalten Sie, indem Sie den Abschnitt Plattform-Hooks unter Erweitern von Elastic Beanstalk-Linux-Plattformen erweitern.

Hooks sind in den folgenden Ordnern organisiert:

  • appdeploy – Skripts, die während der Anwendungsbereitstellung ausgeführt werden. Wenn neue Instances gestartet werden oder ein Client eine neue Versionsbereitstellung initiiert, führt Elastic Beanstalk eine Anwendungsbereitstellung aus.

  • configdeploy – Skripts, die im Rahmen von clientseitigen Konfigurationsaktualisierungen, welche sich auf die Softwarekonfiguration der Instance auswirken (z. B. durch Festlegen von Umgebungseigenschaften oder Aktivieren der Protokollrotation an Amazon S3), ausgeführt werden.

  • restartappserver – Skripts, die bei einem clientseitigen Neustart des Anwendungsservers ausgeführt werden.

  • preinit – Skripts, die während des Instance-Bootstrapping ausgeführt werden.

  • postinit – Skripts, die nach dem Instance-Bootstrapping ausgeführt werden.

Die Ordner appdeploy, configdeploy und restartappserver enthalten die Unterordner pre, enact und post. In den einzelnen Vorgangsphasen werden alle Skripts im Ordner pre in alphabetischer Reihenfolge ausgeführt, dann folgen diejenigen im Ordner enact und anschließend diejenigen im Ordner post.

Beim Starten einer Instance führt Elastic Beanstalk preinit, appdeploy und postinit in dieser Reihenfolge aus. Bei nachfolgenden Bereitstellungen auf ausgeführten Instances führt Elastic Beanstalk die appdeploy-Hooks aus. Die configdeploy-Hooks werden ausgeführt, wenn ein Benutzer die Instance-Softwarekonfigurationseinstellungen aktualisiert. Die restartappserver-Hooks werden nur ausgeführt, wenn ein Benutzer den Neustart des Anwendungsservers initiiert.

Falls die Skripts auf Fehler treffen, werden sie mit einem Status ungleich null beendet und schreiben den fehlgeschlagenen Vorgang in die Datei stderr. Die in die Datei stderr geschriebene Nachricht wird im Ereignis angezeigt, das im Falle eines fehlgeschlagenen Vorgangs ausgegeben wird. Zudem werden diese Informationen von Elastic Beanstalk in der Protokolldatei /var/log/eb-activity.log erfasst. Wenn der Vorgang nicht als fehlgeschlagen gelten soll, muss 0 (Null) zurückgegeben werden. Nachrichten, die in die Datei stderr oder stdout geschrieben werden, erscheinen in den Bereitstellungsprotokollen, werden aber nur bei einem fehlgeschlagenen Vorgang im Ereignis-Stream angegeben.

Bereinigen von Instances durch Packer

Unter bestimmten Umständen, z. B. wenn der Packer-Erstellungsprozess vorzeitig abgebrochen wird, werden von Packer gestartete Instances nicht bereinigt. Diese Instances sind nicht Teil der Elastic Beanstalk-Umgebung und lassen sich nur mit dem Amazon EC2-Service anzeigen und beenden.

So bereinigen Sie diese Instances manuell
  1. Öffnen Sie die Amazon EC2-Konsole.

  2. Achten Sie darauf, dass Sie in derselben AWS-Region sind, in der Sie die Instance mit Packer erstellt haben.

  3. Wählen Sie unter Resources (Ressourcen) den Wert N Running Instances (Ausgeführte Instances) aus, wobei N für die Anzahl der ausgeführten Instances steht.

  4. Klicken Sie in das Abfragetextfeld.

  5. Wählen Sie das Tag Name aus.

  6. Geben Sie packer ein.

    Die Abfrage sollte wie folgt aussehen: tag:Name: packer

  7. Wählen Sie die Instances aus, die mit der Abfrage übereinstimmen.

  8. Wenn der Wert für Instance State (Instance-Status) mit running (wird ausgeführt) angegeben wird, wählen Sie Actions (Aktionen), Instance State (Instance-Status), Stop (Anhalten) und dann Actions (Aktionen), Instance State (Instance-Status), Terminate (Beenden) aus.

Platform.yaml-Dateiformat

Die platform.yaml-Datei hat folgendes Format:

version: "version-number" provisioner: type: provisioner-type template: provisioner-template flavor: provisioner-flavor metadata: maintainer: metadata-maintainer description: metadata-description operating_system_name: metadata-operating_system_name operating_system_version: metadata-operating_system_version programming_language_name: metadata-programming_language_name programming_language_version: metadata-programming_language_version framework_name: metadata-framework_name framework_version: metadata-framework_version option_definitions: - namespace: option-def-namespace option_name: option-def-option_name description: option-def-description default_value: option-def-default_value option_settings: - namespace: "option-setting-namespace" option_name: "option-setting-option_name" value: "option-setting-value"

Ersetzen Sie die Platzhalter mit folgenden Werten:

version-number

Erforderlich. Die Version der YAML-Definition. Der Wert muss 1.0 sein.

provisioner-type

Erforderlich. Der Typ des Builder, der für die Erstellung der benutzerdefinierten Plattform verwendet wurde. Der Wert muss packer sein.

provisioner-template

Erforderlich. Die JSON-Datei mit den Einstellungen für provisioner-type.

provisioner-flavor

Optional. Das Basis-Betriebssystem für die AMI. Eine der beiden folgenden Komponenten:

amazon (Standard)

Amazon Linux. Wenn nicht angegeben, wird die aktuelle Version von Amazon Linux verwendet, wenn die Plattform erstellt wird.

Amazon Linux 2 ist keine unterstützte Betriebssystemvariante.

ubuntu1604

Ubuntu 16.04 LTS

rhel7

RHEL 7

rhel6

RHEL 6

metadata-maintainer

Optional. Kontaktinformationen für den Eigentümer der Plattform (100 Zeichen).

metadata-description

Optional. Beschreibung der Plattform (2000 Zeichen).

metadata-operating_system_name

Optional. Name der Plattform im Betriebssystem (50 Zeichen). Dieser Wert ist verfügbar, wenn die Ausgabe für die ListPlatformVersions-API gefiltert wird.

metadata-operating_system_version

Optional. Version der Plattform im Betriebssystem (20 Zeichen).

metadata-programming_language_name

Optional. Programmiersprache, die von der Plattform unterstützt wird (50 Zeichen)

metadata-programming_language_version

Optional. Version der Sprache im Betriebssystem (20 Zeichen).

metadata-framework_name

Optional. Der Name des Web-Framework, das von der Plattform verwendet wird (50 Zeichen).

metadata-framework_version

Optional. Version des Web-Framework im Betriebssystem (20 Zeichen).

option-def-namespace

Optional. Ein Namespace unter aws:elasticbeanstalk:container:custom (100 Zeichen)

option-def-option_name

Optional. Der Name der Option (100 Zeichen). Sie können bis zu 50 benutzerdefinierte Konfigurationsoptionen festlegen, die die Plattform Benutzern bereitstellt.

option-def-description

Optional. Beschreibung der Option (1024 Zeichen).

option-def-default_value

Optional. Der Standardwert wird verwendet, wenn der Benutzer keinen angibt.

Das folgende Beispiel erstellt die Option NPM_START.

options_definitions: - namespace: "aws:elasticbeanstalk:container:custom:application" option_name: "NPM_START" description: "Default application startup command" default_value: "node application.js"
option-setting-namespace

Optional. Namespace der Option.

option-setting-option_name

Optional. Name der Option. Sie können bis zu 50 Optionen von Elastic Beanstalk angeben.

option-setting-value

Optional. Der Wert wird verwendet, wenn der Benutzer keinen angibt.

Das folgende Beispiel erstellt die Option TEST.

option_settings: - namespace: "aws:elasticbeanstalk:application:environment" option_name: "TEST" value: "This is a test"

Markieren von benutzerdefinierten Plattformversionen

Sie können Ihre benutzerdefinierten AWS Elastic Beanstalk-Plattformversionen mit Tags markieren. Tags sind mit AWS-Ressourcen verknüpfte Schlüssel-Wert-Paare. Weitere Informationen zum Elastic Beanstalk-Ressourcen-Tagging, zu Anwendungsfälle, Einschränkungen für Tag-Schlüssel und -Werte sowie zu unterstützten Ressourcentypen finden Sie unter Markieren von Elastic Beanstalk-Anwendungsressourcen.

Sie können Tags angeben, wenn Sie eine benutzerdefinierte Plattformversion erstellen. In einer vorhandenen benutzerdefinierten Plattformversion können Sie Tags hinzufügen oder entfernen sowie die Werte von vorhandenen Tags aktualisieren. Sie können jeder benutzerdefinierten Plattformversion bis zu 50 Tags hinzufügen.

Hinzufügen von Tags beim Erstellen einer benutzerdefinierten Plattformversion

Wenn Sie mit der EB CLI Ihre benutzerdefinierte Plattform erstellen, verwenden Sie die --tags-Option mit dem Befehl eb platform create, um Tags hinzuzufügen.

~/workspace/my-app$ eb platform create --tags mytag1=value1,mytag2=value2

Fügen Sie Tags mit der AWS CLI oder anderen API-basierten Clients hinzu, indem Sie den --tags-Parameter mit dem Befehl create-platform-version verwenden.

$ aws elasticbeanstalk create-platform-version \ --tags Key=mytag1,Value=value1 Key=mytag2,Value=value2 \ --platform-name my-platform --platform-version 1.0.0 --platform-definition-bundle S3Bucket=DOC-EXAMPLE-BUCKET,S3Key=sample.zip

Verwalten von Tags einer vorhandenen benutzerdefinierten Plattformversion

In einer vorhandenen benutzerdefinierten Elastic Beanstalk-Plattformversion können Sie Tags hinzufügen, aktualisieren und löschen.

Wenn Sie Ihre benutzerdefinierte Plattformversion mit der EB CLI aktualisieren, verwenden Sie den Befehl eb tags zum Hinzufügen, Aktualisieren, Löschen oder Auflisten von Tags.

Beispiel: Der folgende Befehl listet die Tags in einer benutzerdefinierten Plattformversion auf.

~/workspace/my-app$ eb tags --list --resource "arn:aws:elasticbeanstalk:us-east-2:my-account-id:platform/my-platform/1.0.0"

Mit dem folgenden Befehl wird das Tag mytag1 aktualisiert und das Tag mytag2 gelöscht.

~/workspace/my-app$ eb tags --update mytag1=newvalue --delete mytag2 \ --resource "arn:aws:elasticbeanstalk:us-east-2:my-account-id:platform/my-platform/1.0.0"

Eine umfassende Liste der Optionen sowie weitere Beispiele finden Sie unter eb tags.

Wenn Sie die AWS CLI oder andere API-basierte Clients verwenden, nutzen Sie den Befehl list-tags-for-resource, um die Tags einer benutzerdefinierter Plattformversions aufzulisten.

$ aws elasticbeanstalk list-tags-for-resource --resource-arn "arn:aws:elasticbeanstalk:us-east-2:my-account-id:platform/my-platform/1.0.0"

Verwenden Sie den Befehl update-tags-for-resource zum Hinzufügen, Aktualisieren und Löschen von Tags in einer benutzerdefinierten Plattformversion.

$ aws elasticbeanstalk update-tags-for-resource \ --tags-to-add Key=mytag1,Value=newvalue --tags-to-remove mytag2 \ --resource-arn "arn:aws:elasticbeanstalk:us-east-2:my-account-id:platform/my-platform/1.0.0"

Geben Sie sowohl hinzuzufügende als auch zu aktualisierende Tags im Parameter --tags-to-add des Befehls update-tags-for-resource an. Wenn ein Tag nicht vorhanden ist, wird es hinzugefügt, andernfalls wird es aktualisiert.

Anmerkung

Wenn Sie einige der EB CLI- und AWS CLI-Befehle mit einer benutzerdefinierten Elastic-Beanstalk-Plattformversion verwenden möchten, benötigen Sie den ARN der benutzerdefinierten Plattformversion. Verwenden Sie den folgenden Befehl, um den ARN abzurufen.

$ aws elasticbeanstalk list-platform-versions

Verwenden Sie die --filters-Option zum Filtern der Leistung Ihrer benutzerdefinierten Plattform.