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

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

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

Mit dem Fehler im Workflow beginnen

Auf einem Laptop gehostete CI schlägt fehl, wenn der Besitzer schläft, reist, das Netzwerk wechselt, den Deckel schließt oder lokale CPU- und Speicherressourcen benötigt. Eine lokale Registry verschwindet mit diesem Gerät, während eine Testdatenbank Zustände ansammelt, die nur ein Entwickler versteht.

Kontinuierliche Integration hängt von häufiger, automatisierter Verifizierung ab, die alle sehen können. Martin Fowlers Praktiken der kontinuierlichen Integration betonen automatisierte, sich selbst testende Builds und sichtbare Ergebnisse - Eigenschaften, die auf einem nur gelegentlich verfügbaren Laptop schwer zu gewährleisten sind.

Verlagern Sie eine Rolle erst, nachdem Sie den Fehler benannt haben, den sie beheben soll: Warteschlangenverzögerung, Umgebungsabweichungen, Image-Verteilung, gemeinsamer Integrationszustand oder Konkurrenz um Laptop-Ressourcen.

Die Vertrauensgrenze des Runners trennen

Behandeln Sie CI-Jobs als Codeausführung. Verwenden Sie nach Möglichkeit kurzlebige Container oder virtuelle Maschinen, vermeiden Sie es, den Docker-Socket des Hosts in nicht vertrauenswürdige Jobs einzubinden, und weisen Sie jedem Repository oder jeder Pipeline eng begrenzte Zugangsdaten zu.

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

Definieren Sie Runner-Labels nach Vertrauensniveau und Fähigkeiten. Senden Sie keinen Pull-Request-Code eines unbekannten Mitwirkenden an einen Runner, der Produktionsgeheimnisse oder das Heimnetzwerk erreichen kann.

Die Registry zu einer dauerhaften Verteilungsrolle machen

Speichern Sie Registry-Daten und -Konfiguration auf dauerhaftem Speicher mit Authentifizierung, TLS auf nicht vertrauenswürdigen Pfaden, Aufbewahrungsregeln und Zeitfenstern für die Garbage Collection. Trennen Sie unveränderliche Release-Tags von verworfenen Branch-Images.

Sichern Sie Konfiguration, Metadaten und alle Artefakte, die nicht neu erstellt werden können. Wenn Images aus dem Quellcode reproduzierbar sind, dokumentieren Sie die Zeit für den Neuaufbau und bewahren Sie Quellcode, Build-Definitionen und externe Abhängigkeiten auf, statt jede Cache-Schicht zu sichern.

Überwachen Sie die Kapazität vor der Bereinigung. Die Garbage Collection einer Registry kann I/O-intensiv sein und je nach Implementierung einen Wartungsmodus erfordern.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Testdatenbanken verwerfbar, aber repräsentativ halten

Geben Sie jeder Pipeline oder jedem Branch einen isolierten Datenbanknamen, ein isoliertes Schema, einen Container oder eine virtuelle Maschine. Befüllen Sie sie aus versionierten Fixtures oder einem bereinigten Datensatz, führen Sie Migrationen automatisch aus und löschen Sie sie nach Ablauf des Aufbewahrungszeitraums.

Kopieren Sie niemals Produktionsgeheimnisse oder nicht anonymisierte personenbezogene Daten in die Testrolle. Begrenzen Sie die Netzwerkreichweite, damit ein kompromittierter Job nicht von der Testdatenbank aus auf andere, nicht zugehörige Dienste zugreifen kann.

Speichern Sie nur die Protokolle und Artefakte dauerhaft, die zur Diagnose fehlgeschlagener Tests erforderlich sind. Langlebige, rätselhafte Datenbanken schaffen das Laptop-Problem auf einem größeren Gerät erneut.

Die Servertopologie für kleine Teams aufbauen

Verwenden Sie für die Rollen Runner, Registry und Datenbank separate Dienstkonten, Containernetzwerke, Volumes, Kontingente und Sicherungsregeln. Dieser Leitfaden zu NAS- und Docker-Plattformen hilft bei der Entscheidung, ob Container oder virtuelle Maschinen die Isolierung bereitstellen sollten.

Platzieren Sie die Verwaltungsschnittstelle in einem eingeschränkten Netzwerk. Stellen Sie die Registry und die CI-Oberfläche nur dem Team oder über eine authentifizierte Zugriffsschicht zur Verfügung. Protokollieren Sie für jeden Dienst Aktualisierungen, Zuständigkeit und Rollback.

Testen Sie die Neuerstellung eines Runners, die Wiederherstellung oder den Neuaufbau der Registry, die erneute Befüllung der Datenbank, einen Zustand mit vollständig belegtem Datenträger und einen Serverneustart. Entwickler sollten lokal weiterarbeiten können, während sich die gemeinsam genutzten Dienste erholen.

Abschließende Prüfung der Einrichtung

Die Umstellung ist erfolgreich, wenn Builds ohne einen bestimmten Laptop ausgeführt werden, Umgebungen aus versionierten Definitionen neu erstellt werden, Registry-Artefakte über einen Aufbewahrungs- und Wiederherstellungsplan verfügen, Testdatenbanken isoliert und verwerfbar sind und kein Runner umfassendere Geheimnisse besitzt, als sein Job erfordert.