GitHub webhook'u özel Jenkins'e ulaşmıyor: yolu düzeltin

Jenkins'i VPN üzerinden açabilir ve yine de GitHub'ın başarısız bir webhook bildirdiğini görebilirsiniz, çünkü bunlar iki farklı sahibi olan iki farklı bağlantıdır. Tarayıcı dizüstünüzün müzakere ettiği bir tünelden geçer; GitHub'ın teslimat hizmeti genel internetten başlar ve özel ağa giden bir yolu yoktur. Depoya erişim bunu değiştirmez, Jenkins'in kendisi aynı depodan sorunsuz çekebilse bile. Bir giriş, bir aktarıcı veya yoklama seçin, sonra olayın gerçekten izlediği yolu test edin.

Tarayıcı oturumu yalnızca tek yönü kanıtlar

VPN bağlantısı tek bir soruyu yanıtlar: bu dizüstü iç sunucuya ulaşabilir mi. Webhook teslimatı başka bir şey sorar: harici bir hizmet o sunucuya bağlantı açabilir mi. Jenkins'in depodan çekmesi giden trafiktir ve gelen erişilebilirlik hakkında hiçbir şey söylemez. İki yönü diyagramınızda ayrı satırlarda tutun, her birini hangi tarafın başlattığı da dahil.

Herhangi bir şeyi değiştirmeden önce teslimat kaydını okuyun. Zaman aşımı, bağlantı sıfırlaması ve hiçbir işle eşleşmeyen kabul edilmiş bir istek üç farklı sahibe aittir: ağ, proxy ve tetikleyici yapılandırması.

Seçenek A: dar bir uç nokta açın

Kuruluş zaten onaylanmış bir giriş yayımlıyorsa, kontrol paneli yerine webhook yolunu açın. Bu genellikle kanca URL'sinde POST kabul eden ve bunları Jenkins'e ileten bir ters proxy kuralı anlamına gelir; yönetim arayüzü dışarıdan erişilemez kalır.

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

Bu testi VPN erişimi olmayan bir ağdan çalıştırın, çünkü tünelin içinden gelen başarı hiçbir şey kanıtlamaz. Uç nokta, GitHub'ın imza başlığı olarak gönderdiği ortak sırrı taşımayan istekleri reddetmeli ve yalnızca yayımladığınız tek yolu ve yöntemi kabul etmelidir. Herkese açık bir Jenkins konsolu webhook düzeltmesi değildir; bir sonraki tarayıcıyı bekleyen bir olaydır. Kuralı, uygulamanın geri kalanı önceki erişim denetimlerini koruyacak kadar dar tutun.

Seçenek B: yönü aktarıcıyla tersine çevirin

Gelen açıklığın onaylanmayacağı yerlerde, ağ içindeki küçük bir istemci bir aktarıcıya giden bağlantıyı açık tutabilir ve iletilen olayları alabilir. Aktarıcı o zaman teslimat yolunun parçası olur, bu yüzden kullanılabilirliği ve kimlik doğrulaması derleme işi kadar önemlidir.

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

Jenkins'in güvenlik duvarları arkasındaki webhook'lar hakkındaki rehberi bu biçimi açıklar ve kendi ileticinizi yazmadan önce okumaya değer. TLS'i aktarıcıda sonlandırın, olay işe ulaşmadan imzayı doğrulayın ve giden bağlantıyı izleyin, çünkü düşen bir tünel tam olarak hiç gönderilmemiş bir olay gibi görünür. Aktarıcının istek gövdesini bayt bayt koruduğunu da doğrulayın, çünkü imza kontrolleri yolda ayrıştırılıp yeniden kodlanan JSON'da başarısız olur.

Seçenek C: depoyu yoklayın

Yoklama gecikmeyi basitlikle değiştirir ve hiçbir gelen yola ihtiyaç duymaz. Jenkins bir zamanlamaya göre yoklayabilir veya küçük bir iş API'yi sorgulayıp tanımadığı bir revizyon gördüğünde derleme başlatabilir.

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

Her yoklama API çağrısı harcar ve push ile derleme arasına, yoğun depolarda ve paylaşılan hız sınırlarında görünen bir gecikme ekler. Ayrıca yoklayıcının çalıştığı her yerde saklanan kimlik bilgilerine ihtiyaç duyar, bu yüzden belirteci depoya yalnızca okuma erişimiyle sınırlayın ve başka herhangi bir sır gibi döndürün. Olay hacmi düşük olduğunda veya bir giriş asla onaylanmayacaksa bunu seçin ve derlemelerin neden geride kaldığını kimse merak etmesin diye iş açıklamasına yazın.

Sayfa yüklemesini değil, gerçek teslimatı kabul edin

Hangi seçeneği seçerseniz seçin, kabul testi kaynak platformun gönderdiği bir olaydır, ayrıcalıklı bir dizüstünden açılan tarayıcı sekmesi değildir. Taslak dala boş bir commit push edin ve teslimat yanıt kodunu, aktarıcı günlüğünü veya yoklama işinin çıktısını bu sırayla okuyun. Uç noktadan gelen 200 ve derleme yoksa tetikleyici filtresi yanlıştır; zaman aşımı yolu hâlâ kapalı demektir. Üç tasarımdan hangisinin kullanıldığını not edin, yoksa sonraki hata ayıklayıcı tarayıcı testini tekrarlar ve aynı çıkmaza varır.

Aynı mantığı ödeme geri çağırmalarına ve diğer dış bildirimlere uygulayın: her biri özel uygulamaya kendi yoluna ihtiyaç duyar, her insanın zaten bir VPN oturumu olmasına rağmen. Teslimat yolu uygulamanın tasarımına aittir, ağlarla ilgili bir dipnota değil.