Sit SSM Agent se proxy op sy werklike systemd-diens
Gebruik die agent se drop-in en metadata-omleiding, en onderskei dan sy verbinding van 'n Image Builder-komponent se eie curl-versoek.
Identifiseer eers die mislukte sender: SSM Agent-kommunikasie of 'n aflaai binne die Image Builder-komponent. 'n SSH-dop-uitvoer dateer nie die lopende agent op nie.
Vir die gewone amazon-ssm-agent systemd-eenheid, voeg die gedokumenteerde drop-in by /etc/systemd/system/amazon-ssm-agent.service.d/override.conf saam:
[Service]
Environment="http_proxy=http://proxy.example:8080"
Environment="https_proxy=http://proxy.example:8080"
Environment="no_proxy=169.254.169.254"Die HTTP-eindpunt kan HTTPS-bestemmings dra. Wanneer die agent 'n openbare tussenganger vir sy openbare AWS-diens-eindpunte mag gebruik, verskaf die HTTP-proxylys kandidate vir hierdie URL's; behou die metadata-omleiding. Hou 169.254.169.254 direk vir instansie-metadata; AWS dokumenteer ook [fd00:ec2::254] vir die IPv6-metadata-eindpunt.
Herlaai systemd en herbegin die werklike agent-eenheid ná die verandering. Ubuntu snap-verpakking gebruik 'n ander eenheid/drop-in-ligging, so pas by die installasie.
As die agent werk maar die komponent se curl misluk, voorsien daardie opdrag se omgewing. Kleinletters http_proxy maak saak vir curl; 'n suksesvolle agent-transaksie vestig nie daardie kindversoek-insette nie.