VPN ng CI runner: nabubuhay ba ang tunnel nang mas matagal kaysa build?
Pinapanatili ng shared CI runner ang mga ruta at proseso sa pagitan ng mga job. Planuhin ang mga estado ng VPN bago, habang at pagkatapos ng job, at linisin lamang ang koneksyong pag-aari ng job.
Kumokonekta ang isang deployment job, kinokopya ang artifact nito at nag-uulat ng tagumpay. Maaaring buhay pa ang tunnel na binuksan nito kapag nagsimula ang susunod na job, at ang rutang binago nito ay pag-aari ng buong host. Ang resulta ng build ay naglalarawan ng utos, hindi ng estadong iniwan nito. Ituring ang VPN bilang resource na may habang-buhay, hindi bilang isang linya sa simula ng isang stage.
Ano pa ang tumatakbo sa host na ito
Ang isang Jenkins node ay maaaring magpatakbo ng ilang executor nang sabay, at ang job na nagbabago ng mga ruta ng host, mga setting ng resolver o koneksyong pang-system ay nagbabago ng mga ito para sa lahat. Kung mapapansin ito ng ibang job ay depende sa patakaran ng ruta at pag-filter, hindi sa pangkalahatang tuntunin tungkol sa VPN. Ang access sa repository, access sa artifact at control channel ay magkakahiwalay na pangangailangan na kailangan pa rin ng runner. Idagdag ang mga ito sa listahan ng destinasyon ng deployment bago pumili ng buong tunnel.
Kung dadaan ang control channel sa tunnel, kailangang sabihin ito ng disenyo nang sadya. Ang matuklasan ito habang nag-ro-rollback ay hindi plano. Isulat ang dalawang listahan: ano ang dapat maabot ng job nang pribado at ano ang dapat maabot ng runner anuman ang mangyari.
Kailangan ba talaga ng job na ito ng pribadong access?
Itanong bago idagdag ang tunnel kung kailangan ito ng build stage. Maaaring kumuha ang isang pribadong deployment agent ng aprubadong artifact at isagawa ang deployment, na nagpapanatili sa pangkalahatang build stage sa labas ng pribadong network. Ang paghahating iyon ay karaniwang mas mura kaysa turuan ang bawat hakbang ng build na dumaan sa tunnel.
Piliin ang hangganan mula sa workflow, hindi sa ugali. Kung ang sagot ay hindi, hindi kailangan ang natitirang bahagi ng pahinang ito, at iyon ang pinakamagandang resulta na makukuha.
Ang estadong minamana ng susunod na job
Ilarawan kung ano ang dapat totoo bago ang job, habang hawak nito ang pribadong access, at pagkatapos nitong matapos, kasama ang pagkansela. Ang huling estado ang kadalasang iniiwang hindi sinasabi, at iyon ang minamana ng susunod na job. Isulat ito sa tabi ng pipeline sa halip na iwan sa memorya ng isang tao.
| Moment | What proves it | What leaks if it is skipped |
|---|---|---|
| Job start: pre-flight route check | The route table shows no tunnel from an earlier job, and the profile list is empty | A stale route sends deployment traffic into a dead tunnel |
| Job end: disconnect and shred | The profile is down and the temporary key file is gone | The next job inherits an open tunnel and a usable credential |
| Cancelled job: reboot or disposal | The host is replaced or rebooted before the next job starts | A killed process leaves the tunnel up with no owner |
Ang nakalaan o isang-gamit na agent ay nagpapadali sa pagpapatupad ng mga hangganang iyon. Ang container o namespace ay nakakatulong lamang kung tunay na inihihiwalay ng kaayusan ng network at pribilehiyo nito ang pagbabago.
Itigil ang koneksyon, hindi ang programa
Gamitin ang landas ng pagtatapos ng pipeline upang isara ang koneksyong sinimulan ng job na ito at alisin ang mga pansamantalang kredensyal nito. Huwag itugma ang mga proseso ayon sa pangalan ng programa sa isang host na ginagamit ng ibang job; itigil ang partikular na koneksyon sa halip. Ang dalawang utos sa ibaba ang buong paglilinis, at wala sa kanila ang nakasalalay sa paghahanap ng proseso.
vpn-cli disconnect --profile "$PROFILE"
rm -f "$RUNNER_TEMP/client.key"Ang pagtatapos ay hindi paghihiwalay: ang runner na namatay ay pinapanatili ang tunnel na binuksan nito, at ang prosesong sapilitang itinigil ay lumalaktaw sa bloke nang buo. Iyon ang dahilan kung bakit ang utos ng paglilinis lamang ay hindi maaaring maging buong disenyo. Ganito ito nabibigo sa praktika: ang isang deployment job ay kinansela sa hakbang ng pagkopya, hindi kailanman tumatakbo ang bloke ng pagtatapos, at ang susunod na job sa parehong host ay nagsisimula nang may buhay na tunnel at rutang tumuturo sa isang network na hindi nito maabot. Ang kabiguan ay mukhang problemang 'DNS' sa susunod na build, oras pagkatapos matapos ang job na nagdulot nito.
Itala ang pangalan ng profile at ang path ng kredensyal sa output ng job. Ang hubad na utos ng pagdiskonekta na walang identifier ay mahirap i-audit mamaya. Ang linya sa log din ang nagpapatunay na tumakbo ang bloke kapag tinanong ng susunod na imbestigasyon.
Bigyan ang job ng host na walang ibang gumagamit
Inaalis ng isang-gamit na imprastruktura ang problema ng pamana sa halip na pamahalaan ito. Ang bagong agent sa bawat job ay nagsisimula nang walang ruta, walang profile at walang kredensyal ng iba, at nililinis ng pagkawasak nito ang anumang iniwan ng job. Mas mahal ito sa bawat build, at iyon ang tapat na presyo ng hangganang hindi nakasalalay sa code ng paglilinis. Para sa mga job na humahawak sa production network, karaniwang ito ang mas murang opsyon kapag binilang ang mga insidente.
Kung saan kailangang manatili ang shared runner, subukan ang kabiguan at pagkansela nang kasing-ingat ng matagumpay na pagkopya. Dapat ipakita ng pagsubok kung ano ang makikita ng susunod na job kung ito ay kinansela sa kalagitnaan. Tapos na ang job kapag natapos na ang access at pansamantalang estado nito, hindi kapag nagbalik ng zero ang utos ng pagkopya.