VPN pentru runnerul CI: supraviețuiește tunelul build-ului?
Un runner CI partajat păstrează rute și procese între joburi. Planificați stările VPN-ului înainte, în timpul și după job, și curățați doar conexiunea pe care jobul o deține.
Un job de implementare se conectează, își copiază artefactul și raportează succes. Tunelul pe care l-a deschis poate fi încă activ când începe următorul job, iar ruta pe care a schimbat-o aparține întregului host. Rezultatul unui build descrie comanda, nu starea pe care a lăsat-o în urmă. Tratați VPN-ul ca o resursă cu durată de viață, nu ca o singură linie la începutul unei etape.
Ce altceva rulează pe acest host
Un nod Jenkins poate rula mai mulți executanți simultan, iar un job care schimbă rutele hostului, setările resolverului sau o conexiune la nivel de sistem le schimbă pentru toți. Dacă alt job observă asta depinde de politica de rute și filtrare, nu de o regulă generală despre VPN-uri. Accesul la repository, accesul la artefacte și canalul de control sunt cerințe separate de care runnerul are în continuare nevoie. Adăugați-le în lista destinațiilor de implementare înainte de a alege un tunel complet.
Dacă canalul de control ar traversa tunelul, proiectul trebuie să spună asta deliberat. Descoperirea acestui lucru în timpul unei reveniri nu este un plan. Scrieți cele două liste: la ce trebuie să ajungă jobul în mod privat și la ce trebuie să ajungă runnerul indiferent de situație.
Are acest job nevoie de acces privat, de fapt?
Întrebați, înainte de a adăuga tunelul, dacă etapa de build are nevoie de el. Un agent de implementare privat poate aduce un artefact aprobat și poate face implementarea, ceea ce ține etapa generală de build în afara rețelei private. Acea separare este de obicei mai ieftină decât să înveți fiecare pas de build să ruteze printr-un tunel.
Alegeți granița din fluxul de lucru, nu din obișnuință. Dacă răspunsul este nu, restul acestei pagini este inutil, și acesta este cel mai bun rezultat disponibil.
Starea pe care o moștenește următorul job
Descrieți ce ar trebui să fie adevărat înainte de job, cât timp are acces privat și după ce se termină, inclusiv anularea. Starea finală este cea care rămâne cel mai des implicită, și ea este cea pe care o moștenește următorul job. Scrieți-o lângă pipeline în loc să o lăsați în memoria cuiva.
| 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 |
Un agent dedicat sau de unică folosință face aceste granițe mai ușor de impus. Un container sau un spațiu de nume ajută doar dacă aranjamentul său de rețea și privilegii izolează într-adevăr schimbarea.
Opriți conexiunea, nu programul
Folosiți calea de finalizare a pipeline-ului pentru a închide conexiunea pe care a început-o acest job și a elimina acreditările lui temporare. Nu potriviți procese după numele programului pe un host folosit de alte joburi; opriți conexiunea specifică. Cele două comenzi de mai jos sunt toată curățarea, și niciuna nu depinde de găsirea unui proces.
vpn-cli disconnect --profile "$PROFILE"
rm -f "$RUNNER_TEMP/client.key"Finalizarea nu este izolare: un runner care moare păstrează tunelul pe care l-a deschis, iar un proces oprit forțat sare complet peste bloc. De aceea comanda de curățare singură nu poate fi întregul proiect. Iată cum eșuează în practică: un job de implementare este anulat la pasul de copiere, blocul de finalizare nu rulează niciodată, iar următorul job de pe același host pornește cu un tunel activ și o rută care indică o rețea pe care nu o poate atinge. Defecțiunea arată ca o problemă de 'DNS' în build-ul următor, la ore după ce jobul care a cauzat-o s-a încheiat.
Înregistrați numele profilului și calea acreditării în ieșirea jobului. O comandă de deconectare fără niciun identificator este greu de auditat ulterior. Linia de log este și ceea ce dovedește că blocul a rulat atunci când o investigație ulterioară întreabă.
Dați jobului un host pe care nu îl folosește nimeni altcineva
Infrastructura de unică folosință elimină problema moștenirii în loc să o gestioneze. Un agent nou pentru fiecare job pornește fără rută, fără profil și fără acreditările altcuiva, iar distrugerea lui curăță ce a lăsat jobul. Asta costă mai mult pe build, și este prețul onest al unei granițe care nu depinde de codul de curățare. Pentru joburile care ating rețele de producție, este de obicei opțiunea mai ieftină după ce incidentele sunt numărate.
Acolo unde un runner partajat trebuie să rămână, testați eșecul și anularea la fel de atent ca copierea reușită. Testul ar trebui să arate ce ar vedea următorul job dacă acesta ar fi anulat la jumătatea drumului. Un job este gata când accesul și starea lui temporară s-au încheiat, nu când comanda de copiere returnează zero.