GitHub-ის webhook პირად Jenkins-ს არ აღწევს: გაასწორეთ გზა

შეგიძლიათ გახსნათ Jenkins VPN-ის მეშვეობით და მაინც დაინახოთ, რომ GitHub წარუმატებელ webhook-ს აცნობებს, რადგან ეს ორი სხვადასხვა კავშირია ორი სხვადასხვა მფლობელით. ბრაუზერი გადის გვირაბში, რომელიც თქვენმა ლეპტოპმა მოილაპარაკა; GitHub-ის მიწოდების სერვისი საჯარო ინტერნეტიდან იწყება და კერძო ქსელში გზა არ აქვს. საცავზე წვდომა ამას არ ცვლის, თუმცა თავად Jenkins შეიძლება იმავე საცავიდან უპრობლემოდ იღებდეს. აირჩიეთ შესვლის წერტილი, რელე ან გამოკითხვა და შემდეგ შეამოწმეთ გზა, რომლითაც მოვლენა რეალურად მიდის.

ბრაუზერის სესია მხოლოდ ერთ მიმართულებას ამტკიცებს

VPN კავშირი ერთ კითხვას პასუხობს: შეუძლია ამ ლეპტოპს შიდა ჰოსტამდე მისვლა. webhook-ის მიწოდება სხვას კითხულობს: შეუძლია გარე სერვისს ამ ჰოსტთან კავშირის გახსნა. ის, რომ Jenkins საცავიდან იღებს, გამავალი ტრაფიკია და შემავალი ხელმისაწვდომობის შესახებ არაფერს ამბობს. შეინახეთ ორივე მიმართულება თქვენი დიაგრამის ცალკეულ ხაზებზე, მათ შორის რომელი მხარე იწყებს თითოეულს.

წაიკითხეთ მიწოდების ჩანაწერი, სანამ რამეს შეცვლით. დროის ამოწურვა, კავშირის გადატვირთვა და მიღებული მოთხოვნა, რომელიც არცერთ სამუშაოს არ დაემთხვა, სამ სხვადასხვა მფლობელს აქვს: ქსელი, პროქსი და ტრიგერის კონფიგურაცია.

ვარიანტი A: გახსენით ვიწრო ბოლო წერტილი

თუ ორგანიზაცია უკვე აქვეყნებს დამტკიცებულ შესასვლელს, გახსენით webhook-ის გზა დაფის ნაცვლად. ეს ჩვეულებრივ ნიშნავს უკუპროქსის წესს, რომელიც hook-ის URL-ზე POST-ებს იღებს და მათ Jenkins-ში გადასცემს, ხოლო ადმინისტრირების ინტერფეისი გარედან მიუწვდომელი რჩება.

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

ჩაატარეთ ეს ტესტი VPN წვდომის გარეშე ქსელიდან, რადგან გვირაბის შიგნიდან წარმატება არაფერს ამტკიცებს. ბოლო წერტილმა უნდა უარყოს საერთო საიდუმლოს გარეშე მოთხოვნები, რომელსაც GitHub ხელმოწერის სათაურად აგზავნის, და მიიღოს მხოლოდ ის ერთი გზა და მეთოდი, რომელიც თქვენ გამოაქვეყნეთ. საჯარო Jenkins-ის კონსოლი webhook-ის გამოსწორება არ არის; ეს ინციდენტია, რომელიც შემდეგ სკანერს ელოდება. შემოზღუდეთ წესი საკმარისად ვიწროდ, რომ აპლიკაციის დარჩენილმა ნაწილმა შეინარჩუნოს ადრინდელი წვდომის კონტროლი.

ვარიანტი B: გადააბრუნეთ მიმართულება რელეთი

სადაც შემავალი გახსნა არ დამტკიცდება, ქსელის შიგნით მცირე კლიენტს შეუძლია რელესთან გამავალი კავშირი შეინარჩუნოს და გადაცემული მოვლენები მიიღოს. რელე მაშინ მიწოდების გზის ნაწილი ხდება, ამიტომ მისი ხელმისაწვდომობა და ავთენტიფიკაცია ისევე მნიშვნელოვანია, როგორც build-ის სამუშაო.

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

Jenkins-ის სახელმძღვანელო firewall-ების უკან webhook-ების შესახებ აღწერს ამ ფორმას და ღირს მისი წაკითხვა სანამ საკუთარ გადამცემს დაწერთ. დაასრულეთ TLS რელეზე, გადაამოწმეთ ხელმოწერა სანამ მოვლენა სამუშაოს მიაღწევს, და აკონტროლეთ გამავალი კავშირი, რადგან ჩამოვარდნილი გვირაბი ზუსტად ისე გამოიყურება, როგორც არასდროს გაგზავნილი მოვლენა. ასევე დაადასტურეთ, რომ რელე ინახავს მოთხოვნის სხეულს ბაიტი ბაიტად, რადგან ხელმოწერის შემოწმებები ვარდება JSON-ზე, რომელიც გზაში დაიშალა და ხელახლა დაიკოდა.

ვარიანტი C: სამაგიეროდ გამოკითხეთ საცავი

გამოკითხვა დაყოვნებას უცვლის სიმარტივეს და საერთოდ არ საჭიროებს შემავალ გზას. Jenkins-ს შეუძლია გრაფიკით გამოკითხვა, ან პატარა სამუშაოს შეუძლია API-ს ჰკითხოს და build დაიწყოს, როცა უცნობ რევიზიას დაინახავს.

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

ყოველი გამოკითხვა ხარჯავს API-ის გამოძახებებს და ამატებს შეყოვნებას push-სა და build-ს შორის, რაც თვალსაჩინო ხდება დატვირთულ საცავებზე და საერთო სიჩქარის ლიმიტებზე. მას ასევე სჭირდება სერტიფიკატები, რომლებიც ინახება იქ, სადაც გამომკითხავი მუშაობს, ამიტომ შეზღუდეთ ტოკენი საცავზე მხოლოდ კითხვის წვდომით და ბრუნეთ ისე, როგორც ნებისმიერი სხვა საიდუმლო. აირჩიეთ ეს, როცა მოვლენების მოცულობა დაბალია ან როცა შესვლის წერტილი არასდროს არ დამტკიცდება, და თქვით ეს სამუშაოს აღწერაში, რომ მოგვიანებით არავის გაუკვირდეს, რატომ ჩამორჩება build-ები.

მიიღეთ ნამდვილი მიწოდება, და არა გვერდის ჩატვირთვა

რომელი ვარიანტიც არ უნდა აირჩიოთ, მიღების ტესტი არის წყაროს პლატფორმის მიერ გაგზავნილი მოვლენა და არა პრივილეგირებული ლეპტოპიდან გახსნილი ბრაუზერის ჩანართი. გაგზავნეთ ცარიელი commit სკრეჩ ტოტში და წაიკითხეთ მიწოდების პასუხის კოდი, რელეს ჟურნალი ან გამოკითხვის სამუშაოს გამოსავალი, სწორედ ამ თანმიმდევრობით. 200 ბოლო წერტილიდან build-ის გარეშე ნიშნავს, რომ ტრიგერის ფილტრი არასწორია; დროის ამოწურვა ნიშნავს, რომ გზა ჯერ კიდევ დახურულია. ჩაწერეთ, სამი დიზაინიდან რომელი გამოიყენება, თორემ შემდეგი გამმართავი გაიმეორებს ბრაუზერის ტესტს და იმავე ჩიხში მოხვდება.

გამოიყენეთ იგივე ლოგიკა გადახდების უკუგამოძახებებზე და სხვა გარე შეტყობინებებზე: თითოეულს სჭირდება საკუთარი გზა კერძო აპლიკაციაში, მაშინაც კი, როცა ყველა ადამიანს უკვე აქვს VPN სესია. მიწოდების გზა აპლიკაციის დიზაინს ეკუთვნის და არა ქსელების შესახებ ქვედა ნიშანს.