Set de proxy fan SSM Agent op syn eigentlike systemd-tsjinst
Brûk de drop-in fan de agent en de metadata-omgong, en ûnderskied dan syn ferbining fan 'e eigen curl-oproep fan in Image Builder-komponint.
Stel earst fêst wa't mislearret: de kommunikaasje fan SSM Agent of in download binnen de Image Builder-komponint. In eksport fia in SSH-shell fernijt de rinnende agent net.
Foar de gewoane amazon-ssm-agent systemd-ienheid, foegje de dokumintearre drop-in by /etc/systemd/system/amazon-ssm-agent.service.d/override.conf ta:
[Service]
Environment="http_proxy=http://proxy.example:8080"
Environment="https_proxy=http://proxy.example:8080"
Environment="no_proxy=169.254.169.254"It HTTP-einpunt kin HTTPS-bestimmingen ferfiere. As de agent in iepenbier tuskenpersoan brûke mei foar syn iepenbiere AWS-tsjinst-einpunten, leveret de HTTP-proxy list kandidaten foar dizze URL's; behâld de metadata-omgong. Hâld 169.254.169.254 direkt foar instance-metadata; AWS dokumintearret ek [fd00:ec2::254] foar it IPv6-metadata-einpunt.
Laad systemd opnij en start de eigentlike agent-ienheid opnij nei de wiziging. Ubuntu snap-ferpakking brûkt in oare ienheid/drop-in-lokaasje, dus pas oan by de ynstallaasje.
As de agent wurket mar de curl fan 'e komponint mislearret, leverje dan de omjouwing fan dat kommando. Lytse letters http_proxy binne wichtich foar curl; in slagge agent-transaksje bewissiget dy ynfier fan 'e berne-oproep net.