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.
# Mettre à jour un environnement informatique dans AWS Batch
AWS Batch propose plusieurs stratégies de mise à jour des environnements informatiques, chacune étant conçue pour des scénarios et des exigences de mise à jour spécifiques. Ces approches utilisent la même API de mise à jour sous-jacente mais représentent des méthodes prescriptives différentes pour gérer efficacement les mises à jour. Vous pouvez gérer ces mises à jour à l'aide de la AWS Batch console ou du AWS CLI. La compréhension de ces stratégies vous aide à choisir la méthode la mieux adaptée à vos besoins tout en minimisant les perturbations de vos charges de travail.
Cette rubrique fournit une vue d'ensemble des stratégies de mise à jour disponibles et des conseils sur le moment d'utiliser chaque approche. Pour les procédures détaillées, consultez les sections individuelles de chaque stratégie de mise à jour.
**Important**
AWS Batch crée et gère plusieurs AWS ressources en votre nom et au sein de votre compte, notamment les modèles de lancement Amazon EC2, les groupes Amazon EC2 Auto Scaling, les flottes Amazon EC2 Spot et les clusters Amazon ECS. Ces ressources gérées sont configurées spécifiquement pour garantir un AWS Batch fonctionnement optimal. La modification manuelle de ces ressources AWS Batch gérées, sauf indication contraire dans la AWS Batch documentation, peut entraîner des comportements inattendus, notamment des environnements `INVALID` informatiques, un comportement de dimensionnement des instances sous-optimal, des retards dans le traitement des charges de travail ou des coûts imprévus. Ces modifications manuelles ne peuvent pas être prises en charge de manière déterministe par le AWS Batch service. Utilisez toujours le support AWS Batch APIs ou la AWS Batch console pour gérer vos environnements informatiques.
Les modifications manuelles non prises en charge incluent l'exécution de vos propres tâches ou services Amazon ECS sur des AWS Batch clusters Amazon ECS gérés, ou le lancement de processus, de démons ou de services supplémentaires directement sur des instances gérées par ces derniers. AWS Batch AWS Batch assume le contrôle total des ressources de calcul dans un environnement informatique géré et peut mettre fin à des instances, arrêter des tâches ou dimensionner le cluster à tout moment. Toutes les charges de travail que vous exécutez en dehors des soumissions de AWS Batch travail sur ces ressources gérées peuvent être interrompues sans avertissement. L'exécution de AWS Batch charges de travail non gérées sur des clusters et des instances AWS Batch gérés peut également interférer avec la planification des AWS Batch tâches et le dimensionnement des instances.
**Topics**
+ [Stratégies de mise à jour des environnements informatiques](#update-strategies)
+ [Choisir la bonne stratégie de mise à jour](#choosing-update-strategies)
+ [Considérations relatives à la mise à jour de](#ami-update-considerations)
+ [Effectuer des mises à jour de dimensionnement](scaling-updates.md)
+ [Effectuer des mises à jour d'infrastructure](infrastructure-updates.md)
+ [Effectuer des blue/green mises à jour pour les environnements informatiques](blue-green-updates.md)
## Stratégies de mise à jour des environnements informatiques
Lorsque vous utilisez le dimensionnement ou les mises à jour de l'infrastructure, votre environnement informatique est mis à jour sur place. Pour la stratégie de blue/green mise à jour, vous créez un nouvel environnement informatique (vert), puis vous migrez votre charge de travail de l'ancien environnement informatique (bleu) vers le nouvel environnement informatique (vert).
AWS Batch propose trois stratégies différentes pour les mises à jour de l'environnement de calcul :
Mises à jour relatives
Les mises à jour de dimensionnement ajustent la capacité de votre environnement informatique en ajoutant ou en supprimant des instances sans remplacer les instances existantes. Il s'agit du scénario de mise à jour le plus rapide et ne nécessite aucun temps d'arrêt. Utilisez les mises à jour de dimensionnement lorsque vous devez modifier les paramètres de capacité (vCPUs). Ces mises à jour sont généralement effectuées en quelques minutes.
Les mises à jour Fargate sont effectuées selon les mêmes procédures que les mises à jour de dimensionnement. Pour de plus amples informations, veuillez consulter [Effectuer des mises à jour de dimensionnement](scaling-updates.md).
Mises à jour de
Les mises à jour de l'infrastructure remplacent les instances de votre environnement informatique par de nouvelles instances dont les paramètres ont été mis à jour. Ces mises à jour nécessitent des configurations de rôles de service et de stratégie d'allocation spécifiques, mais elles réduisent au minimum les temps d'arrêt, les tâches en cours pouvant être interrompues. Utilisez les mises à jour de l'infrastructure lorsque vous devez modifier les types d'instances, la configuration de l'AMI, les paramètres réseau, le rôle de service, l'état de l'environnement ou d'autres composants de l'infrastructure. Ces mises à jour sont généralement effectuées en 10 à 30 minutes en fonction de l'achèvement de la tâche.
Pour de plus amples informations, veuillez consulter [Effectuer des mises à jour d'infrastructure](infrastructure-updates.md).
Mises à jour bleu/vert
Blue/green updates create a new compute environment alongside your existing environment, allowing gradual workload transition with zero downtime. This approach provides the safest update path but requires running two environments temporarily. Use blue/greenmises à jour lorsque vous n'avez besoin d'aucune interruption de service, que vous souhaitez tester les modifications avant le déploiement complet, que vous avez besoin d'une fonctionnalité de restauration rapide ou que vous utilisez des configurations non prises en charge pour les mises à jour de l'infrastructure. Le temps nécessaire pour terminer est variable et vous pouvez le contrôler.
Pour de plus amples informations, veuillez consulter [Effectuer des blue/green mises à jour pour les environnements informatiques](blue-green-updates.md).
## Choisir la bonne stratégie de mise à jour
Utilisez ce guide de décision pour sélectionner la stratégie de mise à jour la mieux adaptée à vos besoins :
### Choisissez de dimensionner les mises à jour lorsque
Choisissez la stratégie de mise à jour du dimensionnement lorsque vous devez uniquement ajuster la capacité de calcul (vCPUs). Les mises à jour évolutives sont idéales lorsque vous avez besoin de mises à jour rapides, sans interruption ni modification de la configuration de l'infrastructure.
Pour connaître les procédures détaillées, consultez [Effectuer des mises à jour de dimensionnement](scaling-updates.md).
### Choisissez les mises à jour de l'infrastructure quand
Choisissez la stratégie de mise à jour de l'infrastructure lorsque vous devez modifier les types d'instances, les paramètres de l'AMI, le rôle du service, l'état de l'environnement ou la configuration réseau. Votre environnement doit utiliser le rôle *AWSServiceRoleForBatch*lié au service et une stratégie d'allocation de `BEST_FIT_PROGRESSIVE``SPOT_CAPACITY_OPTIMIZED`, ou. `SPOT_PRICE_CAPACITY_OPTIMIZED` Les mises à jour de l'infrastructure fonctionnent bien lorsqu'une interruption de travail est acceptable pendant la mise à jour et que vous souhaitez des mises à jour automatiques de la dernière AMI optimisée pour Amazon ECS.
Pour connaître les procédures détaillées, consultez [Effectuer des mises à jour d'infrastructure](infrastructure-updates.md).
### Choisissez les blue/green mises à jour lorsque
Choisissez la stratégie de blue/green mise à jour lorsque aucune interruption de service n'est requise pour vos charges de travail ou lorsque vous devez tester les modifications avant de transférer les charges de travail de production. Cette approche est essentielle lorsque la capacité de restauration rapide est importante, que votre environnement utilise une stratégie `BEST_FIT` d'allocation ou que votre environnement n'utilise pas le rôle lié au *AWSServiceRoleForBatch*service. Blue/green les mises à jour sont également le meilleur choix lorsque vous utilisez des fonctionnalités personnalisées AMIs qui nécessitent des mises à jour manuelles ou des modifications de configuration majeures.
Pour connaître les procédures détaillées, consultez [Effectuer des blue/green mises à jour pour les environnements informatiques](blue-green-updates.md).
## Considérations relatives à la mise à jour de
L'approche de mise à jour AMIs dépend de la configuration de votre environnement informatique.
### Mise à jour de l'AMI par défaut AWS Batch fournie vers la dernière version
AWS Batch peut être mis à jour vers la dernière AMI optimisée pour Amazon ECS lors des mises à jour de [l'infrastructure](infrastructure-updates.md#infrastructure-updates.title) lorsque toutes les conditions suivantes sont remplies :
**Note**
Une fois la mise à jour de l'infrastructure terminée, elle `updateToLatestImageVersion` est définie sur`false`. Pour lancer une autre mise à jour`updateToLatestImageVersion`, il doit être réglé sur`true`.
+ L'environnement de calcul utilise le rôle *AWSServiceRoleForBatch*lié au service
+ La stratégie d'allocation est définie pour `BEST_FIT_PROGRESSIVE``SPOT_CAPACITY_OPTIMIZED`, ou `SPOT_PRICE_CAPACITY_OPTIMIZED`
+ Aucun ID d'AMI n'est explicitement spécifié dans `imageId``imageIdOverride`, ni dans le modèle de lancement
+ Le `updateToLatestImageVersion` est réglé sur `true`
### Mises à jour des AMI à l'aide blue/green du déploiement
Vous devez utiliser blue/green le déploiement pour effectuer la mise à jour AMIs dans les scénarios suivants :
+ Lors de l'utilisation de la stratégie `BEST_FIT` d'allocation (ne prend pas en charge les mises à jour de l'infrastructure)
+ Lorsque vous n'utilisez pas le rôle *AWSServiceRoleForBatch*[lié au service](using-service-linked-roles-batch-general.md)
### Mises à jour de l'AMI pour une AMI personnalisée
Si vous spécifiez une AMI personnalisée dans le modèle de lancement de l'environnement de calcul, le `imageId` paramètre ou le paramètre de la `imageIdOverride` configuration EC2 ne AWS Batch mettra pas automatiquement à jour votre AMI personnalisée lors des mises à jour de l'infrastructure. Vous pouvez mettre à jour un identifiant d'AMI personnalisé en spécifiant le nouvel identifiant dans le paramètre initialement utilisé lors de la création de l'environnement de calcul. Si vous souhaitez passer à l'utilisation d'une AMI AWS Batch fournie, vous pouvez le faire en supprimant l'ID d'AMI personnalisé dans la mise à jour de votre environnement informatique.
# Effectuer des mises à jour de dimensionnement
Les mises à jour de dimensionnement ajustent la capacité de votre environnement informatique en ajoutant ou en supprimant des instances. Il s'agit de la stratégie de mise à jour la plus rapide et elle ne nécessite pas le remplacement des instances existantes. Les mises à jour évolutives fonctionnent avec tous les types de rôles de service et toutes les stratégies d'allocation, ce qui en fait l'option de mise à jour la plus flexible.
## Modifications qui déclenchent une mise à jour du dimensionnement
Lorsque vous modifiez uniquement les paramètres suivants, AWS Batch effectue une mise à jour de la mise à l'échelle. Si vous modifiez l'un de ces paramètres ainsi que d'autres paramètres de l'environnement de calcul, effectuez plutôt AWS Batch une [mise à jour de l'infrastructure](infrastructure-updates.md#infrastructure-updates.title).
Les paramètres suivants déclenchent des mises à jour de dimensionnement lorsqu'ils sont modifiés exclusivement :
+ `desiredvCpus`— Définit le nombre cible de v CPUs pour l'environnement.
+ `maxvCpus`— Définit le nombre maximum de v CPUs pouvant être lancés.
+ `minvCpus`— Spécifie le nombre minimum de v CPUs à maintenir.
+ `minScaleDownDelayMinutes`— Spécifie la durée minimale (en minutes) pendant laquelle les instances AWS Batch continuent de fonctionner dans l'environnement informatique une fois leurs tâches terminées.
**Note**
`minScaleDownDelayMinutes`ne s'applique pas aux instances remplacées lors des mises à jour de l'infrastructure.
Pour les environnements informatiques Fargate, vous pouvez également modifier les paramètres suivants pour dimensionner les mises à jour :
+ `securityGroupIds`— Groupe de sécurité IDs pour l'environnement informatique.
+ `subnets`— Sous-réseaux pour l'environnement informatique.
**Note**
Nous vous recommandons de ne pas l'utiliser `desiredvCpus` pour lancer une mise à jour du dimensionnement car AWS Batch cela s'ajustera dynamiquement`desiredvCpus`. Vous devriez plutôt effectuer une mise à jour`minvCpus`.
Lors de la mise à jour`desiredvCpus`, la valeur doit être comprise entre `minvCpus` et`maxvCpus`. La nouvelle valeur doit être supérieure ou égale à la valeur actuelle`desiredvCpus`. Pour de plus amples informations, veuillez consulter [Message d'erreur lorsque vous mettez à jour le `desiredvCpus` paramètre](error-desired-vcpus-update.md).
**Important**
Si vous modifiez l'un de ces paramètres de dimensionnement conjointement avec d'autres paramètres d'environnement de calcul (tels que les types d'instances, les AMI ou les modèles de lancement) IDs, AWS Batch effectuez une mise à jour de l'infrastructure au lieu d'une mise à jour de la mise à l'échelle. Les mises à jour de l'infrastructure prennent plus de temps et peuvent remplacer les instances existantes.
------
#### [ Performing scaling updates using the AWS Management Console ]
1. Ouvrez la AWS Batch console à l'adresse [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. Dans le volet de navigation, choisissez **Environments**, puis l'onglet **Compute environments**.
1. Sélectionnez l'environnement informatique à mettre à jour.
1. Choisissez **Actions**, puis **Modifier**.
1. Modifiez un ou plusieurs [paramètres qui prennent en charge les mises à jour de dimensionnement](#scaling-updates-triggers). Par exemple :
+ Pour **Minimum v CPUs**, entrez le nombre minimum de CPUs v.
+ Pour **Desired v CPUs**, entrez le nombre souhaité de CPUs v.
+ Pour **Maximum v CPUs**, entrez le nombre maximum de CPUs v.
1. Sélectionnez **Enregistrer les modifications**.
1. Surveillez l'état de l'environnement informatique. La mise à jour devrait se terminer rapidement car elle ne concerne que des opérations de dimensionnement.
------
#### [ Performing scaling updates using the AWS CLI ]
Utilisez la **update-compute-environment** commande pour effectuer des mises à jour de dimensionnement. Les deux exemples suivants illustrent les opérations de dimensionnement courantes. Vous pouvez modifier un ou plusieurs des [paramètres suivants qui prennent en charge les mises à jour de dimensionnement](#scaling-updates-triggers)
+ Cet exemple met à jour le v souhaité, le minimum et le maximum CPUs :
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources minvCpus=2,maxvCpus=8
```
------
## Surveillance des mises à jour du dimensionnement
Surveillez vos mises à jour de dimensionnement à l'aide de la AWS Batch console pour consulter l'état de l'environnement de calcul et vérifier le nombre d'instances et les métriques de vCPU. Vous pouvez également utiliser la **describe-compute-environments** commande AWS CLI with the pour vérifier l'état et surveiller le nombre d'instances et les valeurs des vCPU.
# Effectuer des mises à jour d'infrastructure
Les mises à jour de l'infrastructure remplacent les instances de votre environnement informatique par de nouvelles instances dont les paramètres ont été mis à jour. Cette stratégie de mise à jour prend plus de temps que le dimensionnement des mises à jour et nécessite des paramètres de rôle de service et de stratégie d'allocation spécifiques. Les mises à jour de l'infrastructure permettent de modifier les configurations fondamentales de l'environnement informatique tout en maintenant la disponibilité des services.
**Important**
Les mises à jour de l'infrastructure nécessitent le rôle *AWSServiceRoleForBatch*lié au service et une stratégie d'allocation de `BEST_FIT_PROGRESSIVE``SPOT_CAPACITY_OPTIMIZED`, ou. `SPOT_PRICE_CAPACITY_OPTIMIZED` Si votre environnement ne répond pas à ces exigences, utilisez plutôt des blue/green mises à jour.
## Changements déclenchant des mises à jour de l'infrastructure
Lorsque vous modifiez l'un des paramètres suivants, AWS Batch effectue une mise à jour de l'infrastructure. Les mises à jour de l'infrastructure se produisent également lorsque vous modifiez ces paramètres en même temps que les paramètres de mise à jour du dimensionnement.
Les paramètres suivants déclenchent les mises à jour de l'infrastructure :
**Configuration de calcul**
+ `allocationStrategy`— Détermine le mode de AWS Batch sélection des types d'instances.
+ `instanceTypes`— Spécifie les types d'instances EC2 à utiliser.
+ `bidPercentage`— Pourcentage maximum du prix à la demande pour les instances Spot.
+ `type`— Type d'environnement de calcul (`EC2`ou`SPOT`).
**AMI et configuration de lancement**
+ `imageId`— AMI spécifique à utiliser pour les instances.
+ `ec2Configuration`— Configuration EC2, y compris`imageIdOverride`.
+ `launchTemplate`— Paramètres du modèle de lancement EC2.
+ `ec2KeyPair`— Paire de clés SSH pour l'accès à l'instance.
+ `updateToLatestImageVersion`— Paramètre de mise à jour automatique de l'AMI.
**Mise en réseau et sécurité**
+ `subnets`— Sous-réseaux VPC où les instances sont lancées (pour les environnements de calcul EC2).
+ `securityGroupIds`— Groupes de sécurité pour les instances (pour les environnements informatiques EC2).
+ `placementGroup`— Configuration du groupe de placement EC2.
**Autres paramètres**
+ `instanceRole`— Rôle IAM pour les instances EC2.
+ `tags`— Balises appliquées aux instances EC2.
**Important**
Si vous modifiez des paramètres de mise à jour de l'infrastructure en même temps que des paramètres de mise à jour de dimensionnement (tels que `desiredvCpus``maxvCpus`, ou`minvCpus`), AWS Batch effectue une mise à jour de l'infrastructure. Les mises à jour de l'infrastructure prennent plus de temps que les mises à niveau.
## Sélection des AMI lors des mises à jour de l'infrastructure
Lors d'une mise à jour de l'infrastructure, l'ID AMI de l'environnement de calcul peut changer, selon qu'il AMIs est spécifié ou non dans l'un de ces trois paramètres. AMIs sont spécifiés dans le `imageId` (in`computeResources`), `imageIdOverride` (in`ec2Configuration`) ou le modèle de lancement spécifié dans`launchTemplate`. Supposons qu'aucune AMI IDs ne soit spécifiée dans aucun de ces paramètres et que le `updateToLatestImageVersion` paramètre soit`true`. Ensuite, la dernière AMI optimisée Amazon ECS prise en charge par AWS Batch est utilisée pour toute mise à jour de l'infrastructure.
Si un ID d'AMI est spécifié dans au moins l'un de ces paramètres, la mise à jour dépend du paramètre qui a fourni l'ID d'AMI utilisé avant la mise à jour. Lorsque vous créez un environnement informatique, la priorité pour sélectionner un ID d'AMI est d'abord le modèle de lancement, puis le `imageId` paramètre, et enfin le `imageIdOverride` paramètre. Toutefois, si l'ID d'AMI utilisé provient du modèle de lancement, la mise à jour des `imageIdOverride` paramètres `imageId` ou des paramètres ne met pas à jour l'ID d'AMI. La seule façon de mettre à jour un ID d'AMI sélectionné dans le modèle de lancement est de mettre à jour le modèle de lancement. Si le paramètre de version du modèle de lancement est `$Default` ou`$Latest`, la version par défaut ou la dernière version du modèle de lancement spécifié est évaluée. Si un autre ID d'AMI est sélectionné par défaut ou si la dernière version du modèle de lancement est sélectionnée, cet ID d'AMI est utilisé dans la mise à jour.
Si le modèle de lancement n'a pas été utilisé pour sélectionner l'ID d'AMI, l'ID d'AMI spécifié dans les `imageIdOverride` paramètres `imageId` ou est utilisé. Si les deux sont spécifiés, l'ID d'AMI spécifié dans le `imageIdOverride` paramètre est utilisé.
Supposons que l'environnement de calcul utilise un ID d'AMI spécifié par les `launchTemplate` paramètres `imageId``imageIdOverride`, ou, et que vous souhaitiez utiliser la dernière AMI optimisée pour Amazon ECS prise en charge par AWS Batch. Ensuite, la mise à jour doit supprimer les paramètres qui ont fourni l'AMI IDs. En `imageId` effet, cela nécessite de spécifier une chaîne vide pour ce paramètre. En `imageIdOverride` effet, cela nécessite de spécifier une chaîne vide pour le `ec2Configuration` paramètre.
Si l'ID d'AMI provient du modèle de lancement, vous pouvez passer à la dernière AMI optimisée pour Amazon ECS prise AWS Batch en charge de l'une des manières suivantes :
+ Supprimez le modèle de lancement en spécifiant une chaîne vide pour le `launchTemplateName` paramètre `launchTemplateId` or. Cela supprime l'intégralité du modèle de lancement, plutôt que le seul ID de l'AMI.
+ Si la version mise à jour du modèle de lancement ne spécifie pas d'ID d'AMI, le `updateToLatestImageVersion` paramètre doit être défini sur`true`.
## Gestion des tâches pendant les mises à jour
Configurez le mode de gestion des tâches en cours lors d'une mise à jour de l'infrastructure à l'aide de la politique de mise à jour. Lorsque vous définissez`terminateJobsOnUpdate=true`, les tâches en cours d'exécution sont immédiatement interrompues, le `jobExecutionTimeoutMinutes` paramètre est ignoré et la mise à jour se poursuit dès que les instances peuvent être remplacées. Lorsque vous le définissez`terminateJobsOnUpdate=false`, les tâches en cours d'exécution se poursuivent pendant la période spécifiée avec un délai d'expiration par défaut de 30 minutes, et les tâches sont interrompues si elles dépassent le délai d'expiration.
**Note**
Pour réessayer des tâches interrompues lors d'une mise à jour, configurez une stratégie de nouvelle tentative de tâche. Pour de plus amples informations, veuillez consulter [Nouvelles tentatives de travail automatisées](job_retries.md).
------
#### [ Performing infrastructure updates using the AWS Management Console ]
1. Ouvrez la AWS Batch console à l'adresse [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. Dans le volet de navigation, choisissez **Environments** puis l'onglet **Compute environments**.
1. Sélectionnez l'environnement informatique à mettre à jour.
1. Choisissez **Actions**, puis **Modifier**.
1. Dans la section **Comportement des mises à jour**, configurez le mode de gestion des tâches en cours d'exécution :
+ Choisissez **Mettre à jour l'AMI vers la dernière version** pour mettre à jour l'AMI vers la dernière version.
+ Choisissez **Terminer les tâches immédiatement après la mise à jour** pour terminer les tâches lorsque le processus de mise à jour est exécuté.
+ Pour le **délai d'exécution du Job**, entrez le nombre de minutes à attendre avant de démarrer le processus de mise à jour.
1. Modifiez un ou plusieurs [paramètres qui nécessitent une mise à jour de l'infrastructure](#infrastructure-updates-triggers). Par exemple :
+ **Rôle de l'instance**
+ **Utiliser des instances EC2 Spot**
+ **Types d'instances autorisés**
+ **Groupe de placement**
+ **Paire de clés EC2**
+ **Configuration EC2**
+ **Modèles de lancement**
+ **Sous-réseaux**
+ **Groupes de sécurité**
1. Sélectionnez **Enregistrer les modifications**.
1. Surveillez l'état de l'environnement informatique. L'environnement s'affichera `UPDATING` pendant le processus de mise à jour.
------
#### [ Performing infrastructure updates using the AWS CLI ]
Utilisez la **update-compute-environment** commande pour modifier un ou plusieurs [paramètres nécessitant une mise à jour de l'infrastructure](#infrastructure-updates-triggers). Les trois exemples suivants sont des opérations d'infrastructure courantes.
+ Cet exemple met à jour les types d'instances et configure la politique de mise à jour :
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources instanceTypes=default_x86_64 \
--update-policy terminateJobsOnUpdate=false,jobExecutionTimeoutMinutes=30
```
+ Cet exemple met à jour les sous-réseaux et les groupes de sécurité VPC :
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources subnets=subnet-abcd1234,subnet-efgh5678 securityGroupIds=sg-abcd1234 \
--update-policy terminateJobsOnUpdate=true
```
+ Cet exemple active les mises à jour automatiques de la dernière AMI optimisée pour Amazon ECS :
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources updateToLatestImageVersion=true \
--update-policy terminateJobsOnUpdate=false,jobExecutionTimeoutMinutes=60
```
------
## Mises à jour de l'infrastructure
Surveillez les mises à jour de votre infrastructure à l'aide de la AWS Batch console pour suivre l'évolution de l'état de l'environnement informatique`UPDATING`, suivre la progression du remplacement des instances et vérifier l'absence d'échec des mises à jour. La mise à jour est réussie une fois que l'état de l'environnement de calcul est atteint`VAILD`. Vous pouvez également l'utiliser CloudWatch pour suivre les événements de cessation d'instance et surveiller l'état des tâches pendant la mise à jour. À l'aide de AWS CLI, utilisez la **describe-compute-environments** commande pour vérifier l'état et surveiller les événements du cycle de vie de l'instance.
# Effectuer des blue/green mises à jour pour les environnements informatiques
Une blue/green mise à jour est une stratégie de mise à jour qui réduit les temps d'arrêt et les risques en créant un nouvel environnement informatique (vert) en plus de votre environnement informatique existant (bleu). Cette approche vous permet de transférer progressivement les charges de travail vers le nouvel environnement tout en maintenant le fonctionnement de l'environnement existant. Blue/green les mises à jour fournissent le chemin de mise à jour le plus sûr et fonctionnent avec tous les types de rôles de service ou de stratégie d'allocation.
## Présentation de
Les mises à jour bleu/vert offrent plusieurs avantages qui les rendent idéales pour les environnements de production. Ils *n'offrent aucun temps d'arrêt* en assurant le fonctionnement continu de vos charges de travail pendant le processus de mise à jour. Cette approche permet des fonctionnalités de *restauration faciles*, vous permettant de revenir rapidement à l'environnement d'origine en cas de problème. Vous pouvez mettre en œuvre une stratégie de *transition progressive*, en vérifiant les performances du nouvel environnement avant de transférer complètement vos charges de travail de production. Cette méthode permet également une excellente *atténuation des risques* puisque l'environnement d'origine reste inchangé et opérationnel jusqu'à ce que vous choisissiez de le supprimer.
### Quand des blue/green mises à jour sont nécessaires
Vous devez utiliser les blue/green mises à jour dans les situations suivantes :
+ Lorsque votre environnement informatique utilise une stratégie `BEST_FIT` d'allocation (ne prend pas en charge les mises à jour de l'infrastructure)
+ Lorsque votre environnement informatique n'utilise pas le rôle lié à *AWSServiceRoleForBatch*un service
+ Quand vous devez passer d'un type de rôle de service à un autre
### Quand des blue/green mises à jour sont recommandées
Blue/green updates are particularly recommended for production environments where zero downtime is critical for your workloads. This approach works well when you need to test new configurations before transitioning production workloads, ensuring that changes meet your performance and reliability requirements. Choose blue/greenmises à jour lorsque la fonctionnalité de restauration rapide est importante pour vos opérations, en particulier si vous effectuez une mise à jour personnalisée AMIs avec des modifications importantes. Cette méthode est également idéale lorsque vous souhaitez valider les caractéristiques de performance et le comportement avant de procéder entièrement aux modifications, afin de garantir la confiance dans votre processus de mise à jour.
### Conditions préalables
Avant d'effectuer une blue/green mise à jour, assurez-vous d'avoir :
+ [Autorisations IAM](IAM_policies.md#IAM_policies.title) appropriées pour créer et gérer des environnements informatiques
+ Accès pour afficher et modifier les paramètres de la file d'attente des tâches
+ Stratégies de nouvelle tentative de tâche configurées pour vos définitions de tâches afin de gérer les échecs potentiels pendant la transition. Pour de plus amples informations, veuillez consulter [Nouvelles tentatives de travail automatisées](job_retries.md).
+ ID AMI du nouvel environnement informatique. Cela peut être soit :
+ Une version récente et approuvée de l'AMI optimisée pour Amazon ECS (utilisée par défaut)
+ Une AMI personnalisée qui répond aux spécifications de l'AMI d'instance de conteneur Amazon ECS. Lorsque vous utilisez une AMI personnalisée, vous pouvez la spécifier de l'une des manières suivantes :
+ Utilisation du champ **Image ID override** dans la configuration EC2
+ Le spécifier dans un modèle de lancement
Pour plus d'informations sur la création de AMIs personnalisations, consultez[Tutoriel : Création d'une AMI de ressources de calcul](create-batch-ami.md).
Avant de créer le nouvel environnement, vous devez enregistrer la configuration de votre environnement informatique existant. Vous pouvez le faire en utilisant le AWS Management Console ou le AWS CLI.
**Note**
Les procédures suivantes expliquent comment effectuer une blue/green mise à jour qui modifie uniquement l'AMI. Vous pouvez mettre à jour d'autres paramètres pour le nouvel environnement.
**Important**
Lorsque vous supprimez l'ancien environnement informatique (bleu), toutes les tâches en cours d'exécution sur ces instances échoueront car les instances seront arrêtées. Configurez des stratégies de nouvelle tentative dans vos définitions de tâches afin de gérer automatiquement ces échecs. Pour de plus amples informations, veuillez consulter [Nouvelles tentatives de travail automatisées](job_retries.md).
Une fois que vous aurez confiance dans le nouvel environnement :
Modifiez la file d'attente des tâches pour supprimer l'ancien environnement informatique.
Attendez que toutes les tâches en cours dans l'ancien environnement soient terminées.
Supprimez l'ancien environnement de calcul.
------
#### [ Performing blue/green updates using the AWS Management Console ]
1. Clonez votre environnement informatique actuel
1. Ouvrez la AWS Batch console à l'adresse [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. Sélectionnez votre environnement informatique existant.
1. Choisissez **Actions**, puis **Cloner**.
1. Dans **Nom**, entrez un nom unique pour votre nouvel environnement informatique.
1. Choisissez **Suivant**.
1. Dans la section **Configuration de l'instance**, mettez à jour les paramètres de l'AMI :
1. Développez **Additional configuration (Configuration supplémentaire)**.
1. Pour la **configuration EC2**, spécifiez le nouveau type d'AMI dans **Type d'image** et l'ID d'AMI dans le champ **Image ID override**.
1. Choisissez **Suivant**.
1. Pour **Configuration réseau**, choisissez **Next**.
1. Passez en revue les autres paramètres qui sont automatiquement copiés depuis votre environnement existant.
1. Choisissez **Créer un environnement informatique**.
1. Attendez que le nouvel état de l'environnement informatique soit atteint`VALID`.
1. Modifier l'ordre de la file d'attente des tâches
1. Dans le volet de navigation, choisissez **Job queues**.
1. Sélectionnez la file d'attente de tâches associée à votre environnement informatique existant.
1. Choisissez **Modifier**.
1. Sous **Environnement informatique connecté**, ajoutez le nouvel environnement de calcul :
+ Ajoutez le nouvel environnement informatique avec un numéro de commande supérieur à celui de l'environnement existant pour transférer la charge de travail.
+ Une fois que vous avez vérifié que le nouvel environnement fonctionne correctement, vous pouvez en faire l'environnement principal en lui attribuant un numéro de commande inférieur.
1. Choisissez **Mettre à jour la file d'attente des tâches**.
1. Nettoyage
1. Surveillez l'exécution des tâches dans le nouvel environnement pour vous assurer que tout fonctionne comme prévu.
1. Une fois que vous aurez confiance dans le nouvel environnement :
1. Modifiez la file d'attente des tâches pour supprimer l'ancien environnement informatique.
1. Attendez que toutes les tâches en cours dans l'ancien environnement soient terminées.
1. Supprimez l'ancien environnement de calcul.
------
#### [ Performing blue/green updates using the AWS CLI ]
1. Pour obtenir la configuration à l'aide de AWS CLI, utilisez la commande suivante :
```
aws batch describe-compute-environments \
--compute-environments your-compute-environment-name
```
Enregistrez la sortie pour référence lors de la création du nouvel environnement.
1. Créez un nouvel environnement informatique en utilisant la configuration de votre environnement existant, mais avec la nouvelle AMI. Voici un exemple de structure de commande :
Remplacez les valeurs d'exemple par votre configuration réelle de l'étape précédente :
```
cat < ./blue-green-compute-environment.json
{
"computeEnvironmentName": "your-new-compute-environment-name",
"type": "MANAGED",
"state": "ENABLED",
"computeResources": {
"instanceRole": "arn:aws:iam::012345678901:instance-profile/ecsInstanceRole",
"type": "EC2",
"minvCpus": 2,
"desiredvCpus": 2,
"maxvCpus": 256,
"instanceTypes": [
"optimal"
],
"allocationStrategy": "BEST_FIT_PROGRESSIVE",
"ec2Configuration": [
{
"imageType": "ECS_AL2023",
"imageIdOverride": "ami-0abcdef1234567890"
}
],
"subnets": [,
"subnet-0abcdef1234567890"
],
"securityGroupIds": [
"sg-0abcdef1234567890"
]
}
}
EOF
```
```
$ aws batch create-compute-environment --cli-input-json file://./blue-green-compute-environment.json
```
1. Attendez que le nouvel environnement soit disponible :
```
aws batch describe-compute-environments \
--compute-environments your-new-compute-environment-name \
--query 'computeEnvironments[].status'
```
1. Ajoutez le nouvel environnement informatique à votre file d'attente de tâches :
```
aws batch update-job-queue \
--job-queue your-job-queue \
--compute-environment-order order=1,computeEnvironment=your-existing-environment \
order=2,computeEnvironment=your-new-compute-environment-name
```
1. Une fois vérifié, effectuez une nouvelle mise à jour pour rendre le nouvel environnement principal :
```
aws batch update-job-queue \
--job-queue your-job-queue \
--compute-environment-order order=1,computeEnvironment=your-new-compute-environment-name
```
Une fois toutes les tâches terminées dans l'ancien environnement, désactivez-le puis supprimez-le :
```
aws batch update-compute-environment \
--compute-environment your-existing-environment \
--state DISABLED
```
```
aws batch delete-compute-environment \
--compute-environment your-existing-environment
```
------