Weka proksi ya SSM Agent kwenye huduma yake halisi ya systemd
Tumia drop-in ya wakala na upitaji wa metadata, kisha tenganisha muunganisho wake na ombi la curl la sehemu ya Image Builder.
Kwanza tambua mtumaji anayeshindwa: mawasiliano ya SSM Agent au upakuaji ndani ya sehemu ya Image Builder. Kuhamisha kwa njia ya shell ya SSH hakuboresha wakala anayefanya kazi.
Kwa kitengo cha kawaida cha amazon-ssm-agent systemd, unganisha drop-in iliyoandikwa kwenye /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"Kituo cha mwisho cha HTTP kinaweza kubeba maeneo ya HTTPS. Wakati wakala anaruhusiwa kutumia mpatanishi wa umma kwa vituo vyake vya mwisho vya huduma ya AWS, orodha ya proksi za HTTP hutoa wagombea kwa URL hizi; hifadhi upitaji wa metadata. Weka 169.254.169.254 moja kwa moja kwa metadata ya instance; AWS pia huandika [fd00:ec2::254] kwa kituo cha mwisho cha metadata cha IPv6.
Pakia upya systemd na uanzishe upya kitengo halisi cha wakala baada ya mabadiliko. Ufungashaji wa snap wa Ubuntu hutumia eneo lingine la kitengo/drop-in, kwa hivyo linganisha na usakinishaji.
Ikiwa wakala anafanya kazi lakini curl ya sehemu inashindwa, toa mazingira ya amri hiyo. Herufi ndogo http_proxy ni muhimu kwa curl; muamala wa wakala uliofaulu hauthibitishi hizo pembejeo za ombi la mtoto.