Amazon CodeCatalyst ist nicht mehr offen für Neukunden. Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter [Wie migriert man von CodeCatalyst](migration.md).
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.
# Konfiguration von Compute- und Runtime-Images
In einem CodeCatalyst Workflow können Sie das Image der Rechen- und Laufzeitumgebung angeben, das zur Ausführung von Workflow-Aktionen CodeCatalyst verwendet wird.
*Compute* bezieht sich auf die Rechenengine (die CPU, den Arbeitsspeicher und das Betriebssystem), die CodeCatalyst zur Ausführung von Workflow-Aktionen verwaltet und gewartet wird.
**Anmerkung**
Wenn Compute als Eigenschaft des Workflows definiert ist, kann es nicht als Eigenschaft einer Aktion in diesem Workflow definiert werden. Ebenso kann Compute, wenn es als Eigenschaft einer Aktion definiert ist, nicht im Workflow definiert werden.
Ein *Laufzeitumgebungs-Image* ist ein Docker-Container, in dem Workflow-Aktionen CodeCatalyst ausgeführt werden. Der Docker-Container wird auf der von Ihnen ausgewählten Rechenplattform ausgeführt und umfasst ein Betriebssystem und zusätzliche Tools, die für eine Workflow-Aktion möglicherweise erforderlich sind, z. B. Node.js und .tar. AWS CLI
**Topics**
+ [Berechnungstypen](#compute.types)
+ [Flotten berechnen](#compute.fleets)
+ [Eigenschaften von On-Demand-Flotten](#compute.on-demand)
+ [Eigenschaften von bereitgestellten Flotten](#compute.provisioned-fleets)
+ [Eine bereitgestellte Flotte erstellen](projects-create-compute-resource.md)
+ [Eine bereitgestellte Flotte bearbeiten](edit-compute-resource.md)
+ [Löschen einer bereitgestellten Flotte](delete-compute-resource.md)
+ [Zuweisen einer Flotte oder Rechenleistung zu einer Aktion](workflows-assign-compute-resource.md)
+ [Rechenleistung für mehrere Aktionen gemeinsam nutzen](compute-sharing.md)
+ [Angabe von Images für die Laufzeitumgebung](build-images.md)
## Berechnungstypen
CodeCatalyst bietet die folgenden Berechnungstypen:
+ Amazon EC2
+ AWS Lambda
Amazon EC2 bietet optimierte Flexibilität bei Aktionsläufen und Lambda bietet optimierte Startgeschwindigkeiten von Aktionen. Lambda unterstützt aufgrund einer geringeren Startlatenz schnellere Workflow-Aktionsausführungen. Mit Lambda können Sie grundlegende Workflows ausführen, mit denen serverlose Anwendungen mit gemeinsamen Laufzeiten erstellt, getestet und bereitgestellt werden können. Zu diesen Laufzeiten gehören Node.js, Python, Java, .NET und Go. Es gibt jedoch einige Anwendungsfälle, die Lambda nicht unterstützt, und wenn sie Sie betreffen, verwenden Sie den Amazon EC2 EC2-Compute-Typ:
+ Lambda unterstützt keine Laufzeitumgebungsbilder aus einer bestimmten Registrierung.
+ Lambda unterstützt keine Tools, für die Root-Rechte erforderlich sind. Verwenden Sie für Tools wie `yum` oder `rpm` den Datentyp Amazon EC2 oder andere Tools, für die keine Root-Rechte erforderlich sind.
+ Lambda unterstützt keine Docker-Builds oder -Läufe. Die folgenden Aktionen, die Docker-Images verwenden, werden nicht unterstützt: AWS CloudFormation Stack bereitstellen, In Amazon ECS bereitstellen, Veröffentlichen in Amazon S3, AWS CDK Bootstrap, AWS CDK Bereitstellen, AWS Lambda Aufrufen und Aktionen. GitHub Docker-basierte GitHub Aktionen, die innerhalb CodeCatalyst GitHub der Actions-Aktion ausgeführt werden, werden von Lambda Compute ebenfalls nicht unterstützt. Sie können Alternativen verwenden, für die keine Root-Rechte erforderlich sind, z. B. Podman.
+ Lambda unterstützt das Schreiben in Dateien außerhalb `/tmp` nicht. Bei der Konfiguration Ihrer Workflow-Aktionen können Sie Ihre Tools neu konfigurieren, um sie zu installieren oder in die Sie schreiben möchten. `/tmp` Wenn Sie über eine Build-Aktion verfügen, die installiert wird`npm`, stellen Sie sicher, dass Sie sie für die Installation unter konfigurieren. `/tmp`
+ Lambda unterstützt keine Laufzeiten von mehr als 15 Minuten.
## Flotten berechnen
CodeCatalyst bietet die folgenden Rechenflotten an:
+ On-Demand-Flotten
+ Bereitgestellte Flotten
Bei On-Demand-Flotten stellt der Workflow beim Start einer Workflow-Aktion die benötigten Ressourcen bereit. Die Maschinen werden zerstört, wenn die Aktion abgeschlossen ist. Sie zahlen nur für die Anzahl der Minuten, für die Sie Ihre Aktionen ausführen. On-Demand-Flotten werden vollständig verwaltet und verfügen über automatische Skalierungsfunktionen zur Bewältigung von Nachfragespitzen.
CodeCatalyst bietet auch bereitgestellte Flotten an, die Maschinen enthalten, die von Amazon EC2 betrieben werden und von verwaltet werden. CodeCatalyst Bei bereitgestellten Flotten konfigurieren Sie eine Reihe von dedizierten Maschinen für die Ausführung Ihrer Workflow-Aktionen. Diese Maschinen bleiben im Leerlauf und sind bereit, Aktionen sofort zu verarbeiten. Mit bereitgestellten Flotten sind Ihre Maschinen immer in Betrieb und es fallen Kosten an, solange sie bereitgestellt werden.
**Um eine Flotte zu erstellen, zu aktualisieren oder zu löschen, benötigen Sie die Rolle eines **Space-Administrators oder eines Projektadministrators**.**
## Eigenschaften von On-Demand-Flotten
CodeCatalyst stellt die folgenden On-Demand-Flotten bereit:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/workflows-working-compute.html)
**Anmerkung**
Die Spezifikationen für On-Demand-Flotten variieren je nach Ihrer Abrechnungsstufe. Weitere Informationen finden Sie unter [ – Preise](https://codecatalyst.aws/explore/pricing).
Wenn keine Flotte ausgewählt ist, CodeCatalyst verwendet`Linux.x86-64.Large`.
## Eigenschaften von bereitgestellten Flotten
Eine bereitgestellte Flotte enthält die folgenden Eigenschaften:
**Betriebssystem**
Das Betriebssystem. Die folgenden Betriebssysteme sind verfügbar:
+ Amazon Linux 2
+ Windows Server 2022
**Anmerkung**
Windows-Flotten werden nur in der Build-Aktion unterstützt. Andere Aktionen unterstützen Windows derzeit nicht.
**Architektur**
Die Prozessorarchitektur. Die folgenden Architekturen sind verfügbar:
+ x86\$164
+ Arm64
**Typ der Maschine**
Der Maschinentyp für jede Instanz. Die folgenden Maschinentypen sind verfügbar:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codecatalyst/latest/userguide/workflows-working-compute.html)
**Capacity (Kapazität)**
Die anfängliche Anzahl der Maschinen, die der Flotte zugewiesen wurden. Sie definiert die Anzahl der Aktionen, die parallel ausgeführt werden können.
**Skalierungsmodus**
Definiert das Verhalten, wenn die Anzahl der Aktionen die Flottenkapazität überschreitet.
**Stellen Sie bei Bedarf zusätzliche Kapazität bereit**
Zusätzliche Maschinen werden bei Bedarf eingerichtet, die bei Ausführung neuer Aktionen automatisch hochskaliert werden und nach Abschluss der Aktionen wieder auf die Basiskapazität herunterskaliert werden. Dadurch können zusätzliche Kosten entstehen, da Sie für jeden laufenden Computer minutengenau zahlen.
**Warten Sie, bis zusätzliche Flottenkapazität verfügbar ist**
Aktionsläufe werden in eine Warteschlange gestellt, bis eine Maschine verfügbar ist. Dadurch werden zusätzliche Kosten begrenzt, da keine zusätzlichen Maschinen zugewiesen werden.
# Eine bereitgestellte Flotte erstellen
Verwenden Sie die folgenden Anweisungen, um eine bereitgestellte Flotte zu erstellen.
**Anmerkung**
Bereitgestellte Flotten werden nach 2 Wochen Inaktivität deaktiviert. Wenn sie erneut verwendet werden, werden sie automatisch reaktiviert. Diese Reaktivierung kann jedoch zu einer Latenz führen.
**Um eine bereitgestellte Flotte zu erstellen**
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Compute aus.**
1. Wählen Sie **Create Provisioned Fleet** aus.
1. Geben Sie im Textfeld **Name der bereitgestellten Flotte** einen Namen für Ihre Flotte ein.
1. **Wählen Sie im Dropdownmenü Betriebssystem das Betriebssystem aus.**
1. Wählen Sie im Drop-down-Menü **Maschinentyp** den Maschinentyp für Ihre Maschine aus.
1. Geben Sie im Textfeld **Kapazität** die maximale Anzahl von Maschinen in der Flotte ein.
1. Wählen Sie **im Drop-down-Menü Skalierungsmodus** das gewünschte Überlaufverhalten aus. Weitere Informationen zu diesen Feldern finden Sie unter [Eigenschaften von bereitgestellten Flotten](workflows-working-compute.md#compute.provisioned-fleets).
1. Wählen Sie **Erstellen** aus.
Nachdem Sie die bereitgestellte Flotte erstellt haben, können Sie sie einer Aktion zuweisen. Weitere Informationen finden Sie unter [Zuweisen einer Flotte oder Rechenleistung zu einer Aktion](workflows-assign-compute-resource.md).
# Eine bereitgestellte Flotte bearbeiten
Verwenden Sie die folgenden Anweisungen, um eine bereitgestellte Flotte zu bearbeiten.
**Anmerkung**
Bereitgestellte Flotten werden nach 2 Wochen Inaktivität deaktiviert. Wenn sie erneut verwendet werden, werden sie automatisch reaktiviert. Diese Reaktivierung kann jedoch zu einer Latenz führen.
**Um eine bereitgestellte Flotte zu bearbeiten**
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Compute aus.**
1. Wählen Sie in der Liste **Bereitgestellte Flotte** die Flotte aus, die Sie bearbeiten möchten.
1. Wählen Sie **Bearbeiten** aus.
1. Geben Sie im Textfeld **Kapazität** die maximale Anzahl von Maschinen in der Flotte ein.
1. Wählen Sie **im Drop-down-Menü Skalierungsmodus** das gewünschte Überlaufverhalten aus. Weitere Informationen zu diesen Feldern finden Sie unter [Eigenschaften von bereitgestellten Flotten](workflows-working-compute.md#compute.provisioned-fleets).
1. Wählen Sie **Speichern**.
# Löschen einer bereitgestellten Flotte
Verwenden Sie die folgenden Anweisungen, um eine bereitgestellte Flotte zu löschen.
**Um eine bereitgestellte Flotte zu löschen**
**Warnung**
Bevor Sie eine bereitgestellte Flotte löschen, entfernen Sie sie aus allen Aktionen, indem Sie die `Fleet` Eigenschaft aus dem YAML-Code der Aktion löschen. Jede Aktion, die nach dem Löschen weiterhin auf eine bereitgestellte Flotte verweist, schlägt fehl, wenn die Aktion das nächste Mal ausgeführt wird.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Compute aus.**
1. Wählen Sie in der Liste **Bereitgestellte Flotte** die Flotte aus, die Sie löschen möchten.
1. Wählen Sie **Löschen** aus.
1. Geben Sie ein**delete**, um den Löschvorgang zu bestätigen.
1. Wählen Sie **Löschen** aus.
# Zuweisen einer Flotte oder Rechenleistung zu einer Aktion
Standardmäßig verwenden Workflow-Aktionen die `Linux.x86-64.Large` On-Demand-Flotte mit einem Amazon EC2 EC2-Berechnungstyp. Wenn Sie stattdessen eine bereitgestellte Flotte oder eine andere On-Demand-Flotte verwenden möchten`Linux.x86-64.2XLarge`, verwenden Sie beispielsweise die folgenden Anweisungen.
------
#### [ Visual ]
**Bevor Sie beginnen**
+ Wenn Sie eine bereitgestellte Flotte zuweisen möchten, müssen Sie zuerst die bereitgestellte Flotte erstellen. Weitere Informationen finden Sie unter [Eine bereitgestellte Flotte erstellen](projects-create-compute-resource.md).
**Um einer Aktion eine bereitgestellte Flotte oder einen anderen Flottentyp zuzuweisen**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie **Visual**.
1. Wählen Sie im Workflow-Diagramm die Aktion aus, der Sie Ihre bereitgestellte Flotte oder Ihren neuen Flottentyp zuweisen möchten.
1. Wählen Sie die Registerkarte **Konfiguration** aus.
1. Gehen **Sie in Compute Fleet** wie folgt vor:
Geben Sie die Maschine oder Flotte an, auf der Ihr Workflow oder Ihre Workflow-Aktionen ausgeführt werden sollen. Bei bedarfsgesteuerten Flotten stellt der Workflow zu Beginn einer Aktion die benötigten Ressourcen bereit, und die Maschinen werden zerstört, wenn die Aktion abgeschlossen ist. Beispiele für Flotten auf Abruf:`Linux.x86-64.Large`,. `Linux.x86-64.XLarge` Weitere Informationen zu Flotten auf Abruf finden Sie unter. [Eigenschaften von On-Demand-Flotten](workflows-working-compute.md#compute.on-demand)
Bei bereitgestellten Flotten konfigurieren Sie eine Reihe von dedizierten Maschinen, um Ihre Workflow-Aktionen auszuführen. Diese Maschinen bleiben inaktiv und sind bereit, Aktionen sofort zu verarbeiten. Weitere Informationen zu bereitgestellten Flotten finden Sie unter. [Eigenschaften von bereitgestellten Flotten](workflows-working-compute.md#compute.provisioned-fleets)
Wenn `Fleet` es weggelassen wird, ist die Standardeinstellung. `Linux.x86-64.Large`
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit** aus.
------
#### [ YAML ]
**Bevor Sie beginnen**
+ Wenn Sie eine bereitgestellte Flotte zuweisen möchten, müssen Sie zuerst die bereitgestellte Flotte erstellen. Weitere Informationen finden Sie unter [Eine bereitgestellte Flotte erstellen](projects-create-compute-resource.md).
**Um einer Aktion eine bereitgestellte Flotte oder einen anderen Flottentyp zuzuweisen**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie **YAML.**
1. Suchen Sie die Aktion, der Sie Ihre bereitgestellte Flotte oder Ihren neuen Flottentyp zuweisen möchten.
1. Fügen Sie in der Aktion eine `Compute` Eigenschaft hinzu und legen Sie `Fleet` sie auf den Namen Ihrer Flotte oder Ihres On-Demand-Flottentyps fest. Weitere Informationen finden Sie in der Beschreibung der `Fleet` Immobilie im Abschnitt [Aktionen erstellen und testen YAML](build-action-ref.md) Für Ihre Aktion.
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit** aus.
------
# Rechenleistung für mehrere Aktionen gemeinsam nutzen
Standardmäßig werden Aktionen in einem Workflow auf separaten Instanzen in einer [Flotte](workflows-working-compute.md#compute.fleets) ausgeführt. Dieses Verhalten sorgt für isolierte und vorhersehbare Aktionen in Bezug auf den Status der Eingaben. Das Standardverhalten erfordert eine explizite Konfiguration, um Kontext wie Dateien und Variablen zwischen Aktionen gemeinsam zu nutzen.
Compute Sharing ist eine Funktion, mit der Sie alle Aktionen in einem Workflow auf derselben Instanz ausführen können. Die Nutzung von Compute Sharing kann zu schnelleren Workflow-Laufzeiten führen, da weniger Zeit für die Bereitstellung von Instanzen aufgewendet wird. Sie können Dateien (Artefakte) auch ohne zusätzliche Workflow-Konfiguration zwischen Aktionen gemeinsam nutzen.
Wenn ein Workflow mithilfe von Compute Sharing ausgeführt wird, ist eine Instanz in der Standardflotte oder in der angegebenen Flotte für die Dauer aller Aktionen in diesem Workflow reserviert. Wenn der Workflow-Lauf abgeschlossen ist, wird die Instanzreservierung freigegeben.
**Topics**
+ [Mehrere Aktionen auf gemeinsam genutztem Computer ausführen](#how-to-compute-share)
+ [Überlegungen zur gemeinsamen Nutzung von Rechenleistung](#compare-compute-sharing)
+ [Compute Sharing einschalten](#compute-sharing-steps)
+ [Beispiele](#compute-sharing-examples)
## Mehrere Aktionen auf gemeinsam genutztem Computer ausführen
Sie können das `Compute` Attribut in der Definition YAML auf Workflow-Ebene verwenden, um sowohl die Flotten- als auch die Compute-Sharing-Eigenschaften von Aktionen anzugeben. Sie können Computing-Eigenschaften auch mit dem Visual Editor in CodeCatalyst konfigurieren. Um eine Flotte anzugeben, legen Sie den Namen einer vorhandenen Flotte fest, legen Sie den Berechnungstyp auf **EC2**fest und aktivieren Sie die gemeinsame Nutzung von Rechenressourcen.
**Anmerkung**
Compute Sharing wird nur unterstützt, wenn der Compute-Typ auf eingestellt ist **EC2**, und sie wird für das Betriebssystem Windows Server 2022 nicht unterstützt. Weitere Informationen zu Rechenflotten, Compute-Typen und Eigenschaften finden Sie unter[Konfiguration von Compute- und Runtime-Images](workflows-working-compute.md).
**Anmerkung**
Wenn Sie das kostenlose Kontingent nutzen und die `Linux.x86-64.2XLarge` Flotte `Linux.x86-64.XLarge` oder manuell in der Workflow-Definition YAML angeben, wird die Aktion trotzdem auf der Standardflotte () `Linux.x86-64.Large` ausgeführt. Weitere Informationen zur Verfügbarkeit von Rechenleistung und zu den Preisen finden Sie in der [Tabelle mit den Tarifoptionen](https://codecatalyst.aws/explore/pricing).
Wenn Compute Sharing aktiviert ist, wird der Ordner, der die Workflow-Quelle enthält, automatisch in alle Aktionen kopiert. Sie müssen keine Ausgabeartefakte konfigurieren und sie in einer Workflow-Definition (YAML-Datei) nicht als Eingabeartefakte referenzieren. Als Workflow-Autor müssen Sie Umgebungsvariablen mithilfe von Eingaben und Ausgaben verknüpfen, genau wie Sie es ohne Compute Sharing tun würden. Wenn Sie Ordner für Aktionen außerhalb der Workflow-Quelle gemeinsam nutzen möchten, sollten Sie das Zwischenspeichern von Dateien in Betracht ziehen. Weitere Informationen erhalten Sie unter [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md) und [Zwischenspeichern von Dateien zwischen Workflow-Läufen](workflows-caching.md).
Das Quell-Repository, in dem sich Ihre Workflow-Definitionsdatei befindet, ist anhand der Bezeichnung gekennzeichnet. `WorkflowSource` Wenn Sie Compute Sharing verwenden, wird die Workflow-Quelle in der ersten Aktion heruntergeladen, die darauf verweist, und automatisch für nachfolgende Aktionen im Workflow-Lauf zur Verfügung gestellt. Alle Änderungen, die durch eine Aktion an dem Ordner, der die Workflow-Quelle enthält, vorgenommen werden, z. B. durch Hinzufügen, Ändern oder Entfernen von Dateien, sind auch in den nachfolgenden Aktionen im Workflow sichtbar. Sie können in jeder Ihrer Workflow-Aktionen auf Dateien verweisen, die sich im Workflow-Quellordner befinden, genauso wie Sie es ohne Compute Sharing tun können. Weitere Informationen finden Sie unter [Quell-Repository-Dateien referenzieren](workflows-sources-reference-files.md).
**Anmerkung**
Compute-Sharing-Workflows müssen eine strikte Reihenfolge von Aktionen angeben, sodass parallel Aktionen nicht festgelegt werden können. Ausgabeartefakte können zwar bei jeder Aktion in der Sequenz konfiguriert werden, Eingabeartefakte werden jedoch nicht unterstützt.
## Überlegungen zur gemeinsamen Nutzung von Rechenleistung
Sie können Workflows mit Compute Sharing ausführen, um Workflow-Ausführungen zu beschleunigen und den Kontext zwischen Aktionen in einem Workflow, die dieselbe Instanz verwenden, gemeinsam zu nutzen. Beachten Sie Folgendes, um festzustellen, ob die Nutzung von Compute Sharing für Ihr Szenario geeignet ist:
| | Compute-Sharing | Ohne gemeinsame Nutzung von Rechenleistung |
| --- | --- | --- |
| Datenverarbeitung | Amazon EC2 | Amazon EC2, AWS Lambda |
| Bereitstellung von Instanzen | Aktionen werden auf derselben Instanz ausgeführt | Aktionen werden auf separaten Instanzen ausgeführt |
| Betriebssystem | Amazon Linux 2 | Amazon Linux 2, Windows Server 2022 (nur Build-Aktion) |
| Dateien referenzieren | `$CATALYST_SOURCE_DIR_WorkflowSource`, `/sources/WorkflowSource/` | `$CATALYST_SOURCE_DIR_WorkflowSource`, `/sources/WorkflowSource/` |
| Workflow-Struktur | Aktionen können nur sequentiell ausgeführt werden | Aktionen können parallel ausgeführt werden |
| Zugreifen auf Daten über Workflow-Aktionen hinweg | Greifen Sie auf die zwischengespeicherte Workflow-Quelle zu () `WorkflowSource` | Greifen Sie auf Ausgaben gemeinsam genutzter Artefakte zu (erfordert zusätzliche Konfiguration) |
## Compute Sharing einschalten
Gehen Sie wie folgt vor, um Compute Sharing für einen Workflow zu aktivieren.
------
#### [ Visual ]
**Um Compute Sharing mit dem Visual Editor zu aktivieren**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows.
1. Wählen Sie **Edit** (Bearbeiten) aus.
1. Wählen Sie **Visual**.
1. Wählen Sie **Workflow-Eigenschaften**.
1. Wählen Sie aus dem Dropdownmenü **Berechnungstyp** die Option **EC2**.
1. (Optional) Wählen Sie im Dropdownmenü **Compute fleet — optional** eine Flotte aus, die Sie für die Ausführung von Workflow-Aktionen verwenden möchten. Sie können eine On-Demand-Flotte wählen oder eine bereitgestellte Flotte erstellen und auswählen. Weitere Informationen finden Sie unter [Eine bereitgestellte Flotte erstellen](projects-create-compute-resource.md) und [Zuweisen einer Flotte oder Rechenleistung zu einer Aktion](workflows-assign-compute-resource.md)
1. Schalten Sie den Schalter um, um Compute Sharing zu aktivieren und die Aktionen im Workflow auf derselben Flotte ausführen zu lassen.
1. (Optional) Wählen Sie den Ausführungsmodus für den Workflow. Weitere Informationen finden Sie unter [Konfiguration des Warteschlangenverhaltens von Läufen](workflows-configure-runs.md).
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit** aus.
------
#### [ YAML ]
**Um Compute Sharing mit dem YAML-Editor zu aktivieren**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Wählen Sie Ihr Projekt.
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows.
1. Wählen Sie **Edit** (Bearbeiten) aus.
1. Wählen Sie **YAML.**
1. Aktivieren Sie Compute Sharing und setzen Sie das `SharedInstance` Feld auf `TRUE` und `Type` bis`EC2`. Stellen `Fleet` Sie eine Rechenflotte ein, die Sie zum Ausführen von Workflow-Aktionen verwenden möchten. Sie können eine On-Demand-Flotte wählen oder eine bereitgestellte Flotte erstellen und auswählen. Weitere Informationen finden Sie unter [Eine bereitgestellte Flotte erstellen](projects-create-compute-resource.md) und [Zuweisen einer Flotte oder Rechenleistung zu einer Aktion](workflows-assign-compute-resource.md)
Fügen Sie in einem Workflow-YAML Code hinzu, der dem folgenden ähnelt:
```
Name: MyWorkflow
SchemaVersion: "1.0"
Compute: # Define compute configuration.
Type: EC2
Fleet: MyFleet # Optionally, choose an on-demand or provisioned fleet.
SharedInstance: true # Turn on compute sharing. Default is False.
Actions:
BuildFirst:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: ...
...
```
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Festschreiben zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit** aus.
------
## Beispiele
**Topics**
+ [Beispiel: Amazon S3 Publish](#compute-share-s3)
### Beispiel: Amazon S3 Publish
Die folgenden Workflow-Beispiele zeigen, wie Sie die Amazon Amazon S3 S3-Aktion „Veröffentlichen“ auf zwei Arten ausführen können: zuerst mithilfe von Eingabeartefakten und dann mithilfe von Compute Sharing. Bei Compute Sharing werden die Eingabeartefakte nicht benötigt, da Sie auf die zwischengespeicherten `WorkflowSource` zugreifen können. Darüber hinaus wird das Ausgabeartefakt in der Build-Aktion nicht mehr benötigt. Die S3-Aktion „Veröffentlichen“ ist so konfiguriert, dass sie die explizite `DependsOn` Eigenschaft zur Verwaltung sequentieller Aktionen verwendet. Die Build-Aktion muss erfolgreich ausgeführt werden, damit die S3-Aktion „Veröffentlichen“ ausgeführt werden kann.
+ Ohne Compute-Sharing müssen Sie Eingabeartefakte verwenden und die Ausgaben mit nachfolgenden Aktionen teilen:
```
Name: S3PublishUsingInputArtifact
SchemaVersion: "1.0"
Actions:
Build:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ArtifactToPublish
Files: [output.zip]
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: ./build.sh # Build script that generates output.zip
PublishToS3:
Identifier: aws/s3-publish@v1
Inputs:
Artifacts:
- ArtifactToPublish
Environment:
Connections:
- Role: codecatalyst-deployment-role
Name: dev-deployment-role
Name: dev-connection
Configuration:
SourcePath: output.zip
DestinationBucketName: amzn-s3-demo-bucket
```
+ Wenn Sie Compute Sharing mit der Einstellung `SharedInstance` auf verwenden`TRUE`, können Sie mehrere Aktionen auf derselben Instanz ausführen und Artefakte gemeinsam nutzen, indem Sie eine einzige Workflow-Quelle angeben. Eingabeartefakte sind nicht erforderlich und können nicht angegeben werden:
```
Name: S3PublishUsingComputeSharing
SchemaVersion: "1.0"
Compute:
Type: EC2
Fleet: dev-fleet
SharedInstance: TRUE
Actions:
Build:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: ./build.sh # Build script that generates output.zip
PublishToS3:
Identifier: aws/s3-publish@v1
DependsOn:
- Build
Environment:
Connections:
- Role: codecatalyst-deployment-role
Name: dev-deployment-role
Name: dev-connection
Configuration:
SourcePath: output.zip
DestinationBucketName: amzn-s3-demo-bucket
```
# Angabe von Images für die Laufzeitumgebung
Ein *Laufzeitumgebungs-Image* ist ein Docker-Container, in dem Workflow-Aktionen CodeCatalyst ausgeführt werden. Der Docker-Container wird auf der von Ihnen ausgewählten Rechenplattform ausgeführt und umfasst ein Betriebssystem und zusätzliche Tools, die für eine Workflow-Aktion möglicherweise erforderlich sind, z. B. Node.js und .tar. AWS CLI
Standardmäßig werden Workflow-Aktionen auf einem der [aktiven Images](#build-curated-images) ausgeführt, die von bereitgestellt und verwaltet werden. CodeCatalyst Nur Build- und Testaktionen unterstützen benutzerdefinierte Images. Weitere Informationen finden Sie unter [Zuweisen eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung zu einer Aktion](#build-images-specify).
**Topics**
+ [Aktive Bilder](#build-curated-images)
+ [Was ist, wenn ein aktives Bild nicht die Tools enthält, die ich benötige?](#build-images-more-tools)
+ [Zuweisen eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung zu einer Aktion](#build-images-specify)
+ [Beispiele](#workflows-working-custom-image-ex)
## Aktive Bilder
*Aktive Images* sind Runtime-Umgebungs-Images, die vollständig von Tools unterstützt werden CodeCatalyst und vorinstallierte Tools enthalten. Derzeit gibt es zwei Gruppen aktiver Images: eines wurde im März 2024 veröffentlicht, das andere wurde im November 2022 veröffentlicht.
Ob für eine Aktion ein Bild vom März 2024 oder vom November 2022 verwendet wird, hängt von der Aktion ab:
+ Build- und Testaktionen, die am oder nach dem 26. März 2024 zu einem Workflow hinzugefügt werden, enthalten in ihrer YAML-Definition einen `Container` Abschnitt, der explizit ein [Bild vom März 2024](#build.default-image) spezifiziert. Sie können den `Container` Abschnitt optional entfernen, um zum Bild vom [November 2022](#build.previous-image) zurückzukehren.
+ Build- und Testaktionen, die vor dem 26. März 2024 zu einem Workflow hinzugefügt wurden, enthalten *keinen* `Container` Abschnitt in ihrer YAML-Definition und verwenden daher ein Image [vom November 2022](#build.previous-image). Sie können das Image vom November 2022 behalten oder es aktualisieren. Um das Image zu aktualisieren, öffnen Sie die Aktion im Visual Editor, wählen Sie die Registerkarte **Konfiguration** und wählen Sie dann das Bild vom März 2024 aus der Dropdownliste **Docker-Image der Laufzeitumgebung** aus. Durch diese Auswahl wird der YAML-Definition der Aktion ein `Container` Abschnitt hinzugefügt, der mit dem entsprechenden Bild vom März 2024 gefüllt ist.
+ Für alle anderen Aktionen wird entweder ein Bild [vom November 2022 oder ein Bild](#build.previous-image) [vom März 2024](#build.default-image) verwendet. Weitere Informationen finden Sie in der Dokumentation der Aktion.
**Topics**
+ [Bilder vom März 2024](#build.default-image)
+ [Bilder vom November 2022](#build.previous-image)
### Bilder vom März 2024
Die Bilder vom März 2024 sind die neuesten Bilder, die von bereitgestellt wurden CodeCatalyst. Pro type/fleet Rechenkombination gibt es ein Bild vom März 2024.
Die folgende Tabelle zeigt die Tools, die auf jedem Image vom März 2024 installiert sind.
**Image-Tools vom März 2024**
| Tool | CodeCatalyst Amazon EC2 für Linux x86\$164 - `CodeCatalystLinux_x86_64:2024_03` | CodeCatalyst Lambda für Linux x86\$164 - `CodeCatalystLinuxLambda_x86_64:2024_03` | CodeCatalyst Amazon EC2 für Linux Arm64 - `CodeCatalystLinux_Arm64:2024_03` | CodeCatalyst Lambda für Linux Arm64 - `CodeCatalystLinuxLambda_Arm64:2024_03` |
| --- | --- | --- | --- | --- |
| AWS CLI | 2.15.17 | 2,15,17 | 2,15,17 | 2,15,17 |
| AWS Copilot CLI | 1.32.1 | 1,32,1 | 1,32,1 | 1,32,1 |
| Docker | 24,9 | – | 24,9 | – |
| Docker Compose | 2.23.3 | – | 2.23.3 | – |
| Git | 2,43,0 | 2,43,0 | 2,43,0 | 2,43,0 |
| Go | 1,21,5 | 1,21,5 | 1,21,5 | 1,21,5 |
| Gradle | 8,5 | 8,5 | 8,5 | 8,5 |
| Java | Korretto 17 | Korretto 17 | Korretto 17 | Korretto 17 |
| Maven | 3.9.6 | 3.9.6 | 3.9.6 | 3.9.6 |
| Node.js | 18,19,0 | 18,19,0 | 18,19,0 | 18,19,0 |
| NPM | 10.2.3 | 10.2.3 | 10.2.3 | 10.2.3 |
| Python | 3.9,18 | 3.9,18 | 3.9,18 | 3.9,18 |
| Python3 | 3.11,6 | 3.11.6 | 3.11.6 | 3.11.6 |
| pip | 22.3.1 | 22.3.1 | 22.3.1 | 22.3.1 |
| .NET | 8.0.100 | 8,0,100 | 8,0,100 | 8,0,100 |
### Bilder vom November 2022
Pro type/fleet Rechenkombination gibt es ein Bild vom November 2022. Es ist auch ein Windows-Image vom November 2022 mit der Build-Aktion verfügbar, wenn Sie eine [bereitgestellte Flotte](workflows-working-compute.md#compute.fleets) konfiguriert haben.
In der folgenden Tabelle sind die Tools aufgeführt, die auf den einzelnen Images vom November 2022 installiert sind.
**Image-Tools für November 2022**
| Tool | CodeCatalyst Amazon EC2 für Linux x86\$164 - `CodeCatalystLinux_x86_64:2022_11` | CodeCatalyst Lambda für Linux x86\$164 - `CodeCatalystLinuxLambda_x86_64:2022_11` | CodeCatalyst Amazon EC2 für Linux Arm64 - `CodeCatalystLinux_Arm64:2022_11` | CodeCatalyst Lambda für Linux Arm64 - `CodeCatalystLinuxLambda_Arm64:2022_11` | CodeCatalyst Amazon EC2 für Windows x86\$164 - `CodeCatalystWindows_x86_64:2022_11` |
| --- | --- | --- | --- | --- | --- |
| AWS CLI | 2.15,17 | 2,15,17 | 2,15,17 | 2,15,17 | 2.13,19 |
| AWS Copilot CLI | 0.6.0 | 0.6.0 | – | – | 1.30.1 |
| Docker | 23,01 | – | 23,0,1 | – | – |
| Docker Compose | 2.16.0 | – | 2.16.0 | – | – |
| Git | 2.40.0 | 2.40.0 | 2,39,2 | 2,39,2 | 2,42,0 |
| Go | 1.20.2 | 1.20.2 | 1,20,1 | 1,20,1 | 1,19 |
| Gradle | 8.0.2 | 8.0.2 | 8.0.1 | 8.0.1 | 8.3 |
| Java | Korretto 17 | Korretto 17 | Korretto 17 | Korretto 17 | Korretto 17 |
| Maven | 3.9.4 | 3.9.4 | 3.9.0 | 3.9.0 | 3.9.4 |
| Node.js | 16.20,2 | 16,20,2 | 16,19,1 | 16,14,2 | 16,20,0 |
| NPM | 8.19,4 | 8.19,4 | 8.19,3 | 8.5.0 | 8.19,4 |
| Python | 3.9,15 | 2.7,18 | 3.11.2 | 2.7.18 | 3.9.13 |
| Python3 | – | 3.9,15 | – | 3.11.2 | – |
| pip | 22.2.2 | 22.2.2 | 23.0.1 | 23.0.1 | 22.0.4 |
| .NET | 6,0,407 | 6,0,407 | 6,0,406 | 6,0,406 | 6,0,414 |
## Was ist, wenn ein aktives Bild nicht die Tools enthält, die ich benötige?
Wenn keines der von Ihnen bereitgestellten [aktiven Bilder](#build-curated-images) die Tools CodeCatalyst enthält, die Sie benötigen, haben Sie mehrere Optionen:
+ Sie können ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung bereitstellen, das die erforderlichen Tools enthält. Weitere Informationen finden Sie unter [Zuweisen eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung zu einer Aktion](#build-images-specify).
**Anmerkung**
Wenn Sie ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung bereitstellen möchten, stellen Sie sicher, dass in Ihrem benutzerdefinierten Image Git installiert ist.
+ Sie können die Build- oder Testaktion Ihres Workflows die Tools installieren lassen, die Sie benötigen.
Sie könnten beispielsweise die folgenden Anweisungen in den `Steps` Abschnitt des YAML-Codes der Build- oder Testaktion aufnehmen:
```
Configuration:
Steps:
- Run: ./setup-script
```
Die *setup-script* Anweisung würde dann das folgende Skript ausführen, um den Node-Paketmanager (npm) zu installieren:
```
#!/usr/bin/env bash
echo "Setting up environment"
touch ~/.bashrc
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | bash
source ~/.bashrc
nvm install v16.1.0
source ~/.bashrc
```
Weitere Hinweise zur Build-Aktion YAML finden Sie unter. [Aktionen erstellen und testen YAML](build-action-ref.md)
## Zuweisen eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung zu einer Aktion
Wenn Sie kein von bereitgestelltes [Active-Image](#build-curated-images) verwenden möchten CodeCatalyst, können Sie ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung bereitstellen. Wenn du ein benutzerdefiniertes Image bereitstellen möchtest, stelle sicher, dass Git darin installiert ist. Das Image kann sich in Docker Hub, Amazon Elastic Container Registry oder einem beliebigen öffentlichen Repository befinden.
Informationen zum Erstellen eines benutzerdefinierten Docker-Images finden Sie unter [Containerisieren einer Anwendung](https://docs.docker.com/get-started/02_our_app/) in der Docker-Dokumentation.
Verwenden Sie die folgenden Anweisungen, um Ihr benutzerdefiniertes Docker-Image für die Laufzeitumgebung einer Aktion zuzuweisen. Nachdem Sie ein Image angegeben haben, CodeCatalyst wird es auf Ihrer Rechenplattform bereitgestellt, wenn die Aktion gestartet wird.
**Anmerkung**
Die folgenden Aktionen unterstützen keine Docker-Images für benutzerdefinierte Laufzeitumgebungen: **Deploy CloudFormation Stack**, **Deploy to ECS** und **GitHub Actions**. Docker-Images für benutzerdefinierte Laufzeitumgebungen unterstützen auch nicht den Compute-Typ **Lambda**.
------
#### [ Visual ]
**So weisen Sie mit dem Visual Editor ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung zu**
1. Öffnen Sie die CodeCatalyst Konsole unter [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie **Visual**.
1. Wählen Sie im Workflow-Diagramm die Aktion aus, die Ihr benutzerdefiniertes Docker-Image für die Laufzeitumgebung verwenden soll.
1. Wählen Sie die Registerkarte **Konfiguration** aus.
1. Füllen Sie unten die folgenden Felder aus.
**Docker-Image für die Laufzeitumgebung — optional**
Geben Sie die Registrierung an, in der Ihr Image gespeichert ist. Gültige Werte sind:
+ `CODECATALYST`(YAML-Editor)
Das Bild wird in der CodeCatalyst Registrierung gespeichert.
+ **Docker Hub** (visueller Editor) oder `DockerHub` (YAML-Editor)
Das Bild wird in der Docker Hub-Image-Registry gespeichert.
+ **Andere Registrierung** (visueller Editor) oder `Other` (YAML-Editor)
Das Bild wird in einer benutzerdefinierten Bildregistrierung gespeichert. Jede öffentlich verfügbare Registrierung kann verwendet werden.
+ **Amazon Elastic Container Registry** (visueller Editor) oder `ECR` (YAML-Editor)
Das Bild wird in einem Image-Repository der Amazon Elastic Container Registry gespeichert. Um ein Bild in einem Amazon ECR-Repository zu verwenden, benötigt diese Aktion Zugriff auf Amazon ECR. Um diesen Zugriff zu aktivieren, müssen Sie eine [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) erstellen, die die folgenden Berechtigungen und eine benutzerdefinierte Vertrauensrichtlinie umfasst. (Sie können eine bestehende Rolle so ändern, dass sie die Berechtigungen und die Richtlinie einbezieht, wenn Sie möchten.)
Die IAM-Rolle muss die folgenden Berechtigungen in ihrer Rollenrichtlinie enthalten:
+ `ecr:BatchCheckLayerAvailability`
+ `ecr:BatchGetImage`
+ `ecr:GetAuthorizationToken`
+ `ecr:GetDownloadUrlForLayer`
Die IAM-Rolle muss die folgende benutzerdefinierte Vertrauensrichtlinie enthalten:
Weitere Informationen zum Erstellen von IAM-Rollen finden Sie unter [Erstellen einer Rolle mithilfe benutzerdefinierter Vertrauensrichtlinien (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) im *IAM-Benutzerhandbuch*.
Nachdem Sie die Rolle erstellt haben, müssen Sie sie der Aktion über eine Umgebung zuweisen. Weitere Informationen finden Sie unter [Eine Umgebung mit einer Aktion verknüpfen](deploy-environments-add-app-to-environment.md).
**ECR-Bild-URL****, **Docker Hub-Bild oder Bild-URL****
Geben Sie eines der folgenden Elemente an:
+ Wenn Sie eine `CODECATALYST` Registrierung verwenden, legen Sie für das Image eines der folgenden [aktiven](#build-curated-images) Images fest:
+ `CodeCatalystLinux_x86_64:2024_03`
+ `CodeCatalystLinux_x86_64:2022_11`
+ `CodeCatalystLinux_Arm64:2024_03`
+ `CodeCatalystLinux_Arm64:2022_11`
+ `CodeCatalystLinuxLambda_x86_64:2024_03`
+ `CodeCatalystLinuxLambda_x86_64:2022_11`
+ `CodeCatalystLinuxLambda_Arm64:2024_03`
+ `CodeCatalystLinuxLambda_Arm64:2022_11`
+ `CodeCatalystWindows_x86_64:2022_11`
+ Wenn Sie eine Docker Hub-Registry verwenden, legen Sie für das Image den Namen des Docker Hub-Images und das optionale Tag fest.
Beispiel: `postgres:latest`
+ Wenn Sie eine Amazon ECR-Registrierung verwenden, setzen Sie das Bild auf die Amazon ECR-Registrierungs-URI.
Beispiel: `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo`
+ Wenn Sie eine benutzerdefinierte Registrierung verwenden, setzen Sie das Bild auf den Wert, der von der benutzerdefinierten Registrierung erwartet wird.
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit**.
------
#### [ YAML ]
**Um mit dem YAML-Editor ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung zuzuweisen**
1. **Wählen Sie im Navigationsbereich **CI/CD** und dann Workflows aus.**
1. Wählen Sie den Namen Ihres Workflows. Sie können nach dem Quell-Repository oder dem Branch-Namen filtern, in dem der Workflow definiert ist, oder nach Workflow-Namen oder -Status filtern.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie **YAML.**
1. Suchen Sie die Aktion, der Sie ein Docker-Image für die Laufzeitumgebung zuweisen möchten.
1. Fügen Sie in der Aktion einen `Container` Abschnitt und die zugrunde liegenden `Registry` `Image` Eigenschaften hinzu. Weitere Informationen finden Sie in der Beschreibung der `Container` `Registry` und den `Image` Eigenschaften in der [Aktionen](workflow-reference.md#actions-reference) Für Ihre Aktion.
1. (Optional) Wählen Sie „**Validieren**“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.
1. Wählen Sie **Commit**, geben Sie eine Commit-Nachricht ein und wählen Sie erneut **Commit**.
------
## Beispiele
Die folgenden Beispiele zeigen, wie Sie einer Aktion in der Workflow-Definitionsdatei ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung zuweisen.
**Topics**
+ [Beispiel: Verwenden eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung, um Unterstützung für Node.js 18 mit Amazon ECR hinzuzufügen](#workflows-working-custom-image-ex-ecr-node18)
+ [Beispiel: Verwenden eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung, um Unterstützung für Node.js 18 mit Docker Hub hinzuzufügen](#workflows-working-custom-image-ex-docker-node18)
### Beispiel: Verwenden eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung, um Unterstützung für Node.js 18 mit Amazon ECR hinzuzufügen
Das folgende Beispiel zeigt, wie Sie ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung verwenden, um Unterstützung für Node.js 18 mit [Amazon ECR](https://gallery.ecr.aws/amazonlinux/amazonlinux) hinzuzufügen.
```
Configuration:
Container:
Registry: ECR
Image: public.ecr.aws/amazonlinux/amazonlinux:2023
```
### Beispiel: Verwenden eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung, um Unterstützung für Node.js 18 mit Docker Hub hinzuzufügen
[Das folgende Beispiel zeigt, wie Sie ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung verwenden, um Unterstützung für Node.js 18 mit Docker Hub hinzuzufügen.](https://hub.docker.com/_/node)
```
Configuration:
Container:
Registry: DockerHub
Image: node:18.18.2
```