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에 중요합니다. 성공한 에이전트 트랜잭션은 그 자식 요청 입력을 보장하지 않습니다.