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.
# Guide de débogage et dépannage
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé pour les nouveaux clients et les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Si vous avez besoin de déboguer une recette ou de résoudre un problème de service, la meilleure approche consiste généralement à exécuter les étapes suivantes, dans l'ordre :
1. Recherchez votre problème dans [Débogage et dépannage des problèmes courants](common-issues.md).
1. Recherchez sur le [forum OpsWorks Stacks](https://forums.aws.amazon.com/forum.jspa?forumID=153#) pour voir si le problème a déjà été abordé.
Le forum comprend de nombreux utilisateurs expérimentés et est surveillé par l'équipe OpsWorks Stacks.
1. Pour tout problème avec les recettes, consultez [Débogage des recettes](troubleshoot-debug.md).
1. Contactez l'assistance OpsWorks Stacks ou publiez votre problème sur le forum [OpsWorks Stacks](https://forums.aws.amazon.com/forum.jspa?forumID=153#).
La section suivante propose des conseils pour le débogage des recettes. La dernière section décrit les problèmes courants de débogage et de dépannage, et leurs solutions.
**Note**
Chaque exécution de Chef produit un journal qui fournit une description détaillée de l'exécution et constitue une ressource précieuse de dépannage. Pour spécifier la quantité de détails dans le journal, ajoutez une instruction [https://docs.chef.io/resource_log.html](https://docs.chef.io/resource_log.html) pour une recette personnalisée qui spécifie le niveau de journalisation souhaité. La valeur par défaut est `:info`. L'exemple suivant montre comment définir le niveau de journalisation de Chef sur `:debug` afin de fournir la description la plus détaillée de l'exécution.
```
Chef::Log.level = :debug
```
Pour plus d'informations sur l'affichage et l'interprétation des journaux de Chef, consultez [Journaux de Chef](troubleshoot-debug-log.md).
**Topics**
+ [Débogage des recettes](troubleshoot-debug.md)
+ [Débogage et dépannage des problèmes courants](common-issues.md)
# Débogage des recettes
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Lorsqu'un événement du cycle de vie se produit ou si vous exécutez la [commande de pile Execute Recipes](workingstacks-commands.md), OpsWorks Stacks émet une commande auprès de l'[agent](troubleshoot-debug-cli.md) pour lancer une [exécution Chef Solo](https://docs.chef.io/ctl_chef_solo.html) sur les instances spécifiées afin d'exécuter les recettes appropriées, y compris vos recettes personnalisées. Cette section décrit quelques méthodes de débogage des recettes ayant échoué.
**Topics**
+ [Connexion à une instance ayant échoué](troubleshoot-debug-login.md)
+ [Journaux de Chef](troubleshoot-debug-log.md)
+ [Utilisation de la CLI OpsWorks de l'agent Stacks](troubleshoot-debug-cli.md)
# Connexion à une instance ayant échoué
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Si une recette échoue, l'instance n'est pas en ligne et son état devient `setup_failed`. Même si l'instance n'est pas en ligne en ce qui concerne OpsWorks Stacks, elle est en cours d'exécution et il est souvent utile de se connecter pour résoudre le problème. EC2 Par exemple, vous pouvez vérifier si une application ou un livre personnalisé est correctement installé. Le support intégré de OpsWorks Stacks pour la connexion [SSH](workinginstances-ssh.md) et [RDP](workinginstances-rdp.md) n'est disponible que pour les instances en ligne. Toutefois, si vous avez attribué une paire de clés SSH à l'instance, vous pouvez toujours vous connecter, comme suit :
+ Instances Linux : utilisez la clé privée de la paire de clés SSH pour vous connecter à un client SSH tiers, tel qu'OpenSSH ou PuTTY.
Vous pouvez utiliser une paire de EC2 clés ou votre [paire de clés SSH personnelle](security-ssh-access.md) à cette fin.
+ Instances Windows : utilisez la EC2 clé privée de la paire de clés pour récupérer le mot de passe administrateur de l'instance.
Utilisez ce mot de passe pour vous connecter avec votre client RDP préféré. Pour de plus amples informations, veuillez consulter [Connexion en tant qu'Administrateur](workinginstances-rdp.md#workinginstances-rdp-admin). Vous ne pouvez pas utiliser de [paire de clés SSH personnelle](security-ssh-access.md) pour récupérer un mot de passe administrateur.
# Journaux de Chef
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Les journaux Chef sont l'une de vos principales ressources de dépannage, en particulier pour le débogage de recettes. OpsWorks Stacks capture le journal Chef pour chaque commande et conserve les journaux des 30 commandes les plus récentes d'une instance. Etant donné que l'exécution est en mode débogage, le journal contient une description détaillée de l'exécution de Chef, y compris le texte qui est envoyé à `stdout` et `stderror`. Si une recette échoue, le journal inclut la trace de la pile de Chef.
OpsWorks Stacks vous propose plusieurs façons de consulter les journaux Chef. Une fois que vous disposez des informations du journal, vous pouvez les utiliser pour déboguer les recettes ayant échoué.
**Note**
Vous pouvez aussi afficher la queue d'un journal spécifié en utilisant SSH pour vous connecter à l'instance et en exécutant la commande `show_log` de l'interface de ligne de commande de l'agent. Pour de plus amples informations, veuillez consulter [Affichage des journaux de Chef](troubleshoot-debug-cli.md#troubleshoot-debug-cli-log).
**Topics**
+ [Affichage d'un journal de Chef avec la console](#troubleshoot-debug-log-console)
+ [Affichage d'un journal de Chef avec l'API ou l'interface de ligne de commande](#troubleshoot-debug-log-cli)
+ [Affichage d'un journal de Chef sur une instance](#troubleshoot-debug-log-instance)
+ [Interprétation d'un journal Chef](#troubleshoot-debug-log-interpret)
+ [Erreurs courantes dans le journal de Chef](#troubleshoot-debug-log-errors)
## Affichage d'un journal de Chef avec la console
La façon la plus simple pour afficher un journal de Chef consiste à accéder à la page des détails de l'instance. La section **Logs** inclut une entrée pour chaque événement et la commande [Execute Recipes](workingstacks-commands.md). Voici la section **Logs** d'une instance avec les commandes **configure** et **setup** qui correspondent à aux événements de cycle de vie Configure et Setup.
![\[Logs section showing configure and setup commands with timestamps and durations.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/gs11.png)
Cliquez sur **show** dans la colonne **Log** de la commande appropriée pour afficher le journal de Chef correspondant. En cas d'erreur, OpsWorks Stacks ouvre automatiquement le journal de l'erreur, qui se trouve généralement à la fin du fichier.
## Affichage d'un journal de Chef avec l'API ou l'interface de ligne de commande
Vous pouvez utiliser la [https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html)commande OpsWorks Stacks CLI ou l'action [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeCommands.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeCommands.html)API pour consulter les journaux, qui sont stockés dans un compartiment Amazon S3. Voici comment utiliser l'interface de ligne de commande pour afficher l'un des fichiers journaux en cours pour une instance spécifiée. La procédure d'utilisation de `DescribeCommands` est globalement similaire.
**Pour utiliser les OpsWorks Stacks pour afficher les journaux Chef d'une instance**
1. Ouvrez la page de détails de l'instance et copiez sa valeur **OpsWorksd'ID**.
1. Utilisez la valeur d'ID pour exécuter la commande d'interface de ligne de commande `describe-commands`, comme suit :
```
aws opsworks describe-commands --instance-id 67bf0da2-29ed-4217-990c-d895d51812b9
```
La commande renvoie un objet JSON avec un objet intégré pour chaque commande exécutée par OpsWorks Stacks sur l'instance, la plus récente en premier. Le paramètre `Type` contient le type de commande pour chaque objet intégré, une commande `configure` et une commande `setup` dans cet exemple.
```
{
"Commands": [
{
"Status": "successful",
"CompletedAt": "2013-10-25T19:38:36+00:00",
"InstanceId": "67bf0da2-29ed-4217-990c-d895d51812b9",
"AcknowledgedAt": "2013-10-25T19:38:24+00:00",
"LogUrl": "https://s3.amazonaws.com/prod_stage-log/logs/b6c402df-5c23-45b2-a707-ad20b9c5ae40?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE
&Expires=1382731518&Signature=YkqS5IZN2P4wixjHwoC3aCMbn5s%3D&response-cache-control=private&response-content-encoding=gzip&response-content-
type=text%2Fplain",
"Type": "configure",
"CommandId": "b6c402df-5c23-45b2-a707-ad20b9c5ae40",
"CreatedAt": "2013-10-25T19:38:11+00:00",
"ExitCode": 0
},
{
"Status": "successful",
"CompletedAt": "2013-10-25T19:31:08+00:00",
"InstanceId": "67bf0da2-29ed-4217-990c-d895d51812b9",
"AcknowledgedAt": "2013-10-25T19:29:01+00:00",
"LogUrl": "https://s3.amazonaws.com/prod_stage-log/logs/2a90e862-f974-42a6-9342-9a4f03468358?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE
&Expires=1382731518&Signature=cxKYHO8mCCd4MvOyFb6ywebeQtA%3D&response-cache-control=private&response-content-encoding=gzip&response-content-
type=text%2Fplain",
"Type": "setup",
"CommandId": "2a90e862-f974-42a6-9342-9a4f03468358",
"CreatedAt": "2013-10-25T19:26:01+00:00",
"ExitCode": 0
}
]
}
```
1. Copiez la valeur `LogUrl` dans votre navigateur pour afficher le journal.
Si l'instance a plus de quelques commandes, vous pouvez ajouter des paramètres à `describe-commands` pour filtrer les commandes à inclure dans l'objet de réponse. Pour plus d'informations, consultez [describe-commands](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html).
## Affichage d'un journal de Chef sur une instance
**Note**
Les rubriques de cette section s'appliquent à Chef 12. Pour plus d'informations sur l'emplacement des journaux de Chef pour Chef 11.10 et les versions antérieures, consultez [Résolution des problèmes de Chef 11.10 et des versions antérieures pour Linux](https://docs.aws.amazon.com/opsworks/latest/userguide/troubleshooting-chef-11-linux.html).
### Instances Linux
OpsWorks Stacks stocke les journaux Chef de chaque instance dans son `/var/chef/runs` répertoire. Pour les instances Linux, ce répertoire inclut également les [conteneurs de données](data-bags.md) associés, stockés sous forme de fichiers au format JSON. Vous avez besoin de [privilèges sudo](opsworks-security-users.md) pour accéder à ce répertoire. Le journal de chaque exécution se trouve dans un fichier nommé `chef.log` dans le sous-répertoire de l'exécution concernée.
OpsWorks Stacks stocke ses journaux internes dans le `/var/log/aws/opsworks` dossier de l'instance. Les informations sont rarement utiles pour le dépannage. Cependant, ces journaux sont utiles au support de OpsWorks Stacks, et il se peut que l'on vous demande de les fournir si vous rencontrez un problème avec le service. Les journaux Linux peuvent également fournir des données de dépannage utiles dans certains cas.
### instances Windows
**Journaux de l'agent**
Sur les instances Windows, les OpsWorks journaux sont stockés dans un `ProgramData` chemin tel que le suivant. Le nombre inclut un horodatage.
```
C:\ProgramData\OpsWorksAgent\var\logs\number
```
**Note**
Par défaut, `ProgramData` est un dossier masqué. Pour l'afficher, accédez à **Folder Options (Options du dossier)**. Sous **Afficher**, sélectionnez l'option d'affichage des fichiers masqués.
L'exemple suivant montre les journaux de l'agent sur une instance Windows.
```
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 5/24/2015 11:59 PM 127277 command.20150524.txt
-a--- 5/25/2015 11:59 PM 546772 command.20150525.txt
-a--- 5/26/2015 11:59 PM 551514 command.20150526.txt
-a--- 5/27/2015 9:43 PM 495181 command.20150527.txt
-a--- 5/24/2015 11:59 PM 24353 keepalive.20150524.txt
-a--- 5/25/2015 11:59 PM 106232 keepalive.20150525.txt
-a--- 5/26/2015 11:59 PM 106208 keepalive.20150526.txt
-a--- 5/27/2015 8:54 PM 92593 keepalive.20150527.txt
-a--- 5/24/2015 7:19 PM 3891 service.20150524.txt
-a--- 5/27/2015 8:54 PM 1493 service.20150527.txt
-a--- 5/24/2015 11:59 PM 112549 wire.20150524.txt
-a--- 5/25/2015 11:59 PM 501501 wire.20150525.txt
-a--- 5/26/2015 11:59 PM 499640 wire.20150526.txt
-a--- 5/27/2015 8:54 PM 436870 wire.20150527.txt
```
**Journaux de Chef**
Pour les instances Windows, les journaux de Chef sont stockés dans un chemin `ProgramData` comme suit. Le nombre inclut un horodatage.
```
C:\ProgramData\OpsWorksAgent\var\commands\number
```
**Note**
Ce répertoire contient uniquement la sortie de la première exécution (OpsWorks possédée) de Chef.
L'exemple suivant montre les journaux Chef OpsWorks détenus sur une instance Windows.
```
Mode LastWriteTime Name
---- ------------- ----
d---- 5/24/2015 7:23 PM configure-7ecb5f47-7626-439b-877f-5e7cb40ab8be
d---- 5/26/2015 8:30 PM configure-8e74223b-d15d-4372-aeea-a87b428ffc2b
d---- 5/24/2015 6:34 PM configure-c3980a1c-3d08-46eb-9bae-63514cee194b
d---- 5/26/2015 8:32 PM grant_remote_access-70dbf834-1bfa-4fce-b195-e50e85402f4c
d---- 5/26/2015 10:30 PM revoke_remote_access-1111fce9-843a-4b27-b93f-ecc7c5e9e05b
d---- 5/24/2015 7:21 PM setup-754ec063-8b60-4cd4-b6d7-0e89d7b7aa78
d---- 5/26/2015 8:27 PM setup-af5bed36-5afd-4115-af35-5766f88bc039
d---- 5/24/2015 6:32 PM setup-d8abeffa-24d4-414b-bfb1-4ad07319f358
d---- 5/24/2015 7:13 PM shutdown-c7130435-9b5c-4a95-be17-6b988fc6cf9a
d---- 5/26/2015 8:25 PM sync_remote_users-64c79bdc-1f6f-4517-865b-23d2def4180c
d---- 5/26/2015 8:48 PM update_custom_cookbooks-2cc59a94-315b-414d-85eb-2bdea6d76c6a
```
**Journaux Chef utilisateur**
Les journaux de vos exécutions de Chef sont disponibles dans les fichiers nommés `logfile.txt` dans un dossier nommé conformément à la commande Chef numérotée, comme illustré ci-après.
C : /chef `runs` `command-12345` `attribs.json` `client.rb` `logfile.txt`
## Interprétation d'un journal Chef
Le début du journal contient principalement la journalisation interne de Chef.
```
# Logfile created on Thu Oct 17 17:25:12 +0000 2013 by logger.rb/1.2.6
[2013-10-17T17:25:12+00:00] INFO: *** Chef 11.4.4 ***
[2013-10-17T17:25:13+00:00] DEBUG: Building node object for php-app1.localdomain
[2013-10-17T17:25:13+00:00] DEBUG: Extracting run list from JSON attributes provided on command line
[2013-10-17T17:25:13+00:00] INFO: Setting the run_list to ["opsworks_custom_cookbooks::load", "opsworks_custom_cookbooks::execute"] from JSON
[2013-10-17T17:25:13+00:00] DEBUG: Applying attributes from json file
[2013-10-17T17:25:13+00:00] DEBUG: Platform is amazon version 2013.03
[2013-10-17T17:25:13+00:00] INFO: Run List is [recipe[opsworks_custom_cookbooks::load], recipe[opsworks_custom_cookbooks::execute]]
[2013-10-17T17:25:13+00:00] INFO: Run List expands to [opsworks_custom_cookbooks::load, opsworks_custom_cookbooks::execute]
[2013-10-17T17:25:13+00:00] INFO: Starting Chef Run for php-app1.localdomain
[2013-10-17T17:25:13+00:00] INFO: Running start handlers
[2013-10-17T17:25:13+00:00] INFO: Start handlers complete.
[2013-10-17T17:25:13+00:00] DEBUG: No chefignore file found at /opt/aws/opsworks/releases/20131015111601_209/cookbooks/chefignore no files will be ignored
[2013-10-17T17:25:13+00:00] DEBUG: Cookbooks to compile: ["gem_support", "packages", "opsworks_bundler", "opsworks_rubygems", "ruby", "ruby_enterprise", "dependencies", "opsworks_commons", "scm_helper", :opsworks_custom_cookbooks]
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook gem_support's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/gem_support/libraries/current_gem_version.rb
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook packages's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/packages/libraries/packages.rb
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook dependencies's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/dependencies/libraries/current_gem_version.rb
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook opsworks_commons's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/opsworks_commons/libraries/activesupport_blank.rb
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook opsworks_commons's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/opsworks_commons/libraries/monkey_patch_chefgem_resource.rb
...
```
Cette partie du fichier est utile essentiellement pour les experts de Chef. Notez que la liste d'exécution inclut uniquement deux recettes, même si la plupart des commandes en impliquent bien plus. Ces deux recettes gèrent la tâche de chargement et d'exécution de toutes les autres recettes intégrées et personnalisées.
La partie la plus intéressante du fichier est généralement à la fin. Si une exécution se termine avec succès, vous devriez voir quelque chose de similaire à ce qui suit :
```
...
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: STDERR:
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: ---- End output of /sbin/service mysqld restart ----
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: Ran /sbin/service mysqld restart returned 0
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: service[mysql]: restarted successfully
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: Chef Run complete in 84.07096 seconds
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: cleaning the checksum cache
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--tmp-chef-rendered-template20130611-4899-8wef7e-0
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--tmp-chef-rendered-template20130611-4899-1xpwyb6-0
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--etc-monit-conf
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: Running report handlers
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: Report handlers complete
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: Exiting
```
**Note**
Vous pouvez utiliser l'interface de ligne de commande de l'agent pour afficher la queue du journal pendant ou après l'exécution. Pour de plus amples informations, veuillez consulter [Affichage des journaux de Chef](troubleshoot-debug-cli.md#troubleshoot-debug-cli-log).
En cas d'échec d'une recette, vous devez rechercher une sortie de niveau ERROR, qui contient une exception suivie d'une trace de la pile de Chef, comme indiqué ci-après :
```
...
Please report any problems with the /usr/scripts/mysqlbug script!
[ OK ]
MySQL Daemon failed to start.
Starting mysqld: [FAILED]STDERR: 130611 15:07:55 [Warning] The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead.
130611 15:07:56 [Warning] The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead.
---- End output of /sbin/service mysqld start ----
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/mixin/command.rb:184:in `handle_command_failures'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/mixin/command.rb:131:in `run_command'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/provider/service/init.rb:37:in `start_service'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/provider/service.rb:60:in `action_start'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource.rb:406:in `send'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource.rb:406:in `run_action'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:53:in `run_action'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `converge'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `each'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `converge'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection.rb:94:in `execute_each_resource'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection.rb:92:in `execute_each_resource'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:84:in `converge'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/client.rb:268:in `converge'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/client.rb:158:in `run'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:190:in `run_application'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:181:in `loop'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:181:in `run_application'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application.rb:62:in `run'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/chef-solo:25
/opt/aws/opsworks/current/bin/chef-solo:16:in `load'
/opt/aws/opsworks/current/bin/chef-solo:16
```
La fin du fichier est la trace de la pile de Chef. Vous devez également examiner la sortie juste avant l'exception, car elle contient souvent une erreur système comme `package not available` qui peut également être utile pour déterminer la cause de l'échec. Dans ce cas, le daemon MySQL n'a pas pu démarrer.
## Erreurs courantes dans le journal de Chef
Voici quelques erreurs courantes qui apparaissent dans le journal de Chef et comment les traiter.
Impossible de trouver le journal
Au début d'une exécution de Chef, les instances reçoivent une URL Amazon S3 présignée qui vous permet de consulter le journal sur une page Web lorsque l'exécution de Chef est terminée. Comme cette URL expire au bout de deux heures, aucun journal n'est chargé sur le site Amazon S3 si une exécution de Chef prend plus de deux heures, même si aucun problème n'est survenu pendant l'exécution de Chef. La commande de création d'un journal a réussi, mais le journal peut être vu uniquement sur l'instance, pas au niveau de l'URL présignée.
Fin brutale du journal
Si un journal de Chef se termine brutalement sans indiquer la réussite ni afficher des informations d'erreur, vous avez probablement rencontré un état de faible mémoire qui a empêché Chef de remplir le journal. La meilleure solution consiste à essayer de nouveau avec une plus grande instance.
Livre de recettes ou recette manquant
Si l'exécution de Chef doit gérer un livre de recettes ou une recette qui ne sont pas dans le cache du livre de recettes, vous verrez quelque chose de similaire à ce qui suit :
```
DEBUG: Loading Recipe mycookbook::myrecipe via include_recipe
ERROR: Caught exception during execution of custom recipe: mycookbook::myrecipe:
Cannot find a cookbook named mycookbook; did you forget to add metadata to a cookbook?
```
Cette entrée indique que le livre de recettes `mycookbook` n'est pas dans le cache de livre de recettes. Avec Chef 11.4, vous pouvez également rencontrer cette erreur si vous ne déclarez pas les dépendances correctement dans `metadata.rb`.
OpsWorks Stacks exécute des recettes à partir du cache du livre de recettes de l'instance. Il télécharge les livres de recettes du référentiel vers le cache lorsque l'instance démarre. Cependant, OpsWorks Stacks ne met pas automatiquement à jour le cache d'une instance en ligne si vous modifiez ultérieurement les livres de recettes de votre référentiel. Si vous avez modifié vos livres de recettes ou si vous en avez ajouté de nouveaux depuis le début de l'instance, procédez comme suit :
1. Assurez-vous que vous avez validé vos modifications dans le référentiel.
1. Exécutez la commande de pile [Update Cookbooks (Mettre à jour les livres de recettes)](workingstacks-commands.md) pour mettre à jour le cache du livre de recettes avec la version la plus récente du référentiel.
Échec de la commande locale
Si une ressource `execute` de Chef ne parvient pas à exécuter la commande spécifiée, vous verrez quelque chose de similaire à ce qui suit :
```
DEBUG: ---- End output of ./configure --with-config-file-path=/ returned 2
ERROR: execute[PHP: ./configure] (/root/opsworks-agent/site-cookbooks/php-fpm/recipes/install.rb line 48) had an error:
./configure --with-config-file-path=/
```
Faites défiler le journal vers le haut et vous devriez voir la sortie `stderr` et `stdout` de la commande, ce qui vous aidera à déterminer pourquoi la commande a échoué.
Échec du package
En cas d'échec d'une installation de package, vous verrez quelque chose de similaire à ce qui suit :
```
ERROR: package[zend-server-ce-php-5.3] (/root/opsworks-agent/site-cookbooks/zend_server/recipes/install.rb line 20)
had an error: apt-get -q -y --force-yes install zend-server-ce-php-5.3=5.0.4+b17 returned 100, expected 0
```
Faites défiler le journal vers le haut et vous devriez voir la sortie STDOUT et STDERROR de la commande, ce qui vous aidera à déterminer pourquoi l'installation du package a échoué.
# Utilisation de la CLI OpsWorks de l'agent Stacks
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
**Note**
L'interface de ligne de commande de l'agent est disponible uniquement sur les instances Linux.
Sur chaque instance en ligne, OpsWorks Stacks installe un agent qui communique avec le service. Le service OpsWorks Stacks envoie à son tour des commandes à l'agent pour effectuer des tâches telles que le lancement des exécutions de Chef sur l'instance lorsqu'un événement du cycle de vie se produit. Sur les instances Linux, l'agent expose une interface de ligne de commande (CLI) qui est très utile pour le dépannage. Pour exécuter les commandes de l'interface de ligne de commande de l'agent, utilisez [SSH pour vous connecter à une instance](workinginstances-ssh.md). Vous pouvez ensuite exécuter les commandes de l'interface de ligne de commande de l'agent pour effectuer diverses tâches, y compris les suivantes :
+ Exécuter les recettes.
+ Afficher les journaux de Chef.
+ Afficher [le JSON de la configuration et du déploiement de la pile](workingcookbook-json.md).
Pour plus d'informations sur la configuration d'une connexion SSH à une instance, consultez [Connexion avec SSH](workinginstances-ssh.md). Vous devez également disposer d'[autorisations SSH et sudo](opsworks-security-users.md) pour la pile.
Cette section décrit comment utiliser l'interface de ligne de commande de l'agent pour le dépannage. Pour plus d'informations et une référence complète sur les commandes, consultez [OpsWorks CLI de l'agent Stacks](agent.md).
**Topics**
+ [Exécution des recettes](#troubleshoot-debug-cli-recipes)
+ [Affichage des journaux de Chef](#troubleshoot-debug-cli-log)
+ [Affichage du JSON de configuration et de déploiement de la pile](#troubleshoot-debug-cli-json)
## Exécution des recettes
La commande [`run_command`](agent-run.md) de l'interface de ligne de commande de l'agent demande à l'agent d'exécuter à nouveau une commande qu'il a déjà effectuée. Les commandes les plus utiles pour le dépannage, `setup`, `configure`, `deploy` et `undeploy`, correspondent chacune à un événement du cycle de vie. Elles demandent à l'agent de lancer une exécution de Chef afin d'exécuter les recettes associées.
**Note**
La commande `run_command` est limitée à l'exécution du groupe de recettes qui est associé à une commande spécifique, généralement les recettes qui sont associées à un événement du cycle de vie. Vous ne pouvez pas l'utiliser pour exécuter une recette particulière. Pour exécuter une ou plusieurs recettes spécifiées, utilisez la [commande de pile Execute Recipes](workingstacks-commands.md) ou les actions équivalentes de l'API ou de l'interface de ligne de commande ([https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html) et [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateDeployment.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateDeployment.html)).
La commande `run_command` est très utile pour le débogage des recettes personnalisées, en particulier les recettes qui sont affectées aux événements du cycle de vie Setup et Configure, que vous ne pouvez pas déclencher directement à partir de la console. En utilisant `run_command`, vous pouvez exécuter les recettes d'un événement particulier aussi souvent que nécessaire sans avoir à démarrer ou interrompre les instances.
**Note**
OpsWorks Stacks exécute les recettes à partir du cache du livre de recettes de l'instance, et non du référentiel de livres de recettes. OpsWorks Stacks télécharge les livres de recettes dans ce cache au démarrage de l'instance, mais ne met pas automatiquement à jour le cache sur les instances en ligne si vous modifiez ultérieurement vos livres de recettes. Si vous avez modifié vos livres de recettes depuis le début de l'instance, assurez-vous d'exécuter la [commande de pile Update Cookbooks (Mettre à jour les livres de recettes)](workingstacks-commands.md) pour mettre à jour le cache des livres de recettes avec la version la plus récente du référentiel.
L'agent met en cache uniquement les commandes les plus récentes. Vous pouvez les lister en exécutant [`list_commands`](agent-list.md), qui retourne une liste des commandes mises en cache et du moment où elles ont été effectuées.
```
sudo opsworks-agent-cli list_commands
2013-02-26T19:08:26 setup
2013-02-26T19:12:01 configure
2013-02-26T19:12:05 configure
2013-02-26T19:22:12 deploy
```
Pour exécuter à nouveau la commande la plus récente, exécutez ceci :
```
sudo opsworks-agent-cli run_command
```
Pour exécuter à nouveau l'instance la plus récente d'une commande spécifiée, exécutez ceci :
```
sudo opsworks-agent-cli run_command command
```
Par exemple, pour exécuter à nouveau les recettes Setup, vous pouvez exécuter la commande suivante :
```
sudo opsworks-agent-cli run_command setup
```
Chaque commande a un [JSON de configuration et de déploiement de la pile associé](workingcookbook-json.md), qui représente l'état de la pile et du déploiement au moment de l'exécution de la commande. Etant donné que ces données peuvent changer d'une commande à l'autre, une instance plus ancienne d'une commande peut utiliser des données légèrement différentes des plus récentes. Pour exécuter à nouveau une instance particulière d'une commande, copiez le temps de la sortie `list_commands` et exécutez les éléments suivants :
```
sudo opsworks-agent-cli run_command time
```
Les exemples précédents exécutent tous à nouveau la commande à l'aide du JSON par défaut, c'est-à-dire le JSON qui a été installé pour cette commande. Vous pouvez exécuter à nouveau une commande sur un fichier JSON arbitraire comme suit :
```
sudo opsworks-agent-cli run_command -f /path/to/valid/json.file
```
## Affichage des journaux de Chef
La commande [`show_log`](agent-show.md) de l'interface de ligne de commande de l'agent affiche un journal spécifié. Une fois la commande terminée, observez la fin du fichier. La commande `show_log` fournit donc un moyen pratique de consulter la queue du journal, où se trouvent généralement les informations relatives aux erreurs. Vous pouvez faire défiler vers le haut pour afficher les premières parties du journal.
Pour afficher le journal de la commande en cours, exécutez ceci :
```
sudo opsworks-agent-cli show_log
```
Vous pouvez également afficher les journaux d'une commande donnée, mais sachez que l'agent met en cache les journaux des trente dernières commandes seulement. Vous pouvez afficher les commandes d'une instance en exécutant [`list_commands`](agent-list.md), qui retourne une liste des commandes mises en cache et l'heure où elles ont été effectuées. Pour obtenir un exemple, consultez [Exécution des recettes](#troubleshoot-debug-cli-recipes).
Pour afficher le journal de la dernière exécution d'une commande spécifique, exécutez ce qui suit :
```
sudo opsworks-agent-cli show_log command
```
Le paramètre de la commande peut être défini sur `setup`, `configure`, `deploy`, `undeploy`, `start`, `stop` ou `restart`. La plupart de ces commandes correspondent aux événements de cycle de vie et demandent à l'agent d'exécuter les recettes associées.
Pour afficher le journal pour une exécution de commande particulière, copiez la date de la sortie `list_commands` et exécutez :
```
sudo opsworks-agent-cli show_log date
```
Si une commande est toujours en cours d'exécution, `show_log` affiche l'état actuel du journal.
**Note**
Pour résoudre les erreurs et `show_log` les problèmes, vous out-of-memory pouvez notamment suivre un journal pendant l'exécution, comme suit :
Utilisez `run_command` pour déclencher l'événement du cycle de vie approprié. Pour de plus amples informations, veuillez consulter [Exécution des recettes](#troubleshoot-debug-cli-recipes).
Exécutez plusieurs fois `show_log` pour voir la queue du journal tel qu'il est écrit.
Si Chef manque de mémoire ou se ferme de façon impromptue, le journal se termine brutalement. Si une recette échoue, le journal se terminera par une exception et une trace de la pile.
## Affichage du JSON de configuration et de déploiement de la pile
La plupart des données utilisées par les recettes proviennent du [JSON de configuration et de déploiement de la pile](workingcookbook-json.md), qui définit un ensemble d'attributs de Chef fournissant une description détaillée de la configuration de la pile, des déploiements et des attributs personnalisés en option que les utilisateurs peuvent ajouter. Pour chaque commande, OpsWorks Stacks installe un JSON qui représente la pile et l'état du déploiement au moment de la commande. Pour de plus amples informations, veuillez consulter [Attributs de déploiement et de configuration de pile](workingcookbook-json.md).
Si vos recettes personnalisées obtiennent du JSON de configuration et de déploiement de la pile, vous pouvez vérifier les données en examinant le JSON. Le plus simple pour afficher le JSON de configuration et de déploiement de la pile consiste à exécuter la commande [`get_json`](agent-json.md) de l'interface de ligne de commande de l'agent, qui affiche une version formatée de l'objet JSON. Voici les premières lignes de certaines sorties types :
```
{
"opsworks": {
"layers": {
"php-app": {
"id": "4a2a56c8-f909-4b39-81f8-556536d20648",
"instances": {
"php-app2": {
"elastic_ip": null,
"region": "us-west-2",
"booted_at": "2013-02-26T20:41:10+00:00",
"ip": "10.112.235.192",
"aws_instance_id": "i-34037f06",
"availability_zone": "us-west-2a",
"instance_type": "c1.medium",
"private_dns_name": "ip-10-252-0-203.us-west-2.compute.internal",
"private_ip": "10.252.0.203",
"created_at": "2013-02-26T20:39:39+00:00",
"status": "online",
"backends": 8,
"public_dns_name": "ec2-10-112-235-192.us-west-2.compute.amazonaws.com"
...
```
Vous pouvez afficher le JSON de configuration et de déploiement de la pile le plus récent comme suit :
```
sudo opsworks-agent-cli get_json
```
Vous pouvez afficher le JSON de configuration et de déploiement de la pile le plus récent pour une commande spécifiée en exécutant ce qui suit :
```
sudo opsworks-agent-cli get_json command
```
Le paramètre de la commande peut être défini sur `setup`, `configure`, `deploy`, `undeploy`, `start`, `stop` ou `restart`. La plupart de ces commandes correspondent aux événements de cycle de vie et demandent à l'agent d'exécuter les recettes associées.
Vous pouvez afficher le JSON de configuration et de déploiement de la pile pour une exécution de commande spécifique en spécifiant la date de la commande comme suit :
```
sudo opsworks-agent-cli get_json date
```
La façon la plus simple d'utiliser cette commande est la suivante :
1. Exécutez `list_commands`, qui retourne une liste des commandes ayant été exécutées sur l'instance et la date à laquelle chaque commande a été exécutée.
1. Copiez la date de la commande appropriée et utilisez-la comme `get_json` *date* argument.
# Débogage et dépannage des problèmes courants
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Cette section décrit certains problèmes de débogage et de dépannage couramment rencontrés et de leurs solutions.
**Topics**
+ [Résolution des problèmes liés aux OpsWorks piles](common-issues-troubleshoot.md)
+ [Dépannage de l'enregistrement des instances](#common-issues-instance-registration)
# Résolution des problèmes liés aux OpsWorks piles
**Important**
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.
Cette section présente certains problèmes courants liés à OpsWorks Stacks et leurs solutions.
**Topics**
+ [Impossible de gérer des instances](#w2ab1c14c77c17b9b9)
+ [Après une exécution Chef, les instances ne démarrent pas](#w2ab1c14c77c17b9c11)
+ [Les instances d'une couche échouent toutes à un test de santé d'Elastic Load Balancing](#common-issues-troubleshoot-health)
+ [Impossible de communiquer avec un Elastic Load Balancing Load Balancer](#w2ab1c14c77c17b9c15)
+ [Une instance locale importée n'a pas réussi à finaliser la configuration du volume après un redémarrage](#w2ab1c14c77c17b9c17)
+ [Un volume EBS ne se rattache pas après un redémarrage](#common-issues-troubleshoot-ebs)
+ [Impossible de supprimer les groupes de sécurité OpsWorks Stacks](#common-issues-troubleshoot-booting-secgroup)
+ [Suppression accidentelle d'un OpsWorks groupe de sécurité Stacks](#common-issues-troubleshoot-booting-secgroup-delete)
+ [Le journal Chef se termine brutalement](#common-issues-troubleshoot-log-terminates)
+ [Le livre de recettes n'est pas mis à jour](#common-issues-troubleshoot-update)
+ [Les instances sont bloquées à l'état de démarrage](#common-issues-troubleshoot-booting)
+ [Redémarrage inattendu des instances](#common-issues-troubleshoot-restart)
+ [`opsworks-agent` Processus en cours d'exécution sur les instances](#common-issues-troubleshoot-agent)
+ [Commandes execute\$1recipes inattendue](#common-issues-troubleshoot-unexpected)
## Impossible de gérer des instances
**Problème :** Vous ne pouvez plus gérer une instance que vous pouviez gérer auparavant. Dans certains cas, les journaux peuvent afficher une erreur semblable à celle-ci :
```
Aws::CharlieInstanceService::Errors::UnrecognizedClientException - The security token included in the request is invalid.
```
**Cause :** Cela peut se produire si une ressource en dehors d' OpsWorks sur laquelle dépend l'instance a été modifiée ou supprimée. Voici des exemples de modifications de ressource qui peuvent interrompre les communications avec une instance.
+ Un utilisateur ou un rôle IAM associé à l'instance a été supprimé accidentellement, en dehors de OpsWorks Stacks. Cela entraîne un échec de communication entre l' OpsWorks agent installé sur l'instance et le service OpsWorks Stacks. L'utilisateur qui est associé à une instance est requis tout au long de la durée de vie de l'instance.
+ La modification de configurations de volume ou de stockage pendant qu'une instance est hors ligne peut rendre une instance ingérable.
+ Ajout manuel d' EC2 instances à un ELB. OpsWorks reconfigure un équilibreur de charge Elastic Load Balancing attribué chaque fois qu'une instance entre ou quitte l'état en ligne. OpsWorks considère uniquement les instances dont il sait qu'elles sont des membres valides ; les instances ajoutées en dehors de OpsWorks ou par un autre processus sont supprimées. Toute instance est supprimée.
**Solution :** ne supprimez pas les utilisateurs ou les rôles IAM dont dépendent vos instances. Si possible, modifiez des configurations de volume ou de stockage uniquement tant que les instances dépendantes s'exécutent. OpsWorks À utiliser pour gérer l'équilibreur de charge ou les adhésions EIP des instances. OpsWorks Lorsque vous enregistrez une instance, pour éviter les problèmes liés à la gestion des instances enregistrées en cas de suppression accidentelle de l'utilisateur, ajoutez le `--use-instance-profile` paramètre à votre `register` commande pour utiliser le profil d'instance intégré de l'instance à la place.
## Après une exécution Chef, les instances ne démarrent pas
**Problème :** sur les piles Chef 11.10 ou antérieures qui sont configurées pour utiliser les livres de recettes personnalisés, après qu'une exécution Chef a utilisée les livres de recettes de la Communauté, les instances ne démarrent pas. Les messages des journaux peuvent établir que les recettes n'ont pas pu être compilées (« Erreur de compilation de recette ») ou n'ont pas pu être chargées, car elles ne peuvent pas trouver une dépendance.
**Cause :** la cause la plus probable est que le livre de recettes personnalisé ou le livre de recettes de la communauté ne prend pas en charge la version Chef qu'utilise votre pile. Certains livres populaires de la communauté, tels que `[apt](https://supermarket.chef.io/cookbooks/apt)` et `[build-essential](https://supermarket.chef.io/cookbooks/build-essential/versions/3.2.0)`, ont connu des problèmes de compatibilité avec Chef 11.10.
**Solution :** Sur les OpsWorks piles dont le paramètre **Utiliser les livres de recettes Chef personnalisés est activé, les livres** de recettes personnalisés ou communautaires doivent toujours prendre en charge la version de Chef utilisée par votre pile. Epinglez les livres de recettes de la communauté avec une version (à savoir, définissez le numéro de version du livre de recettes sur une version spécifique) qui est compatible avec la version Chef configurée dans les paramètres de votre pile. Pour trouver une version du livre de recettes de la communauté prise en charge, affichez le journal des modifications d'un livre des recettes dont la compilation a échoué et utilisez uniquement la version la plus récente du livre de recettes que votre pile prendra en charge. Pour épingler une version du livre de recettes, spécifiez un numéro de version exacte dans le fichier Berksfile du référentiel de votre livre de recettes personnalisé. Par exemple, `cookbook 'build-essential', '= 3.2.0'`.
## Les instances d'une couche échouent toutes à un test de santé d'Elastic Load Balancing
**Problème :** vous attachez un équilibreur de charge Elastic Load Balancing à une couche de serveur d'applications, mais le bilan de santé de toutes les instances échoue.
**Cause :** Lorsque vous créez un équilibreur de charge Elastic Load Balancing, vous devez spécifier le chemin ping que l'équilibreur de charge appelle pour déterminer si l'instance est saine. Assurez-vous de spécifier un chemin d'accès ping approprié pour votre application ; la valeur par défaut est/index.html. Si votre application n'inclut pas un `index.html`, vous devez spécifier un chemin d'accès approprié ou la vérification du statut échoue. Par exemple, l'PHPApp application Simple utilisée dans [Mise en route des piles Linux Chef 11](gettingstarted.md) n'utilise pas index.html ; le chemin ping approprié pour ces serveurs est /.
**Solution :** Modifiez le chemin d'accès ping de l'équilibreur de charge. Pour plus d'informations, consultez [Elastic Load Balancing](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/gs-ec2classic.html).
## Impossible de communiquer avec un Elastic Load Balancing Load Balancer
**Problème :** vous créez un équilibreur de charge Elastic Load Balancing et vous l'associez à une couche de serveur d'applications, mais lorsque vous cliquez sur le nom DNS ou l'adresse IP de l'équilibreur de charge pour exécuter l'application, le message d'erreur suivant s'affiche : « Le serveur distant ne répond pas ».
**Cause :** Si votre stack s'exécute dans un VPC par défaut, lorsque vous créez un équilibreur de charge Elastic Load Balancing dans la région, vous devez spécifier un groupe de sécurité. Le groupe de sécurité doit avoir les règles de trafic entrant qui autorisent le trafic entrant à partir de votre adresse IP. Si vous spécifiez **default VPC security group (groupe de sécurité VPC par défau)**, la règle de trafic entrant par défaut n'accepte aucun trafic entrant.
**Solution :** Modifiez les règles de trafic entrant du groupe de sécurité pour accepter le trafic entrant à partir des adresses IP appropriées.
1. Cliquez sur **Security Groups** dans le volet [de navigation de la EC2 console Amazon](https://console.aws.amazon.com/ec2/).
1. Sélectionnez le groupe de sécurité de l'équilibreur de charge.
1. Cliquez sur **Modifier** sous l'onglet **Entrant**.
1. Ajoutez une règle de trafic entrant avec le champ **Source** défini avec un CIDR approprié.
Par exemple, la spécification **Anywhere** définit le CIDR avec la valeur 0.0.0.0/0, qui demande à l'équilibreur de charge d'accepter le trafic entrant à partir de n'importe quelle adresse IP.
## Une instance locale importée n'a pas réussi à finaliser la configuration du volume après un redémarrage
**Problème :** vous redémarrez une EC2 instance que vous avez importée dans OpsWorks Stacks, et la console OpsWorks Stacks affiche le statut de l'instance « **échec** ». Cela peut se produire sur les instances Chef 11 ou Chef 12.
**Cause : **OpsWorks Stacks ne parvient pas à attacher un volume à votre instance pendant le processus d'installation. Une cause possible est qu' OpsWorks Stacks remplace votre configuration de volume sur votre instance lorsque vous exécutez la commande `setup`.
**Solution :** ouvrez la page **Détails** de l'instance et vérifiez votre configuration de volume dans la zone **Volumes**. Notez que vous pouvez changer la configuration de votre volume uniquement lorsque votre instance se trouve dans l'état **stopped (arrêté)**. N'oubliez pas que chaque volume a un nom et un point de montage spécifiés. Vérifiez que vous avez fourni le bon point de montage dans votre configuration dans OpsWorks Stacks avant de redémarrer l'instance.
## Un volume EBS ne se rattache pas après un redémarrage
**Problème :** vous utilisez la EC2 console Amazon pour associer un volume Amazon EBS à une instance, mais lorsque vous redémarrez l'instance, le volume n'est plus attaché.
**Cause :** OpsWorks Stacks ne peut rattacher que les volumes Amazon EBS dont il a connaissance, qui sont limités aux volumes suivants :
+ Volumes créés par OpsWorks Stacks.
+ Volumes de votre compte que vous avez explicitement enregistrés auprès d'une pile à l'aide de la page **Ressources**.
**Solution :** Gérez vos volumes Amazon EBS uniquement à l'aide de la console, de l'API ou de la CLI OpsWorks Stacks. Si vous souhaitez utiliser l'un des volumes Amazon EBS de votre compte avec une pile, utilisez la page **Ressources** de la pile pour enregistrer le volume et l'associer à une instance. Pour de plus amples informations, veuillez consulter [Gestion des ressources](resources.md).
## Impossible de supprimer les groupes de sécurité OpsWorks Stacks
**Problème :** une fois que vous avez supprimé une pile, il reste un certain nombre de groupes de sécurité OpsWorks Stacks qui ne peuvent pas être supprimés.
**Cause :** Les groupes de sécurité doivent être supprimés selon un ordre particulier.
**Solution :** Tout d'abord, assurez-vous qu'aucune instance n'utilise les groupes de sécurité. Puis, supprimez l'un des groupes de sécurité ci-après, s'ils existent, dans l'ordre suivant :
1. AWS- OpsWorks -Blank-Server
1. AWS- OpsWorks -Monitoring-Master-Server
1. Serveur AWS- OpsWorks -DB-Master-Server
1. Serveur AWS- OpsWorks -Memcached-Server
1. AWS- OpsWorks -Serveur personnalisé
1. Serveur d'applications AWS- OpsWorks -NodeJS
1. Serveur d'applications AWS- OpsWorks -PHP
1. Serveur d'applications AWS- OpsWorks -Rails
1. AWS- OpsWorks -Serveur Web
1. AWS- OpsWorks -Serveur par défaut
1. Serveur AWS- OpsWorks -LB
## Suppression accidentelle d'un OpsWorks groupe de sécurité Stacks
**Problème :** vous avez supprimé l'un des groupes de sécurité OpsWorks Stacks et vous devez le recréer.
**Cause :** Ces groupes de sécurité sont généralement supprimés par accident.
**Solution :** Le groupe recréé doit être une copie exacte de l'original, y compris la même casse pour le nom du groupe. Au lieu de recréer le groupe manuellement, l'approche par défaut consiste à ce qu' OpsWorks Stacks exécute la tâche automatiquement. Créez simplement une nouvelle pile dans la même région AWS (et un VPC, le cas échéant OpsWorks ). Stacks recréera automatiquement tous les groupes de sécurité intégrés, y compris celui que vous avez supprimé. Vous pouvez ensuite supprimer la pile si vous n'en avez plus l'utilisation ; les groupes de sécurité demeureront.
## Le journal Chef se termine brutalement
**Problème :** Un journal Chef se termine brutalement ; la fin du journal n'indique pas une exécution réussie ni n'affiche une exception et une trace de pile.
**Cause :** Ce comportement est généralement dû à une mémoire insuffisante.
**Solution :** Créez une plus grande instance et utilisez la commande `run_command` de l'interface de ligne de commande de l'agent pour exécuter les recettes à nouveau. Pour de plus amples informations, veuillez consulter [Exécution des recettes](troubleshoot-debug-cli.md#troubleshoot-debug-cli-recipes).
## Le livre de recettes n'est pas mis à jour
**Problème :** Vous avez mis à jour vos livres de recettes, mais les instances de la pile exécutent toujours les anciennes recettes.
**Cause :** OpsWorks Stacks met en cache les livres de recettes sur chaque instance et exécute les recettes à partir du cache, et non du référentiel. Lorsque vous démarrez une nouvelle instance, OpsWorks Stacks télécharge vos livres de recettes du référentiel vers le cache de l'instance. Cependant, si vous modifiez par la suite vos livres de recettes personnalisés, OpsWorks Stacks ne met pas automatiquement à jour les caches des instances en ligne.
**Solution :** exécutez la [commande Update Cookbooks stack](workingstacks-commands.md) pour demander explicitement à OpsWorks Stacks de mettre à jour les caches de livres de recettes de vos instances en ligne.
## Les instances sont bloquées à l'état de démarrage
**Problème :** lorsque vous redémarrez une instance ou que la réparation automatique la redémarre, l'opération de démarrage se bloque sur l'état `booting`.
**Cause :** une cause possible de ce problème est la configuration du VPC, VPC par défaut inclus. Les instances doivent toujours être en mesure de communiquer avec le service OpsWorks Stacks, Amazon S3, ainsi qu'avec les référentiels de packages, de livres de recettes et d'applications. Si, par exemple, vous supprimez une passerelle par défaut d'un VPC par défaut, les instances perdent leur connexion au service OpsWorks Stacks. Comme OpsWorks Stacks ne peut plus communiquer avec l'[agent](troubleshoot-debug-cli.md) d'instance, il considère l'instance comme défaillante et la [répare automatiquement.](workinginstances-autohealing.md) Cependant, sans connexion, OpsWorks Stacks ne peut pas installer d'agent d'instance sur l'instance réparée. Sans agent, OpsWorks Stacks ne peut pas exécuter les recettes de configuration sur l'instance, de sorte que l'opération de démarrage ne peut pas progresser au-delà de l'état de « démarrage ».
**Solution :** Modifiez la configuration de votre VPC afin que les instances aient la connectivité requise.
## Redémarrage inattendu des instances
**Problème :** une instance arrêtée redémarre de façon inattendue.
**Cause 1 :** si vous avez activé la [réparation automatique](workinginstances-autohealing.md) pour vos instances, OpsWorks Stacks vérifie régulièrement l'état des EC2 instances Amazon associées et redémarre celles qui ne fonctionnent pas correctement. Si vous arrêtez ou mettez fin à une instance OpsWorks gérée par Stacks à l'aide de la EC2 console, de l'API ou de la CLI Amazon, OpsWorks Stacks n'en est pas informé. Au lieu de cela, il considère l'instance arrêtée comme défectueuse et la redémarre automatiquement.
**Solution :** Gérez vos instances uniquement avec la console OpsWorks Stacks, l'API ou l'interface de ligne de commande. Si vous utilisez OpsWorks Stacks pour arrêter ou supprimer une instance, elle ne sera pas redémarrée. Pour plus d’informations, consultez [Démarrage, arrêt et redémarrage manuels des instances 24/7](workinginstances-starting.md) et [Supprimer des OpsWorks instances de Stacks](workinginstances-delete.md).
**Cause 2 :** Les instances peuvent échouer pour un grand nombre de raisons. Si la guérison automatique est activée, OpsWorks Stacks redémarre automatiquement les instances défaillantes.
**Solution :** Il s'agit d'un fonctionnement normal ; il n'est pas nécessaire de faire quoi que ce soit sauf si vous ne voulez pas que OpsWorks Stacks redémarre les instances défaillantes. Dans ce cas, vous devez désactiver la réparation automatique.
## `opsworks-agent` Processus en cours d'exécution sur les instances
**Problème :** Plusieurs processus `opsworks-agent` sont en cours d'exécution sur vos instances. Par exemple :
```
aws 24543 0.0 1.3 172360 53332 ? S Feb24 0:29 opsworks-agent: master 24543
aws 24545 0.1 2.0 208932 79224 ? S Feb24 22:02 opsworks-agent: keep_alive of master 24543
aws 24557 0.0 2.0 209012 79412 ? S Feb24 8:04 opsworks-agent: statistics of master 24543
aws 24559 0.0 2.2 216604 86992 ? S Feb24 4:14 opsworks-agent: process_command of master 24
```
**Cause :** il s'agit de processus légitimes qui sont obligatoires pour le fonctionnement normal de l'agent. Ils exécutent des tâches telles que la gestion des déploiements et l'envoi de messages de connexion persistante au service.
**Solution :** il s'agit du comportement normal. N'arrêtez pas ces processus, sinon vous compromettrez le fonctionnement de l'agent.
## Commandes execute\$1recipes inattendue
**Problème :** la section **Logs** de la page des détails d'une instance inclut des commandes `execute_recipes` inattendues. Des commandes `execute_recipes` inattendues peuvent également apparaître sur les pages **Stack** et **Deployments**.
**Cause :** ce problème est souvent provoqué par des modifications d'autorisation. Lorsque vous modifiez les autorisations SSH ou sudo d'un utilisateur ou d'un groupe, OpsWorks Stacks s'exécute `execute_recipes` pour mettre à jour les instances de la pile et déclenche également un événement Configure. Une autre source de commandes `execute_recipes` inattendues est la mise à jour par OpsWorks Stacks de l'agent de l'instance.
**Solution :** Il s'agit d'un fonctionnement normal ; nul besoin de faire quoi que ce soit.
Pour voir quelles actions une commande `execute_recipes` exécute, accédez à la page **Déploiements** et cliquez sur l'horodatage de la commande. La page des détails de la commande s'ouvre et affiche les principales recettes qui ont été exécutées. Par exemple, la page de détails suivante concerne une commande `execute_recipes` qui a lancé `ssh_users` pour mettre à jour les autorisations SSH.
![\[Command details page showing successful execution of Recipes and ssh_users on php-app1.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/command_details.png)
Pour voir tous les détails, cliquez sur **afficher** dans la colonne **Journal** de la commande afin d'afficher le journal Chef associé. Recherchez dans le journal**Run List**. OpsWorks Les recettes d'entretien des piles seront présentées ci-dessous. `OpsWorks Custom Run List` Par exemple, la liste suivante est la liste des exécutions de la commande `execute_recipes` affichée dans la capture d'écran précédente et illustre chaque recette associée à la commande.
```
[2014-02-21T17:16:30+00:00] INFO: OpsWorks Custom Run List: ["opsworks_stack_state_sync",
"ssh_users", "test_suite", "opsworks_cleanup"]
```
## Dépannage de l'enregistrement des instances
Cette section contient quelques problèmes d'enregistrement des instances couramment rencontrés et leurs solutions.
**Note**
Si vous rencontrez des problèmes d'enregistrement, exécutez `register` avec l'argument `--debug`, qui fournit des informations de débogage supplémentaires.
**Topics**
+ [EC2L'utilisateur n'est pas autorisé à effectuer :...](#common-issues-instance-registration-ec2user)
+ [Les informations d'identification doivent être limitées à une région valide](#common-issues-instance-registration-valid-region)
### EC2L'utilisateur n'est pas autorisé à effectuer :...
**Problème :** Une commande `register` renvoie quelque chose de similaire à ce qui suit :
```
A client error (AccessDenied) occurred when calling the CreateGroup operation:
User: arn:aws:iam::123456789012:user/ImportEC2User is not authorized to
perform: iam:CreateGroup on resource:
arn:aws:iam::123456789012:group/AWS/OpsWorks/OpsWorks-b583ce55-1d01-4695-b3e5-ee19257d1911
```
**Cause :** La `register` commande est exécutée avec des informations d'identification qui n'accordent pas les autorisations requises. La stratégie de l'utilisateur doit permettre l'action `iam:CreateGroup`, entre autres.
**Solution** : Fournissez à `register` les informations d'identification utilisateur IAM qui disposent des autorisations requises. Pour de plus amples informations, veuillez consulter [Installation et configuration de l’ AWS CLI](registered-instances-register-registering-cli.md).
### Les informations d'identification doivent être limitées à une région valide
**Problème :** Une commande `register` renvoie les éléments suivants :
```
A client error (InvalidSignatureException) occurred when calling the
DescribeStacks operation: Credential should be scoped to a valid region, not 'cn-north-1'.
```
**Cause :** La région de la commande doit être une région OpsWorks Stacks. Pour obtenir une liste des régions prises en charge, consultez la page [Prise en charge de la région](gettingstarted_intro.md#gettingstarted-intro-region). En général, cette erreur se produit pour l'une des raisons suivantes :
+ La pile est dans une autre région et vous avez attribué une région de la pile à l'argument `--region` de la commande.
Il n'est pas nécessaire de spécifier une région de pile ; OpsWorks Stacks la détermine automatiquement à partir de l'ID de pile.
+ Vous avez omis l'argument `--region` qui spécifie implicitement la région par défaut, mais votre région par défaut n'est pas prise en charge par OpsWorks Stacks.
**Solution :** définissez `--region` explicitement une région OpsWorks Stacks prise en charge``, ou modifiez votre AWS CLI `config` fichier pour remplacer la région par défaut par une région OpsWorks Stacks prise en charge. Pour de plus amples informations, veuillez consulter [Configuration de l'interface de ligne de commande AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html).