A Amazon não CodeCatalyst está mais aberta a novos clientes. Os clientes atuais podem continuar usando o serviço normalmente. Para obter mais informações, consulte [Como migrar do CodeCatalyst](migration.md).
As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Especificação de imagens de ambiente de runtime
Uma *imagem do ambiente de tempo de execução* é um contêiner do Docker no qual são CodeCatalyst executadas ações de fluxo de trabalho. O contêiner do Docker é executado na plataforma de computação escolhida e inclui um sistema operacional e ferramentas extras que uma ação de fluxo de trabalho pode precisar, como o AWS CLI Node.js e .tar.
Por padrão, as ações do fluxo de trabalho serão executadas em uma das [imagens ativas](#build-curated-images) fornecidas e mantidas pela CodeCatalyst. Somente ações de criação e teste oferecem suporte a imagens personalizadas. Para obter mais informações, consulte [Atribuir uma imagem do Docker de um ambiente de runtime personalizada a uma ação](#build-images-specify).
**Topics**
+ [Imagens ativas](#build-curated-images)
+ [E se uma imagem ativa não incluir as ferramentas de que preciso?](#build-images-more-tools)
+ [Atribuir uma imagem do Docker de um ambiente de runtime personalizada a uma ação](#build-images-specify)
+ [Exemplos](#workflows-working-custom-image-ex)
## Imagens ativas
*Imagens ativas são imagens* do ambiente de execução que são totalmente suportadas CodeCatalyst e incluem ferramentas pré-instaladas. Atualmente, existem dois conjuntos de imagens ativas: um lançado em março de 2024 e outro lançado em novembro de 2022.
O uso da imagem de março de 2024 ou novembro de 2022 depende da ação:
+ As ações de criação e teste adicionadas a um fluxo de trabalho em ou após 26 de março de 2024 incluirão uma seção `Container` na definição de YAML que especifica explicitamente uma [imagem de março de 2024](#build.default-image). Se desejar, você pode remover a seção `Container` para voltar à [imagem de novembro de 2022](#build.previous-image).
+ As ações de criação e teste que foram adicionadas a um fluxo de trabalho antes de 26 de março de 2024 *não* incluirão uma seção `Container` na definição de YAML e, consequentemente, usarão uma [imagem de novembro de 2022](#build.previous-image). É possível manter a imagem de novembro de 2022 ou atualizá-la. Para atualizar a imagem, abra a ação no editor visual, selecione a guia **Configuração** e selecione a imagem de março de 2024 na lista suspensa **Imagem do Docker do ambiente de runtime**. Essa seleção adicionará uma seção `Container` à definição de YAML da ação que é preenchida com a imagem apropriada de março de 2024.
+ Todas as outras ações usarão uma [imagem de novembro de 2022](#build.previous-image) ou uma [imagem de março de 2024](#build.default-image). Para ter mais informações, consulte a documentação da ação.
**Topics**
+ [Imagens de março de 2024](#build.default-image)
+ [Imagens de novembro de 2022](#build.previous-image)
### Imagens de março de 2024
As imagens de março de 2024 são as imagens mais recentes fornecidas por CodeCatalyst. Há uma imagem de março de 2024 por combinação computacional. type/fleet
A tabela a seguir mostra as ferramentas instaladas em cada imagem de março de 2024.
**Ferramentas de imagem de março de 2024**
| Ferramenta | CodeCatalyst Amazon EC2 para Linux x86\$164 - `CodeCatalystLinux_x86_64:2024_03` | CodeCatalyst Lambda para Linux x86\$164 - `CodeCatalystLinuxLambda_x86_64:2024_03` | CodeCatalyst Amazon EC2 para Linux Arm64 - `CodeCatalystLinux_Arm64:2024_03` | CodeCatalyst Lambda para Linux Arm64 - `CodeCatalystLinuxLambda_Arm64:2024_03` |
| --- | --- | --- | --- | --- |
| AWS CLI | 2.15.17 | 2.15.17 | 2.15.17 | 2.15.17 |
| AWS CLI do Copilot | 1.32.1 | 1.32.1 | 1.32.1 | 1.32.1 |
| Docker | 24.0.9 | N/D | 24.0.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 | Corretto17 | Corretto17 | Corretto17 | Corretto17 |
| 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 |
### Imagens de novembro de 2022
Há uma imagem de novembro de 2022 por type/fleet combinação computacional. Também há uma imagem do Windows de novembro de 2022 disponível com a ação de criação, caso você tenha configurado uma [frota provisionada](workflows-working-compute.md#compute.fleets).
A tabela a seguir mostra as ferramentas instaladas em cada imagem de novembro de 2022.
**Ferramentas de imagem de novembro de 2022**
| Ferramenta | CodeCatalyst Amazon EC2 para Linux x86\$164 - `CodeCatalystLinux_x86_64:2022_11` | CodeCatalyst Lambda para Linux x86\$164 - `CodeCatalystLinuxLambda_x86_64:2022_11` | CodeCatalyst Amazon EC2 para Linux Arm64 - `CodeCatalystLinux_Arm64:2022_11` | CodeCatalyst Lambda para Linux Arm64 - `CodeCatalystLinuxLambda_Arm64:2022_11` | CodeCatalyst Amazon EC2 para 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 do Copilot | 0.6.0 | 0.6.0 | N/D | N/D | 1.30.1 |
| Docker | 23.01 | N/D | 23.0.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.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 | Corretto17 | Corretto17 | Corretto17 | Corretto17 | Corretto17 |
| 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 | 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 |
## E se uma imagem ativa não incluir as ferramentas de que preciso?
Se nenhuma das [imagens ativas](#build-curated-images) fornecidas pelo CodeCatalyst incluir as ferramentas necessárias, você tem algumas opções:
+ Você pode fornecer uma imagem do Docker de ambiente de runtime personalizada que inclua as ferramentas necessárias. Para obter mais informações, consulte [Atribuir uma imagem do Docker de um ambiente de runtime personalizada a uma ação](#build-images-specify).
**nota**
Se você quiser fornecer uma imagem do Docker de ambiente de runtime personalizada, a imagem personalizada deverá ter o Git instalado nela.
+ Você pode fazer com que a ação de criação ou teste do fluxo de trabalho instale as ferramentas necessárias.
Por exemplo, você pode incluir as seguintes instruções na seção `Steps` do código YAML da ação de criação ou teste:
```
Configuration:
Steps:
- Run: ./setup-script
```
A *setup-script* instrução então executaria o seguinte script para instalar o gerenciador de pacotes 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
```
Para ter mais informações sobre o YAML da ação de criação, consulte [Ações de criação e de teste YAML](build-action-ref.md).
## Atribuir uma imagem do Docker de um ambiente de runtime personalizada a uma ação
Se você não quiser usar uma [imagem ativa](#build-curated-images) fornecida pela CodeCatalyst, você pode fornecer uma imagem Docker de ambiente de tempo de execução personalizada. Se você quiser fornecer uma imagem personalizada, ela deverá ter o Git instalado. A imagem pode residir no Docker Hub, no Amazon Elastic Container Registry ou em qualquer repositório público.
Para saber como criar uma imagem do Docker personalizada, consulte [Criar contêineres em uma aplicação](https://docs.docker.com/get-started/02_our_app/) na documentação do Docker.
Use as instruções a seguir para atribuir a imagem do Docker de ambiente de runtime personalizada a uma ação. Depois de especificar uma imagem, CodeCatalyst implante-a na sua plataforma de computação quando a ação começar.
**nota**
**As ações a seguir não oferecem suporte a imagens personalizadas do Docker do ambiente de tempo de execução: **Deploy CloudFormation stack**, **Deploy to ECS** e **GitHub Actions. As** imagens do Docker do ambiente de tempo de execução personalizado também não oferecem suporte ao tipo de computação Lambda.**
------
#### [ Visual ]
**Para atribuir uma imagem do Docker de ambiente de runtime personalizada usando o editor visual**
1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**.
1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho.
1. Escolha **Editar**.
1. Selecione **Visual**.
1. No diagrama do fluxo de trabalho, escolha a ação que usará a imagem do Docker de ambiente de runtime personalizada.
1. Escolha a guia **Configuração**.
1. Na parte inferior, preencha os seguintes campos.
**Imagem do Docker de ambiente de runtime - opcional**
Especifique o registro em que a imagem está armazenada. Os valores válidos são:
+ `CODECATALYST` (editor YAML)
A imagem é armazenada no CodeCatalyst registro.
+ **Docker Hub** (editor visual) ou `DockerHub` (editor YAML)
A imagem é armazenada no registro de imagens do Docker Hub.
+ **Outro registro** (editor visual) ou `Other` (editor YAML)
A imagem é armazenada em um registro de imagem personalizado. Qualquer registro disponível publicamente pode ser usado.
+ **Amazon Elastic Container Registry** (editor visual) ou `ECR` (editor YAML)
A imagem é armazenada em um repositório de imagens do Amazon Elastic Container Registry. Para usar uma imagem em um repositório do Amazon ECR, essa ação precisa acessar o Amazon ECR. Para habilitar esse acesso, é necessário criar um [perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que inclua as permissões e a política de confiança personalizada a seguir. (Se desejar, você poderá modificar um perfil existente para incluir as permissões e a política.)
O perfil do IAM deve incluir as seguintes permissões na política:
+ `ecr:BatchCheckLayerAvailability`
+ `ecr:BatchGetImage`
+ `ecr:GetAuthorizationToken`
+ `ecr:GetDownloadUrlForLayer`
O perfil do IAM deve incluir a seguinte política de confiança personalizada:
Para ter mais informações sobre como criar perfis do IAM, consulte [Criar um perfil usando políticas de confiança personalizadas (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) no *Guia do usuário do IAM*.
Depois que você criar o perfil, deverá atribuí-lo à ação por meio de um ambiente. Para obter mais informações, consulte [Associação de um ambiente a uma ação](deploy-environments-add-app-to-environment.md).
**URL da imagem do ECR**, **imagem do Docker Hub** ou **URL da imagem**
Especifique um dos seguintes:
+ Se você estiver usando um registro `CODECATALYST`, defina a imagem como uma das seguintes [imagens ativas](#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 você estiver usando um registro do Docker Hub, defina a imagem como o nome da imagem do Docker Hub e a tag opcional.
Exemplo: `postgres:latest`
+ Se estiver usando um registro do Amazon ECR, defina a imagem como o URI do registro do Amazon ECR.
Exemplo: `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo`
+ Se estiver usando um registro personalizado, defina a imagem como o valor esperado pelo registro personalizado.
1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar.
1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente.
------
#### [ YAML ]
**Para atribuir uma imagem do Docker de ambiente de runtime personalizada usando o editor YAML**
1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**.
1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho.
1. Escolha **Editar**.
1. Selecione **YAML**.
1. Encontre a ação à qual você quer atribuir uma imagem do Docker do ambiente de runtime.
1. Na ação, adicione uma seção `Container` e as propriedades subjacentes `Registry` e `Image`. Para ter mais informações, consulte a descrição das propriedades `Container`, `Registry` e `Image` da [Ações](workflow-reference.md#actions-reference) para sua ação.
1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar.
1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente.
------
## Exemplos
Os exemplos a seguir mostram como atribuir uma imagem do Docker de ambiente de runtime personalizada a uma ação no arquivo de definição do fluxo de trabalho.
**Topics**
+ [Exemplo: uso de uma imagem do Docker de ambiente de runtime personalizada para adicionar suporte ao Node.js 18 com o Amazon ECR](#workflows-working-custom-image-ex-ecr-node18)
+ [Exemplo: uso de uma imagem do Docker de ambiente de runtime personalizada para adicionar suporte ao Node.js 18 com o Docker Hub](#workflows-working-custom-image-ex-docker-node18)
### Exemplo: uso de uma imagem do Docker de ambiente de runtime personalizada para adicionar suporte ao Node.js 18 com o Amazon ECR
O exemplo a seguir mostra como usar uma imagem do Docker de ambiente de runtime personalizada para adicionar suporte ao Node.js 18 com o [Amazon ECR](https://gallery.ecr.aws/amazonlinux/amazonlinux).
```
Configuration:
Container:
Registry: ECR
Image: public.ecr.aws/amazonlinux/amazonlinux:2023
```
### Exemplo: uso de uma imagem do Docker de ambiente de runtime personalizada para adicionar suporte ao Node.js 18 com o Docker Hub
O exemplo a seguir mostra como usar uma imagem do Docker de ambiente de runtime personalizada para adicionar suporte ao Node.js 18 com o [Docker Hub](https://hub.docker.com/_/node).
```
Configuration:
Container:
Registry: DockerHub
Image: node:18.18.2
```