CI-runner-VPN: overlever tunnelen bygget?
En delt CI-runner beholder ruter og prosesser mellom jobber. Planlegg tilstandene til VPN-en før, under og etter jobben, og rydd bare opp i tilkoblingen jobben eier.
En deployment-jobb kobler til, kopierer artefakten sin og rapporterer suksess. Tunnelen den åpnet, kan fortsatt være oppe når neste jobb starter, og ruten den endret, tilhører hele verten. Et byggeresultat beskriver kommandoen, ikke tilstanden den etterlot. Behandle VPN-en som en ressurs med levetid, ikke som én linje i starten av et steg.
Hva annet som kjører på denne verten
En Jenkins-node kan kjøre flere utførere samtidig, og en jobb som endrer vertens ruter, resolver-innstillinger eller en systemomfattende tilkobling, endrer dem for alle. Om en annen jobb merker det, avhenger av rute- og filtreringspolicyen, ikke av en generell regel om VPN-er. Tilgang til repository, tilgang til artefakter og kontrollkanalen er separate krav som runneren fortsatt trenger. Legg dem til i listen over deployment-mål før du velger en full tunnel.
Hvis kontrollkanalen skulle krysse tunnelen, må designet si det bevisst. Å oppdage det under en tilbakerulling er ikke en plan. Skriv ned de to listene: hva jobben må nå privat, og hva runneren må nå uansett.
Trenger denne jobben i det hele tatt privat tilgang?
Spør før du legger til tunnelen om byggesteget trenger den. En privat deployment-agent kan hente en godkjent artefakt og utføre deploymenten, noe som holder det generelle byggesteget utenfor det private nettet. Den delingen er vanligvis billigere enn å lære hvert byggesteg å rute gjennom en tunnel.
Velg grensen ut fra arbeidsflyten, ikke av vane. Hvis svaret er nei, er resten av denne siden unødvendig, og det er det beste resultatet som finnes.
Tilstanden neste jobb arver
Beskriv hva som skal være sant før jobben, mens den har privat tilgang og etter at den er ferdig, inkludert avbrudd. Sluttilstanden er den som oftest blir stående implisitt, og det er den neste jobb arver. Skriv den ved siden av pipeline i stedet for å la den ligge i noens 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 dedikert eller engangs agent gjør disse grensene lettere å håndheve. En container eller et namespace hjelper bare hvis nettverks- og privilegieoppsettet faktisk isolerer endringen.
Stopp tilkoblingen, ikke programmet
Bruk pipelines avslutningssti for å lukke tilkoblingen denne jobben startet og fjerne dens midlertidige påloggingsinformasjon. Ikke match prosesser etter programnavn på en vert som andre jobber bruker; stopp den konkrete tilkoblingen i stedet. De to kommandoene nedenfor er hele oppryddingen, og ingen av dem avhenger av å finne en prosess.
vpn-cli disconnect --profile "$PROFILE"
rm -f "$RUNNER_TEMP/client.key"Avslutning er ikke isolasjon: en runner som dør, beholder tunnelen den åpnet, og en prosess som stoppes med makt, hopper helt over blokken. Derfor kan oppryddingskommandoen alene ikke være hele designet. Slik svikter det i praksis: en deployment-jobb avbrytes ved kopieringstrinnet, avslutningsblokken kjører aldri, og neste jobb på samme vert starter med en levende tunnel og en rute som peker på et nettverk den ikke når. Feilen ser ut som et 'DNS'-problem i neste bygg, timer etter at jobben som forårsaket den, var ferdig.
Registrer profilnavnet og stien til påloggingsinformasjonen i jobbens utdata. En bar frakoblingskommando uten identifikator er vanskelig å revidere etterpå. Logglinjen er også det som beviser at blokken kjørte når en senere undersøkelse spør.
Gi jobben en vert som ingen andre bruker
Engangsinfrastruktur fjerner arveproblemet i stedet for å administrere det. En fersk agent per jobb starter uten rute, uten profil og uten andres påloggingsinformasjon, og ødeleggelsen rydder opp i det jobben etterlot. Det koster mer per bygg, og det er den ærlige prisen for en grense som ikke avhenger av oppryddingskode. For jobber som berører produksjonsnettverk, er det vanligvis det billigere alternativet når hendelser regnes med.
Der en delt runner må bli, test feil og avbrudd like nøye som den vellykkede kopien. Testen bør vise hva neste jobb ville se hvis denne ble avbrutt halvveis. En jobb er ferdig når tilgangen og den midlertidige tilstanden er over, ikke når kopieringskommandoen returnerer null.