Տեղադրեք SSM Agent-ի proxy-ն իր իրական systemd ծառայության վրա
Օգտագործեք agent-ի drop-in-ը և metadata-ի շրջանցումը, ապա տարբերեք նրա կապը Image Builder բաղադրիչի սեփական curl հարցումից։
Նախ որոշեք ձախողվող ուղարկողին՝ SSM Agent-ի հաղորդակցությունը, թե Image Builder բաղադրիչի ներսում ներբեռնումը։ SSH shell-ով արտահանումը չի թարմացնում աշխատող agent-ը։
Սովորական amazon-ssm-agent systemd միավորի համար միավորեք փաստաթղթավորված 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 նպատակակետեր։ Երբ agent-ին թույլատրվում է օգտագործել հանրային միջնորդ իր հանրային AWS ծառայության վերջնակետերի համար, HTTP proxy ցանկը առաջարկում է թեկնածուներ այս URL-ների համար. պահպանեք metadata-ի շրջանցումը։ Թողեք 169.254.169.254-ը ուղիղ instance metadata-ի համար. AWS-ը նաև փաստաթղթավորում է [fd00:ec2::254]-ը IPv6 metadata վերջնակետի համար։
Փոփոխությունից հետո վերաբեռնեք systemd-ը և վերագործարկեք agent-ի իրական միավորը։ Ubuntu snap փաթեթավորումը օգտագործում է այլ միավոր/drop-in տեղակայում, ուստի համապատասխանեցրեք տեղադրմանը։
Եթե agent-ը աշխատում է, բայց բաղադրիչի curl-ը ձախողվում է, տրամադրեք այդ հրամանի միջավայրը։ Փոքրատառ http_proxy-ը կարևոր է curl-ի համար. հաջող agent գործարքը չի հաստատում այդ ենթահարցման մուտքերը։