VPN-ийн ард байгаа Jenkins-ийн эсрэг GitHub webhook яагаад хугацаа хэтэрдэг вэ
GitHub webhook-уудыг дотогш илгээдэг тул Jenkins-ийг хамгаалдаг VPN тэдгээрийг татгалздаг. Хүргэлтийг relay-ээр гадагш илгээх эсвэл webhook-ыг санал асуулга явуулдаг agent-ээр солино уу.
Хүргэлтийн хуудас хугацаа хэтэрснийг харуулж, Jenkins юу ч бүртгэхгүй байгаа нь хэзээ ч ирээгүй холболтын шинж юм. GitHub webhook-ыг өөрийн дэд бүтцээс таны тохируулсан payload URL руу гадагш HTTP POST хэлбэрээр илгээдэг. VPN нь яг ийм төрлийн холболтыг татгалзах замаар Jenkins-ийг хамгаалдаг. Аль ч талд ямар нэгэн зүйл эвдээгүй. Асуудал нь хүсэлтийн чиглэлд байна.
Хүргэлт үнэндээ юу хийхийг оролддог вэ
GitHub payload URL дахь хостын нэрийг шийдэж, нийтийн интернэтээс түүнтэй холбогддог. Хэрэв тэр URL хувийн хаяг руу, эсвэл зөвхөн таны сүлжээний дотор шийдэгддэг нэр рүү зааж байвал оролдлого ямар ч хүсэлт илгээхээс өмнө бүтэлгүйтдэг. Хэрэв таны ирмэг хаядаг нийтийн нэр рүү зааж байвал оролдлого оронд нь хугацаа хэтэрдэг.
Энэ ялгаа оношилгоонд чухал. DNS-ийн алдаа болон шүүсэн порт хоёулаа Jenkins-ийн талд юу ч болоогүй мэт харагдаж, хоёулаа GitHub дээр өөр шалтгаан хавсаргасан бүтэлгүй хүргэлт болж харагддаг. URL-ыг өөрчлөхөөс өмнө тэр шалтгааныг уншина уу.
Гадагш залгадаг туннель сонсогч үүсгэдэггүй. Хүмүүс өөрөөр ажиллана гэж хүлээдэг хэсэг нь яг энэ.
Холболтын чиглэлийг засах гурван арга
Шийдэл бүр холболтыг хэн эхлүүлэхийг өөрчилдөг бөгөөд ердөө гурван хэлбэр байна.
| 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 |
Санал асуулга нь хамгийн бага гоёмсог бөгөөд ажиллуулахад хамгийн хялбар. 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 бол хэнд ч хамаарахгүй нийтийн төгсгөлийн цэг юм.