View a markdown version of this page

Verwaltung von Erstellungs-, Test- und Verteilungs-Workflows für Image Builder-Images - EC2 Image Builder

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.

Verwaltung von Erstellungs-, Test- und Verteilungs-Workflows für Image Builder-Images

Ein Image-Workflow definiert die Abfolge von Schritten, die EC2 Image Builder während einer Phase des Image-Erstellungsprozesses ausführt. Sie erstellen einen Workflow als YAML-Dokument und erstellen ihn als versionierte, wiederverwendbare Ressource. Image Builder führt dann Ihre Workflows aus, wenn es Ihre Bilder erstellt, testet und verteilt.

Workflows geben Ihnen die direkte Kontrolle über den Image-Erstellungsprozess. Sie entscheiden, welche Schritte in welcher Reihenfolge ausgeführt werden, was die einzelnen Schritte tun, wenn sie fehlschlagen, und ob Image Builder einen fehlgeschlagenen Schritt rückgängig macht. Sie können mit einem von Amazon verwalteten Workflow beginnen, ihn klonen und anpassen oder Ihren eigenen von Grund auf neu schreiben.

Vorteile des Image-Workflows
  • Mit Image-Workflows haben Sie mehr Flexibilität, Transparenz und Kontrolle über den Image-Erstellungsprozess.

  • Sie können benutzerdefinierte Workflow-Schritte hinzufügen, wenn Sie Ihr Workflow-Dokument definieren, oder Sie können den Standard-Workflow von Image Builder verwenden.

  • Sie können Workflow-Schritte ausschließen, die Image Builder in Standard-Image-Workflows einschließt.

  • Sie können reine Test-Workflows erstellen, bei denen der Erstellungsprozess vollständig übersprungen wird. Sie können dasselbe tun, um reine Build-Workflows oder reine Distribution-Workflows zu erstellen.

Anmerkung

Sie können einen vorhandenen Workflow nicht ändern, aber Sie können ihn klonen oder eine neue Version erstellen.

Workflow-Framework: Stufen

Image Builder organisiert den Image-Erstellungsprozess in drei Phasen. In jeder Phase wird ein Workflow des passenden Typs ausgeführt. Phasen werden in einer festen Reihenfolge ausgeführt, und eine Phase beginnt erst, nachdem die vorherige Phase erfolgreich abgeschlossen wurde.

In der folgenden Tabelle ist das Standardverhalten der einzelnen Phasen aufgeführt. Da Sie die Schritte in jedem Workflow definieren, können Sie anpassen, was eine Phase tut.

Die Phasen des Image Builder-Workflows

Order

Stage

Workflow-Typ

Was macht es (Standard)

1

Entwicklung

BUILD

Startet eine Build-Instance, führt Ihre Build-Komponenten aus und erstellt ein Image (AMI oder Container-Image) aus der Instance.

2

Test

TEST

Startet eine Testinstanz aus dem neuen Image, führt Ihre Testkomponenten aus und erfasst optional die Ergebnisse des Image-Scans.

3

Verteilung

DISTRIBUTION

Kopiert das Image in die Zielregionen und -konten, ändert die Image-Attribute und wendet Konfigurationen an, die nach der Verteilung vorgenommen wurden, z. B. Startvorlagen und Lizenzkonfigurationen.

Sie können einen Workflow nur für einige Phasen ausführen. Sie können beispielsweise die Build-Phase überspringen, um ein bereits vorhandenes Image zu testen oder zu verteilen, oder die Testphase überspringen, um ohne Tests zu erstellen und zu verteilen. Um die Build- oder Testphase zu überspringen, lassen Sie einen solchen Workflow aus Ihrer Pipeline- oder Image-Anfrage weg.

Anmerkung

Der Verteilungsworkflow ist optional. Wenn Sie ihn weglassen, überspringt Image Builder die Verteilung nicht. Ihr AMI wird trotzdem verteilt, indem er die Verteilungskonfiguration ausführt, die Sie an die Pipeline oder das Image anhängen. Fügen Sie einen Verteilungs-Workflow hinzu, wenn Sie diese Verteilungskonfiguration mit anderen Verteilungseinstellungen überschreiben oder einen besseren Einblick in den Verteilungsprozess erhalten möchten. Um die Verteilung vollständig zu überspringen, geben Sie eine Nullverteilung oder eine leere Verteilungskonfiguration an.

Anmerkung

Eine Image-Pipeline oder eine Image-Anfrage kann höchstens einen Build-Workflow und einen Verteilungs-Workflow umfassen. Sie kann auch einen oder mehrere Test-Workflows enthalten. Die Gesamtzahl der Workflows darf zehn nicht überschreiten. Sie können beispielsweise einen Build-Workflow und einen Verteilungs-Workflow mit bis zu acht Test-Workflows kombinieren.

Wie läuft ein Workflow ab

Ein Workflow führt seine Schritte in der Reihenfolge aus, in der Sie sie im YAML-Dokument definiert haben. Jeder Schritt führt eine Aktion aus, z. B. das Starten einer Instanz oder das Ausführen von Komponenten.

Ergebnisse des Schritts

Jeder Schritt endet in einem der folgenden Zustände.

Ergebnisse der Workflow-Schritte

Status

Bedeutung

COMPLETED

Der Schritt wurde erfolgreich abgeschlossen.

SKIPPED

Eine bedingte if Anweisung für den Schritt ergabfalse, sodass Image Builder den Schritt übersprungen hat.

FAILED

Der Schritt wurde nicht erfolgreich abgeschlossen.

WAITING

Ein WaitForAction Schritt wird angehalten und wartet auf eine externe Aktion.

TIMED_OUT

Der Schritt lief länger als sein Wert. timeoutSeconds

Fehlerbehandlung

Das onFailure Attribut in jedem Schritt steuert, was passiert, wenn ein Schritt fehlschlägt.

  • Abort(Standard) — Image Builder schlägt den Schritt fehl, der Workflow schlägt fehl und führt keine weiteren Schritte aus. Wenn das Rollback aktiviert ist, beginnt das Rollback beim fehlgeschlagenen Schritt und führt die vorherigen Schritte rückwärts durch.

  • Continue— Image Builder schlägt den Schritt fehl, führt aber die verbleibenden Schritte aus. Es findet kein Rollback statt.

Rollback

Wenn ein Schritt mit onFailure: Abort und rollbackEnabled: true (Standardeinstellung) fehlschlägt, macht Image Builder die abgeschlossenen Schritte in umgekehrter Reihenfolge rückgängig, wobei mit dem fehlgeschlagenen Schritt begonnen wird. Nicht jede Aktion kann rückgängig gemacht werden. Für eine Aktion ohne Rollback wird der Status von NO_ROLLBACK aufgezeichnet.

Überwachen Sie die Workflow-Ausführungen mit Amazon EventBridge

Image Builder sendet EventBridge Amazon-Ereignisse aus, während Ihre Workflows ausgeführt werden, sodass Sie auf Fortschritte und Schritte reagieren können, die Ihre Aufmerksamkeit erfordern. Ein WaitForAction Schritt veröffentlicht beispielsweise ein Ereignis mit dem Detailtyp EC2 Image Builder Workflow Step Waiting auf Ihrem Standard-Event-Bus. Sie können dieses Ereignis an ein Ziel wie eine Lambda-Funktion oder ein Amazon SNS-Thema weiterleiten, um einen Genehmigungsprozess einzuleiten. Weitere Informationen zur Funktionsweise von Image Builder finden Sie unter EventBridge. EventBridge Amazon-Integration in Image Builder

Verwenden Sie die API-Operationen,, undGetWorkflowStepExecution, um den ListWorkflowExecutions Fortschritt auf Schrittebene programmgesteuert zu verfolgen. GetWorkflowExecution ListWorkflowStepExecutions

Einschränkungen bei den Workflow-Ressourcen

Ihre Workflow-Dokumente und Konfigurationen müssen innerhalb der folgenden Standardgrenzen bleiben.

Einschränkungen der Workflow-Ressourcen

Einschränkung

Standardlimit

Hinweise

Schritte pro Workflow-Dokument

15

Die Schritte werden in der Reihenfolge der Dokumente ausgeführt.

Ausgaben pro Workflow-Dokument

25

Ausgaben geben Werte an spätere Workflows weiter.

Parameter pro Workflow-Dokument

25

Eingaben, die der Anrufer setzen kann.

Länge des Parameterwerts

1,024 Zeichen

Pro Parameterwert.

Größe des eingebetteten Dokuments (data)

16.000 Byte

Verwenden Sie die Option uri (Amazon S3) für größere Dokumente.

Workflows pro Bild oder Pipeline

10

Höchstens 1 Build und 1 Distribution plus Test-Workflows, insgesamt also 10.

Workflow-Ressourcen sind unveränderlich. Um einen Workflow zu ändern, erstellen Sie eine neue Version oder klonen Sie ihn. Image Builder speichert jede Version, sodass Sie nachvollziehen können, welcher Workflow jedes Bild erzeugt hat.

Zugriff auf Services

Um Image-Workflows ausführen zu können, benötigt Image Builder die Erlaubnis, Workflow-Aktionen auszuführen. Sie gewähren diese Berechtigung mit einer Ausführungsrolle, die Image Builder in Ihrem Namen übernimmt. Sie weisen die Ausführungsrolle wie folgt zu.

Wichtig

Es wird empfohlen, die AWSServiceRoleForImageBuilder dienstgebundene Rolle nicht als Ausführungsrolle zu übergeben. Erstellen Sie stattdessen eine benutzerdefinierte IAM-Rolle und hängen Sie die EC2ImageBuilderExecutionPolicy AWS verwaltete Richtlinie an. Diese Richtlinie gewährt dieselben Berechtigungen, die Image Builder benötigt, um in AWS-Services Ihrem Namen anzurufen. Durch die Verwendung einer benutzerdefinierten Rolle haben Sie die volle Kontrolle über die Berechtigungen, die Image Builder verwendet. Außerdem bleiben Ihre Service Control Policies (SCPs) und Resource Control Policies (RCPs) für Vorgänge gültig, die Image Builder in Ihrem Namen ausführt.

  • Konsole — Wählen Sie im Pipeline-Assistenten Schritt 3 Definieren Sie den Image-Erstellungsprozess und wählen Sie Ihre benutzerdefinierte Rolle aus der IAM-Rollenliste im Bereich Service Access aus.

  • Image Builder-API — Geben Sie in der CreateImage Aktionsanfrage Ihre benutzerdefinierte Rolle als Wert für den executionRole Parameter an.

Informationen zum Erstellen einer benutzerdefinierten Ausführungsrolle finden Sie im AWS Identity and Access Management Benutzerhandbuch unter Erstellen einer Rolle zum Delegieren von Berechtigungen an einen AWS Dienst.

Verwenden Sie verwaltete Workflows für Ihre Bilder

AWS erstellt und verwaltet verwaltete Workflows. Wenn Sie verwaltete Workflows in Ihren Image-Pipelines oder für die einmalige Image-Erstellung verwenden, können Sie den Amazon-Ressourcennamen (ARN) des verwalteten Workflows auswählen, den Sie verwenden möchten. Amazon stellt die neuesten Versionen bereit, auf die Patches und andere Updates angewendet wurden. Eine Liste der verwalteten Workflows finden Sie unter Bild-Workflows auflisten Besitzer = Amazon (Konsole) und filtern Sie danach.

Sie können einen verwalteten Workflow auswählen, der auf Ihrer Build-Geschwindigkeit und Ihren Validierungsanforderungen basiert. Im Folgenden finden Sie Beispiele für verwaltete Workflowtypen:

Verwaltete Standardworkflows (Standard)

Zu den standardmäßig verwalteten Workflows gehören umfassende Schritte zum Erstellen, Testen und Validieren Ihrer Images mit vollständigen EC2-Statusprüfungen.

Im Folgenden finden Sie verwaltete Standardworkflows:

  • build-image — Amazon-managed Standard-AMI-Build-Workflow.

  • test-image — Amazon-managed Standard-AMI-Testworkflow.

  • build-container — Amazon-managed Standardworkflow zum Erstellen von Containern.

  • test-container — Amazon-managed Standardworkflow zum Testen von Containern.

Von Express verwaltete Workflows

Von Express verwaltete Workflows umfassen nur wichtige Schritte und reduzieren die Zeit für die Image-Erstellung.

Bei den folgenden Workflows handelt es sich um per Express verwaltete Workflows:

  • express-build-image — Amazon-managed Express-AMI-Build-Workflow, der die Erstellungszeit reduziert. Wartet nur darauf, dass die Instanz ausgeführt wird, anstatt den EC2-Status vollständig zu überprüfen, und überspringt die Erfassung von Image-Metadaten.

  • express-build-container — Express-Container-Build-Workflow, der die Erstellungszeit Amazon-managed reduziert. Wartet nur darauf, dass die Instanz ausgeführt wird, anstatt den EC2-Status vollständig zu überprüfen.

  • express-test-image — Express-AMI-Testworkflow, der die Amazon-managed Testzeit reduziert. Wartet nur darauf, dass die Instanz ausgeführt wird, anstatt den EC2-Status vollständig zu überprüfen, und überspringt die Erfassung der Ergebnisse der Sicherheitsscans.