הציבו את ה-proxy של SSM Agent בשירות ה-systemd האמיתי שלו
השתמשו ב-drop-in של הסוכן ובעקיפת ה-metadata, ואז הבדילו את הקישוריות שלו מבקשת ה-curl של רכיב Image Builder.
תחילה זהו את השולח שנכשל: תקשורת SSM Agent או הורדה בתוך רכיב Image Builder. ייצוא דרך מעטפת SSH אינו מעדכן את הסוכן הפועל.
עבור יחידת ה-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. כאשר הסוכן רשאי להשתמש במתווך ציבורי עבור נקודות הקצה הציבוריות של AWS, רשימת ה-proxy של HTTP מספקת מועמדים לכתובות ה-URL האלה; שמרו על עקיפת ה-metadata. השאירו את 169.254.169.254 ישירות עבור metadata של המופע; AWS מתעדת גם את [fd00:ec2::254] עבור נקודת הקצה של metadata ב-IPv6.
טענו מחדש את systemd והפעילו מחדש את יחידת הסוכן האמיתית לאחר השינוי. אריזת snap של אובונטו משתמשת במיקום יחידה/drop-in אחר, לכן התאימו להתקנה.
אם הסוכן עובד אך ה-curl של הרכיב נכשל, ספקו את הסביבה של אותה פקודה. אותיות קטנות http_proxy חשובות ל-curl; עסקת סוכן מוצלחת אינה מוכיחה את קלטי בקשת הבת האלה.