把 SSM Agent 的代理放到它真正的 systemd 服务上

使用 agent 的 drop-in 与 metadata 绕过，再区分它与 Image Builder 组件自身 curl 请求的连接性。

先确认是哪个发送方失败：SSM Agent 的通信，还是 Image Builder 组件内部的下载。通过 SSH shell 导出并不会更新正在运行的 agent。

对于常规的 amazon-ssm-agent systemd 单元，合并文档中给出的 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 目标。当允许 agent 为其公共 AWS 服务端点使用公共中转时，HTTP 代理列表可为这些 URL 提供候选；请保留 metadata 绕过。让 169.254.169.254 直连以获取实例 metadata；AWS 也为 IPv6 metadata 端点记录了 [fd00:ec2::254]。

改动后请重新加载 systemd 并重启真正的 agent 单元。Ubuntu snap 打包使用另一个单元/drop-in 位置，因此要与安装方式对应。

如果 agent 正常而组件的 curl 失败，请为该命令提供环境变量。小写的 http_proxy 对 curl 很关键；一次成功的 agent 事务并不能证明这些子请求的输入。

相关文章