Mengapa webhook GitHub tamat masa terhadap Jenkins di sebalik VPN

Halaman penghantaran menunjukkan tamat masa dan Jenkins tidak mencatat apa-apa, yang merupakan tanda sambungan yang tidak pernah tiba. GitHub menghantar webhook sebagai HTTP POST keluar dari infrastrukturnya sendiri ke payload URL yang anda konfigurasikan. VPN melindungi Jenkins dengan menolak tepat jenis sambungan itu. Tiada apa yang rosak pada kedua-dua belah. Masalahnya ialah arah permintaan.

Apa yang sebenarnya dicuba oleh penghantaran

GitHub menyelesaikan nama hos dalam payload URL dan menyambung kepadanya dari internet awam. Jika URL itu menunjuk ke alamat peribadi, atau ke nama yang hanya diselesaikan di dalam rangkaian anda, percubaan gagal sebelum sebarang permintaan dibuat. Jika ia menunjuk ke nama awam yang dibuang oleh tepi anda, percubaan itu tamat masa sebaliknya.

Perbezaan ini penting untuk diagnosis. Kegagalan DNS dan port yang ditapis kedua-duanya kelihatan seperti tiada apa berlaku di pihak Jenkins, dan kedua-duanya muncul di GitHub sebagai penghantaran gagal dengan sebab berbeza dilampirkan. Baca sebab itu sebelum anda menukar URL.

Terowong yang mendail ke luar tidak mencipta pendengar. Itulah bahagian yang orang jangkakan berfungsi secara berbeza.

Tiga cara untuk membetulkan arah sambungan

Setiap penyelesaian mengubah siapa yang memulakan sambungan, dan hanya ada tiga bentuk.

Pengundian ialah yang paling kurang elegan dan paling mudah dikendalikan. Relay mengekalkan maklum balas hampir serta-merta tanpa membuka port. Runner biasanya jawapan yang betul apabila kerahsiaan payload mengecualikan pihak ketiga, kerana kerja itu boleh berjalan pada mesin yang sudah berada di dalam rangkaian.

Pilih berdasarkan apa yang anda boleh kendalikan, bukan berdasarkan apa yang kedengaran moden.

Salurkan penghantaran ke luar dengan smee

Cipta saluran pada perkhidmatan relay dan simpan URLnya. Di dalam rangkaian, pasang klien dan teruskan penghantaran ke laluan yang dijangka oleh Jenkins. Payload URL dalam tetapan repositori menjadi URL saluran, dengan jenis kandungan ditetapkan kepada application/json.

sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080

Tiga butiran menentukan sama ada ia berfungsi. Laluan mesti sepadan dengan apa yang dijangka Jenkins untuk peristiwa GitHub, yang secara lalai ialah /github-webhook/. Jenkins mesti mendengar pada port yang anda berikan kepada klien. Dan Jenkins URL yang dikonfigurasikan dalam kerja mesti bersetuju dengan laluan itu, jika tidak peristiwa tiba dan kemudian dibuang.

Ketidakpadanan garis miring di hujung menghasilkan 404 yang dibaca seperti kegagalan penghantaran dan sebenarnya bukan.

Menjalankannya supaya ia bertahan seminggu

Klien di hadapan mati bersama terminal, dan webhook berfungsi sehari kemudian berhenti. Berikan ia unit dengan Restart=always, jalankannya sebagai pengguna Jenkins, dan baca journal selepas penghantaran sebenar pertama. Langkah terakhir itulah yang memisahkan relay yang berfungsi daripada yang dikonfigurasikan.

[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

Uji dengan push sebenar dan bukan butang main semula. Main semula melatih payload tersimpan relay, bukan laluan dari GitHub ke saluran anda, jadi ia boleh lulus walaupun penghantaran langsung masih gagal.

Berikan amaran apabila unit berhenti. Relay yang mati itu senyap secara binaan, dan kesenyapan itulah yang anda sudah nyahpepijat.

Apa yang relay boleh lihat, dan bila tidak menggunakannya

Relay menamatkan payload, jadi ia melihat nama repositori, data commit dan apa sahaja yang dibawa peristiwa. Layan URL saluran sebagai titik akhir awam. Kekalkan token rahsia Jenkins dikonfigurasikan supaya penghantaran palsu ditolak, dan hadkan token yang digunakan Jenkins kepada minimum yang diperlukan.

Jika kerahsiaan payload mengecualikan perkara itu, runner yang dihoskan sendiri atau terowong songsang yang disahkan ialah jawapannya.

Relay kini infrastruktur, dan ia wajar mendapat semakan yang sama seperti build yang dicetuskannya. Putar saluran jika ia bocor, dan catat tarikh anda kali terakhir mengesahkan penghantaran langsung. Letakkan tarikh itu dalam runbook di sebelah URL saluran. Relay yang tiada siapa semak selama setahun ialah titik akhir awam yang tiada siapa miliki.