Ինչու են GitHub-ի webhook-ները ժամկետանցվում VPN-ի հետևում գտնվող Jenkins-ի դեմ
GitHub-ը webhook-ները ուղարկում է դեպի ներս, ուստի Jenkins-ը պաշտպանող VPN-ն մերժում է դրանք։ Ուղարկեք առաքումը դուրս relay-ի միջով, կամ փոխարինեք webhook-ը հարցումներ անող agent-ով։
Առաքման էջը ցույց է տալիս ժամկետի սպառում, և Jenkins-ը ոչինչ չի գրանցում, ինչը նշան է այն կապի, որը երբեք չի հասել։ GitHub-ը webhook-ը ուղարկում է որպես ելքային HTTP POST իր իսկ ենթակառուցվածքից ձեր կարգավորած payload URL-ին։ 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-ը պահում է գրեթե ակնթարթային արձագանք՝ առանց պորտ բացելու։ Runner-ը սովորաբար ճիշտ պատասխանն է, երբ payload-ի գաղտնիությունը բացառում է երրորդ կողմին, քանի որ աշխատանքը կարող է ընթանալ ցանցի ներսում արդեն գտնվող մեքենայի վրա։
Ընտրեք ըստ այն բանի, ինչ կարող եք շահագործել, ոչ թե ըստ այն բանի, ինչ ժամանակակից է հնչում։
Ուղարկեք առաքումը դուրս smee-ով
Ստեղծեք ալիք relay ծառայությունում և պահեք դրա URL-ը։ Ցանցի ներսում տեղադրեք հաճախորդը և առաքումները փոխանցեք այն ուղուն, որը Jenkins-ը սպասում է։ Պահոցի կարգավորումներում payload URL-ը դառնում է ալիքի URL-ը, բովանդակության տեսակը սահմանված է application/json։
sudo npm install --global smee-client
smee -u CHANNEL_URL --path /github-webhook/ --port 8080Երեք մանրամասն որոշում է, թե արդյոք այն կաշխատի։ Ուղին պետք է համապատասխանի այն բանին, ինչ Jenkins-ը սպասում է GitHub-ի իրադարձությունների համար, որը լռելյայն /github-webhook/ է։ Jenkins-ը պետք է լսի այն պորտում, որը դուք տվեցիք հաճախորդին։ Եվ աշխատանքում կարգավորված Jenkins URL-ը պետք է համաձայնի այդ ուղու հետ, այլապես իրադարձությունը կհասնի և հետո կմերժվի։
Վերջնական շեղի անհամապատասխանությունը առաջացնում է 404, որը կարդացվում է որպես առաքման ձախողում և այդպիսին չէ։
Գործարկել այնպես, որ այն դիմանա շաբաթին
Առաջին պլանի հաճախորդը մահանում է տերմինալի հետ, և webhook-ները աշխատում են մեկ օր, ապա դադարում։ Տվեք նրան unit՝ Restart=always-ով, գործարկեք այն որպես Jenkins օգտատեր, և առաջին իրական առաքումից հետո կարդացեք journal-ը։ Հենց այդ վերջին քայլն է, որ տարբերում է աշխատող 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-ի գաղտնի token-ը կարգավորված, որպեսզի կեղծ առաքումները մերժվեն, և սահմանափակեք Jenkins-ի օգտագործած token-ը անհրաժեշտ նվազագույնով։
Եթե payload-ի գաղտնիությունը բացառում է դա, ինքնուրույն հյուրընկալված runner կամ նույնականացված հակադարձ թունել է պատասխանը։
Relay-ն այժմ ենթակառուցվածք է և արժանի է նույն վերանայմանը, ինչ այն build-ը, որը գործարկում է։ Պտտեք ալիքը, եթե այն արտահոսում է, և նշեք ամսաթիվը, երբ վերջին անգամ ստուգել եք ուղիղ առաքումը։ Դրեք այդ ամսաթիվը runbook-ում ալիքի URL-ի կողքին։ Relay-ը, որը մեկ տարի ոչ ոք չի վերանայել, հանրային վերջնակետ է, որի տերը ոչ ոք չէ։