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.

# Gérez les flux de travail de création, de test et de distribution pour les images Image Builder
<a name="manage-image-workflows"></a>

Un flux de travail d'image définit la séquence d'étapes qu'EC2 Image Builder exécute au cours d'une étape du processus de création d'image. Vous créez un flux de travail sous forme de document YAML et vous le créez en tant que ressource versionnée et réutilisable. Image Builder exécute ensuite vos flux de travail lorsqu'il crée, teste et distribue vos images.

Les flux de travail vous permettent de contrôler directement le processus de création d'images. Vous décidez quelles étapes s'exécutent, dans quel ordre, ce que fait chaque étape en cas d'échec et si Image Builder annule une étape échouée. Vous pouvez partir d'un flux de travail géré par Amazon, le cloner et le personnaliser, ou créer le vôtre en partant de zéro.

**Avantages du flux de travail d'imagerie**
+ Grâce aux flux de travail d'images, vous bénéficiez d'une flexibilité, d'une visibilité et d'un contrôle accrus sur le processus de création d'images.
+ Vous pouvez ajouter des étapes de flux de travail personnalisées lorsque vous définissez votre document de flux de travail, ou vous pouvez choisir d'utiliser le flux de travail par défaut d'Image Builder.
+ Vous pouvez exclure les étapes du flux de travail qu'Image Builder inclut dans les flux de travail d'imagerie par défaut.
+ Vous pouvez créer des flux de travail de test uniquement qui ignorent complètement le processus de génération. Vous pouvez faire de même pour créer des flux de travail uniquement liés à la création ou à la distribution.

**Note**  
Vous ne pouvez pas modifier un flux de travail existant, mais vous pouvez le cloner ou créer une nouvelle version.

**Astuce**  
Pour plus d'informations sur les exemples de flux de travail déployables, y compris les portes d'approbation et AWS Step Functions l'intégration, consultez les exemples de [ flux de travail ](https://github.com/aws-samples/amazon-ec2-image-builder-samples/tree/HEAD/workflows) sur GitHub. Pour de plus amples informations, veuillez consulter [Découvrez des exemples de projets Image Builder sur GitHub](sample-projects.md).

**Topics**
+ [Structure du flux de travail : étapes](#wf-stages)
+ [Fonctionnement d'un flux de travail](#wf-how-runs)
+ [Surveillez l'exécution du flux de travail avec Amazon EventBridge](#wf-monitor-eventbridge)
+ [Contraintes liées aux ressources du flux](#wf-constraints)
+ [Accès au service](#wf-service-access)
+ [Utilisez des flux de travail gérés pour vos images](#use-managed-workflows)
+ [Répertorier les flux de](list-image-workflows.md)
+ [Création d'un flux de travail d'images](image-workflow-create-resource.md)
+ [Création d'un document de flux de travail YAML](image-workflow-create-document.md)

## Structure du flux de travail : étapes
<a name="wf-stages"></a>

Image Builder organise le processus de création d'images en trois étapes. Chaque étape exécute un flux de travail du * type correspondant*. Les étapes se déroulent dans un ordre fixe et une étape ne commence que lorsque l'étape précédente s'est terminée avec succès.

Le tableau suivant répertorie le comportement par défaut de chaque étape. Comme vous définissez les étapes de chaque flux de travail, vous pouvez personnaliser le fonctionnement d'une étape.


**Étapes du flux de travail Image Builder**  

|  Ordre  |  Étape  |  Type de flux de travail  |  Ce qu'il fait (par défaut)  | 
| --- | --- | --- | --- | 
| 1 | **Build** | `BUILD` | Lance une instance de génération, exécute vos composants de génération et crée une image (AMI ou image de conteneur) à partir de l'instance. | 
| 2 | **Test** | `TEST` | Lance une instance de test à partir de la nouvelle image, exécute vos composants de test et collecte éventuellement les résultats de numérisation de l'image. | 
| 3 | ** Distribution** | `DISTRIBUTION` | Copie l'image dans les régions et les comptes cibles, modifie les attributs de l'image et applique des configurations post-distribution telles que des modèles de lancement et des configurations de licence. | 

Vous ne pouvez exécuter un flux de travail que pour certaines étapes. Par exemple, vous pouvez ignorer l'étape de génération pour tester ou distribuer une image qui existe déjà, ou ignorer l'étape de test pour créer et distribuer sans tester. Pour ignorer la phase de création ou de test, omettez un flux de travail de ce type dans votre pipeline ou votre demande d'image.

**Note**  
Le flux de travail de distribution est facultatif. Si vous l'omettez, Image Builder n'ignore pas la distribution. Il distribue tout de même votre AMI en exécutant la configuration de distribution que vous attachez au pipeline ou à l'image. Ajoutez un flux de distribution lorsque vous souhaitez remplacer cette configuration de distribution par d'autres paramètres de distribution, ou pour obtenir plus de visibilité sur le processus de distribution. Pour ignorer complètement la distribution, fournissez une configuration de distribution nulle ou vide.

**Note**  
Un pipeline d'images ou une demande d'image peut inclure au plus un flux de travail de création et un flux de travail de distribution. Il peut également inclure un ou plusieurs flux de travail de test. Le nombre total de flux de travail ne peut pas dépasser dix. Par exemple, vous pouvez associer un flux de création et un flux de distribution avec jusqu'à huit flux de travail de test.

## Fonctionnement d'un flux de travail
<a name="wf-how-runs"></a>

Un flux de travail exécute ses étapes dans l'ordre dans lequel vous les avez définies dans le document YAML. Chaque étape exécute une action, telle que le lancement d'une instance ou l'exécution de composants.

**Résultats de l'étape**  
Chaque étape se termine dans l'un des états suivants.


**Résultats des étapes du flux de travail**  

|  State  |  Signification  | 
| --- | --- | 
| `COMPLETED` | L'étape s'est terminée avec succès. | 
| `SKIPPED` | Une `if` déclaration conditionnelle sur l'étape évaluée à`false`, Image Builder a donc ignoré l'étape. | 
| `FAILED` | L'étape ne s'est pas terminée correctement. | 
| `WAITING` | Une `WaitForAction` étape est suspendue, en attente d'une action externe. | 
| `TIMED_OUT` | Le pas a duré plus longtemps que sa `timeoutSeconds` valeur. | 

**Gestion des défaillances**  
L'`onFailure`attribut de chaque étape contrôle ce qui se passe en cas d'échec d'une étape.
+ `Abort`(par défaut) — Image Builder échoue à l'étape, échoue au flux de travail et n'exécute aucune autre étape. Si la restauration est activée, elle commence à l'étape qui a échoué et revient aux étapes précédentes.
+ `Continue`— Image Builder échoue à l'étape mais exécute les étapes restantes. Aucun retour en arrière ne se produit.

**Restauration**  
Lorsqu'une étape échoue avec `onFailure: Abort` et `rollbackEnabled: true` (valeur par défaut), Image Builder annule les étapes terminées dans l'ordre inverse, en commençant par l'étape qui a échoué. Toutes les actions ne peuvent pas être annulées. Une action qui n'a pas de retour en arrière enregistre un statut de`NO_ROLLBACK`.

## Surveillez l'exécution du flux de travail avec Amazon EventBridge
<a name="wf-monitor-eventbridge"></a>

Image Builder émet des EventBridge événements Amazon au fur et à mesure de l'exécution de vos flux de travail, afin que vous puissiez réagir à la progression et aux étapes nécessitant une attention particulière. Par exemple, une `WaitForAction` étape publie un événement avec le type de détail dans votre bus `EC2 Image Builder Workflow Step Waiting` d'événements par défaut. Vous pouvez acheminer cet événement vers une cible telle qu'une fonction Lambda ou une rubrique Amazon SNS afin de piloter un processus d'approbation. Pour plus d'informations sur le fonctionnement d'Image Builder EventBridge, consultez[EventBridge Intégration d'Amazon dans Image Builder](integ-eventbridge.md).

Pour suivre la progression au niveau des étapes par programmation, utilisez les opérations`ListWorkflowExecutions`, `GetWorkflowExecution``ListWorkflowStepExecutions`, et `GetWorkflowStepExecution` API.

## Contraintes liées aux ressources du flux
<a name="wf-constraints"></a>

Vos documents et configurations de flux de travail doivent respecter les limites par défaut suivantes.


**Contraintes liées aux ressources du flux**  

|  Contrainte  |  Limite par défaut  |  Remarques  | 
| --- | --- | --- | 
| Étapes par document de flux de travail | 15 | Les étapes s'exécutent dans l'ordre des documents. | 
| Sorties par document de flux de travail | 25 | Les sorties transmettent des valeurs aux flux de travail ultérieurs. | 
| Paramètres par document de flux de travail | 25 | Entrées que l'appelant peut définir. | 
| Longueur de la valeur du paramètre | 1,024 caractères | Par valeur de paramètre. | 
| Taille du document en ligne () `data` | 16 000 octets | Utilisez l'option `uri` (Amazon S3) pour les documents plus volumineux. | 
| Flux de travail par image ou pipeline | 10 | Au plus 1 build et 1 distribution, plus des workflows de test, pour un total combiné de 10. | 

Les ressources du flux de travail sont immuables. Pour modifier un flux de travail, créez une nouvelle version ou clonez-la. Image Builder conserve toutes les versions, afin que vous puissiez suivre le flux de travail qui a produit chaque image.

## Accès au service
<a name="wf-service-access"></a>

Pour exécuter des flux de travail liés à l'imagerie, Image Builder doit être autorisé à effectuer des actions de flux de travail. Vous accordez cette autorisation avec un rôle d'exécution qu'Image Builder assume en votre nom. Vous attribuez le rôle d'exécution comme suit.

**Important**  
Nous vous recommandons de ne pas transmettre le rôle [AWSServiceRoleForImageBuilder](security-iam-awsmanpol.md#sec-iam-manpol-AWSServiceRoleForImageBuilder) lié à un service en tant que rôle d'exécution. Créez plutôt un rôle IAM personnalisé et associez la politique [EC2ImageBuilderExecutionPolicy](security-iam-awsmanpol.md#sec-iam-manpol-EC2ImageBuilderExecutionPolicy) AWS gérée. Cette politique accorde les mêmes autorisations dont Image Builder a besoin pour appeler Services AWS en votre nom. L'utilisation d'un rôle personnalisé vous permet de contrôler totalement les autorisations utilisées par Image Builder. Il permet également de maintenir vos politiques de contrôle des services (SCP) et vos politiques de contrôle des ressources (RCP) en vigueur pour les opérations qu'Image Builder effectue en votre nom.
+ **Console ** : dans l'assistant de pipeline ** Étape 3 Définissez le processus de création d'images**, sélectionnez votre rôle personnalisé dans la ** liste des rôles ** IAM du ** panneau d'accès au ** service.
+ **API Image Builder ** : dans la demande [ CreateImage ](https://docs.aws.amazon.com/imagebuilder/latest/APIReference/API_CreateImage.html) d'action, spécifiez votre rôle personnalisé comme valeur du `executionRole` paramètre.

Pour créer un rôle d'exécution personnalisé, consultez la section [ Création d'un rôle pour déléguer des autorisations à un AWS service ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le Guide de *Gestion des identités et des accès AWS l'utilisateur*.

## Utilisez des flux de travail gérés pour vos images
<a name="use-managed-workflows"></a>

AWS crée et gère des flux de travail gérés. Lorsque vous utilisez des flux de travail gérés dans vos pipelines d'images ou pour la création d'images ponctuelles, vous pouvez sélectionner le nom de ressource Amazon (ARN) du flux de travail géré que vous souhaitez utiliser. Amazon fournit les dernières versions auxquelles des correctifs et autres mises à jour ont été appliqués. Pour obtenir la liste des flux de travail gérés[Répertorier les flux de](list-image-workflows.md), consultez et filtrez sur ** Owner = Amazon ** (console).

Vous pouvez choisir un flux de travail géré en fonction de votre vitesse de création et de vos exigences de validation. Voici des exemples de types de flux de travail gérés :

Workflows gérés standard (par défaut)  
Les flux de travail gérés standard incluent des étapes complètes pour créer, tester et valider vos images avec des contrôles d'état EC2 complets.  
Les flux de travail gérés standard sont les suivants :  
+ **build-image ** — Workflow de création d' Amazon-managed AMI par défaut.
+ **test-image ** — Workflow de test Amazon-managed AMI par défaut.
+ **build-container ** — Workflow de création de Amazon-managed conteneurs par défaut.
+ **test-container ** — Workflow de test de Amazon-managed conteneur par défaut.

Flux de travail gérés Express  
Les flux de travail gérés par Express incluent uniquement les étapes essentielles et réduisent le temps de création d'images.  
Les flux de travail gérés en mode express sont les suivants :  
+ **express-build-image ** — Workflow de création d'Express Amazon-managed AMI qui réduit le temps de génération. Attend uniquement l'état d'exécution de l'instance au lieu des vérifications complètes de l'état EC2, et ignore la collecte de métadonnées d'image.
+ **express-build-container ** — Flux de travail de création de Amazon-managed conteneurs Express qui réduit le temps de génération. Attend uniquement l'état d'exécution de l'instance au lieu de vérifications complètes de l'état EC2.
+ **express-test-image ** — Workflow de test Express Amazon-managed AMI qui réduit la durée des tests. Attend uniquement l'état d'exécution de l'instance au lieu de procéder à des vérifications complètes de l'état EC2, et ignore la collecte des résultats des scans de sécurité.