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.
# Stratégies de déploiement
Outre la sélection des bons outils pour mettre à jour le code de votre application et l'infrastructure de support, la mise en œuvre des processus de déploiement appropriés est un élément essentiel d'une solution de déploiement complète et performante. Les processus de déploiement que vous choisissez pour mettre à jour votre application peuvent dépendre de l'équilibre que vous souhaitez atteindre en termes de contrôle, de rapidité, de coût, de tolérance au risque et d'autres facteurs.
Chaque service de déploiement AWS prend en charge un certain nombre de stratégies de déploiement. Cette section fournit une vue d'ensemble des stratégies de déploiement générales qui peuvent être utilisées avec votre solution de déploiement.
# Précuisson ou amorçage AMIs
*Si votre application repose principalement sur la personnalisation ou le déploiement d'applications sur des EC2 instances Amazon, vous pouvez optimiser vos déploiements grâce à des pratiques d'*amorçage* et de précuisson.*
L'installation de votre application, de vos dépendances ou de vos personnalisations à chaque fois qu'une EC2 instance Amazon est lancée s'appelle le *démarrage d'une instance.* Si vous avez besoin d'une application complexe ou de téléchargements volumineux, cela peut ralentir les déploiements et les événements de dimensionnement.
Une [Amazon Machine Image](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) (AMI) fournit les informations requises pour lancer une instance (systèmes d'exploitation, volumes de stockage, autorisations, packages logiciels, etc.). Vous pouvez lancer plusieurs instances identiques à partir d'une seule AMI. Chaque fois qu'une EC2 instance est lancée, vous sélectionnez l'AMI à utiliser comme modèle. Le *précuisson* est le processus qui consiste à intégrer une partie importante des artefacts de votre application dans une AMI.
Le prémontage des composants de l'application dans une AMI peut accélérer le lancement et l'opérationnalisation d'une instance Amazon EC2 . Les pratiques de précuisson et d'amorçage peuvent être combinées au cours du processus de déploiement afin de créer rapidement de nouvelles instances personnalisées en fonction de l'environnement actuel.
# Déploiements bleus/verts
Un blue/green déploiement est une stratégie de déploiement dans laquelle vous créez deux environnements distincts mais identiques. Un environnement (bleu) exécute la version actuelle de l'application et un environnement (vert) exécute la nouvelle version de l'application. L'utilisation d'une stratégie de blue/green déploiement augmente la disponibilité des applications et réduit les risques liés au déploiement en simplifiant le processus de restauration en cas d'échec d'un déploiement. Une fois les tests terminés sur l'environnement vert, le trafic réel des applications est dirigé vers l'environnement vert et l'environnement bleu est obsolète.
Un certain nombre de services de déploiement AWS prennent en charge les stratégies de blue/green déploiement, notamment Elastic OpsWorks Beanstalk CloudFormation,, CodeDeploy, et Amazon ECS. Reportez-vous à la section [Déploiements bleu/vert sur AWS](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html) pour plus de détails et pour connaître les stratégies de mise en œuvre des processus de blue/green déploiement pour votre application.
# Déploiements propagés
Un déploiement progressif est une stratégie de déploiement qui remplace progressivement les versions précédentes d'une application par de nouvelles versions d'une application en remplaçant complètement l'infrastructure sur laquelle l'application s'exécute. Par exemple, lors d'un déploiement continu dans Amazon ECS, les conteneurs exécutant les versions précédentes de l'application seront one-by-one remplacés par des conteneurs exécutant les nouvelles versions de l'application.
Un déploiement progressif est généralement plus rapide qu'un blue/green déploiement ; toutefois, contrairement à un blue/green déploiement continu, il n'y a aucune isolation environnementale entre les anciennes et les nouvelles versions de l'application. Cela permet aux déploiements progressifs de se terminer plus rapidement, mais augmente également les risques et complique le processus de restauration en cas d'échec d'un déploiement.
Les stratégies de déploiement progressif peuvent être utilisées avec la plupart des solutions de déploiement. [Reportez-vous aux [politiques de CloudFormation mise à jour](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-updatepolicy.html) pour plus d'informations sur les déploiements progressifs [avec Amazon ECS CloudFormation ; aux mises à jour](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-ecs.html) continues avec Amazon ECS ; aux mises à jour de [configuration de l'environnement évolutif d'Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.rollingupdates.html) pour plus de détails sur les déploiements progressifs avec Elastic Beanstalk ; et à l'utilisation d'un déploiement progressif pour plus de détails sur le déploiement avec. AWS OpsWorks](https://docs.aws.amazon.com/opsworks/latest/userguide/best-deploy.html#best-deploy-rolling) OpsWorks
# Déploiements Canary
Les [déploiements Canary](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/deployment-strategies.html#canary-deployments) constituent un type de stratégie de blue/green déploiement moins risqué. Cette stratégie implique une approche progressive dans laquelle le trafic est transféré vers une nouvelle version de l'application en deux étapes. Le premier incrément correspond à un faible pourcentage du trafic, que l'on appelle le groupe Canary. Ce groupe est utilisé pour tester la nouvelle version et, en cas de succès, le trafic est transféré vers la nouvelle version au cours du deuxième incrément.
Les déploiements Canary peuvent être mis en œuvre en deux étapes ou de manière linéaire. Dans le cadre de l'approche en deux étapes, le nouveau code d'application est déployé et exposé à des fins d'essai. Une fois accepté, il est déployé soit dans le reste de l'environnement, soit de manière linéaire. L'approche linéaire consiste à augmenter progressivement le trafic vers la nouvelle version de l'application jusqu'à ce que tout le trafic soit acheminé vers la nouvelle version.
# Déploiements sur place
Un [déploiement sur place](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/in-place-deployments.html) est une stratégie de déploiement qui met à jour la version de l'application sans remplacer les composants de l'infrastructure. Lors d'un déploiement sur place, la version précédente de l'application sur chaque ressource de calcul est arrêtée, la dernière application est installée et la nouvelle version de l'application est démarrée et validée. Cela permet aux déploiements d'applications de se dérouler en perturbant le moins possible l'infrastructure sous-jacente.
Un déploiement sur place vous permet de déployer votre application sans créer de nouvelle infrastructure ; toutefois, la disponibilité de votre application peut être affectée lors de ces déploiements. Cette approche minimise également les coûts d'infrastructure et les frais de gestion associés à la création de nouvelles ressources.
Reportez-vous à la section [Présentation d'un déploiement sur place](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-in-place) pour plus de détails sur l'utilisation de stratégies de déploiement sur place avec. CodeDeploy
# Combiner les services de déploiement
Il n'existe pas de solution de déploiement « universelle » sur AWS. Dans le contexte de la conception d'une solution de déploiement, il est important de prendre en compte le type d'application, car cela peut dicter les services AWS les plus appropriés. Pour fournir des fonctionnalités complètes de provisionnement, de configuration, de déploiement, de mise à l'échelle et de surveillance de votre application, il est souvent nécessaire de combiner plusieurs services de déploiement
Un modèle courant pour les applications sur AWS consiste à utiliser CloudFormation (et ses extensions) pour gérer l'infrastructure à usage général et à utiliser une solution de déploiement plus spécialisée pour gérer les mises à jour des applications. Dans le cas d'une application conteneurisée, elle CloudFormation peut être utilisée pour créer l'infrastructure de l'application, et Amazon ECS et Amazon EKS peuvent être utilisés pour approvisionner, déployer et surveiller des conteneurs.
Les services de déploiement AWS peuvent également être combinés à des services de déploiement tiers. Cela permet aux entreprises d'intégrer facilement les services de déploiement AWS dans leurs CI/CD pipelines ou leurs solutions de gestion d'infrastructure existants. Par exemple, il OpsWorks peut être utilisé pour synchroniser les configurations entre les nœuds sur site et les nœuds AWS, et CodeDeploy peut être utilisé avec un certain nombre de CI/CD services tiers dans le cadre d'un pipeline complet.