განათავსეთ SSM Agent-ის პროქსი მის რეალურ systemd სერვისზე
გამოიყენეთ agent-ის drop-in და metadata-ის გვერდის ავლა, შემდეგ განასხვავეთ მისი კავშირი Image Builder კომპონენტის საკუთარი curl მოთხოვნისგან.
ჯერ დაადგინეთ წარუმატებელი გამომგზავნი: SSM Agent-ის კავშირი თუ ჩამოტვირთვა Image Builder კომპონენტის შიგნით. SSH shell-ით ექსპორტი არ აახლებს გაშვებულ agent-ს.
ჩვეულებრივი 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 დანიშნულებების გადატანა. როცა agent-ს შეუძლია საჯარო შუამავლის გამოყენება თავისი საჯარო AWS სერვისის ბოლო წერტილებისთვის, HTTP პროქსის სია გთავაზობთ კანდიდატებს ამ URL-ებისთვის; შეინარჩუნეთ metadata-ის გვერდის ავლა. დატოვეთ 169.254.169.254 პირდაპირ instance metadata-სთვის; AWS ასევე ადოკუმენტებს [fd00:ec2::254]-ს IPv6 metadata ბოლო წერტილისთვის.
ცვლილების შემდეგ გადატვირთეთ systemd და გადაუშვით agent-ის რეალური ერთეული. Ubuntu snap პაკეტირება იყენებს სხვა ერთეულის/drop-in-ის ადგილს, ამიტომ მოერგეთ ინსტალაციას.
თუ agent მუშაობს, მაგრამ კომპონენტის curl ვერ ხერხდება, მიაწოდეთ ამ ბრძანების გარემო. პატარა ასოები http_proxy მნიშვნელოვანია curl-ისთვის; წარმატებული agent ტრანზაქცია არ ადასტურებს ამ შვილობილი მოთხოვნის შეყვანებს.