HN Memperkenalkan: Runner GitHub open-source untuk x64 dan Arm

 (ubicloud.com)
2 poin oleh GN⁺ 2024-01-31 | 1 komentar | Bagikan ke WhatsApp
  • Ubicloud menyediakan runner terkelola untuk GitHub Actions, dan mengklaim bahwa dengan hanya mengubah 1 baris di workflow, pengguna dapat tetap memakai cara kerja yang ada sambil meningkatkan kecepatan build dan biaya
  • Harga mulai dari Standard $0,0010 per menit dan Premium $0,0016 per menit, masing-masing menawarkan biaya 85% dan 70% lebih rendah dibandingkan GitHub-hosted runners
  • Standard dibedakan dengan AMD EPYC Genoa dan penyimpanan cache gratis 30GB, sedangkan Premium dengan AMD Ryzen 9 dan penyimpanan cache gratis 100GB
  • Keamanan berfokus pada VM yang sepenuhnya terisolasi berbasis Linux KVM, VM sekali pakai per job, konfigurasi runner GitHub Just-In-Time, enkripsi, dan rotasi kunci
  • Ubicloud mengarah pada cloud open-source, dan pengguna dapat melihat source code di GitHub atau mengelola runner sendiri jika diperlukan

Cara integrasi GitHub Actions

  • Ubicloud menyediakan runner terkelola untuk GitHub Actions, dan terintegrasi dengan cara mengubah 1 baris konfigurasi runner di workflow GitHub
  • Menyediakan 1.250 menit pemakaian gratis per bulan
  • Menonjolkan keunggulan utama: “mulai dalam 5 menit”, “2x lebih cepat”, dan “hemat 4–7x”
  • Integrasi dapat dimulai melalui dokumentasi quickstart

Harga dan spesifikasi runner

  • Runner Standard

    • Harga mulai dari $0,0010 per menit
    • Mengklaim biaya 85% lebih rendah dibandingkan GitHub-hosted runners
    • Menggunakan CPU berbasis AMD EPYC Genoa
    • Menyediakan penyimpanan cache gratis 30GB

  • Runner Premium

    • Harga mulai dari $0,0016 per menit
    • Mengklaim biaya 70% lebih rendah dibandingkan GitHub-hosted runners
    • Menggunakan CPU berbasis AMD Ryzen 9
    • Menyediakan penyimpanan cache gratis 100GB

  • Harga berdasarkan 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

Isolasi dan keamanan

  • Model keamanan berfokus pada VM terisolasi berbasis Linux KVM dan VM sekali pakai untuk setiap job
  • Menangani secret sekali pakai melalui konfigurasi runner GitHub Just-In-Time
  • Mencakup enkripsi saat disimpan dan saat ditransmisikan, rotasi kunci bawaan, konfigurasi firewall otomatis, dan notifikasi kerentanan otomatis

Berorientasi pada cloud open-source

  • Ubicloud adalah cloud open-source, yang bertujuan menjadi alternatif penyedia cloud seperti Linux terhadap sistem operasi proprietary
  • Source code dapat dilihat di GitHub
  • Pengguna dapat mengelola runner sendiri secara langsung jika menginginkannya

Bacaan terkait

1 komentar

 
GN⁺ 2024-01-31
Opini Hacker News

  • Selamat atas peluncurannya. Kelihatannya menarik, dan harganya di landing page tampak sangat bagus
    Semua pekerjaan saya saat ini adalah open source dengan GitHub Actions gratis, jadi untuk sekarang saya bukan target pelanggannya, tetapi saya jadi penasaran kenapa bisa lebih murah dan lebih cepat / apa jebakannya
    Saya juga melihat masalah visual berupa kurangnya padding horizontal pada rentang lebar sekitar 990px hingga sekitar 1200px, ukuran jendela yang umum di MBP 14"
    Kalimat “Ubicloud adalah cloud open source. Anggap saja sebagai alternatif terbuka untuk penyedia cloud, seperti Linux yang menjadi alternatif untuk sistem operasi proprietari” sulit dipahami, dan beberapa kali pertama saya mengira maksudnya adalah alternatif untuk Linux
    Akan lebih jelas kalau terlebih dahulu menjelaskan secara konkret apa ini, seperti di bagian “What is Ubicloud?” pada dokumentasi: “menyediakan fitur IaaS di atas penyedia sewa bare metal seperti Hetzner, OVH, dan AWS Bare Metal, serta juga ditawarkan sebagai layanan terkelola”
    Rasanya ada pepatah lama bahwa marketing untuk engineer lebih berhasil jika menjelaskan secara konkret apa produknya daripada manfaatnya, dan di sini sepertinya keduanya diperlukan. Akan bagus jika identitas sebenarnya dan alasan mengapa lebih murah serta lebih baik dijelaskan bersama
    Di paragraf tersebut juga ada typo berupa spasi yang hilang, seperti systems.Ubicloud

    • Karena produknya terlihat keren, kalau boleh menambahkan beberapa perbaikan kecil pada copy, saya tidak tahu apa arti “Imagine to do more” dan itu terdengar seperti kalimat promosi, jadi sebaiknya dihapus
      Pada “Fast runs even at this price point”, sebaiknya hapus point. “Price point” bukan sinonim dari “price”, dan karena sudah mengatakan lebih murah, lebih baik ubah judul bagian menjadi “Faster than GitHub Actions” tanpa tagline
      Paragraf “Ubicloud is an open, free, and portable cloud...” juga kabur. Sepertinya akan lebih jelas jika menjadi kira-kira: “Ubicloud adalah cloud yang terbuka dan gratis. Anda bisa menjalankannya di penyedia hosting pilihan Anda, atau membawa hardware milik Anda sendiri. Lihat kode sumbernya di GitHub!”
    • Saya baru pertama kali mendengar Ubicloud, tetapi sudah banyak memakai GitHub Actions, dan alasan mengapa ini lebih murah dan lebih cepat tampaknya karena GitHub memasang margin yang sangat besar di atas biaya pokok untuk komputasi Actions
      Dari sekilas lihat, tarif dasarnya sekitar $0,008 per menit, dan jika dibandingkan dengan tarif per jam EC2, rasionya tidak terlalu aneh
      Saya pernah mengerjakan proyek yang hanya dengan menjalankan satu instance EC2 dan menghubungkannya ke Actions saja sudah sangat menurunkan biaya sekaligus memperbaiki waktu build
    • Setelah menerima masukan, kami memperjelas copy di beberapa tempat, dan sambil memperbaiki bug UX, kami berencana merilis pembaruan yang lebih besar dalam beberapa minggu ke depan
    • Menurut saya biaya mengoperasikan server build tidak semahal itu

  • Kami sudah memakai builder Ubicloud selama beberapa bulan di proyek Rust [0], dan sejauh ini berjalan cukup baik. Waktu CI turun dari 10–15 menit menjadi 6–7 menit, dan biaya turun dari $300 per bulan menjadi $30
    Hal yang mengejutkan adalah penyimpanan/pemulihan cache lambat. Karena CPU mesinnya bagus, bagi kami lebih cepat untuk mematikan cache sepenuhnya dan membangun ulang semuanya di setiap build
    [0] https://github.com/ArroyoSystems/arroyo

    • Senang melihat contoh nyata repositori yang beralih ke runner selain runner resmi GitHub Actions. Saya sedang perlahan mengumpulkan perbandingan waktu eksekusi per repositori antara GitHub vs Buildjet/Warpbuild/Ubicloud vs solusi saya, RunsOn
      Workflow ini bisa dijalankan dalam kurang dari 5 menit di mesin sementara AWS dengan harga yang sama seperti Ubicloud: https://github.com/runs-on/arroyo/actions/runs/7723361513/jo...
    • Tautan SPDK itu sangat menarik: https://www.ubicloud.com/blog/building-block-storage-for-clo...
      Untuk aplikasi berkinerja tinggi yang memakai filesystem, saya sering melihat ZFS menjadi bottleneck dibandingkan konfigurasi yang lebih sederhana seperti XFS ± mdadm ± enkripsi
      Ini poin yang kontroversial, tetapi ada juga hasil serupa: https://klarasystems.com/articles/virtualization-showdown-fr... : “Ini mungkin mengejutkan banyak pembaca, tetapi secara pribadi saya tidak terkejut. Saya sudah menguji kinerja storage guest OpenZFS dan Linux KVM selama lebih dari 10 tahun, dan zvol selalu relatif berkinerja buruk”
      OpenZFS juga tampaknya mulai mempertimbangkan optimasi untuk drive modern (SSD, NVMe) yang karakteristik kinerjanya sangat berbeda dari disk berputar tempat ZFS awalnya dibuat
      Dalam ringkasan SPDK disebutkan, “untuk mengurangi waktu provisioning VM, kami mengganti OS host dari ext4 ke btrfs”, dan “setelah mengganti filesystem host ke btrfs, kinerja disk turun secara mencolok dan throughput menjadi sekitar 1/3 dari ext4”
      Masalah Ubicloud tampaknya berlaku pada filesystem copy-on-write secara umum, dan menarik bahwa mereka memilih varian yang sedikit berbeda bernama CoA, tetapi saya penasaran apakah mereka juga mengevaluasi alternatif yang lebih sederhana berupa overlay di atas filesystem journaling seperti XFS atau Ext4
      Atau mungkin juga menggunakan UFS2 + snapshot untuk memulihkan kondisi siap-uji yang telah diinisialisasi, lalu kembali ke kondisi itu di antara pengujian
      Jika pelanggan merasa lebih baik mematikan cache, itu tampaknya berarti CoA juga memiliki masalah yang mirip dengan CoW
      Secara pribadi, alih-alih menambah kompleksitas, saya mungkin akan mencoba SR-IOV dengan namespace per pelanggan lalu selesai, tetapi pasti ada alasan bagus, jadi saya penasaran apa alasannya
    • Saya penasaran bagaimana jejak karbonnya jika pendekatan mematikan cache sepenuhnya dan membangun ulang setiap kali ini diskalakan ke semua perusahaan/pekerjaan dengan karakter serupa
    • Terima kasih sudah berbagi. Saat melihat repositorinya, sebagian job masih berjalan di runner yang di-host GitHub; saya penasaran kenapa tidak semuanya dijalankan di Ubicloud

  • Saya Ozgun, salah satu pendiri Ubicloud.
    Saat ini puluhan pelanggan memakai runner Ubicloud di produksi, dan kami sedang merancang lapisan caching. Kami membukanya ke publik karena ingin mendengar masukan tentang hal-hal seperti registry instance Docker, cache layer Docker, dan cache paket.
    Secara lebih luas, kalau ada poin terkait tema cloud yang terbuka dan portabel, kami juga senang mendengarnya.

    • Akan bagus kalau bisa menaruh disk persisten yang cepat seperti Depot di dekat build dan meng-cache layer Docker.
      Cara menambahkan panggilan jaringan yang mahal untuk meng-cache layer secara manual di GitHub Actions runner, CircleCI, dan sebagainya selalu memakan banyak waktu, dan sepertinya membuat banyak orang menghapus cache sama sekali.
    • Akan bagus kalau kalian bisa membangun image runner GitHub dan mengunggahnya ke Docker Hub.
      Ini akan cukup berguna bagi pengguna clone GitHub Actions lain seperti act [0].
      [0]: https://github.com/nektos/act

  • Saya sudah memakai BuildJet [0] dengan puas selama lebih dari setahun.
    Dibanding GH Actions, kami menghemat biaya CI lebih dari $25k, dan karena BuildJet juga memakai server bare-metal Hetzner yang kuat, waktu build berkurang sekitar 94%.
    Saya benar-benar puas, dan senang melihat lebih banyak perusahaan hadir di pasar ini.
    [0] https://buildjet.com

  • Porsi terbesar biaya GHA kami adalah eksekusi MacOS. Apakah kalian menyediakan MacOS sebagai layanan terkelola, atau ada rencana untuk menyediakannya? Saya juga penasaran seberapa murah dibanding GitHub.

    • Kami tidak berencana menyediakannya dalam waktu dekat.
      Ubicloud berjalan di atas penyedia bare-metal, dan mereka tidak menyewakan hardware Mac.
      Secara teknis, VM MacOS bisa dijalankan di arm64, tetapi kami menafsirkan Apple End User License Agreement (EULA) sebagai tidak memperbolehkannya.
      Referensi terkait tersusun dengan baik di repositori ini: https://github.com/kholia/OSX-KVM?tab=readme-ov-file#is-this...
    • Masalah terbesar MacOS adalah perlu Mac fisik, tidak bisa divirtualisasi, dan seingat saya lisensi Apple mensyaratkan ketentuan seperti periode sewa minimal 24 jam.
      Ketentuan OS X menyatakan sebagai berikut:
      3. Penyewaan untuk Layanan Pengembang yang Diizinkan. A. Penyewaan. Anda dapat menyewakan atau menyewakan kembali keseluruhan Apple Software yang berlisensi sah kepada individu atau organisasi (masing-masing “Lessee”), dengan ketentuan semua syarat berikut dipenuhi: (i) Apple Software yang disewakan hanya boleh digunakan untuk tujuan penyediaan Layanan Pengembang yang Diizinkan dan setiap Lessee harus meninjau serta menyetujui untuk terikat oleh ketentuan lisensi ini; (ii) setiap masa sewa harus minimal 24 jam berturut-turut.
    • Di WarpBuild [1], kami mendukung GitHub MacOS 13 runner berbasis M2 Pro.
      Ini sekitar 25% lebih cepat daripada runner hosting GitHub yang setara dan biaya per menitnya 50% lebih murah.
      [1] https://docs.warpbuild.com/runners#macos-m2-pro-on-arm64

  • Kami sudah memakai Ubicloud di Resmo untuk beberapa waktu dan memang 10 kali lebih murah. Kami menaikkan ukuran instance 2 kali untuk mendapatkan sedikit performa tambahan, tetapi tetap 5 kali lebih murah.
    Alasan utamanya adalah platform ini di-host di atas instance dedicated Hetzner.

    • Kalau begitu, saya penasaran kenapa tidak mengirim request webhook dari GitHub Action ke CI sendiri yang berada di Hetzner?

  • Kami di PeerDB[1] sudah memakai runner Ubicloud untuk beberapa waktu. Nilai harga/kinerjanya bagus, dan khususnya runner ARM membantu menurunkan biaya CI.
    Timnya juga responsif, dan mereka menambahkan dukungan runner ARM hanya beberapa minggu setelah kami memintanya.
    [1] https://github.com/PeerDB-io/peerdb

  • Hal yang menjengkelkan dari harga GitHub Actions runner adalah penagihan per menit. Tidak bisakah ditagih per detik? Walau ada minimum 1 menit, setelah itu akan lebih baik kalau dihitung per detik.
    Sepertinya ini dilakukan untuk menutup waktu reboot VM di antara job.

    • Di WarpBuild, kami melakukan persis seperti itu. Tujuannya terutama agar adil dan tidak membebankan biaya acak kepada pengguna.
      Karena waktu reboot VM cepat terakumulasi, mungkin itulah alasannya.
      Namun ada juga pengguna yang menjalankan job lint sekitar 2 detik di instance 16 vCPU, jadi kami tetap mempertahankan penagihan minimum 1 menit.

  • Saya harap lisensi Elastic tidak disebut open source. Bagus bahwa source-nya terbuka, tetapi itu bukan lisensi open source.
    Melihat balasan-balasan, informasi ini tampaknya sudah usang, dan sekarang proyeknya tampaknya memakai AGPL.

  • Selamat atas peluncurannya. Semoga Ubicloud lebih sukses daripada proyek sebelumnya, Citus.