Ihre Runner für Continuous Integration selbst betreiben
Eigene Runner: keine abgerechneten Minuten mehr und ein Cache, der von Build zu Build überlebt.
Ab ab 13,99 €/Monat
Einleitung
Minuten für Continuous Integration werden teuer, sobald Builds häufig oder lang werden. Eigene Runner auf einem VDS zu betreiben ändert die Rechnung: ein fester Monatspreis, gleich wie viele Builds, und ein Server, den man auf das auslegen kann, was man tatsächlich baut.
Der zweite Gewinn ist weniger offensichtlich, aber oft spürbarer: der Cache bleibt. Auf einem selbst betriebenen Runner bleiben heruntergeladene Abhängigkeiten, Image-Schichten und Zwischenartefakte von Build zu Build liegen. Viele Pipelines fallen allein dadurch von mehreren Minuten auf einige zehn Sekunden.
Das L-Angebot für 26,99 €/Monat mit 8 vCore deckt zwei bis drei parallele Runner bequem ab. Isolieren Sie sie in eigenen VMs statt in geteilten Containern: ein Build führt beliebigen Code aus, und genau davor soll der Rest des Servers geschützt sein.
Was der Server mitbringt, über die ganze Reihe
Proxmox VE bereits installiert
Der Server kommt mit installiertem <strong>Proxmox VE</strong> und erreichbarer Weboberfläche. Sie erstellen Ihre virtuellen Maschinen und LXC-Container im Browser, ohne Ticket und ohne Wartezeit. <strong>Neuinstallationen sind unbegrenzt</strong>: ein misslungener Versuch ist in Minuten zurückgesetzt.
Arbeitsspeicher, denn er geht zuerst aus
Auf einem Hypervisor stößt selten der Prozessor zuerst an die Grenze, sondern der <strong>Speicher</strong> — jede virtuelle Maschine reserviert ihren eigenen. Die Reihe beginnt bei <strong>16 GB</strong> und reicht bis <strong>96 GB</strong>, genug Luft für mehrere VMs, ohne sie auszuhungern.
Snapshots und Sicherungen ohne Limit
Ein Snapshot vor einem Update, einer vor einer Konfigurationsänderung: das unterscheidet einen Test von einer Wette. Weder Anzahl noch Häufigkeit werden berechnet, nichts hält also davon ab, einen weiteren zu nehmen.
Bis zu 16 zusätzliche IPv4-Adressen
Jede VM kann ihre eigene öffentliche Adresse führen, statt alles über Portweiterleitungen des Hosts zu schleusen. Nützlich, sobald eine virtuelle Firewall, ein Webserver und ein Fremddienst sauber nebeneinander laufen sollen.
Was man gewinnt
Ein fester Preis
Hundertmal am Tag zu bauen kostet so viel wie zehnmal. Für ein Team, das häufig integriert, wächst der Abstand zur Minutenabrechnung schnell.
Ein Cache, der bleibt
Abhängigkeiten, Image-Schichten, Artefakte: alles, was zuvor jedes Mal neu geladen wurde, bleibt vor Ort. Oft der sichtbarste Gewinn.
Die Maschine wählen
Ein Projekt, das lange kompiliert, profitiert von den 8 vCore des L-Angebots. Bei einem geteilten Dienst nimmt man die Maschine, die man bekommt.
Den Code im Haus behalten
Repository und Artefakte verlassen einen Server, den Sie kontrollieren, nicht — in einem französischen Rechenzentrum. Für manche Projekte ist das keine Nebensache.
Über mehrere Umgebungen testen
Eine VM je Sprach- oder Distributionsversion, alle auf demselben Server, alle aus einem Snapshot zurücksetzbar.
Häufig gestellte Fragen
VM, ohne Zögern. Ein Build führt beliebigen Code aus, mitunter aus einem fremden Beitrag. Eine VM schottet diesen Code vom Rest des Servers ab, ein geteilter Container weit weniger.
Das L-Angebot für 26,99 € mit 8 vCore passt für zwei bis drei parallele Runner. Steigen Sie auf, wenn Ihre Builds lang sind oder das Team fortlaufend integriert.
Ein Snapshot der frisch eingerichteten VM dient als Referenz. Das Zurückspielen dauert Sekunden und garantiert, dass kein Build Rückstände hinterlassen hat.
Für den Ausführungsteil ja. Oberfläche, Repository-Verwaltung und Orchestrierung bleiben bei Ihrem Anbieter: Sie verlagern nur die Maschine, die arbeitet.