Zet de proxy van SSM Agent op de werkelijke systemd-service
Gebruik de drop-in van de agent en de metadata-omzeiling en onderscheid daarna de verbinding van de eigen curl-aanvraag van een Image Builder-component.
Bepaal eerst welke afzender faalt: de communicatie van SSM Agent of een download binnen de Image Builder-component. Een export via een SSH-shell werkt de draaiende agent niet bij.
Voor de gewone amazon-ssm-agent systemd-unit voegt u de gedocumenteerde drop-in samen 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"Het HTTP-eindpunt kan HTTPS-bestemmingen vervoeren. Wanneer de agent een openbare tussenpartij mag gebruiken voor zijn openbare AWS-service-eindpunten, levert de HTTP-proxylijst kandidaten voor deze URL's; behoud de metadata-omzeiling. Houd 169.254.169.254 rechtstreeks voor instance-metadata; AWS documenteert ook [fd00:ec2::254] voor het IPv6-metadata-eindpunt.
Herlaad systemd en herstart de werkelijke agent-unit na de wijziging. De Ubuntu snap-pakkettering gebruikt een andere unit-/drop-in-locatie, dus sluit aan bij de installatie.
Als de agent werkt maar de curl van de component faalt, geef dan de omgeving van dat commando mee. Kleine letters http_proxy zijn belangrijk voor curl; een geslaagde agenttransactie bewijst die invoer van de onderliggende aanvraag niet.