VPN-ന് പിന്നിലുള്ള Jenkins-നെതിരെ GitHub webhook സമയം കവിയുന്നത് എന്തുകൊണ്ട്
GitHub webhook അകത്തേക്ക് അയയ്ക്കുന്നു, അതിനാൽ Jenkins-നെ സംരക്ഷിക്കുന്ന VPN അവ നിരസിക്കുന്നു. ഡെലിവറി relay വഴി പുറത്തേക്ക് അയയ്ക്കുക, അല്ലെങ്കിൽ webhook-നെ പോളിംഗ് ചെയ്യുന്ന agent ഉപയോഗിച്ച് മാറ്റുക.
ഡെലിവറി പേജ് ഒരു സമയപരിധി കാണിക്കുന്നു, Jenkins ഒന്നും ലോഗ് ചെയ്യുന്നുമില്ല, ഇത് ഒരിക്കലും എത്താത്ത ഒരു കണക്ഷന്റെ അടയാളമാണ്. GitHub തന്റെ സ്വന്തം ഇൻഫ്രാസ്ട്രക്ചറിൽ നിന്ന് നിങ്ങൾ കോൺഫിഗർ ചെയ്ത payload URL-ലേക്ക് ഒരു ഔട്ട്ബൗണ്ട് HTTP POST ആയി webhook അയയ്ക്കുന്നു. 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-യെ കോൺഫിഗർ ചെയ്ത ഒന്നിൽ നിന്ന് വേർതിരിക്കുന്നത്.
[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 ആരും ഉടമസ്ഥതയില്ലാത്ത പൊതു അന്തിമ പോയിന്റാണ്.