Хүргэлтийн хуудас хугацаа хэтэрснийг харуулж, Jenkins юу ч бүртгэхгүй байгаа нь хэзээ ч ирээгүй холболтын шинж юм. GitHub webhook-ыг өөрийн дэд бүтцээс таны тохируулсан payload URL руу гадагш HTTP POST хэлбэрээр илгээдэг. VPN нь яг ийм төрлийн холболтыг татгалзах замаар Jenkins-ийг хамгаалдаг. Аль ч талд ямар нэгэн зүйл эвдээгүй. Асуудал нь хүсэлтийн чиглэлд байна.

Хүргэлт үнэндээ юу хийхийг оролддог вэ

GitHub payload URL дахь хостын нэрийг шийдэж, нийтийн интернэтээс түүнтэй холбогддог. Хэрэв тэр URL хувийн хаяг руу, эсвэл зөвхөн таны сүлжээний дотор шийдэгддэг нэр рүү зааж байвал оролдлого ямар ч хүсэлт илгээхээс өмнө бүтэлгүйтдэг. Хэрэв таны ирмэг хаядаг нийтийн нэр рүү зааж байвал оролдлого оронд нь хугацаа хэтэрдэг.

Энэ ялгаа оношилгоонд чухал. DNS-ийн алдаа болон шүүсэн порт хоёулаа Jenkins-ийн талд юу ч болоогүй мэт харагдаж, хоёулаа GitHub дээр өөр шалтгаан хавсаргасан бүтэлгүй хүргэлт болж харагддаг. URL-ыг өөрчлөхөөс өмнө тэр шалтгааныг уншина уу.

Гадагш залгадаг туннель сонсогч үүсгэдэггүй. Хүмүүс өөрөөр ажиллана гэж хүлээдэг хэсэг нь яг энэ.

Холболтын чиглэлийг засах гурван арга

Шийдэл бүр холболтыг хэн эхлүүлэхийг өөрчилдөг бөгөөд ердөө гурван хэлбэр байна.

ApproachWho initiatesWhat you give up
Relay serviceAn outbound client inside the networkA third party sees every payload
Reverse tunnel or ingressThe public edge, into a controlled listenerAn inbound surface you must secure
Runner or pollingThe agent, outbound to GitHubInstant delivery, replaced by a schedule

Санал асуулга нь хамгийн бага гоёмсог бөгөөд ажиллуулахад хамгийн хялбар. relay порт нээхгүйгээр бараг шуурхай эргэх холбоог хадгалдаг. payload-ийн нууцлал гуравдагч талыг хасах үед runner ихэвчлэн зөв хариулт байдаг, учир нь ажил сүлжээний дотор аль хэдийн байгаа машин дээр ажиллаж болно.

Юуг ажиллуулж чадахаараа сонго, орчин үеийн сонсогдохоор нь биш.

Хүргэлтийг smee-ээр гадагш илгээ

relay үйлчилгээ дээр суваг үүсгэж, түүний URL-ыг хадгал. Сүлжээний дотор клиентийг суулгаж, хүргэлтүүдийг Jenkins-ийн хүлээж буй зам руу дамжуул. Репозиторийн тохиргоон дахь payload URL нь сувгийн URL болж, агуулгын төрөл application/json-д тохируулагдана.

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

Гурван дэлгэрэнгүй зүйл ажиллах эсэхийг шийддэг. Зам нь GitHub үйл явдлын хувьд Jenkins-ийн хүлээдэгтэй тохирох ёстой бөгөөд энэ нь анхдагчаар /github-webhook/ юм. Jenkins нь клиентэд өгсөн порт дээр сонсож байх ёстой. Мөн ажилд тохируулсан Jenkins URL тэр замтай нийцэх ёстой, эс бөгөөс үйл явдал ирээд дараа нь хаягдана.

Төгсгөлийн налуу зураасны зөрүү нь 404 үүсгэдэг бөгөөд энэ нь хүргэлтийн алдаа мэт уншигдах боловч тийм биш.

Долоо хоногийг давахаар ажиллуулах

Урд талын клиент терминалтай хамт үхдэг бөгөөд webhook-ууд нэг өдөр ажиллаад дараа нь зогсдог. Түүнд Restart=always бүхий unit өгч, Jenkins хэрэглэгчээр ажиллуулж, эхний бодит хүргэлтийн дараа journal-ыг уншина уу. Яг тэр сүүлчийн алхам нь ажиллаж буй relay-г тохируулсан relay-ээс ялгадаг.

[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

Дахин тоглуулах товчны оронд бодит push-ээр туршина уу. Дахин тоглуулах нь relay-ийн хадгалсан payload-ыг ажиллуулдаг, GitHub-аас таны суваг хүртэлх замыг биш, тиймээс шууд хүргэлт хараахан бүтэлгүй байхад ч энэ нь тэнцэж болно.

unit зогсоход анхааруулга өг. Унасан relay нь бүтцээрээ чимээгүй бөгөөд чимээгүй байдал нь таны аль хэдийн дибаг хийж буй зүйл юм.

relay юуг харж чадах вэ, хэзээ ашиглахгүй байх вэ

relay payload-ыг дуусгадаг тул репозиторийн нэрс, commit өгөгдөл болон үйл явдлын дамжуулж буй бусад бүхнийг хардаг. Сувгийн URL-ыг нийтийн төгсгөлийн цэг гэж үзээрэй. Хуурамч хүргэлтүүд татгалзагдахын тулд Jenkins-ийн secret token-ыг тохируулсан байлгаж, Jenkins-ийн ашигладаг token-ыг шаардлагатай доод хэмжээнд хязгаарла.

Хэрэв payload-ийн нууцлал үүнийг хасах бол, өөрөө байршуулсан runner эсвэл баталгаажсан урвуу туннель нь хариулт юм.

relay одоо дэд бүтэц болсон бөгөөд энэ нь өдөөдөг build-тай ижил хяналтад хүртэх ёстой. Суваг алдагдвал түүнийг эргүүлж, шууд хүргэлтийг хамгийн сүүлд хэзээ баталгаажуулснаа тэмдэглэ. Тэр огноог сувгийн URL-ийн хажууд runbook-д бич. Жил гаруй хэн ч хянаагүй relay бол хэнд ч хамаарахгүй нийтийн төгсгөлийн цэг юм.

Холбоотой нийтлэлүүд