CI-runner-VPN: overlever tunnelen buildet?
En delt CI-runner beholder ruter og processer mellem jobs. Planlæg VPN'ens tilstande før, under og efter jobbet, og ryd kun op i den forbindelse, som jobbet ejer.
Et deployment-job forbinder, kopierer sit artefakt og rapporterer succes. Den tunnel, det åbnede, kan stadig være oppe, når det næste job starter, og den rute, det ændrede, tilhører hele værten. Et build-resultat beskriver kommandoen, ikke den tilstand, den efterlod. Behandl VPN'en som en ressource med en levetid, ikke som én linje i starten af et trin.
Hvad ellers kører på denne vært
En Jenkins-node kan køre flere executors på én gang, og et job, der ændrer værtens ruter, resolver-indstillinger eller en systemdækkende forbindelse, ændrer dem for alle. Om et andet job bemærker det, afhænger af rute- og filterpolitikken, ikke af en generel regel om VPN'er. Adgang til repository, adgang til artefakter og kontrolkanalen er separate krav, som runneren stadig har brug for. Føj dem til listen over deployment-destinationer, før du vælger en fuld tunnel.
Hvis kontrolkanalen skulle krydse tunnelen, skal designet sige det bevidst. At opdage det under en tilbagerulning er ikke en plan. Skriv de to lister ned: hvad jobbet skal nå privat, og hvad runneren skal nå uanset hvad.
Har dette job overhovedet brug for privat adgang?
Spørg, før du tilføjer tunnelen, om build-trinnet har brug for den. En privat deployment-agent kan hente et godkendt artefakt og udføre deployment, hvilket holder det generelle build-trin uden for det private netværk. Den opdeling er normalt billigere end at lære hvert build-trin at rute gennem en tunnel.
Vælg grænsen ud fra arbejdsgangen i stedet for af vane. Hvis svaret er nej, er resten af denne side unødvendig, og det er det bedste resultat, der findes.
Den tilstand, det næste job arver
Beskriv, hvad der skal være sandt før jobbet, mens det har privat adgang, og efter det slutter, inklusive afbrydelse. Sluttilstanden er den, der oftest efterlades implicit, og det er den, det næste job arver. Skriv den ved siden af pipeline i stedet for at lade den ligge i nogens hukommelse.
| 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 |
En dedikeret eller kasserbar agent gør de grænser lettere at håndhæve. En container eller et namespace hjælper kun, hvis dens netværks- og privilegieopsætning faktisk isolerer ændringen.
Stop forbindelsen, ikke programmet
Brug pipelines afslutningssti til at lukke den forbindelse, som dette job startede, og fjerne dets midlertidige legitimationsoplysninger. Match ikke processer efter programnavn på en vært, som andre jobs bruger; stop i stedet den specifikke forbindelse. De to kommandoer nedenfor er hele oprydningen, og ingen af dem afhænger af at finde en proces.
vpn-cli disconnect --profile "$PROFILE"
rm -f "$RUNNER_TEMP/client.key"Afslutning er ikke isolering: en runner, der dør, beholder den tunnel, den åbnede, og en proces, der stoppes med magt, springer blokken helt over. Derfor kan oprydningskommandoen alene ikke være hele designet. Sådan fejler det i praksis: et deployment-job afbrydes ved kopieringstrinnet, afslutningsblokken kører aldrig, og det næste job på samme vært starter med en levende tunnel og en rute, der peger på et netværk, det ikke kan nå. Fejlen ligner et 'DNS'-problem i det næste build, timer efter at jobbet, der forårsagede den, sluttede.
Registrér profilnavnet og stien til legitimationsoplysningerne i jobbets output. En bar afbrydelseskommando uden identifikator er svær at revidere bagefter. Loglinjen er også det, der beviser, at blokken kørte, når en senere undersøgelse spørger.
Giv jobbet en vært, som ingen andre bruger
Kasserbar infrastruktur fjerner arvsproblemet i stedet for at styre det. En frisk agent pr. job starter uden rute, uden profil og uden andres legitimationsoplysninger, og dens ødelæggelse rydder op i, hvad jobbet efterlod. Det koster mere pr. build, og det er den ærlige pris for en grænse, der ikke afhænger af oprydningskode. For jobs, der rører produktionsnetværk, er det normalt den billigere løsning, når hændelser tælles med.
Hvor en delt runner skal blive, skal fejl og afbrydelse testes lige så omhyggeligt som den vellykkede kopiering. Testen bør vise, hvad det næste job ville se, hvis dette blev afbrudt på halvvejen. Et job er færdigt, når dets adgang og midlertidige tilstand er slut, ikke når kopieringskommandoen returnerer nul.