Webhook GitHub không tới được Jenkins nội bộ: sửa lại đường đi

Bạn có thể mở Jenkins qua VPN mà vẫn thấy GitHub báo webhook thất bại, vì đây là hai kết nối khác nhau với hai chủ sở hữu khác nhau. Trình duyệt đi qua đường hầm mà laptop của bạn đã thương lượng; dịch vụ giao hàng của GitHub bắt đầu từ internet công cộng và không có đường vào mạng riêng. Quyền truy cập kho mã không thay đổi điều đó, dù bản thân Jenkins có thể lấy từ chính kho mã ấy mà không gặp trở ngại. Hãy chọn một lối vào, một relay hoặc polling, rồi kiểm tra đường đi mà sự kiện thực sự đi qua.

Phiên trình duyệt chỉ chứng minh một chiều

Một kết nối VPN trả lời một câu hỏi: laptop này có tới được máy chủ nội bộ không. Việc giao webhook hỏi điều khác: một dịch vụ bên ngoài có mở được kết nối tới máy chủ đó không. Việc Jenkins lấy từ kho mã là lưu lượng đi ra và không nói gì về khả năng tiếp cận đi vào. Giữ cả hai chiều trên những dòng riêng trong sơ đồ, kể cả bên nào khởi tạo mỗi chiều.

Đọc bản ghi giao hàng trước khi thay đổi bất cứ thứ gì. Hết thời gian chờ, kết nối bị đặt lại và một yêu cầu được chấp nhận nhưng không khớp với công việc nào có ba chủ sở hữu khác nhau: mạng, proxy và cấu hình trình kích hoạt.

Tùy chọn A: mở một điểm cuối hẹp

Nếu tổ chức đã công bố một lối vào được phê duyệt, hãy mở đường của webhook thay vì bảng điều khiển. Thường thì điều đó nghĩa là một quy tắc proxy ngược chấp nhận POST tại URL của hook và chuyển tiếp chúng tới Jenkins, trong khi giao diện quản trị vẫn không thể truy cập từ bên ngoài.

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

Chạy thử nghiệm đó từ một mạng không có quyền truy cập VPN, vì thành công từ bên trong đường hầm không chứng minh điều gì. Điểm cuối nên từ chối các yêu cầu thiếu bí mật chia sẻ, thứ GitHub gửi dưới dạng tiêu đề chữ ký, và chỉ chấp nhận đúng một đường và một phương thức mà bạn đã công bố. Một bảng điều khiển Jenkins công khai không phải là cách sửa webhook; đó là sự cố đang chờ máy quét tiếp theo. Giới hạn quy tắc đủ chặt để phần còn lại của ứng dụng giữ nguyên các kiểm soát truy cập trước đây.

Tùy chọn B: đảo chiều bằng một relay

Ở nơi việc mở ra từ bên ngoài sẽ không được phê duyệt, một ứng dụng khách nhỏ bên trong mạng có thể giữ một kết nối đi ra tới relay và nhận các sự kiện được chuyển tiếp. Relay sau đó trở thành một phần của đường giao hàng, nên tính sẵn sàng và việc xác thực của nó quan trọng như công việc build.

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

Hướng dẫn của Jenkins về webhook sau tường lửa mô tả hình thức này, và đáng đọc trước khi viết bộ chuyển tiếp của riêng bạn. Kết thúc TLS tại relay, xác minh chữ ký trước khi sự kiện tới công việc, và theo dõi liên kết đi ra, vì một đường hầm bị rơi trông giống hệt một sự kiện chưa từng được gửi. Cũng hãy xác nhận rằng relay giữ nguyên phần thân yêu cầu theo từng byte, vì các kiểm tra chữ ký thất bại với JSON đã bị phân tích và mã hóa lại trên đường đi.

Tùy chọn C: polling kho mã

Polling đổi độ trễ lấy sự đơn giản và không cần bất kỳ đường vào nào. Jenkins có thể polling theo lịch, hoặc một công việc nhỏ có thể hỏi API và bắt đầu build khi thấy một bản sửa đổi lạ.

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

Mỗi lần polling tiêu tốn các lệnh gọi API và thêm độ trễ giữa push và build, điều này lộ ra trên các kho mã đông đúc và giới hạn tốc độ dùng chung. Nó cũng cần thông tin đăng nhập được lưu ở nơi bộ polling chạy, nên hãy giới hạn token ở quyền chỉ đọc kho mã và xoay vòng nó như mọi bí mật khác. Chọn cách này khi lưu lượng sự kiện thấp hoặc khi sẽ không bao giờ có lối vào nào được phê duyệt, và ghi điều đó trong mô tả công việc để sau này không ai thắc mắc vì sao build bị chậm.

Chấp nhận một lần giao hàng thật, không phải tải trang

Dù bạn chọn tùy chọn nào, bài kiểm tra chấp nhận là một sự kiện do nền tảng nguồn gửi, không phải một tab trình duyệt mở từ laptop có đặc quyền. Push một commit rỗng lên nhánh nháp và đọc mã phản hồi của lần giao hàng, nhật ký relay hoặc đầu ra của công việc polling, theo đúng thứ tự đó. Một 200 từ điểm cuối mà không có build nghĩa là bộ lọc trình kích hoạt sai; hết thời gian chờ nghĩa là đường vẫn đóng. Ghi lại thiết kế nào trong ba thiết kế đang được dùng, nếu không người tiếp theo gỡ lỗi sẽ lặp lại bài kiểm tra trình duyệt và đi vào đúng ngõ cụt đó.

Áp dụng lý lẽ tương tự cho callback thanh toán và các thông báo bên ngoài khác: mỗi thứ cần đường riêng vào ứng dụng riêng, ngay cả khi mọi người đã có phiên VPN. Đường giao hàng thuộc về thiết kế ứng dụng, không phải một chú thích về mạng.