VPN arkasındaki bir Jenkins’e karşı GitHub webhook’ları neden zaman aşımına uğrar
GitHub webhook’ları içeri doğru gönderir, bu yüzden Jenkins’i koruyan bir VPN onları reddeder. Teslimatı bir relay üzerinden dışarı aktarın veya webhook’u yoklayan bir agent ile değiştirin.
Teslimat sayfası bir zaman aşımı gösteriyor ve Jenkins hiçbir şey kaydetmiyor; bu, hiç ulaşmamış bir bağlantının imzasıdır. GitHub webhook’u kendi altyapısından yapılandırdığınız payload URL’sine giden bir HTTP POST olarak gönderir. Bir VPN, Jenkins’i tam olarak bu tür bağlantıyı reddederek korur. İki tarafta da bozuk bir şey yok. Sorun isteğin yönünde.
Teslimatın gerçekte denediği şey
GitHub, payload URL’sindeki ana bilgisayar adını çözer ve ona genel internetten bağlanır. Bu URL özel bir adrese veya yalnızca ağınızın içinde çözülen bir ada işaret ediyorsa, deneme herhangi bir istek yapılmadan önce başarısız olur. Kenarınızın düşürdüğü genel bir ada işaret ediyorsa, deneme bunun yerine zaman aşımına uğrar.
Bu ayrım tanı için önemlidir. DNS hatası ve filtrelenmiş bir port, ikisi de Jenkins tarafında hiçbir şey olmamış gibi görünür ve ikisi de GitHub’da farklı bir neden eklenmiş başarısız teslimat olarak görünür. URL’sini değiştirmeden önce o nedeni okuyun.
Dışarı doğru arayan bir tünel dinleyici oluşturmaz. İnsanların farklı çalışmasını beklediği kısım tam olarak burasıdır.
Bağlantının yönünü düzeltmenin üç yolu
Her çözüm bağlantıyı kimin başlattığını değiştirir ve yalnızca üç biçim vardır.
| 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 |
Yoklama en az zarif olan ve işletmesi en kolay olandır. Bir relay, bir port açmadan neredeyse anlık geri bildirim sağlar. Payload gizliliği üçüncü bir tarafı dışladığında runner genellikle doğru yanıttır, çünkü iş zaten ağın içinde duran bir makinede çalışabilir.
İşletebildiğinize göre seçin, modern kulağa gelene göre değil.
Bir teslimatı smee ile dışarı aktarın
Relay hizmetinde bir kanal oluşturun ve URL’sini saklayın. Ağın içinde istemciyi kurun ve teslimatları Jenkins’in beklediği yola iletin. Depo ayarlarındaki payload URL’si kanalın URL’si olur ve içerik türü application/json olarak ayarlanır.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Üç ayrıntı çalışıp çalışmayacağını belirler. Yol, Jenkins’in GitHub olayları için beklediğiyle eşleşmelidir, bu da varsayılan olarak /github-webhook/. Jenkins, istemciye verdiğiniz portu dinliyor olmalıdır. Ve işte yapılandırılmış Jenkins URL’si o yolla uyuşmalıdır, aksi halde olay gelir ve sonra atılır.
Sondaki eğik çizgi uyuşmazlığı, başarısız bir teslimat gibi okunan ve öyle olmayan bir 404 üretir.
Haftayı atlatacak şekilde çalıştırmak
Ön plandaki bir istemci terminalle birlikte ölür ve webhook’lar bir gün çalışıp sonra durur. Ona Restart=always içeren bir unit verin, Jenkins kullanıcısı olarak çalıştırın ve ilk gerçek teslimattan sonra journal’ı okuyun. İşte o son adım, çalışan bir relay’i yapılandırılmış olandan ayırır.
[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.targetYeniden oynat düğmesi yerine gerçek bir push ile test edin. Yeniden oynatma, relay’in sakladığı payload’ı çalıştırır, GitHub’dan kanalınıza giden yolu değil, bu yüzden canlı teslimat hâlâ başarısızken geçebilir.
Unit durduğunda uyarı verin. Çalışmayan bir relay yapısı gereği sessizdir ve sessizlik zaten ayıkladığınız şeydir.
Relay ne görebilir ve ne zaman kullanılmamalı
Bir relay payload’ı sonlandırır, bu yüzden depo adlarını, commit verilerini ve olayın taşıdığı her şeyi görür. Kanalın URL’sine genel bir uç nokta olarak davranın. Sahte teslimatların reddedilmesi için Jenkins’in gizli token’ını yapılandırılmış tutun ve Jenkins’in kullandığı token’ı gereken en aza sınırlayın.
Payload gizliliği bunu dışlıyorsa, kendi barındırdığınız bir runner veya kimlik doğrulamalı bir ters tünel yanıttır.
Relay artık bir altyapıdır ve tetiklediği build kadar aynı incelemeyi hak eder. Kanal sızarsa döndürün ve en son ne zaman canlı bir teslimatı doğruladığınız tarihi not edin. Bu tarihi kanalın URL’sinin yanına runbook’a koyun. Bir yıl boyunca kimsenin incelemediği bir relay, kimsenin sahip olmadığı genel bir uç noktadır.