Розмістіть проксі 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-проксі пропонує кандидатів для цих URL; збережіть обхід metadata. Залиште 169.254.169.254 напряму для метаданих екземпляра; AWS також документує [fd00:ec2::254] для кінцевої точки метаданих IPv6.
Після зміни перезавантажте systemd і перезапустіть фактичний юніт агента. Пакет Ubuntu snap використовує інше розташування юніта/drop-in, тому орієнтуйтеся на встановлення.
Якщо агент працює, а curl компонента збоїть, задайте середовище цієї команди. Малі літери http_proxy важливі для curl; успішна транзакція агента не підтверджує ці вхідні дані дочірнього запиту.