แนะนำบน HN: GitHub Runner แบบโอเพนซอร์สสำหรับ x64 และ Arm

 (ubicloud.com)
2 คะแนน โดย GN⁺ 2024-01-31 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Ubicloud นำเสนอ managed runner สำหรับ GitHub Actions โดยระบุว่าเพียงเปลี่ยน 1 บรรทัดใน workflow ก็สามารถใช้งานแบบเดิมต่อไปได้ พร้อมเพิ่มความเร็วในการ build และลดต้นทุน
  • ราคาเริ่มต้นที่ Standard $0.0010 ต่อนาที, Premium $0.0016 ต่อนาที โดยเสนอค่าใช้จ่ายที่ต่ำกว่า GitHub-hosted runners 85% และ 70% ตามลำดับ
  • Standard ใช้ AMD EPYC Genoa พร้อมพื้นที่เก็บ cache ฟรี 30GB ส่วน Premium ใช้ AMD Ryzen 9 พร้อมพื้นที่เก็บ cache ฟรี 100GB
  • ด้านความปลอดภัยประกอบด้วย VM ที่แยกขาดจากกันอย่างสมบูรณ์ บน Linux KVM, VM แบบใช้ครั้งเดียวต่อแต่ละงาน, การตั้งค่า GitHub Just-In-Time runner, การเข้ารหัส และการหมุนเวียนคีย์
  • Ubicloud มุ่งเป็น คลาวด์โอเพนซอร์ส โดยสามารถดูซอร์สโค้ดบน GitHub หรือจัดการ runner ของตนเองได้หากต้องการ

วิธีผสานกับ GitHub Actions

  • Ubicloud ให้บริการ managed runner สำหรับ GitHub Actions และผสานการใช้งานด้วยการเปลี่ยนการตั้งค่า runner เพียง 1 บรรทัดใน GitHub workflow
  • ให้โควตาใช้งานฟรี 1,250 นาทีต่อเดือน
  • ชูจุดเด่นหลักคือ “เริ่มได้ภายใน 5 นาที”, “เร็วขึ้น 2 เท่า”, และ “ประหยัด 4–7 เท่า”
  • สามารถเริ่มผสานการใช้งานได้ผ่าน เอกสารเริ่มต้นอย่างรวดเร็ว

ราคาและสเปกของ runner

  • Standard runner

    • ราคาเริ่มต้นคือ $0.0010 ต่อนาที
    • ชูว่ามีค่าใช้จ่าย ต่ำกว่า 85% เมื่อเทียบกับ GitHub-hosted runners
    • ใช้ CPU บนพื้นฐาน AMD EPYC Genoa
    • ให้พื้นที่เก็บ cache ฟรี 30GB

  • Premium runner

    • ราคาเริ่มต้นคือ $0.0016 ต่อนาที
    • ชูว่ามีค่าใช้จ่าย ต่ำกว่า 70% เมื่อเทียบกับ GitHub-hosted runners
    • ใช้ CPU บนพื้นฐาน AMD Ryzen 9
    • ให้พื้นที่เก็บ cache ฟรี 100GB

  • ราคาตามฮาร์ดแวร์

    • 2 vCPU, RAM 8GB: Standard $0.0010/min, Premium $0.0016/min
    • 4 vCPU, RAM 16GB: Standard $0.0020/min, Premium $0.0032/min
    • 8 vCPU, RAM 32GB: Standard $0.0040/min, Premium $0.0064/min
    • 16 vCPU, RAM 64GB: Standard $0.0080/min, Premium $0.0128/min

การแยกสภาพแวดล้อมและความปลอดภัย

  • โมเดลความปลอดภัยเน้น VM ที่แยกขาดจากกันบน Linux KVM และ VM แบบใช้ครั้งเดียวต่อแต่ละงาน
  • จัดการ secret แบบใช้ครั้งเดียว ด้วยการตั้งค่า GitHub Just-In-Time runner
  • รวมถึงการเข้ารหัสทั้งขณะจัดเก็บและระหว่างส่งข้อมูล, การหมุนเวียนคีย์ในตัว, การตั้งค่า firewall อัตโนมัติ และการแจ้งเตือนช่องโหว่อัตโนมัติ

แนวทางคลาวด์โอเพนซอร์ส

  • Ubicloud เป็น คลาวด์โอเพนซอร์ส ที่มุ่งเป็นทางเลือกผู้ให้บริการคลาวด์แบบเดียวกับที่ Linux เป็นทางเลือกให้กับระบบปฏิบัติการแบบปิด
  • สามารถดูซอร์สโค้ดได้ที่ GitHub
  • ผู้ใช้สามารถจัดการ runner ของตนเองได้โดยตรงหากต้องการ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-31
ความคิดเห็นใน Hacker News

  • ยินดีด้วยกับการเปิดตัว ดูน่าสนใจ และราคาบนหน้าแลนดิ้งเพจก็ดูดีมาก
    ตอนนี้ผมยังไม่ใช่ลูกค้าเป้าหมาย เพราะงานที่ทำทั้งหมดเป็นโอเพนซอร์สและใช้ GitHub Actions ฟรีอยู่แล้ว แต่ก็ทำให้อยากรู้ว่าทำไมถึงถูกกว่าและเร็วกว่า / มีข้อควรระวังอะไรบ้าง
    ยังเห็นปัญหาด้านภาพเล็กน้อยตรงช่วงความกว้างหน้าต่าง 990px~ประมาณ 1200px ซึ่งเป็นขนาดหน้าต่างที่พบบ่อยบน MBP 14" โดยมี padding แนวนอนไม่พอ
    ข้อความที่ว่า “Ubicloud คือโอเพนซอร์สคลาวด์ คิดซะว่าเป็นทางเลือกแบบเปิดของผู้ให้บริการคลาวด์ เหมือนที่ Linux เป็นทางเลือกแทนระบบปฏิบัติการแบบปิด” เข้าใจยาก และตอนอ่านครั้งแรก ๆ ผมนึกว่าเขากำลังบอกว่าเป็นทางเลือกของ Linux
    น่าจะชัดเจนกว่าถ้าพูดก่อนเลยว่า มันคืออะไร แบบในส่วน “What is Ubicloud?” ของเอกสาร เช่น “ให้ความสามารถแบบ IaaS บนผู้ให้บริการเช่า bare metal อย่าง Hetzner, OVH, AWS Bare Metal และให้บริการแบบ managed service ด้วย”
    เหมือนจะมีคติการตลาดเก่า ๆ สำหรับกลุ่มวิศวกรว่า การบอกให้ชัดว่ามันคืออะไรได้ผลดีกว่าการพูดถึงประโยชน์ลอย ๆ และกรณีนี้ก็น่าจะต้องมีทั้งสองอย่าง ควรบอกทั้งตัวตนที่แท้จริงและเหตุผลว่าทำไมถึงถูกกว่าและดีกว่า
    ในย่อหน้านั้นยังมีคำผิดที่เว้นวรรคหายไปอย่าง systems.Ubicloud ด้วย

    • ตัวผลิตภัณฑ์ดูเจ๋งมาก ถ้าจะเสนอปรับถ้อยคำเล็ก ๆ น้อย ๆ เพิ่มอีกหน่อย “Imagine to do more” ผมไม่เข้าใจว่าหมายถึงอะไร และฟังดูเป็นข้อความโฆษณา เลยคิดว่าตัดออกน่าจะดีกว่า
      ใน “Fast runs even at this price point” ควรเอา point ออก “Price point” ไม่ได้เป็นคำพ้องกับ “price” และในเมื่อบอกอยู่แล้วว่าถูกกว่า ก็น่าจะเปลี่ยนหัวข้อส่วนนั้นเป็น “Faster than GitHub Actions” ไปเลยโดยไม่ต้องมี tagline
      ย่อหน้า “Ubicloud is an open, free, and portable cloud...” ก็ยังคลุมเครืออยู่ น่าจะชัดกว่าถ้าเขียนว่า “Ubicloud คือคลาวด์ที่เปิดเผย ฟรี และพกพาได้ คุณรันมันบนผู้ให้บริการโฮสติ้งที่คุณต้องการได้ หรือจะใช้ฮาร์ดแวร์ของตัวเองก็ได้ ดูซอร์สโค้ดได้บน GitHub!”
    • ผมเพิ่งเคยได้ยินชื่อ Ubicloud แต่ใช้ GitHub Actions มาค่อนข้างเยอะ และสาเหตุที่ถูกกว่าและเร็วกว่า ก็น่าจะเพราะ GitHub บวกมาร์จินกับคอมพิวต์สำหรับ Actionsสูงมากเมื่อเทียบกับต้นทุน
      เท่าที่ดูคร่าว ๆ ราคาพื้นฐานอยู่แถว ๆ $0.008 ต่อนาที ซึ่งพอเทียบกับราคา EC2 ต่อชั่วโมงแล้วก็ไม่ได้ดูผิดธรรมชาติมาก
      ผมเคยทำโปรเจ็กต์ที่แค่รัน EC2 instance เดี่ยวแล้วต่อเข้ากับ Actions ก็ลดต้นทุนได้มากและยังทำให้เวลา build ดีขึ้นด้วย
    • เราปรับแก้ข้อความให้ชัดขึ้นหลายจุดตามฟีดแบ็กแล้ว และกำลังแก้บั๊ก UXอยู่ด้วย พร้อมวางแผนอัปเดตใหญ่ขึ้นในอีกไม่กี่สัปดาห์ข้างหน้า
    • ผมไม่คิดว่าต้นทุนในการรัน build server จะแพงขนาดนั้น

  • เราใช้ builder ของ Ubicloud มาหลายเดือนแล้วกับโปรเจ็กต์ Rust [0] และมันทำงานได้ค่อนข้างดี เวลา CI ลดจาก 10~15 นาทีเหลือ 6~7 นาที และค่าใช้จ่ายลดจาก $300 ต่อเดือนเหลือ $30
    เรื่องที่น่าแปลกคือการบันทึก/กู้คืนแคชช้ามาก CPU ของเครื่องดีพอจนสำหรับเรา การปิดแคชไปเลยแล้ว build ใหม่ทั้งหมดทุกครั้งกลับเร็วกว่า
    [0] https://github.com/ArroyoSystems/arroyo

    • ดีที่ได้เห็นกรณีจริงของรีโปที่เปลี่ยนจาก official GitHub Actions runner ไปใช้ runner แบบอื่น ตอนนี้ผมกำลังค่อย ๆ รวบรวมการเทียบเวลาแต่ละรีโประหว่าง GitHub vs Buildjet/Warpbuild/Ubicloud vs โซลูชันของผมเอง RunsOn
      เวิร์กโฟลว์นี้รันบนเครื่องชั่วคราวของ AWS ได้ภายใน 5 นาที ที่ราคาเท่ากับ Ubicloud: https://github.com/runs-on/arroyo/actions/runs/7723361513/jo...
    • ลิงก์ SPDK น่าสนใจมาก: https://www.ubicloud.com/blog/building-block-storage-for-clo...
      ผมใช้ไฟล์ซิสเต็มกับแอปพลิเคชันประสิทธิภาพสูง และหลายครั้ง ZFS กลายเป็นคอขวดเมื่อเทียบกับชุดที่เรียบง่ายกว่าอย่าง XFS ± mdadm ± encryption
      เป็นประเด็นที่ถกเถียงได้ แต่ก็มีผลลัพธ์คล้ายกันอยู่: https://klarasystems.com/articles/virtualization-showdown-fr... : “อาจทำให้ผู้อ่านหลายคนแปลกใจ แต่สำหรับผมไม่แปลกใจเลย ผมทดสอบประสิทธิภาพ guest storage ของ OpenZFS และ Linux KVM มานานกว่าสิบปีแล้ว และ zvol ก็ให้ประสิทธิภาพค่อนข้างแย่ทุกครั้ง”
      ดูเหมือน OpenZFS เองก็เริ่มพิจารณาการปรับแต่งให้เหมาะกับไดรฟ์ยุคใหม่ (SSD, NVMe) ซึ่งมีลักษณะด้านประสิทธิภาพต่างจากดิสก์จานหมุนที่ ZFS ถูกออกแบบมาสำหรับมันมาก
      ในสรุป SPDK มีข้อความว่า “เราเปลี่ยน host OS จาก ext4 เป็น btrfs เพื่อลดเวลา provisioning VM” และ “หลังเปลี่ยน host filesystem เป็น btrfs ประสิทธิภาพดิสก์ลดลงอย่างเห็นได้ชัด และ throughput เหลือประมาณ 1/3 ของ ext4”
      ปัญหาของ Ubicloud ดูเหมือนจะเกี่ยวกับไฟล์ซิสเต็มแบบ copy-on-writeโดยรวม และแม้การเลือกใช้รูปแบบที่ต่างออกไปเล็กน้อยอย่าง CoA จะน่าสนใจ แต่ก็สงสัยว่าเคยพิจารณาทางเลือกที่ง่ายกว่านี้หรือไม่ เช่น การวาง overlay บนไฟล์ซิสเต็มแบบ journaling อย่าง XFS หรือ Ext4
      หรือจะใช้ UFS2 + snapshot เพื่อกู้คืนสภาพพร้อมทดสอบตั้งต้น แล้ว revert กลับไปที่สถานะนั้นระหว่างแต่ละรอบทดสอบก็น่าจะเป็นไปได้
      ถ้าลูกค้ารู้สึกว่าปิดแคชไปเลยดีกว่า ก็เหมือนบอกเป็นนัยว่า CoA อาจมีปัญหาคล้ายกับ CoW
      ส่วนตัวผมคงลองใช้SR-IOVพร้อม namespace แยกตามลูกค้าแล้วจบไปมากกว่าแทนที่จะเพิ่มความซับซ้อน แต่ก็น่าจะมีเหตุผลที่ดีแน่ ๆ เลยอยากรู้ว่าเหตุผลนั้นคืออะไร
    • ผมสงสัยว่าถ้าขยายแนวทางปิดแคชแล้ว build ใหม่ทุกครั้งออกไปยังทุกบริษัท/ทุกขนาดงานที่มีลักษณะคล้ายกัน carbon footprint จะออกมาเป็นอย่างไร
    • ขอบคุณที่แชร์นะ ดูจากรีโปแล้วเห็นว่างานบางส่วนยังรันบน GitHub-hosted runner อยู่ เลยสงสัยว่าทำไมถึงยังไม่ได้ย้ายทั้งหมดไปรันบน Ubicloud

  • หนึ่งในผู้ก่อตั้ง Ubicloud ชื่อ Ozgun
    ตอนนี้มีลูกค้าหลายสิบรายใช้ Ubicloud runner ในระบบโปรดักชันอยู่ และกำลังออกแบบ ชั้นแคช อยู่ในตอนนี้ จึงเปิดเผยออกมาเพื่ออยากฟังความเห็นเกี่ยวกับส่วนต่าง ๆ อย่าง Docker instance registry, Docker layer cache และ package cache
    ในภาพกว้างกว่านั้น ถ้าใครมีข้อคิดเห็นเกี่ยวกับประเด็นเรื่องคลาวด์ที่เปิดเผยและพกพาได้ ก็ยินดีรับฟังเช่นกัน

    • น่าจะดีถ้ามี persistent disk ที่เร็วแบบ Depot อยู่ใกล้กับขั้นตอน build เพื่อใช้แคช Docker layer
      วิธีเพิ่ม network call ราคาแพงเพื่อแคชเลเยอร์ด้วยตัวเองใน GitHub Actions runner, CircleCI ฯลฯ มักกินเวลามากเสมอ และดูเหมือนจะทำให้หลายคนลบแคชออกไปเลย
    • น่าจะดีถ้าสามารถ build runner image ของ GitHub แล้วอัปโหลดขึ้น Docker Hub ได้
      น่าจะมีประโยชน์มากสำหรับผู้ใช้ GitHub Actions clone ตัวอื่นอย่าง act [0]
      [0]: https://github.com/nektos/act

  • ใช้ BuildJet [0] มานานกว่าหนึ่งปีแล้วและพอใจมาก
    ประหยัด ค่าใช้จ่าย CI ไปได้มากกว่า $25k เมื่อเทียบกับ GH Actions และเพราะ BuildJet ก็ใช้ bare metal server ที่แรงของ Hetzner เหมือนกัน เวลา build จึงลดลงราว 94%
    พอใจมากจริง ๆ และยินดีที่มีบริษัทในตลาดนี้เพิ่มขึ้นอีก
    [0] https://buildjet.com

  • ส่วนที่ใหญ่ที่สุดของค่าใช้จ่าย GHA ของเราคือ การรัน MacOS มีให้บริการ MacOS แบบ managed service ไหม หรือมีแผนจะให้บริการหรือเปล่า? แล้วราคาถูกกว่า GitHub แค่ไหน?

    • ยังไม่มีแผนจะให้บริการในอนาคตอันใกล้
      Ubicloud ทำงานอยู่บนผู้ให้บริการ bare metal ซึ่งผู้ให้บริการเหล่านั้นไม่ได้ปล่อยเช่า Mac hardware
      ในทางเทคนิคสามารถรัน MacOS VM บน arm64 ได้ แต่จากการอ่าน Apple End User License Agreement (EULA) ของเรา เราตีความว่าไม่ควรทำแบบนั้น
      มีการรวบรวมข้อมูลอ้างอิงที่เกี่ยวข้องไว้ดีใน repository นี้: https://github.com/kholia/OSX-KVM?tab=readme-ov-file#is-this...
    • ปัญหาใหญ่ที่สุดของ MacOS คือจำเป็นต้องมี Mac จริง ไม่สามารถทำ virtualization ได้ และถ้าจำไม่ผิด Apple license ยังกำหนดเงื่อนไขอย่าง ระยะเวลาเช่าขั้นต่ำ 24 ชั่วโมง ด้วย
      ในข้อกำหนดของ OS X เขียนไว้แบบนี้:
      3. การให้เช่าสำหรับบริการนักพัฒนาที่ได้รับอนุญาต A. การให้เช่า คุณสามารถให้เช่าหรือให้เช่าช่วง Apple Software ที่มีไลเซนส์ถูกต้องครบถ้วนแก่บุคคลหรือองค์กรแต่ละราย (“Lessee”) ได้ โดยต้องเป็นไปตามเงื่อนไขทั้งหมดต่อไปนี้: (i) Apple Software ที่ให้เช่าต้องใช้เพื่อวัตถุประสงค์ในการให้บริการนักพัฒนาที่ได้รับอนุญาตเท่านั้น และ Lessee แต่ละรายต้องตรวจสอบและยอมรับว่าตนผูกพันตามข้อกำหนดไลเซนส์นี้; (ii) ระยะเวลาการเช่าแต่ละครั้งต้องต่อเนื่องอย่างน้อย 24 ชั่วโมง
    • WarpBuild [1] รองรับ GitHub MacOS 13 runner บน M2 Pro
      เร็วกว่ารันเนอร์โฮสต์โดย GitHub ระดับเดียวกันราว 25% และราคาต่อนาทีถูกกว่า 50%
      [1] https://docs.warpbuild.com/runners#macos-m2-pro-on-arm64

  • ที่ Resmo เราใช้ Ubicloud มาสักพักแล้ว และมันถูกกว่าจริง 10 เท่า แม้จะเพิ่มขนาดอินสแตนซ์เป็น 2 เท่าเพื่อเอาประสิทธิภาพเพิ่มอีกหน่อย ก็ยังถูกกว่า 5 เท่าอยู่ดี
    เหตุผลหลักคือแพลตฟอร์มนี้โฮสต์อยู่บน dedicated instance ของ Hetzner

    • ถ้าอย่างนั้นก็สงสัยว่าทำไมถึงไม่แค่ส่ง webhook request จาก GitHub Action ไปยัง CI ของตัวเองที่อยู่บน Hetzner ล่ะ

  • ที่ PeerDB[1] เราใช้ Ubicloud runner มาสักพักแล้ว คุ้มค่ามาก และโดยเฉพาะ ARM runner ก็ช่วยลดค่าใช้จ่าย CI ได้
    ทีมตอบสนองเร็วมาก และก็เพิ่มการรองรับ ARM runner ภายในไม่กี่สัปดาห์หลังจากที่เราขอ
    [1] https://github.com/PeerDB-io/peerdb

  • สิ่งที่น่าหงุดหงิดในราคาของ GitHub Actions runner คือการ คิดเงินเป็นนาที จะคิดเงินเป็นวินาทีไม่ได้หรือ? ต่อให้มีขั้นต่ำ 1 นาทีก็ยังดี ถ้าหลังจากนั้นคิดเป็นวินาทีก็น่าจะดีกว่า
    เดาว่าคงทำแบบนี้เพื่อชดเชยเวลาที่ VM รีบูตระหว่างงาน

    • WarpBuild ทำแบบนั้นอยู่พอดี จุดประสงค์หลักคือเพื่อความยุติธรรมและไม่ผลักภาระค่าใช้จ่ายสุ่ม ๆ ไปให้ผู้ใช้
      เวลารีบูต VM สะสมขึ้นได้เร็วมาก เลยน่าจะเป็นเหตุผลนั้น
      แต่ก็มีผู้ใช้ที่รันงาน lint ใช้เวลาแค่ประมาณ 2 วินาทีบนอินสแตนซ์ 16 vCPU อยู่เหมือนกัน จึงยังคง การคิดเงินขั้นต่ำ 1 นาที ไว้

  • อยากให้เลิกเรียก Elastic license ว่าเป็น โอเพนซอร์ส มันเปิดให้ดูซอร์สก็จริง แต่ไม่ใช่ไลเซนส์โอเพนซอร์ส
    ดูจากคำตอบต่าง ๆ แล้วข้อมูลนี้น่าจะเก่าไปแล้ว และตอนนี้โครงการน่าจะใช้ AGPL แล้ว

    • ในเอกสารยังเขียนว่าใช้ Elastic license อยู่ แต่ดูจาก https://github.com/ubicloud/ubicloud/blob/main/LICENSE แล้ว เหมือนว่าโครงการเพิ่งเปลี่ยนเป็น GNU Affero General Public License v3.0 เมื่อประมาณหนึ่งวันก่อน

  • ขอแสดงความยินดีกับการเปิดตัว ขอให้ Ubicloud ประสบความสำเร็จยิ่งกว่าโปรเจกต์ก่อนหน้าของพวกเขาอย่าง Citus