Uncloud - เครื่องมือสำหรับดีพลอยแอปคอนเทนเนอร์ข้ามเซิร์ฟเวอร์โดยไม่ต้องมีความซับซ้อนของ Kubernetes

 (uncloud.run)
23 คะแนน โดย GN⁺ 2025-12-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Uncloud เป็นเครื่องมือโอเพนซอร์สที่สามารถ ดีพลอยและสเกลเว็บแอปพลิเคชันแบบคอนเทนเนอร์ ไปยังหลายเซิร์ฟเวอร์ได้โดยไม่ต้องใช้ Kubernetes
  • รองรับ เวิร์กโฟลว์ที่อิงกับ Docker Compose เหมือนเดิม พร้อมสนับสนุนการดีพลอยแบบไม่มีดาวน์ไทม์, HTTPS อัตโนมัติ และการสเกลข้ามเซิร์ฟเวอร์
  • ไม่มี central control plane โดยแต่ละเครื่องเชื่อมต่อกันผ่าน เครือข่าย P2P บนพื้นฐานของ WireGuard ทำให้คลัสเตอร์ยังทำงานต่อได้แม้บางเซิร์ฟเวอร์ออฟไลน์
  • มาพร้อม HTTPS อัตโนมัติผ่าน Caddy reverse proxy, service discovery ด้วย DNS ในตัว และความสามารถด้าน load balancing
  • สามารถดีพลอยได้ด้วยวิธีเดียวกันทั้งใน สภาพแวดล้อมแบบผสมระหว่างคลาวด์และ on-premises ช่วยให้คงอำนาจควบคุมโครงสร้างพื้นฐานและคาดการณ์ต้นทุนได้

เวิร์กโฟลว์แบบ PaaS

  • มอบประสบการณ์การดีพลอยที่เรียบง่ายแบบ Heroku หรือ Fly.io แต่ยังคง การควบคุมเซิร์ฟเวอร์และข้อมูลได้อย่างเต็มรูปแบบ
    • โครงสร้างต้นทุนที่คาดการณ์ได้ แทนการคิดค่าบริการตามจำนวนคำขอ
    • ไม่ผูกติดกับผู้ให้บริการ, ดีบักได้ด้วยเครื่องมือ SSH มาตรฐาน
  • โครงสร้างที่ เป็นมิตรกับ Docker Compose ทำให้ build, push และ deploy ได้ด้วยคำสั่งเดียว
    • ไม่ต้องมี image registry, รองรับ rolling deployment แบบไม่มีดาวน์ไทม์
    • สามารถ สเกลแบบ replication ครอบคลุมหลายเครื่องได้

การออกแบบที่ดูแลรักษาต่ำ

  • ไม่ต้องมี control plane หรือจัดการ quorum ลดความซับซ้อนในการดูแลให้เหลือน้อยที่สุด
  • รองรับ การสื่อสารระหว่างเครื่องอย่างปลอดภัยโดยไม่ต้องเปิดพอร์ต
  • มี service discovery อัตโนมัติ และ การออก HTTPS อัตโนมัติบนพื้นฐานของ Let's Encrypt ในตัว

วิธีการทำงาน

  • แทนที่จะใช้คลัสเตอร์ที่ซับซ้อน ระบบถูกสร้างเป็น เครือข่ายของเครื่องแบบเรียบง่าย เพื่อให้ได้โครงสร้างพื้นฐานที่เสถียรโดยไม่เพิ่มภาระการดูแลรักษา
  • แต่ละเครื่องจะเข้าร่วมใน WireGuard mesh network เพื่อทำ peer discovery อัตโนมัติและ NAT traversal
    • คอนเทนเนอร์จะได้รับ IP เฉพาะ ทำให้ สื่อสารกันข้ามเซิร์ฟเวอร์ได้โดยตรง
  • ใช้ สถาปัตยกรรมแบบกระจายศูนย์เต็มรูปแบบ โดยไม่มี control node ส่วนกลาง และแต่ละเครื่องจะ ซิงก์สถานะของคลัสเตอร์ ร่วมกัน
    • แม้บางเครื่องออฟไลน์ คลัสเตอร์ก็ยังทำงานต่อได้
  • ควบคุมโครงสร้างพื้นฐานทั้งหมดผ่าน CLI แบบคล้าย Docker
    • สามารถ ดีพลอย, มอนิเตอร์ และสเกล ได้ด้วยการเข้าถึง SSH ไปยังเครื่องเดียวเท่านั้น

ความสามารถหลัก

  • ดีพลอยได้ทุกที่: รองรับเครื่อง Linux ทุกประเภท ทั้ง cloud VM, dedicated server และ on-premises
  • HTTPS อัตโนมัติ: ใช้ Caddy reverse proxy ในตัวเพื่อ ออกใบรับรอง TLS และเปิดใช้ HTTPS ได้โดยไม่ต้องตั้งค่า
  • Load balancing: กระจายทราฟฟิกระหว่างคอนเทนเนอร์สำเนาที่กระจายอยู่บนหลายเครื่อง
  • Service discovery: DNS ในตัวจะติดตามตำแหน่งของบริการภายในเครือข่ายโดยอัตโนมัติ
  • Infrastructure as Code: สามารถนิยามสแตกแอปทั้งหมดได้ด้วย ไฟล์ Docker Compose ที่มีอยู่แล้ว
  • ไม่ผูกติดกับผู้ให้บริการ: ใช้งานคลาวด์และฮาร์ดแวร์ของตนเองร่วมกันได้อย่างอิสระ

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

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

 
GN⁺ 2025-12-06
ความคิดเห็นจาก Hacker News

  • สวัสดี ฉันเป็นผู้สร้างเอง ขอบคุณที่ช่วยแชร์
    Uncloud คือคอนเทนเนอร์ออร์เคสเตรเตอร์ที่ไม่มี control plane พูดให้ง่ายคือเป็น Docker Compose ที่ครอบหลายเครื่อง พร้อม mesh ของ WireGuard อัตโนมัติ, service discovery และ HTTPS ผ่าน Caddy แต่ละเครื่องจะ ซิงก์สถานะกันแบบ p2p โดยใช้ Corrosion ของ Fly.io จึงไม่จำเป็นต้องรักษา quorum
    หลังจากเคยดูแล Kubernetes ทั้งในสตาร์ตอัปและบริษัทระดับยูนิคอร์น ก็พบว่าทีมส่วนใหญ่จริง ๆ แค่ต้องการรันคอนเทนเนอร์ให้ดีบนเครื่องไม่กี่เครื่อง พร้อม networking, rollout และ HTTPS เท่านั้น ภาระในการดูแล K8s เมื่อเทียบกันแล้วสูงเกินไป
    ฟีเจอร์หลักมีดังนี้

    • ใช้สเปก Docker Compose ที่คุ้นเคย ไม่ต้องเรียนรู้ DSL ใหม่
    • build·push Docker image ไปยังเครื่องโดยตรงโดยไม่ต้องมี external registry (ใช้โปรเจกต์อีกตัวของฉัน unregistry)
    • มี CLI แบบ imperative แทน declarative ทำให้ดีบักได้ง่าย
    • เชื่อมต่อได้ทั้ง cloud VM, bare metal ไปจนถึง Raspberry Pi ที่อยู่หลัง NAT
    • ใช้หน่วยความจำน้อยกว่า 150MB
      ลิงก์โปรเจกต์: https://github.com/psviderski/uncloud
      • ผมคิดว่า K8s ก็รันคอนเทนเนอร์ได้ดีอยู่แล้วแม้ในสภาพแวดล้อมขนาดเล็ก จึงไม่เห็นเหตุผลนักว่าทำไมต้องใช้อย่างอื่น เพราะแม้แต่ดิสทริบิวชันเบา ๆ อย่าง k3s ก็ทำให้ติดตั้งง่ายขึ้นมากแล้ว เลยไม่ค่อยรู้สึกว่าต้องมีทางเลือกอื่น
      • ไอเดียน่าสนใจมาก แต่การที่ uc machine init ไปรัน curl | bash ด้วยสิทธิ์ root ภายใน ดู เสี่ยงด้านความปลอดภัย มาก อยากลองทดสอบนะ แต่คงไม่รันบนเครื่องจริง
      • น่าสนใจมาก คิดว่าน่าจะได้ลองในเร็ว ๆ นี้ แต่ดูจากเอกสารแล้ว ยังไม่ชัดเจนว่าจะ onboard วิศวกรคนอื่นหลังตั้งค่าคลัสเตอร์แล้วอย่างไร หรือจะ deploy จาก CI/CD runner แบบไหน อยากรู้ขั้นตอนการเชื่อมเครื่องใหม่เข้าคลัสเตอร์เดิม
      • อยากรู้ว่าต่างจาก Kamal อย่างไร
      • อยากรู้ว่าภายใน private network ที่สร้างด้วย WireGuard จะทำ การเชื่อมต่ออย่างปลอดภัย ไปยังบริการภายนอกอย่าง AWS RDS ได้อย่างไร รองรับแบบเดียวกับ แนวทางเข้าถึง AWS RDS ของ Tailscale หรือไม่

  • ฉันใช้เวลาส่วนใหญ่ในอาชีพกับ Kubernetes เลยอยากรู้ว่าข้อดีของสถาปัตยกรรมที่ไม่มี control plane คืออะไร สำหรับฉัน control plane นี่แหละคือหัวใจของ K8s
    ระดับหลายร้อยโหนด หลายหมื่นคอนเทนเนอร์ก็ไม่ได้เป็นภาระใหญ่นัก เพราะคลัสเตอร์แบบ managed อัปเดตอัตโนมัติให้หมด เลยสงสัยว่าความเจ็บปวดจากการ self-host K8s เองนี่แหละหรือที่ทำให้เกิดทางเลือกแบบนี้

    • “หลายร้อยโหนด หลายหมื่นคอนเทนเนอร์” ฟังดูไม่เล็กเลย สำหรับผมสเกลคือ 2~5 โหนด กับ 10~30 คอนเทนเนอร์ และในขนาดนี้ K8s หนักเกินไป น่าจะมีบริษัทเล็กจำนวนมากที่อยู่ในจุดนี้
    • ไม่ใช่คำถามเสียมารยาทเลย ข้อดีของการไม่มี control plane คือมันลดความซับซ้อนให้ทุกเครื่องเป็น โครงสร้างแบบ peer ที่เท่าเทียมกัน ไม่มี “สมองของคลัสเตอร์” แบบรวมศูนย์ จึงไม่ต้องกังวลเรื่องการทำ HA หรือปัญหา quorum ของ etcd
      ต่อให้เครือข่ายแยกส่วน แต่ละพาร์ทิชันก็ยังทำงานได้อย่างอิสระ เป็นความเรียบง่ายแบบยุค Chef หรือ Ansible ที่นำบทเรียนจาก K8s มาปรับใช้
    • แน่นอนว่าคนยังพยายาม self-host K8s กันอยู่ ก็เหมือนการสำรองข้อมูล ถ้าไม่เคยลองไว้ก่อน ตอนจำเป็นจริงอาจทำไม่เป็น
    • สำหรับธุรกิจขนาดเล็กถึงกลาง คอนเทนเนอร์เป็นหมื่นนี่ไม่เล็กเลย ของผมมีไม่ถึง 10 แต่ต้องการ high availability (HA) และ Uncloud ก็ดูเหมาะกับเคสนี้มาก
    • “คอนเทนเนอร์เป็นหมื่นนี่เล็กเหรอ นั่นมันตัวเลขของงาน CI หรือเปล่า? ;)”

  • โปรเจกต์เจ๋งมาก ไว้จะลองใช้แน่นอน
    ถ้าอยากได้ทางเลือกที่เรียบง่ายกว่านี้ Kamal ก็ใช้ได้เหมือนกัน เป็นเครื่องมือที่ใช้งานจริงและ ผ่านการพิสูจน์ในภาคสนาม โดยบริษัทที่ออกจากทั้ง K8s และคลาวด์มาแล้วและดูแลระบบเอง

  • อยากรู้ว่าถ้าระบุเซิร์ฟเวอร์ให้แล้ว มีฟีเจอร์ทำ server hardening อัตโนมัติหรือไม่

  • ฉันใช้ Docker Swarm อยู่ และ Uncloud เป็นทางเลือกแรกที่รู้สึกว่าน่าสนใจจริง ๆ
    สิ่งที่อยากรู้มีดังนี้

    • มีแผนรองรับ secrets หรือไม่
    • แบบเดียวกับ Swarm+Traefik สามารถกำหนดกฎ URL rewrite ผ่าน container label ได้หรือไม่
    • ถ้า deploy Compose stack สองชุด คอนเทนเนอร์ข้ามคนละสแตกจะเข้าถึงเครือข่ายกันได้หรือไม่
    • การแมปโดเมนกับพอร์ตภายในกำหนดในไฟล์ Compose ได้ด้วย x-ports: app.example.com:8000/https
      หรือจะปรับแต่ง การตั้งค่า Caddy ผ่าน x-caddy: Caddyfile ก็ได้ ดูรายละเอียดได้ในเอกสารทางการ
      ตอนนี้ยัง ไม่มีฟีเจอร์แยกเครือข่ายระหว่างสแตก การพูดคุยเรื่องนี้อยู่ที่ GitHub Discussion #94
      อยากรู้ว่าคุณคาดหวังพฤติกรรมแบบไหน
    • ฟีเจอร์ secrets กำลังติดตามอยู่ใน issue #75 ตอนนี้ inject ผ่าน Compose config ได้ แต่ยังไม่มี การจัดเก็บแบบเข้ารหัส
      คำตอบของคำถามข้อ 2 และ 3 คือ “ยังไม่ได้” และ “ตอนนี้ได้” ตามลำดับ ดูการพูดคุยเพิ่มเติมได้ที่ Discussion #94
      ในฐานะคนที่เคยใช้ Swarm มาก่อน อยากรู้ว่าอะไรคือจุดที่ Swarm ยังขาดหรือใช้งานไม่สะดวก ซึ่ง Uncloud น่าจะช่วยปรับปรุงได้

  • โปรเจกต์ดีมาก เครื่องมืออื่น ๆ ในหัวข้อคล้ายกันก็น่าสนใจเช่นกัน

    • Dokploy
    • Coolify
    • Kubero
      ถ้าใครรู้จักตัวอื่นอีกก็อยากให้ช่วยเพิ่ม
    • ลิสต์ Self-hosted PaaS มีประโยชน์มาก
      ช่วงหลังได้ลองใช้ Coolify แล้วรู้สึกว่ายัง ไม่ค่อยสมบูรณ์ ตอนนี้ใช้ Dokku อยู่ แต่ก็อยากให้ UI สำหรับจัดการฐานข้อมูลดีขึ้นกว่านี้

  • ฉันพอใจกับ k3s อยู่แล้ว แต่ก็ยินดีที่เห็นความพยายามใหม่ ๆ ใน พื้นที่ตรงกลาง ระหว่าง Docker Compose กับ K8s แบบเต็มรูปแบบ โดยเฉพาะการผสาน WireGuard ที่น่าสนใจมาก

  • เป็นเครื่องมือที่ยอดเยี่ยมจริง ๆ ขอบคุณสำหรับความทุ่มเท
    แต่อยากรู้ว่าระบบ state replication ฝั่งแบ็กเอนด์ทำงานอย่างไร เห็นพูดถึง CRDT กับ gossip protocol แต่รายละเอียดการใช้งานจริงยังไม่ชัด

    • ตอนนี้ state replication อิงกับ Corrosion

  • ถ้าไม่ใช้ K8s แล้วทำไมไม่ใช้ Nomad ล่ะ

    • Nomad ก็ดี แต่ก็ยังมี control plane อยู่
    • Nomad มี learning curve พอสมควร แต่ Uncloud นั้นใครที่รู้จัก Docker และ Compose ก็แทบจะ เริ่มใช้ได้ทันที
    • ไลเซนส์ของ HashiCorp ห้ามนำไปแก้ไขแล้วให้บริการในรูปแบบ SaaS
      หมายความว่านอกจากโฮสต์ใช้เองแล้ว การนำไปใช้งานจะถูกจำกัด และในทางปฏิบัติก็คือ ไม่สามารถทำเป็นบริการได้อย่างอิสระ ดู ข้อความเต็มของไลเซนส์

  • เพื่ออ้างอิง ขอแชร์ คอมโพเนนต์ p2p ที่น่าสนใจสองตัว