Giới thiệu HN: GitHub runner x64 và Arm mã nguồn mở
(ubicloud.com)- Ubicloud cung cấp runner được quản lý cho GitHub Actions, cho biết chỉ cần đổi 1 dòng trong workflow là có thể giữ nguyên cách sử dụng hiện tại trong khi cải thiện tốc độ build và chi phí
- Giá bắt đầu từ Standard $0.0010/phút, Premium $0.0016/phút, lần lượt thấp hơn 85% và 70% so với GitHub-hosted runners
- Standard gồm AMD EPYC Genoa và 30GB dung lượng cache miễn phí; Premium gồm AMD Ryzen 9 và 100GB dung lượng cache miễn phí
- Bảo mật tập trung vào VM cô lập hoàn toàn dựa trên Linux KVM, VM dùng một lần cho từng job, cấu hình GitHub Just-In-Time runner, mã hóa và xoay vòng khóa
- Ubicloud hướng tới đám mây mã nguồn mở; có thể xem mã nguồn trên GitHub hoặc tự quản lý runner riêng nếu cần
Cách tích hợp GitHub Actions
- Ubicloud cung cấp runner được quản lý cho GitHub Actions, tích hợp bằng cách đổi 1 dòng cấu hình runner trong GitHub workflow
- Cung cấp 1.250 phút sử dụng miễn phí mỗi tháng
- Nêu các ưu điểm chính: “bắt đầu trong 5 phút”, “nhanh gấp 2 lần”, “tiết kiệm 4–7 lần”
- Có thể bắt đầu tích hợp qua tài liệu bắt đầu nhanh
Giá và thông số runner
-
Runner Standard
- Giá khởi điểm là $0.0010/phút
- Đưa ra mức chi phí thấp hơn 85% so với GitHub-hosted runners
- Sử dụng CPU dựa trên AMD EPYC Genoa
- Cung cấp 30GB dung lượng cache miễn phí
-
Runner Premium
- Giá khởi điểm là $0.0016/phút
- Đưa ra mức chi phí thấp hơn 70% so với GitHub-hosted runners
- Sử dụng CPU dựa trên AMD Ryzen 9
- Cung cấp 100GB dung lượng cache miễn phí
-
Giá theo phần cứng
- 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
Cô lập và bảo mật
- Mô hình bảo mật tập trung vào VM cô lập dựa trên Linux KVM và VM dùng một lần cho từng job
- Xử lý secret dùng một lần bằng cấu hình GitHub Just-In-Time runner
- Bao gồm mã hóa khi lưu trữ và khi truyền, xoay vòng khóa tích hợp, cấu hình tường lửa tự động và cảnh báo lỗ hổng tự động
Định hướng đám mây mã nguồn mở
- Ubicloud là đám mây mã nguồn mở, hướng tới trở thành lựa chọn nhà cung cấp đám mây tương tự Linux so với các hệ điều hành độc quyền
- Có thể xem mã nguồn trên GitHub
- Người dùng có thể tự quản lý runner riêng nếu muốn
1 bình luận
Các ý kiến trên Hacker News
Chúc mừng ra mắt. Trông có vẻ thú vị, và giá trên trang landing page trông rất tốt
Hiện tại mọi việc tôi làm đều là open source và dùng GitHub Actions miễn phí, nên tôi chưa phải khách hàng mục tiêu, nhưng tôi tò mò vì sao nó rẻ hơn và nhanh hơn / cái bẫy nằm ở đâu
Tôi cũng thấy một vấn đề thị giác là thiếu padding ngang trong khoảng 990px đến khoảng 1200px, vốn là kích thước cửa sổ phổ biến trên MBP 14"
Câu “Ubicloud là một cloud open source. Hãy nghĩ nó như một lựa chọn thay thế mở cho các nhà cung cấp cloud, giống như Linux là lựa chọn thay thế cho các hệ điều hành độc quyền” khá khó hiểu; vài lần đầu tôi tưởng họ đang nói đây là lựa chọn thay thế cho Linux
Sẽ rõ ràng hơn nếu nói trước cụ thể nó là gì, như trong phần “What is Ubicloud?” của tài liệu: “cung cấp các tính năng IaaS trên các nhà cung cấp cho thuê bare metal như Hetzner, OVH, AWS Bare Metal, và cũng được cung cấp dưới dạng dịch vụ được quản lý”
Tôi nhớ có một câu ngạn ngữ cũ rằng marketing cho kỹ sư hiệu quả hơn khi nói cụ thể thứ đó thực sự là gì thay vì chỉ nói về lợi ích; ở đây có vẻ cần cả hai. Sẽ tốt hơn nếu nói cùng lúc bản chất thật sự của nó và vì sao nó rẻ hơn, tốt hơn
Đoạn đó cũng có lỗi chính tả thiếu khoảng trắng như
systems.UbicloudTrong “Fast runs even at this price point” nên bỏ
point. “Price point” không đồng nghĩa với “price”, và vì đã nói là rẻ hơn rồi, có lẽ nên đổi tiêu đề mục thành “Faster than GitHub Actions” mà không cần taglineĐoạn “Ubicloud is an open, free, and portable cloud...” cũng mơ hồ. Đại loại “Ubicloud là một cloud mở và miễn phí. Bạn có thể chạy nó trên nhà cung cấp hosting mình muốn, hoặc mang phần cứng của chính mình vào. Xem mã nguồn trên GitHub!” có vẻ rõ hơn
Nhìn qua thì giá cơ bản khoảng $0.008/phút, so với giá theo giờ của EC2 cũng không phải tỷ lệ quá bất thường
Tôi từng làm một dự án chỉ cần dựng một instance EC2 rồi nối vào Actions là đã giảm chi phí đáng kể và cải thiện cả thời gian build
Chúng tôi đã dùng builder của Ubicloud trong vài tháng cho dự án Rust [0], và nó hoạt động khá tốt. Thời gian CI giảm từ 10–15 phút xuống 6–7 phút, còn chi phí giảm từ $300/tháng xuống $30/tháng
Điều bất ngờ là lưu/khôi phục cache chậm. CPU của máy tốt nên với chúng tôi, tắt hẳn cache và làm lại mọi thứ từ đầu ở mỗi lần build lại nhanh hơn
[0] https://github.com/ArroyoSystems/arroyo
Workflow này có thể chạy trong chưa tới 5 phút trên máy tạm thời của AWS với cùng mức giá như Ubicloud: https://github.com/runs-on/arroyo/actions/runs/7723361513/jo...
Tôi dùng filesystem cho các ứng dụng hiệu năng cao, và ZFS thường trở thành nút thắt so với các cấu hình đơn giản hơn như XFS ± mdadm ± mã hóa
Đây là điểm gây tranh luận, nhưng cũng có kết quả tương tự: https://klarasystems.com/articles/virtualization-showdown-fr... : “Điều này có thể gây ngạc nhiên với nhiều độc giả, nhưng cá nhân tôi thì không. Tôi đã kiểm thử hiệu năng lưu trữ guest của OpenZFS và Linux KVM hơn 10 năm, và zvol lần nào cũng có hiệu năng tương đối kém”
Có vẻ OpenZFS cũng đã bắt đầu xem xét tối ưu hóa cho các ổ đĩa hiện đại (SSD, NVMe), vốn có đặc tính hiệu năng rất khác với đĩa quay mà ZFS ban đầu được tạo ra cho
Trong phần tóm tắt SPDK có nói “để giảm thời gian provisioning VM, chúng tôi đổi host OS từ ext4 sang btrfs”, và “sau khi đổi filesystem của host sang btrfs, hiệu năng đĩa giảm rõ rệt, throughput chỉ còn khoảng 1/3 so với ext4”
Vấn đề của Ubicloud có vẻ nằm ở filesystem copy-on-write nói chung; việc họ chọn biến thể hơi khác gọi là CoA khá thú vị, nhưng tôi tò mò không biết họ đã xem xét phương án đơn giản hơn là đặt overlay lên các filesystem journaling như XFS, Ext4 chưa
Hoặc cũng có thể dùng UFS2 + snapshot để khôi phục trạng thái sẵn sàng cho test đã được khởi tạo, rồi quay lại trạng thái đó giữa các lần test
Nếu khách hàng cảm thấy tắt cache còn tốt hơn, điều đó có vẻ cho thấy CoA cũng có vấn đề tương tự CoW
Cá nhân tôi có lẽ sẽ thử dùng SR-IOV với namespace theo từng khách hàng rồi kết thúc ở đó, thay vì tăng thêm độ phức tạp; chắc chắn họ có lý do tốt, nên tôi tò mò lý do đó là gì
Tôi là Ozgun, một trong những nhà sáng lập Ubicloud
Hiện có hàng chục khách hàng đang dùng runner của Ubicloud trong production, và chúng tôi đang thiết kế lớp caching. Tôi công khai việc này vì muốn nghe ý kiến về các phần như Docker instance registry, cache layer Docker, cache package
Rộng hơn nữa, nếu có góp ý về chủ đề đám mây mở và có tính di động thì cũng rất mong được nghe
Cách thêm các lệnh gọi mạng tốn kém để cache layer thủ công trong GitHub Actions runner, CircleCI, v.v. lúc nào cũng mất nhiều thời gian, và có vẻ khiến nhiều người bỏ hẳn cache
Điều này sẽ khá hữu ích cho người dùng các bản clone GitHub Actions khác như act [0]
[0]: https://github.com/nektos/act
Tôi đã dùng BuildJet [0] hơn một năm và khá hài lòng
So với GH Actions, chúng tôi đã tiết kiệm hơn $25k chi phí CI, và vì BuildJet cũng dùng các máy chủ bare-metal mạnh của Hetzner nên thời gian build giảm khoảng 94%
Tôi thật sự hài lòng, và rất vui khi thị trường có thêm nhiều công ty hơn
[0] https://buildjet.com
Phần lớn nhất trong chi phí GHA của chúng tôi là chạy MacOS. Các bạn có cung cấp MacOS dưới dạng dịch vụ được quản lý không, hoặc có kế hoạch cung cấp không? Tôi cũng tò mò là rẻ hơn GitHub bao nhiêu
Ubicloud chạy trên các nhà cung cấp bare-metal, và họ không cho thuê phần cứng Mac
Về mặt kỹ thuật có thể chạy VM MacOS trên arm64, nhưng theo cách chúng tôi diễn giải thỏa thuận cấp phép người dùng cuối (EULA) của Apple thì không được làm vậy
Kho này tổng hợp khá tốt các tài liệu tham khảo liên quan: https://github.com/kholia/OSX-KVM?tab=readme-ov-file#is-this...
Điều khoản OS X viết như sau:
3. Cho thuê cho Dịch vụ nhà phát triển được phép. A. Cho thuê. Có thể cho thuê hoặc cho thuê lại toàn bộ Apple Software đã được cấp phép hợp lệ cho một cá nhân hoặc tổ chức (mỗi bên là “Lessee”), với điều kiện phải đáp ứng tất cả các điều kiện sau: (i) Apple Software được cho thuê chỉ được sử dụng nhằm mục đích cung cấp Dịch vụ nhà phát triển được phép, và mỗi Lessee phải xem xét các điều khoản của giấy phép này và đồng ý bị ràng buộc bởi các điều khoản đó; (ii) mỗi thời hạn thuê phải kéo dài liên tục tối thiểu 24 giờ
Nhanh hơn khoảng 25% so với runner tương đương do GitHub host và chi phí theo phút rẻ hơn 50%
[1] https://docs.warpbuild.com/runners#macos-m2-pro-on-arm64
Chúng tôi đã dùng Ubicloud ở Resmo một thời gian và thực sự rẻ hơn 10 lần. Chúng tôi tăng kích thước instance lên gấp đôi để có thêm chút hiệu năng, nhưng vẫn rẻ hơn 5 lần
Lý do chính là nền tảng được host trên các instance chuyên dụng của Hetzner
Chúng tôi đã dùng runner Ubicloud ở PeerDB[1] một thời gian. Tỷ lệ giá/hiệu năng tốt, và đặc biệt ARM runner đã giúp giảm chi phí CI
Đội ngũ phản hồi cũng nhanh; họ đã bổ sung hỗ trợ ARM runner chỉ trong vài tuần sau khi chúng tôi yêu cầu
[1] https://github.com/PeerDB-io/peerdb
Điều gây khó chịu trong giá của GitHub Actions runner là tính phí theo phút. Không thể tính theo giây sao? Dù có đặt tối thiểu 1 phút thì sau đó tính theo giây sẽ tốt hơn
Tôi đoán họ làm vậy để bù thời gian VM khởi động lại giữa các job
Có lẽ đó là lý do, vì thời gian khởi động lại VM cộng dồn rất nhanh
Tuy nhiên, cũng có người dùng chạy job lint chỉ mất khoảng 2 giây trên instance 16 vCPU, nên chúng tôi vẫn giữ mức tính phí tối thiểu 1 phút
Mong đừng gọi giấy phép Elastic là mã nguồn mở. Việc mã nguồn được công khai là tốt, nhưng đó không phải giấy phép mã nguồn mở
Nhìn các phản hồi thì có vẻ thông tin này đã cũ, và giờ dự án dường như dùng AGPL
Chúc mừng ra mắt. Mong Ubicloud sẽ thành công hơn dự án trước đó là Citus