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](applications-versions.md) und [Markieren von Anwendungsversionen](applications-versions-tagging.md).
Erstellen Sie für eine Beanstalk Cluster-Bereitstellung die Anwendungsversion mit einer, `ImageConfiguration` die genau eines von zwei Mitgliedern enthält. `Source`identifiziert 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 liefert`SourceBundle`, `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](beanstalk-cluster-getting-started.md#beanstalk-cluster-getting-started-prerequisites).
Bereiten Sie die folgenden Ressourcen vor und greifen Sie darauf zu:
+ Für einen Quell-Build `CodeBuildServiceRole` ist der von erforderlich`ImageConfiguration.Build`. Dies ist die * Image-Build-Rolle der Umgebung*, die von der Elastic Beanstalk-Konsole erstellt wird. `aws-elasticbeanstalk-eks-image-build-role` Informationen zu ihrem vertrauenswürdigen Dienst und ihren Richtlinien sowie zur Rollenbegrenzung finden Sie unter [Rollen, die Sie bereitstellen](beanstalk-cluster-permissions.md#beanstalk-cluster-permissions-customer-roles) und. [Berechtigungen für Beanstalk Cluster](beanstalk-cluster-permissions.md)
+ Für an`ImageConfiguration.Source`: ein Container-Image, das bereits in die Registrierung übertragen wurde. Die von der Umgebung verwendete Knotenrolle muss in der Lage sein, das Image abzurufen. Siehe [Rollen, die Sie bereitstellen](beanstalk-cluster-permissions.md#beanstalk-cluster-permissions-customer-roles).
+ Für einen Quell-Build, a`SourceBundle`, ein Amazon S3-Objekt, das die Anwendungsquelle enthält. Erstellen Sie das Archiv wie unter beschrieben[Erstellen Sie ein Elastic Beanstalk-Anwendungsquellpaket](applications-sourcebundle.md), laden Sie es in einen Amazon S3-Bucket in Ihrem Konto hoch und übergeben Sie den Bucket und den Objektschlüssel als `S3Bucket` und`S3Key`. Stellen Sie `Process` auf ein`true`, um den Build zu starten; andernfalls bleibt die Version erhalten`UNPROCESSED`.
## 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 Feld`Uri`, 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 an`SourceBundle`, 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, und`S3Bucket`. `S3Key` Ein Quellpaket erfordert außerdem einen`ImageConfiguration`, dessen `Build` Mitglied angibt, wie Elastic Beanstalk die Quelle in ein Image konvertiert. `true`In 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](#beanstalk-cluster-app-versions-buildconfig)
**Anmerkung**
Erstellen Sie unter macOS das Quellarchiv mit Daten `zip -X -r ../my-app.zip .` aus dem Quellverzeichnis. Der ** ** Compress-Befehl des Finders fügt `__MACOSX` Metadateneinträge hinzu, und ein Buildpack-Build kann bei einem dieser Einträge fehlschlagen`zip: not a valid zip file`, indem eine Datei benannt wird, die Sie nicht erstellt haben.
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:
+ `CodeBuildServiceRole`, die IAM-Rolle, die AWS CodeBuild davon ausgeht, den Build in Ihrem Konto auszuführen. Dieses Feld ist für einen Quell-Build erforderlich.
+ `ComputeType`, die optionale Größe des Builds compute: `BUILD_GENERAL1_SMALL``BUILD_GENERAL1_MEDIUM`, oder`BUILD_GENERAL1_LARGE`. Wenn Sie es weglassen, wird es von Elastic Beanstalk verwendet. `BUILD_GENERAL1_MEDIUM`
+ `TimeoutInMinutes`, die optionale Anzahl von Minuten, nach der Elastic Beanstalk einen Build stoppt, der noch nicht abgeschlossen ist. Der Wert kann von bis `5` sein. `480` Wenn Sie ihn weglassen, verwendet Elastic Beanstalk Minuten. `60`
Das `Build` Mitglied wählt in seinem `Type` Feld einen von zwei Build-Typen aus, was erforderlich ist:
+ `docker`, Elastic Beanstalk erstellt das Image aus einem Dockerfile in Ihrer Quelle. Auf `DockerfileLocation` den Pfad des Dockerfiles setzen; wenn Sie ihn weglassen, verwendet Elastic Beanstalk das Stammverzeichnis der Quelle. `Dockerfile`
+ `buildpack`, Elastic Beanstalk erstellt das Image mit Cloud Native Buildpacks. Legen Sie beispielsweise `Buildpack` das Builder-Image fest, das der Build verwendet`paketobuildpacks/builder-jammy-base`; Elastic Beanstalk übergibt den Wert wörtlich an den Build. Der Builder ist für einen Buildpack-Build erforderlich. Elastic Beanstalk erkennt keinen für Sie, und ein Buildpack-Build ohne Builder-Set schlägt fehl.
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](command-options-general-eks.md).
## 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 wurde`Process`. Eine Anwendungsversion, die aus einem bereitgestellten Image erstellt wurde`UNPROCESSED`, 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` und`ImageBuildConfiguration`. 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. `BUILDING`bedeutet, 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 ist`FAILED`, 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 Bericht`BuildArn`, 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 einen`logs.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 auf`true`, und fragen Sie sie anschließend auf ab`PROCESSED`. Stellen Sie keine Version in bereit`FAILED`. 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 unter[Erste Schritte mit Beanstalk Cluster](beanstalk-cluster-getting-started.md).
## 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 weggelassen`Architecture`, 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 ist`PROCESSED`, können Sie jede dieser Versionen in einer Beanstalk-Cluster-Umgebung bereitstellen, indem Sie die Versionsbezeichnung an `CreateEnvironment` oder übergeben`UpdateEnvironment`, 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](customize-containers.md)
## Anwendungsversionen löschen und wiederherstellen
Die Richtlinien für den Lebenszyklus von Anwendungsversionen löschen keine Beanstalk Cluster-Anwendungsversionen. Wird verwendet`DeleteApplicationVersion`, um einen Datensatz für eine Anwendungsversion zu entfernen. Elastic Beanstalk lehnt die Anfrage ab, solange die Version verfügbar ist. Warten Sie`BUILDING`, 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.
`DeleteApplicationVersion`entfernt den Eintrag zur Elastic Beanstalk-Anwendungsversion. Es löscht kein von uns bereitgestelltes Image`ImageConfiguration.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 wurde`BUILDING`, und erstellen Sie dann die korrigierte Version.