Webhook GitHub tidak menjangkau Jenkins privat: perbaiki jalurnya

Anda bisa membuka Jenkins lewat VPN dan tetap melihat GitHub melaporkan webhook yang gagal, karena keduanya adalah dua koneksi berbeda dengan dua pemilik berbeda. Peramban menumpang terowongan yang dinegosiasikan laptop Anda; layanan pengiriman GitHub dimulai dari internet publik dan tidak punya rute ke jaringan privat. Akses ke repositori tidak mengubahnya, meskipun Jenkins sendiri dapat mengambil dari repositori yang sama tanpa masalah. Pilih titik masuk, relai, atau polling, lalu uji jalur yang benar-benar dilalui peristiwa.

Sesi peramban hanya membuktikan satu arah

Koneksi VPN menjawab satu pertanyaan: apakah laptop ini dapat menjangkau host internal. Pengiriman webhook menanyakan hal lain: apakah layanan eksternal dapat membuka koneksi ke host itu. Jenkins mengambil repositori adalah lalu lintas keluar dan tidak mengatakan apa pun tentang keterjangkauan masuk. Simpan kedua arah pada baris terpisah dalam diagram Anda, termasuk sisi mana yang memulai masing-masing.

Baca catatan pengiriman sebelum mengubah apa pun. Waktu tunggu habis, koneksi direset, dan permintaan diterima yang tidak cocok dengan pekerjaan mana pun memiliki tiga pemilik berbeda: jaringan, proksi, dan konfigurasi pemicu.

Opsi A: buka endpoint sempit

Jika organisasi sudah menerbitkan titik masuk yang disetujui, buka jalur webhook alih-alih dasbor. Biasanya itu berarti aturan proksi terbalik yang menerima POST pada URL kait dan meneruskannya ke Jenkins sementara antarmuka administrasi tetap tidak terjangkau dari luar.

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

Jalankan uji itu dari jaringan tanpa akses VPN, karena keberhasilan dari dalam terowongan tidak membuktikan apa pun. Endpoint harus menolak permintaan tanpa rahasia bersama, yang dikirim GitHub sebagai header tanda tangan, dan hanya menerima satu jalur serta metode yang Anda terbitkan. Konsol Jenkins publik bukan perbaikan webhook; itu insiden yang menunggu pemindai berikutnya. Batasi aturannya cukup ketat agar sisa aplikasi mempertahankan kontrol akses yang dimilikinya.

Opsi B: balik arah dengan relai

Di tempat pemaparan masuk tidak akan disetujui, klien kecil di dalam jaringan dapat mempertahankan koneksi keluar ke relai dan menerima peristiwa yang diteruskan. Relai kemudian menjadi bagian dari jalur pengiriman, jadi ketersediaan dan autentikasinya sama pentingnya dengan pekerjaan build.

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

Panduan Jenkins tentang webhook di balik firewall menjelaskan bentuk ini, dan layak dibaca sebelum menulis penerus sendiri. Akhiri TLS di relai, verifikasi tanda tangan sebelum peristiwa mencapai pekerjaan, dan pantau tautan keluar, karena terowongan yang putus terlihat persis seperti peristiwa yang tidak pernah dikirim. Pastikan juga relai mempertahankan isi permintaan byte demi byte, karena pemeriksaan tanda tangan gagal pada JSON yang telah diurai dan dikodekan ulang di jalan.

Opsi C: polling repositori saja

Polling menukar latensi dengan kesederhanaan dan tidak memerlukan jalur masuk sama sekali. Jenkins dapat polling sesuai jadwal, atau pekerjaan kecil dapat menanyakan API dan memulai build saat melihat revisi yang tidak dikenal.

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

Setiap polling menghabiskan panggilan API dan menambah jeda antara push dan build, yang terlihat pada repositori sibuk dan batas laju bersama. Polling juga memerlukan kredensial yang disimpan di mana pun poller berjalan, jadi batasi token ke akses baca-saja ke repositori dan putar seperti rahasia lain. Pilih ini ketika volume peristiwa rendah atau ketika titik masuk tidak akan pernah disetujui, dan tuliskan di deskripsi pekerjaan agar tidak ada yang bertanya-tanya mengapa build tertinggal.

Terima pengiriman nyata, bukan pemuatan halaman

Opsi mana pun yang Anda pilih, uji penerimaan adalah peristiwa yang dikirim platform sumber, bukan tab peramban yang dibuka dari laptop berhak istimewa. Dorong commit kosong ke cabang sementara dan baca kode respons pengiriman, log relai, atau keluaran pekerjaan polling, dalam urutan itu. 200 dari endpoint tanpa build berarti filter pemicu salah; waktu tunggu habis berarti jalur masih tertutup. Catat mana dari tiga desain yang dipakai, karena jika tidak, orang berikutnya yang men-debug akan mengulangi uji peramban dan sampai di jalan buntu yang sama.

Terapkan alasan yang sama pada callback pembayaran dan notifikasi luar lainnya: masing-masing memerlukan rutenya sendiri ke aplikasi privat, bahkan ketika setiap orang sudah memegang sesi VPN. Jalur pengiriman termasuk dalam desain aplikasi, bukan catatan kaki tentang jaringan.