Homelab ของผมไม่ต้องบำรุงรักษา

 (cleberg.net)
1 คะแนน โดย GN⁺ 6 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เพื่อลดภาระในการดูแล Homelab ส่วนตัว จึงมุ่งเน้นไปที่ การจัดโครงสร้างแบบเซิร์ฟเวอร์เดียว และการอัปเดตอัตโนมัติ ทำให้แทบไม่เหลืองานประจำวันที่ต้องเข้าไปจัดการเอง
  • เมื่อรวมเซิร์ฟเวอร์หลายเครื่องให้เหลือเครื่องเดียว ความซับซ้อนของสภาพแวดล้อมลดลง และภาระบำรุงรักษาเมื่อวัดจากจำนวนเซิร์ฟเวอร์ก็ลดลง 75%
  • Raspberry Pi 4 ใช้ Home Assistant OS ส่วนเครือข่ายปล่อยให้ UniFi จัดการอัปเดตอัตโนมัติและอัปเดตตามกำหนดเวลา ทำให้จุดที่ต้องดูแลด้วยมือมีน้อยลง
  • บริการ Docker อัปเดตด้วย crontab ที่รัน docker compose pull และ docker compose up -d สัปดาห์ละครั้ง ส่วน root crontab ใช้สำหรับแบ็กอัปเป็นหลัก
  • หากไม่มีเหตุฉุกเฉิน การบำรุงรักษารายเดือนใช้เวลาประมาณ 15 นาที และแม้จะเลื่อน apt update กับการรีสตาร์ตออกไป ก็แทบไม่กระทบต่อบริการในทันที

โครงสร้างอินฟราที่ทำให้เรียบง่าย

  • บริการ Homelab ถูกรวมจากหลายอุปกรณ์มาเป็น เซิร์ฟเวอร์เดียว
    • เดิมใช้เซิร์ฟเวอร์ 4 เครื่อง แต่ปัจจุบันรวมบริการไว้บนเซิร์ฟเวอร์กายภาพเครื่องเดียว
    • แทนที่จะใช้คลัสเตอร์ ไฮเปอร์ไวเซอร์ หรือไฮบริดคลาวด์ ก็รันบนเครื่องกายภาพหนึ่งเครื่องในชั้นใต้ดิน
    • การทำให้เรียบง่ายนี้ลดปริมาณงานบำรุงรักษาตามจำนวนเซิร์ฟเวอร์ลง 75%
  • ยังมี Raspberry Pi 4 แยกต่างหาก แต่ Home Assistant OS จัดการอัปเดตเอง ทำให้ภาระดูแลน้อย
    • ในเชิงเทคนิคมันใกล้เคียงกับเซิร์ฟเวอร์ แต่ประสบการณ์ใช้งานจริงใกล้เคียงกับอุปกรณ์ IoT ที่ดูแลตัวเอง
  • อุปกรณ์เครือข่ายทำงานด้วยชุด UniFi ในมินิแร็ก
    • ประกอบด้วย UniFi Dream Machine Pro, สวิตช์ และ AP หลายตัว
    • รองรับการอัปเดตอัตโนมัติและอัปเดตตามกำหนดเวลา จึงไม่จำเป็นต้องเข้าไปจัดการอุปกรณ์เครือข่ายด้วยมือบ่อย ๆ

การอัปเดตซอฟต์แวร์และการแบ็กอัปแบบอัตโนมัติ

  • การอัปเดตบริการ Docker รันทุกสัปดาห์ผ่านรายการ crontab เดียวบนเซิร์ฟเวอร์
    • 0 0 * * 0 docker-update
    • docker-update รัน sudo docker compose pull และ sudo docker compose up -d ในแต่ละไดเรกทอรีใต้ ~/docker/*/
  • crontab ของผู้ใช้ root ส่วนใหญ่ใช้เพื่อ แบ็กอัป
    • สร้างรายงานระบบทุกวัน
    • สร้าง dump ของ PostgreSQL สำหรับ Immich และ Piped
    • แบ็กอัป Plex, เว็บเซิร์ฟเวอร์, คอนฟิก Nginx, ไดเรกทอรี Docker และไฟล์ SSH ไปยัง ZFS pool ด้วย rsync
    • ในการแบ็กอัปไดเรกทอรี Docker จะยกเว้นฐานข้อมูล แคช ไฟล์ชั่วคราว และพาธของล็อกบางส่วน
  • งานที่ยังต้องทำด้วยมือเหลือเพียงรัน apt update, apt upgrade, apt autoremove และรีสตาร์ตเมื่อจำเป็น
    • งานนี้ใช้เวลาประมาณ 60 วินาที
  • หากไม่มีเหตุฉุกเฉิน เวลาในการบำรุงรักษาอยู่ที่ประมาณ 15 นาที ต่อเดือน
    • แม้จะไม่ SSH เข้าไปอัปเดตตลอดหนึ่งเดือน ก็ไม่กระทบต่อบริการจริง
    • มีความเป็นไปได้ว่าจะไม่เสียแม้ปล่อยทิ้งไว้นานกว่า 6 เดือน แต่ไม่มีแผนจะตั้งใจทดสอบ
  • โครงสร้างปัจจุบันมอบสมดุลระหว่าง ความเป็นส่วนตัว ความปลอดภัย และความสะดวก แม้จะมีตารางงานที่ยุ่ง

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

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

 
GN⁺ 6 시간 전
ความคิดเห็นจาก Lobste.rs

  • ผมก็รันโฮมเซิร์ฟเวอร์คล้าย ๆ กัน
    เปิดใช้งานการอัปเกรดความปลอดภัยอัตโนมัติบน Debian และรันทุกอย่างใน rootless container ที่ตรึงเวอร์ชันไว้ โดยให้ systemd จัดการผ่าน Podman Quadlet
    auto-update ของ Podman จัดการอัปเดตคอนเทนเนอร์ และ systemd timer รับหน้าที่งานประจำอย่างแบ็กอัปและล้างอิมเมจ
    จะล็อกอินไปรีบูตเฉพาะตอนมีการอัปเกรดเคอร์เนลหรือเพิ่มเวอร์ชันอิมเมจเท่านั้น ซึ่งงานนี้ Ansible เป็นคนจัดการ

    • ตรงที่ใช้คำว่า “ตรึงเวอร์ชัน” กับ “Podman auto-update” ด้วยกันทำให้งงนิดหน่อย
      ผมเข้าใจว่าการตรึงเวอร์ชันหมายถึงจะไม่ดึงอัปเดตมาแบบอัตโนมัติ แต่ดูเหมือนในทางปฏิบัติก็ยังมีการอัปเดตอยู่ เลยไม่แน่ใจว่าเป็นการอัปเดตคนละส่วนกันหรือเปล่า
    • ผมใช้ชุดคอนฟิกแทบจะเหมือนกันนี้มา เกิน 10 ปี แล้ว และจะอัปเป็น stable รุ่นล่าสุดทุกสองปี
      อุปกรณ์ที่ต้องดูแลแยกต่างหากมีแค่เราเตอร์ตัวเดียว ซึ่งเป็น OpenBSD เลยอัปเกรดทุกประมาณ 6 เดือนตอนมีเวอร์ชันใหม่ออก
      ทั้งสองอย่างเสถียรจนแทบน่าเบื่อ

  • คล้ายกัน แต่ผมจะไม่อัปเดตอะไรเลยจนกว่าจะมีฟีเจอร์ที่อยากได้
    ข้อดีของ ซอฟต์แวร์ self-hosted คือเราสามารถอัปเดตตามตารางของเราเองได้
    ถ้าทุกอย่างยังทำงานดี เข้าถึงได้ผ่าน Tailscale เท่านั้น และไม่ได้เปิดออกสู่อินเทอร์เน็ตโดยตรง ก็แทบจะปล่อยทิ้งไว้ได้อย่างเสถียร ยกเว้นกรณีฮาร์ดแวร์เสีย

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

  • ถ้าไปถึงจุดนั้นได้ก็ถือว่าดีมากแล้ว
    ผมเองก็กำลังพยายามไปให้ถึง แต่ยังไม่สุด
    การอัปเกรด Debian แบบ major ทุก 2 ปียังต้องทำมืออยู่ดี: "Issues to be aware of for trixie", "Obsolescence and deprecation", "Cleanup after the upgrade"
    Ansible เวอร์ชันเก่าจัดการระบบ Debian รุ่นใหม่ไม่ได้ ดังนั้นพออัป Debian server ก็ต้องอัปเวอร์ชัน Ansible ด้วย และสุดท้ายก็ต้องแก้ playbook ให้เข้ากับ Ansible รุ่นใหม่
    ตอนนี้ผมพยายามลดปัญหานี้ด้วยการ ใช้ Docker containers ให้มากขึ้น แต่ก็คงแทน Ansible ได้ไม่หมด
    ยังมีบริการออนไลน์ที่ไม่อยากโฮสต์เองอย่าง freeDNS, dynv6.net และบริการพวกนี้ก็มีการเปลี่ยนแปลงที่ทำของพังเป็นครั้งคราวเหมือนกัน
    ถึงอย่างนั้นโดยรวมก็ยังถือว่าค่อนข้างดี
    ถ้าพูดกันตรง ๆ การดูแลโฮมแล็บแบบ “แทบไม่ต้องบำรุงรักษา” ก็คือการฝากงานไว้กับเหล่า นักพัฒนาโอเพนซอร์ส ทั่วโลกที่ดูแลซอฟต์แวร์ แพ็กเกจ และ Docker image ที่เราใช้อยู่นั่นเอง

  • ผมยังลังเลที่จะเรียกชุดคอนฟิกของตัวเองว่า “โฮมแล็บ” แต่มันคือ unRAID NAS ที่รัน Docker containers หลายตัว
    เหตุผลหนึ่งที่ผมยอมจ่ายเงินให้ unRAID แล้วรู้สึกคุ้มก็คือมันรองรับ Docker ได้ดีพอสมควร มีปลั๊กอินสำหรับอัปเดตคอนเทนเนอร์อัตโนมัติ และงานบำรุงรักษาอื่น ๆ ก็เรียบง่ายพอใช้

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

  • สำหรับการดูแลโฮมแล็บของผม pyinfra ให้ความขี้เกียจในระดับที่กำลังพอดี
    เราสามารถเขียนขั้นตอนการตั้งค่าไว้เป็นโค้ดได้ ซึ่งมีประโยชน์มากโดยเฉพาะกับพวกไฟล์คอนฟิก และถ้าจำเป็นก็เรียก apt ได้เลยโดยไม่ต้องมานั่งคิดว่า nix จะจัดการเรื่องนี้อย่างไร
    มันอาจไม่ใช่เครื่องมือที่ฉลาดมาก แต่ก็ดีกว่าสคริปต์เชลล์ไฟล์เดียว และผมก็อยากพัฒนาต่อไปอีกในอนาคต
    ถ้าใช้ agentic coding ก็มีโบนัสตรงที่สามารถให้ Claude ดู ไฟล์ pyinfra แล้วช่วยดีบักคอนฟิกได้

  • ผมใช้ NixOS บนเซิร์ฟเวอร์ และจะอัปเดตเป็นครั้งคราวเวลานึกขึ้นได้
    ส่วนใหญ่ก็จบแค่ nix flake update && nix run .#deploy เลยไม่ได้ต้องใส่ใจมาก

  • ผมก็อยู่ในสถานการณ์คล้ายกันมาก และถึงจะไม่อยากยอมรับ แต่ส่วนใหญ่ก็คงเป็นเพราะคอนฟิกมันเรียบง่ายขึ้นจริง ๆ
    เมื่อก่อนผมชอบ observability stack เต็มชุดพร้อม log rotation แต่ปัญหาปวดหัวทั้งหมดในช่วงกว่า 2 ปีที่ผ่านมา ล้วนเป็นปัญหาเล็ก ๆ ที่เกิดจากความซับซ้อนนั้นเอง
    เช่น ดิสก์เต็มเพราะล็อกกับเมตริก
    แก้ไม่ยากหรอก แต่ตอนนี้ผมไม่อยากต้องมารับมือกับของพวกนั้นอีกแล้ว

  • สำหรับการทำให้คอนฟิก docker-compose ทันสมัยอยู่เสมอ ผมชอบ Watchtower
    https://hub.docker.com/r/nickfedor/watchtower
    มันมีตัวเลือกการตั้งค่าที่ดีพอสมควรสำหรับการค่อย ๆ อัปเวอร์ชันโดยยังพอคำนึงถึงการเปลี่ยนแปลงใหญ่ได้
    ระบบปฏิบัติการพื้นฐานผมใช้ Debian LTS แล้วเปิดแค่อัปเดตอัตโนมัติไว้ จากนั้นค่อยล็อกอินไปรีบูตตอนมีเคอร์เนลใหม่
    งานจริง ๆ มีไม่มาก และผมก็เห็นด้วยกับคำว่าต่ำกว่า 15 นาทีต่อเดือน