GitHub-ի webhook-ը չի հասնում մասնավոր Jenkins-ին՝ ուղղեք ուղին

Դուք կարող եք բացել Jenkins-ը VPN-ի միջոցով և այդուամենայնիվ տեսնել, որ GitHub-ը հաղորդում է ձախողված webhook-ի մասին, որովհետև դրանք երկու տարբեր կապեր են՝ երկու տարբեր տերերով։ Զննարկիչը շարժվում է թունելով, որը բանակցել է ձեր նոութբուքը, իսկ GitHub-ի առաքման ծառայությունը սկսվում է հանրային ինտերնետից և ուղի չունի դեպի մասնավոր ցանց։ Պահոցի հասանելիությունը դա չի փոխում, նույնիսկ եթե Jenkins-ն ինքը կարող է նույն պահոցից առանց դժվարության վերցնել։ Ընտրեք մուտքի կետ, ռելե կամ հարցում, ապա ստուգեք այն ուղին, որով իրադարձությունն իրականում անցնում է։

Զննարկիչի սեանսը ապացուցում է միայն մեկ ուղղություն

VPN կապը պատասխանում է մեկ հարցի՝ կարո՞ղ է այս նոութբուքը հասնել ներքին հոսթին։ Webhook-ի առաքումը հարցնում է մեկ այլ բան՝ կարո՞ղ է արտաքին ծառայությունը կապ բացել այդ հոսթի հետ։ Այն, որ Jenkins-ը պահոցից վերցնում է, արտագնա տրաֆիկ է և ոչինչ չի ասում մուտքային հասանելիության մասին։ Պահեք երկու ուղղությունները ձեր գծապատկերի առանձին գծերի վրա՝ ներառյալ, թե որ կողմն է սկսում յուրաքանչյուրը։

Կարդացեք առաքման գրառումը նախքան որևէ բան փոխելը։ Ժամկետի ավարտը, կապի վերականգնումը և ընդունված հարցումը, որը չհամապատասխանեց ոչ մի աշխատանքի, ունեն երեք տարբեր տերեր՝ ցանց, փրոքսի և գործարկիչի կարգավորում։

Տարբերակ Ա՝ բացեք նեղ վերջնակետ

Եթե կազմակերպությունն արդեն հրապարակում է հաստատված մուտքի կետ, բացեք webhook-ի ուղին՝ վահանակի փոխարեն։ Սովորաբար դա նշանակում է հակադարձ փրոքսիի կանոն, որն ընդունում է POST-երը կեռիկի URL-ում և փոխանցում դրանք Jenkins-ին, մինչ վարչական ինտերֆեյսը դրսից անհասանելի է մնում։

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

Անցկացրեք այդ թեստը VPN հասանելիություն չունեցող ցանցից, որովհետև թունելի ներսից հաջողությունը ոչինչ չի ապացուցում։ Վերջնակետը պետք է մերժի առանց ընդհանուր գաղտնիքի հարցումները, որը GitHub-ը ուղարկում է որպես ստորագրության վերնագիր, և ընդունի միայն այն միակ ուղին ու մեթոդը, որը դուք հրապարակել եք։ Հանրային Jenkins-ի կոնսոլը webhook-ի լուծում չէ, դա միջադեպ է, որը սպասում է հաջորդ սկաներին։ Սահմանափակեք կանոնը բավական նեղ, որպեսզի հավելվածի մնացած մասը պահպանի նախկին հասանելիության վերահսկումը։

Տարբերակ Բ՝ շրջեք ուղղությունը ռելեով

Այնտեղ, որտեղ մուտքային բացումը չի հաստատվի, ցանցի ներսում գտնվող փոքր կլիենտը կարող է արտագնա կապ պահել ռելեի հետ և ստանալ փոխանցված իրադարձությունները։ Ռելեն այնուհետև դառնում է առաքման ուղու մաս, ուստի դրա հասանելիությունն ու նույնականացումը նույնքան կարևոր են, որքան կառուցման աշխատանքը։

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

Jenkins-ի ուղեցույցը firewall-ների հետևում գտնվող webhook-ների մասին նկարագրում է այս ձևը, և արժե կարդալ այն նախքան սեփական փոխանցիչ գրելը։ Ավարտեք TLS-ը ռելեի մոտ, ստուգեք ստորագրությունը նախքան իրադարձությունը աշխատանքին հասնելը, և վերահսկեք արտագնա կապը, որովհետև ընկած թունելը ճիշտ նույն տեսքն ունի, ինչ երբեք չուղարկված իրադարձությունը։ Հաստատեք նաև, որ ռելեն պահպանում է հարցման մարմինը բայթ առ բայթ, քանի որ ստորագրության ստուգումները ձախողվում են ճանապարհին վերլուծված և նորից կոդավորված JSON-ի դեպքում։

Տարբերակ Գ՝ փոխարենը հարցրեք պահոցը

Հարցումը հետաձգումը փոխանակում է պարզության հետ և ընդհանրապես մուտքային ուղի չի պահանջում։ Jenkins-ը կարող է հարցնել ըստ ժամանակացույցի, կամ փոքր աշխատանքը կարող է հարցնել API-ին և սկսել կառուցում, երբ տեսնի անծանոթ վերանայում։

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

Յուրաքանչյուր հարցում ծախսում է API-ի կանչեր և ավելացնում ուշացում push-ի և կառուցման միջև, ինչը տեսանելի է դառնում զբաղված պահոցներում և ընդհանուր արագության սահմանաչափերում։ Այն նաև պահանջում է հավատարմագրեր, որոնք պահվում են այնտեղ, որտեղ աշխատում է հարցնողը, ուստի սահմանափակեք թոքենը պահոցի միայն կարդալու հասանելիությամբ և պտտեք այն ինչպես ցանկացած այլ գաղտնիք։ Ընտրեք սա, երբ իրադարձությունների ծավալը ցածր է կամ երբ մուտքի կետը երբեք չի հաստատվի, և ասեք դա աշխատանքի նկարագրում, որպեսզի հետո ոչ ոք չզարմանա, թե ինչու են կառուցումները հետ մնում։

Ընդունեք իրական առաքում, ոչ էջի բեռնում

Ինչ տարբերակ էլ ընտրել եք, ընդունման թեստը աղբյուր հարթակի ուղարկած իրադարձությունն է, ոչ թե արտոնյալ նոութբուքից բացված զննարկիչի ներդիր։ Ուղարկեք դատարկ commit սկրեչ ճյուղ և կարդացեք առաքման պատասխանի կոդը, ռելեի մատյանը կամ հարցման աշխատանքի ելքը՝ այդ հերթականությամբ։ Վերջնակետից ստացված 200-ը առանց կառուցման նշանակում է, որ գործարկիչի զտիչը սխալ է, իսկ ժամկետի ավարտը նշանակում է, որ ուղին դեռ փակ է։ Գրանցեք, թե երեք նախագծերից որն է օգտագործվում, այլապես հաջորդ վրիպազերծողը կկրկնի զննարկիչի թեստը և կհասնի նույն փակուղին։

Կիրառեք նույն տրամաբանությունը վճարումների հետադարձ կանչերի և այլ արտաքին ծանուցումների նկատմամբ՝ յուրաքանչյուրին պետք է իր ուղին դեպի մասնավոր հավելված, նույնիսկ երբ յուրաքանչյուր մարդ արդեն ունի VPN սեանս։ Առաքման ուղին պատկանում է հավելվածի ձևավորմանը, ոչ թե ցանցերի մասին ծանոթագրությանը։