SSM Agent ના પ્રોક્સીને તેની વાસ્તવિક systemd સેવા પર મૂકો
એજન્ટના drop-in અને metadata બાયપાસનો ઉપયોગ કરો, પછી તેની કનેક્ટિવિટીને Image Builder કમ્પોનન્ટની પોતાની curl વિનંતીથી અલગ કરો.
પહેલા નિષ્ફળ જતા પ્રેષકને ઓળખો: SSM Agent સંચાર કે Image Builder કમ્પોનન્ટની અંદર ડાઉનલોડ. SSH-shell એક્સપોર્ટ ચાલતા એજન્ટને અપડેટ કરતું નથી.
સામાન્ય 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 માટે મહત્વપૂર્ણ છે; સફળ એજન્ટ વ્યવહાર તે ચાઇલ્ડ-વિનંતી ઇનપુટ સ્થાપિત કરતો નથી.