Presentación en HN: runner open source x64 y Arm para GitHub
(ubicloud.com)- Ubicloud ofrece runners administrados para GitHub Actions y afirma que, cambiando solo 1 línea en el workflow, se puede mantener la forma de uso actual mientras se mejora la velocidad de compilación y el costo
- Los precios comienzan desde $0.0010 por minuto para Standard y $0.0016 por minuto para Premium, y presentan costos 85% y 70% más bajos, respectivamente, frente a los GitHub-hosted runners
- Standard se diferencia por usar AMD EPYC Genoa y 30 GB de almacenamiento de caché gratis, mientras que Premium usa AMD Ryzen 9 y 100 GB de almacenamiento de caché gratis
- La seguridad se basa en VM completamente aisladas sobre Linux KVM, VM efímeras por trabajo, configuración de runners GitHub Just-In-Time, cifrado y rotación de claves
- Ubicloud apunta a ser una nube open source, por lo que se puede revisar el código fuente en GitHub o, si se prefiere, administrar runners propios directamente
Cómo se integra con GitHub Actions
- Ubicloud ofrece runners administrados para GitHub Actions y se integra cambiando 1 línea en la configuración del runner dentro del workflow de GitHub
- Ofrece 1,250 minutos gratis al mes
- Presenta como ventajas principales: “empieza en 5 minutos”, “2 veces más rápido” y “ahorra de 4 a 7 veces”
- La integración puede iniciarse desde la guía de inicio rápido
Precios y especificaciones de los runners
-
Runner Standard
- El precio inicial es de $0.0010 por minuto
- Se promociona como 85% más barato que los GitHub-hosted runners
- Usa CPU basadas en AMD EPYC Genoa
- Incluye 30 GB de almacenamiento de caché gratis
-
Runner Premium
- El precio inicial es de $0.0016 por minuto
- Se promociona como 70% más barato que los GitHub-hosted runners
- Usa CPU basadas en AMD Ryzen 9
- Incluye 100 GB de almacenamiento de caché gratis
-
Precios por hardware
- 2 vCPU, 8 GB RAM: Standard $0.0010/min, Premium $0.0016/min
- 4 vCPU, 16 GB RAM: Standard $0.0020/min, Premium $0.0032/min
- 8 vCPU, 32 GB RAM: Standard $0.0040/min, Premium $0.0064/min
- 16 vCPU, 64 GB RAM: Standard $0.0080/min, Premium $0.0128/min
Aislamiento y seguridad
- El modelo de seguridad se centra en VM aisladas basadas en Linux KVM y VM efímeras por trabajo
- Maneja secretos de un solo uso mediante la configuración de runners GitHub Just-In-Time
- Incluye cifrado en reposo y en tránsito, rotación de claves integrada, configuración automática de firewall y alertas automáticas de vulnerabilidades
Enfoque de nube open source
- Ubicloud es una nube open source que busca ser una alternativa de proveedor cloud para Linux frente a sistemas operativos propietarios
- El código fuente puede revisarse en GitHub
- Si se desea, los usuarios pueden administrar sus propios runners directamente
1 comentarios
Opiniones de Hacker News
Felicidades por el lanzamiento. Se ve interesante y, en la landing page, el precio se ve muy bueno.
Todo lo que hago ahora es open source con GitHub Actions gratis, así que por ahora no soy el cliente objetivo, pero me da curiosidad por qué es más barato y rápido / cuál es la trampa.
También veo un problema visual por falta de padding horizontal en el rango de 990 px a alrededor de 1200 px, tamaños de ventana comunes en una MBP de 14".
La frase “Ubicloud es una nube open source. Piénsenla como una alternativa abierta a los proveedores de nube, así como Linux es una alternativa a los sistemas operativos propietarios” me costó entenderla, y las primeras veces pensé que estaban diciendo que era una alternativa a Linux.
Sería más claro decir primero concretamente qué es, como en la sección “What is Ubicloud?” de la documentación: “ofrece funciones de IaaS sobre proveedores de alquiler de bare metal como Hetzner, OVH y AWS Bare Metal, y también se ofrece como servicio administrado”.
Creo que había un viejo dicho de que, en marketing dirigido a ingenieros, funciona mejor decir concretamente qué es algo que hablar de su utilidad, y aquí parece que hacen falta ambas cosas. Estaría bueno decir tanto cuál es realmente su identidad como por qué es más barato y mejor.
En ese párrafo también hay un typo donde falta un espacio, como
systems.Ubicloud.En “Fast runs even at this price point”, convendría quitar
point. “Price point” no es sinónimo de “price”, y como ya dijeron que es más barato, sería mejor cambiar el título de la sección a “Faster than GitHub Actions” sin tagline.El párrafo “Ubicloud is an open, free, and portable cloud...” también es difuso. Algo como “Ubicloud es una nube abierta y gratuita. Puedes ejecutarla en el proveedor de hosting que prefieras o traer tu propio hardware. ¡Revisa el código fuente en GitHub!” parece más claro.
Mirándolo por encima, la tarifa base parece ser de unos $0.008 por minuto, que no es una proporción demasiado rara si se compara con los precios por hora de EC2.
Una vez trabajé en un proyecto donde con solo levantar una instancia EC2 y conectarla a Actions redujimos mucho los costos y también mejoramos los tiempos de build.
En el proyecto Rust [0] llevamos varios meses usando builders de Ubicloud y han funcionado bastante bien. El tiempo de CI bajó de 10-15 minutos a 6-7 minutos, y el costo pasó de $300 al mes a $30.
Lo que me sorprendió fue que guardar/restaurar cachés es lento. Como la CPU de las máquinas es buena, para nosotros fue más rápido apagar por completo la caché y rehacer todo en cada build.
[0] https://github.com/ArroyoSystems/arroyo
Este workflow puede correr en menos de 5 minutos en una máquina efímera de AWS al mismo precio que Ubicloud: https://github.com/runs-on/arroyo/actions/runs/7723361513/jo...
Uso sistemas de archivos para aplicaciones de alto rendimiento, y muchas veces ZFS se vuelve un cuello de botella frente a configuraciones más simples como XFS ± mdadm ± cifrado.
Es un punto controversial, pero también hay resultados similares: https://klarasystems.com/articles/virtualization-showdown-fr... : “Puede sorprender a muchos lectores, pero personalmente no me sorprendió. He probado el rendimiento de almacenamiento de invitados con OpenZFS y Linux KVM durante más de 10 años, y los zvol siempre han rendido relativamente mal”.
Parece que OpenZFS también empezó a considerar optimizaciones para unidades modernas (SSD, NVMe), cuyas características de rendimiento son muy distintas de los discos giratorios para los que se creó ZFS.
En el resumen de SPDK dicen: “cambiamos el sistema de archivos del SO host de ext4 a btrfs para reducir el tiempo de aprovisionamiento de VMs”, y “al cambiar el sistema de archivos del host a btrfs, el rendimiento de disco cayó de forma notable y el throughput quedó en aproximadamente 1/3 del de ext4”.
El problema de Ubicloud parece estar relacionado con los sistemas de archivos copy-on-write en general, y es interesante que hayan elegido una variante algo distinta llamada CoA, pero me pregunto si evaluaron una alternativa más simple como poner un overlay sobre un sistema de archivos con journaling como XFS o Ext4.
O también parece posible usar UFS2 + snapshots para restaurar un estado inicial listo para pruebas y volver a ese estado entre pruebas.
Si los clientes sienten que les conviene apagar la caché, eso parece indicar que CoA tiene problemas parecidos a CoW.
Personalmente, en vez de sumar complejidad, creo que habría probado SR-IOV con namespaces por cliente y lo habría dejado ahí, pero seguramente había buenas razones, y me da curiosidad saber cuáles fueron.
Soy Ozgun, uno de los fundadores de Ubicloud.
Actualmente decenas de clientes usan runners de Ubicloud en producción, y ahora estamos diseñando una capa de caché. Lo publicamos porque queremos escuchar opiniones sobre aspectos como el registro de instancias de Docker, la caché de capas de Docker y la caché de paquetes.
En términos más amplios, también nos gustaría saber si tienen puntos sobre el tema de una nube abierta y portátil.
En GitHub Actions runners, CircleCI, etc., la estrategia de agregar llamadas de red costosas para cachear capas manualmente siempre ha consumido mucho tiempo, y parece que lleva a mucha gente a quitar la caché por completo.
Sería bastante útil para usuarios de otros clones de GitHub Actions como act [0].
[0]: https://github.com/nektos/act
He usado BuildJet [0] con satisfacción durante más de un año.
Ahorramos más de $25k en costos de CI frente a GH Actions, y como BuildJet también usa los potentes servidores bare metal de Hetzner, los tiempos de build se redujeron alrededor de un 94%.
Estamos muy contentos, y da gusto ver que haya más empresas en el mercado.
[0] https://buildjet.com
La mayor parte de nuestros costos de GHA corresponde a ejecuciones en MacOS. ¿Ofrecen MacOS como servicio administrado, o tienen planes de hacerlo? También me interesa saber cuánto más barato sería que GitHub.
Ubicloud funciona sobre proveedores de bare metal, y ellos no alquilan hardware Mac.
Técnicamente se pueden ejecutar VMs de MacOS en arm64, pero interpretamos que el acuerdo de licencia de usuario final (EULA) de Apple no permite hacerlo.
Este repositorio tiene referencias bien organizadas al respecto: https://github.com/kholia/OSX-KVM?tab=readme-ov-file#is-this...
Los términos de OS X dicen lo siguiente:
3. Alquiler para servicios de desarrollador permitidos. A. Alquiler. Puedes alquilar o subalquilar la totalidad del Apple Software con licencia válida a una persona u organización (cada una, un “Arrendatario”), siempre que se cumplan todas las condiciones siguientes: (i) el Apple Software alquilado debe usarse únicamente con el fin de prestar servicios de desarrollador permitidos, y cada Arrendatario debe revisar estos términos de licencia y aceptar quedar sujeto a ellos; (ii) cada período de alquiler debe ser de al menos 24 horas consecutivas.
Son aproximadamente un 25% más rápidos que los runners equivalentes hospedados por GitHub y cuestan 50% menos por minuto.
[1] https://docs.warpbuild.com/runners#macos-m2-pro-on-arm64
En Resmo hemos usado Ubicloud durante un tiempo y realmente es 10 veces más barato. Aumentamos el tamaño de la instancia al doble para obtener un poco más de rendimiento, pero aun así sigue siendo 5 veces más barato.
La razón principal es que la plataforma está alojada sobre instancias dedicadas de Hetzner.
En PeerDB[1] hemos usado runners de Ubicloud durante un tiempo. Tienen buena relación costo-beneficio, y en particular los runners ARM ayudaron a reducir los costos de CI.
El equipo también responde rápido, y agregaron soporte para runners ARM pocas semanas después de que se lo pedimos.
[1] https://github.com/PeerDB-io/peerdb
Lo frustrante de los precios de GitHub Actions runners es la facturación por minuto. ¿No podrían cobrar por segundo? Aunque hubiera un mínimo de 1 minuto, estaría bien que después de eso cobraran por segundo.
Supongo que lo hacen así para cubrir el tiempo en que se reinicia la VM entre jobs.
Probablemente esa sea la razón, porque los tiempos de reinicio de VM se acumulan rápido.
Aun así, mantenemos una facturación mínima de 1 minuto porque también hay usuarios que ejecutan tareas de lint de unos 2 segundos en instancias de 16 vCPU.
Preferiría que no llamaran open source a la licencia de Elastic. Es bueno que el código fuente esté disponible, pero no es una licencia open source.
Por las respuestas, parece que esta información está desactualizada y que ahora el proyecto usa AGPL.
Felicitaciones por el lanzamiento. Espero que Ubicloud tenga más éxito que su proyecto anterior, Citus.