Lightwhale 3: ทำให้เซิร์ฟเวอร์ Linux กลับมาสนุกอีกครั้ง

 (lightwhale.asklandd.dk)
4 คะแนน โดย GN⁺ 3 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นระบบปฏิบัติการเซิร์ฟเวอร์ Linux ที่ออกแบบมา สำหรับคอนเทนเนอร์ Docker โดยเฉพาะ เพียงบูตจาก ISO ก็จะเข้าสู่ สภาพแวดล้อม Docker Engine ได้ทันที
  • วางระบบแกนกลางให้เป็นโครงสร้างแบบ immutable และ stateless แล้วแยก /etc, /var, /home และข้อมูล Docker ไปไว้ในพื้นที่เขียนแยกต่างหาก ช่วยลดภาระในการติดตั้งและตั้งค่าเริ่มต้นได้มาก
  • ไฟล์ซิสเต็มข้อมูลเริ่มต้นเป็น พื้นที่เก็บข้อมูลชั่วคราวแบบ tmpfs และเมื่อเปิดใช้ persistence ระบบจะตรวจหาอุปกรณ์จัดเก็บแยกโดยอัตโนมัติ แล้วทำการแบ่งพาร์ทิชัน ฟอร์แมต และเมานต์ให้ พร้อมตั้งค่าเป็น Btrfs RAID1 ได้หากต้องการ
  • ใช้ root แบบอ่านอย่างเดียวบนพื้นฐาน squashfs และมีองค์ประกอบน้อยที่สุด เพื่อลดพื้นที่เสี่ยงจากมัลแวร์หรือการแก้ไขที่ไม่ตั้งใจ รวมถึงช่วยลดการใช้ทรัพยากรและการใช้พลังงาน
  • รองรับเฉพาะ x86-64 ทำงานได้ทั้งบน bare metal และเครื่องเสมือน ช่วยให้โฟกัสกับการรันคอนเทนเนอร์และการทำ self-hosting ได้ทันที มากกว่าการจัดการเซิร์ฟเวอร์เอง

ภาพรวม

  • เป็นระบบปฏิบัติการเซิร์ฟเวอร์ Linux ที่ออกแบบมา สำหรับคอนเทนเนอร์ Docker โดยเฉพาะ และเมื่อบูตแบบ live จาก ISO ก็จะเข้าสู่สภาพแวดล้อม Docker Engine ได้ทันที
  • เพื่อลด ภาระในการติดตั้งและตั้งค่าเริ่มต้น จึงทำให้ระบบแกนกลางเป็นแบบ immutable และแยกข้อมูลกับการปรับแต่งของผู้ใช้ไปไว้ในพื้นที่จัดเก็บต่างหาก
  • มุ่งเป้าไปที่ homelab, bare metal, สภาพแวดล้อมเสมือน, edge node และคลัสเตอร์ แต่สถาปัตยกรรมที่รองรับจำกัดอยู่ที่ x86-64
  • ให้ความสำคัญกับองค์ประกอบขั้นต่ำและความใช้งานง่าย ทำให้ผู้ใช้โฟกัสกับการรันและดูแลคอนเทนเนอร์ได้มากกว่าการบริหารเซิร์ฟเวอร์

คุณสมบัติหลัก

  • เป็นแบบ plug and play แค่ดาวน์โหลด ISO แล้วบูตก็พร้อมใช้งาน Docker Engine ที่มีเครื่องมือที่จำเป็นรวมมาให้ทันที
  • ลดจำนวนองค์ประกอบให้เหลือน้อยที่สุด เพื่อลดภาระในการเรียนรู้และช่วยให้เข้าใจการทำงานของระบบได้รวดเร็ว
  • ใช้ แกนกลางแบบ immutable และ stateless เพื่อลดพื้นที่เสี่ยงต่อมัลแวร์และการแก้ไขที่ไม่ตั้งใจ และบูตขึ้นมาในสถานะเดิมทุกครั้ง
  • มี persistence แบบเลือกเปิดได้ โดยไฟล์ซิสเต็มข้อมูลเริ่มต้นคือ tmpfs แบบชั่วคราวใน RAM และเมื่อเปิด persistence ระบบจะตรวจหาอุปกรณ์จัดเก็บแยกโดยอัตโนมัติ แล้วแบ่งพาร์ทิชัน ฟอร์แมต และเมานต์ให้
  • ลดโปรเซสที่ไม่จำเป็นเพื่อให้ ใช้ทรัพยากรและพลังงานน้อยลง และช่วยยืดอายุการใช้งานอุปกรณ์เก่าหรือสเปกต่ำ
  • ทำให้ self-hosting ใช้งานได้ง่ายขึ้น เพื่อหลุดจากการพึ่งพา Big Tech และดูแลข้อมูลกับความเป็นส่วนตัวได้ด้วยตนเอง

วิธีเริ่มต้น

  • ดาวน์โหลดอิมเมจจาก ISO ล่าสุด หรือจาก ส่วนดาวน์โหลด แล้วเขียนลง USB จากนั้นบูตได้เลย
  • ในบางระบบ อาจต้องปิดใช้งาน safe boot ใน BIOS ก่อนบูต
  • บัญชีเริ่มต้นคือชื่อผู้ใช้ op รหัสผ่าน opsecret และอย่างน้อยควร เปลี่ยนรหัสผ่าน ก่อนนำเครื่องออกสู่อินเทอร์เน็ต
  • สามารถตั้งค่า Wi‑Fi เพิ่มเติมได้ด้วย setup-wifi
  • การรันคอนเทนเนอร์ทำได้เหมือนการใช้ Docker ทั่วไป โดยมีตัวอย่างเป็น docker run -it --rm busybox ps
  • เวลาจะเปิดใช้ persistence ต้องเขียน magic header ลงบน block device ไม่ใช่พาร์ทิชัน และกระบวนการนี้จะลบข้อมูลเดิม

โครงสร้างการบูตและการทำงาน

  • ISO สามารถบูตได้ทั้งบน bare metal และเครื่องเสมือน และรองรับทั้ง UEFI กับ BIOS แบบดั้งเดิม
  • กระบวนการเริ่มระบบใช้ init system ที่คล้าย sysv เพื่อคงลำดับการบูตที่เรียบง่ายและโปร่งใส
  • บูตโหลดเดอร์จะโหลด Linux kernel และ root filesystem ขึ้นสู่หน่วยความจำ จากนั้น kernel จะเริ่มต้นฮาร์ดแวร์และส่งการควบคุมต่อให้ /init
  • init จะอ่าน /etc/inittab เมานต์ tmpfs สำหรับ /tmp, /run แล้วเรียกใช้สคริปต์ใน /etc/init.d
  • ในช่วงต้น ระบบจะเมานต์ data filesystem เพื่อเก็บข้อมูล Docker และเป็น upper layer ของ overlay สำหรับ /etc, /var, /home
  • เมื่อไฟล์ซิสเต็มทั้งหมดและ overlay พร้อมแล้ว บริการที่เหลือจึงจะเริ่มทำงาน และนับจากจุดนั้นก็สามารถให้บริการคอนเทนเนอร์ได้

การออกแบบด้านความเป็น immutable

  • root filesystem ถูกจัดมาเป็น อิมเมจ squashfs แบบคงที่ ซึ่งเป็นโครงสร้างที่แก้ไขเองไม่ได้
  • ด้วยโครงสร้างนี้ ซอฟต์แวร์และการตั้งค่าที่จำเป็นจึงรวมมาให้ล่วงหน้า กลายเป็น อิมเมจแบบพึ่งพาตัวเองได้ ที่บูตใช้งานได้โดยไม่ต้องผ่านขั้นตอนติดตั้ง
  • ช่วยหลีกเลี่ยงตัวจัดการแพ็กเกจ การจัดการ dependency และการต้องแข่งขันกับการอัปเดตในระบบเดิม โดยแทนงาน ติดตั้งสิ่งที่ทำงานอยู่แล้วซ้ำอีกครั้ง ด้วย การรีบูตเพียงครั้งเดียว
  • ไฟล์ใน root filesystem จะไม่ถูกลบโดยไม่ตั้งใจหรือถูกไวรัสแก้ไข และไม่เปิดให้ kernel กับไบนารีพื้นฐานทั้งหมดอยู่ในสถานะที่แก้ไขได้เหมือนระบบดั้งเดิม
  • ด้วยโครงสร้าง root แบบอ่านอย่างเดียว จึงป้องกัน การสะสมของไฟล์จุกจิก ที่มักเกิดขึ้นระหว่างการใช้งานระยะยาว ซึ่งส่งผลเสียต่อการสำรองข้อมูล ประสิทธิภาพ และความเรียบร้อยของระบบ
  • สามารถทดลองได้อย่างอิสระบน VM ภายในเครื่องหรือคอมพิวเตอร์เครื่องอื่น และย้อนการเปลี่ยนแปลงได้ด้วยการรีบูต
  • สื่อสำหรับบูตไม่มีข้อมูลสำคัญและยังคงสภาพนั้นไว้ด้วยความเป็น immutable ดังนั้นแม้อุปกรณ์จะเสียหายหรือสูญหาย ก็สามารถกู้คืนได้จากสำเนาใหม่

โครงสร้าง persistence

  • การติดตั้งและรันคอนเทนเนอร์ การเปลี่ยนการตั้งค่า และการเขียนข้อมูล ต้องใช้ ไฟล์ซิสเต็มที่เขียนได้ และหากต้องการให้คงอยู่หลังรีบูตก็ต้องใช้ persistence
  • มีซับซิสเต็มที่ทำงานอัตโนมัติในช่วงเริ่มบูตเพื่อเมานต์ data filesystem ไว้ที่ /mnt/lightwhale-data
  • ข้อมูลที่ Lightwhale เขียนจะถูกรวมไว้ใต้ /mnt/lightwhale-data/lightwhale-state และไดเรกทอรีนี้จะเป็น upper layer ที่เขียนได้ของ overlayfs
  • ค่าเริ่มต้นคือ tmpfs แบบชั่วคราว และเมื่อเปิด persistence แล้ว data filesystem จะถูกย้ายไปอยู่บน อุปกรณ์จัดเก็บแยกต่างหาก
  • แทนที่จะ overlay ทั้ง root ระบบจะเลือกทำเฉพาะ /etc, /var, /home เพื่อคงเป้าหมายของความเป็น immutable
    • /etc ใช้สำหรับปรับแต่งการตั้งค่าระบบ เช่น เครือข่าย รหัสผ่าน และ sshd
    • /var ใช้สำหรับล็อกและข้อมูลแอปพลิเคชันอื่น ๆ
    • /home ใช้สำหรับการปรับแต่งของผู้ใช้ เช่น SSH authorized keys, การ clone Git repository และการจัดการ Docker/Swarm stack
  • data root ของ Docker อยู่ที่ /mnt/lightwhale-data/lightwhale-state/docker โดยตรง และเก็บสถานะของอิมเมจ คอนเทนเนอร์ วอลุ่ม และเครือข่าย

การเปิดใช้ persistence และลำดับการทำงานอัตโนมัติ

  • การเปิดใช้ persistence ต้องทำอย่างชัดเจนโดยเขียน magic header ลงในอุปกรณ์จัดเก็บ เช่น echo "lightwhale-please-format-me" | sudo dd conv=notrunc of=/dev/sdx
  • สามารถเขียน magic header ลงบนอุปกรณ์จัดเก็บหลายตัวได้ และในกรณีนั้นจะถูกรวมเป็นโวลุม Btrfs RAID1
  • ในการบูตครั้งถัดไป ระบบจะตรวจพบ magic disk แล้วฟอร์แมตเพื่อใช้เป็น data filesystem
  • persistence subsystem จะเริ่มจาก /etc/init.d/S11persistence

  • การตรวจหา data filesystem

    • ตรวจทุกดิสก์เพื่อหาพาร์ทิชันที่มีป้ายกำกับไฟล์ซิสเต็มเป็น lightwhale-data
    • หากพบ จะใช้พาร์ทิชันนั้นเป็น data filesystem และข้ามไปขั้นตอนเมานต์ต่อจากนั้น

  • การตรวจหา magic disk และการสร้างพาร์ทิชัน

    • ใช้การค้นหาลำดับไบต์ lightwhale-please-format-me ที่จุดเริ่มต้นของดิสก์เพื่อระบุ magic disk
    • สำหรับแต่ละ magic disk จะสร้างพาร์ทิชัน swap ที่มีป้ายกำกับ lightwhale-swap และพาร์ทิชัน Linux ที่มีป้ายกำกับ lightwhale-data ซึ่งใช้พื้นที่ที่เหลือทั้งหมด

  • การสร้างไฟล์ซิสเต็ม

    • พาร์ทิชัน swap ของ magic จะถูกฟอร์แมตและติดป้ายกำกับ lightwhale-swap
    • หากมี magic data partition เพียงตัวเดียว จะฟอร์แมตด้วย btrfs --data single --metadata dup
    • หากมีหลายตัว จะรวมเป็น RAID1 และฟอร์แมตด้วย btrfs --data raid1 --metadata raid1cn
    • จะสร้าง subvolume @lightwhale-data, @lightwhale-state, @lightwhale-state-snapshots

  • การเมานต์และการตั้งค่า overlay

    • หากมี data filesystem จะเมานต์ @lightwhale-data ไปที่ /mnt/lightwhale-data และหากไม่มีจะเมานต์ tmpfs แทน
    • lower layer แบบ immutable จะ bind mount /etc ไปที่ /run/lightwhale/overlay/lower/etc และเตรียมโครงสร้างไดเรกทอรีของ root filesystem แบบสะท้อนไว้
    • upper layer ที่เขียนได้จะถูกเตรียมไว้ในพาธอย่าง /mnt/lightwhale-data/lightwhale-state/overlay/upper/etc
    • จากนั้นจะรวมสองเลเยอร์ด้วย overlayfs แล้วเมานต์ที่ /etc และทำแบบเดียวกันซ้ำกับ /var, /home

ข้อจำกัดและสาระสำคัญจาก FAQ

  • ฮาร์ดแวร์ที่รองรับคือ x86-64 เท่านั้น และรองรับทั้ง BIOS กับ EFI
  • ขณะนี้ยังไม่รองรับ Raspberry Pi และอยู่ใน backlog
  • Apple M-series ไม่รองรับแบบ bare metal แต่สามารถ รันแบบ virtualization ได้
  • สามารถทำงานในสภาพแวดล้อมเสมือนอย่าง VMWare/ESX/Proxmox/cloud ได้ และมี guest agent สำหรับ QEMU/KVM กับ VMware ESXi รวมมาให้
  • ซอฟต์แวร์ที่ติดตั้งได้มีเพียง Docker container เท่านั้น ไม่สามารถติดตั้งลงบน root filesystem โดยตรงได้
  • แม้ระบบแกนกลางจะเป็น immutable แต่การตั้งค่า การปรับแต่ง และข้อมูลคอนเทนเนอร์ จะถูกเขียนลงหน่วยความจำเป็นค่าเริ่มต้น และจะคงอยู่หลังรีบูตเมื่อเปิด persistence เท่านั้น
  • ชื่อโฮสต์เริ่มต้นจะมี machine ID รวมอยู่ด้วยเพื่อป้องกันปัญหาชนกันบนเครือข่าย และหากเปลี่ยนด้วย setup-hostname จะมีผลทันที ยกเว้นเชลล์ปัจจุบัน
  • ไม่มีการรับประกันใด ๆ และผู้ใช้ต้องรับผิดชอบผลจากการใช้งานเอง
  • โครงการนี้ไม่ได้มุ่งไปในทิศทางของการเพิ่มเครื่องมือโปรดอย่าง wget, nano ลงใน root filesystem และยังคงข้อจำกัดแบบ ระบบปฏิบัติการเซิร์ฟเวอร์ขั้นต่ำที่เฉพาะทางตามวัตถุประสงค์
  • ในส่วน TL;DR ของนโยบายความเป็นส่วนตัว ระบุว่าไม่มีการเก็บข้อมูลส่วนบุคคล และจะเก็บ ข้อมูลแบบไม่ระบุตัวตน เฉพาะเมื่อผู้ใช้ยินยอมให้เก็บ telemetry เท่านั้น โดยสามารถตรวจสอบเนื้อหาที่เก็บได้
  • การปฏิบัติตามข้อกำหนดด้านอายุไม่ใช่ความรับผิดชอบของตัว OS เอง แต่เป็นความรับผิดชอบของ บริการของผู้ใช้ ที่นำไปเผยแพร่บนระบบ

ลิงก์ที่เกี่ยวข้อง

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

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

 
GN⁺ 3 일 전
ความคิดเห็นบน Hacker News

  • ก็น่ายินดีที่มีการ ปล่อยของออกมาจริง แต่ยังไม่ค่อยเห็นว่าทำไมถึงต้องใช้ตัวนี้โดยเฉพาะ
    มีทางเลือกที่เป้าหมายคล้ายกันอยู่แล้วอย่าง Flatcar Container Linux, Fedora CoreOS, Talos Linux, IncusOS ซึ่งดูมีทั้งชุมชนและแรงสนับสนุนเชิงพาณิชย์ที่แข็งแรงกว่า
    ถ้าอธิบายให้ชัดกว่านี้ว่าอะไรคือจุดต่าง ก็น่าจะเข้าใจได้มากขึ้น

    • ผมใช้ IncusOS อยู่ในโฮมแล็บ และประสบการณ์ทั้งการตั้งค่าและการใช้งานดีมาก
      ย้ายมาจาก Proxmox แล้วตอนนี้ก็ใช้จัดการ VM ทั้งหมด โดยใช้ coding assistant อย่างจริงจังเพื่อทำงานอย่างอัตโนมัติ เช่น ตั้งค่า IncusOS CLI, แปลงอิมเมจ Docker-Compose เป็น Incus, หรือเขียน bash script สำหรับเปิดคอนเทนเนอร์ใหม่โดยไม่ต้องกังวลกับการใช้ --dangerously-skip-permissions
      จุดที่ดีที่สุดคือมันจัดการได้ด้วย ไฟล์แบบ declarative ทำให้มองเห็นการตั้งค่าเครือข่ายและทรัพยากรต่าง ๆ ได้ชัดเจนตลอดเวลา
      ถ้าใช้งานแนวคล้ายกัน IncusOS ก็น่าลองดู
    • ปกติเครื่องมือแบบนี้มักต้องใช้ เวลาตั้งค่าหลายชั่วโมง แต่ตัวนี้ต่างตรงที่บูตแล้วใช้งานได้เลย

  • ตราบใดที่ยังเป็นซอฟต์แวร์ ก็ไม่มีทาง ข้ามเรื่องการบำรุงรักษา ไปได้
    ไม่มีอะไรที่ไร้บั๊ก และถ้าพูดว่าไม่ต้องอัปเกรด แพตช์ หรือดูแลอะไรเลย สุดท้ายก็มักจะเป็นทางลัดไปสู่ ระบบที่ถูกเจาะ

    • ไม่ได้หมายความว่า OS นี้ ไม่ต้องบำรุงรักษา
      แต่ใกล้เคียงกับการบอกว่ามันช่วยลดภาระการดูแลหลายอย่างที่ต้องทำใน base system แบบดั้งเดิม เพราะ 1) แทบไม่ได้ติดตั้งอะไรไว้เลย และ 2) การอัปเกรด base ทำได้ง่าย แค่รีบูตแล้วเปิดคอนเทนเนอร์ขึ้นมาใหม่
      แน่นอนว่าซอฟต์แวร์ที่รันอยู่ด้านบนยังต้องอัปเกรด แต่ถ้าใช้ Docker เป็นหลัก เลเยอร์นั้นมักถูกจัดการจากอีกฝั่งอยู่แล้ว ก็แค่ดึงคอนเทนเนอร์ใหม่มาแล้วรีสตาร์ต ส่วน OS ก็ทำหน้าที่คล้าย ๆ กับรับประกันว่าข้อมูลจะยังถูกเมานต์อยู่ตำแหน่งเดิม
      ถ้าคุณโอเคกับการรันทุกอย่างบน Docker มันก็ดูเหมือนเป็นตัวเลือกที่ก้าวไปอีกขั้นจาก Debian หรือ Redhat และมีความซับซ้อนเชิงขั้นตอนน้อยกว่า CoreOS
      จะใช้งานง่ายแค่ไหนในทางปฏิบัติยังน่าสงสัยอยู่บ้าง โดยเฉพาะฝั่งการจัดการสตอเรจ แต่สิ่งที่เขาพยายามขายนั้นชัดเจนมาก
    • ประเด็นนี้พูดกันมาหลายปีแล้ว
      self-hosting น่ะทำได้ แต่ก็เท่ากับแบกรับ SLA ไว้ในเวลาว่างนอกงานด้วย
      เพราะงั้นอะไรที่มีผู้ใช้เกิน 1 คน ผมเลิกดูแลไปหมดนานแล้ว
    • แน่นอนว่าไม่มีอะไรปลอดบั๊ก 100%
      แต่ก็มีเหตุผลที่โปรเจกต์อย่าง Talos มีอยู่
      ไม่มีเทอร์มินัล ไม่มี SSH ไม่มี package manager ใช้ไฟล์ซิสเต็มแบบอ่านอย่างเดียว ตัด systemd ออก และลดจำนวน executable ให้เหลือน้อยที่สุด แบบนี้ก็ช่วยลด attack surface ได้ชัดเจน
      ไม่ได้กำลังพูดถึงโปรเจกต์นี้โดยเฉพาะ แต่ระบบที่ปลอดภัยกว่าและต้องดูแลน้อยกว่านั้นมีอยู่จริง
      การที่ไม่มีอะไรปลอดภัย 100% ไม่ได้แปลว่าเราควร YOLO รับ npm package ที่เพิ่งถูกแก้มาเมื่อ 3 นาทีที่แล้วเข้าไปด้วย

  • น่าสนใจดี แต่ผมสงสัยว่าเรื่อง แพตช์, การอัปเกรด และการ สร้าง ISO เอง ทำกันยังไง
    ดูจากซอร์สรีโปแล้วแทบไม่เห็นรายละเอียดส่วนนั้นเลย

    The actual repository here hosts the source code for Lightwhale, and is not of any interest for most people.

    https://bitbucket.org/asklandd/lightwhale/src/master/

    • รีโปดูเหมือน ไม่ได้อัปเดตมานาน
      คอมมิตล่าสุดคือเมื่อ 2 ปีก่อน และดูเหมือนจะไม่มีซอร์สของ เวอร์ชัน 3.0

  • อันนี้ไม่ใช่ OS แต่เป็น Linux distro ไม่ใช่เหรอ?

    • ถ้า Linux distro ไม่ใช่ OS แล้วอะไรถึงจะเป็น OS ล่ะ

  • ผมรู้สึกว่าตัวเองแทบจะเป็นมือใหม่ในด้านนี้ แต่ทำ self-hosting มาเกิน 10 ปีแล้ว และย้ายมาใช้ Unraid ตั้งแต่ราวปี 2019
    มันใช้ง่ายเพราะเน้นเว็บพอร์ทัล และดูแลรักษาก็สะดวก
    เลยสงสัยว่า home server OS ตัวนี้โต้ตอบกับมันยังไง
    เห็นในเว็บไม่มีรูป ก็เลยเดาว่าต้องใช้งานแบบ เทอร์มินัลล้วน หรือเปล่า

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

    • ผมก็ทำเหมือนกัน
      ข้อดีของแนว immutable ที่คนพูดถึงกันมักอยู่ที่เรื่องอัปเดต คือถ้าไปใช้ image เวอร์ชันใหม่แล้วมีปัญหา ก็แค่บูตกลับไปเวอร์ชันก่อนหน้าได้เลย
      แต่ในแง่ฟีเจอร์ ผมก็รู้สึกว่า Ubuntu Server เพียงพอเหมือนกัน
      ปีหนึ่งแค่รัน apt update กับอัปเกรดไม่กี่ครั้ง และเข้าถึงได้เฉพาะในโลคัลกับผ่าน Tailscale เท่านั้น
      OS แบบ immutable นี้กลับดูน่าสนใจกับ โน้ตบุ๊กหรือเดสก์ท็อป มากกว่าโฮมเซิร์ฟเวอร์
      เพราะมีความคาดหวังว่าเมื่อเขียนได้แค่ในโฮมไดเรกทอรี ระบบปฏิบัติการจะเสถียรกว่าและพังได้ยากกว่า

  • ผมสงสัยว่าข้อมูลคอนเทนเนอร์ที่รันบน Lightwhale ควรสำรองข้อมูลเป็นประจำด้วยวิธีไหนถึงจะถือว่าแนะนำที่สุด

  • ผมยังไม่ค่อยเข้าใจ
    ถ้าจะรันแค่ Docker ทำไมถึงต้องใช้ immutable และถ้าติดตั้ง Docker ได้ในไม่กี่นาทีอยู่แล้ว ทำไมต้องใช้ Debian ดัดแปลงแบบพิเศษแทน Debian หรือ Ubuntu ด้วย
    เรื่องการบำรุงรักษาเองก็ดูเหมือนแค่จัดการผ่าน package manager จากรีโปของดิสโทรหรือรีโปทางการของ Docker ก็พอไม่ใช่เหรอ
    ผมอยากให้กระแส immutable แบบนี้หายไปสักที และ flatpak หรือ snap ก็เหมือนกัน
    Linux ทำสิ่งที่โซลูชันพวกนี้อ้างว่าจะแก้ไว้ได้อยู่แล้วตั้งแต่แรก
    ผู้ใช้แตะ base system ไม่ได้ถ้าไม่มี root และแอปพลิเคชันก็แค่ลง dependency ไว้ที่ /usr/lib ได้

    • สำหรับผม Debian stable กับ podman/Docker ก็ immutable พอแล้ว
      ต่อให้มีปัญหาก็ยังหาคนช่วยได้ง่าย ซึ่งเป็นประกันชั้นดี
      มันอาจทำให้เล็กลงได้กว่านี้ แต่ตอนนี้ก็รันได้ดีอยู่แล้วแม้บนฮาร์ดแวร์ประหลาด ๆ อย่าง BananaPi สเปกต่ำ หรือ RISC-V ราคาถูก เลยไม่ค่อยมีเหตุผลให้ต้องการอย่างอื่น

  • ของแบบนี้น่าจะเหมาะกับ คลัสเตอร์ Swarm mode พอสมควร
    ไม่แน่ใจว่าโฟกัสแค่โฮมเซิร์ฟเวอร์หรือเปล่า แต่จะติดตามดูต่อไป
    โปรเจกต์ก็ดูดีมาก

    • ตอนนี้ที่สื่อสารไปทาง โฮมเซิร์ฟเวอร์ เพราะเป็นพื้นที่ที่คนกล้าลองมากที่สุด
      แต่จริง ๆ แล้ว Lightwhale รันอยู่ในโปรดักชันแล้ว และก็เหมาะมากสำหรับการใช้งานแบบ Swarm cluster

  • ดูสะอาดตามาก
    จากมุมมองของ มือใหม่ นี่แหละคือแนวทางที่ต้องการ เพราะช่วยไม่ให้เผลอทำการตั้งค่าพัง เลยตั้งใจว่าจะลองใช้แน่นอน