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.
# Résolution des problèmes CodeDeploy
Utilisez les rubriques de cette section pour résoudre les problèmes et les erreurs que vous pourriez rencontrer lors de l'utilisation CodeDeploy.
**Note**
Vous pouvez identifier les causes de nombreux échecs de déploiement en passant en revue les fichiers journaux créés pendant le processus de déploiement. Pour des raisons de simplicité, nous vous recommandons d'utiliser Amazon CloudWatch Logs pour surveiller les fichiers journaux de manière centralisée au lieu de les consulter instance par instance. Pour plus d'informations, consultez [Surveillance des déploiements à l'aide des outils Amazon CloudWatch](monitoring-cloudwatch.md).
**Topics**
+ [Dépannage des problèmes généraux](troubleshooting-general.md)
+ [Résoudre les problèmes de déploiement d'EC2/sur site](troubleshooting-deployments.md)
+ [Résoudre les problèmes de déploiement d'Amazon ECS](troubleshooting-ecs.md)
+ [Résoudre les problèmes de déploiement AWS de Lambda](troubleshooting-deployments-lambda.md)
+ [Résolution des problèmes de groupe de déploiement](troubleshooting-deployment-groups.md)
+ [Résolution des problèmes d'instance](troubleshooting-ec2-instances.md)
+ [Résoudre les problèmes liés aux GitHub jetons](troubleshooting-github-token-issues.md)
+ [Résoudre les problèmes liés à Amazon EC2 Auto Scaling](troubleshooting-auto-scaling.md)
+ [Codes d'erreur pour AWS CodeDeploy](error-codes.md)
# Dépannage des problèmes généraux
**Topics**
+ [Liste de contrôle de dépannage général](#troubleshooting-checklist)
+ [CodeDeploy les ressources de déploiement ne sont prises en charge que dans certaines AWS régions](#troubleshooting-supported-regions)
+ [Les procédures décrites dans ce guide ne correspondent pas à celles de la CodeDeploy console](#troubleshooting-old-console)
+ [Les rôles IAM requis ne sont pas disponibles](#troubleshooting-iam-cloudformation)
+ [L'utilisation de certains éditeurs de texte pour créer des AppSpec fichiers et des scripts shell peut entraîner l'échec des déploiements.](#troubleshooting-text-editors)
+ [L'utilisation du Finder sur MacOS pour grouper une révision d'application peut entraîner l'échec des déploiements](#troubleshooting-bundle-with-finder)
## Liste de contrôle de dépannage général
Vous pouvez utiliser la liste de contrôle suivante pour dépanner un déploiement ayant échoué.
1. Consultez les rubriques [Afficher les détails CodeDeploy du déploiement](deployments-view-details.md) et [Afficher les détails de l'instance avec CodeDeploy](instances-view-details.md) pour déterminer pourquoi le déploiement a échoué. Si vous ne parvenez pas à déterminer la cause de l’échec, passez en revue les éléments de cette liste de contrôle.
1. Vérifiez que vous avez configuré les instances correctement :
+ L'instance a-t-elle été lancée avec une paire de clés EC2 spécifiée ? Pour plus d'informations, consultez les [paires de clés EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2-key-pairs.html) dans le guide de l'*utilisateur Amazon EC2.*
+ Le profil d'instance IAM approprié est-il attaché à l'instance ? Pour plus d’informations, consultez [Configurer une instance Amazon EC2 pour qu'elle fonctionne avec CodeDeploy](instances-ec2-configure.md) et [Étape 4 : Création d'un profil d'instance IAM pour vos instances Amazon EC2](getting-started-create-iam-instance-profile.md).
+ L'instance a-t-elle été balisée ? Pour plus d'informations, consultez la section [Utilisation des balises dans la console](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) dans le guide de l'*utilisateur Amazon EC2*.
+ L' CodeDeploy agent est-il installé, mis à jour et exécuté sur l'instance ? Pour de plus amples informations, veuillez consulter [Gestion des opérations des CodeDeploy agents](codedeploy-agent-operations.md). Pour vérifier quelle version de l'agent est installée, consultez[Déterminer la version de l' CodeDeploy agent](codedeploy-agent-operations-version.md).
1. Vérifiez les paramètres de l'application et du groupe de déploiement :
+ Pour vérifier les paramètres de votre application, consultez la rubrique [Consultez les détails de l'application avec CodeDeploy](applications-view-details.md).
+ Pour vérifier les paramètres de votre groupe de déploiement, consultez la rubrique [Afficher les détails du groupe de déploiement avec CodeDeploy](deployment-groups-view-details.md).
1. Confirmez que la révision d'application est configurée correctement :
+ Vérifiez le format de votre AppSpec fichier. Pour plus d’informations, consultez [Ajouter un fichier de spécification d'application à une révision pour CodeDeploy](application-revisions-appspec-file.md) et [CodeDeploy AppSpec référence de fichier](reference-appspec-file.md).
+ Vérifiez votre compartiment ou GitHub référentiel Amazon S3 pour vérifier que la révision de votre application se trouve à l'emplacement prévu.
+ Passez en revue les détails de la révision de votre CodeDeploy demande pour vous assurer qu'elle est correctement enregistrée. Pour plus d'informations, consultez [Consultez les détails de révision de l'application avec CodeDeploy](application-revisions-view-details.md).
+ Si vous effectuez un déploiement à partir d'Amazon S3, vérifiez dans votre compartiment Amazon S3 que vous avez CodeDeploy obtenu les autorisations nécessaires pour télécharger la révision de l'application. Pour plus d'informations sur les stratégies de compartiment, consultez la rubrique [Conditions préalables au déploiement](deployments-create-prerequisites.md).
+ Si vous effectuez le déploiement à partir de GitHub, vérifiez dans votre GitHub référentiel que CodeDeploy les autorisations nécessaires au téléchargement de la révision de l'application ont été accordées. Pour plus d’informations, consultez [Créez un déploiement avec CodeDeploy](deployments-create.md) et [GitHub authentification avec des applications dans CodeDeploy](integrations-partners-github.md#behaviors-authentication).
1. Vérifiez que le rôle de service est configuré correctement. Pour plus d'informations, consultez [Étape 2 : créer un rôle de service pour CodeDeploy](getting-started-create-service-role.md).
1. Confirmez que vous avez suivi les étapes de la rubrique [Commencer avec CodeDeploy](getting-started-codedeploy.md) pour :
+ A octroyé à un utilisateur les autorisations appropriées.
+ installer ou mettre à niveau et configurer l'interface AWS CLI ;
+ Créez un profil d'instance IAM et un rôle de service.
Pour de plus amples informations, veuillez consulter [Gestion des identités et des accès pour AWS CodeDeploy](security-iam.md).
1. Vérifiez que vous utilisez AWS CLI la version 1.6.1 ou ultérieure. Pour vérifier la version que vous avez installée, appelez **aws --version**.
Si vous ne parvenez toujours pas à dépanner votre déploiement ayant échoué, passez en revue les autres problèmes dans cette rubrique.
## CodeDeploy les ressources de déploiement ne sont prises en charge que dans certaines AWS régions
Si vous ne voyez pas ou ne pouvez pas accéder aux applications, aux groupes de déploiement, aux instances ou à d'autres ressources de déploiement depuis la console AWS CLI ou depuis la CodeDeploy console, assurez-vous de faire référence à l'une des AWS régions répertoriées dans [Région et aux points de terminaison](https://docs.aws.amazon.com/general/latest/gr/rande.html#codedeploy_region) dans. *Références générales AWS*
Les instances EC2 et les groupes Amazon EC2 Auto Scaling utilisés CodeDeploy dans les déploiements doivent être lancés et créés dans l'une de ces régions. AWS
Si vous utilisez le AWS CLI, exécutez la **aws configure** commande depuis le AWS CLI. Vous pouvez ensuite afficher et définir votre AWS région par défaut.
Si vous utilisez la CodeDeploy console, dans la barre de navigation, dans le sélecteur de région, choisissez l'une des AWS régions prises en charge.
**Important**
Pour utiliser les services de la région Chine (Pékin) ou de la région Chine (Ningxia), vous devez disposer d'un compte et d'informations d'identification pour ces régions. Les comptes et informations d'identification AWS des autres régions ne fonctionnent pas pour les régions de Pékin et du Ningxia, et vice versa.
Les informations relatives à certaines ressources pour les régions de Chine, telles que les noms des compartiments du kit de CodeDeploy ressources et les procédures d'installation des CodeDeploy agents, ne sont pas incluses dans cette édition du *guide de CodeDeploy l'utilisateur*.
Pour plus d’informations, consultez:
[CodeDeploy](http://docs.amazonaws.cn/en_us/aws/latest/userguide/codedeploy.html)dans *[Commencer AWS dans la région de Chine (Pékin)](http://docs.amazonaws.cn/en_us/aws/latest/userguide/introduction.html)*
*CodeDeploy Guide de l'utilisateur pour les régions de Chine* ([version anglaise](http://docs.amazonaws.cn/en_us/codedeploy/latest/userguide/welcome.html) \$1 [version chinoise](http://docs.amazonaws.cn/codedeploy/latest/userguide/welcome.html))
## Les procédures décrites dans ce guide ne correspondent pas à celles de la CodeDeploy console
Les procédures de ce guide sont rédigées pour la nouvelle conception de la console. Si vous utilisez l'ancienne version de la console, la plupart des concepts et des procédures de base de ce guide sont toujours applicables. Pour accéder à l'aide de la nouvelle console, cliquez sur l'icône d'information.
## Les rôles IAM requis ne sont pas disponibles
Si vous vous fiez à un profil d'instance IAM ou à un rôle de service créé dans le cadre d'une AWS CloudFormation pile, si vous supprimez la pile, tous les rôles IAM sont également supprimés. C'est peut-être la raison pour laquelle le rôle IAM n'est plus affiché dans la console IAM et CodeDeploy ne fonctionne plus comme prévu. Pour résoudre ce problème, vous devez recréer manuellement le rôle IAM supprimé.
## L'utilisation de certains éditeurs de texte pour créer des AppSpec fichiers et des scripts shell peut entraîner l'échec des déploiements.
Certains éditeurs de texte introduisent des caractères non imprimables non conformes dans les fichiers. Si vous utilisez des éditeurs de texte pour créer ou modifier AppSpec des fichiers ou des fichiers de script shell destinés à être exécutés sur des instances Amazon Linux, Ubuntu Server ou RHEL, les déploiements basés sur ces fichiers risquent d'échouer. Lors de l' CodeDeploy utilisation de ces fichiers lors d'un déploiement, la présence de ces caractères peut entraîner des échecs de validation de hard-to-troubleshoot AppSpec fichiers et d'exécution de scripts.
Dans la CodeDeploy console, sur la page des détails de l'événement pour le déploiement, choisissez **Afficher les journaux**. (Ou vous utilisez le AWS CLI pour appeler la [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html)commande.) Recherchez des erreurs telles que `invalid character`, `command not found`, ou `file not found`.
Pour résoudre ce problème, nous vous recommandons de procéder comme suit :
+ N'utilisez pas d'éditeurs de texte qui introduisent des caractères non imprimables tels que les retours de transport (`^M`caractères) dans vos AppSpec fichiers et vos fichiers de script shell.
+ Utilisez des éditeurs de texte qui affichent des caractères non imprimables tels que les fiches de transport dans vos AppSpec fichiers et les fichiers de script shell, afin de détecter et de supprimer ceux qui pourraient être introduits. Pour obtenir des exemples de ce type d'éditeurs de texte, recherchez sur Internet les éditeurs de texte affichant les retours à la ligne.
+ Utilisez des éditeurs de texte exécutés sur des instances Amazon Linux, Ubuntu Server ou RHEL pour créer des fichiers de script shell qui s'exécutent sur des instances Amazon Linux, Ubuntu Server ou RHEL. Pour obtenir des exemples de ce type d'éditeurs de texte, recherchez sur Internet les éditeurs de script shell Linux.
+ Si vous devez utiliser un éditeur de texte sous Windows ou macOS pour créer des fichiers de script shell à exécuter sur des instances Amazon Linux, Ubuntu Server ou RHEL, utilisez un programme ou un utilitaire qui convertit le texte au format Windows ou macOS au format Unix. Pour obtenir des exemples de tels programmes et utilitaires, recherchez sur Internet « DOS vers UNIX » ou « Mac vers UNIX ». Veillez à tester les fichiers de script shell convertis sur les systèmes d'exploitation cibles.
## L'utilisation du Finder sur MacOS pour grouper une révision d'application peut entraîner l'échec des déploiements
Les déploiements peuvent échouer si vous utilisez l'application d'interface utilisateur graphique (GUI) du Finder sur un Mac pour regrouper (compresser) un AppSpec fichier ainsi que les fichiers et scripts associés dans un fichier d'archive de révisions d'applications (.zip). Ceci tient au fait que Finder crée un dossier `__MACOSX` intermédiaire dans le fichier .zip et y place les fichiers composants. CodeDeploy ne peut pas trouver les fichiers composants, ce qui entraîne l'échec du déploiement.
Pour résoudre ce problème, nous vous recommandons d'utiliser la commande AWS CLI to call the [push](https://docs.aws.amazon.com/cli/latest/reference/deploy/push.html), qui permet de compresser les fichiers des composants dans la structure attendue. Vous pouvez également utiliser le terminal au lieu de l'interface graphique utilisateur pour compresser les fichiers composants. Le terminal ne crée pas de dossier `__MACOSX` intermédiaire.
# Résoudre les problèmes de déploiement d'EC2/sur site
**Topics**
+ [CodeDeploy erreur d'identification CommandPoller manquante dans le plugin](#troubleshooting-agent-commandpoller-error)
+ [Le déploiement échoue avec le message « Échec de la validation du message PKCS7 signé »](#troubleshooting-deployments-agent-SHA-256)
+ [Le déploiement ou redéploiement des mêmes fichiers sur les mêmes emplacements d'instance échoue avec l'erreur « Le déploiement a échoué car un fichier spécifié existe déjà à l'emplacement »](#troubleshooting-same-files-different-app-name)
+ [Les longs chemins de fichier provoquent des erreurs « Aucun fichier ou répertoire de ce type »](#troubleshooting-long-file-paths)
+ [Des processus de longue durée peuvent entraîner l'échec des déploiements](#troubleshooting-long-running-processes)
+ [Résolution des problèmes liés à un échec AllowTraffic du cycle de vie sans qu'aucune erreur ne soit signalée dans les journaux de déploiement](#troubleshooting-deployments-allowtraffic-no-logs)
+ [Résolution des problèmes liés à un échec ApplicationStop ou à un événement lié AfterBlockTraffic au cycle de vie du déploiement BeforeBlockTraffic](#troubleshooting-deployments-lifecycle-event-failures)
+ [Résolution des problèmes liés à un échec du cycle de vie d'un DownloadBundle déploiement avec UnknownError : non ouvert pour lecture](#troubleshooting-deployments-downloadbundle)
+ [Résolution des erreurs d’événements de cycle de vie ignorés](#troubleshooting-skipped-lifecycle-events)
+ [PowerShell Les scripts Windows n'utilisent pas la version 64 bits de Windows PowerShell par défaut](#troubleshooting-deployments-powershell)
**Note**
Les causes de nombreux échecs de déploiement peuvent être identifiées en passant en revue les fichiers journaux créés pendant le processus de déploiement. Pour des raisons de simplicité, nous vous recommandons d'utiliser Amazon CloudWatch Logs pour surveiller les fichiers journaux de manière centralisée au lieu de les consulter instance par instance. Pour plus d'informations, voir [Afficher CodeDeploy les CloudWatch journaux dans la console Logs](https://aws.amazon.com/blogs/devops/view-aws-codedeploy-logs-in-amazon-cloudwatch-console/).
**Astuce**
*Pour un runbook qui automatise de nombreuses tâches de dépannage liées aux déploiements EC2/sur site, consultez le manuel de référence du runbook [AWSSupport-TroubleshootCodeDeploy](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshootcodedeploy.html)Systems Manager AWS Automation.*
## CodeDeploy erreur d'identification CommandPoller manquante dans le plugin
Si vous recevez une erreur similaire à `InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile`, elle peut être provoquée par l'une des causes suivantes :
+ Aucun profil d'instance IAM n'est associé à l'instance sur laquelle vous effectuez le déploiement.
+ Les autorisations configurées pour votre profil d'instance IAM ne sont pas correctes.
Un profil d'instance IAM autorise l' CodeDeploy agent à communiquer avec CodeDeploy et à télécharger votre révision depuis Amazon S3. Pour les instances EC2, veuillez consulter [Gestion des identités et des accès pour AWS CodeDeploy](security-iam.md). Pour les instances sur site, consultez [Utilisation d'instances locales pour CodeDeploy](instances-on-premises.md).
## Le déploiement échoue avec le message « Échec de la validation du message PKCS7 signé »
Ce message d'erreur indique que l'instance exécute une version de l' CodeDeploy agent qui prend uniquement en charge l'algorithme de hachage SHA-1. Support de l'algorithme de hachage SHA-2 a été introduit dans la version 1.0.1.854 de l' CodeDeploy agent, publiée en novembre 2015. À compter du 17 octobre 2016, les déploiements échouent si une version de l' CodeDeploy agent antérieure à 1.0.1.854 est installée. Pour plus d'informations, voir pour [passer AWS à l'algorithme de SHA256 hachage pour les certificats SSL](https://aws.amazon.com/security/security-bulletins/aws-to-switch-to-sha256-hash-algorithm-for-ssl-certificates/), [REMARQUE : retrait des agents CodeDeploy hôtes antérieurs à la version 1.0.1.85](https://forums.aws.amazon.com/thread.jspa?threadID=223319), et. [Mettre à jour l' CodeDeploy agent](codedeploy-agent-operations-update.md)
## Le déploiement ou redéploiement des mêmes fichiers sur les mêmes emplacements d'instance échoue avec l'erreur « Le déploiement a échoué car un fichier spécifié existe déjà à l'emplacement »
Lorsque CodeDeploy vous essayez de déployer un fichier sur une instance mais qu'un fichier portant le même nom existe déjà à l'emplacement cible spécifié, le déploiement vers cette instance peut échouer. Vous pouvez recevoir le message d'erreur « Le déploiement a échoué car un fichier spécifié existe déjà à cet emplacement :*location-name*. » Cela est dû au fait que, pour chaque déploiement, CodeDeploy supprime d'abord tous les fichiers du déploiement précédent, lesquels sont répertoriés dans un fichier journal de nettoyage. Si certains fichiers des dossiers d'installation cibles ne sont pas répertoriés dans ce fichier de nettoyage, l' CodeDeploy agent interprète par défaut cela comme une erreur et échoue au déploiement.
**Note**
Sur les instances Amazon Linux, RHEL et Ubuntu Server, le fichier de nettoyage se trouve dans. `/opt/codedeploy-agent/deployment-root/deployment-instructions/` Sur les instances Windows Server, l'emplacement est`C:\ProgramData\Amazon\CodeDeploy\deployment-instructions\`.
Le moyen le plus simple d'éviter cette erreur est de spécifier une option autre que le comportement par défaut qui consiste à faire échouer le déploiement. Pour chaque déploiement, vous pouvez choisir de faire échouer le déploiement, de remplacer les fichiers non répertoriés dans le fichier de nettoyage ou de conserver les fichiers déjà présents sur l'instance.
L'option de remplacement est utile quand, par exemple, vous avez placé manuellement un fichier sur une instance après le dernier déploiement, mais que vous avez ensuite ajouté un fichier du même nom à la révision de l'application suivante.
Vous pouvez choisir l'option de conservation pour les fichiers que vous placez sur l'instance et dont vous souhaitez qu'ils fassent partie du prochain déploiement sans avoir à les ajouter au package de révision de l'application. L'option de conservation est également utile si les fichiers de votre application se trouvent déjà dans votre environnement de production et que vous souhaitez les déployer CodeDeploy pour la première fois. Pour plus d’informations, consultez [Création d'un déploiement de plate-forme de calcul EC2/sur site (console)](deployments-create-console.md) et [Comportement d'annulation avec du contenu existant](deployments-rollback-and-redeploy.md#deployments-rollback-and-redeploy-content-options).
### Résolution des erreurs de déploiement `The deployment failed because a specified file already exists at this location`
Si vous choisissez de ne pas spécifier la possibilité de remplacer ou de conserver le contenu qu' CodeDeploy détecte dans vos emplacements de déploiement cibles (ou si vous ne spécifiez pas d'option de déploiement pour traiter les contenus existants dans une commande de programmation), vous pouvez choisir de résoudre l'erreur.
Les informations suivantes s'appliquent uniquement si vous choisissez de ne pas conserver ou de remplacer le contenu.
Si vous essayez de redéployer des fichiers portant les mêmes noms et emplacements, le redéploiement a plus de chances de réussir si vous spécifiez le nom de l'application et le groupe de déploiement avec le même ID de groupe de déploiement sous-jacent que celui que vous avez utilisé auparavant. CodeDeploy utilise l'ID du groupe de déploiement sous-jacent pour identifier les fichiers à supprimer avant un redéploiement.
Le déploiement de nouveaux fichiers ou le redéploiement des mêmes fichiers aux mêmes emplacements sur les instances peut échouer pour les raisons suivantes :
+ Vous avez spécifié un nom d'application différent pour un redéploiement de la même révision sur les mêmes instances. Le redéploiement échoue parce que, même si le nom du groupe de déploiement est le même, l'utilisation d'un nom d'application différent signifie qu'un autre ID de groupe de déploiement sous-jacent est utilisé.
+ Vous avez supprimé et recréé un groupe de déploiement pour une application, puis essayé de redéployer la même révision dans le groupe de déploiement. Le redéploiement échoue car même si le nom du groupe de déploiement est identique, il CodeDeploy fait référence à un identifiant de groupe de déploiement sous-jacent différent.
+ Vous avez supprimé une application et un groupe de déploiement dans CodeDeploy, puis vous avez créé un nouveau groupe d'applications et de déploiement portant les mêmes noms que ceux que vous avez supprimés. Après cela, vous avez essayé de redéployer une révision qui avait été déployée dans le groupe de déploiement précédent vers le nouveau groupe portant le même nom. Le redéploiement échoue car même si les noms de l'application et du groupe de déploiement sont identiques, ils font CodeDeploy toujours référence à l'ID du groupe de déploiement que vous avez supprimé.
+ Vous avez déployé une révision dans un groupe de déploiement, puis déployé la même révision dans un autre groupe de déploiement sur les mêmes instances. Le second déploiement échoue, car CodeDeploy référence un autre ID de groupe de déploiement sous-jacent.
+ Vous avez déployé une révision dans un seul groupe de déploiement, puis déployé une autre révision dans un autre groupe de déploiement sur les mêmes instances. Il existe au moins un fichier portant le même nom et situé au même emplacement que le second groupe de déploiement tente de déployer. Le deuxième déploiement échoue car CodeDeploy le fichier existant n'est pas supprimé avant le début du deuxième déploiement. Les deux déploiements font référence à un groupe de déploiement différent. IDs
+ Vous avez déployé une révision dans CodeDeploy, mais il existe au moins un fichier portant le même nom et se trouvant au même emplacement. Le déploiement échoue car, par défaut, CodeDeploy le fichier existant n'est pas supprimé avant le début du déploiement.
Pour traiter de telles situations, effectuez l'une des actions suivantes :
+ Supprimez les fichiers des emplacements et des instances vers lesquels ils ont été précédemment déployés, puis réessayez d'effectuer le déploiement.
+ Dans AppSpec le fichier de votre révision, que ce soit dans les événements du cycle de vie ApplicationStop ou de BeforeInstall déploiement, spécifiez un script personnalisé pour supprimer les fichiers dans tous les emplacements correspondant aux fichiers que votre révision est sur le point d'installer.
+ Déployez ou redéployez les fichiers à des emplacements ou sur des instances qui ne faisaient pas partie des déploiements précédents.
+ Avant de supprimer une application ou un groupe de déploiement, déployez une révision contenant un AppSpec fichier ne spécifiant aucun fichier à copier sur les instances. Pour le déploiement, spécifiez le nom de l'application et le nom du groupe de déploiement qui utilisent les mêmes applications et groupes de déploiement sous-jacents IDs que ceux que vous êtes sur le point de supprimer. (Vous pouvez utiliser la [get-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-group.html)commande pour récupérer l'ID du groupe de déploiement.) CodeDeployutilise l'ID et le AppSpec fichier du groupe de déploiement sous-jacents pour supprimer tous les fichiers installés lors du précédent déploiement réussi.
## Les longs chemins de fichier provoquent des erreurs « Aucun fichier ou répertoire de ce type »
Pour les déploiements sur des instances Windows, si le chemin du fichier appspec.yml contient un chemin de fichier supérieur à 260 caractères dans la section fichiers de votre fichier appspec.yml, les déploiements peuvent échouer avec une erreur similaire à la suivante :
`No such file or directory @ dir_s_mkdir - C:\your-long-file-path`
Cette erreur se produit parce que Windows n'autorise pas par défaut les chemins de fichiers supérieurs à 260 caractères, comme indiqué dans [la documentation de Microsoft](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=powershell#enable-long-paths-in-windows-10-version-1607-and-later).
Pour les versions 1.4.0 ou ultérieures de l' CodeDeploy agent, vous pouvez activer les longs chemins de fichiers de deux manières, en fonction du processus d'installation de l'agent :
Si l' CodeDeploy agent n'est pas encore installé :
1. Sur la machine sur laquelle vous comptez installer l' CodeDeploy agent, activez la clé de registre `LongPathsEnabled` Windows à l'aide de cette commande :
```
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem"
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
```
1. Installez l' CodeDeploy agent. Pour de plus amples informations, veuillez consulter [Installation de l' CodeDeploy agent](codedeploy-agent-operations-install.md).
Si l' CodeDeploy agent a déjà été installé :
1. Sur la machine CodeDeploy agent, activez la clé de registre `LongPathsEnabled` Windows à l'aide de cette commande :
```
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem"
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
```
1. Redémarrez l' CodeDeploy agent pour que la modification de la clé de registre soit prise en compte. Pour redémarrer l'agent, utilisez cette commande :
```
powershell.exe -Command Restart-Service -Name codedeployagent
```
## Des processus de longue durée peuvent entraîner l'échec des déploiements
Pour les déploiements sur les instances Amazon Linux, Ubuntu Server et RHEL, si vous disposez d'un script de déploiement qui lance un processus de longue durée, vous CodeDeploy risquez de devoir attendre longtemps avant de voir le cycle de vie du déploiement échouer. La raison en est que si le processus s'exécute plus longtemps que les processus au premier plan et en arrière-plan sont censés durer dans cet événement, CodeDeploy arrête le déploiement et le considère comme ayant échoué, même si le processus s'exécute encore comme prévu.
Par exemple, une révision d'application contient deux fichiers à la racine, `after-install.sh` et `sleep.sh`. Son AppSpec fichier contient les instructions suivantes :
```
version: 0.0
os: linux
files:
- source: ./sleep.sh
destination: /tmp
hooks:
AfterInstall:
- location: after-install.sh
timeout: 60
```
Le `after-install.sh` fichier s'exécute pendant l'événement du cycle de vie de l' AfterInstall application. Voici son contenu :
```
#!/bin/bash
/tmp/sleep.sh
```
Le fichier `sleep.sh` contient le code suivant, qui interrompt l'exécution du programme pendant trois minutes (180 secondes) et simule ainsi un processus de longue durée :
```
#!/bin/bash
sleep 180
```
Lorsque l'`after-install.sh`appel `sleep.sh` `sleep.sh` démarre et s'exécute pendant trois minutes (180 secondes), soit deux minutes (120 secondes) au-delà de l'heure prévue CodeDeploy `sleep.sh` (et, par relation,`after-install.sh`) d'arrêt de l'exécution. Après un délai d'une minute (60 secondes), le déploiement CodeDeploy s'arrête et échoue lors de l'événement du cycle de vie de l' AfterInstall application, même si `sleep.sh` son exécution se poursuit comme prévu. L'erreur suivante s'affiche :
`Script at specified location: after-install.sh failed to complete in 60 seconds`.
Vous ne pouvez pas ajouter simplement une esperluette (`&`) dans `after-install.sh` pour exécuter `sleep.sh` en arrière-plan.
```
#!/bin/bash
# Do not do this.
/tmp/sleep.sh &
```
Cela peut laisser le déploiement en attente pendant la période d'expiration par défaut d'une heure du cycle de vie du déploiement, après quoi le déploiement CodeDeploy s'arrête et échoue lors de l'événement du cycle de vie de l' AfterInstall application, comme auparavant.
Dans`after-install.sh`, appelez `sleep.sh` comme suit, ce qui permet CodeDeploy de continuer après le début du processus :
```
#!/bin/bash
/tmp/sleep.sh > /dev/null 2> /dev/null < /dev/null &
```
Dans l'appel précédent, `sleep.sh` est le nom du processus que vous voulez commencer à exécuter en arrière-plan, en redirigeant stdout, stderr et stdin vers `/dev/null`.
## Résolution des problèmes liés à un échec AllowTraffic du cycle de vie sans qu'aucune erreur ne soit signalée dans les journaux de déploiement
Dans certains cas, un blue/green déploiement échoue pendant l'événement du AllowTraffic cycle de vie, mais les journaux de déploiement n'indiquent pas la cause de l'échec.
Cet échec est généralement dû à des contrôles de santé mal configurés dans Elastic Load Balancing pour le Classic Load Balancer, l'Application Load Balancer ou le Network Load Balancer utilisés pour gérer le trafic du groupe de déploiement.
Pour résoudre le problème, passez en revue et corrigez les erreurs de configuration de la vérification de l'état pour l'équilibreur de charge.
Pour les équilibreurs de charge classiques, consultez la section [Configure Health Checks](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html) dans le *guide de l'utilisateur pour les équilibreurs de charge classiques* et [ConfigureHealthCheck](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_ConfigureHealthCheck.html)dans la *version 2012-06-01 de référence de l'API Elastic Load Balancing*.
Pour les équilibreurs de charge d'application, consultez [la section Contrôles de santé de vos groupes cibles](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html) dans le *guide d'utilisation des équilibreurs de charge d'application*.
Pour les Network Load Balancers, consultez [la section Health Checks for Your Target Groups](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html) dans le guide de l'*utilisateur du Network Load Balancer*.
## Résolution des problèmes liés à un échec ApplicationStop ou à un événement lié AfterBlockTraffic au cycle de vie du déploiement BeforeBlockTraffic
Au cours d'un déploiement, l' CodeDeploy agent exécute les scripts spécifiés pour ApplicationStop et AfterBlockTraffic dans le AppSpec fichier du précédent déploiement réussi. BeforeBlockTraffic (Tous les autres scripts sont exécutés à partir du AppSpec fichier dans le déploiement en cours.) Si l'un de ces scripts contient une erreur et ne s'exécute pas correctement, le déploiement peut échouer.
Les raisons possibles de ces échecs sont les suivantes :
+ L' CodeDeploy agent trouve le `deployment-group-id_last_successful_install` fichier au bon emplacement, mais l'emplacement indiqué dans le `deployment-group-id_last_successful_install` fichier n'existe pas.
**Sur les instances Amazon Linux, Ubuntu Server et RHEL**, ce fichier doit exister dans`/opt/codedeploy-agent/deployment-root/deployment-instructions`.
**Sur les instances Windows Server**, ce fichier doit être stocké dans le `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions` dossier.
+ À l'emplacement indiqué dans le `deployment-group-id_last_successful_install` fichier, le AppSpec fichier n'est pas valide ou les scripts ne s'exécutent pas correctement.
+ Le script contient une erreur qui ne peut pas être corrigée. Il ne réussit donc jamais à s'exécuter.
Utilisez la CodeDeploy console pour déterminer pourquoi un déploiement a pu échouer lors de l'un de ces événements. Sur la page des détails du déploiement, choisissez **View Events**. Sur la page de détails de l'instance, dans la **AfterBlockTraffic**ligne **ApplicationStop**BeforeBlockTraffic****, ou, choisissez **Afficher les journaux**. Ou utilisez le AWS CLI pour appeler la [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html)commande.
Si l'échec est dû à un script du dernier déploiement réussi qui ne s'exécute jamais correctement, créez un déploiement et spécifiez que les ApplicationStop AfterBlockTraffic échecs doivent être ignorés. BeforeBlockTraffic Il existe deux façons de procéder :
+ Utilisez la CodeDeploy console pour créer un déploiement. Sur la page **Créer un déploiement**, sous **Défaillance d'un événement ApplicationStop du cycle** de vie, sélectionnez **Ne pas échouer le déploiement sur une instance si cet événement du cycle de vie de l'instance échoue**.
+ Utilisez le AWS CLI pour appeler la **[create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html)** commande et inclure l'`--ignore-application-stop-failures`option.
Lorsque vous déployez la révision de l'application à nouveau, le déploiement se poursuit même si l'un de ces trois événements du cycle de vie échoue. Si la nouvelle révision inclut des scripts fixes pour ces événements du cycle de vie, les déploiements futurs peuvent réussir sans appliquer ce correctif.
## Résolution des problèmes liés à un échec du cycle de vie d'un DownloadBundle déploiement avec UnknownError : non ouvert pour lecture
Si vous essayez de déployer une révision d'application depuis Amazon S3 et que le déploiement échoue pendant l'événement du cycle de vie du DownloadBundle déploiement avec l'`UnknownError: not opened for reading`erreur suivante :
+ Une erreur interne du service Amazon S3 s'est produite. Déployez de nouveau la révision d'application.
+ Le profil d'instance IAM de votre instance EC2 n'est pas autorisé à accéder à la révision de l'application dans Amazon S3. Pour plus d'informations sur les politiques relatives aux compartiments Amazon S3, consultez [Transférer une révision CodeDeploy pour Amazon S3 (déploiements EC2/sur site uniquement)](application-revisions-push.md) et[Conditions préalables au déploiement](deployments-create-prerequisites.md).
+ Les instances vers lesquelles vous déployez sont associées à une AWS région (par exemple, USA Ouest (Oregon)), mais le compartiment Amazon S3 qui contient la révision de l'application est associé à une autre AWS région (par exemple, USA Est (Virginie du Nord)). Assurez-vous que la révision de l'application se trouve dans un compartiment Amazon S3 associé à la même AWS région que les instances.
Sur la page de présentation des événements pour le déploiement, à la ligne **Download bundle**, choisissez **View logs**. Ou utilisez le AWS CLI pour appeler la [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html)commande. Si cette erreur s'est produite, il devrait y avoir une erreur dans la sortie avec le code d'erreur `UnknownError` et le message d'erreur `not opened for reading`.
Pour déterminer la cause de cette erreur :
1. Activez la journalisation avec connexion sur au moins une des instances, puis déployez de nouveau la révision d'application.
1. Examinez le fichier de consignation avec connexion pour trouver l'erreur. Les messages d'erreur courants pour ce problème incluent l'expression « access denied ».
1. Une fois que vous avez examiné les fichiers journaux, nous vous recommandons de désactiver la journalisation avec connexion pour réduire la taille des fichiers journaux et la quantité d'informations sensibles qui peuvent apparaître dans la sortie en texte clair, sur l'instance, à l'avenir.
Pour plus d'informations sur la façon de trouver le fichier d'enregistrement des câbles et d'activer et de désactiver l'enregistrement des câbles, reportez-vous `:log_aws_wire:` à la section [Référence de configuration de CodeDeploy l'agent](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-agent-configuration.html).
## Résolution des erreurs d’événements de cycle de vie ignorés
Si tous les événements du cycle de vie d'un déploiement EC2 ou sur site sont ignorés, vous risquez de recevoir une erreur similaire à. `The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems. (Error code: HEALTH_CONSTRAINTS)` Voici certaines des causes et solutions possibles :
+ L' CodeDeploy agent n'est peut-être pas installé ou ne s'exécute pas sur l'instance. Pour déterminer si l' CodeDeploy agent est en cours d'exécution :
+ Pour Amazon Linux, RHEL ou Ubuntu Server, exécutez la commande suivante :
```
systemctl status codedeploy-agent
```
+ Pour Windows, exécutez la commande suivante :
```
powershell.exe -Command Get-Service -Name CodeDeployagent
```
Si l' CodeDeploy agent n'est pas installé ou n'est pas en cours d'exécution, consultez[Vérifiez que l' CodeDeploy agent est en cours d'exécution](codedeploy-agent-operations-verify.md).
Il est possible que votre instance ne parvienne pas à atteindre le point de terminaison public CodeDeploy ou Amazon S3 via le port 443. Essayez l’une des actions suivantes :
+ Attribuez une adresse IP publique à l'instance et utilisez sa table de routage pour autoriser l'accès Internet. Assurez-vous que le groupe de sécurité associé à l'instance autorise l'accès sortant sur le port 443 (HTTPS). Pour de plus amples informations, veuillez consulter [Protocole de communication et port pour l' CodeDeploy agent](codedeploy-agent.md#codedeploy-agent-outbound-port).
+ Si une instance est provisionnée dans un sous-réseau privé, utilisez une passerelle NAT au lieu d'une passerelle Internet dans la table de routage. Pour plus d’informations, consultez [Passerelles NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html).
+ Le rôle de service pour n'a CodeDeploy peut-être pas les autorisations requises. Pour configurer un rôle de service CodeDeploy, consultez [Étape 2 : créer un rôle de service pour CodeDeploy](getting-started-create-service-role.md).
+ Si vous utilisez un proxy HTTP, assurez-vous qu'il est spécifié dans le `:proxy_uri:` paramètre du fichier de configuration de l' CodeDeploy agent. Pour de plus amples informations, veuillez consulter [CodeDeploy référence de configuration de l'agent](reference-agent-configuration.md).
+ La date et l’heure de signature de votre instance de déploiement pourraient ne pas correspondre à la date et l'heure de signature de votre demande de déploiement. Recherchez une erreur similaire à celle qui se trouve `Cannot reach InstanceService: Aws::CodeDeployCommand::Errors::InvalidSignatureException - Signature expired` dans le fichier journal de votre CodeDeploy agent. Si vous voyez cette erreur, suivez les étapes décrites dans [Résolution des erreurs de déploiement « InvalidSignatureException — Signature expirée : [heure] est maintenant antérieure à [heure] »](troubleshooting-ec2-instances.md#troubleshooting-instance-time-failures). Pour de plus amples informations, veuillez consulter [Afficher les données du journal pour les déploiements CodeDeploy EC2/sur site](deployments-view-logs.md).
+ L' CodeDeploy agent peut s'arrêter parce qu'une instance manque de mémoire ou d'espace sur le disque dur. Essayez de réduire le nombre de déploiements archivés sur votre instance en mettant à jour le `max_revisions` paramètre dans la configuration de l' CodeDeploy agent. Si vous effectuez cette opération pour une instance EC2 et que le problème persiste, envisagez d'utiliser une instance plus grande. Par exemple, si votre type d'instance est `t2.small`, essayez d'utiliser une instance `t2.medium`. Pour plus d'informations, reportez-vous aux [Fichiers installés par l' CodeDeploy agent](codedeploy-agent.md#codedeploy-agent-install-files) sections[CodeDeploy référence de configuration de l'agent](reference-agent-configuration.md), et [Types d'instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html).
+ Il est possible qu'aucun profil d'instance IAM ne soit attaché à l'instance sur laquelle vous effectuez le déploiement ou qu'un profil d'instance IAM ne dispose pas des autorisations requises.
+ Si aucun profil d'instance IAM n'est attaché à votre instance, créez-en un avec les autorisations requises, puis attachez-le.
+ Si un profil d'instance IAM est déjà attaché à votre instance, assurez-vous qu'il dispose des autorisations requises.
Une fois que votre profil d'instance attaché est configuré avec les autorisations requises, redémarrez votre instance. Pour plus d'informations, consultez [Étape 4 : Création d'un profil d'instance IAM pour vos instances Amazon EC2](getting-started-create-iam-instance-profile.md) la section [Rôles IAM pour Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-EC2.html) EC2 dans le guide de l'utilisateur *Amazon EC2*.
## PowerShell Les scripts Windows n'utilisent pas la version 64 bits de Windows PowerShell par défaut
Si un PowerShell script Windows exécuté dans le cadre d'un déploiement repose sur des fonctionnalités 64 bits (par exemple, parce qu'il consomme plus de mémoire que ce qu'autorise une application 32 bits ou qu'il appelle des bibliothèques proposées uniquement dans une version 64 bits), le script risque de se bloquer ou de ne pas s'exécuter comme prévu. Cela est dû au fait que, par défaut, la version 32 bits de Windows est CodeDeploy utilisée PowerShell pour exécuter des PowerShell scripts Windows qui font partie d'une révision d'application.
Ajoutez le code suivant au début de tout script devant être exécuté avec la version 64 bits de Windows PowerShell :
```
# Are you running in 32-bit mode?
# (\SysWOW64\ = 32-bit mode)
if ($PSHOME -like "*SysWOW64*")
{
Write-Warning "Restarting this script under 64-bit Windows PowerShell."
# Restart this script under 64-bit Windows PowerShell.
# (\SysNative\ redirects to \System32\ for 64-bit mode)
& (Join-Path ($PSHOME -replace "SysWOW64", "SysNative") powershell.exe) -File `
(Join-Path $PSScriptRoot $MyInvocation.MyCommand) @args
# Exit 32-bit script.
Exit $LastExitCode
}
# Was restart successful?
Write-Warning "Hello from $PSHOME"
Write-Warning " (\SysWOW64\ = 32-bit mode, \System32\ = 64-bit mode)"
Write-Warning "Original arguments (if any): $args"
# Your 64-bit script code follows here...
# ...
```
Bien que les informations de chemin de fichier contenues dans ce code puissent sembler peu intuitives, Windows 32 bits PowerShell utilise un chemin tel que :
`c:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe`
Windows 64 bits PowerShell utilise un chemin tel que :
`c:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe`
# Résoudre les problèmes de déploiement d'Amazon ECS
**Topics**
+ [Un délai d'attente survient pendant l'attente d'un ensemble de tâches de remplacement](#troubleshooting-ecs-timeout)
+ [Un délai d'attente survient pendant l'attente de la poursuite d'une notification](#troubleshooting-ecs-timeout-notif)
+ [Le rôle IAM ne dispose pas de suffisamment d'autorisations](#troubleshooting-ecs-iam)
+ [Le délai de déploiement a expiré en attendant un rappel de statut](#troubleshooting-ecs-timeout-callback)
+ [Le déploiement a échoué car une ou plusieurs fonctions de validation des événements du cycle de vie ont échoué](#troubleshooting-ecs-lifecycle)
+ [L'ELB n'a pas pu être mis à jour en raison de l'erreur suivante : Le groupe cible de l'ensemble de tâches principal doit être derrière l'écouteur](#troubleshooting-ecs-elb)
+ [Mon déploiement échoue parfois lorsque j'utilise Auto Scaling](#troubleshooting-ecs-auto-scaling)
+ [Seul ALB prend en charge le routage progressif du trafic, utilisez plutôt AllAtOnce le routage du trafic lorsque vous êtes un groupe create/update de déploiement](#troubleshooting-ecs-lb)
+ [Même si mon déploiement a réussi, l'ensemble de tâches de remplacement échoue aux tests de santé d'Elastic Load Balancing, et mon application est en panne](#troubleshooting-ecs-task-set-stability)
+ [Puis-je associer plusieurs équilibreurs de charge à un groupe de déploiement ?](#troubleshooting-ecs-lb-multi)
+ [Puis-je effectuer des déploiements CodeDeploy bleu/vert sans équilibreur de charge ?](#troubleshooting-ecs-lb-bg)
+ [Comment puis-je mettre à jour mon service Amazon ECS avec de nouvelles informations lors d'un déploiement ?](#troubleshooting-ecs-exec)
## Un délai d'attente survient pendant l'attente d'un ensemble de tâches de remplacement
**Problème** : le message d'erreur suivant s'affiche lors du déploiement de votre application Amazon ECS à l'aide de CodeDeploy :
`The deployment timed out while waiting for the replacement task set to become healthy. This time out period is 60 minutes.`
**Cause possible** : Cette erreur peut se produire en cas d'erreur dans votre fichier de définition de tâche ou dans d'autres fichiers liés au déploiement. Par exemple, s'il y a une faute de frappe dans le `image` champ de votre fichier de définition de tâche, Amazon ECS essaiera d'extraire la mauvaise image de conteneur et échouera continuellement, ce qui provoquera cette erreur.
**Corrections possibles et prochaines étapes** :
+ Corrigez les erreurs typographiques et les problèmes de configuration dans votre fichier de définition des tâches et dans d'autres fichiers.
+ Consultez l'événement de service Amazon ECS correspondant et découvrez pourquoi les tâches de remplacement ne se portent pas bien. Pour plus d'informations sur les événements Amazon ECS, consultez les [événements Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) dans le manuel *Amazon Elastic Container Service Developer Guide*.
+ Consultez la section relative au [dépannage d'Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html) du manuel *Amazon Elastic Container Service Developer Guide* pour détecter les erreurs liées aux messages de l'événement.
## Un délai d'attente survient pendant l'attente de la poursuite d'une notification
**Problème** : le message d'erreur suivant s'affiche lors du déploiement de votre application Amazon ECS à l'aide de CodeDeploy :
`The deployment timed out while waiting for a notification to continue. This time out period is n minutes.`
**Cause possible** : Cette erreur peut se produire si vous avez spécifié un temps d'attente dans le champ **Spécifiez quand rediriger le trafic** lorsque vous avez créé votre groupe de déploiement, mais que le déploiement n'a pas pu se terminer avant l'expiration du temps d'attente.
**Corrections possibles et prochaines étapes** :
+ Dans votre groupe de déploiement, **définissez le moment où vous souhaitez rediriger le trafic** sur une période plus longue et le redéployer. Pour de plus amples informations, veuillez consulter [Création d'un groupe de déploiement pour un déploiement Amazon ECS (console)](deployment-groups-create-ecs.md).
+ Dans votre groupe de déploiement, modifiez **Spécifiez quand rediriger le trafic vers Réacheminer** le **trafic immédiatement et redéployer**. Pour de plus amples informations, veuillez consulter [Création d'un groupe de déploiement pour un déploiement Amazon ECS (console)](deployment-groups-create-ecs.md).
+ Redéployez puis exécutez la [https://docs.aws.amazon.com/cli/latest/reference/deploy/continue-deployment.html](https://docs.aws.amazon.com/cli/latest/reference/deploy/continue-deployment.html) AWS CLI commande avec l'`--deployment-wait-type`option définie sur. `READY_WAIT` Assurez-vous d'exécuter cette commande *avant* l'expiration du délai indiqué dans **Spécifier quand le trafic doit être redirigé**.
## Le rôle IAM ne dispose pas de suffisamment d'autorisations
**Problème** : le message d'erreur suivant s'affiche lors du déploiement de votre application Amazon ECS à l'aide de CodeDeploy :
`The IAM role role-arn does not give you permission to perform operations in the following AWS service: AWSLambda.`
**Cause possible** : Cette erreur peut se produire si vous avez spécifié une fonction Lambda dans la [`Hooks`section du AppSpec fichier](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs), mais que vous n'avez pas CodeDeploy autorisé le service Lambda.
**Solution possible** : ajoutez l'`lambda:InvokeFunction`autorisation au rôle CodeDeploy de service. Pour ajouter cette autorisation, ajoutez l'une des politiques AWS gérées suivantes au rôle : **AWSCodeDeployRoleForECS** ou**AWSCodeDeployRoleForECSLimited**. Pour plus d'informations sur ces politiques et sur la manière de les ajouter au rôle de CodeDeploy service, consultez[Étape 2 : créer un rôle de service pour CodeDeploy](getting-started-create-service-role.md).
## Le délai de déploiement a expiré en attendant un rappel de statut
**Problème** : le message d'erreur suivant s'affiche lors du déploiement de votre application Amazon ECS à l'aide de CodeDeploy :
`The deployment timed out while waiting for a status callback. CodeDeploy expects a status callback within one hour after a deployment hook is invoked.`
**Cause possible** : Cette erreur peut se produire si vous avez spécifié une fonction Lambda dans la [`Hooks`section du AppSpec fichier](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs), mais que la fonction Lambda n'a pas pu appeler l'`PutLifecycleEventHookExecutionStatus`API nécessaire pour renvoyer un `Succeeded` statut ou à. `Failed` CodeDeploy
**Corrections possibles et prochaines étapes** :
+ Ajoutez l'`codedeploy:putlifecycleEventHookExecutionStatus`autorisation au rôle d'exécution Lambda utilisé par la fonction Lambda que vous avez spécifiée dans le fichier. AppSpec Cette autorisation permet à la fonction Lambda de renvoyer un statut de `Succeeded` ou `Failed` à. CodeDeploy *Pour plus d'informations sur le rôle d'exécution Lambda, consultez la section Rôle d'exécution [Lambda dans le Guide de l'utilisateur](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html).AWS Lambda *
+ Vérifiez le code de votre fonction Lambda et les journaux d'exécution pour vous assurer que votre fonction Lambda appelle l'`PutLifecycleEventHookExecutionStatus`API afin de CodeDeploy savoir si CodeDeploy le test de validation du cycle de vie est ou. `Succeeded` `Failed` Pour plus d'informations sur l'`putlifecycleEventHookExecutionStatus`API, consultez [PutLifecycleEventHookExecutionStatus](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_PutLifecycleEventHookExecutionStatus.html)la *référence de l'AWS CodeDeploy API*. Pour plus d'informations sur les journaux d'exécution Lambda, consultez la section Accès [ CloudWatch aux journaux Amazon](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html) pour. AWS Lambda
## Le déploiement a échoué car une ou plusieurs fonctions de validation des événements du cycle de vie ont échoué
**Problème** : le message d'erreur suivant s'affiche lors du déploiement de votre application Amazon ECS à l'aide de CodeDeploy :
`The deployment failed because one or more of the lifecycle event validation functions failed.`
**Cause possible** : Cette erreur peut se produire si vous avez spécifié une fonction Lambda dans la [`Hooks`section du AppSpec fichier](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs), mais que la fonction Lambda est revenue `Failed` à CodeDeploy son appel. `PutLifecycleEventHookExecutionStatus` Cet échec indique CodeDeploy que le test de validation du cycle de vie a échoué.
**Étape suivante possible** : consultez vos journaux d'exécution Lambda pour voir pourquoi le code du test de validation échoue. Pour plus d'informations sur les journaux d'exécution Lambda, consultez la section Accès [ CloudWatch aux journaux Amazon](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html) pour. AWS Lambda
## L'ELB n'a pas pu être mis à jour en raison de l'erreur suivante : Le groupe cible de l'ensemble de tâches principal doit être derrière l'écouteur
**Problème** : le message d'erreur suivant s'affiche lors du déploiement de votre application Amazon ECS à l'aide de CodeDeploy :
`The ELB could not be updated due to the following error: Primary taskset target group must be behind listener`
**Cause possible** : Cette erreur peut se produire si vous avez configuré un écouteur de test facultatif et qu'il est configuré avec le mauvais groupe cible. Pour plus d'informations sur l'écouteur de test intégré CodeDeploy, reportez-vous aux sections [Avant de commencer un déploiement Amazon ECS](deployment-steps-ecs.md#deployment-steps-prerequisites-ecs) et[Que se passe-t-il lors d'un déploiement d'Amazon ECS](deployment-steps-ecs.md#deployment-steps-what-happens). Pour plus d'informations sur les ensembles de tâches, consultez [TaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_TaskSet.html)le manuel *Amazon Elastic Container Service API Reference* et [describe-task-set](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-task-set.html)la section Amazon ECS du manuel *AWS CLI Command Reference*.
**Solution possible** : assurez-vous que l'écouteur de production et l'écouteur de test d'Elastic Load Balancing pointent tous deux vers le groupe cible qui gère actuellement vos charges de travail. Il y a trois endroits à vérifier :
+ Dans Amazon EC2, dans les paramètres des **écouteurs** et des règles de votre équilibreur de charge. Pour plus d'informations, consultez la section [Écouteurs pour vos équilibreurs de charge d'application dans le guide de l'utilisateur pour les équilibreurs](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html) *de charge d'application, ou Écouteurs pour vos équilibreurs* [de charge réseau dans le *guide de l'utilisateur* pour les équilibreurs](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-listeners.html) de charge réseau.
+ Dans Amazon ECS, dans votre cluster, dans la configuration **réseau** de votre service. Pour plus d'informations, consultez les considérations relatives à [Application Load Balancer et Network Load Balancer](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/load-balancer-types.html#alb-considerations) dans le manuel *Amazon Elastic Container* Service Developer Guide.
+ Dans CodeDeploy, dans les paramètres de votre groupe de déploiement. Pour de plus amples informations, veuillez consulter [Création d'un groupe de déploiement pour un déploiement Amazon ECS (console)](deployment-groups-create-ecs.md).
## Mon déploiement échoue parfois lorsque j'utilise Auto Scaling
**Problème** : vous utilisez Auto Scaling avec CodeDeploy et vous remarquez que vos déploiements échouent parfois. Pour plus d'informations sur les symptômes de ce problème, consultez la rubrique intitulée Pour les [services configurés pour utiliser le dimensionnement automatique des services et le type de blue/green déploiement, le dimensionnement automatique n'est pas bloqué pendant un déploiement, mais le déploiement peut échouer dans certaines circonstances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-bluegreen.html#deployment-type-bluegreen-considerations) dans le manuel *Amazon Elastic Container Service Developer Guide*.
**Cause possible** : ce problème peut se produire en cas CodeDeploy de conflit entre deux processus Auto Scaling.
**Solution possible** : Suspendez et reprenez les processus Auto Scaling pendant le CodeDeploy déploiement à l'aide de l'`RegisterScalableTarget`API (ou de la `register-scalable-target` AWS CLI commande correspondante). Pour plus d'informations, voir [Suspendre et reprendre le dimensionnement pour Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html) dans le *Guide de l'utilisateur d'Application Auto Scaling*.
**Note**
CodeDeploy Je ne peux pas appeler `RegisterScaleableTarget` directement. Pour utiliser cette API, vous devez configurer CodeDeploy pour envoyer une notification ou un événement à Amazon Simple Notification Service (ou Amazon CloudWatch). Vous devez ensuite configurer Amazon SNS (or CloudWatch) pour appeler une fonction Lambda, et configurer la fonction Lambda pour appeler l'API. `RegisterScalableTarget` L'`RegisterScalableTarget`API doit être appelée avec le `SuspendedState` paramètre défini sur `true` pour suspendre les opérations Auto Scaling et les `false` reprendre.
La notification ou l'événement CodeDeploy envoyé doit se produire au démarrage d'un déploiement (pour déclencher les opérations de suspension d'Auto Scaling) ou lorsqu'un déploiement réussit, échoue ou s'arrête (pour déclencher les opérations de reprise d'Auto Scaling).
Pour plus d'informations sur la configuration CodeDeploy pour générer des notifications ou des CloudWatch événements Amazon SNS, consultez[Surveillance des déploiements avec Amazon CloudWatch Events](monitoring-cloudwatch-events.md). et. [Surveillance des déploiements à l'aide des notifications d'événements Amazon SNS](monitoring-sns-event-notifications.md)
## Seul ALB prend en charge le routage progressif du trafic, utilisez plutôt AllAtOnce le routage du trafic lorsque vous êtes un groupe create/update de déploiement
**Problème** : le message d'erreur suivant s'affiche lors de la création ou de la mise à jour d'un groupe de déploiement dans CodeDeploy :
`Only ALB supports gradual traffic routing, use AllAtOnce Traffic routing instead when you create/update Deployment group.`
**Cause possible** : Cette erreur peut se produire si vous utilisez un Network Load Balancer et que vous essayez d'utiliser une configuration de déploiement prédéfinie autre que. `CodeDeployDefault.ECSAllAtOnce`
**Correctifs possibles :**
+ Modifiez votre configuration de déploiement prédéfinie en`CodeDeployDefault.ECSAllAtOnce`. Il s'agit de la seule configuration de déploiement prédéfinie prise en charge par les équilibreurs de charge réseau.
Pour plus d'informations sur les configurations de déploiement prédéfinies, consultez[Configurations de déploiement prédéfinies pour une plateforme de calcul Amazon ECS](deployment-configurations.md#deployment-configurations-predefined-ecs).
+ Changez votre équilibreur de charge en un Application Load Balancer. Les équilibreurs de charge d'application prennent en charge toutes les configurations de déploiement prédéfinies. Pour plus d'informations sur la création d'un Application Load Balancer, consultez. [Configuration d'un équilibreur de charge, de groupes cibles et d'écouteurs pour les déploiements CodeDeploy Amazon ECS](deployment-groups-create-load-balancer-for-ecs.md)
## Même si mon déploiement a réussi, l'ensemble de tâches de remplacement échoue aux tests de santé d'Elastic Load Balancing, et mon application est en panne
**Problème** : même si cela CodeDeploy indique que mon déploiement a réussi, l'ensemble de tâches de remplacement échoue aux tests de santé d'Elastic Load Balancing, et mon application est hors service.
**Cause possible** : ce problème peut se produire si vous avez effectué un CodeDeploy all-at-once déploiement et que votre ensemble de tâches de remplacement (vert) contient du code incorrect à l'origine de l'échec des tests de santé d'Elastic Load Balancing. Avec la configuration de all-at-once déploiement, les contrôles de santé de l'équilibreur de charge commencent à être exécutés sur l'ensemble de tâches de remplacement une *fois* que le trafic y a été transféré (c'est-à-dire *après* la survenue d'un événement CodeDeploy du `AllowTraffic` cycle de vie). C'est pourquoi les bilans de santé de l'ensemble de tâches de remplacement échoueront une fois que le trafic aura changé, mais pas avant. Pour plus d'informations sur les événements du cycle de vie CodeDeploy générés, consultez[Que se passe-t-il lors d'un déploiement d'Amazon ECS](deployment-steps-ecs.md#deployment-steps-what-happens).
**Correctifs possibles :**
+ Changez la configuration de votre déploiement all-at-once en Canary ou Linear. Dans une configuration Canary ou linéaire, les contrôles de santé de l'équilibreur de charge commencent à être exécutés sur l'ensemble de tâches de remplacement pendant l' CodeDeploy installation de votre application dans l'environnement de remplacement, et *avant que le trafic ne* soit déplacé (c'est-à-dire pendant l'événement `Install` du cycle de vie et *avant* l'`AllowTraffic`événement). En autorisant l'exécution des vérifications pendant l'installation de l'application, mais avant que le trafic ne soit transféré, un code d'application incorrect sera détecté et provoquera des échecs de déploiement avant que l'application ne soit rendue publique.
Pour plus d'informations sur la configuration des déploiements Canary ou Linear, consultez[Modifiez les paramètres du groupe de déploiement avec CodeDeploy](deployment-groups-edit.md).
Pour plus d'informations sur les événements CodeDeploy du cycle de vie qui s'exécutent lors d'un déploiement d'Amazon ECS, consultez[Que se passe-t-il lors d'un déploiement d'Amazon ECS](deployment-steps-ecs.md#deployment-steps-what-happens).
**Note**
Les configurations de déploiement Canary et linéaire ne sont prises en charge qu'avec les équilibreurs de charge d'application.
+ Si vous souhaitez conserver votre configuration de all-at-once déploiement, configurez un écouteur de test et vérifiez l'état de santé de l'ensemble de tâches de remplacement à l'aide du hook du `BeforeAllowTraffic` cycle de vie. Pour de plus amples informations, veuillez consulter [Liste des hooks d'événements liés au cycle de vie pour un déploiement d'Amazon ECS](reference-appspec-file-structure-hooks.md#reference-appspec-file-structure-hooks-list-ecs).
## Puis-je associer plusieurs équilibreurs de charge à un groupe de déploiement ?
Non Si vous souhaitez utiliser plusieurs équilibreurs de charge d'application ou de charge réseau, utilisez les mises à jour continues d'Amazon ECS au lieu de déploiements CodeDeploy bleu/vert. Pour plus d'informations sur les mises à jour continues, consultez la section [Mise à jour progressive](https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-type-ecs.html) dans le manuel *Amazon Elastic Container Service Developer Guide*. Pour plus d'informations sur l'utilisation de plusieurs équilibreurs de charge avec Amazon ECS, consultez la section [Enregistrement de plusieurs groupes cibles auprès d'un service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html) dans le manuel *Amazon Elastic Container Service Developer Guide*.
## Puis-je effectuer des déploiements CodeDeploy bleu/vert sans équilibreur de charge ?
Non, vous ne pouvez pas effectuer de déploiements CodeDeploy bleu/vert sans équilibreur de charge. Si vous ne parvenez pas à utiliser un équilibreur de charge, utilisez plutôt la fonctionnalité de mises à jour continues d'Amazon ECS. Pour plus d'informations sur les mises à jour continues d'Amazon ECS, consultez la section [Mise à jour continue](https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-type-ecs.html) du manuel *Amazon Elastic Container Service Developer Guide*.
## Comment puis-je mettre à jour mon service Amazon ECS avec de nouvelles informations lors d'un déploiement ?
Pour CodeDeploy mettre à jour votre service Amazon ECS avec un nouveau paramètre pendant qu'il effectue un déploiement, spécifiez le paramètre dans la `resources` section du AppSpec fichier. Seuls quelques paramètres Amazon ECS sont pris en charge CodeDeploy, tels que le fichier de définition des tâches et les paramètres du nom du conteneur. Pour obtenir la liste complète des paramètres Amazon ECS CodeDeploy pouvant être mis à jour, consultez[AppSpec section « ressources » pour les déploiements Amazon ECS](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs).
**Note**
Si vous devez mettre à jour votre service Amazon ECS avec un paramètre qui n'est pas pris en charge par CodeDeploy, effectuez les tâches suivantes :
Appelez l'`UpdateService`API d'Amazon ECS avec le paramètre que vous souhaitez mettre à jour. Pour obtenir la liste complète des paramètres pouvant être mis à jour, consultez [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)le manuel *Amazon Elastic Container Service API Reference*.
Pour appliquer la modification aux tâches, créez un nouveau blue/green déploiement Amazon ECS. Pour de plus amples informations, veuillez consulter [Création d'un déploiement d'Amazon ECS Compute Platform (console)](deployments-create-console-ecs.md).
# Résoudre les problèmes de déploiement AWS de Lambda
**Topics**
+ [AWS Lambda les déploiements échouent après l'arrêt manuel d'un déploiement Lambda pour lequel aucune annulation n'est configurée](#troubleshooting-manually-stopped-lambda-deployment)
## AWS Lambda les déploiements échouent après l'arrêt manuel d'un déploiement Lambda pour lequel aucune annulation n'est configurée
Dans certains cas, l'alias d'une fonction Lambda spécifié dans un déploiement peut faire référence à deux versions différentes de la fonction. Il en résulte que les tentatives suivantes de déploiement de la fonction Lambda échouent. Un déploiement Lambda peut passer dans cet état lorsqu'aucune restauration n'est configurée et qu'il est arrêté manuellement. Pour continuer, utilisez la AWS Lambda console pour vous assurer que la fonction n'est pas configurée pour transférer le trafic entre deux versions :
1. Connectez-vous à la AWS Lambda console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).
1. Dans le volet gauche, sélectionnez **Functions**.
1. Sélectionnez le nom de la fonction Lambda intégrée à votre CodeDeploy déploiement.
1. **Dans Alias**, choisissez l'alias utilisé dans votre CodeDeploy déploiement, puis sélectionnez **Modifier**.
1. Dans **Alias pondéré**, sélectionnez**none**. Cela garantit que l'alias n'est pas configuré pour déplacer un pourcentage ou un poids de trafic à plus d'une seule version. Notez la version sélectionnée dans **Version**.
1. Choisissez **Enregistrer**.
1. Ouvrez la CodeDeploy console et essayez de déployer la version affichée dans le menu déroulant de l'étape 5.
# Résolution des problèmes de groupe de déploiement
## Le balisage d'une instance dans le cadre d'un groupe de déploiement ne déploie pas automatiquement votre application sur la nouvelle instance
CodeDeploy ne déploie pas automatiquement votre application sur une instance nouvellement balisée. Vous devez créer un déploiement dans le groupe de déploiement.
Vous pouvez l'utiliser CodeDeploy pour activer les déploiements automatiques vers de nouvelles instances EC2 dans les groupes Amazon EC2 Auto Scaling. Pour de plus amples informations, veuillez consulter [Intégration CodeDeploy à Amazon EC2 Auto Scaling](integrations-aws-auto-scaling.md).
# Résolution des problèmes d'instance
**Topics**
+ [Les balises doivent être définies correctement](#troubleshooting-EC2-tags)
+ [AWS CodeDeploy l'agent doit être installé et exécuté sur les instances](#troubleshooting-sds-agent)
+ [Les déploiements n'échouent pas pendant une heure lorsqu'une instance est mise hors service au cours d'un déploiement](#troubleshooting-one-hour-timeout)
+ [Analyse des fichiers journaux pour enquêter sur des échecs de déploiement sur les instances](#troubleshooting-deploy-failures)
+ [Créez un nouveau fichier CodeDeploy journal s'il a été supprimé accidentellement](#troubleshooting-create-new-log-file)
+ [Résolution des erreurs de déploiement « InvalidSignatureException — Signature expirée : [heure] est maintenant antérieure à [heure] »](#troubleshooting-instance-time-failures)
## Les balises doivent être définies correctement
Utilisez la commande [list-deployment-instances](https://docs.aws.amazon.com/cli/latest/reference/deploy/list-deployment-instances.html) pour confirmer que les instances utilisées pour un déploiement sont balisées correctement. Si une instance EC2 est absente de la sortie, utilisez la console EC2 pour confirmer que les balises ont été définies sur l'instance. Pour plus d'informations, consultez la section [Utilisation des balises dans la console](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) dans le guide de l'*utilisateur Amazon EC2*.
**Note**
Si vous balisez une instance et que vous l'utilisez immédiatement CodeDeploy pour y déployer une application, l'instance risque de ne pas être incluse dans le déploiement. Cela est dû au fait que plusieurs minutes peuvent CodeDeploy être nécessaires avant de pouvoir lire les balises. Nous vous recommandons d'attendre au moins cinq minutes entre le moment où vous balisez une instance et celui où vous tentez d'y effectuer un déploiement.
## AWS CodeDeploy l'agent doit être installé et exécuté sur les instances
Pour vérifier que l' CodeDeploy agent est installé et s'exécute sur une instance, consultez[Vérifiez que l' CodeDeploy agent est en cours d'exécution](codedeploy-agent-operations-verify.md).
Pour installer, désinstaller ou réinstaller l' CodeDeploy agent, consultez[Installation de l' CodeDeploy agent](codedeploy-agent-operations-install.md).
## Les déploiements n'échouent pas pendant une heure lorsqu'une instance est mise hors service au cours d'un déploiement
CodeDeploy fournit un délai d'une heure pour que chaque événement du cycle de vie du déploiement se déroule jusqu'à son terme. Cela fournit suffisamment de temps pour les scripts de longue durée.
Si les scripts ne s'exécutent pas complètement alors qu'un événement du cycle de vie est en cours (par exemple, si une instance est arrêtée ou si l' CodeDeploy agent est arrêté), l'affichage de l'état du déploiement comme Échec peut prendre jusqu'à une heure. Cela est vrai même si le délai d'expiration spécifié dans le script est inférieur à une heure. En effet, lorsque l'instance est arrêtée, l' CodeDeploy agent s'arrête et ne peut plus traiter d'autres scripts.
Si une instance est mise hors service entre des événements de cycle de vie ou avant le début de la première étape d'événement de cycle de vie, l'expiration du délai a lieu après seulement cinq minutes.
## Analyse des fichiers journaux pour enquêter sur des échecs de déploiement sur les instances
Si le statut d'une instance dans le déploiement est différent de `Succeeded`, vous pouvez passer en revue les données du fichier journal de déploiement pour tenter d'identifier le problème. Pour de plus amples informations sur l'accès aux données du journal de déploiement, veuillez consulter [Afficher les données du journal pour les déploiements CodeDeploy EC2/sur site](deployments-view-logs.md).
## Créez un nouveau fichier CodeDeploy journal s'il a été supprimé accidentellement
Si vous supprimez accidentellement le fichier journal de déploiement sur une instance, CodeDeploy cela ne crée pas de fichier journal de remplacement. Pour créer un nouveau fichier journal, connectez-vous à l'instance, puis exécutez ces commandes :
**Pour une instance Amazon Linux, Ubuntu Server ou RHEL**, exécutez ces commandes dans cet ordre, une par une :
```
systemctl stop codedeploy-agent
```
```
systemctl start codedeploy-agent
```
**Pour une instance Windows Server** :
```
powershell.exe -Command Restart-Service -Name codedeployagent
```
## Résolution des erreurs de déploiement « InvalidSignatureException — Signature expirée : [heure] est maintenant antérieure à [heure] »
CodeDeploy nécessite des références temporelles précises pour effectuer ses opérations. Si la date et l'heure de votre instance ne sont pas correctement définies, elles risquent de ne pas correspondre à la date de signature de votre demande de déploiement, qui est CodeDeploy rejetée.
Pour éviter des échecs de déploiement associés à des paramètres horaires incorrects, consultez les rubriques suivantes :
+ [Réglage de l'heure pour votre instance Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html)
+ [Réglage de l'heure pour une instance Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/windows-set-time.html)
# Résoudre les problèmes liés aux GitHub jetons
## GitHub OAuth Jeton non valide
CodeDeploy les applications créées après juin 2017 utilisent GitHub OAuth des jetons pour chaque AWS région. L'utilisation de jetons liés à des AWS régions spécifiques vous permet de mieux contrôler CodeDeploy les applications qui ont accès à un GitHub référentiel.
Si vous recevez une erreur de GitHub jeton, il se peut que vous ayez un ancien jeton qui n'est plus valide.
**Pour corriger un GitHub OAuth jeton non valide**
1. Supprimez l'ancien jeton en utilisant l'une des méthodes suivantes :
+ Pour supprimer l'ancien jeton à l'aide de l'API, utilisez [ DeleteGitHubAccountToken](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_DeleteGitHubAccountToken.html).
+ Pour supprimer l'ancien jeton en utilisant AWS Command Line Interface :
1. Accédez à l'ordinateur sur lequel réside le jeton.
1. Assurez-vous que le AWS CLI est installé sur cet ordinateur. Pour les instructions d'installation, reportez-vous à la section [Installation, mise à jour et désinstallation du AWS CLI dans le](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) guide de l'*AWS Command Line Interface utilisateur*
1. Entrez la commande suivante sur l'ordinateur sur lequel réside le jeton :
**aws delete-git-hub-account-token**
Pour plus de détails sur la syntaxe des commandes, consultez [delete-git-hub-account-token](https://docs.aws.amazon.com/cli/latest/reference/deploy/delete-git-hub-account-token.html).
1. Ajoutez un nouveau OAuth jeton. Pour de plus amples informations, veuillez consulter [Intégration CodeDeploy avec GitHub](integrations-partners-github.md).
## Nombre maximum de GitHub OAuth jetons dépassé
Lorsque vous créez un CodeDeploy déploiement, le nombre maximum de GitHub jetons autorisés est de 10. Si vous recevez un message d'erreur concernant les GitHub OAuth jetons, assurez-vous que vous disposez de 10 jetons ou moins. Si vous avez plus de 10 jetons, les premiers jetons qui ont été créés ne sont pas valides. Par exemple, si vous avez 11 jetons, le premier jeton que vous avez créé n'est pas valide. Si vous avez 12 jetons, les deux premiers jetons que vous avez créés ne sont pas valides. Pour plus d'informations sur l'utilisation de l' CodeDeploy API pour supprimer d'anciens jetons, consultez [ DeleteGitHubAccountToken](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_DeleteGitHubAccountToken.html).
# Résoudre les problèmes liés à Amazon EC2 Auto Scaling
**Topics**
+ [Résolution générale des problèmes liés à Amazon EC2 Auto Scaling](#troubleshooting-auto-scaling-general)
+ [« CodeDeployRole ne vous autorise pas à effectuer des opérations dans le AWS service suivant : AmazonAutoScaling » erreur](#troubleshooting-auto-scaling-permissions-error)
+ [Les instances d'un groupe Amazon EC2 Auto Scaling sont continuellement provisionnées et mises hors service avant qu'une révision ne puisse être déployée](#troubleshooting-auto-scaling-provision-termination-loop)
+ [La mise hors service ou le redémarrage d'une instance Amazon EC2 Auto Scaling peut entraîner l'échec des déploiements](#troubleshooting-auto-scaling-reboot)
+ [Évitez d'associer plusieurs groupes de déploiement à un seul groupe Amazon EC2 Auto Scaling](#troubleshooting-multiple-depgroups)
+ [Les instances EC2 d'un groupe Amazon EC2 Auto Scaling ne se lancent pas et reçoivent l'erreur « Heartbeat Timeout »](#troubleshooting-auto-scaling-heartbeat)
+ [Des hooks de cycle de vie Amazon EC2 Auto Scaling mal adaptés peuvent entraîner l'arrêt ou l'échec des déploiements automatiques vers les groupes Amazon EC2 Auto Scaling](#troubleshooting-auto-scaling-hooks)
+ [Erreur « Le déploiement a échoué car aucune instance n'a été trouvée pour votre groupe de déploiement »](#troubleshooting-deployment-failed-because-no-instances-found)
## Résolution générale des problèmes liés à Amazon EC2 Auto Scaling
Les déploiements vers des instances EC2 d'un groupe Amazon EC2 Auto Scaling peuvent échouer pour les raisons suivantes :
+ **Amazon EC2 Auto Scaling lance et met fin en permanence aux instances EC2.** Si vous CodeDeploy ne parvenez pas à déployer automatiquement la révision de votre application, Amazon EC2 Auto Scaling lance et arrête en permanence les instances EC2.
Dissociez le groupe Amazon EC2 Auto Scaling du groupe de CodeDeploy déploiement ou modifiez la configuration de votre groupe Amazon EC2 Auto Scaling afin que le nombre d'instances souhaité corresponde au nombre actuel d'instances (empêchant ainsi Amazon EC2 Auto Scaling de lancer d'autres instances EC2). Pour plus d'informations, consultez notre section [Modifiez les paramètres du groupe de déploiement avec CodeDeploy](deployment-groups-edit.md) [Manual Scaling for Amazon EC2 Auto](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html) Scaling.
+ **L' CodeDeploy agent ne répond pas.** L' CodeDeploy agent risque de ne pas être installé si les scripts d'initialisation (par exemple, les scripts cloud-init) qui s'exécutent immédiatement après le lancement ou le démarrage d'une instance EC2 mettent plus d'une heure à s'exécuter. CodeDeploy dispose d'un délai d'une heure pour que l' CodeDeploy agent réponde aux déploiements en attente. Pour résoudre ce problème, placez vos scripts d'initialisation dans votre révision d'application CodeDeploy.
+ **Une instance EC2 d'un groupe Amazon EC2 Auto Scaling redémarre lors d'un déploiement.** Votre déploiement peut échouer si une instance EC2 est redémarrée pendant un déploiement ou si l' CodeDeploy agent est arrêté pendant le traitement d'une commande de déploiement. Pour de plus amples informations, veuillez consulter [La mise hors service ou le redémarrage d'une instance Amazon EC2 Auto Scaling peut entraîner l'échec des déploiements](#troubleshooting-auto-scaling-reboot).
+ **Plusieurs révisions d'applications sont déployées simultanément sur la même instance EC2 dans un groupe Amazon EC2 Auto Scaling.** Le déploiement simultané de plusieurs révisions d'application sur la même instance EC2 d'un groupe Amazon EC2 Auto Scaling peut échouer si l'un des déploiements comporte des scripts qui s'exécutent pendant plus de quelques minutes. Ne déployez pas plusieurs révisions d'applications sur les mêmes instances EC2 d'un groupe Amazon EC2 Auto Scaling.
+ **Un déploiement échoue pour les nouvelles instances EC2 lancées dans le cadre d'un groupe Amazon EC2 Auto Scaling.** Dans ce scénario, l'exécution des scripts dans un déploiement peut empêcher le lancement d'instances EC2 dans le groupe Amazon EC2 Auto Scaling. (Les autres instances EC2 du groupe Amazon EC2 Auto Scaling peuvent sembler fonctionner normalement.) Pour résoudre ce problème, veillez à ce que tous les autres scripts se terminent en premier :
+ **CodeDeploy l'agent n'est pas inclus dans votre AMI** : si vous utilisez la **cfn-init** commande pour installer l' CodeDeploy agent lors du lancement d'une nouvelle instance, placez le script d'installation de l'agent à la fin de la `cfn-init` section de votre CloudFormation modèle.
+ **CodeDeploy l'agent est inclus dans votre AMI** : configurez l'AMI de manière à ce que l'agent soit dans son `Stopped` état lorsque l'instance est créée, puis incluez un script pour démarrer l'agent comme dernière étape dans votre bibliothèque de `cfn-init` scripts.
## « CodeDeployRole ne vous autorise pas à effectuer des opérations dans le AWS service suivant : AmazonAutoScaling » erreur
Les déploiements qui utilisent un groupe Auto Scaling créé à l'aide d'un modèle de lancement nécessitent les autorisations suivantes. Elles s'ajoutent aux autorisations accordées par la politique `AWSCodeDeployRole` AWS gérée.
+ `EC2:RunInstances`
+ `EC2:CreateTags`
+ `iam:PassRole`
Il se peut que vous receviez cette erreur si vous ne disposez pas ces autorisations. Pour plus d'informations[Tutoriel : CodeDeploy À utiliser pour déployer une application dans un groupe Auto Scaling](tutorials-auto-scaling-group.md), consultez [Création d'un modèle de lancement pour un groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) et [Permissions](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html#launch-templates-permissions) dans le guide de l'*utilisateur Amazon EC2 Auto Scaling*.
## Les instances d'un groupe Amazon EC2 Auto Scaling sont continuellement provisionnées et mises hors service avant qu'une révision ne puisse être déployée
Dans certains cas, une erreur peut empêcher un déploiement réussi sur des instances nouvellement provisionnées dans un groupe Amazon EC2 Auto Scaling. En conséquence, aucune instance n'est saine et aucun déploiement n'est réussi. Le déploiement ne pouvant pas être exécuté ou terminé, les instances sont terminées peu de temps après leur création. La configuration du groupe Amazon EC2 Auto Scaling entraîne ensuite le provisionnement d'un autre lot d'instances pour tenter de répondre aux exigences minimales en matière d'hôtes sains. Ce lot est également terminé et le cycle se poursuit.
Les causes possibles incluent :
+ Échec des vérifications de l'état du groupe Amazon EC2 Auto Scaling.
+ Erreur dans la révision d'application.
Pour résoudre ce problème, suivez les étapes suivantes :
1. Créez manuellement une instance EC2 qui ne fait pas partie du groupe Amazon EC2 Auto Scaling. Balisez l'instance avec une balise d'instance EC2 unique.
1. Ajoutez la nouvelle instance au groupe de déploiement affecté.
1. Déployez une nouvelle révision d'application sans erreur dans le groupe de déploiement.
Cela invite le groupe Amazon EC2 Auto Scaling à déployer la révision de l'application sur les futures instances du groupe Amazon EC2 Auto Scaling.
**Note**
Après avoir confirmé que les déploiements sont réussis, supprimez l'instance que vous avez créée afin d'éviter des frais permanents sur votre AWS compte.
## La mise hors service ou le redémarrage d'une instance Amazon EC2 Auto Scaling peut entraîner l'échec des déploiements
Si une instance EC2 est lancée via Amazon EC2 Auto Scaling, puis qu'elle est arrêtée ou redémarrée, les déploiements vers cette instance peuvent échouer pour les raisons suivantes :
+ Au cours d'un déploiement en cours, un événement de scale-in ou tout autre événement de terminaison entraîne le détachement de l'instance du groupe Amazon EC2 Auto Scaling, puis son arrêt. Comme le déploiement ne peut pas être terminé, il échoue.
+ L'instance est redémarrée, mais son démarrage prend plus de cinq minutes. CodeDeploy traite cela comme un délai d'attente. Le service considère tous les déploiements actuels et futurs sur l'instance comme ayant échoué.
Pour résoudre ce problème :
+ En général, assurez-vous que tous les déploiements sont terminés avant la mise hors service ou le redémarrage de l'instance. Assurez-vous que tous les déploiements commencent après le démarrage ou le redémarrage de l'instance.
+ Les déploiements peuvent échouer si vous spécifiez une Amazon Machine Image (AMI) basée sur Windows Server pour une configuration Amazon EC2 Auto Scaling et si vous utilisez le service EC2 Config pour définir le nom d'ordinateur de l'instance. Pour résoudre ce problème, dans l'AMI de base de Windows Server, sous l'onglet **Général** des **propriétés du service EC2**, désactivez l'option **Définir le nom de l'ordinateur**. Une fois que vous avez décoché cette case, ce comportement est désactivé pour toutes les nouvelles instances Amazon EC2 Auto Scaling de Windows Server lancées avec cette AMI de base Windows Server. Pour les instances Amazon EC2 Auto Scaling de Windows Server sur lesquelles ce comportement est activé, il n'est pas nécessaire de décocher cette case. Il vous suffit de redéployer les déploiements ayant échoué sur ces instances après qu'elles ont été redémarrées.
## Évitez d'associer plusieurs groupes de déploiement à un seul groupe Amazon EC2 Auto Scaling
Il est recommandé d'associer un seul groupe de déploiement à chaque groupe Amazon EC2 Auto Scaling.
En effet, si Amazon EC2 Auto Scaling augmente le volume d'une instance comportant des hooks associés à plusieurs groupes de déploiement, il envoie des notifications pour tous les hooks en une seule fois. Cela entraîne le commencement simultané de plusieurs déploiements sur chaque instance. Lorsque plusieurs déploiements envoient des commandes à l' CodeDeploy agent en même temps, le délai de cinq minutes entre un événement du cycle de vie et le début du déploiement ou la fin de l'événement du cycle de vie précédent peut être atteint. Le cas échéant, le déploiement est mis en échec, même si un processus de déploiement se déroule par ailleurs sans difficulté.
**Note**
Le délai d'expiration par défaut d'un script dans un événement du cycle de vie est de 30 minutes. Vous pouvez remplacer le délai d'expiration par une autre valeur dans le AppSpec fichier. Pour de plus amples informations, veuillez consulter [Ajouter un AppSpec fichier pour un déploiement EC2/sur site](application-revisions-appspec-file.md#add-appspec-file-server).
Il n'est pas possible de contrôler l'ordre dans lequel les déploiements se produisent si plusieurs déploiements tentent de s'exécuter en même temps.
Enfin, si le déploiement sur une instance échoue, Amazon EC2 Auto Scaling met immédiatement fin à l'instance. Lorsque cette première instance s'arrête, les autres déploiements en cours d’exécution échouent progressivement. Étant donné que l' CodeDeploy agent CodeDeploy dispose d'un délai d'une heure pour répondre aux déploiements en attente, le délai d'expiration de chaque instance peut prendre jusqu'à 60 minutes.
Pour plus d'informations sur Amazon EC2 Auto Scaling, [consultez Under the hood CodeDeploy : and Auto Scaling integration](https://aws.amazon.com/blogs/devops/under-the-hood-aws-codedeploy-and-auto-scaling-integration/).
## Les instances EC2 d'un groupe Amazon EC2 Auto Scaling ne se lancent pas et reçoivent l'erreur « Heartbeat Timeout »
Il se peut qu'un groupe Amazon EC2 Auto Scaling ne parvienne pas à lancer de nouvelles instances EC2, générant un message similaire au suivant :
`Launching a new EC2 instance . Status Reason: Instance failed to complete user's Lifecycle Action: Lifecycle Action with token was abandoned: Heartbeat Timeout`.
Ce message indique généralement l'une des situations suivantes :
+ Le nombre maximum de déploiements simultanés associés à un AWS compte a été atteint. Pour plus d'informations sur les limites, consultez [CodeDeploy quotas](limits.md).
+ Le groupe Auto Scaling a essayé de lancer trop d'instances EC2 trop rapidement. Les appels d'API vers [RecordLifecycleActionHeartbeat](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_RecordLifecycleActionHeartbeat.html)ou [CompleteLifecycleAction](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html)pour chaque nouvelle instance ont été limités.
+ Une application CodeDeploy a été supprimée avant que les groupes de déploiement associés ne soient mis à jour ou supprimés.
Lorsque vous supprimez une application ou un groupe de déploiement, vous CodeDeploy tentez de nettoyer tous les hooks Amazon EC2 Auto Scaling qui y sont associés, mais certains hooks peuvent subsister. Si vous exécutez une commande pour supprimer un groupe de déploiement, les hooks restants sont renvoyés dans la sortie. Toutefois, si vous exécutez une commande pour supprimer une application, les hooks restants n'apparaissent pas dans la sortie.
Par conséquent, la bonne pratique consiste à supprimer tous les groupes de déploiement associés à une application avant de supprimer l'application. Vous pouvez utiliser la sortie de la commande pour identifier les hooks du cycle de vie qui doivent être supprimés manuellement.
Si vous recevez un message d'erreur « Heartbeat Timeout », vous pouvez déterminer si les hooks de cycle de vie restants en sont la cause et résoudre le problème en procédant comme suit :
1. Effectuez l’une des actions suivantes :
+ Appelez la [delete-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/delete-deployment-group.html)commande pour supprimer le groupe de déploiement associé au groupe Auto Scaling à l'origine du délai d'expiration du rythme cardiaque.
+ Appelez la [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html)commande avec une liste vide non nulle de noms de groupes Auto Scaling pour détacher tous les hooks du cycle de vie Auto CodeDeploy Scaling gérés par Auto Scaling.
Par exemple, entrez la AWS CLI commande suivante :
`aws deploy update-deployment-group --application-name my-example-app --current-deployment-group-name my-deployment-group --auto-scaling-groups`
Autre exemple, si vous utilisez l' CodeDeploy API avec Java, appelez `UpdateDeploymentGroup` et définissez `autoScalingGroups` sur`new ArrayList()`. Cela permet `autoScalingGroups` de définir une liste vide et de supprimer la liste existante. Ne l'utilisez pas`null`, ce qui est le cas par défaut, car cela reste tel `autoScalingGroups` quel, ce qui n'est pas ce que vous voulez.
Examinez la sortie de l'appel. Si la sortie contient une `hooksNotCleanedUp` structure avec une liste des hooks du cycle de vie d'Amazon EC2 Auto Scaling, il reste des hooks du cycle de vie.
1. Appelez la [describe-lifecycle-hooks](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-lifecycle-hooks.html)commande en spécifiant le nom du groupe Amazon EC2 Auto Scaling associé aux instances EC2 qui n'ont pas pu être lancées. Dans le résultat, recherchez l'un des éléments suivants :
+ Les noms des hooks du cycle de vie d'Amazon EC2 Auto Scaling correspondent à `hooksNotCleanedUp` la structure que vous avez identifiée à l'étape 1.
+ Noms des hooks du cycle de vie Amazon EC2 Auto Scaling contenant le nom du groupe de déploiement associé au groupe Auto Scaling défaillant.
+ Noms des hooks du cycle de vie d'Amazon EC2 Auto Scaling susceptibles d'avoir provoqué le délai d'expiration du déploiement. CodeDeploy
1. Si un hook appartient à l'une des catégories répertoriées à l'étape 2, appelez la [delete-lifecycle-hook](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-lifecycle-hook.html)commande pour le supprimer. Spécifiez le groupe Amazon EC2 Auto Scaling et le hook du cycle de vie dans l'appel.
**Important**
Supprimez uniquement les hooks qui posent problème, comme indiqué à l'étape 2. Si vous supprimez des hooks viables, vos déploiements risquent d' CodeDeploy échouer ou de ne pas être en mesure de déployer les révisions de votre application sur des instances EC2 redimensionnées.
1. Appelez la [create-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment-group.html)commande [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html)ou avec les noms de groupes Auto Scaling souhaités. CodeDeployréinstalle les hooks Auto Scaling avec de nouveaux. UUIDs
**Note**
Si vous dissociez un groupe Auto Scaling d'un groupe de CodeDeploy déploiement, les déploiements en cours vers le groupe Auto Scaling risquent d'échouer et les nouvelles instances EC2 redimensionnées par le groupe Auto Scaling ne recevront pas les révisions de votre application. CodeDeploy Pour que Auto Scaling fonctionne à nouveau CodeDeploy, vous devez rattacher le groupe Auto Scaling au groupe de déploiement et appeler un nouveau groupe `CreateDeployment` pour démarrer un déploiement à l'échelle du parc.
## Des hooks de cycle de vie Amazon EC2 Auto Scaling mal adaptés peuvent entraîner l'arrêt ou l'échec des déploiements automatiques vers les groupes Amazon EC2 Auto Scaling
Amazon EC2 Auto Scaling CodeDeploy et utilisez des hooks de cycle de vie pour déterminer quelles révisions d'applications doivent être déployées sur quelles instances EC2 après leur lancement dans les groupes Amazon EC2 Auto Scaling. Les déploiements automatiques peuvent s'arrêter ou échouer si les hooks du cycle de vie et les informations les concernant ne correspondent pas exactement dans Amazon EC2 Auto Scaling et. CodeDeploy
Si les déploiements vers un groupe Amazon EC2 Auto Scaling échouent, vérifiez si les noms des crochets du cycle de vie dans Amazon EC2 Auto Scaling correspondent. CodeDeploy Si ce n'est pas le cas, utilisez ces appels de AWS CLI commande.
Tout d'abord, obtenez la liste des noms des hooks du cycle de vie pour le groupe Amazon EC2 Auto Scaling et le groupe de déploiement :
1. Appelez la [describe-lifecycle-hooks](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-lifecycle-hooks.html)commande en spécifiant le nom du groupe Amazon EC2 Auto Scaling associé au groupe de déploiement dans. CodeDeploy Dans la sortie, dans la liste `LifecycleHooks`, notez chaque valeur `LifecycleHookName`.
1. Appelez la [get-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-group.html)commande en spécifiant le nom du groupe de déploiement associé au groupe Amazon EC2 Auto Scaling. Dans la sortie, dans la `autoScalingGroups` liste, recherchez chaque élément dont le nom correspond au nom du groupe Amazon EC2 Auto Scaling, puis notez la valeur `hook` correspondante.
Comparez alors les deux ensembles de noms de hooks de cycle de vie. S'ils correspondent exactement, caractère par caractère, le problème est ailleurs. Vous pouvez essayer d'autres étapes de dépannage d'Amazon EC2 Auto Scaling décrites ailleurs dans cette section.
Toutefois, si les deux ensembles de noms de hooks de cycle de vie ne correspondent pas exactement, caractère par caractère, procédez comme suit :
1. Si des noms de hooks de cycle de vie figurent dans la sortie de la commande **describe-lifecycle-hooks** qui ne figurent pas également dans la sortie de la commande **get-deployment-group**, procédez comme suit :
1. Pour chaque nom de hook du cycle de vie indiqué dans la sortie de **describe-lifecycle-hooks** commande, appelez la [delete-lifecycle-hook](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-lifecycle-hook.html)commande.
1. Appelez la [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html)commande en spécifiant le nom du groupe Amazon EC2 Auto Scaling d'origine. CodeDeploy crée de nouveaux hooks de cycle de vie de remplacement dans le groupe Amazon EC2 Auto Scaling et associe les crochets de cycle de vie au groupe de déploiement. Les déploiements automatiques devraient maintenant reprendre à mesure que de nouvelles instances sont ajoutées au groupe Amazon EC2 Auto Scaling.
1. Si des noms de hooks de cycle de vie figurent dans la sortie de la commande **get-deployment-group**, mais ne figurent pas dans la sortie de la commande **describe-lifecycle-hooks**, procédez comme suit :
1. Appelez la [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html)commande, mais ne spécifiez pas le nom du groupe Amazon EC2 Auto Scaling d'origine.
1. Appelez à nouveau la **update-deployment-group** commande, mais spécifiez cette fois le nom du groupe Amazon EC2 Auto Scaling d'origine. CodeDeploy recrée les hooks du cycle de vie manquants dans le groupe Amazon EC2 Auto Scaling. Les déploiements automatiques devraient maintenant reprendre à mesure que de nouvelles instances sont ajoutées au groupe Amazon EC2 Auto Scaling.
Une fois que les deux ensembles de noms de hooks du cycle de vie correspondent exactement, caractère par caractère, les révisions de l'application doivent être déployées à nouveau, mais uniquement sur les nouvelles instances au fur et à mesure qu'elles sont ajoutées au groupe Amazon EC2 Auto Scaling. Les déploiements ne sont pas effectués automatiquement sur des instances qui font déjà partie du groupe Amazon EC2 Auto Scaling.
## Erreur « Le déploiement a échoué car aucune instance n'a été trouvée pour votre groupe de déploiement »
Lisez cette section si le message d' CodeDeploy erreur suivant s'affiche :
`The deployment failed because no instances were found for your deployment group. Check your deployment group settings to make sure the tags for your EC2 instances or Auto Scaling groups correctly identify the instances you want to deploy to, and then try again.`
Les causes possibles de cette erreur sont les suivantes :
1. Les paramètres de votre groupe de déploiement incluent des balises incorrectes pour les instances EC2, les instances sur site ou les groupes Auto Scaling. Pour résoudre ce problème, vérifiez que vos balises sont correctes, puis redéployez votre application.
1. Votre flotte s'est agrandie après le début du déploiement. Dans ce scénario, vous voyez des instances saines dans l'`InService`état de votre flotte, mais vous voyez également l'erreur ci-dessus. Pour résoudre ce problème, redéployez votre application.
1. Votre groupe Auto Scaling n'inclut aucune instance présente dans `InService` cet état. Dans ce scénario, lorsque vous essayez d'effectuer un déploiement à l'échelle du parc, le déploiement échoue avec le message d'erreur ci-dessus car il CodeDeploy faut qu'au moins une instance soit dans cet état. `InService` Il existe de nombreuses raisons pour lesquelles vous n'avez peut-être aucune instance dans l'`InService`État. Quelques-uns d'entre eux incluent :
+ Vous avez planifié (ou configuré manuellement) la taille du groupe Auto Scaling comme suit `0` :
+ Auto Scaling a détecté des instances EC2 défectueuses (par exemple, les instances EC2 présentaient des défaillances matérielles), les a donc toutes annulées, n'en laissant aucune dans l'`InService`état.
+ Au cours d'un événement de `0` scale-out de à`1`, a CodeDeploy déployé une révision précédemment réussie (appelée *dernière révision réussie*) qui était devenue défectueuse depuis le dernier déploiement. Cela a entraîné l'échec du déploiement sur l'instance redimensionnée, ce qui a entraîné l'annulation de l'instance par Auto Scaling, ne laissant aucune instance dans cet état. `InService`
Si vous constatez qu'aucune instance n'est présente dans `InService` cet état, résolvez le problème comme décrit dans la procédure suivante,[To troubleshoot the error if there are no instances in the InService state](#ToTroubleshootIfNoInServiceInstances).
**Pour résoudre l'erreur s'il n'y a aucune instance dans l'état InService**
1. Dans la console Amazon EC2, vérifiez le paramètre **Capacité souhaitée.** S'il est égal à zéro, définissez-le sur un nombre positif. Attendez que l'instance existe`InService`, ce qui signifie que le déploiement a réussi. Vous avez résolu le problème et pouvez ignorer les étapes restantes de cette procédure de dépannage. Pour plus d'informations sur la définition du paramètre **Desired** Capacity, consultez la section [Setting capacity limits on your Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html) dans le manuel *Amazon EC2 Auto Scaling User Guide*.
1. Si Auto Scaling continue d'essayer de lancer de nouvelles instances EC2 pour atteindre la capacité souhaitée mais ne parvient jamais à le faire évoluer, cela est généralement dû à un échec du hook du cycle de vie d'Auto Scaling. Résolvez ce problème comme suit :
1. Pour savoir quel événement Auto Scaling Lifecycle Hook échoue, consultez la section [Vérification d'une activité de dimensionnement pour un groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html) dans le guide de l'utilisateur Amazon EC2 Auto Scaling.
1. Si le nom du hook défaillant est`CodeDeploy-managed-automatic-launch-deployment-hook-DEPLOYMENT_GROUP_NAME`, accédez au groupe de déploiement CodeDeploy, recherchez le groupe de déploiement et recherchez le déploiement ayant échoué lancé par Auto Scaling. Déterminez ensuite pourquoi le déploiement a échoué.
1. Si vous comprenez pourquoi le déploiement a échoué (par exemple, des CloudWatch alarmes se sont produites) et que vous pouvez résoudre le problème sans modifier la révision, faites-le maintenant.
1. Si, après enquête, vous déterminez que CodeDeploy la *dernière révision réussie* n'est plus saine et qu'il n'y a aucune instance saine dans votre groupe Auto Scaling, vous êtes dans un scénario de blocage du déploiement. Pour résoudre ce problème, vous devez corriger la mauvaise CodeDeploy révision en supprimant temporairement le hook CodeDeploy du cycle de vie du groupe Auto Scaling, puis en le réinstallant et en redéployant une nouvelle (bonne) révision. Pour obtenir des instructions, consultez :
+ [To fix the deployment deadlock issue (CLI)](#ToFixDeployDeadlockCLI)
+ [To fix the deployment deadlock issue (console)](#ToFixDeployDeadlockConsole)
**Pour résoudre le problème de blocage du déploiement (CLI)**
1. (Facultatif) Bloquez les CI/CD pipelines à l'origine de l' CodeDeploy erreur afin d'éviter des déploiements inattendus pendant que vous résolvez ce problème.
1. Prenez note de votre **DesiredCapacity**paramètre Auto Scaling actuel :
`aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name ASG_NAME`
Vous devrez peut-être revenir à ce chiffre à la fin de cette procédure.
1. Définissez le **DesiredCapacity**paramètre Auto Scaling sur`1`. Ceci est facultatif si la capacité souhaitée était supérieure `1` à la capacité initiale. En le réduisant à`1`, l'instance mettra moins de temps à provisionner et à déployer ultérieurement, ce qui accélère le dépannage. Si la capacité souhaitée par Auto Scaling était initialement définie sur`0`, vous devez l'augmenter à`1`. Cela est obligatoire.
aws autoscaling set-desired-capacity -- auto-scaling-group-name *ASG\$1NAME* --desired-capacity 1
**Note**
Les étapes restantes de cette procédure supposent que vous avez défini votre valeur **DesiredCapacity**sur`1`.
À ce stade, Auto Scaling tente d'effectuer une mise à l'échelle jusqu'à une seule instance. Ensuite, comme le hook CodeDeploy ajouté est toujours présent, CodeDeploy essaie de se déployer ; le déploiement échoue ; Auto Scaling annule l'instance ; et Auto Scaling essaie de relancer une instance pour atteindre la capacité souhaitée d'une instance, mais échoue à nouveau. Vous êtes dans une boucle d'annulation/relance.
1. Désenregistrez le groupe Auto Scaling du groupe de déploiement :
**Avertissement**
La commande suivante lancera une nouvelle instance EC2 sans logiciel. Avant d'exécuter la commande, assurez-vous qu'une `InService` instance Auto Scaling n'exécutant aucun logiciel est acceptable. Par exemple, assurez-vous que l'équilibreur de charge associé à l'instance n'envoie pas de trafic vers cet hôte sans logiciel.
**Important**
Utilisez la CodeDeploy commande ci-dessous pour retirer le crochet. Ne supprimez pas le crochet via le service Auto Scaling, car le retrait ne sera pas reconnu par CodeDeploy.
`aws deploy update-deployment-group --application-name APPLICATION_NAME --current-deployment-group-name DEPLOYMENT_GROUP_NAME --auto-scaling-groups`
Après avoir exécuté cette commande, voici ce qui se produit :
1. CodeDeploy désenregistre le groupe Auto Scaling du groupe de déploiement.
1. CodeDeploy supprime le hook du cycle de vie Auto Scaling du groupe Auto Scaling.
1. Le hook à l'origine de l'échec du déploiement n'étant plus présent, Auto Scaling annule l'instance EC2 existante et en lance immédiatement une nouvelle pour l'adapter à la capacité souhaitée. La nouvelle instance devrait bientôt passer à `InService` l'état. La nouvelle instance n'inclut aucun logiciel.
1. Attendez que l'instance EC2 entre dans l'`InService`état. Pour vérifier son état, utilisez la commande suivante :
`aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names ASG_NAME --query AutoScalingGroups[0].Instances[*].LifecycleState`
1. Ajoutez le hook à l'instance EC2 :
**Important**
Utilisez la CodeDeploy commande ci-dessous pour ajouter le crochet. N'utilisez pas le service Auto Scaling pour ajouter le hook, car l'ajout ne sera pas reconnu par CodeDeploy.
`aws deploy update-deployment-group --application-name APPLICATION_NAME --current-deployment-group-name DEPLOYMENT_GROUP_NAME --auto-scaling-groups ASG_NAME`
Après avoir exécuté cette commande, voici ce qui se produit :
1. CodeDeploy réinstalle le hook du cycle de vie Auto Scaling sur l'instance EC2
1. CodeDeploy réenregistre le groupe Auto Scaling auprès du groupe de déploiement.
1. Créez un déploiement à l'échelle du parc à l'aide de l'Amazon S3 ou de GitHub la version dont vous savez qu'elle est saine et que vous souhaitez utiliser.
Par exemple, si la révision est un fichier .zip dans un compartiment Amazon S3 appelé `my-revision-bucket` avec une clé d'objet de`httpd_app.zip`, entrez la commande suivante :
`aws deploy create-deployment --application-name APPLICATION_NAME --deployment-group-name DEPLOYMENT_GROUP_NAME --revision "revisionType=S3,s3Location={bucket=my-revision-bucket,bundleType=zip,key=httpd_app.zip}"`
Comme il existe désormais une `InService` instance dans le groupe Auto Scaling, ce déploiement devrait fonctionner et le message d'erreur « *Le déploiement a échoué car aucune instance n'a été trouvée pour votre groupe de déploiement* » ne devrait plus s'afficher.
1. Une fois le déploiement réussi, redimensionnez votre groupe Auto Scaling à sa capacité initiale, si vous l'avez déjà redimensionné :
`aws autoscaling set-desired-capacity --auto-scaling-group-name ASG_NAME --desired-capacity ORIGINAL_CAPACITY`
**Pour résoudre le problème de blocage du déploiement (console)**
1. (Facultatif) Bloquez les CI/CD pipelines à l'origine de l' CodeDeploy erreur afin d'éviter des déploiements inattendus pendant que vous résolvez ce problème.
1. Accédez à la console Amazon EC2 et prenez note de votre paramètre de **capacité Auto Scaling Desired.** Vous devrez peut-être revenir à ce chiffre à la fin de cette procédure. Pour plus d'informations sur la recherche de ce paramètre, consultez la section [Définition des limites de capacité sur votre groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html).
1. Définissez le nombre d'instances EC2 souhaité comme suit : `1`
Ceci est facultatif si la capacité souhaitée était supérieure `1` à la capacité initiale. En le réduisant à`1`, l'instance mettra moins de temps à provisionner et à déployer ultérieurement, ce qui accélère le dépannage. Si votre **capacité Auto Scaling Desired** était initialement définie sur`0`, vous devez l'augmenter à`1`. Cela est obligatoire.
**Note**
Les étapes restantes de cette procédure supposent que vous avez défini **la capacité souhaitée** sur`1`.
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Choisissez la région appropriée.
1. Accédez au groupe Auto Scaling problématique.
1. Dans **Détails du groupe**, choisissez **Modifier**.
1. Réglez **la capacité souhaitée** sur**1**.
1. Choisissez **Mettre à jour**.
1. Désenregistrez le groupe Auto Scaling du groupe de déploiement :
**Avertissement**
Les sous-étapes suivantes lanceront une nouvelle instance EC2 sans logiciel. Avant d'exécuter la commande, assurez-vous qu'une `InService` instance Auto Scaling n'exécutant aucun logiciel est acceptable. Par exemple, assurez-vous que l'équilibreur de charge associé à l'instance n'envoie pas de trafic vers cet hôte sans logiciel.
1. Ouvrez la CodeDeploy console à l'adresse [https://console.aws.amazon.com/codedeploy/](https://console.aws.amazon.com/codedeploy/).
1. Choisissez la région appropriée.
1. Dans le volet de navigation, choisissez **Applications**.
1. Choisissez le nom de votre CodeDeploy application.
1. Choisissez le nom de votre groupe CodeDeploy de déploiement.
1. Choisissez **Modifier**.
1. Dans **Configuration de l'environnement**, désélectionnez les groupes **Amazon EC2 Auto Scaling**.
**Note**
La console ne vous permet pas d'enregistrer la configuration si aucune configuration d'environnement n'est définie. Pour contourner cette vérification, ajoutez temporairement un tag de `EC2` ou `On-premises` dont vous savez qu'il ne sera résolu à aucun hôte. Pour ajouter une balise, sélectionnez des **instances Amazon EC2** ou une **instance sur site**, puis ajoutez une balise **Key** of or. **EC2** **On-premises** Vous pouvez laisser le tag **Value** vide.
1. Sélectionnez **Enregistrer les modifications**.
Une fois ces sous-étapes terminées, voici ce qui se produit :
1. CodeDeploy désenregistre le groupe Auto Scaling du groupe de déploiement.
1. CodeDeploy supprime le hook du cycle de vie Auto Scaling du groupe Auto Scaling.
1. Le hook à l'origine de l'échec du déploiement n'étant plus présent, Auto Scaling annule l'instance EC2 existante et en lance immédiatement une nouvelle pour l'adapter à la capacité souhaitée. La nouvelle instance devrait bientôt passer à `InService` l'état. La nouvelle instance n'inclut aucun logiciel.
1. Attendez que l'instance EC2 entre dans l'`InService`état. Pour vérifier son état :
1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Dans le panneau de navigation, choisissez **Groupes Auto Scaling**.
1. Choisissez votre groupe Auto Scaling.
1. Dans le volet de contenu, choisissez l'onglet **Instance Management**.
1. Sous **Instances**, assurez-vous que la colonne **Lifecycle** est indiquée à **InService**côté de l'instance.
1. Réenregistrez le groupe Auto Scaling auprès du groupe de CodeDeploy déploiement en utilisant la même méthode que celle que vous avez utilisée pour le supprimer :
1. Ouvrez la CodeDeploy console à l'adresse [https://console.aws.amazon.com/codedeploy/](https://console.aws.amazon.com/codedeploy/).
1. Choisissez la région appropriée.
1. Dans le volet de navigation, choisissez **Applications**.
1. Choisissez le nom de votre CodeDeploy application.
1. Choisissez le nom de votre groupe CodeDeploy de déploiement.
1. Choisissez **Modifier**.
1. Dans **Configuration de l'environnement**, sélectionnez les groupes **Amazon EC2 Auto Scaling** et sélectionnez votre groupe Auto Scaling dans la liste.
1. Sous Instances **Amazon EC2 ou Instances** **sur site**, recherchez le tag que vous avez ajouté et supprimez-le.
1. Décochez la case à côté des instances **Amazon EC2** **ou** des instances sur site.
1. Sélectionnez **Enregistrer les modifications**.
Cette configuration réinstalle le hook du cycle de vie dans le groupe Auto Scaling.
1. Créez un déploiement à l'échelle du parc à l'aide de l'Amazon S3 ou de GitHub la version dont vous savez qu'elle est saine et que vous souhaitez utiliser.
Par exemple, si la révision est un fichier .zip dans un compartiment Amazon S3 appelé `my-revision-bucket` avec une clé d'objet de`httpd_app.zip`, procédez comme suit :
1. Dans la CodeDeploy console, sur la page **Groupe de déploiement**, choisissez **Créer un déploiement**.
1. Pour **Type de révision**, choisissez **Mon application est stockée dans Amazon S3**.
1. Pour **Emplacement de la révision**, sélectionnez`s3://my-revision-bucket/httpd_app.zip`.
1. Pour le **type de fichier de révision**, sélectionnez`.zip`.
1. Choisissez **Créer un déploiement**.
Comme il existe désormais une `InService` instance dans le groupe Auto Scaling, ce déploiement devrait fonctionner et le message d'erreur « *Le déploiement a échoué car aucune instance n'a été trouvée pour votre groupe de déploiement* » ne devrait plus s'afficher.
1. Une fois le déploiement réussi, redimensionnez votre groupe Auto Scaling à sa capacité initiale, si vous l'avez déjà redimensionné :
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Choisissez la région appropriée.
1. Accédez à votre groupe Auto Scaling.
1. Dans **Détails du groupe**, choisissez **Modifier**.
1. **Rétablissez la capacité souhaitée** à sa valeur initiale.
1. Choisissez **Mettre à jour**.
# Codes d'erreur pour AWS CodeDeploy
Cette rubrique fournit des informations de référence sur CodeDeploy les erreurs.
****
| Code d’erreur | Description |
| --- | --- |
| `AGENT_ISSUE` | Le déploiement a échoué en raison d'un problème lié à l' CodeDeploy agent. Assurez-vous que l'agent est installé et en cours d'exécution sur toutes les instances de ce groupe de déploiement. En savoir plus : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/error-codes.html) |
| `AUTO_SCALING_IAM_ROLE_PERMISSIONS` | Le rôle de service associé à votre groupe de déploiement ne dispose pas de l'autorisation requise pour effectuer des opérations dans le AWS service suivant. En savoir plus : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/error-codes.html) |
| `HEALTH_CONSTRAINTS` | Le déploiement global a échoué, car trop d'instances individuelles n'ont pas réussi le déploiement, trop peu d'instances saines sont disponibles pour le déploiement ou certaines instances de votre groupe de déploiement rencontrent des problèmes. En savoir plus : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/error-codes.html) |
| `HEALTH_CONSTRAINTS_INVALID` | Le déploiement ne peut pas démarrer, car le nombre minimal d'instances saines, tel que défini par la configuration de votre déploiement, n'est pas disponible. Vous pouvez réduire le nombre requis d'instances saines en mettant à jour votre configuration de déploiement ou augmenter le nombre d'instances dans ce groupe de déploiement. En savoir plus : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/error-codes.html) |
| `IAM_ROLE_MISSING` | Le déploiement a échoué car il n'existe aucun rôle de service avec le nom du rôle de service spécifié pour le groupe de déploiement. Assurez-vous d'utiliser le nom de rôle de service correct. En savoir plus : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/error-codes.html) |
| `IAM_ROLE_PERMISSIONS` | CodeDeploy ne dispose pas des autorisations requises pour assumer un rôle, ou le rôle IAM que vous utilisez ne vous autorise pas à effectuer des opérations dans un AWS service. En savoir plus : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/error-codes.html) |
| `NO_INSTANCES` | Cela peut être dû à l'une des raisons suivantes. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/error-codes.html) En savoir plus : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/error-codes.html) |
| `OVER_MAX_INSTANCES` | Le déploiement a échoué, car plus d'instances sont ciblées pour le déploiement que d'instances sont autorisées pour votre compte. Afin de réduire le nombre d'instances ciblées pour ce déploiement, mettez à jour les paramètres de balise pour ce groupe de déploiement ou supprimez certaines des instances ciblées. Vous pouvez également nous contacter AWS Support pour demander une augmentation de limite. En savoir plus : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/error-codes.html) |
| `THROTTLED` | Le déploiement a échoué car le nombre de demandes effectuées est supérieur à celui autorisé AWS CodeDeploy par un rôle IAM. Essayez de réduire le nombre de demandes. En savoir plus : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/error-codes.html) |
| `UNABLE_TO_SEND_ASG` | Le déploiement a échoué car le groupe de déploiement n'est pas correctement configuré avec son groupe Amazon EC2 Auto Scaling. Dans la CodeDeploy console, supprimez le groupe Amazon EC2 Auto Scaling du groupe de déploiement, puis ajoutez-le à nouveau. En savoir plus : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/error-codes.html) |
## Rubriques en relation
[Résolution des problèmes CodeDeploy](troubleshooting.md)