- Ubicloud propose des runners managés pour GitHub Actions et affirme qu’en ne modifiant qu’une seule ligne dans un workflow, on peut conserver son mode d’utilisation existant tout en améliorant la vitesse de build et les coûts
- Les tarifs commencent à 0,0010 $ par minute pour Standard et 0,0016 $ par minute pour Premium, soit des coûts respectivement 85 % et 70 % inférieurs à ceux des GitHub-hosted runners
- L’offre Standard repose sur AMD EPYC Genoa avec 30 Go de stockage de cache gratuit, tandis que Premium repose sur AMD Ryzen 9 avec 100 Go de stockage de cache gratuit
- La sécurité s’articule autour de VM entièrement isolées basées sur Linux KVM, de VM éphémères par job, de la configuration Just-In-Time des runners GitHub, du chiffrement et de la rotation des clés
- Ubicloud se positionne comme un cloud open source ; il est possible de consulter le code source sur GitHub ou, si nécessaire, de gérer directement ses propres runners
Mode d’intégration avec GitHub Actions
- Ubicloud propose des runners managés pour GitHub Actions, intégrés en modifiant une seule ligne de configuration du runner dans les workflows GitHub
- L’offre inclut 1 250 minutes gratuites par mois
- Les principaux avantages mis en avant sont « démarrer en 5 minutes », « 2× plus rapide » et « 4 à 7× moins cher »
- L’intégration peut être lancée via la documentation de démarrage rapide
Tarifs et caractéristiques des runners
-
Runners Standard
- Le tarif de départ est de 0,0010 $ par minute
- Ubicloud met en avant un coût inférieur de 85 % à celui des GitHub-hosted runners
- Utilise des CPU basés sur AMD EPYC Genoa
- Fournit 30 Go de stockage de cache gratuit
-
Runners Premium
- Le tarif de départ est de 0,0016 $ par minute
- Ubicloud met en avant un coût inférieur de 70 % à celui des GitHub-hosted runners
- Utilise des CPU basés sur AMD Ryzen 9
- Fournit 100 Go de stockage de cache gratuit
-
Prix selon le matériel
- 2 vCPU, 8 Go de RAM : Standard 0,0010 $/min, Premium 0,0016 $/min
- 4 vCPU, 16 Go de RAM : Standard 0,0020 $/min, Premium 0,0032 $/min
- 8 vCPU, 32 Go de RAM : Standard 0,0040 $/min, Premium 0,0064 $/min
- 16 vCPU, 64 Go de RAM : Standard 0,0080 $/min, Premium 0,0128 $/min
Isolation et sécurité
- Le modèle de sécurité s’appuie sur des VM isolées basées sur Linux KVM et des VM éphémères pour chaque job
- Les secrets éphémères sont traités via la configuration Just-In-Time des runners GitHub
- Il inclut le chiffrement au repos et en transit, la rotation intégrée des clés, la configuration automatique du pare-feu et les alertes automatiques de vulnérabilités
Orientation cloud open source
- Ubicloud est un cloud open source qui vise à offrir une alternative de fournisseur cloud, à l’image de Linux face aux systèmes d’exploitation propriétaires
- Le code source est disponible sur GitHub
- Les utilisateurs peuvent gérer directement leurs propres runners s’ils le souhaitent
1 commentaires
Avis sur Hacker News
Félicitations pour le lancement. Ça a l’air intéressant, et les prix affichés sur la landing page semblent très bons.
Tout ce que je fais actuellement est open source avec GitHub Actions gratuit, donc je ne fais pas partie de la cible pour le moment, mais je me demande pourquoi c’est moins cher et plus rapide / où est le piège.
Je vois aussi un problème visuel de manque de padding horizontal entre 990 px et environ 1200 px, des largeurs de fenêtre courantes sur un MBP 14".
La phrase « Ubicloud est un cloud open source. Voyez-le comme une alternative ouverte aux fournisseurs de cloud, tout comme Linux est une alternative aux systèmes d’exploitation propriétaires » était difficile à comprendre, et les premières fois j’ai cru qu’elle parlait d’une alternative à Linux.
Il serait plus clair de commencer par dire concrètement de quoi il s’agit, comme dans la section « What is Ubicloud? » de la documentation : « fournit des fonctionnalités IaaS au-dessus de fournisseurs de location bare metal comme Hetzner, OVH ou AWS Bare Metal, et est aussi proposé comme service managé ».
Il me semble qu’il y avait un vieil adage selon lequel, pour du marketing destiné aux ingénieurs, dire concrètement ce que c’est marche mieux que de parler d’utilité, et ici les deux semblent nécessaires. Ce serait bien de dire à la fois ce que c’est réellement et pourquoi c’est moins cher et meilleur.
Dans ce paragraphe, il y a aussi une faute avec un espace manquant, comme
systems.Ubicloud.Dans « Fast runs even at this price point », il vaudrait mieux enlever
point. « Price point » n’est pas un synonyme de « price », et comme vous dites déjà que c’est moins cher, il vaudrait mieux remplacer le titre de section par « Faster than GitHub Actions » sans tagline.Le paragraphe « Ubicloud is an open, free, and portable cloud... » est lui aussi flou. Quelque chose comme « Ubicloud est un cloud ouvert et gratuit. Vous pouvez l’exécuter chez l’hébergeur de votre choix, ou apporter votre propre matériel. Consultez le code source sur GitHub ! » me paraît plus clair.
À première vue, le tarif de base est autour de 0,008 $ par minute, ce qui n’est pas un ratio particulièrement étrange même comparé aux tarifs horaires d’EC2.
J’ai déjà travaillé sur un projet où le simple fait de lancer une seule instance EC2 et de la connecter à Actions avait fortement réduit les coûts tout en améliorant les temps de build.
Nous utilisons les builders Ubicloud depuis quelques mois sur un projet Rust [0], et ça fonctionne plutôt bien. Le temps de CI est passé de 10–15 minutes à 6–7 minutes, et le coût de 300 $ à 30 $ par mois.
Ce qui m’a surpris, c’est la lenteur de la sauvegarde/restauration du cache. Les CPU des machines étant bons, il était plus rapide pour nous de désactiver complètement le cache et de tout refaire à chaque build.
[0] https://github.com/ArroyoSystems/arroyo
Ce workflow peut tourner en moins de 5 minutes sur une machine éphémère AWS, au même prix qu’Ubicloud : https://github.com/runs-on/arroyo/actions/runs/7723361513/jo...
J’utilise des systèmes de fichiers pour des applications hautes performances, et ZFS s’est souvent révélé être le goulot d’étranglement par rapport à des configurations plus simples comme XFS ± mdadm ± chiffrement.
C’est un point controversé, mais on trouve aussi des résultats similaires : https://klarasystems.com/articles/virtualization-showdown-fr... : « Cela peut surprendre beaucoup de lecteurs, mais personnellement cela ne m’a pas surpris. J’ai testé les performances de stockage invité d’OpenZFS et de Linux KVM pendant plus de dix ans, et les zvol ont à chaque fois eu des performances relativement mauvaises. »
OpenZFS semble aussi avoir commencé à envisager des optimisations adaptées aux disques modernes (SSD, NVMe), dont les caractéristiques de performance sont très différentes de celles des disques rotatifs pour lesquels ZFS a été créé.
Le résumé sur SPDK dit : « pour réduire le temps de provisionnement des VM, nous avons remplacé le système de fichiers de l’OS hôte, ext4, par btrfs », puis « après le passage du système de fichiers hôte à btrfs, les performances disque ont nettement chuté et le débit est tombé à environ un tiers de celui d’ext4 ».
Le problème d’Ubicloud semble concerner plus largement les systèmes de fichiers en copie sur écriture, et il est intéressant qu’ils aient choisi une variante un peu différente appelée CoA, mais je me demande s’ils ont envisagé une alternative plus simple consistant à mettre un overlay au-dessus de systèmes de fichiers journalisés comme XFS ou Ext4.
Ou encore, il semble possible d’utiliser UFS2 + snapshots pour restaurer un état de test initialisé et y revenir entre chaque test.
Si les clients estiment qu’il vaut mieux désactiver le cache, cela semble indiquer que CoA rencontre des problèmes similaires à CoW.
Personnellement, j’aurais probablement essayé du SR-IOV avec un namespace par client et je m’en serais tenu là, plutôt que d’ajouter de la complexité, mais il devait sûrement y avoir de bonnes raisons, et je serais curieux de les connaître.
Je suis Ozgun, l’un des fondateurs d’Ubicloud.
Aujourd’hui, plusieurs dizaines de clients utilisent les runners Ubicloud en production, et nous sommes en train de concevoir la couche de cache. Nous publions cela parce que nous aimerions recueillir des avis sur des aspects comme le registre d’instances Docker, le cache de couches Docker et le cache de paquets.
Plus largement, si vous avez des points à partager sur le thème d’un cloud ouvert et portable, n’hésitez pas à nous en faire part.
Dans GitHub Actions, CircleCI, etc., ajouter des appels réseau coûteux pour mettre manuellement les couches en cache a toujours pris beaucoup de temps, et semble pousser beaucoup de gens à supprimer complètement le cache.
Ce serait assez utile pour les utilisateurs d’autres clones de GitHub Actions comme act [0].
[0]: https://github.com/nektos/act
J’utilise BuildJet [0] depuis plus d’un an avec satisfaction.
Nous avons économisé plus de 25 k$ de coûts de CI par rapport à GH Actions, et comme BuildJet utilise aussi les puissants serveurs bare metal de Hetzner, les temps de build ont été réduits d’environ 94 %.
Nous en sommes vraiment satisfaits, et c’est une bonne chose de voir davantage d’entreprises arriver sur ce marché.
[0] https://buildjet.com
La plus grosse part de nos coûts GHA concerne l’exécution macOS. Proposez-vous macOS en service managé, ou prévoyez-vous de le faire ? Je suis aussi curieux de savoir à quel point ce serait moins cher que GitHub.
Ubicloud fonctionne au-dessus de fournisseurs bare metal, et ceux-ci ne louent pas de matériel Mac.
Techniquement, il est possible de faire tourner des VM macOS sur arm64, mais notre interprétation du contrat de licence utilisateur final (EULA) d’Apple est que cela n’est pas autorisé.
Ce dépôt rassemble de bonnes références à ce sujet : https://github.com/kholia/OSX-KVM?tab=readme-ov-file#is-this...
Les conditions d’OS X disent ceci :
3. Location pour services développeur autorisés. A. Location. Vous pouvez louer ou sous-louer l’intégralité de l’Apple Software valablement licencié à une personne ou une organisation (chacune, un « Lessee »), sous réserve que toutes les conditions suivantes soient respectées : (i) l’Apple Software loué doit être utilisé uniquement dans le but de fournir des services développeur autorisés, et chaque Lessee doit examiner les conditions de cette licence et accepter d’y être lié ; (ii) chaque période de location doit durer au minimum 24 heures consécutives
Ils sont environ 25 % plus rapides que les runners hébergés par GitHub de même catégorie, et coûtent 50 % moins cher par minute.
[1] https://docs.warpbuild.com/runners#macos-m2-pro-on-arm64
Chez Resmo, nous utilisons Ubicloud depuis un certain temps et c’est effectivement 10 fois moins cher. Nous avons doublé la taille des instances pour gagner un peu en performance, mais cela reste 5 fois moins cher.
La raison principale est que la plateforme est hébergée sur des instances dédiées Hetzner.
Chez PeerDB[1], nous utilisons les runners Ubicloud depuis un moment. Le rapport qualité-prix est bon, et les runners ARM nous ont particulièrement aidés à réduire les coûts de CI.
L’équipe est aussi réactive : elle a ajouté le support des runners ARM quelques semaines après notre demande.
[1] https://github.com/PeerDB-io/peerdb
Ce qui est frustrant dans la tarification des runners GitHub Actions, c’est la facturation à la minute. Ne pourriez-vous pas facturer à la seconde ? Même avec un minimum d’une minute, ce serait bien de facturer à la seconde ensuite.
J’imagine que c’est fait ainsi pour couvrir le temps de redémarrage de la VM entre les jobs.
Comme les temps de redémarrage des VM s’accumulent vite, c’est probablement la raison.
Cela dit, certains utilisateurs lancent des tâches de lint d’environ 2 secondes sur des instances 16 vCPU, donc nous avons conservé la facturation minimale d’une minute.
J’aimerais qu’on n’appelle pas la licence Elastic open source. C’est bien que le code source soit disponible, mais ce n’est pas une licence open source.
À en juger par les réponses, cette information semble dater, et le projet semble désormais utiliser l’AGPL.
Félicitations pour le lancement. J’espère qu’Ubicloud aura encore plus de succès que votre précédent projet, Citus.