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 ਨੂੰ ਕਨਫਿਗਰ ਕੀਤੇ 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 ਦੀ ਕਿਸੇ ਨੇ ਸਾਲ ਭਰ ਸਮੀਖਿਆ ਨਹੀਂ ਕੀਤੀ ਉਹ ਜਨਤਕ ਅੰਤ ਬਿੰਦੂ ਹੈ ਜਿਸ ਦਾ ਕੋਈ ਮਾਲਕ ਨਹੀਂ।