Metti il proxy di SSM Agent sul suo effettivo servizio systemd
Usa il drop-in dell'agente e il bypass dei metadata, poi distingui la sua connettività dalla richiesta curl di un componente Image Builder.
Per prima cosa individua il mittente che fallisce: la comunicazione di SSM Agent o un download all'interno del componente Image Builder. Un export tramite shell SSH non aggiorna l'agente in esecuzione.
Per l'unità systemd standard amazon-ssm-agent, unisci il drop-in documentato in /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"L'endpoint HTTP può trasportare destinazioni HTTPS. Quando all'agente è consentito usare un intermediario pubblico per i suoi endpoint pubblici di AWS, la lista di proxy HTTP fornisce candidati per questi URL; conserva il bypass dei metadata. Mantieni 169.254.169.254 diretto per i metadata dell'istanza; AWS documenta anche [fd00:ec2::254] per l'endpoint metadata IPv6.
Ricarica systemd e riavvia l'unità effettiva dell'agente dopo la modifica. Il pacchetto snap di Ubuntu usa un'altra posizione di unità/drop-in, quindi allineati all'installazione.
Se l'agente funziona ma il curl del componente fallisce, fornisci l'ambiente di quel comando. Le minuscole http_proxy contano per curl; una transazione riuscita dell'agente non dimostra quegli input della richiesta figlia.