CI-runner-VPN: overleeft de tunnel de build?
Een gedeelde CI-runner houdt routes en processen tussen jobs vast. Plan de toestanden van de VPN voor, tijdens en na de job, en ruim alleen de verbinding op die de job bezit.
Een deployment-job verbindt, kopieert zijn artefact en meldt succes. De tunnel die hij opende, kan nog actief zijn wanneer de volgende job begint, en de route die hij wijzigde, hoort bij de hele host. Een buildresultaat beschrijft het commando, niet de toestand die het achterliet. Behandel de VPN als een resource met een levensduur, niet als één regel aan het begin van een stage.
Wat er nog meer op deze host draait
Een Jenkins-node kan meerdere executors tegelijk draaien, en een job die hostroutes, resolver-instellingen of een systeembrede verbinding wijzigt, wijzigt ze voor iedereen. Of een andere job dat merkt, hangt af van het route- en filterbeleid, niet van een algemene regel over VPN's. Repository-toegang, artefacttoegang en het controlekanaal zijn afzonderlijke vereisten die de runner nog steeds nodig heeft. Voeg ze toe aan de lijst met deployment-bestemmingen voordat je een volledige tunnel kiest.
Als het controlekanaal de tunnel zou kruisen, moet het ontwerp dat bewust zeggen. Het ontdekken tijdens een rollback is geen plan. Schrijf de twee lijsten op: wat de job privé moet bereiken, en wat de runner sowieso moet bereiken.
Heeft deze job überhaupt privétoegang nodig?
Vraag voordat je de tunnel toevoegt of de buildstage die nodig heeft. Een privé-deploymentagent kan een goedgekeurd artefact ophalen en de deployment uitvoeren, waardoor de algemene buildstage buiten het privénetwerk blijft. Die splitsing is meestal goedkoper dan elke buildstap leren om via een tunnel te routeren.
Kies de grens vanuit de workflow, niet vanuit gewoonte. Als het antwoord nee is, is de rest van deze pagina overbodig, en dat is het beste beschikbare resultaat.
De toestand die de volgende job erft
Beschrijf wat waar moet zijn voor de job, terwijl hij privétoegang heeft en nadat hij eindigt, inclusief annulering. De eindtoestand is degene die het vaakst impliciet blijft, en dat is degene die de volgende job erft. Schrijf hem naast de pipeline in plaats van hem in iemands geheugen te laten.
| 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 |
Een toegewijde of wegwerpagent maakt die grenzen makkelijker te handhaven. Een container of namespace helpt alleen als de netwerk- en bevoegdheidsopzet de wijziging echt isoleert.
Stop de verbinding, niet het programma
Gebruik het afrondingspad van de pipeline om de verbinding te sluiten die deze job begon en zijn tijdelijke inloggegevens te verwijderen. Vergelijk geen processen op programmanaam op een host die andere jobs gebruiken; stop in plaats daarvan de specifieke verbinding. De twee opdrachten hieronder zijn de hele opruiming, en geen van beide hangt af van het vinden van een proces.
vpn-cli disconnect --profile "$PROFILE"
rm -f "$RUNNER_TEMP/client.key"Afronding is geen isolatie: een runner die sterft, houdt de tunnel die hij opende, en een proces dat met geweld wordt gestopt, slaat het blok volledig over. Daarom kan de opruimopdracht alleen niet het hele ontwerp zijn. Zo faalt het in de praktijk: een deployment-job wordt geannuleerd bij de kopieerstap, het afrondingsblok draait nooit, en de volgende job op dezelfde host begint met een levende tunnel en een route die naar een netwerk wijst dat hij niet kan bereiken. De fout lijkt op een 'DNS'-probleem in de volgende build, uren nadat de job die hem veroorzaakte klaar was.
Leg de profielnaam en het pad van de inloggegevens vast in de uitvoer van de job. Een kale verbreekopdracht zonder enige identificatie is achteraf moeilijk te auditen. De logregel is ook wat bewijst dat het blok liep wanneer een later onderzoek erom vraagt.
Geef de job een host die niemand anders gebruikt
Wegwerpinfastructuur verwijdert het erfenisprobleem in plaats van het te beheren. Een verse agent per job begint zonder route, zonder profiel en zonder andermans inloggegevens, en de vernietiging ervan ruimt op wat de job achterliet. Dat kost meer per build, en het is de eerlijke prijs van een grens die niet van opruimcode afhangt. Voor jobs die productienetwerken raken, is het meestal de goedkopere optie zodra incidenten worden meegeteld.
Waar een gedeelde runner moet blijven, test fouten en annulering net zo zorgvuldig als de geslaagde kopie. De test moet laten zien wat de volgende job zou zien als deze halverwege werd geannuleerd. Een job is klaar wanneer zijn toegang en tijdelijke toestand voorbij zijn, niet wanneer de kopieeropdracht nul teruggeeft.