Twake Drive – ทางเลือกโอเพนซอร์สแทน Google Drive

 (github.com/linagora)
19 คะแนน โดย GN⁺ 2025-10-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Twake Drive เป็นแพลตฟอร์มคลาวด์สตอเรจโอเพนซอร์สที่มอบความสามารถในการจัดเก็บและแชร์ไฟล์คล้ายกับ Google Drive
  • รองรับการปรับใช้แบบ Docker จึงสามารถรันบนสภาพแวดล้อมโลคัลได้อย่างง่ายดาย และใช้ Node.js และ MongoDB เป็นเทคโนโลยีสแต็กหลัก
  • ออกแบบด้วยโครงสร้างที่แยกฟรอนต์เอนด์และแบ็กเอนด์ พร้อมมอบสภาพแวดล้อมการพัฒนาบนพื้นฐาน Yarn และความสามารถในการตั้งค่าเส้นทางจัดเก็บไฟล์ภายในเครื่อง
  • เผยแพร่ภายใต้ไลเซนส์ Affero GPL v3 ทำให้องค์กรหรือหน่วยงานสามารถปรับแต่งเพื่อนำไปโฮสต์เองได้อย่างอิสระ

ภาพรวมโปรเจกต์

  • Twake Drive เป็นโซลูชันทดแทน Google Drive แบบโอเพนซอร์สที่พัฒนาโดย Linagora โดยให้ความสามารถด้านการจัดเก็บไฟล์ การแชร์ และการทำงานร่วมกันในรูปแบบที่สามารถใช้งานบนเซิร์ฟเวอร์ของตนเองได้
    • มุ่งเป้าไปที่องค์กรที่ต้องการหลีกเลี่ยงการผูกติดกับบริการคลาวด์ และคงไว้ซึ่งความเป็นเจ้าของข้อมูลและการควบคุมความปลอดภัย
  • รีโพซิทอรีที่เผยแพร่บน GitHub มีดาวมากกว่า 1,000 รายการและฟอร์กมากกว่า 70 รายการ และยังคงได้รับการบำรุงรักษาอย่างต่อเนื่อง
  • โปรเจกต์นี้ใช้ไลเซนส์ AGPL-3.0 ซึ่งกำหนดให้เมื่อมีการแก้ไขซอร์สโค้ดและแจกจ่ายต่อ จะต้องคงเงื่อนไขไลเซนส์เดิมไว้

ฟีเจอร์หลักและเทคโนโลยีสแต็ก

  • Twake Drive ทำงานบนพื้นฐานของ Node.js(18.x ขึ้นไป), MongoDB, และ Yarn และออกแบบด้วยสถาปัตยกรรมที่แยกฟรอนต์เอนด์และแบ็กเอนด์ออกจากกัน
    • ฟรอนต์เอนด์รันจากไดเรกทอรี tdrive/frontend/ ด้วย yarn dev:start
    • แบ็กเอนด์รันจาก tdrive/backend/node/ หลังตั้งค่าตัวแปรสภาพแวดล้อมแล้วด้วย yarn dev
  • มีตัวเลือกการปรับใช้ที่เรียบง่ายผ่าน Docker Compose (docker-compose.minimal.yml) ทำให้สะดวกต่อการทดสอบบนเครื่องโลคัลและการปรับใช้ภายในองค์กร
    • สามารถเข้าถึงเว็บอินเทอร์เฟซได้ที่ http://localhost/
  • สามารถรันฐานข้อมูลได้อย่างง่ายดายด้วยคำสั่งรันคอนเทนเนอร์ MongoDB (docker run -p 27017:27017 -d mongo)
  • การตั้งค่าสภาพแวดล้อมสามารถปรับรายละเอียดได้ผ่านไฟล์ tdrive/backend/node/config/development.json

โครงสร้างการพัฒนาและการปรับใช้

  • Twake Drive แยกส่วนระหว่างฟรอนต์เอนด์ (อิง React) และแบ็กเอนด์ (อิง Node.js) และสามารถกำหนดพาธจัดเก็บไฟล์ภายในเครื่องได้โดยตรง
    • ตั้งค่าตำแหน่งจัดเก็บเอกสารผ่านตัวแปรสภาพแวดล้อม STORAGE_LOCAL_PATH
  • รองรับฟังก์ชัน publish-subscribe ในสภาพแวดล้อมโลคัลด้วยการตั้งค่า PUBSUB_TYPE=local
  • แอปพลิเคชันรันบนพอร์ต 3000 โดยค่าเริ่มต้น และมีโครงสร้างที่เหมาะกับสภาพแวดล้อมการพัฒนาและการทดสอบ
  • มีทั้งไฟล์ตั้งค่า Docker Bake (docker-bake.hcl) และคอนฟิก GitHub Actions สำหรับ CI/CD จึงรองรับการ build และทดสอบแบบอัตโนมัติ

สถานะโค้ดและรีโพซิทอรี

  • รีโพซิทอรีประกอบด้วย882 คอมมิต, 61 แบรนช์, และ 46 แท็ก สะท้อนประวัติการพัฒนาที่ต่อเนื่อง
  • สัดส่วนภาษาหลักประกอบด้วย TypeScript 58.9%, JavaScript 32.6%, SCSS 3.7%, CSS 2.2%, HTML 1.3%, Less 1.0%

ไลเซนส์และศักยภาพการนำไปใช้

  • Twake Drive เผยแพร่ภายใต้ไลเซนส์ Affero GPL v3 ซึ่งกำหนดให้การแก้ไขซอร์สโค้ดและการแจกจ่ายต่อยังคงมีภาระการเปิดเผยภายใต้เงื่อนไขเดียวกัน
  • องค์กรสามารถนำไปใช้เป็นฐานสำหรับสร้างระบบคลาวด์สตอเรจภายในองค์กร หรือขยายต่อในรูปแบบ SaaS ได้
  • ถูกมองว่าเป็นทางเลือกที่ช่วยให้บรรลุทั้งการลดต้นทุนจากบริการคลาวด์เชิงพาณิชย์ และการรักษาอธิปไตยของข้อมูลไปพร้อมกัน

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

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

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

  • หลายคนที่นี่พูดถึงฟีเจอร์จำเป็นหรือเรื่องแบ็กอัป แต่สิ่งที่สำคัญจริง ๆ คือจะสร้างชุมชนและรักษามันไว้ได้ในระยะยาวหรือไม่
    เนื่องจากสตอเรจคลาวด์โอเพนซอร์สมักหายไปอย่างรวดเร็วเมื่อผู้ดูแลหมดไฟ โมเดลธุรกิจที่ยั่งยืนหรือฐานผู้มีส่วนร่วมจึงสำคัญพอ ๆ กับเช็กลิสต์ทางเทคนิค
    อีกอย่างคือ การทำงานร่วมกันได้ (interoperability) ที่มักถูกประเมินค่าต่ำไป ถ้ารองรับ WebDAV หรือ S3 และเชื่อมกับระบบยืนยันตัวตนเดิมได้ ทีมต่าง ๆ ก็จะลองใช้ได้ง่ายขึ้นมาก
    ท้ายที่สุดผู้คนต้องการบริการที่จะไม่หายไปหลังช่วง ‘ฮันนีมูน’ จบลง ซึ่งนั่นยากกว่าการเพิ่มแถบความคืบหน้าอันเดียวมาก

    • นั่นอาจเป็นจุดอ่อนของโมเดลองค์กรของเครื่องมือนั้นก็ได้ แต่ฉันไม่อยากมีส่วนร่วมกับชุมชน แค่อยากให้มันทำงานได้ดีก็พอ
      ฉันใช้ Syncthing และไม่เคยมีใครบอกให้ฉันไปมีส่วนร่วมกับชุมชนเลย แต่มันก็ยังทำงานได้ดีอยู่
      ดูเหมือนว่า Syncthing จะหาเงินค่าพัฒนาด้วยการที่บริษัทชื่อ Kastelo ให้บริการซัพพอร์ตระดับองค์กร
      ฉันเองก็ทำบริษัทที่ปรึกษาโอเพนซอร์ส และอยู่ได้สบายด้วยสัญญากับองค์กรโดยไม่ต้องพึ่งชุมชน
      ชุมชนก็ดีอยู่หรอก แต่ในระยะยาวฉันคิดว่า โมเดลธุรกิจและกลยุทธ์การตลาด สำคัญกว่า
    • โดยส่วนตัวฉันคิดว่า ความเข้ากันได้กับ S3 คือหัวใจของ object storage
      ถ้าระบบรองรับ S3 API ก็เปลี่ยนสตอเรจอะไรก็ได้ง่ายมาก ไม่ว่าจะเป็น Backblaze, Wasabi หรือ S3 API แบบโลคัล ส่วนใหญ่แทนกันได้แทบจะทันที
    • ฉันไม่เข้าใจว่าทำไมชุมชนถึงสำคัญ ถ้าเป็นเครื่องมือที่แก้ปัญหาได้ ชุมชนก็เป็นแค่หนทางในการบำรุงรักษาเท่านั้น

  • ในบรรดา การซิงก์ไฟล์แบบ self-hosted ที่เคยใช้มา Seafile ใช้งานได้ดีที่สุด
    แต่การอัปเกรดเซิร์ฟเวอร์ก็ยังยุ่งยากอยู่ ส่วน NextCloud หรือเครื่องมือคล้ายกันนั้น สำหรับฉันมันคือ หายนะเต็มรูปแบบ

    • อยากรู้ว่าทำไมถึงคิดว่าเป็นหายนะ ที่บริษัทเราใช้ NextCloud มา 3 ปีแล้วแบบไม่มีปัญหา
      มีปลั๊กอินที่ต้องใช้ครบ ประสิทธิภาพก็ดี และการซิงก์ก็สมบูรณ์แบบ ถึงขั้นไม่มีเหตุผลให้ลองทางเลือกอื่นเลย
    • ฉันรัน Seafile ด้วย เวอร์ชัน Docker แค่เปลี่ยนแท็กก็อัปเกรดได้ง่ายมาก
      เมื่อก่อน NextCloud อืดกับรีโพขนาดใหญ่และต้องใช้เครื่องที่แรงกว่า
      แต่ Seafile ทำงานได้ดีแม้บนบอร์ด ARM ที่มี RAM 2GB
    • ไม่นานมานี้ฉันติดตั้ง Seafile ลงบนเซิร์ฟเวอร์เอง และใส่ใจกับการวาง กลยุทธ์แบ็กอัปและความปลอดภัย มาก
      ทดสอบอย่างละเอียดแล้ว และประหลาดใจกับความเร็วกับความตอบสนองของการซิงก์
      ตอนนี้ย้ายไฟล์ทั้งหมดออกจาก Google Drive มาใช้เป็นคลาวด์หลักแล้ว
    • Resilio ก็ใช้ได้ดี Syncthing ก็ดีเหมือนกัน แต่จากประสบการณ์ของฉัน Resilio เร็วกว่าและเจาะ NAT ได้ดีกว่า
    • ฉันก็ใช้ Seafile กับ Seadrive มาหลายปีแล้ว และมันทำงานได้ดีมากด้วย การแมปไดรฟ์แบบ subst

  • ถ้าตั้งชื่อว่า Twake Dwive น่าจะขำดี

  • เหมือนที่คนอื่นถาม ฉันก็อยากรู้ว่ามันเทียบกับ NextCloud หรือ ownCloud แล้วเป็นอย่างไร และมีไคลเอนต์สำหรับ Windows/Mac/Mobile หรือเปล่า

    • ownCloud มีไคลเอนต์ครบทุกแพลตฟอร์ม แต่มีบั๊กเล็ก ๆ และปัญหาความน่าเชื่อถือในแต่ละแพลตฟอร์มมากเกินไปจนฉันใช้งานไม่ได้
    • ฉันลองติดตั้ง NextCloud แล้ว และมันเป็นประสบการณ์ที่ทรมานสุด ๆ
    • จากประสบการณ์ของฉัน NextCloud เหมือน สัตว์ประหลาด PHP ที่เทอะทะ ประสิทธิภาพก็แย่ ส่วน Twake ดูเบากว่ามากและมีขอบเขตที่ชัดเจนกว่า

  • ความอยู่รอดของเครื่องมือไดรฟ์โอเพนซอร์สขึ้นอยู่กับสามอย่าง

    1. การซิงก์ที่เรียบง่ายและไม่ทำให้ตกใจเลยแม้แต่น้อย
    2. การจัดการความขัดแย้ง ที่อธิบายให้คนที่ไม่ใช่สายเทคนิคเข้าใจได้
    3. การอัปเกรดที่ไม่มีปัญหา
      ถ้า Twake ทำสิ่งเหล่านี้ได้ดีพร้อมรองรับ S3 และ LDAP ก็มีโอกาสไปได้ไกล
      แต่สิ่งที่ยากจริง ๆ คือ ความน่าเชื่อถือและเอกสารประกอบ ต้องมี threat model ที่ชัดเจน คู่มือย้ายจาก Drive หรือ Dropbox และ CLI ขนาดเล็กที่ทำงานได้แม้ในสภาพแวดล้อมแบบ headless
    • ฉันอยากเพิ่มข้อที่สี่คือ ความง่ายในการตรวจสอบแบ็กอัป
      ครั้งหนึ่งที่บริษัทเคยเปิดใช้แบ็กอัปไว้ แต่พอจะกู้คืนกลับพบว่าพังเสียหายทั้งหมด ตั้งแต่นั้นมาการตรวจสอบแบ็กอัปจึงเป็นเรื่องสำคัญอันดับหนึ่งสำหรับฉัน
    • อยากให้มีปุ่ม “ซิงก์ตอนนี้” แบบกดเองได้ ใน Google Drive สถานะการซิงก์ไม่ชัดเจนจนบางทีก็น่าหงุดหงิดมาก

  • ฉันสงสัยว่าการสร้างแอปประสิทธิภาพสูงแบบนี้ด้วย 58.9% TypeScript และ 32.6% JavaScript จะทำได้จริงหรือ

    • งั้นก็ 91.5% เป็น JavaScript ไม่ใช่เหรอ? ล้อเล่นน่ะว่า TypeScript ไม่ใช่ภาษาจริง
    • แอปนี้เป็นงานแบบ I/O-bound ดังนั้นรันด้วย TS/JS ก็ไม่มีปัญหา
    • ดูเหมือนว่าแบ็กเอนด์เป็น TS ส่วนฟรอนต์เอนด์เป็น JS ฉันเองก็แยกเทสต์ไว้เป็น JS และโค้ดแอปเป็น TS
      ฉันคิดว่าส่วนที่ไม่ใช่คอขวดสำคัญกว่าความเร็วของภาษา
    • ถ้าดูสตาร์ทอัพทุกวันนี้ที่สร้างสถาปัตยกรรมแบบ event-driven ด้วย ไมโครเซอร์วิส TS/JS การเลือกแบบนี้ก็ไม่ได้แปลกอะไร

  • ออกนอกประเด็นนิดหน่อย แต่มีวิธีทำให้ Viber หรือ WhatsApp ใช้สตอเรจแบ็กอัปอื่นแทน Google Drive ไหม? สงสัยว่าถ้ารูทเครื่องแล้วหลอกอินเทอร์เฟซจะทำได้หรือเปล่า

    • บน Android ทำแบบ share-target ได้ง่าย ๆ เลย ทำเป็น PWA ก็ได้ไม่ยาก

  • ระบบแบบนี้จำเป็นต้องมี ฐานข้อมูล จริงหรือ?
    บน Unix แค่มี CRUD ของผู้ใช้และไฟล์กับการกำหนดสิทธิ์ก็น่าจะพอแล้ว มีซอฟต์แวร์เก่า ๆ ที่แค่ครอบสิ่งเหล่านี้ด้วย UI หรือ API ไหม? ต่อให้ใช้โปรโตคอล SAMBA ก็ได้

    • ถ้าจะทำฟีเจอร์อย่างประวัติเวอร์ชันหรือ URL แชร์ ก็จำเป็นต้องมี DB
      อีกทั้งถ้าจะจำกัดตามกลุ่มผู้ใช้ ก็จะชนเพดานจำนวนกลุ่ม (65536 กลุ่ม) ได้อย่างรวดเร็ว
    • ลองดู Cockpit ได้ ที่ Cockpit Applications มีฟังก์ชันส่วนใหญ่ เช่น สำรวจไฟล์ แก้ไขสิทธิ์ อัปโหลด/ดาวน์โหลด
    • ถ้าจะทำ disk operation caching หรือซิงก์ข้ามหลายโหนด ก็ต้องมี การเก็บ metadata สุดท้ายแล้วเลยเลี่ยงการใช้ DB ได้ยาก
    • ฉันก็เคยคิดถึงอะไรแบบนั้น และอยากได้อินเทอร์เฟซสไตล์ Google Drive ที่ใช้ Python กับ fsspec เพื่อจัดการไฟล์ระบบได้หลากหลาย ทั้งโลคัลหรือ S3/SSH
    • ถ้าใช้ DB ก็จะ join users กับ documents ได้ง่าย หรือใช้ MongoDB indexes และ transactions ได้สะดวก
      การจัดการ metadata ของเวอร์ชันก็ง่ายขึ้น และยังแฮ็กใช้งานบน Windows ได้ง่ายด้วย

  • ฉันคงต่างจากบรรยากาศใน HN แต่สำหรับฉันฟีเจอร์ที่สำคัญที่สุดคือ การค้นหา
    พอเก็บข้อมูลระดับหลาย TB ก็หาภาพสักภาพได้ยากมาก
    ต้องมีฟีเจอร์วิเคราะห์ภาพที่ค้นหาได้แบบ “คนสองคนบน Nothing Street”
    ตอนนี้ Google ยังเหนือกว่ามากในเรื่องนี้ แต่ก็หวังว่าคลาวด์เจ้าอื่นจะตามทันสักวัน

  • ฉันแนะนำให้ลองใช้ Syncthing สักครั้ง

    • ฉันก็ใช้ Syncthing มาตั้งแต่ส่วนลดนักศึกษาของ Dropbox หมด และมันเสถียรมากมาหลายปีแล้ว
      เพียงแต่ประสบการณ์บนมือถือยังค่อนข้างดิบอยู่ ถึงอย่างนั้นเวลารีบก็ยังดึงไฟล์ผ่านเว็บอินเทอร์เฟซได้
    • Syncthing ยอดเยี่ยมก็จริง แต่ไม่เหมาะกับการจัดการ ไฟล์ขนาดใหญ่บนมือถือ เพราะวิธีซิงก์ทั้งชุดมีข้อจำกัด
    • มันคือ เครื่องมือ FOSS ที่ฉันเชื่อถือได้มากที่สุด ที่ฉันใช้อยู่ แค่ทำงานได้ดี และทำงานได้บนทุกแพลตฟอร์ม