Warum verlagern Entwickler CI-Runner, Registries und Testdatenbanken von ihren Laptops?

Teams verlagern diese Dienste von Laptops, damit Builds reproduzierbar sind, gemeinsam genutzte Abhängigkeiten erreichbar sind, Testzustände verworfen werden können und die Bereitstellung nicht vom Akku oder Arbeitsbereich einer einzelnen Person abhängt.

Der Server ist kein größerer Laptop. Ein CI-Runner führt nicht vertrauenswürdige Projektanweisungen aus, eine Registry speichert Artefakte der Softwarelieferkette und eine Testdatenbank enthält veränderlichen Zustand. Sie zu kombinieren, kann für ein kleines Team effizient sein, aber nur, wenn Identitäten, Netzwerke, Speicher, Geheimnisse, Kontingente und Wiederherstellung nach Rollen getrennt sind.

Beginne mit dem Problem im Arbeitsablauf

Auf einem Laptop gehostete CI fällt aus, wenn der Besitzer schläft, unterwegs ist, das Netzwerk wechselt, den Deckel schließt oder lokale CPU- und Arbeitsspeicherressourcen benötigt. Eine lokale Registry ist mit dem Gerät nicht mehr verfügbar, während eine Testdatenbank Zustand ansammelt, den nur ein einzelner Entwickler versteht.

Kontinuierliche Integration setzt häufige, automatisierte Prüfungen voraus, deren Ergebnisse für alle sichtbar sind. Martin Fowlers Praktiken zur kontinuierlichen Integration betonen automatisierte Builds mit Selbsttests und sichtbaren Ergebnissen - Eigenschaften, die sich auf einem nur gelegentlich verfügbaren Laptop nur schwer gewährleisten lassen.

Verlagere eine Rolle erst, nachdem du das Problem benannt hast, das damit gelöst werden soll: Warteschlangenverzögerung, abweichende Umgebungen, Image-Verteilung, gemeinsam genutzter Integrationszustand oder ausgelastete Laptops.

Die Vertrauensgrenze der Runner festlegen

Behandle CI-Jobs als Codeausführung. Verwende nach Möglichkeit kurzlebige Container oder virtuelle Maschinen, binde den Docker-Socket des Hosts nicht in nicht vertrauenswürdige Jobs ein und weise jedem Repository oder jeder Pipeline eng begrenzte Zugangsdaten zu.

Begrenze Build-Arbeitsbereiche und Caches durch Kontingente. Ein fehlgeschlagener Job darf weder das Root-Dateisystem des Servers füllen noch Registry-Zugangsdaten lesen, die nicht zu seinem Projekt gehören.

Definiere Runner-Labels nach Vertrauensniveau und Fähigkeiten. Leite keinen Pull-Request-Code von unbekannten Mitwirkenden an einen Runner weiter, der auf Produktionsgeheimnisse oder das Heimnetzwerk zugreifen kann.

Die Registry als dauerhafte Verteilungsrolle einrichten

Speichere die Registry-Daten und die Konfiguration auf dauerhaftem Speicher, mit Authentifizierung, TLS über nicht vertrauenswürdige Verbindungen, Aufbewahrungsregeln und Zeitfenstern für die Garbage Collection. Trenne unveränderliche Release-Tags von entbehrlichen Branch-Images.

Sichere Konfiguration, Metadaten und alle Artefakte, die sich nicht neu erstellen lassen. Wenn Images anhand des Quellcodes reproduzierbar sind, dokumentiere die Wiederaufbauzeit und bewahre stattdessen den Quellcode, die Build-Definitionen und externe Abhängigkeiten auf, anstatt jede Cache-Ebene zu sichern.

Überwache die Kapazität, bevor du Bereinigungen durchführst. Die Garbage Collection der Registry kann I/O-intensiv sein und je nach Implementierung einen Wartungsmodus erfordern.

Featured

ZimaCube 2 persönliche Cloud-NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Testdatenbanken entbehrlich, aber repräsentativ halten

Gib jeder Pipeline oder jedem Branch einen isolierten Datenbanknamen, ein isoliertes Schema, einen Container oder eine VM. Befülle sie anhand versionierter Fixtures oder eines bereinigten Datensatzes, führe Migrationen automatisch aus und lösche sie nach Ablauf der Aufbewahrungsfrist.

Kopiere niemals Produktionsgeheimnisse oder ungeschwärzte personenbezogene Daten in die Testrolle. Beschränke den Netzwerkzugriff, damit ein kompromittierter Job nicht von der Testdatenbank zu anderen Diensten wechseln kann.

Bewahre nur die Protokolle und Artefakte auf, die zur Diagnose fehlgeschlagener Tests benötigt werden. Langfristig aufbewahrte, undokumentierte Datenbanken lösen das Laptop-Problem nur auf einem größeren Rechner erneut aus.

Die Server-Topologie für ein kleines Team aufbauen

Verwende getrennte Dienstkonten, Containernetzwerke, Volumes, Kontingente und Backup-Regeln für Runner-, Registry- und Datenbankrollen. Dieser Leitfaden zu NAS- und Docker-Plattformen hilft dir bei der Entscheidung, ob Container oder virtuelle Maschinen für die Isolierung sorgen sollen.

Platziere die Verwaltungsoberfläche in einem eingeschränkten Netzwerk. Mache die Registry und die CI-Oberfläche nur für das Team oder über eine Authentifizierungsebene zugänglich. Dokumentiere für jeden Dienst Aktualisierungen, Zuständigkeiten und Rollback-Verfahren.

Teste die Neuerstellung eines Runners, die Wiederherstellung oder den Neuaufbau der Registry, das erneute Befüllen der Datenbank, einen Zustand mit voller Festplatte und einen Serverneustart. Entwickler sollten weiterhin lokal arbeiten können, während die gemeinsamen Dienste wiederhergestellt werden.

Abschließende Einrichtungsprüfung

Der Umzug ist erfolgreich, wenn Builds ohne einen bestimmten Laptop laufen, Umgebungen anhand versionierter Definitionen neu erstellt werden, für Registry-Artefakte ein Aufbewahrungs- und Wiederherstellungsplan besteht, Testdatenbanken isoliert und entbehrlich sind und kein Runner weiterreichende Geheimnisse verwaltet, als sein Auftrag erfordert.