ដាក់ប្រូកស៊ីរបស់ SSM Agent នៅលើសេវា systemd ពិតប្រាកដរបស់វា
ប្រើ drop-in របស់ agent និងការរំលង metadata បន្ទាប់មកបែងចែកការតភ្ជាប់របស់វាពីសំណើ curl របស់សមាសភាគ Image Builder។
ដំបូងកំណត់អ្នកផ្ញើដែលបរាជ័យ៖ ការទំនាក់ទំនងរបស់ SSM Agent ឬការទាញយកនៅក្នុងសមាសភាគ Image Builder។ ការនាំចេញតាម shell SSH មិនធ្វើបច្ចុប្បន្នភាព agent ដែលកំពុងដំណើរការទេ។
សម្រាប់ឯកតា systemd ធម្មតា amazon-ssm-agent បញ្ចូល 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។ នៅពេល agent អាចប្រើអ្នកកណ្តាលសាធារណៈសម្រាប់ចំណុចបញ្ចប់សេវា AWS សាធារណៈរបស់វា បញ្ជីប្រូកស៊ី HTTP ផ្តល់បេក្ខជនសម្រាប់ URL ទាំងនេះ; រក្សាការរំលង metadata។ ទុក 169.254.169.254 ដោយផ្ទាល់សម្រាប់ metadata នៃ instance; AWS ក៏ចងក្រង [fd00:ec2::254] សម្រាប់ចំណុចបញ្ចប់ metadata IPv6 ផងដែរ។
ផ្ទុក systemd ឡើងវិញ និងចាប់ផ្តើមឯកតា agent ពិតប្រាកដឡើងវិញ បន្ទាប់ពីការផ្លាស់ប្តូរ។ ការវេចខ្ចប់ snap របស់ Ubuntu ប្រើទីតាំងឯកតា/drop-in ផ្សេង ដូច្នេះត្រូវផ្គូផ្គងនឹងការដំឡើង។
ប្រសិនបើ agent ដំណើរការ ប៉ុន្តែ curl របស់សមាសភាគបរាជ័យ សូមផ្តល់បរិស្ថាននៃពាក្យបញ្ជានោះ។ អក្សរតូច http_proxy សំខាន់សម្រាប់ curl; ប្រតិបត្តិការ agent ជោគជ័យមិនបញ្ជាក់ធាតុបញ្ចូលសំណើកូនទាំងនោះទេ។