Vì sao webhook GitHub hết thời gian chờ với Jenkins sau VPN
GitHub gửi webhook vào trong, nên VPN bảo vệ Jenkins từ chối chúng. Chuyển tiếp việc giao hàng ra ngoài qua relay, hoặc thay webhook bằng một agent thăm dò.
Trang giao hàng hiển thị hết thời gian chờ và Jenkins không ghi nhật ký gì, đó là dấu hiệu của một kết nối không bao giờ đến. GitHub gửi webhook dưới dạng HTTP POST đi ra từ hạ tầng của chính nó đến payload URL bạn đã cấu hình. VPN bảo vệ Jenkins bằng cách từ chối đúng loại kết nối đó. Không có gì hỏng ở cả hai phía. Vấn đề là hướng của yêu cầu.
Giao hàng thực sự cố gắng điều gì
GitHub phân giải tên máy chủ trong payload URL và kết nối tới nó từ internet công cộng. Nếu URL đó trỏ tới một địa chỉ riêng, hoặc tới một tên chỉ phân giải được bên trong mạng của bạn, nỗ lực thất bại trước khi bất kỳ yêu cầu nào được gửi. Nếu nó trỏ tới một tên công cộng mà biên của bạn loại bỏ, nỗ lực thay vào đó hết thời gian chờ.
Sự khác biệt này quan trọng cho chẩn đoán. Lỗi DNS và một cổng bị lọc đều trông như không có gì xảy ra ở phía Jenkins, và cả hai đều xuất hiện trên GitHub như một lần giao hàng thất bại với lý do khác nhau được đính kèm. Hãy đọc lý do đó trước khi thay đổi URL.
Một đường hầm quay số ra ngoài không tạo ra trình lắng nghe. Đó chính là phần mà mọi người mong đợi hoạt động khác đi.
Ba cách sửa hướng của kết nối
Mọi giải pháp đều thay đổi ai khởi tạo kết nối, và chỉ có ba hình dạng.
| 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 |
Thăm dò là cách kém thanh lịch nhất và dễ vận hành nhất. Một relay duy trì phản hồi gần như tức thì mà không mở cổng. Một runner thường là câu trả lời đúng khi tính bảo mật của payload loại trừ bên thứ ba, vì công việc có thể chạy trên một máy đã nằm trong mạng.
Chọn theo thứ bạn có thể vận hành, không phải theo thứ nghe có vẻ hiện đại.
Chuyển tiếp một lần giao hàng ra ngoài bằng smee
Tạo một kênh trên dịch vụ relay và giữ URL của nó. Bên trong mạng, cài đặt ứng dụng khách và chuyển tiếp các lần giao hàng tới đường dẫn mà Jenkins mong đợi. Payload URL trong cài đặt kho lưu trữ trở thành URL của kênh, với loại nội dung được đặt là application/json.
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Ba chi tiết quyết định liệu nó có hoạt động. Đường dẫn phải khớp với thứ Jenkins mong đợi cho các sự kiện GitHub, mà mặc định là /github-webhook/. Jenkins phải lắng nghe trên cổng bạn đã cấp cho ứng dụng khách. Và Jenkins URL được cấu hình trong công việc phải đồng ý với đường dẫn đó, nếu không sự kiện đến rồi bị loại bỏ.
Sự không khớp của dấu gạch chéo cuối tạo ra 404, đọc như một lần giao hàng thất bại và không phải vậy.
Chạy nó để tồn tại qua tuần
Một ứng dụng khách ở tiền cảnh chết cùng thiết bị đầu cuối, và các webhook hoạt động một ngày rồi dừng. Hãy cho nó một unit có Restart=always, chạy nó với tư cách người dùng Jenkins, và đọc journal sau lần giao hàng thật đầu tiên. Chính bước cuối đó phân biệt một relay đang hoạt động với một relay đã được cấu hình.
[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.targetKiểm tra bằng một push thật thay vì nút phát lại. Phát lại chỉ chạy payload đã lưu của relay, không phải đường đi từ GitHub tới kênh của bạn, nên nó có thể đạt trong khi giao hàng trực tiếp vẫn thất bại.
Cảnh báo khi unit dừng. Một relay đã chết là im lặng theo thiết kế, và sự im lặng chính là thứ bạn đang gỡ lỗi.
Relay có thể thấy gì, và khi nào không nên dùng
Một relay kết thúc payload, nên nó thấy tên kho lưu trữ, dữ liệu commit và mọi thứ khác mà sự kiện mang theo. Hãy coi URL của kênh như một điểm cuối công cộng. Giữ secret token của Jenkins được cấu hình để các lần giao hàng giả bị từ chối, và giới hạn token mà Jenkins dùng ở mức tối thiểu cần thiết.
Nếu tính bảo mật của payload loại trừ điều đó, một runner tự lưu trữ hoặc một đường hầm ngược có xác thực là câu trả lời.
Một relay giờ là hạ tầng, và nó xứng đáng được xem xét như build mà nó kích hoạt. Hãy xoay kênh nếu nó rò rỉ, và ghi lại ngày bạn xác minh lần cuối một lần giao hàng trực tiếp. Đặt ngày đó vào runbook bên cạnh URL của kênh. Một relay mà không ai xem xét trong một năm là một điểm cuối công cộng mà không ai sở hữu.