CI-Runner-VPN: Überlebt der Tunnel den Build?
Ein geteilter CI-Runner behält Routen und Prozesse zwischen Jobs. Planen Sie die Zustände der VPN vor, während und nach dem Job und räumen Sie nur die Verbindung auf, die der Job besitzt.
Ein Deployment-Job verbindet sich, kopiert sein Artefakt und meldet Erfolg. Der Tunnel, den er geöffnet hat, kann noch stehen, wenn der nächste Job beginnt, und die Route, die er geändert hat, gehört dem ganzen Host. Ein Build-Ergebnis beschreibt den Befehl, nicht den Zustand, den er hinterlassen hat. Behandeln Sie die VPN als Ressource mit Lebensdauer, nicht als eine Zeile am Anfang einer Stage.
Was sonst auf diesem Host läuft
Ein Jenkins-Knoten kann mehrere Executors gleichzeitig ausführen, und ein Job, der Host-Routen, Resolver-Einstellungen oder eine systemweite Verbindung ändert, ändert sie für alle. Ob ein anderer Job das bemerkt, hängt von der Routen- und Filterrichtlinie ab, nicht von einer allgemeinen Regel über VPNs. Repository-Zugriff, Artefakt-Zugriff und der Steuerkanal sind getrennte Anforderungen, die der Runner weiterhin braucht. Nehmen Sie sie in die Liste der Deployment-Ziele auf, bevor Sie einen vollen Tunnel wählen.
Wenn der Steuerkanal den Tunnel kreuzen würde, muss das Design es bewusst sagen. Es während eines Rollbacks zu entdecken, ist kein Plan. Schreiben Sie die beiden Listen auf: was der Job privat erreichen muss und was der Runner unabhängig davon erreichen muss.
Braucht dieser Job überhaupt privaten Zugriff?
Fragen Sie vor dem Hinzufügen des Tunnels, ob die Build-Stage ihn braucht. Ein privater Deployment-Agent kann ein freigegebenes Artefakt holen und das Deployment ausführen, was die allgemeine Build-Stage aus dem privaten Netz heraushält. Diese Trennung ist meist billiger, als jeden Build-Schritt zu lehren, durch einen Tunnel zu routen.
Wählen Sie die Grenze aus dem Workflow, nicht aus der Gewohnheit. Wenn die Antwort nein ist, ist der Rest dieser Seite unnötig, und das ist das beste verfügbare Ergebnis.
Der Zustand, den der nächste Job erbt
Beschreiben Sie, was vor dem Job gelten soll, während er privaten Zugriff hat, und nach seinem Ende, einschließlich Abbruch. Der Endzustand ist der, der am häufigsten implizit bleibt, und er ist der, den der nächste Job erbt. Schreiben Sie ihn neben die Pipeline, statt ihn in jemandes Gedächtnis zu lassen.
| 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 |
Ein dedizierter oder wegwerfbarer Agent macht diese Grenzen leichter durchsetzbar. Ein Container oder Namespace hilft nur, wenn seine Netzwerk- und Rechteanordnung die Änderung tatsächlich isoliert.
Stoppen Sie die Verbindung, nicht das Programm
Nutzen Sie den Finalisierungspfad der Pipeline, um die Verbindung zu schließen, die dieser Job begonnen hat, und seine temporären Anmeldedaten zu entfernen. Vergleichen Sie auf einem Host, den andere Jobs nutzen, keine Prozesse nach Programmnamen; stoppen Sie stattdessen die konkrete Verbindung. Die beiden Befehle unten sind die ganze Bereinigung, und keiner hängt davon ab, einen Prozess zu finden.
vpn-cli disconnect --profile "$PROFILE"
rm -f "$RUNNER_TEMP/client.key"Finalisierung ist keine Isolation: Ein Runner, der stirbt, behält den Tunnel, den er geöffnet hat, und ein gewaltsam gestoppter Prozess überspringt den Block vollständig. Deshalb kann der Bereinigungsbefehl allein nicht das ganze Design sein. So scheitert es in der Praxis: Ein Deployment-Job wird beim Kopierschritt abgebrochen, der Finalisierungsblock läuft nie, und der nächste Job auf demselben Host startet mit einem lebenden Tunnel und einer Route, die auf ein Netz zeigt, das er nicht erreicht. Der Fehler sieht wie ein 'DNS'-Problem im nächsten Build aus, Stunden nachdem der Job, der ihn verursacht hat, beendet war.
Halten Sie den Profilnamen und den Pfad der Anmeldedaten in der Job-Ausgabe fest. Ein nackter Trennungsbefehl ohne Kennung ist später schwer zu prüfen. Die Logzeile ist auch das, was beweist, dass der Block lief, wenn eine spätere Untersuchung danach fragt.
Geben Sie dem Job einen Host, den niemand sonst nutzt
Wegwerfbare Infrastruktur beseitigt das Vererbungsproblem, statt es zu verwalten. Ein frischer Agent pro Job startet ohne Route, ohne Profil und ohne fremde Anmeldedaten, und seine Zerstörung räumt auf, was der Job hinterlassen hat. Das kostet mehr pro Build, und es ist der ehrliche Preis für eine Grenze, die nicht von Bereinigungscode abhängt. Für Jobs, die Produktionsnetze berühren, ist es meist die billigere Option, sobald man Vorfälle mitzählt.
Wo ein geteilter Runner bleiben muss, testen Sie Fehler und Abbruch genauso sorgfältig wie die erfolgreiche Kopie. Der Test sollte zeigen, was der nächste Job sähe, wenn dieser auf halbem Weg abgebrochen würde. Ein Job ist fertig, wenn sein Zugriff und sein temporärer Zustand beendet sind, nicht wenn der Kopierbefehl null zurückgibt.