GitHub ವೆಬ್ಹುಕ್ ಖಾಸಗಿ Jenkins ತಲುಪುತ್ತಿಲ್ಲ: ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸಿ

ನೀವು VPN ಮೂಲಕ Jenkins ತೆರೆಯಬಹುದು ಮತ್ತು ಆದರೂ GitHub ವಿಫಲ ವೆಬ್ಹುಕ್ ವರದಿ ಮಾಡುವುದನ್ನು ನೋಡಬಹುದು, ಏಕೆಂದರೆ ಇವು ಬೇರೆ ಬೇರೆ ಮಾಲೀಕರಿರುವ ಎರಡು ವಿಭಿನ್ನ ಸಂಪರ್ಕಗಳು. ಬ್ರೌಸರ್ ನಿಮ್ಮ ಲ್ಯಾಪ್ಟಾಪ್ ಮಾತುಕತೆ ನಡೆಸಿದ ಸುರಂಗದ ಮೂಲಕ ಸಾಗುತ್ತದೆ; GitHub ನ ವಿತರಣಾ ಸೇವೆ ಸಾರ್ವಜನಿಕ ಇಂಟರ್ನೆಟ್ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಖಾಸಗಿ ನೆಟ್ವರ್ಕ್ಗೆ ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ. ರೆಪೊಸಿಟರಿ ಪ್ರವೇಶ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ, Jenkins ಸ್ವತಃ ಅದೇ ರೆಪೊಸಿಟರಿಯಿಂದ ತೊಂದರೆಯಿಲ್ಲದೆ ಪಡೆಯಬಲ್ಲದಾದರೂ. ಒಂದು ಒಳಮುಖ, ರಿಲೇ ಅಥವಾ ಪೋಲಿಂಗ್ ಆಯ್ಕೆಮಾಡಿ, ನಂತರ ಈವೆಂಟ್ ನಿಜವಾಗಿ ಹೋಗುವ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಿ.

ಬ್ರೌಸರ್ ಸೆಶನ್ ಒಂದೇ ದಿಕ್ಕನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ

VPN ಸಂಪರ್ಕ ಒಂದು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಈ ಲ್ಯಾಪ್ಟಾಪ್ ಒಳಗಿನ ಹೋಸ್ಟ್ ತಲುಪಬಹುದೇ. ವೆಬ್ಹುಕ್ ವಿತರಣೆ ಬೇರೊಂದನ್ನು ಕೇಳುತ್ತದೆ: ಬಾಹ್ಯ ಸೇವೆ ಆ ಹೋಸ್ಟ್ಗೆ ಸಂಪರ್ಕ ತೆರೆಯಬಹುದೇ. Jenkins ರೆಪೊಸಿಟರಿ ಪಡೆಯುವುದು ಹೊರಹೋಗುವ ಸಂಚಾರ ಮತ್ತು ಒಳಬರುವ ತಲುಪುವಿಕೆಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ನಿಮ್ಮ ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಸಾಲುಗಳಲ್ಲಿ ಇರಿಸಿ, ಯಾವ ಬದಿ ಪ್ರತಿಯೊಂದನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಎಂಬುದೂ ಸೇರಿದಂತೆ.

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ವಿತರಣಾ ದಾಖಲೆಯನ್ನು ಓದಿ. ಸಮಯ ಮೀರುವಿಕೆ, ಸಂಪರ್ಕ ಮರುಹೊಂದಿಸುವಿಕೆ ಮತ್ತು ಯಾವುದೇ ಕೆಲಸಕ್ಕೆ ಹೊಂದದ ಸ್ವೀಕೃತ ವಿನಂತಿ ಇವುಗಳಿಗೆ ಮೂರು ಬೇರೆ ಬೇರೆ ಮಾಲೀಕರಿದ್ದಾರೆ: ನೆಟ್ವರ್ಕ್, ಪ್ರಾಕ್ಸಿ ಮತ್ತು ಟ್ರಿಗರ್ ಸಂರಚನೆ.

ಆಯ್ಕೆ A: ಸಣ್ಣ ಎಂಡ್ಪಾಯಿಂಟ್ ಬಹಿರಂಗಪಡಿಸಿ

ಸಂಸ್ಥೆ ಈಗಾಗಲೇ ಅನುಮೋದಿತ ಒಳಮುಖವನ್ನು ಪ್ರಕಟಿಸಿದ್ದರೆ, ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಬದಲು ವೆಬ್ಹುಕ್ ಮಾರ್ಗವನ್ನು ಬಹಿರಂಗಪಡಿಸಿ. ಸಾಮಾನ್ಯವಾಗಿ ಇದು ಹುಕ್ URL ನಲ್ಲಿ POST ಸ್ವೀಕರಿಸಿ ಅವನ್ನು Jenkins ಗೆ ರವಾನಿಸುವ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ನಿಯಮವನ್ನು ಅರ್ಥೈಸುತ್ತದೆ, ಆದರೆ ನಿರ್ವಹಣಾ ಇಂಟರ್ಫೇಸ್ ಹೊರಗಿನಿಂದ ತಲುಪಲಾಗದೇ ಇರುತ್ತದೆ.

curl -sS -o /dev/null -w "%{http_code}\n" -X POST https://jenkins.example.com/github-webhook/

ಆ ಪರೀಕ್ಷೆಯನ್ನು VPN ಪ್ರವೇಶವಿಲ್ಲದ ನೆಟ್ವರ್ಕ್ನಿಂದ ನಡೆಸಿ, ಏಕೆಂದರೆ ಸುರಂಗದ ಒಳಗಿನಿಂದ ಬರುವ ಯಶಸ್ಸು ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಎಂಡ್ಪಾಯಿಂಟ್ ಹಂಚಿದ ರಹಸ್ಯವಿಲ್ಲದ ವಿನಂತಿಗಳನ್ನು ತಿರಸ್ಕರಿಸಬೇಕು, ಅದನ್ನು GitHub ಸಹಿ ಹೆಡರ್ ಆಗಿ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ನೀವು ಪ್ರಕಟಿಸಿದ ಒಂದೇ ಮಾರ್ಗ ಮತ್ತು ವಿಧಾನವನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸಬೇಕು. ಸಾರ್ವಜನಿಕ Jenkins ಕನ್ಸೋಲ್ ವೆಬ್ಹುಕ್ ಪರಿಹಾರವಲ್ಲ; ಅದು ಮುಂದಿನ ಸ್ಕ್ಯಾನರ್ಗಾಗಿ ಕಾಯುತ್ತಿರುವ ಘಟನೆ. ಅಪ್ಲಿಕೇಶನ್ನ ಉಳಿದ ಭಾಗ ತನ್ನ ಹಿಂದಿನ ಪ್ರವೇಶ ನಿಯಂತ್ರಣಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವಂತೆ ನಿಯಮವನ್ನು ಸಾಕಷ್ಟು ಕಿರಿದಾಗಿಸಿ.

ಆಯ್ಕೆ B: ರಿಲೇ ಮೂಲಕ ದಿಕ್ಕನ್ನು ತಿರುಗಿಸಿ

ಒಳಮುಖ ಬಹಿರಂಗಪಡಿಸುವಿಕೆ ಅನುಮೋದನೆ ಆಗದ ಸಂದರ್ಭದಲ್ಲಿ, ನೆಟ್ವರ್ಕ್ ಒಳಗಿನ ಸಣ್ಣ ಕ್ಲೈಂಟ್ ರಿಲೇಗೆ ಹೊರಹೋಗುವ ಸಂಪರ್ಕವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಬಹುದು ಮತ್ತು ರವಾನಿಸಿದ ಈವೆಂಟ್ಗಳನ್ನು ಸ್ವೀಕರಿಸಬಹುದು. ಆಗ ರಿಲೇ ವಿತರಣಾ ಮಾರ್ಗದ ಭಾಗವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದರ ಲಭ್ಯತೆ ಮತ್ತು ದೃಢೀಕರಣವು ಬಿಲ್ಡ್ ಕೆಲಸದಷ್ಟೇ ಮುಖ್ಯ.

ssh -N -R 9000:localhost:8080 relay.example.net

ಫೈರ್ವಾಲ್ಗಳ ಹಿಂದಿನ ವೆಬ್ಹುಕ್ಗಳ ಕುರಿತು Jenkins ನ ಮಾರ್ಗದರ್ಶನ ಈ ರೂಪವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮದೇ ಫಾರ್ವರ್ಡರ್ ಬರೆಯುವ ಮೊದಲು ಅದನ್ನು ಓದುವುದು ಯೋಗ್ಯ. ರಿಲೇನಲ್ಲಿ TLS ಮುಗಿಸಿ, ಈವೆಂಟ್ ಕೆಲಸವನ್ನು ತಲುಪುವ ಮೊದಲು ಸಹಿಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಹೊರಹೋಗುವ ಕೊಂಡಿಯನ್ನು ಗಮನಿಸಿ, ಏಕೆಂದರೆ ಬಿದ್ದ ಸುರಂಗವು ಎಂದಿಗೂ ಕಳುಹಿಸದ ಈವೆಂಟ್ನಂತೆಯೇ ಕಾಣುತ್ತದೆ. ರಿಲೇ ವಿನಂತಿಯ ದೇಹವನ್ನು ಬೈಟ್ ಬೈಟ್ ಉಳಿಸುತ್ತದೆ ಎಂಬುದನ್ನೂ ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ದಾರಿಯಲ್ಲಿ ಪಾರ್ಸ್ ಮಾಡಿ ಮತ್ತೆ ಎನ್ಕೋಡ್ ಮಾಡಿದ JSON ನಲ್ಲಿ ಸಹಿ ಪರಿಶೀಲನೆಗಳು ವಿಫಲವಾಗುತ್ತವೆ.

ಆಯ್ಕೆ C: ಬದಲಾಗಿ ರೆಪೊಸಿಟರಿ ಪೋಲ್ ಮಾಡಿ

ಪೋಲಿಂಗ್ ವಿಳಂಬವನ್ನು ಸರಳತೆಗೆ ಬದಲಿಸುತ್ತದೆ ಮತ್ತು ಒಳಬರುವ ಮಾರ್ಗವನ್ನು ಬೇಕೆಂದೇ ಬಯಸುವುದಿಲ್ಲ. Jenkins ವೇಳಾಪಟ್ಟಿಯಂತೆ ಪೋಲ್ ಮಾಡಬಹುದು, ಅಥವಾ ಸಣ್ಣ ಕೆಲಸವು API ಗೆ ಕೇಳಿ ಅಪರಿಚಿತ ಮರುಪರಿಷ್ಕರಣೆ ಕಂಡಾಗ ಬಿಲ್ಡ್ ಪ್ರಾರಂಭಿಸಬಹುದು.

curl -sS -u "$USER:$TOKEN" "https://api.github.com/repos/OWNER/REPO/commits?per_page=1"

ಪ್ರತಿ ಪೋಲ್ API ಕರೆಗಳನ್ನು ಖರ್ಚು ಮಾಡುತ್ತದೆ ಮತ್ತು push ಹಾಗೂ ಬಿಲ್ಡ್ ನಡುವೆ ವಿಳಂಬ ಸೇರಿಸುತ್ತದೆ, ಇದು ನಿರತ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ ಮತ್ತು ಹಂಚಿದ ದರ ಮಿತಿಗಳಲ್ಲಿ ಕಾಣುತ್ತದೆ. ಪೋಲರ್ ಚಾಲನೆಯಾಗುವಲ್ಲಿ ಸಂಗ್ರಹಿಸಿದ ರುಜುವಾತುಗಳೂ ಬೇಕು, ಆದ್ದರಿಂದ ಟೋಕನ್ ಅನ್ನು ರೆಪೊಸಿಟರಿಗೆ ಓದಲು ಮಾತ್ರದ ಪ್ರವೇಶಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸಿ ಮತ್ತು ಬೇರೆ ಯಾವುದೇ ರಹಸ್ಯದಂತೆ ಅದನ್ನು ತಿರುಗಿಸಿ. ಈವೆಂಟ್ ಪ್ರಮಾಣ ಕಡಿಮೆ ಇದ್ದಾಗ ಅಥವಾ ಒಳಮುಖ ಎಂದಿಗೂ ಅನುಮೋದನೆ ಆಗದಿದ್ದಾಗ ಇದನ್ನು ಆಯ್ಕೆಮಾಡಿ, ಮತ್ತು ಬಿಲ್ಡ್ಗಳು ಏಕೆ ಹಿಂದೆ ಬೀಳುತ್ತವೆ ಎಂದು ನಂತರ ಯಾರೂ ಆಶ್ಚರ್ಯಪಡದಂತೆ ಕೆಲಸದ ವಿವರಣೆಯಲ್ಲಿ ಅದನ್ನು ಹೇಳಿ.

ಪುಟ ಲೋಡ್ ಅಲ್ಲ, ನಿಜವಾದ ವಿತರಣೆಯನ್ನು ಸ್ವೀಕರಿಸಿ

ನೀವು ಯಾವ ಆಯ್ಕೆ ತೆಗೆದುಕೊಂಡರೂ, ಸ್ವೀಕಾರ ಪರೀಕ್ಷೆ ಎಂಬುದು ಮೂಲ ವೇದಿಕೆ ಕಳುಹಿಸಿದ ಈವೆಂಟ್, ವಿಶೇಷಾಧಿಕಾರದ ಲ್ಯಾಪ್ಟಾಪ್ನಿಂದ ತೆರೆದ ಬ್ರೌಸರ್ ಟ್ಯಾಬ್ ಅಲ್ಲ. ಸ್ಕ್ರ್ಯಾಚ್ ಶಾಖೆಗೆ ಖಾಲಿ commit push ಮಾಡಿ ಮತ್ತು ವಿತರಣಾ ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್, ರಿಲೇ ಲಾಗ್ ಅಥವಾ ಪೋಲಿಂಗ್ ಕೆಲಸದ ಔಟ್ಪುಟ್ ಅನ್ನು ಆ ಕ್ರಮದಲ್ಲಿ ಓದಿ. ಎಂಡ್ಪಾಯಿಂಟ್ನಿಂದ 200 ಬಂದು ಬಿಲ್ಡ್ ಇಲ್ಲದಿದ್ದರೆ ಟ್ರಿಗರ್ ಫಿಲ್ಟರ್ ತಪ್ಪು; ಸಮಯ ಮೀರಿದರೆ ಮಾರ್ಗ ಇನ್ನೂ ಮುಚ್ಚಿದೆ. ಮೂರು ವಿನ್ಯಾಸಗಳಲ್ಲಿ ಯಾವುದು ಬಳಕೆಯಲ್ಲಿದೆ ಎಂದು ದಾಖಲಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದೆ ಡೀಬಗ್ ಮಾಡುವವರು ಬ್ರೌಸರ್ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ ಅದೇ ಬಿಕ್ಕಟ್ಟಿಗೆ ಸಿಲುಕುತ್ತಾರೆ.

ಪಾವತಿ ಕಾಲ್ಬ್ಯಾಕ್ಗಳು ಮತ್ತು ಇತರ ಬಾಹ್ಯ ಅಧಿಸೂಚನೆಗಳಿಗೂ ಅದೇ ತರ್ಕವನ್ನು ಅನ್ವಯಿಸಿ: ಪ್ರತಿಯೊಂದಕ್ಕೂ ಖಾಸಗಿ ಅಪ್ಲಿಕೇಶನ್ಗೆ ತನ್ನದೇ ಮಾರ್ಗ ಬೇಕು, ಪ್ರತಿ ವ್ಯಕ್ತಿಯು ಈಗಾಗಲೇ VPN ಸೆಶನ್ ಹೊಂದಿದ್ದರೂ. ವಿತರಣಾ ಮಾರ್ಗವು ಅಪ್ಲಿಕೇಶನ್ನ ವಿನ್ಯಾಸಕ್ಕೆ ಸೇರಿದ್ದು, ನೆಟ್ವರ್ಕಿಂಗ್ ಪಾದಟಿಪ್ಪಣಿಗೆ ಅಲ್ಲ.