Прызначце проксі SSM Agent яго рэальнаму сэрвісу systemd
Выкарыстайце drop-in агента і абыход metadata, затым адрозніце яго злучэнне ад уласнага запыту curl кампанента Image Builder.
Спачатку вызначце адпраўніка, які збоіць: сувязь SSM Agent ці запампаванне ўнутры кампанента Image Builder. Экспарт праз SSH-shell не абнаўляе запушчаны агент.
Для звычайнага блока systemd amazon-ssm-agent аб'яднайце дакументаваны 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 і перазапусціце фактычны блок агента пасля змены. Пакет Ubuntu snap выкарыстоўвае іншае месца блока/drop-in, таму ўзгадніце з усталёўкай.
Калі агент працуе, а curl кампанента збоіць, забяспечце асяроддзе гэтай каманды. Малыя літары http_proxy важныя для curl; паспяховая транзакцыя агента не ўсталёўвае гэтыя ўваходы даччынага запыту.