Placez le proxy de SSM Agent sur son véritable service systemd
Utilisez le drop-in de l'agent et le contournement de metadata, puis distinguez sa connectivité de la propre requête curl d'un composant Image Builder.
Identifiez d'abord l'émetteur en échec : la communication de SSM Agent ou un téléchargement dans le composant Image Builder. Un export via un shell SSH ne met pas à jour l'agent en cours d'exécution.
Pour l'unité systemd standard amazon-ssm-agent, fusionnez le drop-in documenté dans /etc/systemd/system/amazon-ssm-agent.service.d/override.conf :
[Service]
Environment="http_proxy=http://proxy.example:8080"
Environment="https_proxy=http://proxy.example:8080"
Environment="no_proxy=169.254.169.254"Le point de terminaison HTTP peut transporter des destinations HTTPS. Lorsque l'agent peut recourir à un intermédiaire public pour ses points de terminaison AWS publics, la liste de proxys HTTP fournit des candidats pour ces URL ; conservez le contournement de metadata. Gardez 169.254.169.254 en direct pour les metadata de l'instance ; AWS documente aussi [fd00:ec2::254] pour le point de terminaison metadata IPv6.
Rechargez systemd et redémarrez la véritable unité de l'agent après la modification. Le paquet snap d'Ubuntu utilise un autre emplacement d'unité/drop-in, alignez-vous donc sur l'installation.
Si l'agent fonctionne mais que le curl du composant échoue, fournissez l'environnement de cette commande. Les minuscules http_proxy comptent pour curl ; une transaction d'agent réussie n'établit pas ces entrées de la requête enfant.