Den Proxy des SSM Agent im tatsächlichen systemd-Dienst setzen
Nutzen Sie das Drop-in des Agents und die Metadata-Umgehung und unterscheiden Sie dann seine Verbindung von der eigenen curl-Anfrage einer Image-Builder-Komponente.
Bestimmen Sie zuerst den fehlschlagenden Absender: die Kommunikation des SSM Agent oder einen Download innerhalb der Image-Builder-Komponente. Ein Export über eine SSH-Shell aktualisiert den laufenden Agent nicht.
Für die reguläre systemd-Unit amazon-ssm-agent fügen Sie das dokumentierte Drop-in unter /etc/systemd/system/amazon-ssm-agent.service.d/override.conf zusammen:
[Service]
Environment="http_proxy=http://proxy.example:8080"
Environment="https_proxy=http://proxy.example:8080"
Environment="no_proxy=169.254.169.254"Der HTTP-Endpunkt kann HTTPS-Ziele transportieren. Wenn der Agent für seine öffentlichen AWS-Service-Endpunkte einen öffentlichen Vermittler verwenden darf, liefert die HTTP-Proxy-Liste Kandidaten für diese URLs; die Metadata-Umgehung bleibt erhalten. Halten Sie 169.254.169.254 für Instanz-Metadaten direkt; AWS dokumentiert außerdem [fd00:ec2::254] für den IPv6-Metadata-Endpunkt.
Laden Sie systemd neu und starten Sie die tatsächliche Agent-Unit neu, nachdem Sie die Änderung vorgenommen haben. Die Ubuntu-Snap-Paketierung verwendet einen anderen Unit-/Drop-in-Ort, richten Sie sich daher nach der Installation.
Wenn der Agent funktioniert, aber curl in der Komponente fehlschlägt, stellen Sie die Umgebung dieses Befehls bereit. Kleingeschriebenes http_proxy ist für curl wichtig; eine erfolgreiche Agent-Transaktion belegt diese Eingaben der untergeordneten Anfrage nicht.