คู่มือสร้างสภาพแวดล้อม Self-Hosting ขั้นสุด

 (codecaptured.com)
26 คะแนน โดย GN⁺ 2025-07-20 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังจากลองใช้แนวทาง self-hosting หลากหลายแบบมาหลายปี ผู้เขียนได้แบ่งปันประสบการณ์การสร้างสภาพแวดล้อมแบบคัสตอมที่ประสบความสำเร็จ
  • เป้าหมายหลักคือ การควบคุมข้อมูลส่วนตัว และการรักษาโครงสร้างพื้นฐานที่เชื่อถือได้ โดยผสานเทคโนโลยีสำคัญหลายอย่าง เช่น NixOS, ZFS, Tailscale และ Authelia
  • ยังให้ความสำคัญกับ การใช้งานของครอบครัวและคนใกล้ตัว ด้วยการเพิ่ม SSO และหน้าเริ่มต้นแยกต่างหากเพื่อให้เข้าถึงได้ง่ายขึ้น
  • มีการสรุปปัญหาที่พบในการใช้งานจริงและวิธีแก้แบบละเอียด (เช่น รีเวิร์สพร็อกซีสำหรับบริการภายใน, สภาพแวดล้อม VPN แบบผสม, การเชื่อมต่อระบบยืนยันตัวตน)
  • ในอนาคตมีแผนปรับปรุงเพิ่มเติม เช่น โครงสร้างพื้นฐานสำรองข้อมูลและการเสริมความปลอดภัย พร้อมทิ้งเคล็ดลับและแหล่งอ้างอิงไว้

บทนำและแรงจูงใจ

  • หลังจากทดลองวิธี self-hosting หลายแบบตลอดหลายปี ผู้เขียนก็สร้างสภาพแวดล้อมที่ "ดีพอสำหรับตัวเอง" ได้สำเร็จ
  • ได้อ้างอิงทั้งแหล่งข้อมูลโอเพนซอร์สและประสบการณ์ของผู้อื่น และต้องการแบ่งปันกระบวนการนี้เพื่อให้เป็นประโยชน์กับนักพัฒนาคนอื่น

เป้าหมาย

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

ข้อกำหนด

  • สิ่งจำเป็น

    • จำกัด การเปิดเผยบริการสู่สาธารณะบนอินเทอร์เน็ต ให้มากที่สุด เพื่อลดความเสี่ยงด้านความปลอดภัย
    • ลด downtime ของโครงสร้างพื้นฐานหลักจากความผิดพลาด ให้ต่ำที่สุด (หลีกเลี่ยง circular dependency และทำให้ rollback การตั้งค่าได้ง่าย)
    • เป็นเจ้าขององค์ประกอบหลัก เช่น ระบบยืนยันตัวตน เครือข่าย และโดเมนด้วยตนเอง พร้อมให้ความสำคัญกับโอเพนซอร์สเป็นอันดับแรก
    • คำนึงถึงการใช้งานจากมุมมองของครอบครัวและคนใกล้ตัว (มี SSO login ที่สม่ำเสมอ และต้องการการดูแลรักษาน้อย)
    • นำ การตั้งค่าแบบ declarative ผ่านไฟล์คอนฟิก มาใช้อย่างจริงจัง (เพื่อให้ง่ายต่อการทำ version control, สำรอง/กู้คืน และอ้างอิงหรือนำการตั้งค่าของผู้อื่นมาใช้)
    • การอัปเดต ต้องทำได้ง่ายและปลอดภัย เพื่อให้ดูแลได้เป็นประจำ

  • สิ่งที่ไม่ใช่ลำดับความสำคัญ

    • ไม่จำเป็นต้อง modular หรือเนี้ยบสุดขีด (ให้ความสำคัญกับการใช้งานจริงก่อน)
    • ไม่จำเป็นต้องเป็นโอเพนซอร์สทั้งหมด แต่ถ้าเป็นไปได้ก็อยากใช้
    • ไม่ได้มุ่งหา high availability (HA) โดยยอมรับ downtime ได้เพื่อแลกกับโครงสร้างที่เรียบง่าย

การเลือกเทคโนโลยี

  • NixOS

    • เป็น Linux distribution ที่จัดการการตั้งค่า OS ทั้งหมดแบบ declarative ด้วยภาษา Nix และ package manager
    • การตั้งค่าอยู่ในรูปแบบโค้ด จึงทำ version control และ rollback อย่างเป็นระบบได้
    • รองรับแพ็กเกจหลากหลาย รวมถึงการเชื่อมต่อกับ Docker/PODMAN
    • ผู้เขียนสะสมความรู้จากการอ้างอิงการตั้งค่า Nix ของนักพัฒนาคนอื่น

  • ZFS

    • เป็น filesystem ประสิทธิภาพสูง ที่มีความสามารถด้าน การปกป้องข้อมูล เด่นมาก เช่น snapshot และ rollback
    • ใช้ HDD 10TB จำนวน 4 ลูกในแบบ RAIDZ2 (ทนการเสียพร้อมกันได้ 2 ดิสก์) และใช้ SDD 256GB สำหรับ caching
    • แยก dataset ของไฟล์และมีเดีย และจัดการด้วยการ mount NFS ตามการใช้งาน
    • ทำให้ได้สถาปัตยกรรมสตอเรจหลักที่เรียบง่ายและเชื่อถือได้

  • Tailscale & headscale

    • Tailscale: Mesh VPN ที่ใช้งานสะดวก เพียงติดตั้ง client ก็เข้าถึงเครือข่ายภายในได้ โดยไม่ต้องเปิดเผยต่ออินเทอร์เน็ตสาธารณะ
    • Headscale: backend ของ Tailscale แบบโอเพนซอร์สที่โฮสต์เองได้ (ช่วยตัดความเสี่ยงจากการเปลี่ยนนโยบายของบริษัท)
    • ช่วย เพิ่มความปลอดภัยของเครือข่าย ได้ดี แต่ผู้ใช้ต้องติดตั้ง client บนอุปกรณ์ของตน
    • ในแง่ usability การต้องติดตั้ง client แยกตามอุปกรณ์ยังเป็นอุปสรรคในการเริ่มต้นอยู่บ้าง

  • Authelia & LLDAP

    • Authelia: โซลูชัน SSO / authentication / authorization บนพื้นฐาน OpenID Connect ที่เชื่อมกับ nginx proxy ได้
    • LLDAP: Lightweight LDAP ใช้สำหรับจัดการผู้ใช้/กลุ่มของ Authelia และเป็นระบบยืนยันตัวตนสำรอง
    • ทำงานได้ดีด้วยทรัพยากรน้อย แต่ตั้งค่ายากและมี learning curve ในการทำความเข้าใจว่าจะเชื่อมกับแต่ละบริการอย่างไร

การออกแบบโครงสร้าง

  • สถาปัตยกรรม

    • แต่ละเซิร์ฟเวอร์ตั้งชื่อตามชื่อดาวเคราะห์ใน Star Wars
    • จุดเข้าสู่ระบบ (public server) คือ "taris" ซึ่งให้บริการสำคัญ เช่น Authelia, headscale และบล็อก
    • headscale, Authelia, LLDAP จำเป็นต้องให้เข้าถึงจากภายนอกได้ จึงเปิดให้ใช้งานสาธารณะในขอบเขตจำกัด
    • บริการภายใน (เช่น Foundry VTT, ระบบ monitoring) ถูกทำพร็อกซีผ่าน NGINX เพื่อเปิดเผยเฉพาะตามต้องการ

  • เซิร์ฟเวอร์ภายใน

    • บนเซิร์ฟเวอร์หลัก "kuat" ใช้ TrueNAS เพื่อจัดการ NixOS VM และ ZFS storage pool
    • แยกขอบเขต snapshot/backup เป็น "files" (ข้อมูลที่กู้คืนไม่ได้) และ "media" (ข้อมูลที่กู้คืนได้หากต้องการ)
    • บริการหลักรันบน VM "bespin" ด้วย NixOS และมี VM สำหรับทดสอบ "alderaan" แยกต่างหาก

  • บริการอื่น ๆ

    • อุปกรณ์ที่สำคัญระดับ mission-critical ถูกจัดเป็น appliance แบบจุดประสงค์เดียว (เช่น ใช้ Home Assistant OS แยกต่างหากสำหรับสมาร์ตโฮม)
    • ใช้ Ansible Playbook อย่างเป็นทางการสำหรับ Matrix server และ Element client
    • จ้างใช้บริการภายนอกสำหรับอีเมลและการจัดการรหัสผ่านด้วย ProtonMail และ Bitwarden เพื่อหลีกเลี่ยง circular dependency

ปัญหาเฉพาะและวิธีแก้

  • หน้าเริ่มต้นของบริการ

    • ใช้ แดชบอร์ดแบบเรียบง่าย ที่อิงจาก Flame เพื่อช่วยให้ผู้ใช้เข้าถึงบริการต่าง ๆ ได้สะดวกขึ้น
    • ใช้งานไม่บ่อยแต่มีหน้าตาที่ดูดี จึงยังใช้งานได้จริงจนกว่าจะเปลี่ยนไปใช้บริการอื่น

  • ใช้ Tailscale ควบคู่กับ VPN อื่น

    • บางระบบปฏิบัติการ (โดยเฉพาะ Android, Windows) ไม่รองรับการรันหลาย VPN พร้อมกัน
    • จึงใช้ความสามารถ exit node ของ Tailscale ร่วมกับ Gluetun (VPN client แบบ container) เพื่ออ้อมผ่าน VPN ภายนอกอย่าง ProtonVPN
    • อย่างไรก็ตาม มีผลข้างเคียง เช่น ใช้แบตเตอรี่มากขึ้นและความเร็วตกเป็นบางครั้ง

  • ข้อควรระวังเรื่องการยืนยันตัวตน (Authentification)

    • โปรโตคอลยืนยันตัวตนหลักของบริการ self-hosting แต่ละตัว ได้แก่ OIDC (แนะนำเป็นอันดับแรก), OAuth, LDAP
    • ต้องตั้งค่าแยกทั้งในแต่ละบริการและใน Authelia
    • บัญชีผู้ดูแลระบบควรคงไว้แยกจากการผูกกับ Authelia/LLDAP เสมอ เพื่อให้มีช่องทางกู้คืนเมื่อเกิดปัญหาด้านการยืนยันตัวตน
    • สำหรับบริการที่ไม่รองรับ OIDC สามารถใช้การเชื่อมต่อระหว่าง NGINX กับพร็อกซีของ Authelia เพื่อทำ access control ได้
    • OIDC ของ Authelia และ access control ผ่าน NGINX Proxy ต้องตั้งค่าแยกจากกัน

  • DNS และการออก SSL

    • บริการสาธารณะ ใช้วิธีทั่วไป (โดเมน → public IP)
    • บริการภายใน ใช้ซับโดเมน "internal" และ Tailscale IP เพื่อป้องกันการเปิดเผยจากภายนอก
    • ใบรับรอง SSL ใช้การรองรับ Lets Encrypt ที่มีมาใน NixOS (บริการสาธารณะใช้ HTTP-01, บริการภายในใช้ DNS-01)

  • ข้อควรระวังในการติดตั้ง NixOS บน VPS

    • VPS จำนวนมากไม่มีตัวเลือกติดตั้ง NixOS มาให้
    • หากจำเป็นต้องติดตั้ง ควรอ้างอิง community wiki และตรวจสอบเส้นทางการติดตั้งที่รองรับ

  • การ mount dataset ของ TrueNAS เข้ากับ VM

    • firewall พื้นฐานของ TrueNAS จะบล็อกไม่ให้ VM เข้าถึงโฮสต์
    • จึงทำการ mount NFS dataset ตามคู่มือทางการ (สร้าง bridge network)

  • รีเวิร์สพร็อกซีสำหรับเปิดบริการส่วนตัวสู่ภายนอก

    • เมื่อใช้ headscale สามารถเปิดบริการภายในออกสู่ภายนอกได้ด้วย NGINX proxyPass
    • นอกจาก Tailscale Funnel อย่างเป็นทางการแล้ว ยังมีตัวอย่างการตั้งค่าและแหล่งอ้างอิงสำหรับการจัดวางระบบด้วย

ขั้นตอนถัดไปและโจทย์ที่ยังเหลือ

  • จำเป็นต้องเพิ่ม เซิร์ฟเวอร์สำรองข้อมูลโดยเฉพาะ และระบบตรวจสอบการกู้คืน
  • มีแผนใช้งาน การควบคุมการเข้าถึง ของ Tailscale/headscale อย่างจริงจังมากขึ้น
  • เตรียมเดินหน้า เสริมความปลอดภัย เพิ่มเติม เช่น การเข้าถึงผ่าน SSH
  • กำลังพิจารณาใช้โซลูชัน DNS ภายในแบบเข้ารหัส/แคช เช่น Pi-hole และ AdGuard Home
  • อาจขยายไปใช้บริการใหม่ เช่น Forgejo, Manyfold, RomM

แหล่งอ้างอิง

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

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

 
opminsu 2025-07-25

เจ๋งมาก!
 
GN⁺ 2025-07-20
ความคิดเห็นจาก Hacker News

  • เป้าหมายคือทำให้ครอบครัวหรือเพื่อนใช้งานได้ง่าย โดยให้ 1 คนมี 1 บัญชีล็อกอินแล้วเข้าถึงหลายบริการผ่าน SSO (Single Sign-On) ซึ่งนี่เป็นทั้งส่วนที่ยากมากและเท่มากในเวลาเดียวกัน, open source กับ Linux มีความย้อนแย้งอยู่ตรงที่มันถูกใช้แทบทุกที่และรองรับทุกโปรโตคอล แต่พอมาถึงสภาพแวดล้อมฝั่งไคลเอนต์จริง ๆ หรือการเชื่อมคนเข้าด้วยกันและสร้างองค์ประกอบแบบ groupware เอง กลับซับซ้อนกว่าเดิม, กระบวนการเชื่อมหลายระบบเข้าหากันอย่างเป็นองค์รวม รวมถึงสร้าง directory infrastructure ด้วยนั้นน่าทึ่งมาก, ไม่คิดมาก่อนว่าสักวันจะได้มาดูแล FreeIPA หรือบริการ directory service ที่เข้ากันได้กับ Windows เอง แต่ช่วงหลัง ๆ ก็รู้สึกว่าโลกแบบ OpenID กำลังเริ่มลงหลักปักฐานจริง ๆ

    • ขอบคุณที่เห็นด้วย, การล็อกอินที่เรียบง่ายและการเข้าถึงที่สะดวกคือ requirement ที่ยากที่สุดของโปรเจ็กต์นี้ และผมคิดว่ามันเป็นจุดชี้เป็นชี้ตายว่าคนจะใช้จริงหรือไม่, open source มีอยู่ทุกที่จริง แต่ปัญหาจะเริ่มทันทีเมื่อผู้ใช้ทั่วไปพยายามจะใช้มันด้วยตัวเอง, ผมคิดว่าความย้อนแย้งนี้เกิดจากการที่แต่ละโปรเจ็กต์อยากสร้างนวัตกรรมในแนวทางของตัวเอง, การไม่มีผู้เล่นรายเดียวคอยดึงทุกอย่างไปทางเดียวกันเป็นทั้งข้อดีและข้อเสีย, ถึงอย่างนั้น แค่ดูวงการ self-hosting ในช่วง 5 ปีที่ผ่านมา ก็รู้สึกได้ว่าทั้งการติดตั้งและการใช้งานง่ายขึ้นมาก

    • เห็นด้วยกับความย้อนแย้งนี้มาก, เมื่อวานผมยังโพสต์ใน แพลตฟอร์มตรวจสอบของผม เกี่ยวกับว่า FOSS เข้าถึงยากแค่ไหนสำหรับคนที่ไม่ใช่สายเทคนิค, เลยทำให้นึกว่าบางทีแพลตฟอร์มแบบ system integrator ที่เชื่อมผู้ใช้สายเทคนิคกับผู้ใช้ทั่วไปอาจเป็นทางออกได้

    • จริง ๆ แล้วไม่ได้ยากขนาดนั้น, ถ้าไม่ได้ยึดติดกับบริการใดบริการหนึ่งและใช้การรองรับ SSO เป็นเกณฑ์สำคัญอันดับแรกในการเลือก ก็เซ็ตอัปได้ง่ายกว่าที่คิด, ตอนเริ่มผมแทบไม่มีประสบการณ์เลย แต่ใช้ caddy กับ authentik แล้วก็ทำระบบ self-host ได้เสร็จเร็วมาก, อีกทางเลือกคือ yunohost ซึ่งเป็นดิสโทรที่ตั้งค่า SSO ให้แทบทั้งหมดแบบง่ายมาก

    • ผมใช้การยืนยันตัวตน SSO ของ Google, Discord และ GitHub ผ่าน authentik อยู่, ใช้งานได้ดีพอสำหรับทุกคน

  • ผมรู้ว่าการหาชุดระบบที่ “พอดีกับตัวเอง” อาจใช้เวลา เพราะแต่ละคนมีเป้าหมาย ความชอบ และสภาพแวดล้อมต่างกัน, เลยอยากสรุปเส้นทางเซ็ตอัปสุดท้ายของผมเป็นโพสต์บล็อกเพื่อแชร์, ครอบคลุมทั้งเป้าหมายและความต้องการ เทคโนโลยีที่ใช้ การออกแบบ และกระบวนการแก้ปัญหา, วิธีของผมอาจไม่ได้เหมาะกับทุกคน แต่หวังว่าจะเป็นประโยชน์อ้างอิงให้คนอื่นได้บ้าง, ผมเองก็เติบโตมาได้ด้วยคอนเทนต์และซอฟต์แวร์ฟรีมากมาย เลยอยากแบ่งปันความช่วยเหลือต่อไป

    • อยากรู้ความเห็นหลังใช้ Nix กับ homelab, ผมสายฮาร์ดคอร์พอสมควร ใช้แร็ก 25U รัน small kubernetes, ceph และ Talos Linux มานานกว่า 7 ปี แต่ยิ่งนานยิ่งอยากทำให้เรียบง่ายลง พอคิดไปคิดมาก็มักจบที่ Nix กับ ZFS, ปัญหาพวกนี้คุ้นเคยมากสำหรับผม, ถ้าคุณมีอะไรสงสัยก็ถามได้เลย

    • สงสัยว่าเคยพิจารณาใช้ coolify ไหม, ผมใช้ coolify มาเกินปีแล้ว และชอบมากตรงที่มัน deploy อัตโนมัติจาก GitHub ได้ง่ายเหมือน Heroku https://coolify.io/

    • อยากรู้ว่าคุณใช้ฟีเจอร์เข้ารหัสของ ZFS ด้วยไหม, เมื่อก่อนผมรันหลาย VM อย่าง FreeIPA บน Debian+ZFS แต่ภายหลังเปลี่ยนเป็นให้ VPS รันแค่ไลบรารีเข้ารหัสของ Seafile เพื่อให้ระบบง่ายขึ้น แล้วใช้ ZFS send/receive แบ็กอัปกลับมาที่เซิร์ฟเวอร์บ้าน, เครื่องนั้นจะเปิดตอนกลางคืนเพื่ออัปเดตและซิงก์ แล้วกลับไป sleep, เพื่อความปลอดภัยมากขึ้น ผมก็กำลังคิดว่าจะให้ ZFS บน Linux desktop (Fedora) เข้ารหัสทั้งระบบด้วยดีไหม, ตอนนี้ dataset หลักก็เข้ารหัสอยู่แล้ว เลยทำให้การซิงก์ไป external drive หรือ cloud ง่ายขึ้นมาก, แต่การเอาคลังรูปทั้งหมดขึ้น Seafile บน VPS มีค่าใช้จ่ายสูง เลยกำลังหาทางอื่นอยู่

    • รีวิวการเซ็ตอัปและคำอธิบายละเอียดมีประโยชน์มาก, ผมอาจยังเอาไปใช้แบบคุณทันทีไม่ได้ แต่ตัดสินใจว่าจะลองติดตั้ง flame เป็น dashboard เพื่อทดลองกับครอบครัว

    • ยินดีที่ได้รู้จัก, สิ่งที่คุณทำอยู่น่าสนใจมาก, ผมเองก็กำลังทำโปรเจ็กต์คล้ายกันบนฐาน NixOS, เป้าหมายคือทำกล่องเล็ก ๆ ที่ใครก็เสียบเข้ากับโมเด็มแล้วผ่าน web install wizard ก็จบ แทบไม่ต้องตั้งค่าเลย ให้ความรู้สึกแบบ Apple, ยังอยู่ช่วงต้นแต่ที่บ้านผมใช้งานจริงแล้ว, มันทำหน้าที่ทั้ง hybrid router (OPNSense/PFSense) และ app server (Nextcloud, Synology, Yunohost ฯลฯ) ในเครื่องเดียว, ทุกการตั้งค่าก็จัดการด้วย Nix module แค่ไฟล์เดียว, มี dynamic DNS, ใบรับรอง Let's encrypt, การจัดสรร subdomain อัตโนมัติแยกตามแอป, ad blocking และฝัง headscale มาให้, ตอนนี้กำลังทำ SSO อยู่ และจะขอยืมไอเดียบางอย่างจากบทความของคุณด้วย, รายละเอียดดูได้ที่ https://homefree.host

  • บางครั้งพอมองเครือข่ายในบ้านตัวเอง ก็จินตนาการว่าถ้าผมตายไป ครอบครัวจะเดือดร้อนแค่ไหน(?) หรือคนนอกจะลำบากขนาดไหนกว่าจะเข้าใจเซ็ตอัปของผม, “การเล่น homelab” จริง ๆ แล้วเติมเต็มอะไรบางอย่างคล้ายงานอดิเรกของ “ลุง” ยุคก่อนที่ชอบทำรางรถไฟจำลองใต้ดิน, ไม่ได้พูดในแง่ลบนะ แต่รู้สึกว่าบางคนมีสัญชาตญาณอยากมีโลกจิ๋วที่ตัวเองควบคุมได้อย่างสมบูรณ์

    • ผมก็คิดแบบนั้นเหมือนกัน เลยเขียนเอกสารเผื่อเหตุการณ์ไม่คาดฝันไว้, ส่วนที่ 1 คือเรื่องเงินกับตำแหน่งเอกสารสำคัญ, ส่วนที่ 2 คือคู่มือว่าจะทำให้บ้าน “ฉลาดน้อยลง” ได้อย่างไร, เช่น วิธีถอด smart switch แล้วกลับไปใช้สวิตช์แบบเดิม, วิธีย้ายบริการสำคัญอย่าง Bitwarden ไปไว้บน cloud, ค่าใช้จ่ายในการคงโดเมน/เมล, วิธีเปลี่ยนเราเตอร์กลับไปใช้อุปกรณ์มาตรฐานของ ISP เป็นต้น, ภรรยาผมไม่ค่อยชอบ smart home เท่าไร แต่พอบอกว่าสามารถทำให้กลับไปเป็น “บ้านธรรมดา” ได้ทุกเมื่อก็สบายใจขึ้น, เอาตรง ๆ ถ้าทั้งหมดนี้หายไปจะลำบากแค่ไหนก็ไม่รู้ แต่ก็ปลอบใจตัวเองว่าคงไม่ใช่ปัญหาของผมแล้ว

    • ผมเก็บรูปครอบครัวไว้บน home lab RAID1 แล้วทุกคืนก็ rsync ไปสำรองลง external drive บนคอมพิวเตอร์ที่บ้านของญาติ, นี่ทำทั้งเพื่อแบ็กอัปและเพื่อให้ครอบครัวเข้าถึงได้ง่ายหากเกิดอะไรขึ้น, ภรรยาผมไม่สนใจเรื่อง IT เลย แค่บอกว่า "เสียบ USB แล้วทุกอย่างอยู่ในนั้น" ก็พอ

    • ผมคิดว่าสามารถมองข้ามภัยคุกคามที่ไม่ค่อยมีประโยชน์อย่างการถูกขโมย physical disk ได้, การเก็บรูปทั้งหมดและเอกสารสำคัญโดยไม่เข้ารหัส พร้อมทิ้งคำอธิบายที่เข้าใจง่ายไว้ด้วย น่าจะเป็นทางเลือกที่ใช้งานได้จริงกว่า, ฝั่ง home automation กลับน่ากังวลกว่าอีก

    • การคิดล่วงหน้าว่าจะทำอย่างไรเมื่อผู้ดูแล homelab ไม่อยู่เป็นเวลานานหรือเกิดเหตุไม่คาดคิดนั้นสำคัญในทางปฏิบัติ, แม้ผมจะไม่ได้ออกแบบสิ่งนี้โดยตั้งใจให้มันง่ายในกรณีนั้น แต่ก็รู้สึกว่าควรคิดเรื่องนี้ให้มากขึ้น, หัวใจสำคัญคือการทิ้งข้อมูลสำคัญและ credential สำหรับเข้าถึงมันไว้, ใช้บริการอย่าง Nextcloud ให้ข้อมูลซิงก์ไปยังอุปกรณ์ของครอบครัวอัตโนมัติ และทำให้ครอบครัวหรือเพื่อนได้ลองใช้งานด้วยตัวเองก็น่าจะดี, ที่บ้านผมก็พยายามทำให้ Home Assistant กลายเป็นของใช้จำเป็นระดับเครื่องใช้ไฟฟ้าที่คู่ชีวิตใช้งานร่วมกันได้พอสมควร, และมันดูแลง่ายกว่าเมื่อมีตัวตนเป็นอุปกรณ์จริง ไม่ใช่ VM แยกต่างหาก, แน่นอนว่าทั้งหมดนี้มีความหวังปนอยู่มาก จึงสำคัญที่จะต้องวางแผนรายละเอียดร่วมกันกับคนในครอบครัวอย่างน้อยก็วงใกล้ชิด

    • ผมคิดเรื่องนี้ค่อนข้างเยอะเหมือนกัน, โดยตั้งสมมติฐานว่า NAS และบริการ Docker คงบูตขึ้นมาเองได้ไม่ดีหากไม่มีผม, ส่วนแบ็กอัปรหัสผ่านแบบ off-site ก็ดูเหมือนจะกู้คืนไม่ได้หากไม่มีผู้เชี่ยวชาญช่วย, เลยใช้ external HDD แบบ NTFS ให้ cron สร้าง incremental snapshot เป็นโฟลเดอร์ใหม่ทุกวันแทน, ใช้พื้นที่ไม่ถึง 50GB และทำสำเนาซ้ำได้ถูก, ถ้าเกิดเหตุขึ้นมาก็แค่เสียบไดรฟ์นั้นแล้วคัดลอกโฟลเดอร์ก็พอ, ผมยังมีสำเนาไลบรารี Seafile ทั้งหมดไว้บนโน้ตบุ๊กแต่ละเครื่องด้วย, ส่วนโดเมนอีเมลผมจ่ายล่วงหน้าไว้ 10 ปีและโฮสต์กับ iCloud, ตอนนี้กำลังคิดเรื่อง migadu เพราะรูปครอบครัวที่แนบเมลทำให้พื้นที่เต็มและเมลตีกลับ

  • ผมเองก็สนใจเรื่องนี้มาก และอยากเตือนว่าถ้าคุณทำธุรกิจส่วนตัว/สตาร์ตอัปสาย IT เอง ความอยากทำ homelab จะยิ่งพุ่งขึ้น, แค่รันคอนเทนเนอร์ธรรมดาจะไม่พออีกต่อไป แล้วคุณจะเริ่มยื่นเอกสารสารพัดเพื่อให้ได้ DBA และ ASN อย่างถูกกฎหมาย, มี IP block/IPV6 ของตัวเองจริง ๆ จนวิวัฒน์เป็น ISP ของตัวเอง, ปัญหา ingress (การเข้าถึงจากภายนอก) หลายคนแก้ด้วย tailscale แต่เรื่องนี้ยากจริง, ผมคิดว่าในเชิงทฤษฎี โครงสร้างแบบ STUN/TURN ที่แคช static file ทั้งหมดไว้ฝั่งเซิร์ฟเวอร์ และให้การเข้าถึงแบบ dynamic ยืนยันตัวตนที่กำแพงล็อกอินด้วย email magic link นั้นไม่ได้อันตรายหรือแพงเกินไปนัก, พอเริ่มทำ remote development environment ก็มีข้ออ้างให้ขุดลึกเรื่องพวกนี้ต่ออีก, ลิงก์อ้างอิง https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT, https://en.wikipedia.org/wiki/STUN

    • ผมทำ ingress ด้วย Fly.io, ที่ปลายทางฝั่ง remote มี nginx cache และที่ ingress pod ก็เพิ่ม Fly Wireguard peer container เข้าไป, วิธีนี้ไม่ฟรี แต่เป็นต้นทุนที่คุ้มที่สุดเพราะไม่ต้องเปิดพอร์ตใด ๆ จากบ้านโดยตรง และยังได้ anycast ingress ด้วย

  • ช่วงนี้ผมกำลังลองเล่น Immich แต่ก็ลังเลทุกครั้งว่าควรให้ใช้นอกบ้านได้ผ่าน tailscale เท่านั้น หรือจะตั้ง reverse proxy บน VPS ด้วย, สิ่งที่กังวลที่สุดคือการหาวิธี monitoring/security ที่เป็นมิตรกับผู้ใช้และช่วยตรวจจับได้ว่ามีใครพยายามโจมตีผ่าน VPS อยู่หรือไม่

    • ผมก็คิดเหมือนกัน, ถ้าคุณหาข้อมูลเรื่องโซลูชัน security/monitoring ได้เมื่อไร รบกวนมาแชร์ด้วย

  • เซ็ตอัปของผมง่ายกว่ามาก

    • เครื่องเดียว
    • nginx proxy
    • หลายบริการบนเครื่องเดียวกัน; บางอันใช้ภายใน บางอันเปิดภายนอก แต่ทั้งหมดเข้าผ่านเว็บ
    • บริการภายในใช้รหัสผ่าน HTTP basic auth ที่ยาวมาก (ตัวจัดการรหัสผ่านใน Firefox)
    • บริการภายนอกเป็นแบบสาธารณะหรือใช้ Google OAuth
    • ทุกอย่างเขียนโค้ดเองตั้งแต่ต้น และนั่นแหละคือจุดประสงค์ของ homelab
    • จะเป็นรูปหรือวิดีโอ เบราว์เซอร์ก็จัดการอ่านได้ดีเอง
    • ส่วนที่ยากคือ backend เสมอ ส่วน frontend แทบจะให้กลิ่นอาย HTML ยุค 90

    • HTTP ส่งรหัสผ่านเป็น plain text ดังนั้นอย่างน้อยก็ควรใช้ self-signed certificate เพื่อความปลอดภัย

    • การทำ infra หรือบริการเป็นโค้ดเองก็เป็นวิธีเรียนรู้ที่ยอดเยี่ยมจริง ๆ, และยังเท่มากตรงที่ตอบโจทย์ความต้องการเฉพาะของตัวเองได้เป๊ะ

  • ผมอยากลองทำ homelab แบบนี้เหมือนกัน แต่ไม่มีเวลา, สุดสัปดาห์อาจพอติดตั้งได้ แต่ไม่มีเวลาว่างพอสำหรับดูแล/อัปเดตอย่างต่อเนื่อง, เลยโยนให้ cloud provider ดูแลแล้วตัดปัญหา, ถ้ามีใครที่ใช้แต่ cloud แบบผมก็อยากรู้ว่าเข้าหากันอย่างไร

    • ตอนใช้เซ็ตอัปแบบเก่า ผมก็เครียดเพราะบำรุงรักษาไม่ไหว, เลยเริ่มชอบ NixOS กับ ZFS เพราะทั้งคู่ rollback ง่ายมาก, อัปเดตแล้วมีปัญหาก็ย้อนกลับเวอร์ชันก่อนหน้าได้ทันที แล้วค่อยดีบักตอนมีเวลา, แต่ถ้าคุณพอใจกับตัวเลือก cloud ก็ถือว่าโอเคแล้ว, การตั้งเองใช้เวลาแน่นอน ดังนั้นแต่ละคนต้องชั่งน้ำหนักต้นทุนกับคุณค่าที่ได้เอง

    • ผมรันบริการ self-host ประมาณ 12 ตัว และโดยปกติการอัปเกรดใช้เวลาไม่ถึง 1 นาทีต่อเดือน, แต่ละบริการมีโฟลเดอร์ของตัวเอง ข้างในมี docker-compose stack กับ data folder, เวลาอัปเดตก็แค่ docker compose pull แล้ว up -d ก็จบ, นาน ๆ ทีอาจมีอัปเกรดที่ต้องแก้ config แต่ส่วนใหญ่ก็เสร็จในไม่กี่นาที, ไม่มี VM ด้วย, ผมคิดว่า self-host ที่ทำอัตโนมัติทั้งหมดด้วย Docker Compose อย่างเดียวคือวิธีที่ง่ายที่สุด

    • เรื่องนี้ไม่ได้จบแค่วันหยุดวันเดียวจริง ๆ, สำหรับผมมันเริ่มจากลองติดตั้ง Plex ครั้งเดียว แต่หนึ่งปีต่อมากลายเป็นโครงสร้างซับซ้อนที่มีทั้ง Proxmox และระบบ home automation สารพัด, พูดเล่นปนจริง ถ้าจะเริ่มแบบขั้นต่ำก็ควรเริ่มด้วย docker compose เพราะดูแลง่ายและอัปเกรดก็ไม่ซับซ้อน

  • ผมสงสัยว่าจำเป็นต้องใช้ SSO ถึงขนาดนั้นไหม, ถ้าครอบครัวหรือเพื่อนใช้ไคลเอนต์ wireguard (บน iOS ก็ง่ายมาก) ก็แค่สลับปุ่มครั้งเดียวแล้วเข้าเครือข่ายบ้านได้เลย, จากนั้นก็ใช้บริการภายในทั้งหมดได้โดยไม่ต้องมี SSO แยก, สำหรับเครือข่ายบ้านขนาดเล็ก ข้อดีมีมากกว่าข้อเสียเยอะ

    • บริการอย่าง Nextcloud หรือ Mealie ที่เราใช้ มีบัญชีแยกตามผู้ใช้เป็นพื้นฐานอยู่แล้ว, SSO ทำให้ทุกบริการเข้าถึงได้ด้วยบัญชีเดียว และผมไม่ต้องคอยจัดการรหัสผ่านด้วย, ถึงการตั้งค่าจะซับซ้อนขึ้นนิดหน่อย แต่ตอนใช้งานจริงกลับง่ายกว่า ทำให้โอกาสที่ครอบครัวจะใช้งานจริงสูงขึ้น

    • ตอนนี้ผม self-host แอปอยู่ 20 ตัว และเหนื่อยมากกับการต้องจัดการ authentication แยกกันแต่ละตัว เลยกำลังจะทำ SSO, โดยเฉพาะถ้าจะเปิดบางแอปให้ครอบครัวใช้ สิ่งสำคัญอันดับแรกคือการรวมเรื่อง auth ไปจัดการที่จุดเดียว, ผมจึงไม่ค่อยเห็นด้วยกับวิธีที่พูดไว้ข้างบน

  • ผมสงสัยว่าทำไมต้องใช้ flame โดยเฉพาะ, มันเหมือนดึง dependency ฝั่ง third-party เป็นสิบเป็นร้อยตัวอย่าง node, react, redux เข้ามาใน “อาณาจักรแห่งความปลอดภัย” ทั้งที่หน้าเริ่มต้นจริง ๆ แค่มีไฟล์ HTML ธรรมดาหนึ่งหน้าพร้อมลิงก์ก็น่าจะพอแล้วไม่ใช่หรือ

    • ผมใช้ flame มาตลอดเลยคุ้นมือ และมันช่วยแก้ปัญหาได้ทันทีจึงเลือกมัน, ผมก็ชอบดีไซน์ด้วย, พอวางไว้หลัง Tailscale กับ Authelia แล้วก็ไม่ได้กังวลเรื่องความปลอดภัยเป็นพิเศษ, แต่ตั้งใจว่าจะดูทางเลือกอื่นในภายหลัง

  • ผมอยากลอง self-host บน NixOS เหมือนกัน แต่ยังไม่เคยลงมือจริง, สภาพแวดล้อมของผมตอนนี้จัดการด้วย VM ไม่กี่ตัวและไฟล์ docker compose ตัวเดียวต่อ VM, ใช้ ansible playbook แค่คัดลอกไฟล์ compose และใช้ Fedora Server แบบตามหลังรุ่นล่าสุด 1 เวอร์ชันแล้วค่อยอัปเกรดตอนหมดซัพพอร์ต, บน Mac ผมก็ใช้ nix-darwin อยู่ เลยเข้าใจข้อดีของการตั้งค่าแบบ Nix แต่ยังไม่รู้สึกว่าคุ้มพอจะย้ายสภาพแวดล้อมจริงทั้งหมดไป Nix ในแง่ประสิทธิภาพหรือผลตอบแทนต่อเวลา, ถ้า LLM (AI ขนาดใหญ่) ช่วยเขียน config ตามคำบอกได้ก็คงอีกเรื่อง แต่ตอนนี้ยังไม่มีแรงจูงใจพอ

    • ผมก็ลอง NixOS แล้วภายในหนึ่งสัปดาห์ก็ย้ายทั้งเครือข่ายบ้านและเซิร์ฟเวอร์จริงสองเครื่องไปหมด, ผ่านมา 3-4 เดือนแล้วและพอใจเกินคาด, การย้ายเซิร์ฟเวอร์ง่ายกว่าย้าย workstation เสียอีก, ช่วงนี้ยังตั้ง NixOS บน Jetson Orin Nano ที่เอามาเล่นด้วย, ถ้าเป็นสมัย Gentoo ผมคงไม่กล้าทำแบบนี้เลย, สิ่งที่น่ารำคาญที่สุดของ Gentoo คือเวลาคอมไพล์ที่ยาวจนน่ากลัวบนเครื่องเก่า ๆ เช่นเคยใช้เวลา build GHC บน XPS ปี 2019 ถึง 6 ชั่วโมง

    • สำหรับผม ความต่างที่ใหญ่ที่สุดของ NixOS คือเวลามีอะไรพัง rollback ง่ายมาก, ระบบแบบ ansible หรือ compose ก็แบ็กอัป/กู้คืนได้เหมือนกัน แต่คุณต้องลงแรงเขียนระบบนั้นเอง, ถึงอย่างนั้น ถ้าคุณพอใจกับระบบปัจจุบันอยู่แล้ว ผมก็คิดว่านั่นเป็นเรื่องที่ดี

    • ถ้าคุณใช้ IaC อยู่พอสมควรแล้ว ก็อาจไม่ได้รู้สึกว่า NixOS เพิ่มประสิทธิภาพให้อีกมากนัก