Nukreipkite SSM Agent tarpinį serverį į tikrąją jo systemd paslaugą
Naudokite agento drop-in failą ir metadata apėjimą, tada atskirkite jo ryšį nuo Image Builder komponento curl užklausos.
Pirmiausia nustatykite, kas nepavyksta: SSM Agent ryšys ar atsisiuntimas Image Builder komponento viduje. Eksportas per SSH apvalkalą neatnaujina veikiančio agento.
Įprastam amazon-ssm-agent systemd įrenginiui sujunkite dokumentuotą drop-in failą, esantį /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 galinis taškas gali perduoti HTTPS paskirties vietas. Kai agentui leidžiama naudoti viešą tarpininką savo viešiems AWS paslaugų galiniams taškams, HTTP tarpinių serverių sąrašas siūlo kandidatus šiems URL; išsaugokite metadata apėjimą. Palikite 169.254.169.254 tiesiogiai instance metadata; AWS taip pat dokumentuoja [fd00:ec2::254] IPv6 metadata galiniam taškui.
Po pakeitimo iš naujo įkelkite systemd ir paleiskite tikrąjį agento įrenginį. Ubuntu snap paketas naudoja kitą įrenginio/drop-in vietą, todėl prisitaikykite prie diegimo.
Jei agentas veikia, bet komponento curl nepavyksta, pateikite tos komandos aplinką. Mažosios raidės http_proxy curl yra svarbios; sėkminga agento transakcija neįrodo tų antrinės užklausos įvesties duomenų.