Amazon n' CodeCatalyst est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour de plus amples informations, veuillez consulter [Comment effectuer une migration depuis CodeCatalyst](migration.md).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Configuration des images de calcul et d'exécution
Dans un CodeCatalyst flux de travail, vous pouvez spécifier l'image de l'environnement de calcul et d'exécution à CodeCatalyst utiliser pour exécuter les actions du flux de travail.
Le *calcul* fait référence au moteur informatique (le processeur, la mémoire et le système d'exploitation) géré et maintenu par lequel les actions du flux CodeCatalyst de travail sont exécutées.
**Note**
Si le calcul est défini comme une propriété du flux de travail, il ne peut être défini comme une propriété d'aucune action dans ce flux de travail. De même, si le calcul est défini comme une propriété d'une action, il ne peut pas être défini dans le flux de travail.
Une *image d'environnement d'exécution* est un conteneur Docker dans lequel CodeCatalyst s'exécutent des actions de flux de travail. Le conteneur Docker s'exécute sur la plate-forme informatique que vous avez choisie et inclut un système d'exploitation et des outils supplémentaires dont une action de flux de travail peut avoir besoin AWS CLI, tels que Node.js et .tar.
**Topics**
+ [Types de calcul](#compute.types)
+ [Flottes informatiques](#compute.fleets)
+ [Propriétés de la flotte à la demande](#compute.on-demand)
+ [Propriétés de la flotte de véhicules provisionnée](#compute.provisioned-fleets)
+ [Création d'une flotte approvisionnée](projects-create-compute-resource.md)
+ [Modification d'une flotte approvisionnée](edit-compute-resource.md)
+ [Supprimer une flotte approvisionnée](delete-compute-resource.md)
+ [Affectation d'une flotte ou d'un ordinateur à une action](workflows-assign-compute-resource.md)
+ [Partage du calcul entre les actions](compute-sharing.md)
+ [Spécification des images de l'environnement d'exécution](build-images.md)
## Types de calcul
CodeCatalyst propose les types de calcul suivants :
+ Amazon EC2
+ AWS Lambda
Amazon EC2 offre une flexibilité optimisée lors des exécutions d'actions et Lambda offre des vitesses de démarrage des actions optimisées. Lambda permet des exécutions d'actions de flux de travail plus rapides grâce à une latence de démarrage plus faible. Lambda vous permet d'exécuter des flux de travail de base permettant de créer, de tester et de déployer des applications sans serveur avec des environnements d'exécution courants. Ces environnements d'exécution incluent Node.js, Python, Java, .NET et Go. Cependant, Lambda ne prend pas en charge certains cas d'utilisation, et s'ils vous concernent, utilisez le type de calcul Amazon EC2 :
+ Lambda ne prend pas en charge les images d'environnement d'exécution provenant d'un registre spécifié.
+ Lambda ne prend pas en charge les outils qui nécessitent des autorisations root. Pour des outils tels que `yum` ou`rpm`, utilisez le type de calcul Amazon EC2 ou d'autres outils ne nécessitant pas d'autorisations root.
+ Lambda ne prend pas en charge les builds ou les exécutions de Docker. Les actions suivantes qui utilisent des images Docker ne sont pas prises en charge : Deploy AWS CloudFormation stack, Deploy to Amazon ECS, Amazon S3 publish, AWS CDK bootstrap, AWS CDK deploy, AWS Lambda invoke et GitHub Actions. Les GitHub actions basées sur Docker qui s'exécutent dans le cadre d'une action CodeCatalyst GitHub Actions ne sont pas non plus prises en charge par le calcul Lambda. Vous pouvez utiliser des alternatives qui ne nécessitent pas d'autorisations root, telles que Podman.
+ Lambda ne prend pas en charge l'écriture dans des fichiers externes. `/tmp` Lorsque vous configurez les actions de votre flux de travail, vous pouvez reconfigurer les outils à installer ou à utiliser pour `/tmp` écrire. Si vous avez une action de compilation qui s'installe`npm`, assurez-vous de la configurer pour l'installer sur`/tmp`.
+ Lambda ne prend pas en charge les durées d'exécution supérieures à 15 minutes.
## Flottes informatiques
CodeCatalyst propose les flottes de calcul suivantes :
+ Flottes à la demande
+ Flottes provisionnées
Dans le cas des flottes à la demande, lorsqu'une action de flux de travail démarre, le flux de travail fournit les ressources dont il a besoin. Les machines sont détruites à la fin de l'action. Vous ne payez que pour le nombre de minutes pendant lesquelles vous exécutez vos actions. Les flottes à la demande sont entièrement gérées et incluent des fonctionnalités de mise à l'échelle automatique pour faire face aux pics de demande.
CodeCatalyst propose également des flottes provisionnées contenant des machines alimentées par Amazon EC2 et entretenues par. CodeCatalyst Avec les flottes provisionnées, vous configurez un ensemble de machines dédiées pour exécuter les actions de votre flux de travail. Ces machines restent inactives, prêtes à exécuter des actions immédiatement. Avec les flottes provisionnées, vos machines fonctionnent toujours et entraîneront des coûts tant qu'elles seront provisionnées.
Pour créer, mettre à jour ou supprimer une flotte, vous devez avoir le rôle d'**administrateur de l'espace** ou le rôle d'**administrateur du projet**.
## Propriétés de la flotte à la demande
CodeCatalyst fournit les flottes à la demande suivantes :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/workflows-working-compute.html)
**Note**
Les spécifications des flottes à la demande varient en fonction de votre niveau de facturation. Pour plus d’informations, consultez [Tarification d’](https://codecatalyst.aws/explore/pricing).
Si aucune flotte n'est sélectionnée, CodeCatalyst utilise`Linux.x86-64.Large`.
## Propriétés de la flotte de véhicules provisionnée
Une flotte provisionnée contient les propriétés suivantes :
**Système d’exploitation**
Le système d'exploitation. Les systèmes d'exploitation suivants sont disponibles :
+ Amazon Linux 2
+ Windows Server 2022
**Note**
Les flottes Windows ne sont prises en charge que dans l'action de génération. Les autres actions ne sont actuellement pas compatibles avec Windows.
**Architecture**
Architecture du processeur. Les architectures disponibles sont les suivantes :
+ x86\$164
+ Bras 64
**Type de machine**
Type de machine pour chaque instance. Les types de machines suivants sont disponibles :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/workflows-working-compute.html)
**Capacity**
Le nombre initial de machines allouées au parc, qui définit le nombre d'actions pouvant être exécutées en parallèle.
**Mode mise à l'échelle**
Définit le comportement lorsque le nombre d'actions dépasse la capacité de la flotte.
**Fournir des capacités supplémentaires à la demande**
Des machines supplémentaires sont configurées à la demande. Elles augmentent automatiquement en réponse aux nouvelles actions en cours d'exécution, puis réduisent leur capacité de base à la fin des actions. Cela peut entraîner des coûts supplémentaires, car vous payez à la minute pour chaque machine en marche.
**Attendez que la capacité de flotte supplémentaire soit disponible**
Les exécutions d'actions sont placées dans une file d'attente jusqu'à ce qu'une machine soit disponible. Cela limite les coûts supplémentaires car aucune machine supplémentaire n'est allouée.
# Création d'une flotte approvisionnée
Suivez les instructions ci-dessous pour créer une flotte provisionnée.
**Note**
Les flottes approvisionnées seront désactivées après 2 semaines d'inactivité. S'ils sont réutilisés, ils seront automatiquement réactivés, mais cette réactivation peut entraîner une latence.
**Pour créer une flotte approvisionnée**
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Compute.**
1. Choisissez **Créer une flotte provisionnée**.
1. Dans le champ de texte **Nom du parc approvisionné**, entrez le nom de votre flotte.
1. Dans le menu déroulant **Système d'exploitation**, sélectionnez le système d'exploitation.
1. Dans le menu déroulant **Type de machine**, choisissez le type de machine pour votre machine.
1. Dans le champ de texte **Capacité**, entrez le nombre maximum de machines du parc.
1. Dans le menu déroulant du **mode de mise à l'échelle**, choisissez le comportement de débordement souhaité. Pour plus d’informations sur ces champs, consultez [Propriétés de la flotte de véhicules provisionnée](workflows-working-compute.md#compute.provisioned-fleets).
1. Choisissez **Créer**.
Après avoir créé le parc approvisionné, vous êtes prêt à l'affecter à une action. Pour de plus amples informations, veuillez consulter [Affectation d'une flotte ou d'un ordinateur à une action](workflows-assign-compute-resource.md).
# Modification d'une flotte approvisionnée
Suivez les instructions suivantes pour modifier un parc provisionné.
**Note**
Les flottes approvisionnées seront désactivées après 2 semaines d'inactivité. S'ils sont réutilisés, ils seront automatiquement réactivés, mais cette réactivation peut entraîner une latence.
**Pour modifier une flotte approvisionnée**
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Compute.**
1. Dans la liste des **flottes approvisionnées**, choisissez la flotte que vous souhaitez modifier.
1. Choisissez **Modifier**.
1. Dans le champ de texte **Capacité**, entrez le nombre maximum de machines du parc.
1. Dans le menu déroulant du **mode de mise à l'échelle**, choisissez le comportement de débordement souhaité. Pour plus d’informations sur ces champs, consultez [Propriétés de la flotte de véhicules provisionnée](workflows-working-compute.md#compute.provisioned-fleets).
1. Choisissez **Enregistrer**.
# Supprimer une flotte approvisionnée
Suivez les instructions ci-dessous pour supprimer une flotte approvisionnée.
**Pour supprimer une flotte approvisionnée**
**Avertissement**
Avant de supprimer un parc provisionné, supprimez-le de toutes les actions en supprimant la `Fleet` propriété du code YAML de l'action. Toute action qui continue de faire référence à une flotte approvisionnée après sa suppression échouera lors de la prochaine exécution de l'action.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Compute.**
1. Dans la liste des **flottes approvisionnées**, choisissez la flotte que vous souhaitez supprimer.
1. Sélectionnez **Delete (Supprimer)**.
1. Entrez **delete** pour confirmer la suppression.
1. Sélectionnez **Supprimer**.
# Affectation d'une flotte ou d'un ordinateur à une action
Par défaut, les actions de flux de travail utilisent le parc `Linux.x86-64.Large` à la demande avec un type de calcul Amazon EC2. Pour utiliser un parc provisionné à la place, ou pour utiliser un autre parc à la demande, par exemple`Linux.x86-64.2XLarge`, suivez les instructions suivantes.
------
#### [ Visual ]
**Avant de commencer**
+ Si vous souhaitez attribuer une flotte approvisionnée, vous devez d'abord créer la flotte approvisionnée. Pour de plus amples informations, veuillez consulter [Création d'une flotte approvisionnée](projects-create-compute-resource.md).
**Pour affecter une flotte approvisionnée ou un type de flotte différent à une action**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. Dans le diagramme du flux de travail, choisissez l'action à laquelle vous souhaitez attribuer votre flotte approvisionnée ou votre nouveau type de flotte.
1. Cliquez sur l’onglet **Configuration**.
1. Dans **Compute fleet**, procédez comme suit :
Spécifiez la machine ou le parc qui exécutera votre flux de travail ou vos actions de flux de travail. Dans le cas des flottes à la demande, lorsqu'une action démarre, le flux de travail fournit les ressources dont il a besoin et les machines sont détruites à la fin de l'action. Exemples de flottes à la demande :`Linux.x86-64.Large`,`Linux.x86-64.XLarge`. Pour plus d'informations sur les flottes à la demande, consultez[Propriétés de la flotte à la demande](workflows-working-compute.md#compute.on-demand).
Avec les flottes provisionnées, vous configurez un ensemble de machines dédiées pour exécuter les actions de votre flux de travail. Ces machines restent inactives, prêtes à exécuter des actions immédiatement. Pour plus d'informations sur les flottes provisionnées, consultez. [Propriétés de la flotte de véhicules provisionnée](workflows-working-compute.md#compute.provisioned-fleets)
S'il `Fleet` est omis, la valeur par défaut est`Linux.x86-64.Large`.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Avant de commencer**
+ Si vous souhaitez attribuer une flotte approvisionnée, vous devez d'abord créer la flotte approvisionnée. Pour de plus amples informations, veuillez consulter [Création d'une flotte approvisionnée](projects-create-compute-resource.md).
**Pour affecter une flotte approvisionnée ou un type de flotte différent à une action**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Recherchez l'action à laquelle vous souhaitez attribuer votre flotte approvisionnée ou votre nouveau type de flotte.
1. Dans l'action, ajoutez une `Compute` propriété et définissez `Fleet` le nom de votre flotte ou le type de flotte à la demande. Pour plus d'informations, consultez la description de la `Fleet` propriété dans le champ [Créez et testez des actions YAML](build-action-ref.md) correspondant à votre action.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
# Partage du calcul entre les actions
Par défaut, les actions d'un flux de travail s'exécutent sur des instances distinctes d'une [flotte](workflows-working-compute.md#compute.fleets). Ce comportement permet aux actions d'isoler et de prévoir l'état des entrées. Le comportement par défaut nécessite une configuration explicite pour partager le contexte tel que les fichiers et les variables entre les actions.
Le partage de calcul est une fonctionnalité qui vous permet d'exécuter toutes les actions d'un flux de travail sur la même instance. L'utilisation du partage de calcul peut accélérer les temps d'exécution des flux de travail, car moins de temps est consacré au provisionnement des instances. Vous pouvez également partager des fichiers (artefacts) entre des actions sans configuration supplémentaire du flux de travail.
Lorsqu'un flux de travail est exécuté à l'aide du partage de calcul, une instance de la flotte par défaut ou spécifiée est réservée pour la durée de toutes les actions de ce flux de travail. Lorsque l'exécution du flux de travail est terminée, la réservation d'instance est publiée.
**Topics**
+ [Exécution de plusieurs actions sur un ordinateur partagé](#how-to-compute-share)
+ [Considérations relatives au partage du calcul](#compare-compute-sharing)
+ [Activer le partage de données](#compute-sharing-steps)
+ [Exemples](#compute-sharing-examples)
## Exécution de plusieurs actions sur un ordinateur partagé
Vous pouvez utiliser l'`Compute`attribut dans la définition YAML au niveau du flux de travail pour spécifier à la fois la flotte et les propriétés de partage de calcul des actions. Vous pouvez également configurer les propriétés de calcul à l'aide de l'éditeur visuel dans CodeCatalyst. Pour spécifier un parc, définissez le nom d'un parc existant, définissez le type de **EC2**calcul sur et activez le partage de calcul.
**Note**
Le partage de calcul n'est pris en charge que si le type de calcul est défini sur **EC2**, et il n'est pas pris en charge pour le système d'exploitation Windows Server 2022. Pour plus d'informations sur les flottes de calcul, les types de calcul et les propriétés, consultez[Configuration des images de calcul et d'exécution](workflows-working-compute.md).
**Note**
Si vous êtes au niveau Free et que vous spécifiez la `Linux.x86-64.2XLarge` flotte `Linux.x86-64.XLarge` ou manuellement dans la définition du flux de travail YAML, l'action sera toujours exécutée sur la flotte par défaut (`Linux.x86-64.Large`). Pour plus d'informations sur la disponibilité et la tarification du calcul, consultez le [tableau des options de niveaux](https://codecatalyst.aws/explore/pricing).
Lorsque le partage de calcul est activé, le dossier contenant la source du flux de travail est automatiquement copié d'une action à l'autre. Il n'est pas nécessaire de configurer les artefacts de sortie et de les référencer en tant qu'artefacts d'entrée dans une définition de flux de travail (fichier YAML). En tant qu'auteur de flux de travail, vous devez câbler les variables d'environnement à l'aide d'entrées et de sorties, comme vous le feriez sans utiliser le partage de calcul. Si vous souhaitez partager des dossiers entre des actions extérieures à la source du flux de travail, pensez à mettre en cache des fichiers. Pour plus d’informations, consultez [Partage d'artefacts et de fichiers entre les actions](workflows-working-artifacts.md) et [Mise en cache des fichiers entre les exécutions du flux de travail](workflows-caching.md).
Le référentiel source dans lequel réside le fichier de définition de votre flux de travail est identifié par l'étiquette`WorkflowSource`. Lors de l'utilisation du partage de calcul, la source du flux de travail est téléchargée lors de la première action qui la référence et est automatiquement mise à disposition pour les actions suivantes de l'exécution du flux de travail. Toutes les modifications apportées au dossier contenant la source du flux de travail par une action, telle que l'ajout, la modification ou la suppression de fichiers, sont également visibles dans les actions suivantes du flux de travail. Vous pouvez référencer les fichiers qui se trouvent dans le dossier source du flux de travail dans n'importe laquelle de vos actions de flux de travail, comme vous le pouvez sans utiliser le partage de calcul. Pour de plus amples informations, veuillez consulter [Référencement des fichiers du référentiel source](workflows-sources-reference-files.md).
**Note**
Les flux de travail de partage de calcul doivent spécifier une séquence d'actions stricte, de sorte que les actions parallèles ne peuvent pas être définies. Bien que les artefacts de sortie puissent être configurés à n'importe quelle action de la séquence, les artefacts d'entrée ne sont pas pris en charge.
## Considérations relatives au partage du calcul
Vous pouvez exécuter des flux de travail avec le partage de calcul afin d'accélérer les exécutions de flux de travail et de partager le contexte entre les actions d'un flux de travail utilisant la même instance. Tenez compte des points suivants pour déterminer si l'utilisation du partage de calcul convient à votre scénario :
| | Partage du calcul | Sans partage de calcul |
| --- | --- | --- |
| Type de calcul | Amazon EC2 | Amazon EC2, AWS Lambda |
| Provisionnement d'instances | Actions exécutées sur la même instance | Actions exécutées sur des instances distinctes |
| Système d’exploitation | Amazon Linux 2 | Amazon Linux 2, Windows Server 2022 (action de génération uniquement) |
| Référencement de fichiers | `$CATALYST_SOURCE_DIR_WorkflowSource`, `/sources/WorkflowSource/` | `$CATALYST_SOURCE_DIR_WorkflowSource`, `/sources/WorkflowSource/` |
| Structure de flux de travail | Les actions ne peuvent être exécutées que de manière séquentielle | Les actions peuvent être exécutées en parallèle |
| Accès aux données via les actions du flux de travail | Accéder à la source de flux de travail mise en cache () `WorkflowSource` | Accès aux sorties des artefacts partagés (nécessite une configuration supplémentaire) |
## Activer le partage de données
Suivez les instructions ci-dessous pour activer le partage de calcul pour un flux de travail.
------
#### [ Visual ]
**Pour activer le partage de données à l'aide de l'éditeur visuel**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. Choisissez les **propriétés du flux** de travail.
1. Dans le menu déroulant **Type de calcul**, sélectionnez **EC2**.
1. (Facultatif) Dans le menu déroulant **Compute fleet - facultatif**, choisissez le parc que vous souhaitez utiliser pour exécuter des actions de flux de travail. Vous pouvez choisir une flotte à la demande ou créer et choisir une flotte provisionnée. Pour plus d’informations, consultez [Création d'une flotte approvisionnée](projects-create-compute-resource.md) et [Affectation d'une flotte ou d'un ordinateur à une action](workflows-assign-compute-resource.md)
1. Activez ce bouton pour activer le partage de calcul et exécuter les actions du flux de travail sur le même parc.
1. (Facultatif) Choisissez le mode d'exécution du flux de travail. Pour de plus amples informations, veuillez consulter [Configuration du comportement de mise en file d'attente des exécutions](workflows-configure-runs.md).
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour activer le partage de calcul à l'aide de l'éditeur YAML**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Activez le partage de calcul en définissant le `SharedInstance` champ sur `TRUE` et `Type` sur`EC2`. Définissez `Fleet` un parc informatique que vous souhaitez utiliser pour exécuter des actions de flux de travail. Vous pouvez choisir une flotte à la demande ou créer et choisir une flotte provisionnée. Pour plus d’informations, consultez [Création d'une flotte approvisionnée](projects-create-compute-resource.md) et [Affectation d'une flotte ou d'un ordinateur à une action](workflows-assign-compute-resource.md)
Dans un flux de travail YAML, ajoutez un code similaire au suivant :
```
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. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
## Exemples
**Topics**
+ [Exemple : Amazon S3 Publish](#compute-share-s3)
### Exemple : Amazon S3 Publish
Les exemples de flux de travail suivants montrent comment exécuter l'action Amazon Amazon S3 Publish de deux manières : d'abord en utilisant des artefacts d'entrée, puis en utilisant le partage de calcul. Avec le partage de calcul, les artefacts d'entrée ne sont pas nécessaires puisque vous pouvez accéder au cache`WorkflowSource`. De plus, l'artefact de sortie de l'action Build n'est plus nécessaire. L'action S3 Publish est configurée pour utiliser la `DependsOn` propriété explicite afin de maintenir des actions séquentielles ; l'action Build doit être exécutée avec succès pour que l'action S3 Publish puisse s'exécuter.
+ Sans partage de calcul, vous devez utiliser des artefacts d'entrée et partager les sorties avec les actions suivantes :
```
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
```
+ Lorsque vous utilisez le partage de calcul en `SharedInstance` réglant sur`TRUE`, vous pouvez exécuter plusieurs actions sur la même instance et partager des artefacts en spécifiant une seule source de flux de travail. Les artefacts d'entrée ne sont pas obligatoires et ne peuvent pas être spécifiés :
```
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
```
# Spécification des images de l'environnement d'exécution
Une *image d'environnement d'exécution* est un conteneur Docker dans lequel CodeCatalyst s'exécutent des actions de flux de travail. Le conteneur Docker s'exécute sur la plate-forme informatique que vous avez choisie et inclut un système d'exploitation et des outils supplémentaires dont une action de flux de travail peut avoir besoin AWS CLI, tels que Node.js et .tar.
Par défaut, les actions du flux de travail s'exécutent sur l'une [des images actives](#build-curated-images) fournies et gérées par CodeCatalyst. Seules les actions de création et de test prennent en charge les images personnalisées. Pour de plus amples informations, veuillez consulter [Affectation d'une image Docker d'environnement d'exécution personnalisée à une action](#build-images-specify).
**Topics**
+ [Images actives](#build-curated-images)
+ [Et si une image active n'inclut pas les outils dont j'ai besoin ?](#build-images-more-tools)
+ [Affectation d'une image Docker d'environnement d'exécution personnalisée à une action](#build-images-specify)
+ [Exemples](#workflows-working-custom-image-ex)
## Images actives
Les *images actives sont des images* d'environnement d'exécution qui sont entièrement prises en charge par CodeCatalyst des outils préinstallés et qui incluent ceux-ci. Il existe actuellement deux séries d'images actives : l'une publiée en mars 2024 et l'autre publiée en novembre 2022.
Le fait qu'une action utilise une image de mars 2024 ou de novembre 2022 dépend de l'action :
+ Les actions de création et de test ajoutées à un flux de travail le 26 mars 2024 ou après cette date incluront une `Container` section dans leur définition YAML qui spécifie explicitement une [image de mars 2024](#build.default-image). Vous pouvez éventuellement supprimer la `Container` section pour revenir à l'[image de novembre 2022](#build.previous-image).
+ Les actions de création et de test ajoutées à un flux de travail avant le 26 mars 2024 *n'*incluront aucune `Container` section dans leur définition YAML et utiliseront par conséquent une [image de novembre 2022](#build.previous-image). Vous pouvez conserver l'image de novembre 2022 ou la mettre à jour. Pour mettre à niveau l'image, ouvrez l'action dans l'éditeur visuel, choisissez l'onglet **Configuration**, puis sélectionnez l'image de mars 2024 dans la liste déroulante des **images docker de l'environnement d'exécution**. Cette sélection ajoutera une `Container` section à la définition YAML de l'action qui sera remplie avec l'image de mars 2024 appropriée.
+ Toutes les autres actions utiliseront une image de [novembre 2022 ou une image](#build.previous-image) de [mars 2024](#build.default-image). Pour plus d'informations, consultez la documentation de l'action.
**Topics**
+ [Images du mois de mars 2024](#build.default-image)
+ [Images de novembre 2022](#build.previous-image)
### Images du mois de mars 2024
Les images de mars 2024 sont les dernières images fournies par CodeCatalyst. Il existe une image de mars 2024 par type/fleet combinaison de calcul.
Le tableau suivant présente les outils installés sur chaque image de mars 2024.
**Outils d'image de mars 2024**
| Outil | CodeCatalyst Amazon EC2 pour Linux x86\$164 - `CodeCatalystLinux_x86_64:2024_03` | CodeCatalyst Lambda pour Linux x86\$164 - `CodeCatalystLinuxLambda_x86_64:2024_03` | CodeCatalyst Amazon EC2 pour Linux Arm64 - `CodeCatalystLinux_Arm64:2024_03` | CodeCatalyst Lambda pour Linux Arm64 - `CodeCatalystLinuxLambda_Arm64:2024_03` |
| --- | --- | --- | --- | --- |
| AWS CLI | 2,1,17 | 2,1,17 | 2,1,17 | 2,1,17 |
| AWS CLI du copilote | 1,32.1 | 1,32.1 | 1,32.1 | 1,32.1 |
| Docker | 24,0,9 | N/A | 24,0,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 | 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 | 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 |
### Images de novembre 2022
Il existe une image de novembre 2022 par type/fleet combinaison de calcul. Une image Windows de novembre 2022 est également disponible avec l'action de génération si vous avez configuré un [parc provisionné](workflows-working-compute.md#compute.fleets).
Le tableau suivant montre les outils installés sur chaque image de novembre 2022.
**outils d'image de novembre 2022**
| Outil | CodeCatalyst Amazon EC2 pour Linux x86\$164 - `CodeCatalystLinux_x86_64:2022_11` | CodeCatalyst Lambda pour Linux x86\$164 - `CodeCatalystLinuxLambda_x86_64:2022_11` | CodeCatalyst Amazon EC2 pour Linux Arm64 - `CodeCatalystLinux_Arm64:2022_11` | CodeCatalyst Lambda pour Linux Arm64 - `CodeCatalystLinuxLambda_Arm64:2022_11` | CodeCatalyst Amazon EC2 pour Windows x86\$164 - `CodeCatalystWindows_x86_64:2022_11` |
| --- | --- | --- | --- | --- | --- |
| AWS CLI | 2,1,17 | 2,1,17 | 2,1,17 | 2,1,17 | 2,13,19 |
| AWS CLI du copilote | 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 | 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/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 |
## Et si une image active n'inclut pas les outils dont j'ai besoin ?
Si aucune des [images actives](#build-curated-images) fournies par n' CodeCatalyst inclut les outils dont vous avez besoin, plusieurs options s'offrent à vous :
+ Vous pouvez fournir une image Docker d'environnement d'exécution personnalisée qui inclut les outils nécessaires. Pour de plus amples informations, veuillez consulter [Affectation d'une image Docker d'environnement d'exécution personnalisée à une action](#build-images-specify).
**Note**
Si vous souhaitez fournir une image Docker d'environnement d'exécution personnalisée, assurez-vous que Git est installé sur votre image personnalisée.
+ Vous pouvez demander à l'action de création ou de test de votre flux de travail d'installer les outils dont vous avez besoin.
Par exemple, vous pouvez inclure les instructions suivantes dans la `Steps` section du code YAML de l'action de compilation ou de test :
```
Configuration:
Steps:
- Run: ./setup-script
```
L'*setup-script*instruction exécuterait ensuite le script suivant pour installer le gestionnaire de packages 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
```
Pour plus d'informations sur l'action de génération YAML, consultez[Créez et testez des actions YAML](build-action-ref.md).
## Affectation d'une image Docker d'environnement d'exécution personnalisée à une action
Si vous ne souhaitez pas utiliser une [image active](#build-curated-images) fournie par CodeCatalyst, vous pouvez fournir une image Docker d'environnement d'exécution personnalisée. Si vous souhaitez fournir une image personnalisée, assurez-vous que Git y est installé. L'image peut résider dans Docker Hub, Amazon Elastic Container Registry ou dans n'importe quel référentiel public.
Pour savoir comment créer une image Docker personnalisée, consultez la section [Conteneuriser une application](https://docs.docker.com/get-started/02_our_app/) dans la documentation Docker.
Suivez les instructions suivantes pour attribuer l'image Docker de votre environnement d'exécution personnalisé à une action. Après avoir spécifié une image, elle la CodeCatalyst déploie sur votre plateforme de calcul lorsque l'action démarre.
**Note**
Les actions suivantes ne prennent pas en charge les images Docker de l'environnement d'exécution personnalisé : **Deploy CloudFormation stack**, **Deploy to ECS** et **GitHub Actions. Les** images Docker de l'environnement d'exécution personnalisé ne prennent pas non plus en charge le type de calcul **Lambda**.
------
#### [ Visual ]
**Pour attribuer une image Docker à un environnement d'exécution personnalisé à l'aide de l'éditeur visuel**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. Dans le diagramme du flux de travail, choisissez l'action qui utilisera l'image Docker de votre environnement d'exécution personnalisé.
1. Cliquez sur l’onglet **Configuration**.
1. En bas de la page, remplissez les champs suivants.
**Image Docker de l'environnement d'exécution - facultatif**
Spécifiez le registre dans lequel votre image est stockée. Les valeurs valides sont les suivantes :
+ `CODECATALYST`(éditeur YAML)
L'image est enregistrée dans le CodeCatalyst registre.
+ **Docker Hub** (éditeur visuel) ou `DockerHub` (éditeur YAML)
L'image est stockée dans le registre d'images de Docker Hub.
+ **Autre registre** (éditeur visuel) ou `Other` (éditeur YAML)
L'image est stockée dans un registre d'images personnalisé. Tout registre accessible au public peut être utilisé.
+ **Amazon Elastic Container Registry** (éditeur visuel) ou `ECR` (éditeur YAML)
L'image est stockée dans un référentiel d'images Amazon Elastic Container Registry. Pour utiliser une image dans un référentiel Amazon ECR, cette action nécessite l'accès à Amazon ECR. Pour activer cet accès, vous devez créer un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) incluant les autorisations suivantes et une politique de confiance personnalisée. (Vous pouvez modifier un rôle existant pour inclure les autorisations et la politique, si vous le souhaitez.)
Le rôle IAM doit inclure les autorisations suivantes dans sa politique de rôle :
+ `ecr:BatchCheckLayerAvailability`
+ `ecr:BatchGetImage`
+ `ecr:GetAuthorizationToken`
+ `ecr:GetDownloadUrlForLayer`
Le rôle IAM doit inclure la politique de confiance personnalisée suivante :
Pour plus d'informations sur la création de rôles IAM, consultez la section [Création d'un rôle à l'aide de politiques de confiance personnalisées (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) dans le guide de l'*utilisateur IAM*.
Une fois le rôle créé, vous devez l'attribuer à l'action par le biais d'un environnement. Pour de plus amples informations, veuillez consulter [Associer un environnement à une action](deploy-environments-add-app-to-environment.md).
**URL de l'image ECR****, image **Docker Hub ou URL de l'image****
Spécifiez l’un des éléments suivants :
+ Si vous utilisez un `CODECATALYST` registre, définissez l'image sur l'une des [images actives](#build-curated-images) suivantes :
+ `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`
+ Si vous utilisez un registre Docker Hub, attribuez à l'image le nom de l'image Docker Hub et la balise facultative.
Exemple : `postgres:latest`
+ Si vous utilisez un registre Amazon ECR, définissez l'image sur l'URI du registre Amazon ECR.
Exemple : `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo`
+ Si vous utilisez un registre personnalisé, définissez l'image sur la valeur attendue par le registre personnalisé.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour attribuer une image Docker à un environnement d'exécution personnalisé à l'aide de l'éditeur YAML**
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Recherchez l'action à laquelle vous souhaitez attribuer une image Docker de l'environnement d'exécution.
1. Dans l'action, ajoutez une `Container` section, un sous-jacent `Registry` et `Image` des propriétés. Pour plus d'informations, consultez la `Container` description `Registry` et les `Image` propriétés [Actions](workflow-reference.md#actions-reference) de votre action.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
## Exemples
Les exemples suivants montrent comment attribuer une image Docker d'environnement d'exécution personnalisée à une action dans le fichier de définition du flux de travail.
**Topics**
+ [Exemple : utilisation d'une image Docker d'environnement d'exécution personnalisée pour ajouter la prise en charge de Node.js 18 avec Amazon ECR](#workflows-working-custom-image-ex-ecr-node18)
+ [Exemple : utilisation d'une image Docker d'environnement d'exécution personnalisée pour ajouter la prise en charge de Node.js 18 avec Docker Hub](#workflows-working-custom-image-ex-docker-node18)
### Exemple : utilisation d'une image Docker d'environnement d'exécution personnalisée pour ajouter la prise en charge de Node.js 18 avec Amazon ECR
L'exemple suivant montre comment utiliser une image Docker d'environnement d'exécution personnalisée pour ajouter la prise en charge de Node.js 18 avec [Amazon ECR](https://gallery.ecr.aws/amazonlinux/amazonlinux).
```
Configuration:
Container:
Registry: ECR
Image: public.ecr.aws/amazonlinux/amazonlinux:2023
```
### Exemple : utilisation d'une image Docker d'environnement d'exécution personnalisée pour ajouter la prise en charge de Node.js 18 avec Docker Hub
L'exemple suivant montre comment utiliser une image Docker d'environnement d'exécution personnalisée pour ajouter la prise en charge de Node.js 18 avec [Docker Hub](https://hub.docker.com/_/node).
```
Configuration:
Container:
Registry: DockerHub
Image: node:18.18.2
```