HN परिचय: ओपन सोर्स x64 और Arm GitHub runner

 (ubicloud.com)
2 पॉइंट द्वारा GN⁺ 2024-01-31 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Ubicloud GitHub Actions के लिए managed runner प्रदान करता है, और कहता है कि workflow में सिर्फ 1 लाइन बदलकर मौजूदा उपयोग तरीका बनाए रखते हुए build speed और cost में सुधार किया जा सकता है
  • कीमत Standard के लिए $0.0010 प्रति मिनट, Premium के लिए $0.0016 प्रति मिनट से शुरू होती है, और GitHub-hosted runners की तुलना में क्रमशः 85% और 70% कम लागत का दावा किया गया है
  • Standard में AMD EPYC Genoa और 30GB free cache storage मिलता है, जबकि Premium में AMD Ryzen 9 और 100GB free cache storage दिया जाता है
  • security को Linux KVM आधारित पूरी तरह isolated VM, हर job के लिए one-time VM, GitHub Just-In-Time runner configuration, encryption और key rotation पर केंद्रित किया गया है
  • Ubicloud open source cloud को लक्ष्य बनाता है, इसलिए आप GitHub पर source code देख सकते हैं या चाहें तो अपने runner खुद manage कर सकते हैं

GitHub Actions इंटीग्रेशन का तरीका

  • Ubicloud GitHub Actions के लिए managed runner देता है, और GitHub workflow में runner setting की 1 लाइन बदलने भर से integration हो जाता है
  • हर महीने 1,250 मिनट का free usage मिलता है
  • “5 मिनट में शुरुआत”, “2 गुना तेज”, “4~7 गुना बचत” को मुख्य फ़ायदे के रूप में पेश किया गया है
  • quick start दस्तावेज़ के ज़रिए integration शुरू किया जा सकता है

कीमत और runner स्पेसिफिकेशन

  • Standard runner

    • शुरुआती कीमत $0.0010 प्रति मिनट है
    • GitHub-hosted runners से 85% कम लागत का दावा किया गया है
    • AMD EPYC Genoa आधारित CPU का उपयोग होता है
    • 30GB free cache storage मिलता है

  • Premium runner

    • शुरुआती कीमत $0.0016 प्रति मिनट है
    • GitHub-hosted runners से 70% कम लागत का दावा किया गया है
    • AMD Ryzen 9 आधारित CPU का उपयोग होता है
    • 100GB free cache storage मिलता है

  • हार्डवेयर के अनुसार कीमत

    • 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

isolation और security

  • security model का केंद्र Linux KVM आधारित isolated VM और हर job के लिए one-time VM है
  • GitHub Just-In-Time runner configuration के जरिए one-time secret को संभाला जाता है
  • इसमें data-at-rest और data-in-transit encryption, built-in key rotation, automatic firewall configuration, और automatic vulnerability alerts शामिल हैं

open source cloud की दिशा

  • Ubicloud एक open source cloud है, जो proprietary operating system के मुकाबले Linux जैसी cloud provider alternative बनने का लक्ष्य रखता है
  • source code GitHub पर देखा जा सकता है
  • उपयोगकर्ता चाहें तो अपने runner खुद manage कर सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-01-31
Hacker News की राय

  • लॉन्च के लिए बधाई। दिलचस्प लग रहा है, और landing page पर कीमत बहुत अच्छी दिखती है
    अभी मेरा सारा काम open source और मुफ्त GitHub Actions पर है, इसलिए फिलहाल मैं target customer नहीं हूं, लेकिन यह जानने की उत्सुकता है कि यह सस्ता और तेज क्यों है / इसमें catch क्या है
    14" MBP पर आम window size, यानी 990px से लगभग 1200px के बीच, horizontal padding कम होने की visual समस्या भी दिख रही है
    “Ubicloud एक open source cloud है। जैसे Linux proprietary operating systems का विकल्प है, वैसे ही इसे cloud providers का open विकल्प समझें” वाला वाक्य समझना मुश्किल था, और शुरुआती कुछ बार मुझे लगा कि यह Linux का विकल्प कह रहा है
    docs के “What is Ubicloud?” सेक्शन की तरह, “Hetzner, OVH, AWS Bare Metal जैसे bare-metal rental providers के ऊपर IaaS capabilities देता है, और managed service के रूप में भी उपलब्ध है” जैसे यह असल में क्या है पहले कहना ज्यादा स्पष्ट रहेगा
    शायद एक पुरानी कहावत थी कि engineers को की जाने वाली marketing में usefulness से ज्यादा, यह concretely क्या है बताना बेहतर काम करता है; यहां दोनों की जरूरत लगती है। असली पहचान और यह सस्ता व बेहतर क्यों है, दोनों साथ बताना अच्छा होगा
    उस पैराग्राफ में systems.Ubicloud जैसा missing space वाला typo भी है

    • product अच्छा लग रहा है, इसलिए copy में कुछ छोटी-छोटी improvements और लिखूं तो, “Imagine to do more” का मतलब समझ नहीं आता और यह promotional copy जैसा सुनाई देता है, इसलिए इसे हटाना बेहतर होगा
      “Fast runs even at this price point” में point हटाना अच्छा रहेगा। “Price point”, “price” का synonym नहीं है, और चूंकि आप पहले ही कह चुके हैं कि यह सस्ता है, tagline के बिना section title को “Faster than GitHub Actions” कर देना बेहतर होगा
      “Ubicloud is an open, free, and portable cloud...” वाला पैराग्राफ भी धुंधला है। “Ubicloud एक open और मुफ्त cloud है। आप इसे अपनी पसंद के hosting provider पर चला सकते हैं, या अपना hardware ला सकते हैं। source code GitHub पर देखें!” जैसा कुछ ज्यादा स्पष्ट लगता है
    • Ubicloud के बारे में पहली बार सुन रहा हूं, लेकिन GitHub Actions काफी इस्तेमाल किया है, और इसके सस्ते व तेज होने की वजह यह लगती है कि GitHub Actions compute पर cost के मुकाबले बहुत बड़ा margin लगाता है
      मोटे तौर पर देखें तो base rate करीब $0.008 per minute है, जो EC2 hourly pricing से तुलना करने पर भी कोई बहुत अजीब ratio नहीं है
      मैंने एक project किया था जिसमें सिर्फ एक EC2 instance चलाकर उसे Actions से connect करने भर से cost काफी घट गई और build time भी बेहतर हुआ
    • feedback को शामिल करके copy को ज्यादा स्पष्ट करने के लिए कुछ जगहों पर बदलाव किए हैं, और UX bug भी ठीक कर रहे हैं; अगले कुछ हफ्तों में एक बड़ा update भी आएगा
    • मुझे लगता है build server चलाने की cost इतनी ज्यादा नहीं होती

  • Rust project [0] में हम कई महीनों से Ubicloud builders इस्तेमाल कर रहे हैं और ये काफी अच्छे चले हैं। CI time 10–15 मिनट से घटकर 6–7 मिनट हो गया, और cost $300/month से $30/month पर आ गई
    जो बात अप्रत्याशित थी, वह cache save/restore का धीमा होना था। machine का CPU अच्छा है, इसलिए हमारे लिए cache पूरी तरह बंद करके हर build में सब कुछ दोबारा करना ज्यादा तेज निकला
    [0] https://github.com/ArroyoSystems/arroyo

    • उन repositories के real examples देखना अच्छा है जिन्होंने official GitHub Actions runner के अलावा runner पर switch किया है। मैं धीरे-धीरे GitHub vs Buildjet/Warpbuild/Ubicloud vs मेरे solution RunsOn की per-repository runtime comparison इकट्ठा कर रहा हूं
      यह workflow AWS ephemeral machines पर Ubicloud जैसी कीमत में 5 मिनट से कम में चल सकता है: https://github.com/runs-on/arroyo/actions/runs/7723361513/jo...
    • SPDK link बहुत दिलचस्प था: https://www.ubicloud.com/blog/building-block-storage-for-clo...
      high-performance applications में filesystem इस्तेमाल करते हुए, मैंने पाया कि ZFS अक्सर XFS ± mdadm ± encryption जैसी सरल configurations की तुलना में bottleneck बन जाता था
      यह विवादास्पद point है, लेकिन मिलता-जुलता result भी है: https://klarasystems.com/articles/virtualization-showdown-fr... : “कई readers के लिए यह चौंकाने वाला हो सकता है, लेकिन मेरे लिए व्यक्तिगत रूप से नहीं था। मैंने OpenZFS और Linux KVM के साथ guest storage performance को 10 साल से ज्यादा test किया है, और zvol हर बार तुलनात्मक रूप से खराब perform करता रहा”
      लगता है OpenZFS ने भी modern drives (SSD, NVMe), जिनकी performance characteristics ZFS के बनाए जाने के समय के spinning disks से बहुत अलग हैं, के लिए optimizations पर विचार शुरू कर दिया है
      SPDK summary में कहा गया है कि “VM provisioning time घटाने के लिए host OS को ext4 से btrfs में बदला”, और “host filesystem को btrfs में बदलते ही disk performance में साफ गिरावट आई और throughput ext4 का लगभग 1/3 रह गया”
      Ubicloud की समस्या कुल मिलाकर copy-on-write filesystems से जुड़ी लगती है, और CoA नाम का थोड़ा अलग variant चुनना दिलचस्प है, लेकिन उत्सुकता है कि क्या XFS, Ext4 जैसे journaling filesystems के ऊपर overlay रखने वाले ज्यादा सरल विकल्पों पर विचार किया गया था
      या UFS2 + snapshots से initialized test-ready state restore करके हर test के बीच उसी state पर लौटना भी संभव लगता है
      अगर customers को cache बंद करना बेहतर लग रहा है, तो इसका मतलब लगता है कि CoA में भी CoW जैसी ही समस्याएं हैं
      निजी तौर पर, complexity बढ़ाने के बजाय मैं customer-specific namespaces के साथ SR-IOV आजमाकर बात खत्म कर देता, लेकिन जरूर कोई अच्छी वजह रही होगी, इसलिए वह वजह जानना चाहूंगा
    • cache पूरी तरह बंद करके हर build में दोबारा करने का तरीका अगर इसी तरह की सभी कंपनियों/workloads के scale तक बढ़े, तो उसका carbon footprint कैसा होगा, यह जानने की उत्सुकता है
    • share करने के लिए धन्यवाद। repository देखकर लगा कि कुछ jobs अभी भी GitHub-hosted runners पर चल रही थीं; जानना चाहूंगा कि सब कुछ Ubicloud पर क्यों नहीं चलाते

  • मैं Ubicloud के सह-संस्थापकों में से एक Ozgun हूँ
    अभी दर्जनों ग्राहक production में Ubicloud runners इस्तेमाल कर रहे हैं, और हम इस समय caching layer डिज़ाइन कर रहे हैं। Docker instance registry, Docker layer cache, package cache जैसे हिस्सों पर राय सुनना चाहते थे, इसलिए इसे सार्वजनिक किया है
    व्यापक तौर पर, अगर खुले और portable cloud के विषय पर भी कोई points हों तो बताएं

    • अच्छा होगा अगर Depot की तरह तेज़ persistent disk को build के पास रखकर Docker layers cache किए जाएं
      GitHub Actions runner, CircleCI आदि में layers को manually cache करने के लिए महंगे network calls जोड़ने का तरीका हमेशा बहुत समय लेता रहा है, और लगता है कि इससे कई लोग cache को पूरी तरह हटा देते हैं
    • अच्छा होगा अगर GitHub की runner images build करके Docker Hub पर अपलोड की जा सकें
      act [0] जैसे दूसरे GitHub Actions clone users के लिए यह काफी उपयोगी होगा
      [0]: https://github.com/nektos/act

  • BuildJet [0] को एक साल से ज़्यादा समय से संतुष्टि के साथ इस्तेमाल कर रहा हूँ
    GH Actions के मुकाबले CI लागत में $25k से ज़्यादा बचाए, और BuildJet भी Hetzner के शक्तिशाली bare-metal servers इस्तेमाल करता है, इसलिए build time लगभग 94% घट गया
    सच में बहुत संतुष्ट हूँ, और market में और companies का आना अच्छा है
    [0] https://buildjet.com

  • हमारे GHA खर्च का सबसे बड़ा हिस्सा MacOS execution है। क्या आप MacOS को managed service के रूप में देते हैं, या देने की योजना है? यह भी जानना चाहूंगा कि GitHub से कितना सस्ता होगा

    • निकट भविष्य में देने की योजना नहीं है
      Ubicloud bare-metal providers के ऊपर चलता है, और वे Mac hardware rent पर नहीं देते
      तकनीकी रूप से arm64 पर MacOS VM चलाया जा सकता है, लेकिन Apple End User License Agreement (EULA) को देखकर हमारी व्याख्या है कि ऐसा नहीं करना चाहिए
      इस repository में संबंधित references अच्छी तरह संकलित हैं: https://github.com/kholia/OSX-KVM?tab=readme-ov-file#is-this...
    • MacOS की सबसे बड़ी समस्या यह है कि physical Mac चाहिए, virtualization नहीं हो सकता, और याद पड़ता है कि Apple license कम-से-कम 24 घंटे की rental period जैसी शर्तें मांगता है
      OS X terms में यह लिखा है:
      3. अनुमत developer services के लिए lease. A. Lease. आप वैध रूप से licensed Apple Software की पूरी copy किसी individual या organization (प्रत्येक “Lessee”) को lease या sublease कर सकते हैं, बशर्ते ये सभी conditions पूरी हों: (i) leased Apple Software का इस्तेमाल केवल permitted developer services देने के उद्देश्य से किया जाना चाहिए और प्रत्येक Lessee को इस license की शर्तों की समीक्षा करके उनसे बंधे रहने के लिए सहमत होना होगा; (ii) प्रत्येक lease period कम-से-कम लगातार 24 घंटे की होनी चाहिए
    • WarpBuild [1] में M2 Pro आधारित GitHub MacOS 13 runners support हैं
      समान स्तर के GitHub-hosted runners से लगभग 25% तेज़ और प्रति मिनट लागत 50% कम है
      [1] https://docs.warpbuild.com/runners#macos-m2-pro-on-arm64

  • Resmo में हम कुछ समय से Ubicloud इस्तेमाल कर रहे हैं और यह सच में 10 गुना सस्ता है। थोड़ा और performance पाने के लिए instance size 2 गुना कर दिया, फिर भी 5 गुना सस्ता है
    मुख्य वजह यह है कि platform Hetzner dedicated instances पर hosted है

    • तो फिर मैं जानना चाहूंगा कि GitHub Action से Hetzner में मौजूद अपने CI को webhook request क्यों नहीं भेजनी चाहिए

  • PeerDB[1] में हम कुछ समय से Ubicloud runners इस्तेमाल कर रहे हैं। value-for-money अच्छा है और खासकर ARM runners ने CI cost घटाने में मदद की
    team भी responsive है, और हमारे request करने के कुछ ही हफ्तों में उन्होंने ARM runner support जोड़ दिया
    [1] https://github.com/PeerDB-io/peerdb

  • GitHub Actions runner pricing में परेशान करने वाली बात minute-based billing है। क्या per-second billing नहीं हो सकती? minimum 1 minute रख लें, लेकिन उसके बाद seconds के हिसाब से charge करें तो अच्छा होगा
    लगता तो है कि यह jobs के बीच VM reboot होने में लगने वाले time की भरपाई के लिए है

    • WarpBuild में हम ठीक यही कर रहे हैं। मकसद ज़्यादातर यह है कि random costs users पर न थोपें और fair रहें
      VM reboot time तेज़ी से accumulate होता है, इसलिए शायद यही वजह होगी
      हालांकि कुछ users 16 vCPU instance पर लगभग 2 second लगने वाला lint job भी चलाते हैं, इसलिए minimum 1 minute billing बनाए रखी है

  • Elastic license को open source नहीं कहना चाहूंगा। source public होना अच्छा है, लेकिन यह open source license नहीं है
    replies देखकर लगता है कि यह जानकारी पुरानी है, और अब project AGPL इस्तेमाल करता दिख रहा है

    • docs में अभी भी लिखा है कि Elastic license इस्तेमाल होता है, लेकिन https://github.com/ubicloud/ubicloud/blob/main/LICENSE देखने पर लगता है कि project करीब एक दिन पहले GNU Affero General Public License v3.0 पर बदल गया है

  • launch के लिए बधाई। उम्मीद है Ubicloud पिछले project Citus से भी ज्यादा सफल होगा