HN tanıtımı: Açık kaynak x64 ve Arm GitHub runner'ları

 (ubicloud.com)
2 puan yazan GN⁺ 2024-01-31 | 1 yorum | WhatsApp'ta paylaş
  • Ubicloud, GitHub Actions için yönetilen runner'lar sunuyor; iş akışında yalnızca 1 satır değiştirerek mevcut kullanım biçimini korurken derleme hızını ve maliyeti iyileştirebildiğini öne sürüyor
  • Fiyatlar Standard için dakikada $0.0010, Premium için dakikada $0.0016'dan başlıyor; GitHub-hosted runners'a kıyasla sırasıyla %85 ve %70 daha düşük maliyet sunduğunu belirtiyor
  • Standard, AMD EPYC Genoa ve 30GB ücretsiz cache depolama; Premium ise AMD Ryzen 9 ve 100GB ücretsiz cache depolama ile ayrışıyor
  • Güvenlik; Linux KVM tabanlı tam yalıtılmış VM, iş başına tek kullanımlık VM, GitHub Just-In-Time runner yapılandırması, şifreleme ve anahtar rotasyonu etrafında kurgulanmış
  • Ubicloud, açık kaynak bulut yaklaşımını benimsiyor; kaynak kodu GitHub'da inceleyebilir veya gerekirse kendi runner'larınızı doğrudan yönetebilirsiniz

GitHub Actions entegrasyon şekli

  • Ubicloud, GitHub Actions için yönetilen runner'lar sunuyor ve GitHub iş akışında runner ayarını 1 satır değiştirerek entegre oluyor
  • Aylık 1.250 dakika ücretsiz kullanım sunuyor
  • “5 dakikada başlayın”, “2 kat daha hızlı”, “4~7 kat tasarruf” öne çıkarılan başlıca avantajlar arasında
  • Entegrasyona hızlı başlangıç dokümanı üzerinden başlayabilirsiniz

Fiyatlandırma ve runner özellikleri

  • Standard runner

    • Başlangıç fiyatı dakikada $0.0010
    • GitHub-hosted runners'dan %85 daha düşük maliyet sunduğunu belirtiyor
    • AMD EPYC Genoa tabanlı CPU kullanıyor
    • 30GB ücretsiz cache depolama sunuyor

  • Premium runner

    • Başlangıç fiyatı dakikada $0.0016
    • GitHub-hosted runners'dan %70 daha düşük maliyet sunduğunu belirtiyor
    • AMD Ryzen 9 tabanlı CPU kullanıyor
    • 100GB ücretsiz cache depolama sunuyor

  • Donanıma göre fiyatlar

    • 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

Yalıtım ve güvenlik

  • Güvenlik modeli, Linux KVM tabanlı yalıtılmış VM ve iş başına tek kullanımlık VM etrafında şekilleniyor
  • GitHub Just-In-Time runner yapılandırmasıyla tek kullanımlık secret'lar işleniyor
  • Saklama ve aktarım sırasında şifreleme, yerleşik anahtar rotasyonu, otomatik firewall yapılandırması ve otomatik güvenlik açığı bildirimlerini içeriyor

Açık kaynak bulut yaklaşımı

  • Ubicloud, açık kaynak bulut olarak, tescilli işletim sistemlerine karşı Linux'un yaptığına benzer şekilde bulut sağlayıcılarına alternatif olmayı hedefliyor
  • Kaynak kodu GitHub üzerinde incelenebilir
  • İsteyen kullanıcılar kendi runner'larını doğrudan yönetebilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-31
Hacker News yorumları

  • Lansman için tebrikler. İlginç görünüyor ve açılış sayfasındaki fiyat çok iyi görünüyor.
    Şu anda yaptığım her şey açık kaynak ve ücretsiz GitHub Actions üzerinde olduğu için şimdilik hedef müşteri değilim; ama neden daha ucuz ve daha hızlı olduğunu / işin püf noktasının ne olduğunu merak ettim.
    14" MBP’de yaygın bir pencere boyutu olan 990px ile yaklaşık 1200px aralığında yatay padding’in yetersiz olduğu görsel bir sorun da görüyorum.
    “Ubicloud açık kaynak bir buluttur. Linux’un tescilli işletim sistemlerine alternatif olması gibi, onu bulut sağlayıcılarına açık bir alternatif olarak düşünün” ifadesini anlamakta zorlandım; ilk birkaç seferinde Linux alternatifi olduğunu söylüyor sandım.
    Belgelerdeki “What is Ubicloud?” bölümü gibi, önce “Hetzner, OVH, AWS Bare Metal gibi bare metal kiralama sağlayıcılarının üzerinde IaaS özellikleri sunar ve yönetilen servis olarak da sağlanır” diye somut olarak ne olduğunu söylemek daha net olurdu.
    Mühendislere yönelik pazarlamada, faydadan ziyade bunun gerçekten ne olduğunu somut biçimde söylemenin daha iyi işlediğine dair eski bir deyiş vardı sanırım; burada ikisi de gerekli görünüyor. Gerçek kimliğiyle birlikte neden daha ucuz ve daha iyi olduğunu da söylemek iyi olur.
    İlgili paragrafta systems.Ubicloud gibi eksik boşluk içeren bir yazım hatası da var.

    • Ürün güzel göründüğü için birkaç küçük metin iyileştirmesi daha yazayım: “Imagine to do more”un ne anlama geldiğini bilmiyorum ve tanıtım dili gibi duyuluyor; bence çıkarmak daha iyi olur.
      “Fast runs even at this price point”te point çıkarılmalı. “Price point”, “price” ile eş anlamlı değil; ayrıca zaten daha ucuz olduğunuzu söylediğiniz için, slogan olmadan bölüm başlığını “Faster than GitHub Actions” olarak değiştirmek daha iyi olur.
      “Ubicloud is an open, free, and portable cloud...” paragrafı da belirsiz. “Ubicloud açık ve ücretsiz bir buluttur. İstediğiniz hosting sağlayıcısında çalıştırabilir veya kendi sahip olduğunuz donanımı getirebilirsiniz. Kaynak kodunu GitHub’da inceleyin!” gibi bir ifade daha net görünüyor.
    • Ubicloud’u ilk kez duyuyorum ama GitHub Actions’ı çok kullandım; daha ucuz ve hızlı olmasının nedeni, GitHub’ın Actions compute için maliyetin üzerine muazzam bir marj koyması gibi görünüyor.
      Kabaca bakınca temel ücretin dakika başına $0.008 civarında olduğunu görüyorum; EC2’nin saatlik fiyatlarıyla karşılaştırınca da çok garip olmayan bir oran.
      Tek bir EC2 instance’ı ayağa kaldırıp Actions’a bağlayarak maliyeti ciddi biçimde düşürdüğümüz ve build süresini de iyileştirdiğimiz bir proje yapmıştım.
    • Geri bildirimleri dikkate alıp metni birkaç yerde daha net hale getirdik; UX hatasını da düzeltiyoruz ve önümüzdeki birkaç hafta içinde daha büyük bir güncelleme yapmayı planlıyoruz.
    • Bir build sunucusu çalıştırmanın maliyetinin o kadar pahalı olduğunu düşünmüyorum.

  • Rust projemizde [0] birkaç aydır Ubicloud builder’larını kullanıyoruz ve oldukça iyi çalıştı. CI süresi 10-15 dakikadan 6-7 dakikaya indi, maliyet de aylık $300’dan $30’a düştü.
    Şaşırtıcı olan nokta, cache kaydetme/geri yüklemenin yavaş olmasıydı. Makinelerin CPU’su iyi olduğu için bizim açımızdan cache’i tamamen kapatıp her build’de her şeyi baştan yapmak daha hızlıydı.
    [0] https://github.com/ArroyoSystems/arroyo

    • Resmî GitHub Actions runner’ı olmayan bir runner’a geçen depolardan gerçek örnekler görmek iyi oluyor. GitHub vs Buildjet/Warpbuild/Ubicloud vs kendi çözümüm RunsOn için depo bazında çalışma süresi karşılaştırmalarını yavaş yavaş topluyorum.
      Bu workflow, AWS geçici makinelerinde Ubicloud ile aynı fiyata 5 dakikanın altında çalıştırılabiliyor: https://github.com/runs-on/arroyo/actions/runs/7723361513/jo...
    • SPDK bağlantısı çok ilginçti: https://www.ubicloud.com/blog/building-block-storage-for-clo...
      Yüksek performanslı uygulamalarda dosya sistemi kullanıyorum; ZFS’nin, XFS ± mdadm ± şifreleme gibi daha basit kurulumlara göre sık sık darboğaz olduğunu gördüm.
      Tartışmalı bir nokta ama benzer sonuçlar da var: https://klarasystems.com/articles/virtualization-showdown-fr... : “Birçok okuyucu için şaşırtıcı olabilir, ama şahsen benim için şaşırtıcı değildi. OpenZFS ve Linux KVM’nin konuk depolama performansını 10 yıldan uzun süredir test ediyorum; zvol her seferinde görece kötü performans gösterdi.”
      OpenZFS de ZFS’nin tasarlandığı dönen disklerden çok farklı performans özelliklerine sahip modern sürücüler (SSD, NVMe) için optimizasyonları değerlendirmeye başlamış gibi görünüyor.
      SPDK özetinde “VM provisioning süresini azaltmak için host OS’yi ext4’ten btrfs’ye geçirdik”, “host dosya sistemini btrfs’ye geçirince disk performansı belirgin biçimde düştü ve throughput ext4’ün yaklaşık 1/3’ü oldu” deniyor.
      Ubicloud’un sorunu genel olarak yazarken kopyalayan dosya sistemleriyle ilgili gibi görünüyor; CoA adlı biraz farklı bir varyantı seçmeleri ilginç, ama XFS, Ext4 gibi journaling dosya sistemlerinin üzerine overlay koymak gibi daha basit bir alternatifi değerlendirip değerlendirmediklerini merak ediyorum.
      Ya da UFS2 + snapshot’larla ilklendirilmiş test-hazır durumunu geri yüklemek ve testler arasında o duruma dönmek de mümkün görünüyor.
      Müşteriler cache’i kapatmanın daha iyi olduğunu düşünüyorsa, bu CoA’nın da CoW’a benzer sorunları olduğu anlamına geliyor gibi.
      Şahsen karmaşıklık eklemek yerine müşteri başına namespace’lere sahip SR-IOV dener ve konuyu kapatırdım; ama mutlaka iyi bir nedenleri vardır, o nedeni merak ediyorum.
    • Cache’i tamamen kapatıp her build’de baştan yapma yaklaşımı, benzer nitelikteki tüm şirket/iş yükü ölçeğine büyüdüğünde karbon ayak izinin nasıl olacağını merak ediyorum.
    • Paylaşım için teşekkürler. Depoya bakınca bazı job’ların hâlâ GitHub barındırmalı runner’larda çalıştığını gördüm; neden hepsini Ubicloud’da çalıştırmadığınızı merak ediyorum.

  • Ubicloud kurucularından biri olan Ozgun’um.
    Şu anda onlarca müşteri üretimde Ubicloud runner’larını kullanıyor ve şu anda önbellekleme katmanını tasarlıyoruz. Docker instance registry, Docker katman önbelleği, paket önbelleği gibi konularda görüş almak istediğimiz için bunu açtık.
    Daha geniş anlamda açık ve taşınabilir bulut konusu hakkında noktalarınız varsa da duymak isteriz.

    • Depot gibi hızlı bir kalıcı diski derlemeye yakın konumlandırıp Docker katmanlarını önbelleğe alması güzel olurdu.
      GitHub Actions runner’larında, CircleCI’da vb. katmanları elle önbelleğe almak için pahalı ağ çağrıları ekleme yöntemi her zaman çok zaman alıyordu ve birçok kişiyi önbelleği tamamen kaldırmaya itiyor gibi görünüyor.
    • GitHub’ın runner imajlarını derleyip Docker Hub’a yükleyebilmeniz iyi olurdu.
      act [0] gibi diğer GitHub Actions klonu kullanıcıları için oldukça yararlı olur.
      [0]: https://github.com/nektos/act

  • BuildJet’i [0] bir yıldan uzun süredir memnuniyetle kullanıyorum.
    GH Actions’a kıyasla CI maliyetlerinde $25k’dan fazla tasarruf ettik; BuildJet de Hetzner’in güçlü bare-metal sunucularını kullandığı için derleme süreleri yaklaşık %94 azaldı.
    Gerçekten memnunuz ve pazarda daha fazla şirketin ortaya çıkması sevindirici.
    [0] https://buildjet.com

  • GHA maliyetlerimizdeki en büyük kalem MacOS çalıştırma. MacOS’u yönetilen servis olarak sunuyor musunuz ya da sunma planınız var mı? GitHub’dan ne kadar ucuz olduğunu da merak ediyorum.

    • Yakın gelecekte sunmayı planlamıyoruz.
      Ubicloud bare-metal sağlayıcıların üzerinde çalışıyor; onlar da Mac donanımı kiralamıyor.
      Teknik olarak arm64 üzerinde MacOS VM çalıştırmak mümkün, ancak Apple son kullanıcı lisans sözleşmesine (EULA) bakınca bunun yapılmaması gerektiği şeklinde yorumluyoruz.
      Bu depoda ilgili referanslar iyi derlenmiş: https://github.com/kholia/OSX-KVM?tab=readme-ov-file#is-this...
    • MacOS’un en büyük sorunu fiziksel Mac gerektirmesi, sanallaştırılamaması ve hatırladığım kadarıyla Apple lisansının en az 24 saatlik kiralama süresi gibi şartlar istemesi.
      OS X şartlarında şöyle yazıyor:
      3. İzin Verilen Geliştirici Hizmetleri için Kiralama. A. Kiralama. Geçerli şekilde lisanslanmış Apple Software’in tamamını bir kişi veya kuruluşa (her biri “Lessee”) kiralayabilir veya yeniden kiralayabilirsiniz; bunun için aşağıdaki koşulların tümü karşılanmalıdır: (i) kiralanan Apple Software yalnızca İzin Verilen Geliştirici Hizmetleri sağlama amacıyla kullanılmalı ve her Lessee bu lisans koşullarını inceleyip bunlara bağlı olmayı kabul etmelidir; (ii) her kiralama süresi kesintisiz en az 24 saat olmalıdır.
    • WarpBuild [1], M2 Pro tabanlı GitHub MacOS 13 runner desteği sunuyor.
      Eşdeğer GitHub barındırmalı runner’dan yaklaşık %25 daha hızlı ve dakika başı maliyeti %50 daha ucuz.
      [1] https://docs.warpbuild.com/runners#macos-m2-pro-on-arm64

  • Resmo’da bir süredir Ubicloud kullanıyoruz ve gerçekten 10 kat daha ucuz. Biraz daha performans almak için instance boyutunu 2 katına çıkardık ama yine de 5 kat daha ucuz.
    Temel sebep, platformun Hetzner ayrılmış instance’ları üzerinde barındırılması.

    • O halde GitHub Action’dan Hetzner’deki kendi CI’ınıza webhook isteği göndermemeniz için bir neden var mı merak ediyorum.

  • PeerDB’de[1] bir süredir Ubicloud runner’larını kullanıyoruz. Fiyat/performans iyi ve özellikle ARM runner’lar CI maliyetlerini düşürmeye yardımcı oldu.
    Ekip de hızlı yanıt veriyor; biz talep ettikten birkaç hafta içinde ARM runner desteği eklediler.
    [1] https://github.com/PeerDB-io/peerdb

  • GitHub Actions runner fiyatlandırmasında can sıkan nokta dakika bazlı ücretlendirme. Saniye bazında faturalandırmak mümkün değil mi? En az 1 dakika olsa bile sonrasında saniye bazında alınsa iyi olurdu.
    Sanırım işler arasında VM’in yeniden başlatılması için geçen süreyi karşılamak amacıyla böyle yapıyorlar.

    • WarpBuild’de tam olarak bunu yapıyoruz. Temel amacımız rastgele maliyetleri kullanıcılara yıkmadan adil olmak.
      VM yeniden başlatma süresi hızla biriktiği için muhtemelen sebep budur.
      Yine de 16 vCPU’lu instance üzerinde yaklaşık 2 saniye süren lint işleri çalıştıran kullanıcılar da olduğundan en az 1 dakika ücretlendirmeyi koruduk.

  • Elastic lisansına açık kaynak denmemesini isterim. Kaynağın açık olması iyi, ama bu bir açık kaynak lisansı değil.
    Yanıtlara bakınca bu bilgi eski gibi görünüyor; artık projenin AGPL kullandığı anlaşılıyor.

  • Lansmanınız kutlu olsun. Ubicloud’un önceki projeniz Citus’tan daha başarılı olmasını dilerim.