Docker-Images für die Laufzeitumgebung angeben - Amazon CodeCatalyst
Aktive BilderWas ist, wenn ein aktives Bild nicht die Tools enthält, die ich benötige?Zuweisen eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung zu einer AktionBeispiele

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.

Docker-Images für die Laufzeitumgebung angeben

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 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.

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 spezifiziert. Sie können den Container Abschnitt optional entfernen, um zum Bild vom November 2022 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. 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 ein Bild vom November 2022 verwendet, unabhängig davon, wann sie dem Workflow hinzugefügt wurden. Ein Upgrade dieser Aktionen zur Verwendung eines Images vom März 2024 ist derzeit nicht möglich.

Bilder vom März 2024

Die Bilder vom März 2024 sind die neuesten Bilder, die von bereitgestellt wurden CodeCatalyst. Pro Kombination aus Rechnertyp und Flotte 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_64 - CodeCatalystLinux_x86_64:2024_03 CodeCatalyst Lambda für Linux x86_64 - 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 N/A 24,9 N/A
Docker Compose 2.23.3 N/A 2.23.3 N/A
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 Kombination aus Rechnertyp und Flotte 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 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_64 - CodeCatalystLinux_x86_64:2022_11 CodeCatalyst Lambda für Linux x86_64 - 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_64 - 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 N/A N/A 1.30.1
Docker 23,01 N/A 23,0,1 N/A N/A
Docker Compose 2.16.0 N/A 2.16.0 N/A N/A
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 N/A 3.9,15 N/A 3.11.2 N/A
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 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.

    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. YAML-Definition für Aktionen erstellen und testen

Zuweisen eines Docker-Images für eine benutzerdefinierte Laufzeitumgebung zu einer Aktion

Wenn Sie kein von bereitgestelltes Active-Image verwenden möchten CodeCatalyst, können Sie ein benutzerdefiniertes Docker-Image für die Laufzeitumgebung bereitstellen. Wenn Sie ein benutzerdefiniertes Image bereitstellen möchten, stellen Sie 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 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: AWS CloudFormation Stack bereitstellen, In ECS bereitstellen und GitHub Aktionen. Docker-Images für benutzerdefinierte Laufzeitumgebungen unterstützen auch nicht den Lambda-Compute-Typ.

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/.

  2. Wählen Sie im Navigationsbereich CI/CD und dann Workflows aus.

  3. 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 dem Workflow-Namen filtern.

  4. Wählen Sie Bearbeiten aus.

  5. Wählen Sie Visual.

  6. Wählen Sie im Workflow-Diagramm die Aktion aus, die Ihr benutzerdefiniertes Docker-Image für die Laufzeitumgebung verwenden soll.

  7. Wählen Sie die Registerkarte Konfiguration aus.

  8. 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 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:

      {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service":  [
                   "codecatalyst-runner.amazonaws.com",
                   "codecatalyst.amazonaws.com"
                 ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

      Weitere Informationen zum Erstellen von IAM-Rollen finden Sie unter Erstellen einer Rolle mithilfe benutzerdefinierter Vertrauensrichtlinien (Konsole) im IAM-Benutzerhandbuch.

      Nachdem Sie die Rolle erstellt haben, müssen Sie sie der Aktion über eine Umgebung zuweisen. Weitere Informationen finden Sie unter Einer Workflow-Aktion eine Umgebung, eine Kontoverbindung und eine IAM-Rolle zuordnen.

    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 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.

  9. (Optional) Wählen Sie „Validieren“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.

  10. 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.

  2. 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 dem Workflow-Namen filtern.

  3. Wählen Sie Bearbeiten aus.

  4. Wählen Sie YAML.

  5. Suchen Sie die Aktion, der Sie ein Docker-Image für die Laufzeitumgebung zuweisen möchten.

  6. 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 Für Ihre Aktion.

  7. (Optional) Wählen Sie „Validieren“, um den YAML-Code des Workflows vor dem Commit zu überprüfen.

  8. 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.

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 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.

Configuration:
  Container:
    Registry: DockerHub
    Image: node:18.18.2