SSM Agent のプロキシを実際の systemd サービスに設定する
エージェントの drop-in と metadata バイパスを使い、その接続を Image Builder コンポーネント自身の curl リクエストと区別します。
まず失敗している送信元を特定します。SSM Agent の通信か、Image Builder コンポーネント内のダウンロードかです。SSH シェルでのエクスポートは実行中のエージェントを更新しません。
通常の 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 の宛先も運べます。エージェントが公開 AWS サービスエンドポイントに公開中継を使える場合、HTTP プロキシ一覧がこれらの URL の候補を提供します。metadata バイパスは維持してください。インスタンス metadata には 169.254.169.254 を直接使います。AWS は IPv6 metadata エンドポイント用に [fd00:ec2::254] も文書化しています。
変更後は systemd を再読み込みし、実際のエージェントユニットを再起動します。Ubuntu の snap パッケージは別のユニット/drop-in の場所を使うため、インストールに合わせてください。
エージェントは動くのにコンポーネントの curl が失敗する場合は、そのコマンドの環境を渡します。小文字の http_proxy は curl にとって重要です。エージェントの通信成功は、そうした子リクエストの入力が整っていることを示しません。