Comment puis-je résoudre les problèmes liés à l’agent Systems Manager qui est bloqué au démarrage ou qui ne démarre pas ?

Lecture de 8 minute(s)
0

Je souhaite déterminer pourquoi AWS Systems Manager Agent (SSM Agent) est bloqué au démarrage ou ne démarre pas.

Brève description

Une instance gérée est une instance Amazon EC2 configurée pour être utilisée avec le Systems Manager. Les instances gérées peuvent utiliser les services du Systems Manager tels qu’Exécuter la commande, Gestionnaire de correctifs et Gestionnaire de session.

Assurez-vous que votre instance Amazon Elastic Compute Cloud (Amazon EC2) répond aux conditions préalables suivantes pour être une instance gérée :

  • Le SSM Agent est installé et en cours d’exécution sur l’instance.
  • L’instance est connectée au service de métadonnées de l’instance.
  • L’instance est connectée aux points de terminaison de Systems Manager à l’aide du SSM Agent.
  • Le rôle AWS Identity and Access Management (IAM) approprié est associé à l’instance.

Le SSM Agent ne démarre pas lorsque ces conditions préalables ne sont pas remplies.

Pour les versions 3.1.501.0 et ultérieures du SSM Agent, vous pouvez utiliser l'outil ssm-cli pour déterminer si une instance répond à ces exigences. Cet outil vous permet de déterminer pourquoi une instance EC2 en cours d’exécution ne figure pas dans la liste des instances gérées de Systems Manager.

Si votre instance n’apparaît pas en tant qu’instance gérée dans la console Systems Manager, consultez les journaux du SSM Agent pour un dépannage plus approfondi.

  • Vous pouvez trouver les journaux du SSM Agent pour Linux à l’adresse /var/log/amazon/ssm.
  • Vous pouvez trouver les journaux du SSM Agent pour Windows à l’adresse %PROGRAMDATA%\Amazon\SSM\Logs.

Remarque : si l’instance ne rapporte pas à Systems Manager, essayez de vous connecter via RDP (Windows) ou SSH (Linux) pour collecter les journaux. Si vous ne parvenez toujours pas à vous connecter, arrêtez l’instance et détachez le volume racine. Ensuite, attachez le volume racine à une autre instance de la même zone de disponibilité en tant que volume secondaire pour obtenir les journaux.

Résolution

Remarque : si des erreurs surviennent lors de l’exécution des commandes de l’Interface de la ligne de commande AWS CLI, vérifiez que vous utilisez la version la plus récente d’AWS CLI.

Assurez-vous d’avoir installé la dernière version du SSM Agent

Il est recommandé d’utiliser la dernière version du SSM Agent.

Pour Linux, consultez la section Installation manuelle du SSM Agent sur des instances EC2 pour Linux.

Pour Windows, consultez la section Installation manuelle du SSM Agent sur des instances EC2 pour Windows Server.

Vérifiez la connectivité au service de métadonnées de l’instance

Remarque : cette connectivité est requise uniquement pour une instance EC2 et non pour une activation hybride.

Le SSM Agent s’appuie sur les métadonnées de l’instance EC2 pour fonctionner correctement. Le SSM Agent peut accéder aux métadonnées de l’instance à l’aide du service de métadonnées d’instance version 1 (IMDSv1) ou du service de métadonnées d’instance version 2 (IMDSv2). Assurez-vous que votre instance peut accéder à l’adresse IPv4 du service de métadonnées d’instance : 169.254.169.254.

Pour vérifier la connectivité au service de métadonnées d’instance, exécutez la commande suivante depuis votre instance EC2 :

Linux :

telnet 169.254.169.254 80
or
curl -I http://169.254.169.254/latest/meta-data/

Windows :

curl http://169.254.169.254/latest/meta-data/  
or
Test-NetConnection 169.254.169.254  -port 80

Si votre instance ne peut pas accéder aux métadonnées, assurez-vous que les métadonnées sont activées.

Pour les instances EC2 existantes, procédez comme suit pour vérifier si les métadonnées sont activées :

  1. Ouvrez la console Amazon EC2.
  2. Dans le volet de navigation, choisissez Instances.
  3. Sélectionnez votre instance.
  4. Choisissez Actions, Paramètres de l’instance, Options de modification des métadonnées de l’instance.
  5. Dans la boîte de dialogue Modifier les options des métadonnées de l’instance, vérifiez si le service de métadonnées de l’instance est activé.

Vous pouvez également utiliser la commande describe-instances pour vérifier si le service de métadonnées d’instance est activé :

aws ec2 describe-instances --query "Reservations[*].Instances[*].MetadataOptions" --instance-ids i-012345678910

Le résultat ressemble à ce qui suit :

[
  [
    {
      "State": "applied",
      "HttpTokens": "optional",
      "HttpPutResponseHopLimit": 1,
      "HttpEndpoint": "enabled",
      "HttpProtocolIpv6": "disabled",
      "InstanceMetadataTags": "disabled"
    }
  ]
]

Le champ HttpEndpoint dans la sortie précédente indique si les métadonnées sont activées.

Si l’accès aux métadonnées est désactivé, activez-le.

Si un proxy est configuré dans l’instance, assurez-vous que l’instance contourne l’adresse IP des métadonnées (169.254.169.254). Pour plus d’informations, consultez les guides de l’utilisateur suivants :

Linux : Configuration du SSM Agent pour utiliser un proxy (Linux)

Windows : Configurer le SSM Agent pour utiliser un proxy pour les instances de Windows Server

Pour Windows, vérifiez l’itinéraire spécifique vers les métadonnées (169.254.169.254).

Dans PowerShell, exécutez les commandes route print et ipconfig /all. Vérifiez ensuite la sortie des métadonnées :

    Network Address        Netmask             Gateway Address
    169.254.169.254        255.255.255.255     <Subnet Router Address>

Vérifiez que le champ Adresse de la passerelle dans la sortie correspond à la passerelle par défaut pour l’interface réseau principale de l’instance.

Si l’itinéraire n’est pas présent ou si le champ Adresse de la passerelle ne correspond pas, procédez comme suit :

  1. Vérifiez que la dernière version d’EC2Config (Windows Server 2012R2 et versions antérieures) ou d’EC2Launch (Windows Server 2016 ou version ultérieure) est installée sur l’instance.
  2. Pour appliquer l’itinéraire à l’instance, redémarrez le service EC2Config.
  3. Si les itinéraires sont corrects, mais que l’instance ne parvient toujours pas à récupérer les métadonnées, passez en revue la configuration du pare-feu Windows, du pare-feu tiers et de l’antivirus de votre instance. Vérifiez que le trafic vers 169.254.169.254 n’est pas explicitement refusé.

Pour réinitialiser manuellement les itinéraires de métadonnées, procédez comme suit :

Remarque : ces modifications configurées sont immédiatement renseignées. Il n’est pas nécessaire de redémarrer l’instance pour que les modifications prennent effet.

  1. Exécutez les commandes suivantes pour supprimer les itinéraires de métadonnées existants de la table de routage :

    route delete 169.254.169.123
    route delete 169.254.169.249
    route delete 169.254.169.250
    route delete 169.254.169.251
    route delete 169.254.169.252
    route delete 169.254.169.253
    route delete 169.254.169.254
  2. Exécutez la commande suivante :

    ipconfig /all
  3. Notez l’adresse IP de la passerelle par défaut renvoyée par la commande à l’étape 2.

  4. Exécutez la commande suivante. Remplacez DefaultGatewayIP par l’adresse IP que vous avez récupérée à l’étape 3.

    route -p add 169.254.169.123 MASK 255.255.255.255 DefaultGatewayIP
    route -p add 169.254.169.249 MASK 255.255.255.255 DefaultGatewayIP
    route -p add 169.254.169.250 MASK 255.255.255.255 DefaultGatewayIP
    route -p add 169.254.169.251 MASK 255.255.255.255 DefaultGatewayIP
    route -p add 169.254.169.252 MASK 255.255.255.255 DefaultGatewayIP
    route -p add 169.254.169.253 MASK 255.255.255.255 DefaultGatewayIP
    route -p add 169.254.169.254 MASK 255.255.255.255 DefaultGatewayIP
  5. Redémarrez le SSM Agent.

Vérifiez la connectivité au points de terminaison de Systems Manager

La meilleure méthode pour vérifier cette connectivité dépend de votre système d’exploitation. Pour obtenir la liste des points de terminaison de Systems Manager par région, consultez la section Points de terminaison et quotas d’AWS Systems Manager.

**Remarque :**dans les exemples suivants, le point de terminaison ssmmessages est requis uniquement pour AWS Systems Manager Session Manager.

Pour les instances Linux EC2, exécutez les commandes telnet ou netcat pour vérifier la connectivité aux points de terminaison sur le port 443.

Telnet

telnet ssm.RegionID.amazonaws.com 443
telnet ec2messages.RegionID.amazonaws.com 443
telnet ssmmessages.RegionID.amazonaws.com 443

Assurez-vous de remplacer RegionID par votre ID de région AWS.

Si la connexion est établie, vous obtenez une sortie similaire à la suivante :

root@111800186:~# telnet ssm.us-east-1.amazonaws.com 443
Trying 52.46.141.158...
Connected to ssm.us-east-1.amazonaws.com.
Escape character is '^]'.
To exit from telnet, hold down the Ctrl key and press the ] key. Enter quit, and then press Enter.

Netcat

nc -vz ssm.RegionID.amazonaws.com 443
nc -vz ec2messages.RegionID.amazonaws.com 443
nc -vz ssmmessages.RegionID.amazonaws.com 443

Remarque : Netcat n’est pas préinstallé sur les instances Amazon EC2. Pour installer Netcat manuellement, consultez Ncat sur le site Web de Nmap.

Pour les instances Windows EC2, exécutez les commandes Windows PowerShell suivantes pour vérifier la connectivité aux points de terminaison sur le port 443 :

Test-NetConnection ssm.RegionID.amazonaws.com -port 443
Test-NetConnection ec2messages.RegionID.amazonaws.com -port 443
Test-NetConnection ssmmessages.RegionID.amazonaws.com -port 443

Si la connexion est établie, vous obtenez une sortie similaire à la suivante :

PS C:\Users\ec2-user> Test-NetConnection ssm.us-east-1.amazonaws.com -port 443
ComputerName     : ssm.us-east-1.amazonaws.com
RemoteAddress    : 52.46.145.233
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 10.35.218.225
TcpTestSucceeded : True

Vérifiez le rôle IAM du SSM Agent

Le SSM Agent nécessite certaines autorisations de l’IAM pour passer les appels de l’API Systems Manager. Vous pouvez gérer ces autorisations à l’aide de l’une des approches suivantes :

  • La configuration de gestion des hôtes par défaut permet à Systems Manager de gérer automatiquement vos instances Amazon EC2. Il permet de gérer les instances sans utiliser de profils d’instance. Cette configuration garantit que Systems Manager est autorisé à gérer toutes les instances de la région et du compte.
  • Vous pouvez accorder l’accès au niveau de l’instance à l’aide d’un profil d’instance IAM. Un profil d’instance est un conteneur qui transmet les informations relatives au rôle IAM à une instance lors de son lancement. Pour plus d’informations, consultez la section Configuration alternative.

Informations connexes

Pourquoi mon instance EC2 ne s’affiche-t-elle pas en tant que nœud géré ou affiche-t-elle l’état « Connexion perdue » dans Systems Manager ?

Rendre un volume Amazon EBS disponible pour une utilisation sous Linux

Rendre un volume Amazon EBS disponible pour une utilisation sous Windows

Pourquoi mon instance Windows Amazon EC2 génère-t-elle le message d’erreur « En attente du service de métadonnées » ?

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an