Puneți proxy-ul SSM Agent pe serviciul systemd real
Folosiți drop-in-ul agentului și ocolirea metadata, apoi distingeți conectivitatea acestuia de cererea curl proprie a unui component Image Builder.
Identificați mai întâi expeditorul care eșuează: comunicația SSM Agent sau o descărcare în componentul Image Builder. Un export prin shell SSH nu actualizează agentul aflat în execuție.
Pentru unitatea systemd obișnuită amazon-ssm-agent, îmbinați drop-in-ul documentat în /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"Punctul final HTTP poate transporta destinații HTTPS. Când agentului i se permite să folosească un intermediar public pentru punctele sale finale publice AWS, lista de proxy HTTP oferă candidați pentru aceste URL-uri; păstrați ocolirea metadata. Păstrați 169.254.169.254 direct pentru metadata instanței; AWS documentează și [fd00:ec2::254] pentru punctul final metadata IPv6.
Reîncărcați systemd și reporniți unitatea reală a agentului după modificare. Pachetul snap Ubuntu folosește altă locație de unitate/drop-in, așa că aliniați-vă la instalare.
Dacă agentul funcționează, dar curl-ul componentului eșuează, furnizați mediul acelei comenzi. Literele mici http_proxy contează pentru curl; o tranzacție reușită a agentului nu stabilește acele intrări ale cererii copil.