Set proxyen til SSM Agent på den faktiske systemd-tenesta
Bruk drop-in-fila til agenten og metadata-omgåinga, og skil deretter tilknytinga frå den eigne curl-førespurnaden til ein Image Builder-komponent.
Identifiser først avsendaren som feilar: SSM Agent-kommunikasjon eller ei nedlasting inne i Image Builder-komponenten. Ein SSH-shell-eksport oppdaterer ikkje agenten som køyrer.
For den vanlege amazon-ssm-agent systemd-eininga, flette inn den dokumenterte drop-in-fila 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 bera HTTPS-destinasjonar. Når agenten kan bruka ein offentleg mellommann for dei offentlege AWS-tenesteslutpunkta sine, leverer HTTP-proxy-lista kandidatar for desse URL-ane; hald på metadata-omgåinga. Hald 169.254.169.254 direkte for instansmetadata; AWS dokumenterer òg [fd00:ec2::254] for IPv6-metadataendepunktet.
Last systemd på nytt og start den faktiske agent-eininga på nytt etter endringa. Ubuntu snap-pakking brukar ein annan eining/drop-in-stad, så tilpass etter installasjonen.
Viss agenten verkar, men curl i komponenten feilar, må du oppgi miljøet til den kommandoen. Små bokstavar http_proxy har noko å seia for curl; ein vellukka agenttransaksjon fastslår ikkje desse inndataa for underførespurnaden.