

Amazon non CodeCatalyst è più aperta a nuovi clienti. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, consulta [Come migrare da CodeCatalyst](migration.md).

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Specificazione delle immagini dell'ambiente di runtime
<a name="build-images"></a>

Un'*immagine di ambiente di runtime* è un contenitore Docker all'interno del quale vengono CodeCatalyst eseguite le azioni del flusso di lavoro. Il contenitore Docker viene eseguito sulla piattaforma di elaborazione prescelta e include un sistema operativo e strumenti aggiuntivi di cui potrebbe aver bisogno un'azione di workflow, come Node.js AWS CLI e.tar.

Per impostazione predefinita, le azioni del flusso di lavoro verranno eseguite su una delle [immagini attive](#build-curated-images) fornite e gestite da. CodeCatalyst Solo le azioni di compilazione e test supportano immagini personalizzate. Per ulteriori informazioni, consulta [Assegnazione di un'immagine Docker in un ambiente di runtime personalizzato a un'azione](#build-images-specify).

**Topics**
+ [Immagini attive](#build-curated-images)
+ [Cosa succede se un'immagine attiva non include gli strumenti di cui ho bisogno?](#build-images-more-tools)
+ [Assegnazione di un'immagine Docker in un ambiente di runtime personalizzato a un'azione](#build-images-specify)
+ [Esempi](#workflows-working-custom-image-ex)

## Immagini attive
<a name="build-curated-images"></a>

*Le immagini attive sono immagini* di ambiente di runtime che sono completamente supportate CodeCatalyst e includono strumenti preinstallati. Attualmente esistono due set di immagini attive: uno rilasciato a marzo 2024 e l'altro rilasciato a novembre 2022.

Il fatto che un'azione utilizzi un'immagine di marzo 2024 o novembre 2022 dipende dall'azione:
+ [Le azioni di creazione e test che vengono aggiunte a un flusso di lavoro a partire dal 26 marzo 2024 includeranno una `Container` sezione nella loro definizione YAML che specifica esplicitamente un'immagine di marzo 2024.](#build.default-image) [Facoltativamente, puoi rimuovere la `Container` sezione per tornare all'immagine di novembre 2022.](#build.previous-image)
+ [Le azioni di compilazione e test aggiunte a un flusso di lavoro prima del 26 marzo 2024 *non* includeranno una `Container` sezione nella loro definizione YAML e di conseguenza utilizzeranno un'immagine di novembre 2022.](#build.previous-image) Puoi conservare l'immagine di novembre 2022 o aggiornarla. Per aggiornare l'immagine, apri l'azione nell'editor visivo, scegli la scheda **Configurazione**, quindi seleziona l'immagine di marzo 2024 dall'elenco a discesa delle immagini **docker dell'ambiente Runtime**. Questa selezione aggiungerà una `Container` sezione alla definizione YAML dell'azione che viene compilata con l'immagine appropriata di marzo 2024.
+ [Tutte le altre azioni utilizzeranno un'immagine di [novembre 2022 o un'immagine](#build.previous-image) di marzo 2024.](#build.default-image) Per ulteriori informazioni, consulta la documentazione dell'azione. 

**Topics**
+ [Immagini di marzo 2024](#build.default-image)
+ [Immagini di novembre 2022](#build.previous-image)

### Immagini di marzo 2024
<a name="build.default-image"></a>

Le immagini di marzo 2024 sono le ultime immagini fornite da. CodeCatalyst Esiste un'immagine del marzo 2024 per combinazione di elaborazione type/fleet .

La tabella seguente mostra gli strumenti installati su ogni immagine di marzo 2024.


**strumenti di immagine di marzo 2024**  

| Strumento | CodeCatalyst Amazon EC2 per Linux x86\$164 - `CodeCatalystLinux_x86_64:2024_03` | CodeCatalyst Lambda per Linux x86\$164 - `CodeCatalystLinuxLambda_x86_64:2024_03` | CodeCatalyst Amazon EC2 per Linux Arm64 - `CodeCatalystLinux_Arm64:2024_03` | CodeCatalyst Lambda per Linux Arm64 - `CodeCatalystLinuxLambda_Arm64:2024_03` | 
| --- | --- | --- | --- | --- | 
| AWS CLI | 2.15.17 | 2,15,17 | 2,15,17 | 2,15,17 | 
| AWS CLI Copilot | 1.32.1 | 1,32,1 | 1,32,1 | 1,32,1 | 
| Docker | 24,9 | N/D | 24,9 | N/D | 
| Docker Compose | 2.23.3 | N/D | 2.23.3 | N/D | 
| 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 | Corretto 17 | Corretto 17 | Corretto 17 | Corretto 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 | 311,6 | 311,6 | 311,6 | 
| pip | 22,31 | 22,31 | 22,31 | 22,31 | 
| .NET | 8,0100 | 8,0100 | 8,0100 | 8,0100 | 

### Immagini di novembre 2022
<a name="build.previous-image"></a>

È disponibile un'immagine del novembre 2022 per type/fleet combinazione di elaborazione. È disponibile anche un'immagine Windows di novembre 2022 con l'azione di creazione se hai configurato una flotta [predisposta](workflows-working-compute.md#compute.fleets).

La tabella seguente mostra gli strumenti installati in ogni immagine di novembre 2022.


**strumenti di immagine di novembre 2022**  

| Strumento | CodeCatalyst Amazon EC2 per Linux x86\$164 - `CodeCatalystLinux_x86_64:2022_11` | CodeCatalyst Lambda per Linux x86\$164 - `CodeCatalystLinuxLambda_x86_64:2022_11` | CodeCatalyst Amazon EC2 per Linux Arm64 - `CodeCatalystLinux_Arm64:2022_11` | CodeCatalyst Lambda per Linux Arm64 - `CodeCatalystLinuxLambda_Arm64:2022_11` | CodeCatalyst Amazon EC2 per 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 CLI Copilot | 0.6.0 | 0,6,0 | N/D | N/D | 1,30,1 | 
| Docker | 23,01 | N/D | 23,1 | N/D | N/D | 
| Docker Compose | 2.16.0 | N/D | 2.16.0 | N/D | N/D | 
| Git | 2.40.0 | 2.40.0 | 2,39,2 | 2,339,2 | 2,42,0 | 
| Go | 1.20.2 | 1.20.2 | 1,20.1 | 1,20.1 | 1,19 | 
| Gradle | 80,2 | 80,2 | 8.0.1 | 8.0.1 | 8.3 | 
| Java | Corretto 17 | Corretto 17 | Corretto 17 | Corretto 17 | Corretto 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/D | 3,9,15 | N/D | 3.11.2 | N/D | 
| pip | 222,2 | 222,2 | 23,1 | 23,1 | 22,4 | 
| .NET | 6,0,407 | 6,0,407 | 6,0,406 | 6,0,406 | 6,0,414 | 

## Cosa succede se un'immagine attiva non include gli strumenti di cui ho bisogno?
<a name="build-images-more-tools"></a>

Se nessuna delle [immagini attive](#build-curated-images) fornite da CodeCatalyst include gli strumenti necessari, hai un paio di opzioni:
+ Puoi fornire un'immagine Docker per un ambiente di runtime personalizzato che includa gli strumenti necessari. Per ulteriori informazioni, consulta [Assegnazione di un'immagine Docker in un ambiente di runtime personalizzato a un'azione](#build-images-specify).
**Nota**  
 Se vuoi fornire un'immagine Docker per un ambiente di runtime personalizzato, assicurati che nell'immagine personalizzata sia installato Git. 
+ Puoi fare in modo che l'azione di compilazione o test del tuo flusso di lavoro installi gli strumenti di cui hai bisogno.

  Ad esempio, puoi includere le seguenti istruzioni nella `Steps` sezione del codice YAML dell'azione di compilazione o test:

  ```
  Configuration:
    Steps:
      - Run: ./setup-script
  ```

  L'*setup-script*istruzione eseguirebbe quindi il seguente script per installare il gestore di pacchetti Node (npm):

  ```
  #!/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
  ```

  Per ulteriori informazioni sull'azione di compilazione YAML, vedere. [Crea e testa azioni YAML](build-action-ref.md)

## Assegnazione di un'immagine Docker in un ambiente di runtime personalizzato a un'azione
<a name="build-images-specify"></a>

Se non desideri utilizzare un'[immagine Active fornita da CodeCatalyst, puoi fornire un'immagine](#build-curated-images) Docker per un ambiente di runtime personalizzato. Se vuoi fornire un'immagine personalizzata, assicurati che abbia Git installato al suo interno. L'immagine può risiedere in Docker Hub, Amazon Elastic Container Registry o in qualsiasi archivio pubblico.

Per sapere come creare un'immagine Docker personalizzata, consulta [Containerizzare un'](https://docs.docker.com/get-started/02_our_app/)applicazione nella documentazione Docker.

Usa le seguenti istruzioni per assegnare l'immagine Docker del tuo ambiente di runtime personalizzato a un'azione. Dopo aver specificato un'immagine, la CodeCatalyst distribuisce sulla tua piattaforma di elaborazione all'inizio dell'azione.

**Nota**  
**Le seguenti azioni non supportano immagini Docker in ambiente di runtime personalizzate: **Deploy CloudFormation stack, Deploy** **to ECS** e **GitHub Actions**. Inoltre, le immagini Docker dell'ambiente di runtime personalizzato non supportano il tipo di calcolo Lambda.**

------
#### [ Visual ]

**Per assegnare un'immagine Docker all'ambiente di runtime personalizzato utilizzando l'editor visivo**

1. [Apri la CodeCatalyst console all'indirizzo https://codecatalyst.aws/.](https://codecatalyst.aws/)

1. **Nel riquadro di navigazione, scegli **CI/CD**, quindi scegli Flussi di lavoro.**

1. Scegli il nome del tuo flusso di lavoro. Puoi filtrare in base al nome del repository o del ramo di origine in cui è definito il flusso di lavoro oppure filtrare in base al nome o allo stato del flusso di lavoro.

1. Scegli **Modifica**.

1. Scegli **Visual**.

1. Nel diagramma del flusso di lavoro, scegli l'azione che utilizzerà l'immagine Docker del tuo ambiente di runtime personalizzato.

1. Scegli la scheda **Configurazione**.

1. Nella parte inferiore, compila i seguenti campi.

   **Immagine Docker in ambiente di runtime - opzionale**

   Specificate il registro in cui è archiviata l'immagine. I valori validi includono:
   + `CODECATALYST`(Editor YAML)

     L'immagine è memorizzata nel registro. CodeCatalyst 
   + **Docker Hub** (editor visivo) o `DockerHub` (editor YAML)

     L'immagine è memorizzata nel registro delle immagini di Docker Hub.
   + **Altro registro** (editor visivo) o `Other` (editor YAML)

     L'immagine viene memorizzata in un registro di immagini personalizzato. È possibile utilizzare qualsiasi registro disponibile pubblicamente.
   + **Amazon Elastic Container Registry** (editor visivo) o `ECR` (editor YAML)

     L'immagine è archiviata in un repository di immagini di Amazon Elastic Container Registry. Per utilizzare un'immagine in un repository Amazon ECR, questa azione richiede l'accesso ad Amazon ECR. Per abilitare questo accesso, devi creare un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) che includa le seguenti autorizzazioni e una politica di fiducia personalizzata. (Se lo desideri, puoi modificare un ruolo esistente per includere le autorizzazioni e la policy.)

     Il ruolo IAM deve includere le seguenti autorizzazioni nella sua politica del ruolo:
     + `ecr:BatchCheckLayerAvailability`
     + `ecr:BatchGetImage`
     + `ecr:GetAuthorizationToken`
     + `ecr:GetDownloadUrlForLayer`

     Il ruolo IAM deve includere la seguente politica di fiducia personalizzata:

     Per ulteriori informazioni sulla creazione di ruoli IAM, consulta [Creating a role using custom trust policies (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) nella *IAM User Guide*.

     Una volta creato il ruolo, è necessario assegnarlo all'azione tramite un ambiente. Per ulteriori informazioni, consulta [Associare un ambiente a un'azione](deploy-environments-add-app-to-environment.md).

   **URL dell'immagine ECR****, immagine **Docker Hub o URL dell'immagine****

   Specifica una delle seguenti proprietà:
   + Se utilizzi un `CODECATALYST` registro, imposta l'immagine su una delle seguenti immagini [attive](#build-curated-images):
     + `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`
   + Se utilizzi un registro Docker Hub, imposta l'immagine sul nome dell'immagine Docker Hub e sul tag opzionale.

     Ad esempio: `postgres:latest`
   + Se utilizzi un registro Amazon ECR, imposta l'immagine sull'URI del registro Amazon ECR.

     Ad esempio: `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo`
   + Se utilizzi un registro personalizzato, imposta l'immagine sul valore previsto dal registro personalizzato.

1. (Facoltativo) Scegliete **Convalida per convalidare** il codice YAML del flusso di lavoro prima di eseguire il commit.

1. **Scegliete **Commit**, inserite un messaggio di commit e scegliete nuovamente Commit.**

------
#### [ YAML ]

**Per assegnare un'immagine Docker all'ambiente di runtime personalizzato utilizzando l'editor YAML**

1. **Nel riquadro di navigazione, scegli **CI/CD, quindi scegli Flussi** di lavoro.**

1. Scegli il nome del tuo flusso di lavoro. Puoi filtrare in base al nome del repository o del ramo di origine in cui è definito il flusso di lavoro oppure filtrare in base al nome o allo stato del flusso di lavoro.

1. Scegli **Modifica**.

1. Scegli **YAML**.

1. Trova l'azione a cui vuoi assegnare un'immagine Docker in un ambiente di runtime.

1. Nell'azione, aggiungi una `Container` sezione e le proprietà sottostanti`Registry`. `Image` Per ulteriori informazioni, consultate la `Container` descrizione `Registry` e `Image` le proprietà nella sezione [Azioni](workflow-reference.md#actions-reference) dedicata all'azione.

1. (Facoltativo) Scegliete **Convalida per convalidare** il codice YAML del flusso di lavoro prima di eseguire il commit.

1. **Scegliete **Commit**, inserite un messaggio di commit e scegliete nuovamente Commit.**

------

## Esempi
<a name="workflows-working-custom-image-ex"></a>

Gli esempi seguenti mostrano come assegnare un'immagine Docker di un ambiente di runtime personalizzato a un'azione nel file di definizione del flusso di lavoro.

**Topics**
+ [Esempio: utilizzo di un'immagine Docker in un ambiente di runtime personalizzato per aggiungere il supporto per Node.js 18 con Amazon ECR](#workflows-working-custom-image-ex-ecr-node18)
+ [Esempio: utilizzo di un'immagine Docker in un ambiente di runtime personalizzato per aggiungere il supporto per Node.js 18 con Docker Hub](#workflows-working-custom-image-ex-docker-node18)

### Esempio: utilizzo di un'immagine Docker in un ambiente di runtime personalizzato per aggiungere il supporto per Node.js 18 con Amazon ECR
<a name="workflows-working-custom-image-ex-ecr-node18"></a>

L'esempio seguente mostra come utilizzare un'immagine Docker in un ambiente di runtime personalizzato per aggiungere il supporto per Node.js 18 con [Amazon ECR](https://gallery.ecr.aws/amazonlinux/amazonlinux).

```
Configuration:
  Container:
    Registry: ECR
    Image: public.ecr.aws/amazonlinux/amazonlinux:2023
```

### Esempio: utilizzo di un'immagine Docker in un ambiente di runtime personalizzato per aggiungere il supporto per Node.js 18 con Docker Hub
<a name="workflows-working-custom-image-ex-docker-node18"></a>

[L'esempio seguente mostra come utilizzare un'immagine Docker in un ambiente di runtime personalizzato per aggiungere il supporto per Node.js 18 con Docker Hub.](https://hub.docker.com/_/node)

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