Sett proxyen til SSM Agent på den faktiske systemd-tjenesten
Bruk drop-in-filen til agenten og metadata-omgåelsen, og skill deretter tilkoblingen fra den egne curl-forespørselen til en Image Builder-komponent.
Identifiser først avsenderen som feiler: SSM Agent-kommunikasjon eller en nedlasting inne i Image Builder-komponenten. En SSH-shell-eksport oppdaterer ikke agenten som kjører.
For den vanlige amazon-ssm-agent systemd-enheten fletter du inn den dokumenterte drop-in-filen i /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"HTTP-endepunktet kan bære HTTPS-destinasjoner. Når agenten kan bruke en offentlig mellommann for sine offentlige AWS-tjenestesluttepunkter, leverer HTTP-proxy-listen kandidater for disse URL-ene; behold metadata-omgåelsen. Hold 169.254.169.254 direkte for instansmetadata; AWS dokumenterer også [fd00:ec2::254] for IPv6-metadataendepunktet.
Last inn systemd på nytt og start den faktiske agentenheten på nytt etter endringen. Ubuntu snap-pakking bruker en annen enhet/drop-in-plassering, så tilpass etter installasjonen.
Hvis agenten virker, men curl i komponenten feiler, må du oppgi miljøet til den kommandoen. Små bokstaver http_proxy betyr noe for curl; en vellykket agenttransaksjon fastslår ikke disse inndataene for underforespørselen.