HN-Vorstellung: Open-Source-x64- und -Arm-GitHub-Runner
(ubicloud.com)- Ubicloud bietet verwaltete Runner für GitHub Actions an und wirbt damit, dass sich Build-Geschwindigkeit und Kosten verbessern lassen, während die bestehende Nutzung beibehalten wird, wenn im Workflow nur eine Zeile geändert wird
- Die Preise beginnen bei Standard mit $0.0010 pro Minute und bei Premium mit $0.0016 pro Minute; gegenüber GitHub-hosted runners werden jeweils 85 % bzw. 70 % geringere Kosten angegeben
- Standard nutzt AMD EPYC Genoa und 30 GB kostenlosen Cache-Speicher, Premium nutzt AMD Ryzen 9 und 100 GB kostenlosen Cache-Speicher
- Die Sicherheit basiert auf vollständig isolierten VMs auf Linux-KVM-Basis, einmaligen VMs pro Job, GitHub-Just-In-Time-Runner-Konfiguration sowie Verschlüsselung und Schlüsselrotation
- Ubicloud versteht sich als Open-Source-Cloud; der Quellcode kann auf GitHub eingesehen werden, und bei Bedarf lassen sich eigene Runner selbst verwalten
GitHub-Actions-Integrationsweise
- Ubicloud bietet verwaltete Runner für GitHub Actions an; die Integration erfolgt, indem in einem GitHub-Workflow die Runner-Konfiguration in einer Zeile geändert wird
- Es gibt 1.250 kostenlose Minuten pro Monat
- Als wichtigste Vorteile werden „in 5 Minuten starten“, „2x schneller“ und „4- bis 7-mal günstiger“ genannt
- Über die Schnellstart-Dokumentation kann die Integration begonnen werden
Preise und Runner-Spezifikationen
-
Standard-Runner
- Der Einstiegspreis beträgt $0.0010 pro Minute
- Gegenüber GitHub-hosted runners werden 85 % geringere Kosten angegeben
- Es werden CPUs auf Basis von AMD EPYC Genoa verwendet
- Es gibt 30 GB kostenlosen Cache-Speicher
-
Premium-Runner
- Der Einstiegspreis beträgt $0.0016 pro Minute
- Gegenüber GitHub-hosted runners werden 70 % geringere Kosten angegeben
- Es werden CPUs auf Basis von AMD Ryzen 9 verwendet
- Es gibt 100 GB kostenlosen Cache-Speicher
-
Preise nach Hardware
- 2 vCPU, 8GB RAM: Standard $0.0010/min, Premium $0.0016/min
- 4 vCPU, 16GB RAM: Standard $0.0020/min, Premium $0.0032/min
- 8 vCPU, 32GB RAM: Standard $0.0040/min, Premium $0.0064/min
- 16 vCPU, 64GB RAM: Standard $0.0080/min, Premium $0.0128/min
Isolation und Sicherheit
- Das Sicherheitsmodell konzentriert sich auf isolierte VMs auf Linux-KVM-Basis und einmalige VMs pro Job
- Über die GitHub-Just-In-Time-Runner-Konfiguration werden einmalige Secrets verarbeitet
- Enthalten sind Verschlüsselung bei Speicherung und Übertragung, integrierte Schlüsselrotation, automatische Firewall-Konfiguration und automatische Benachrichtigungen über Schwachstellen
Ausrichtung auf eine Open-Source-Cloud
- Ubicloud versteht sich als Open-Source-Cloud und will eine Alternative für Cloud-Anbieter sein, ähnlich wie Linux eine Alternative zu proprietären Betriebssystemen ist
- Der Quellcode ist auf GitHub einsehbar
- Nutzer können auf Wunsch ihre eigenen Runner selbst verwalten
1 Kommentare
Hacker-News-Kommentare
Glückwunsch zum Launch. Sieht interessant aus, und der Preis auf der Landingpage wirkt sehr gut
Ich nutze derzeit ausschließlich kostenlose GitHub Actions für Open Source, bin also aktuell nicht die Zielgruppe, aber ich frage mich, warum es günstiger und schneller ist bzw. wo der Haken liegt
Mir ist auch ein visuelles Problem mit zu wenig horizontalem Padding im Bereich von 990 px bis etwa 1200 px aufgefallen, was auf einem 14" MBP eine gängige Fensterbreite ist
Der Satz „Ubicloud ist eine Open-Source-Cloud. Betrachten Sie es als die offene Alternative zu Cloud-Anbietern, so wie Linux die Alternative zu proprietären Betriebssystemen ist“ war schwer zu verstehen, und anfangs dachte ich mehrmals, es sei von einer Alternative zu Linux die Rede
Es wäre klarer, zuerst konkret zu sagen, was es ist, wie im Abschnitt „What is Ubicloud?“ der Doku: etwa „bietet IaaS-Funktionen auf Bare-Metal-Mietanbietern wie Hetzner, OVH und AWS Bare Metal und wird auch als Managed Service angeboten“
Ich meine, es gibt diese alte Marketingweisheit für Engineers, dass man eher konkret sagen sollte, was etwas ist, statt nur den Nutzen zu verkaufen, und hier scheint beides nötig zu sein. Es wäre gut, sowohl die tatsächliche Einordnung als auch zu erklären, warum es günstiger und besser ist
In dem Absatz gibt es auch einen Tippfehler ohne Leerzeichen wie
systems.UbicloudBei „Fast runs even at this price point“ würde ich
pointstreichen. „Price point“ ist nicht einfach ein Synonym für „price“, und da ohnehin schon gesagt wird, dass es günstiger ist, wäre es vielleicht besser, den Abschnittstitel ohne Tagline in „Faster than GitHub Actions“ zu ändernAuch der Absatz „Ubicloud is an open, free, and portable cloud...“ bleibt vage. Klarer wäre vielleicht etwas wie: „Ubicloud ist eine offene, kostenlose Cloud. Sie können sie bei einem Hosting-Anbieter Ihrer Wahl betreiben oder Ihre eigene Hardware mitbringen. Sehen Sie sich den Source Code auf GitHub an!“
Auf den ersten Blick liegt der Basispreis wohl bei etwa 0,008 $ pro Minute, und selbst verglichen mit den EC2-Stundensätzen wirkt das Verhältnis nicht besonders ungewöhnlich
Ich habe schon ein Projekt gemacht, bei dem allein das Starten einer einzelnen EC2-Instanz und deren Anbindung an Actions die Kosten massiv gesenkt und die Build-Zeit verbessert hat
Wir nutzen seit einigen Monaten Ubicloud-Builder für ein Rust-Projekt [0], und es hat ziemlich gut funktioniert. Die CI-Zeit ist von 10–15 Minuten auf 6–7 Minuten gesunken, und die Kosten sind von 300 $ pro Monat auf 30 $ gefallen
Überraschend war, dass das Speichern/Wiederherstellen des Caches langsam ist. Die CPU der Maschinen ist so gut, dass es für uns schneller war, den Cache komplett abzuschalten und bei jedem Build alles neu zu machen
[0] https://github.com/ArroyoSystems/arroyo
Dieser Workflow kann auf kurzlebigen AWS-Maschinen in unter 5 Minuten zum gleichen Preis wie bei Ubicloud laufen: https://github.com/runs-on/arroyo/actions/runs/7723361513/jo...
Ich habe Dateisysteme für High-Performance-Anwendungen genutzt, und ZFS war oft ein Flaschenhals gegenüber einfacheren Setups wie XFS ± mdadm ± Verschlüsselung
Das ist ein strittiger Punkt, aber es gibt ähnliche Ergebnisse: https://klarasystems.com/articles/virtualization-showdown-fr... : „Für viele Leser mag das überraschend sein, für mich persönlich war es das nicht. Ich teste seit über zehn Jahren die Gast-Storage-Performance von OpenZFS und Linux KVM, und zvol schnitt jedes Mal vergleichsweise schlecht ab“
Offenbar prüft auch OpenZFS inzwischen Optimierungen für moderne Laufwerke (SSD, NVMe), deren Performance-Eigenschaften sich stark von den rotierenden Festplatten unterscheiden, für die ZFS ursprünglich entwickelt wurde
In der SPDK-Zusammenfassung heißt es: „Um die VM-Bereitstellungszeit zu verkürzen, haben wir das Host-OS von ext4 auf btrfs umgestellt“ und „Nachdem wir das Host-Dateisystem auf btrfs umgestellt hatten, fiel die Disk-Performance deutlich ab und der Durchsatz lag nur noch bei etwa einem Drittel von ext4“
Das Problem bei Ubicloud scheint allgemeiner mit Copy-on-Write-Dateisystemen zusammenzuhängen. Die Wahl einer leicht abgewandelten Variante namens CoA ist interessant, aber ich frage mich, ob auch einfachere Alternativen mit Overlays auf Journaling-Dateisystemen wie XFS oder ext4 geprüft wurden
Oder man könnte vielleicht UFS2 + Snapshots verwenden, um einen initialisierten testbereiten Zustand wiederherzustellen und zwischen den Tests immer wieder auf diesen Stand zurückzusetzen
Wenn Kunden das Gefühl haben, dass das Abschalten des Caches besser ist, deutet das darauf hin, dass CoA ähnliche Probleme wie CoW hat
Persönlich hätte ich wahrscheinlich einfach SR-IOV mit kundenspezifischen Namespaces ausprobiert und es dabei belassen, aber es gab sicher gute Gründe dagegen, und die würden mich interessieren
Einer der Ubicloud-Gründer hier, Ozgun.
Derzeit nutzen bereits Dutzende Kunden Ubicloud-Runner in der Produktion, und wir entwerfen gerade die Caching-Schicht. Ich veröffentliche das, weil ich gern Meinungen zu Dingen wie Docker-Instanz-Registry, Docker-Layer-Cache und Paket-Cache hören würde.
Allgemeiner freue ich mich auch über Hinweise zum Thema offene und portable Cloud.
In GitHub-Action-Runnern, CircleCI usw. hat das Hinzufügen teurer Netzwerkaufrufe, um Layer manuell zu cachen, immer viel Zeit gekostet, und ich glaube, das bringt viele Leute dazu, das Caching ganz zu entfernen.
Das wäre für Nutzer anderer GitHub-Actions-Klone wie act [0] ziemlich nützlich.
[0]: https://github.com/nektos/act
Ich nutze BuildJet [0] seit über einem Jahr zufrieden.
Im Vergleich zu GH Actions habe ich über $25k an CI-Kosten gespart, und da BuildJet ebenfalls die leistungsstarken Bare-Metal-Server von Hetzner nutzt, haben sich die Build-Zeiten um etwa 94 % reduziert.
Ich bin wirklich zufrieden und freue mich über mehr Unternehmen in diesem Markt.
[0] https://buildjet.com
Der größte Posten bei unseren GHA-Kosten ist die MacOS-Ausführung. Bietet ihr MacOS als Managed Service an oder plant ihr das, und wie viel günstiger wäre es als GitHub?
Ubicloud läuft auf Bare-Metal-Anbietern, und diese vermieten keine Mac-Hardware.
Technisch könnte man zwar MacOS-VMs auf arm64 ausführen, aber nach unserer Auslegung der Apple-Endbenutzer-Lizenzvereinbarung (EULA) darf man das nicht.
In diesem Repository sind die relevanten Verweise gut zusammengetragen: https://github.com/kholia/OSX-KVM?tab=readme-ov-file#is-this...
In den OS-X-Bedingungen steht:
3. Vermietung für zulässige Entwicklerdienste. A. Vermietung. Die vollständig gültig lizenzierte Apple Software darf an eine Einzelperson oder Organisation (jeweils ein „Lessee“) vermietet oder weitervermietet werden, sofern alle folgenden Bedingungen erfüllt sind: (i) die vermietete Apple Software darf ausschließlich zum Zweck der Bereitstellung zulässiger Entwicklerdienste genutzt werden, und jeder Lessee muss diese Lizenzbedingungen prüfen und ihrer Bindung zustimmen; (ii) jede Mietdauer muss mindestens 24 aufeinanderfolgende Stunden betragen.
Sie sind etwa 25 % schneller als vergleichbare von GitHub gehostete Runner und kosten pro Minute 50 % weniger.
[1] https://docs.warpbuild.com/runners#macos-m2-pro-on-arm64
Wir verwenden bei Resmo seit einiger Zeit Ubicloud, und es ist tatsächlich 10-mal günstiger. Wir haben die Instanzgröße verdoppelt, um etwas mehr Leistung zu bekommen, und trotzdem ist es noch 5-mal günstiger.
Der Hauptgrund ist, dass die Plattform auf dedizierten Hetzner-Instanzen gehostet wird.
Wir bei PeerDB[1] nutzen Ubicloud-Runner schon eine Weile. Das Preis-Leistungs-Verhältnis ist gut, und besonders die ARM-Runner haben geholfen, die CI-Kosten zu senken.
Das Team reagiert außerdem schnell und hat innerhalb weniger Wochen nach unserer Anfrage ARM-Runner-Unterstützung hinzugefügt.
[1] https://github.com/PeerDB-io/peerdb
Frustrierend an den Preisen für GitHub-Action-Runner ist die minutengenaue Abrechnung. Könnt ihr nicht sekundengenau abrechnen? Selbst wenn es bei mindestens 1 Minute bleibt, wäre danach eine Abrechnung pro Sekunde gut.
Vermutlich macht GitHub das so, um die Zeit für den Neustart der VM zwischen den Jobs abzudecken.
Die Zeit für VM-Neustarts summiert sich schnell, daher ist das vermutlich der Grund.
Allerdings gibt es auch Nutzer, die einen nur etwa 2 Sekunden dauernden Lint-Job auf einer Instanz mit 16 vCPU ausführen, deshalb haben wir die Mindestabrechnung von 1 Minute beibehalten.
Ich fände es besser, wenn man die Elastic-Lizenz nicht als Open Source bezeichnen würde. Es ist gut, dass der Quellcode offen einsehbar ist, aber es ist keine Open-Source-Lizenz.
Den Antworten nach zu urteilen, scheint diese Information veraltet zu sein, und das Projekt verwendet inzwischen offenbar die AGPL.
Glückwunsch zum Launch. Ich hoffe, Ubicloud wird noch erfolgreicher als euer vorheriges Projekt Citus.