Résolution des problèmes AWS OpsWorks for Chef Automate - AWS OpsWorks
Conseils généraux de dépannageRésolution d'erreurs spécifiquesAide supplémentaire et support

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 AWS OpsWorks for Chef Automate

Important

AWS OpsWorks for Chef Automate a atteint sa fin de vie le 5 mai 2024 et a été désactivé pour les nouveaux clients et les clients existants. Nous recommandons aux clients existants de migrer vers Chef SaaS ou vers une solution alternative. Si vous avez des questions, vous pouvez contacter l' AWS Support équipe sur AWS Re:Post ou via le AWS Support Premium.

Cette rubrique présente certains AWS OpsWorks for Chef Automate problèmes courants et propose des solutions à ces problèmes.

Conseils généraux de dépannage

Si vous ne pouvez pas créer ou utiliser un serveur de Chef, vous pouvez afficher les messages d'erreur ou les journaux pour vous aider à résoudre le problème. Les tâches suivantes décrivent les emplacements généraux où démarrer lorsque vous voulez résoudre un problème lié à un serveur Chef. Pour plus d'informations sur des erreurs spécifiques et les solutions, consultez la section Résolution d'erreurs spécifiques de cette rubrique.

  • Utilisez la AWS OpsWorks for Chef Automate console pour afficher les messages d'erreur si un serveur Chef ne démarre pas. Sur la page des détails du serveur Chef, les messages d'erreur liés au lancement et au fonctionnement du serveur sont affichés en haut de la page. Les erreurs peuvent provenir AWS OpsWorks for Chef Automate AWS CloudFormation des services utilisés pour créer un serveur Chef ou d'Amazon EC2. Sur la page des détails, vous pouvez aussi afficher des événements se produisant sur un serveur en cours d'exécution, qui peut contenir des messages d'événement d'erreur.

  • Pour résoudre des problèmes EC2, connectez-vous à l'instance de votre serveur à l'aide de SSH et affichez les journaux. Les journaux d'instance EC2 sont stockés dans le répertoire /var/log/aws/opsworks-cm. Ces journaux capturent les sorties de commande lors du AWS OpsWorks for Chef Automate lancement d'un serveur Chef.

Résolution d'erreurs spécifiques

Le serveur est dans un état de perte de connexion

Problème : l'état d'un serveur indique que la connexion est perdue.

Cause : Cela se produit le plus souvent lorsqu'une entité extérieure AWS OpsWorks apporte des modifications à un AWS OpsWorks for Chef Automate serveur ou à ses ressources de support. AWS OpsWorks ne peut pas se connecter aux serveurs Chef Automate en état de perte de connexion pour gérer les tâches de maintenance telles que la création de sauvegardes, l'application de correctifs du système d'exploitation ou la mise à jour de Chef Automate. Par conséquent, il est possible que votre serveur ne dispose pas de mises à jour importantes, soit exposé à des problèmes de sécurité ou ne fonctionne pas comme prévu.

Solution : essayez les étapes suivantes pour rétablir la connexion du serveur.

  1. Assurez-vous que votre rôle de service dispose de toutes les autorisations requises.

    1. Sur la page Paramètres de votre serveur, dans Réseau et sécurité, choisissez le lien correspondant au rôle de service utilisé par le serveur. Cela ouvre le rôle de service à afficher dans la console IAM.

    2. Dans l'onglet Autorisations, vérifiez que cela AWSOpsWorksCMServiceRole figure dans la liste des politiques d'autorisations. Si elle n'est pas répertoriée, ajoutez la politique AWSOpsWorksCMServiceRole gérée manuellement au rôle.

    3. Dans l'onglet Relations de confiance, vérifiez que le rôle de service dispose d'une politique de confiance qui autorise le opsworks-cm.amazonaws.com service à assumer des rôles en votre nom. Pour plus d'informations sur l'utilisation des politiques de confiance avec les rôles, consultez Modifier un rôle (console) ou le billet du blog sur la AWS sécurité intitulé Comment utiliser les politiques de confiance avec les rôles IAM.

  2. Assurez-vous que votre profil d'instance dispose de toutes les autorisations requises.

    1. Sur la page Paramètres de votre serveur, dans Réseau et sécurité, choisissez le lien correspondant au profil d'instance utilisé par le serveur. Cela ouvre le profil de l'instance pour qu'il soit affiché dans la console IAM.

    2. Dans l'onglet Autorisations, vérifiez cela AmazonEC2RoleforSSM et AWSOpsWorksCMInstanceProfileRole les deux figurent dans la liste des politiques d'autorisations. Si l'une ou les deux ne figurent pas dans la liste, ajoutez ces politiques gérées manuellement au rôle.

    3. Dans l'onglet Relations de confiance, vérifiez que le rôle de service dispose d'une politique de confiance qui autorise le ec2.amazonaws.com service à assumer des rôles en votre nom. Pour plus d'informations sur l'utilisation des politiques de confiance avec les rôles, consultez Modifier un rôle (console) ou le billet du blog sur la AWS sécurité intitulé Comment utiliser les politiques de confiance avec les rôles IAM.

  3. Dans la console Amazon EC2, assurez-vous que vous vous trouvez dans la même région que celle du AWS OpsWorks for Chef Automate serveur, puis redémarrez l'instance EC2 utilisée par votre serveur.

    1. Choisissez l'instance EC2 nommée aws-opsworks-cm-instance- server-name.

    2. Dans le menu État de l'instance, choisissez Redémarrer l'instance.

    3. Prévoyez jusqu'à 15 minutes pour que votre serveur redémarre et soit entièrement en ligne.

  4. Dans la AWS OpsWorks for Chef Automate console, sur la page de détails du serveur, vérifiez que l'état du serveur est désormais sain.

Si l'état du serveur est toujours Perte de connexion après avoir effectué les étapes précédentes, essayez l'une des solutions suivantes.

Un nœud géré apparaît dans le tableau de bord Chef Automate dans la colonne Missing

Problème : Un nœud géré apparaît dans la colonne Missing (Manquant) du tableau de bord Chef Automate.

Cause : Lorsqu'un nœud ne s'est pas connecté au serveur Chef Automate depuis plus de 12 heures, et que chef-client ne peut pas s'exécuter sur le nœud, le nœud reprend l'état qu'il avait 12 heures auparavant et est transféré dans la colonne Missing (Manquant) du tableau de bord Chef Automate.

Solution : Vérifiez si le nœud est en ligne. Essayez de lancer knife node show node_name --run-list pour voir si chef-client peut s'exécuter sur le nœud, ou knife node show -l node_name pour afficher toutes les informations concernant le nœud. Le nœud est peut-être hors connexion ou déconnecté du réseau.

Impossible de créer un coffre Chef ; la commande knife vault échoue avec des erreurs

Problème : Vous essayez de créer un coffre sur votre serveur Chef Automate (par exemple, un coffre pour stocker des informations d'identification pour des nœuds Windows de jointure au domaine) en exécutant la commande knife vault. La commande renvoie un message d'erreur similaire à celui qui apparaît ci-dessous.

WARN: Auto inflation of JSON data is deprecated. Please pass in the class to inflate or use #edit_hash (CHEF-1) 
at /opt/chefdk/embedded/lib/ruby/2.3.0/forwardable.rb:189:in `edit_data'.Please see https://docs.chef.io/deprecations_json_auto_inflate.html 
for further details and information on how to correct this problem.
WARNING: pivotal not found in users, trying clients.
ERROR: ChefVault::Exceptions::AdminNotFound: FATAL: Could not find pivotal in users or clients!

L'utilisateur central n'est pas renvoyé lorsque vous exécutez la commande knife user list à distance, mais vous pouvez voir l'utilisateur central dans les résultats lorsque vous exécutez la commande chef-server-ctl user-show en local sur votre serveur Chef Automate. En d'autres termes, votre commande knife vault ne peut pas trouver l'utilisateur central mais vous savez qu'il existe.

Cause : Même si l'utilisateur central est considéré comme le super-utilisateur dans Chef et s'il dispose des autorisations complètes, il n'est membre d'aucune organisation, ni même de l'organisation default utilisée dans AWS OpsWorks for Chef Automate. La commande knife user list renvoie tous les utilisateurs figurant dans l'organisation actuelle de votre configuration Chef. La commande chef-server-ctl user-show renvoie tous les utilisateurs quelle que soit l'organisation, y compris l'utilisateur central.

Solution : Pour remédier à ce problème, ajoutez l'utilisateur central dans l'organisation par défaut en exécutant knife opc.

Tout d'abord, vous devez installer le plug-in knife-opc.

chef gem install knife-opc

Une fois que vous avez installé le plug-in, exécutez la commande suivante pour ajouter l'utilisateur central dans l'organisation par défaut.

knife opc org user add default pivotal

Vous pouvez vérifier que l'utilisateur central fait partie de l'organisation par défaut en exécutant à nouveau knife user list. pivotal devrait apparaître dans les résultats. Ensuite, réessayez d'exécuter knife vault.

La création du serveur échoue avec un message indiquant que la configuration demandée n'est actuellement pas prise en charge.

Problème : Vous essayez de créer un serveur Chef Automate, mais la création du serveur échoue avec un message d'erreur similaire à « The requested configuration is currently not supported. Please check the documentation for supported configurations. »

Cause : Un type d'instance non pris en charge a peut-être été spécifié pour le serveur Chef Automate. Si vous choisissez de créer le serveur Chef Automate dans un VPC disposant d'une location autre que celle par défaut, comme une location pour des instances dédiées, toutes les instances à l'intérieur du VPC spécifié doivent être également associées à une location dédiée ou d'hôte. Comme certains types d'instance, comme t2, ne sont disponibles qu'avec la location par défaut, le type d'instance du serveur Chef Automate peut ne pas être pris en charge par le VPC spécifié et la création du serveur échoue.

Solution : Si vous choisissez un VPC disposant d'une location autre que celle par défaut, utilisez un type d'instance m4 qui peut prendre en charge une location dédiée.

Le serveur Chef ne reconnaît pas les noms d'organisation ajoutés dans le tableau de bord de Chef Automate.

Problème : vous avez ajouté de nouveaux noms d'organisation de flux de travail dans le tableau de bord de Chef Automate ou spécifié une valeur CHEF_AUTOMATE_ORGANIZATION autre que "default" dans le script d'association sans surveillance des nœuds, mais l'association de nœuds échoue. Votre serveur AWS OpsWorks for Chef Automate ne reconnaît pas les nouveaux noms d'organisation.

Cause : les noms d'organisation du flux de travail et ceux du serveur Chef sont différents. Vous pouvez créer de nouvelles organisations du flux de travail dans le tableau de bord web de Chef Automate, mais pas de nouveaux noms d'organisation du serveur Chef. Vous pouvez utiliser le tableau de bord de Chef Automate uniquement pour afficher les organisations existantes du serveur Chef. Une nouvelle organisation créée dans le tableau de bord de Chef Automate est une organisation du flux de travail et elle n'est pas reconnue par le serveur Chef. Vous ne pouvez pas créer de nouveaux noms d'organisation en les spécifiant dans le script d'association des nœuds. Si vous faites référence à un nom d'organisation dans un script d'association de nœuds alors que l'organisation n'a pas été ajoutée au serveur Chef, l'association de nœuds échouera.

Solution : pour créer de nouvelles organisation reconnues sur le serveur Chef, utilisez la commande knife opc org create ou exécutez chef-server-ctl org-create.

Impossible de créer l'instance Amazon EC2 du serveur

Problème : La création du serveur a échoué avec un message d'erreur semblable au message suivant : « The following resource(s) failed to create: [EC2Instance]. Failed to receive 1 resource signal(s) within the specified duration. »

Cause : Cette erreur est probablement due au fait que l'instance EC2 n'a pas accès au réseau.

Solution : assurez-vous que l'instance dispose d'un accès Internet sortant et que l'agent de AWS service est en mesure d'émettre des commandes. Assurez-vous que le paramètre Résolution DNS est activé pour votre VPC (un VPC avec un seul sous-réseau public), et que le paramètre Activer l'adresse IP publique attribuée automatiquement est activé pour votre sous-réseau.

Une erreur de rôle de service empêche la création du serveur

Problème : la création du serveur échoue avec un message d'erreur indiquant « Non autorisé à exécuter sts : »AssumeRole.

Cause : Cela peut se produire lorsque le rôle de service vous utilisez n'a pas les autorisations appropriées pour créer un nouveau serveur.

Solution : ouvrez la AWS OpsWorks for Chef Automate console ; utilisez-la pour générer un nouveau rôle de service et un rôle de profil d'instance. Si vous préférez utiliser votre propre rôle de service, associez la AWSOpsWorksCMServiceRolepolitique au rôle. Vérifiez que opsworks-cm.amazonaws.com figure parmi les services concernés par les relations de confiance du rôle. Vérifiez que la politique AWSOpsWorksCMServiceRolegérée est attachée au rôle de service associé au serveur Chef.

Limite appliquée aux adresses IP Elastic dépassée

Problème : La création du serveur échoue avec le message d'erreur « The following resource(s) failed to create: [EIP, EC2Instance]. Resource creation cancelled, the maximum number of addresses has been reached. »

Cause : Cette erreur a lieu lorsque votre compte a utilisé le nombre maximal d'adresses IP Elastic (EIP). La limite d'adresses IP Elastic est de cinq.

Solution : vous pouvez soit libérer les adresses EIP existantes, soit supprimer celles que votre compte n'utilise pas activement, soit contacter le Support AWS client pour augmenter le nombre d'adresses EIP associées à votre compte.

Impossible de se connecter au tableau de bord Chef Automate

Problème : Le tableau de bord Chef Automate affiche une erreur similaire à l'erreur suivante : « Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://myserver-name.region.opsworks-cm.io/api/v0/e/default/verify-token. (Reason: CORS header 'Access-Control-Allow-Origin' missing). » L'erreur peut également similaire à « The User Id / Password combination entered is incorrect. »

Cause : Le tableau de bord Chef Automate définit explicitement le nom de domaine complet (FQDN) et n'accepte pas les adresses URL relatives. Pour le moment, vous ne pouvez pas vous connecter à l'aide de l'adresse IP Chef ; vous pouvez uniquement vous connecter en utilisant le nom DNS du serveur.

Solution : Connectez-vous au tableau de bord Chef Automate uniquement à l'aide de l'entrée de nom DNS du serveur Chef, pas avec son adresse IP. Vous pouvez également essayer de réinitialiser les informations d'identification du tableau de bord Chef Automate en exécutant une commande de l' AWS CLI , comme décrit dans Réinitialiser les informations d'identification du tableau de bord Chef Automate.

Une association de nœud sans surveillance échoue

Problème : l'association automatique ou sans surveillance de nouveaux nœuds Amazon EC2 échoue. Les nœuds qui auraient dû être ajoutés au serveur Chef n'apparaissent pas dans le tableau de bord Chef Automate et ne sont pas répertoriés dans les résultats des commandes knife client show ou knife node show.

Cause : Cela peut se produire lorsque vous n'avez de rôle IAM configuré en tant que profil d'instance qui autorise les appels d'API opsworks-cm pour communiquer avec les nouvelles instances EC2.

Solution : Attachez à votre profil d'instance EC2 une stratégie qui permet aux appels d'API AssociateNode et DescribeNodeAssociationStatus de fonctionner avec EC2, comme décrit dans Ajouter des nœuds automatiquement AWS OpsWorks for Chef Automate.

Échec de la maintenance du système

AWS OpsWorks CM effectue une maintenance hebdomadaire du système pour s'assurer que les dernières versions mineures de Chef Server et Chef Automate Server, y compris les mises à jour de sécurité, s'exécutent toujours sur un serveur AWS OpsWorks pour Chef Automate. Si, pour une raison quelconque, la maintenance du système échoue, vous en AWS OpsWorks CM informe. Pour plus d'informations sur la maintenance du système, consultezMaintenance du système dans AWS OpsWorks for Chef Automate.

Cette section décrit les causes possibles de l'échec et propose des solutions.

Une erreur de rôle de service ou de profil d'instance empêche la maintenance du système

Problème : la maintenance du système échoue avec un message d'erreur indiquant « Non autorisé à exécuter sts : AssumeRole » ou un message d'erreur similaire concernant les autorisations.

Cause : Cela peut se produire lorsque le rôle de service ou le profil d'instance que vous utilisez ne dispose pas des autorisations adéquates pour effectuer la maintenance du système sur le serveur.

Solution : Assurez-vous que votre rôle de service et votre profil d'instance disposent de toutes les autorisations requises.

  1. Assurez-vous que votre rôle de service dispose de toutes les autorisations requises.

    1. Sur la page Paramètres de votre serveur, dans Réseau et sécurité, choisissez le lien correspondant au rôle de service utilisé par le serveur. Cela ouvre le rôle de service à afficher dans la console IAM.

    2. Dans l'onglet Autorisations, vérifiez qu'AWSOpsWorksCMServiceRoleil est attaché au rôle de service. Si elle n'AWSOpsWorksCMServiceRoleest pas répertoriée, ajoutez cette politique au rôle.

    3. Vérifiez que opsworks-cm.amazonaws.com figure parmi les services concernés par les relations de confiance du rôle. Pour plus d'informations sur l'utilisation des politiques de confiance avec les rôles, consultez Modifier un rôle (console) ou le billet du blog sur la AWS sécurité intitulé Comment utiliser les politiques de confiance avec les rôles IAM.

  2. Assurez-vous que votre profil d'instance dispose de toutes les autorisations requises.

    1. Sur la page Paramètres de votre serveur, dans Réseau et sécurité, choisissez le lien correspondant au profil d'instance utilisé par le serveur. Cela ouvre le profil de l'instance pour qu'il soit affiché dans la console IAM.

    2. Dans l'onglet Autorisations, vérifiez cela AmazonEC2RoleforSSM et AWSOpsWorksCMInstanceProfileRole les deux figurent dans la liste des politiques d'autorisations. Si l'une ou les deux ne figurent pas dans la liste, ajoutez ces politiques gérées manuellement au rôle.

    3. Dans l'onglet Relations de confiance, vérifiez que le rôle de service dispose d'une politique de confiance qui autorise le ec2.amazonaws.com service à assumer des rôles en votre nom. Pour plus d'informations sur l'utilisation des politiques de confiance avec les rôles, consultez Modifier un rôle (console) ou le billet du blog sur la AWS sécurité intitulé Comment utiliser les politiques de confiance avec les rôles IAM.

Aide supplémentaire et support

Si vous ne voyez pas votre problème spécifique décrit dans cette rubrique, ou si vous avez essayé les suggestions de cette rubrique et que les problèmes persistent, consultez les forums AWS OpsWorks.

Vous pouvez également visiter le Centre de Support AWS. Le Centre de AWS support est le centre de création et de gestion des dossiers de AWS support. Le Centre de AWS support inclut également des liens vers d'autres ressources utiles, telles que des forums, des FAQ techniques, l'état de santé du service et AWS Trusted Advisor.