რატომ ეწურება GitHub-ის webhook-ებს დრო VPN-ის უკან მდგარ Jenkins-თან
GitHub webhook-ებს შიგნით იგზავნის, ამიტომ Jenkins-ის დამცავი VPN მათ უარყოფს. გაატარეთ მიწოდება გარეთ relay-ის მეშვეობით, ან შეცვალეთ webhook გამოკითხვის აგენტით.
მიწოდების გვერდი დროის ამოწურვას აჩვენებს და Jenkins არაფერს იწერს, რაც იმ კავშირის ნიშანია, რომელიც არასოდეს მოვიდა. GitHub webhook-ს აგზავნის როგორც გამავალ HTTP POST-ს საკუთარი ინფრასტრუქტურიდან თქვენ მიერ კონფიგურირებულ payload URL-ზე. VPN იცავს Jenkins-ს ზუსტად ასეთი ტიპის კავშირის უარყოფით. არც ერთ მხარეს არაფერია გატეხილი. პრობლემა მოთხოვნის მიმართულებაა.
რას ცდილობს მიწოდება სინამდვილეში
GitHub ამუშავებს payload URL-ში მოცემულ ჰოსტის სახელს და უკავშირდება მას საჯარო ინტერნეტიდან. თუ ეს URL კერძო მისამართზე მიუთითებს, ან ისეთ სახელზე, რომელიც მხოლოდ თქვენი ქსელის შიგნით იხსნება, მცდელობა მარცხდება ნებისმიერი მოთხოვნის გაგზავნამდე. თუ ის საჯარო სახელზე მიუთითებს, რომელსაც თქვენი კიდე ყრის, მცდელობა ნაცვლად დროში იწურება.
ეს განსხვავება დიაგნოსტიკისთვის მნიშვნელოვანია. DNS-ის უკმარისობა და გაფილტრული პორტი ორივე ისე გამოიყურება, თითქოს Jenkins-ის მხარეს არაფერი მომხდარა, და ორივე GitHub-ზე ჩნდება როგორც წარუმატებელი მიწოდება განსხვავებული მიზეზით. წაიკითხეთ ეს მიზეზი URL-ის შეცვლამდე.
გარეთ აკრეფილი გვირაბი მსმენელს არ ქმნის. სწორედ ამ ნაწილს ელოდებიან ადამიანები განსხვავებულად მუშაობას.
კავშირის მიმართულების გასწორების სამი გზა
ყოველი გადაწყვეტა ცვლის, თუ ვინ იწყებს კავშირს, და მხოლოდ სამი ფორმა არსებობს.
| Approach | Who initiates | What you give up |
|---|---|---|
| Relay service | An outbound client inside the network | A third party sees every payload |
| Reverse tunnel or ingress | The public edge, into a controlled listener | An inbound surface you must secure |
| Runner or polling | The agent, outbound to GitHub | Instant delivery, replaced by a schedule |
გამოკითხვა ყველაზე ნაკლებად დახვეწილი და ყველაზე მარტივი საოპერაციოდ არის. Relay ინარჩუნებს თითქმის მყისიერ კავშირს პორტის გახსნის გარეშე. Runner ჩვეულებრივ სწორი პასუხია, როცა payload-ის კონფიდენციალურობა მესამე მხარეს გამორიცხავს, რადგან სამუშაო შეიძლება გაეშვას მანქანაზე, რომელიც უკვე ქსელის შიგნითაა.
აირჩიეთ იმის მიხედვით, რისი ოპერირებაც შეგიძლიათ, და არა იმის მიხედვით, რაც თანამედროვედ ჟღერს.
გაატარეთ მიწოდება გარეთ smee-ით
შექმენით არხი relay სერვისზე და შეინახეთ მისი URL. ქსელის შიგნით დააინსტალირეთ კლიენტი და გადაამისამართეთ მიწოდებები იმ ბილიკზე, რომელსაც Jenkins ელოდება. რეპოზიტორიის პარამეტრებში payload URL ხდება არხის URL, ხოლო კონტენტის ტიპი დაყენებულია application/json-ზე.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080სამი დეტალი წყვეტს, იმუშავებს თუ არა. ბილიკი უნდა ემთხვეოდეს იმას, რასაც Jenkins GitHub-ის მოვლენებისთვის ელოდება, რაც ნაგულისხმევად /github-webhook/ არის. Jenkins უნდა უსმენდეს იმ პორტს, რომელიც კლიენტს მიეცით. და სამუშაოში კონფიგურირებული Jenkins URL უნდა შეესაბამებოდეს ამ ბილიკს, თორემ მოვლენა მოვა და შემდეგ გადაიყრება.
ბოლო დახრილი ხაზის შეუსაბამობა წარმოქმნის 404-ს, რომელიც მიწოდების წარუმატებლობად იკითხება და ასე არ არის.
გაშვება ისე, რომ კვირას გაუძლოს
წინა პლანზე მომუშავე კლიენტი ტერმინალთან ერთად კვდება, და webhook-ები დღე მუშაობს, შემდეგ ჩერდება. მიეცით მას unit Restart=always-ით, გაუშვით Jenkins მომხმარებლად და წაიკითხეთ journal პირველი რეალური მიწოდების შემდეგ. სწორედ ეს ბოლო ნაბიჯი გამოყოფს მომუშავე relay-ს კონფიგურირებულისგან.
[Unit]
Description=smee webhook relay
After=network.target
[Service]
Type=simple
Restart=always
RestartSec=2
User=jenkins
ExecStart=/usr/bin/smee -u CHANNEL_URL --path /github-webhook/ --port 8080
[Install]
WantedBy=multi-user.targetსცადეთ რეალური push-ით და არა გამეორების ღილაკით. გამეორება relay-ის შენახულ payload-ს ავარჯიშებს, და არა გზას GitHub-იდან თქვენს არხამდე, ამიტომ ის შეიძლება გაიაროს, სანამ ცოცხალი მიწოდება ჯერ კიდევ ვერ ახერხებს.
გააფრთხილეთ, როცა unit ჩერდება. გამორთული relay კონსტრუქციითვე ჩუმია, და სიჩუმე სწორედ ის არის, რასაც უკვე აშკარავებთ.
რისი დანახვა შეუძლია relay-ს და როდის არ გამოვიყენოთ ის
Relay ამთავრებს payload-ს, ამიტომ ხედავს რეპოზიტორიების სახელებს, commit-ის მონაცემებს და ყველაფერს, რასაც მოვლენა ატარებს. მოექეცით არხის URL-ს როგორც საჯარო ბოლო წერტილს. შეინახეთ Jenkins-ის საიდუმლო token კონფიგურირებული, რომ ყალბი მიწოდებები უარყოფილი იყოს, და შეზღუდეთ Jenkins-ის მიერ გამოყენებული token საჭირო მინიმუმამდე.
თუ payload-ის კონფიდენციალურობა ამას გამორიცხავს, თვითგანთავსებული runner ან აუთენტიფიცირებული უკუქცევითი გვირაბი არის პასუხი.
Relay ახლა ინფრასტრუქტურაა და იმსახურებს იმავე განხილვას, რასაც build, რომელსაც ის იწვევს. მოაბრუნეთ არხი, თუ გაჟონავს, და ჩაწერეთ თარიღი, როცა ბოლოს დაადასტურეთ ცოცხალი მიწოდება. ჩასვით ეს თარიღი runbook-ში არხის URL-ის გვერდით. Relay, რომელიც ერთი წელი არავის განუხილავს, საჯარო ბოლო წერტილია, რომელიც არავის ეკუთვნის.