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.

Erstellen von Container-Images für Beanstalk Cluster-Umgebungen

In einer Beanstalk Cluster-Umgebung wird eine Anwendung von einem Container-Image aus ausgeführt. Wie bei Beanstalk Standard wird eine Anwendungsversion in der Umgebung bereitgestellt. In einer Beanstalk-Cluster-Umgebung stellt die Anwendungsversion entweder ein Image bereit, das Elastic Beanstalk unverändert ausführt, oder eine Quelle, die Elastic Beanstalk in ein Image integriert. In diesem Thema werden die Voraussetzungen behandelt, sowohl die Erstellungspfade als auch der Verarbeitungsstatus und das für Beanstalk Cluster-Umgebungen spezifische Löschverhalten. Bereitstellungs-, Tagging- und Versionskontingente funktionieren in beiden Modi auf die gleiche Weise, ebenso wie die allgemeinen Erstellungs- und Löschverfahren. Siehe Verwalten von Anwendungsversionen und Markieren von Anwendungsversionen.

Erstellen Sie für eine Beanstalk Cluster-Bereitstellung die Anwendungsversion mit einer, ImageConfiguration die genau eines von zwei Mitgliedern enthält. Sourceidentifiziert ein Container-Image, das bereits erstellt wurde, und Build gibt an, wie Elastic Beanstalk ein Image aus einem Quellpaket erstellt. Elastic Beanstalk lehnt eine CreateApplicationVersion Anfrage ab, die beide Mitglieder oder keines von beiden ImageConfiguration liefert, eine Anforderung, die sowohl als auch einen liefertSourceBundle, ImageConfiguration.Source und eine Anforderung, die ImageConfiguration mit dem BuildConfiguration Parameter kombiniert wird, der Anwendungsversionen für Beanstalk Standard konfiguriert AWS CodeBuild . In den folgenden Abschnitten werden die einzelnen Pfade beschrieben.

Voraussetzungen

Die Beispiele in diesem Thema verwenden die AWS CLI. Installieren und konfigurieren Sie es, bevor Sie die Befehle ausführen. Sie verwenden das Konto und die AWS Region in Ihrer AWS CLI Konfiguration. Siehe Bevor Sie beginnen.

Bereiten Sie die folgenden Ressourcen vor und greifen Sie darauf zu:

Eingabe von Container-Bildern

Geben Sie eine ImageConfiguration mit einem Source Mitglied für ein Container-Image an, das bereits erstellt und in eine Registrierung übertragen wurde. Elastic Beanstalk führt das Image ohne einen Build-Schritt aus. Das Source enthält ein einzelnes FeldUri, das auf das Bild zeigt. Das Bild kann sich in Amazon Elastic Container Registry (Amazon ECR) oder in einer beliebigen Registrierung befinden, die einen unauthentifizierten Abruf zulässt. Verwenden Sie für ein privates Image Amazon ECR: Die Node-Rolle der Umgebung authentifiziert sich dafür. Für eine Anwendungsversion, die aus einem bereitgestellten Image erstellt wurde, ist kein Build erforderlich. Elastic Beanstalk zeichnet sie mit dem Status auf UNPROCESSED und sie kann in einer Beanstalk-Cluster-Umgebung bereitgestellt werden.

Elastic Beanstalk zeichnet den URI genau so auf, wie Sie ihn angeben, unabhängig davon, ob er ein Tag oder einen Digest benennt. Ein Image, das Elastic Beanstalk erstellt, wird von Digest aufgezeichnet.

Verwenden Sie dieses Shape, wenn eine separate Pipeline das Image erstellt oder wenn ein Image bereitgestellt wird, das mit einer früheren Anwendungsversion erstellt wurde. Damit Elastic Beanstalk das Image erstellt, stellen Sie ein Quellpaket und ein Build Mitglied bereit, wie im Folgenden beschrieben.

Geben Sie den Quellcode an, den Elastic Beanstalk erstellen soll

Geben Sie eine anSourceBundle, wenn Elastic Beanstalk das Container-Image aus der Anwendungsquelle erstellen muss. Das SourceBundle identifiziert das Quellarchiv in Amazon Simple Storage Service (Amazon S3) mit zwei Feldern, undS3Bucket. S3Key Ein Quellpaket erfordert außerdem einenImageConfiguration, dessen Build Mitglied angibt, wie Elastic Beanstalk die Quelle in ein Image konvertiert. trueIn der CreateApplicationVersion Anfrage Process auf gesetzt, um den Build zu starten; verwenden Sie mit dem AWS CLI. --process Wenn Sie diese Einstellung weglassen, bleibt die quellbasierte Anwendungsversion erhalten UNPROCESSED und der Build wird nicht gestartet. Wenn die Verarbeitung beginnt, erstellt Elastic Beanstalk das Image und überträgt es an Amazon Elastic Container Registry in Ihrem Konto. Informationen zu den Buildtypen Docker und Buildpack und ihren Einstellungen finden Sie unter. Konfiguration erstellen

Während der Build ausgeführt wird, meldet die Anwendungsversion den Status. BUILDING Sie wechselt zu dem PROCESSED Zeitpunkt, zu dem das Image erstellt und übertragen wird, oder zu FAILED dem Zeitpunkt, an dem der Build nicht erfolgreich ist.

Konfiguration erstellen

Das Build Mitglied von gehört ImageConfiguration zu einem Quellpaket und steuert, wie Elastic Beanstalk das Image erstellt. Es enthält neben dem im Folgenden beschriebenen Build-Typ die folgenden Felder:

Das Build Mitglied wählt in seinem Type Feld einen von zwei Build-Typen aus, was erforderlich ist:

Das Architecture Feld legt die Ziel-CPU-Architektur des Images fest, entweder oder. amd64 arm64 Wenn Sie es weglassen, erstellt Elastic Beanstalk für. amd64 Erstellen Sie für dieselbe Architektur wie die arch Umgebungseinstellung, die ebenfalls standardmäßig auf eingestellt ist. amd64 Ein für eine Architektur erstelltes Image läuft nicht auf der anderen. Informationen für arch finden Sie unter Konfigurationsoptionen für Beanstalk Cluster-Umgebungen.

Prüfen und überwachen Sie den Verarbeitungsstatus

Eine quellbasierte Version meldet, BUILDING während Elastic Beanstalk sein Image erstellt. Stellen Sie es erst bereit, nachdem es die Meldung gemeldet hat. PROCESSED Der Status von FAILED bedeutet, dass der Build nicht erfolgreich war und die Version nicht bereitgestellt werden kann. Ein Status von UNPROCESSED bedeutet, dass die Verarbeitung nicht gestartet wurde, z. B. als die CreateApplicationVersion Anforderung ausgelassen wurdeProcess. Eine Anwendungsversion, die aus einem bereitgestellten Image erstellt wurdeUNPROCESSED, meldet ebenfalls, aber sie ist bereit für die Bereitstellung, da für ihr Image kein Build erforderlich ist.

Eine Beschreibung einer Anwendungsversion gibt ihren Image-Status als zwei Mitglieder an, ImageSource undImageBuildConfiguration. Gibt bei einer quellbasierten Version die Build-Einstellungen an und fehlt, während die Version gemeldet ImageSource wird. ImageBuildConfiguration BUILDING Wenn der Build erfolgreich ist, wird die im Digest-Modus hinterlegte URI des Images ImageSource zurückgegeben, das der Build erstellt und übertragen hat.

Prüfen Sie den Verarbeitungsstatus einer quellbasierten Version mit. DescribeApplicationVersions Auf operation_start den Zeitstempel gesetzt, der unmittelbar vor der CreateApplicationVersion Anforderung aufgezeichnet wurde; die nachfolgenden Ereignisabfragen verwenden ihn, um Ereignisse auf den Build einzugrenzen.

$ aws elasticbeanstalk describe-application-versions \
    --application-name my-app \
    --version-labels v1-build \
    --query 'ApplicationVersions[0].Status' \
    --output text

Wiederholen Sie diesen Befehl, bis die Version den Terminalstatus erreicht hat. BUILDINGbedeutet, dass der Build noch läuft. Stellen Sie die Version erst bereit, nachdem sie PROCESSED gemeldet wurde. Ein Status von FAILED oder UNPROCESSED bedeutet, dass die Version nicht bereitgestellt werden kann.

Bei einer quellenbasierten Version bestätigen ein PROCESSED Status und ein Ereignis zum Abschluss der Image-Erstellung, dass Elastic Beanstalk das Image erstellt und aufgezeichnet hat. Rufen Sie Ereignisse für die jeweilige Version ab, um einen Terminalausfall von einem Build zu unterscheiden, der noch läuft:

$ aws elasticbeanstalk describe-events \
    --application-name my-app \
    --version-label v1-build \
    --start-time "$operation_start" \
    --max-items 20

Wenn die Version erreicht istFAILED, fügen Sie die zugehörigen Fehlerereignisse hinzu, --severity ERROR um sie abzurufen. Die Ereignisse unterscheiden Fehler wie das Herunterladen der Quelle, die Übernahme der Rolle, die Amazon ECR-Authentifizierung und Fehler beim Erstellen oder Senden von Images:

$ aws elasticbeanstalk describe-events \
    --application-name my-app \
    --version-label v1-build \
    --severity ERROR \
    --start-time "$operation_start" \
    --max-items 20

Die Ereignisse identifizieren, welche Phase fehlgeschlagen ist. Um zu sehen, warum der Build selbst fehlgeschlagen ist, verwenden Sie den BerichtBuildArn, den eine quellenbasierte Version meldet. Darin wird die AWS CodeBuild Ausführung identifiziert, bei der der Build ausgeführt wurde. Übergeben Sie es an den folgenden Befehl, um den Status des Builds und den Speicherort seiner Protokolle abzurufen:

$ aws codebuild batch-get-builds \
    --ids build-arn \
    --query 'builds[0].{status:buildStatus,logGroup:logs.groupName,logStream:logs.streamName}'

Die Antwort enthält auch einenlogs.deepLink, der den Log-Stream des Builds in der CloudWatch Amazon-Konsole öffnet.

Korrigieren Sie den Quellspeicherort, die Build-Konfiguration oder die Rollenkonfiguration, die durch das Ereignis identifiziert wurden. Erstellen Sie eine neue Anwendungsversion mit einer neuen Bezeichnung und Process setzen Sie sie auftrue, und fragen Sie sie anschließend auf abPROCESSED. Stellen Sie keine Version in bereitFAILED. Die erfolgreiche Verarbeitung beweist nur, dass das Image für die Anwendungsversion verfügbar ist; eine Bereitstellung in einer Umgebung wird damit nicht überprüft.

Die Beispielanwendung

Eine Anwendungsversion ist optional, wenn Sie eine Beanstalk Cluster-Umgebung erstellen. Wenn Elastic Beanstalk ohne Versionsbezeichnung (oder mit einer leeren) aufgerufen CreateEnvironment wird, stellt es eine Beispielanwendung bereit, um eine lauffähige Umgebung bereitzustellen. Elastic Beanstalk unterstützt das Beispiel mit einem vorgefertigten Container-Image, sodass für die Bereitstellung kein Build-Schritt erforderlich ist. Die Beispielanwendung kann nicht als Kundenanwendung ausgewählt oder konfiguriert werden. Elastic Beanstalk stellt sie bereit, wenn keine Versionsbezeichnung angegeben ist. Um eine Anwendung bereitzustellen, erstellen Sie eine Anwendungsversion, wie in diesem Thema beschrieben, und übergeben Sie die Versionsbezeichnung an. CreateEnvironment Informationen zur Erstellung von Umgebungen finden Sie unterErste Schritte mit Beanstalk Cluster.

Beispiele

Die folgende CreateApplicationVersion Anforderung stellt ein vorhandenes Container-Image bereit. Elastic Beanstalk führt das Image unverändert aus, ohne Build.

aws elasticbeanstalk create-application-version \
  --application-name my-app \
  --version-label v1-image \
  --image-configuration Source={Uri=111122223333.dkr.ecr.us-east-1.amazonaws.com/my-app:v1}

Die folgende Anfrage stellt stattdessen ein Quellpaket in Amazon S3 und eine Build-Konfiguration bereit, die das Image aus einem Dockerfile für die Architektur erstellt. arm64 Um dieses Image auszuführen, setzen Sie die arch Umgebungsoption arm64 ebenfalls auf.

operation_start=$(date -u +%Y-%m-%dT%H:%M:%SZ)
aws elasticbeanstalk create-application-version \
  --application-name my-app \
  --version-label v1-build \
  --process \
  --source-bundle S3Bucket=my-source-bucket,S3Key=my-app/v1.zip \
  --image-configuration '{
    "Build": {
      "Type": "docker",
      "DockerfileLocation": "Dockerfile",
      "Architecture": "arm64",
      "CodeBuildServiceRole": "arn:aws:iam::111122223333:role/my-build-role",
      "ComputeType": "BUILD_GENERAL1_SMALL",
      "TimeoutInMinutes": 30
    }
  }'

Die folgende Anfrage erstellt das Image mit Cloud Native Buildpacks anstelle eines Dockerfiles. Die Quelle benötigt kein Dockerfile und der Builder bestimmt, wie das Image zusammengestellt wird. Die Anfrage wird weggelassenArchitecture, sodass Elastic Beanstalk dafür erstellt. amd64

operation_start=$(date -u +%Y-%m-%dT%H:%M:%SZ)
aws elasticbeanstalk create-application-version \
  --application-name my-app \
  --version-label v1-buildpack \
  --process \
  --source-bundle S3Bucket=my-source-bucket,S3Key=my-app/v1.zip \
  --image-configuration '{
    "Build": {
      "Type": "buildpack",
      "Buildpack": "paketobuildpacks/builder-jammy-base",
      "CodeBuildServiceRole": "arn:aws:iam::111122223333:role/my-build-role"
    }
  }'

Wenn ein Quellpaket-Build erreicht istPROCESSED, können Sie jede dieser Versionen in einer Beanstalk-Cluster-Umgebung bereitstellen, indem Sie die Versionsbezeichnung an CreateEnvironment oder übergebenUpdateEnvironment, wie bei einer Beanstalk Standard-Anwendungsversion. Informationen zur Konfiguration der Umgebung, in der es ausgeführt wird, finden Sie unter. Konfigurieren von Elastic-Beanstalk-Umgebungen

Anwendungsversionen löschen und wiederherstellen

Die Richtlinien für den Lebenszyklus von Anwendungsversionen löschen keine Beanstalk Cluster-Anwendungsversionen. Wird verwendetDeleteApplicationVersion, um einen Datensatz für eine Anwendungsversion zu entfernen. Elastic Beanstalk lehnt die Anfrage ab, solange die Version verfügbar ist. Warten SieBUILDING, bis der Status der Terminalverarbeitung vorliegt, bevor Sie sie löschen.

Bei einer Beanstalk Cluster-Anwendungsversion löscht die DeleteSourceBundle Option das Quellpaket nicht aus Amazon S3. Source-object Die Aufbewahrung wird separat verwaltet.

DeleteApplicationVersionentfernt den Eintrag zur Elastic Beanstalk-Anwendungsversion. Es löscht kein von uns bereitgestelltes ImageImageConfiguration.Source, kein von einem Quell-Build erstelltes Image oder das Amazon ECR-Repository, das das Image enthält. Sie verwalten die Aufbewahrung eines von Ihnen bereitgestellten Images. Wenn Elastic Beanstalk ein Amazon ECR-Repository für Quell-Builds erstellt, wendet es eine Lebenszyklusrichtlinie auf dieses Repository an. Das Löschen einer Anwendungsversion führt nicht zu einer sofortigen Image- oder Repository-Bereinigung.

Eine quellenbasierte Version im Status kann nicht bereitgestellt werden. FAILED Korrigieren Sie die Quell- oder Build-Konfiguration und rufen Sie CreateApplicationVersion mit einer neuen Versionsbezeichnung auf und Process setzen Sie sie auf. true Um das Label der fehlgeschlagenen Version wiederzuverwenden, löschen Sie zunächst den Versionsdatensatz, nachdem er gelöscht wurdeBUILDING, und erstellen Sie dann die korrigierte Version.