- A Ubicloud oferece runners gerenciados para GitHub Actions e afirma que é possível melhorar a velocidade de build e o custo mantendo a forma de uso atual ao trocar apenas 1 linha no workflow
- Os preços começam em Standard $0.0010 por minuto e Premium $0.0016 por minuto, com custos 85% e 70% menores, respectivamente, em comparação com os GitHub-hosted runners
- O Standard usa AMD EPYC Genoa e 30 GB de armazenamento de cache gratuito, enquanto o Premium usa AMD Ryzen 9 e 100 GB de armazenamento de cache gratuito
- A segurança é centrada em VMs totalmente isoladas com base em Linux KVM, VMs efêmeras por job, configuração de runner GitHub Just-In-Time, criptografia e rotação de chaves
- A Ubicloud se propõe a ser uma nuvem open source, permitindo verificar o código-fonte no GitHub ou, se necessário, gerenciar seus próprios runners diretamente
Forma de integração com GitHub Actions
- A Ubicloud oferece runners gerenciados para GitHub Actions, integrados por meio da troca de 1 linha na configuração do runner no workflow do GitHub
- Oferece 1.250 minutos gratuitos por mês
- Destaca como principais vantagens: “comece em 5 minutos”, “2x mais rápido” e “redução de custo de 4 a 7 vezes”
- A integração pode ser iniciada pela documentação de início rápido
Preços e especificações dos runners
-
Runner Standard
- O preço inicial é $0.0010 por minuto
- Apresenta 85% menor custo que os GitHub-hosted runners
- Usa CPU baseada em AMD EPYC Genoa
- Oferece 30 GB de armazenamento de cache gratuito
-
Runner Premium
- O preço inicial é $0.0016 por minuto
- Apresenta 70% menor custo que os GitHub-hosted runners
- Usa CPU baseada em AMD Ryzen 9
- Oferece 100 GB de armazenamento de cache gratuito
-
Preços por 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
Isolamento e segurança
- O modelo de segurança é centrado em VMs isoladas baseadas em Linux KVM e VMs efêmeras por job
- Usa a configuração de runner GitHub Just-In-Time para lidar com segredos efêmeros
- Inclui criptografia em repouso e em trânsito, rotação de chaves embutida, configuração automática de firewall e alertas automáticos de vulnerabilidade
Proposta de nuvem open source
- A Ubicloud é uma nuvem open source, buscando ser uma alternativa entre provedores de nuvem, assim como o Linux é em relação a sistemas operacionais proprietários
- O código-fonte pode ser consultado no GitHub
- Se quiser, o usuário pode gerenciar seus próprios runners diretamente
1 comentários
Comentários do Hacker News
Parabéns pelo lançamento. Parece interessante, e o preço na landing page parece muito bom
Hoje tudo o que faço usa GitHub Actions gratuito para open source, então no momento não sou o cliente-alvo, mas fiquei curioso para saber por que é mais barato e mais rápido / qual é a pegadinha
Também vi um problema visual de falta de padding horizontal na faixa de 990px até cerca de 1200px, que é um tamanho de janela comum em um MBP de 14"
A frase “Ubicloud é uma nuvem open source. Pense nela como uma alternativa aberta aos provedores de nuvem, assim como o Linux é uma alternativa a sistemas operacionais proprietários” foi difícil de entender, e nas primeiras vezes achei que estivesse dizendo que era uma alternativa ao Linux
Como na seção “What is Ubicloud?” da documentação, seria mais claro dizer primeiro o que é concretamente, algo como “fornece recursos de IaaS sobre provedores de aluguel de bare metal como Hetzner, OVH e AWS Bare Metal, e também é oferecido como serviço gerenciado”
Acho que existe esse velho ditado de que marketing para engenheiros funciona melhor quando fala concretamente o que algo é, e não só sua utilidade, e aqui parece que precisa dos dois. Seria bom explicar junto o que realmente é e por que é mais barato e melhor
Nesse parágrafo também há um erro de digitação sem espaço, como em
systems.UbicloudEm “Fast runs even at this price point”, seria melhor tirar
point. “Price point” não é sinônimo de “price”, e como vocês já dizem que é mais barato, talvez seja melhor mudar o título da seção para “Faster than GitHub Actions” sem taglineO parágrafo “Ubicloud is an open, free, and portable cloud...” também está vago. Algo como “Ubicloud é uma nuvem aberta, gratuita e portátil. Você pode executá-la no provedor de hospedagem que quiser ou usar seu próprio hardware. Confira o código-fonte no GitHub!” parece mais claro
Olhando por alto, a tarifa-base parece ficar em torno de $0.008 por minuto, o que nem parece uma proporção tão estranha mesmo comparando com o preço por hora do EC2
Já trabalhei em um projeto em que só subir uma instância EC2 única e conectá-la ao Actions já reduziu muito o custo e também melhorou o tempo de build
Tenho usado builders da Ubicloud há alguns meses em um projeto Rust [0], e funcionaram muito bem. O tempo de CI caiu de 10~15 minutos para 6~7 minutos, e o custo foi de $300 por mês para $30
O que foi surpreendente é que salvar/restaurar cache era lento. Como a CPU da máquina é boa, para nós foi mais rápido desligar completamente o cache e refazer tudo a cada build
[0] https://github.com/ArroyoSystems/arroyo
Esse workflow pode rodar em menos de 5 minutos em máquinas efêmeras da AWS pelo mesmo preço da Ubicloud: https://github.com/runs-on/arroyo/actions/runs/7723361513/jo...
Já usei filesystems em aplicações de alto desempenho, e muitas vezes o ZFS vira gargalo em comparação com configurações mais simples como XFS ± mdadm ± criptografia
É um ponto controverso, mas há resultados parecidos também: https://klarasystems.com/articles/virtualization-showdown-fr... : “Isso pode surpreender muitos leitores, mas pessoalmente não me surpreendeu. Testo há mais de 10 anos o desempenho de storage de guests com OpenZFS e Linux KVM, e zvol teve desempenho comparativamente ruim em todas as vezes”
Parece que o OpenZFS também começou a considerar otimizações para drives modernos (SSD, NVMe), cujas características de desempenho são muito diferentes dos discos giratórios para os quais o ZFS foi criado
No resumo sobre SPDK, dizem: “trocamos o host OS de ext4 para btrfs para reduzir o tempo de provisionamento de VMs” e “quando mudamos o filesystem do host para btrfs, o desempenho de disco caiu visivelmente, e a vazão ficou em cerca de 1/3 do ext4”
O problema da Ubicloud parece se estender a filesystems copy-on-write de modo geral, e é interessante que tenham escolhido uma variante um pouco diferente chamada CoA, mas fico curioso se consideraram alternativas mais simples, como colocar um overlay sobre filesystems com journaling como XFS ou Ext4
Ou também parece possível usar UFS2 + snapshots para restaurar um estado inicial pronto para testes e voltar a ele entre um teste e outro
Se os clientes acham melhor desligar o cache, isso parece indicar que o CoA também tem problemas parecidos com os do CoW
Pessoalmente, acho que eu teria simplesmente testado SR-IOV com namespaces por cliente e encerrado ali, mas com certeza houve um bom motivo, então fiquei curioso para saber qual foi
Um dos fundadores da Ubicloud aqui, Ozgun.
Hoje, dezenas de clientes já usam os runners da Ubicloud em produção, e no momento estamos projetando a camada de cache. Estou publicando isso porque queria ouvir opiniões sobre pontos como registro de instâncias Docker, cache de camadas Docker e cache de pacotes.
De forma mais ampla, se alguém tiver observações sobre o tema de uma nuvem aberta e portável, também seria ótimo ouvir.
Em GitHub Actions runners, CircleCI e afins, a abordagem de adicionar chamadas de rede caras para tentar fazer cache manual das camadas sempre consumiu muito tempo, e parece fazer muita gente simplesmente remover o cache de vez.
Isso seria bem útil para usuários de outros clones do GitHub Actions, como o act [0].
[0]: https://github.com/nektos/act
Uso o BuildJet [0] com satisfação há mais de um ano.
Em comparação com o GH Actions, economizamos mais de $25k em custos de CI, e como o BuildJet também usa servidores bare metal potentes da Hetzner, o tempo de build caiu cerca de 94%.
Estou realmente satisfeito, e é ótimo ver mais empresas surgindo nesse mercado.
[0] https://buildjet.com
A maior parte dos nossos custos com GHA vem da execução de MacOS. Vocês oferecem MacOS como serviço gerenciado, ou pretendem oferecer? Também queria saber o quanto seria mais barato do que o GitHub.
A Ubicloud roda sobre provedores de bare metal, e eles não alugam hardware Mac.
Tecnicamente, seria possível rodar VMs de MacOS em arm64, mas pela nossa interpretação do contrato de licença de usuário final (EULA) da Apple, isso não seria permitido.
Este repositório reúne bem as referências relacionadas: https://github.com/kholia/OSX-KVM?tab=readme-ov-file#is-this...
Os termos do OS X dizem o seguinte:
3. Locação permitida para serviços de desenvolvedor. A. Locação. Você pode locar ou sublocar a totalidade do Apple Software devidamente licenciado a um indivíduo ou organização (cada um, um “Locatário”), desde que todas as seguintes condições sejam atendidas: (i) o Apple Software locado deve ser usado apenas com o objetivo de fornecer serviços de desenvolvedor permitidos, e cada Locatário deve revisar e concordar em estar vinculado a estes termos de licença; (ii) cada período de locação deve ter duração mínima de 24 horas consecutivas
Eles são cerca de 25% mais rápidos do que runners hospedados equivalentes do GitHub, e o custo por minuto é 50% menor.
[1] https://docs.warpbuild.com/runners#macos-m2-pro-on-arm64
Na Resmo usamos a Ubicloud há algum tempo, e ela realmente é 10x mais barata. Acabamos dobrando o tamanho da instância para ganhar um pouco mais de desempenho, mas mesmo assim continuou 5x mais barata.
O principal motivo é que a plataforma é hospedada em instâncias dedicadas da Hetzner.
Na PeerDB[1], usamos os runners da Ubicloud há algum tempo. O custo-benefício é bom e, em especial, os runners ARM ajudaram a reduzir nossos custos de CI.
A equipe também responde rápido e adicionou suporte a runners ARM poucas semanas depois de pedirmos.
[1] https://github.com/PeerDB-io/peerdb
Uma parte frustrante do preço dos runners do GitHub Actions é a cobrança por minuto. Não daria para cobrar por segundo? Mesmo que houvesse um mínimo de 1 minuto, seria bom se depois disso a cobrança fosse por segundo.
Imagino que façam isso para cobrir o tempo de reinicialização da VM entre jobs.
O tempo de reboot de VMs se acumula rapidamente, então provavelmente esse é o motivo.
Ainda assim, mantivemos a cobrança mínima de 1 minuto, porque há usuários rodando tarefas de lint de cerca de 2 segundos em instâncias de 16 vCPU.
Eu preferiria que não chamassem a licença Elastic de open source. É ótimo que o código-fonte esteja disponível, mas não é uma licença open source.
Pelas respostas, essa informação parece estar desatualizada, e agora o projeto aparentemente usa AGPL.
Parabéns pelo lançamento. Espero que a Ubicloud tenha ainda mais sucesso do que o projeto anterior de vocês, o Citus.