SSM Agent ನ proxy ಅನ್ನು ಅದರ ನಿಜವಾದ systemd ಸೇವೆಗೆ ಇರಿಸಿ
ಏಜೆಂಟ್‌ನ drop-in ಮತ್ತು metadata ಬೈಪಾಸ್ ಬಳಸಿ, ನಂತರ ಅದರ ಸಂಪರ್ಕವನ್ನು Image Builder ಘಟಕದ ಸ್ವಂತ curl ವಿನಂತಿಯಿಂದ ಬೇರ್ಪಡಿಸಿ.
ಮೊದಲು ವಿಫಲವಾಗುವ ಕಳುಹಿಸುವವರನ್ನು ಗುರುತಿಸಿ: SSM Agent ಸಂವಹನ ಅಥವಾ Image Builder ಘಟಕದ ಒಳಗಿನ ಡೌನ್‌ಲೋಡ್. SSH-shell ರಫ್ತು ಚಾಲನೆಯಲ್ಲಿರುವ ಏಜೆಂಟ್ ಅನ್ನು ನವೀಕರಿಸುವುದಿಲ್ಲ.
ಸಾಮಾನ್ಯ 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 ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಸಾಗಿಸಬಹುದು. ಏಜೆಂಟ್ ತನ್ನ ಸಾರ್ವಜನಿಕ AWS ಸೇವಾ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳಿಗೆ ಸಾರ್ವಜನಿಕ ಮಧ್ಯವರ್ತಿಯನ್ನು ಬಳಸಲು ಅನುಮತಿಸಿದಾಗ, HTTP ಪ್ರಾಕ್ಸಿ ಪಟ್ಟಿ ಈ URL ಗಳಿಗೆ ಅಭ್ಯರ್ಥಿಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ; metadata ಬೈಪಾಸ್ ಉಳಿಸಿಕೊಳ್ಳಿ. instance metadata ಗಾಗಿ 169.254.169.254 ನೇರವಾಗಿ ಇರಿಸಿ; AWS IPv6 metadata ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಾಗಿ [fd00:ec2::254] ಅನ್ನೂ ದಾಖಲಿಸುತ್ತದೆ.
ಬದಲಾವಣೆಯ ನಂತರ systemd ಮರುಲೋಡ್ ಮಾಡಿ ಮತ್ತು ನಿಜವಾದ ಏಜೆಂಟ್ ಘಟಕವನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ. Ubuntu snap ಪ್ಯಾಕೇಜಿಂಗ್ ಬೇರೆ ಘಟಕ/drop-in ಸ್ಥಳವನ್ನು ಬಳಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸ್ಥಾಪನೆಗೆ ಹೊಂದಿಸಿ.
ಏಜೆಂಟ್ ಕೆಲಸ ಮಾಡಿದರೂ ಘಟಕದ curl ವಿಫಲವಾದರೆ, ಆ ಆದೇಶದ ಪರಿಸರವನ್ನು ಒದಗಿಸಿ. ಸಣ್ಣ ಅಕ್ಷರಗಳು http_proxy curl ಗೆ ಮುಖ್ಯ; ಯಶಸ್ವಿ ಏಜೆಂಟ್ ವಹಿವಾಟು ಆ ಚೈಲ್ಡ್-ವಿನಂತಿ ಇನ್‌ಪುಟ್‌ಗಳನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.