Насочете проксито на SSM Agent към действителната му systemd услуга
Използвайте drop-in файла на агента и заобикалянето на metadata, после разграничете връзката му от собствения curl запрос на компонент на Image Builder.
Първо установете кой изпращач се проваля: комуникацията на SSM Agent или изтегляне в компонента на Image Builder. Експорт през SSH shell не обновява работещия агент.
За стандартния amazon-ssm-agent systemd unit обединете документирания drop-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"HTTP крайната точка може да пренася HTTPS дестинации. Когато агентът може да използва публичен посредник за публичните си AWS крайни точки, списъкът с HTTP прокси сървъри предлага кандидати за тези URL адреси; запазете заобикалянето на metadata. Оставете 169.254.169.254 директно за метаданни на инстанцията; AWS документира също [fd00:ec2::254] за IPv6 крайната точка за метаданни.
Презаредете systemd и рестартирайте действителния unit на агента след промяната. Пакетирането с Ubuntu snap използва друго място за unit/drop-in, затова се съобразете с инсталацията.
Ако агентът работи, но curl на компонента се проваля, подайте средата на тази команда. Малките букви http_proxy са важни за curl; успешна транзакция на агента не доказва тези входни данни на дъщерната заявка.