ضع وسيط 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 العامة، توفّر قائمة وسطاء HTTP مرشّحين لهذه العناوين؛ حافظ على تجاوز metadata. أبقِ 169.254.169.254 مباشرًا لبيانات instance الوصفية؛ وتوثّق AWS أيضًا [fd00:ec2::254] لنقطة نهاية metadata عبر IPv6.
أعد تحميل systemd وأعد تشغيل وحدة الوكيل الفعلية بعد التغيير. تستخدم حزمة Ubuntu snap موقع وحدة/drop-in آخر، فطابقه مع التثبيت.
إذا عمل الوكيل وفشل curl الخاص بالمكوّن، فوفّر بيئة ذلك الأمر. الأحرف الصغيرة http_proxy مهمة لـ curl؛ ومعاملة وكيل ناجحة لا تثبت تلك المدخلات الخاصة بالطلب الفرعي.