หวนคืนสู่ FreeBSD: ตอนที่ 1

 (hypha.pub)
3 คะแนน โดย GN⁺ 2026-02-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทความที่ไล่ย้อนประวัติของปัญหาการดีพลอยเซิร์ฟเวอร์และการแยกโปรเซส พร้อมชี้ให้เห็นว่า FreeBSD jails ได้นำแนวคิดคอนเทนเนอร์สมัยใหม่ไปใช้จริงก่อนอุตสาหกรรมถึง 10 ปี
  • jails ที่ถูกเพิ่มเข้ามาใน FreeBSD 4.0 เมื่อปี 2000 เป็นการขยาย chroot ให้สามารถแยก ไฟล์ซิสเต็ม เครือข่าย และโปรเซสได้อย่างสมบูรณ์ ในฐานะความสามารถแบบเนทีฟของเคอร์เนล
  • Linux เข้าสู่โลกคอนเทนเนอร์ผ่าน LXC ในปี 2008 และ Docker ในปี 2013 แต่ระหว่างทางก็มีการสะสมของ ชั้นนามธรรมที่ซับซ้อนอย่าง namespace, cgroups, OCI
  • สิ่งที่ Docker แก้ได้ดีคือปัญหาเรื่องการแพ็กเกจและการส่งมอบแอปพลิเคชัน (shipping) ขณะที่ jails เด่นด้านการแยก แต่มีจุดอ่อนคือ ไม่มีมาตรฐานการส่งมอบแบบเนทีฟ
  • ตอนถัดไปจะพูดถึงการสร้างโครงสร้างพื้นฐานบน jails, ZFS snapshots, การ provision ด้วย Ansible และวิธีใช้งานจริง

ปัญหาของการดีพลอยเซิร์ฟเวอร์ในยุคแรก

  • หลายสิบปีก่อน วิธีมาตรฐานในการดีพลอยอะไรบางอย่างขึ้นเซิร์ฟเวอร์คือการ คัดลอกไฟล์ด้วยตนเองผ่าน FTP โดยใช้ Total Commander, FileZilla, FAR Manager ฯลฯ ส่วนผู้ใช้ขั้นสูงอาจใช้ scp หรือ rsync แต่แก่นของวิธีก็ไม่ต่างกัน
  • ในโปรเจ็กต์ที่ทำคนเดียว ความผิดพลาดอาจไม่ใช่ปัญหาใหญ่ แต่เมื่อดูแล โปรเจ็กต์ของลูกค้าหลายสิบราย มันอาจกลายเป็นเรื่องร้ายแรง
  • ในสถาปัตยกรรมแบ็กเอนด์ทั่วไป เว็บไซต์หลายแห่งจะใช้ Apache web server instance เดียวกันและมีวงจรชีวิตเดียวกัน ถ้า Apache ล่ม ทุกเว็บก็ล่มตาม
  • เมื่อทราฟฟิกพุ่งขึ้น หากเว็บไซต์หนึ่งกินทรัพยากรทั้งหมด ก็จะเกิดปัญหาที่ เว็บไซต์อื่น ๆ บนเซิร์ฟเวอร์เดียวกันค่อย ๆ ถูกบีบจนแทบหายใจไม่ออก
  • ผู้ดูแลระบบพยายามทำ automation ด้วยเชลล์สคริปต์ แต่ก็ ไม่มีวิธีมาตรฐานสำหรับการจัดการเวอร์ชันหรือ rollback และมักใช้ธรรมเนียมการตั้งชื่อโฟลเดอร์โปรเจ็กต์ด้วยเลขลำดับหรือ timestamp ต่อท้าย

สองปัญหาหลักที่ต้องแก้

  • การดีพลอย (Deployment): ต้องมีโซลูชันอเนกประสงค์ที่รองรับการส่งมอบอย่างเสถียร ป้องกัน human error จัดการเวอร์ชันและ rollback ได้ และครอบคลุมทุกกรณีทางธุรกิจ
  • การแยกโปรเซส (Process Isolation): ต้องมีการปกป้องทั้งระหว่างแอปกับระบบ ป้องกันไม่ให้ความต้องการของแอปหนึ่งไปทำให้อีกแอปพังโดยไม่รู้ตัว และแก้ปัญหาการชนกันของ dependency
  • ความพยายามในการแก้ปัญหาการดีพลอยได้วิวัฒน์มาเป็น CI/CD pipelines, มาตรฐานการแพ็กเกจ และระบบควบคุมเวอร์ชันสมัยใหม่ แต่ประวัติของปัญหาด้านการแยกกลับเป็นสิ่งที่คนรู้จักน้อยกว่า

จาก chroot สู่ virtual machine

  • chroot ที่ Bell UNIX นำมาใช้ในปี 1979 มอบ มุมมองไฟล์ซิสเต็มแบบแยกขาด ให้กับโปรเซส ทำให้เข้าถึงภายนอก subtree นั้นไม่ได้ เป็นแนวคิดพื้นฐานที่หยาบแต่มีประโยชน์
    • ข้อจำกัด: มันแยกได้แค่ไฟล์ซิสเต็มเท่านั้น ยังสามารถไปรบกวนเครือข่าย โปรเซสอื่น หรือทรัพยากรของระบบได้ และยังหลุดออกมาได้ด้วย
  • คำตอบระดับองค์กรอย่างจริงจังครั้งแรกคือ virtual machine (VM) ซึ่ง VMware ทำให้แพร่หลายในช่วงปลายทศวรรษ 1990
    • มันมอบสภาพแวดล้อม OS ที่แยกจากกันอย่างสมบูรณ์ให้แต่ละแอปพลิเคชัน แต่ทุก VM ต้องมี OS เต็มชุดของตัวเอง จึงมี overhead สูงพอสมควร และมีต้นทุนด้านเวลาเริ่มต้นที่กินเป็นนาที

การถือกำเนิดของ FreeBSD Jails

  • ในปี 2000 การปฏิวัติแบบเงียบ ๆ เกิดขึ้นบน FreeBSD ไม่ใช่ Windows Server หรือ Linux
  • FreeBSD แตกต่างจาก Linux อย่างถึงราก โดย Linux ให้แค่เคอร์เนล ส่วน GNU userland, ecosystem ของแพ็กเกจ และตัวเลือกตามแต่ละดิสโทรถูกประกอบเข้าด้วยกัน ขณะที่ FreeBSD พัฒนา จัดการเวอร์ชัน และทดสอบเคอร์เนล userland เครื่องมือพื้นฐาน และไลบรารีเป็น OS สมบูรณ์ชุดเดียว
  • โซลูชันที่สร้างขึ้นบนรากฐานอันสอดคล้องนี้คือ jails ซึ่งถูกนำเสนอโดย Poul-Henning Kamp และ Robert Watson และถูกรวมเป็นความสามารถแบบเนทีฟของเคอร์เนลใน FreeBSD 4.0 (มีนาคม 2000)
  • แต่ละ jail มี มุมมองไฟล์ซิสเต็ม, network stack และพื้นที่โปรเซส ของตัวเอง และมองไม่เห็นระบบโฮสต์
  • เพราะใช้เคอร์เนลของโฮสต์ร่วมกัน จึงมี overhead แทบเป็นศูนย์ และใช้เวลาเริ่มต้นแทบจะทันที
  • FreeBSD ทำให้สิ่งที่ปัจจุบันเราเรียกว่าคอนเทนเนอร์เกิดขึ้นจริงในเชิงปฏิบัติบน production ก่อนอุตสาหกรรมถึง 10 ปี

ไทม์ไลน์ของเทคโนโลยีการแยก

  • เส้นทางวิวัฒน์ที่แท้จริงของปัญหาการแยกคือ: shared server ที่ไม่มีการแยก → virtual machine ที่หนักแต่แยกได้ → container ที่เบาและแยกได้
  • FreeBSD ไปถึงขั้นที่สามตั้งแต่ปี 2000 ส่วน Linux ไปถึงผ่าน LXC ในปี 2008 และ Docker ปรากฏในปี 2013
  • ตอนที่ Docker ได้รับการยกย่องว่าเป็นของปฏิวัติวงการนั้น FreeBSD jails ก็อยู่ในสถานะที่ สุกงอมและผ่านการพิสูจน์ในสนามจริงมาแล้ว 13 ปี

เหตุใด Linux จึงชนะ

  • ความเหนือกว่าทางเทคนิคไม่ได้แปลว่าจะชนะในสงคราม ecosystem
  • Linux ชนะด้วย การตัดสินใจที่รวดเร็ว, แรงส่งแบบไวรัลของไลเซนส์ GPL และการสนับสนุนระดับองค์กรอย่างแข็งแกร่งจาก Red Hat และ IBM
  • ต่อมา Google, Facebook และ Amazon ก็พัฒนาเครื่องมือสำหรับดาต้าเซ็นเตอร์ขนาดใหญ่ และ เป็นผู้กำหนดทิศทางของอุตสาหกรรมทั้งระบบ
  • Linux เปลี่ยนจาก “OS ฟรีสำหรับคนที่ซื้อไลเซนส์เชิงพาณิชย์ไม่ไหว” ไปเป็น “ตัวเลือกเดียวสำหรับเซิร์ฟเวอร์”

ความซับซ้อนของ ecosystem คอนเทนเนอร์บน Linux

  • วิศวกร Linux สร้าง kernel primitives อย่าง namespace, cgroups, seccomp เพื่อแก้ปัญหาการแยกและการดีพลอย แล้วจึงซ้อน ชั้นนามธรรมที่ซับซ้อน ทับลงไปอีกเป็น LXC (2008) → OCI/runc (2015) → Docker/Podman (2013/2018) → Docker Hub เป็นต้น
  • ผลลัพธ์คือก้อนของ leaky abstractions ที่ถูกออกแบบเกินจำเป็น สำหรับโครงสร้างพื้นฐานแบบคลาวด์และพึ่งพา vendor
  • ปัจจุบัน หากต้องรันแอปพลิเคชันบนระบบขนาดใหญ่ การทำให้เป็นคอนเทนเนอร์ด้วย Docker และ orchestration ด้วย Kubernetes ได้กลายเป็น ค่าตั้งต้นโดยปริยาย ไม่ใช่เพียงหนึ่งในหลายทางเลือก แต่ถูกเสนอเป็นสิ่งที่ต้องทำอยู่แล้ว

สิ่งที่ Docker สร้างไว้ และจุดอ่อนของ Jails

  • สิ่งที่ Docker แก้ได้ดีคือ ปัญหา shipping: การแพ็กแอปพลิเคชันพร้อม dependency ทั้งหมด การกระจายผ่าน registry และการทำให้รันได้เหมือนกันบนทุกเครื่อง ด้วย มาตรฐานอเนกประสงค์
  • OCI image format ได้กลายเป็นมาตรฐานโดยพฤตินัยของอุตสาหกรรม
  • Jails แก้ปัญหาการแยกได้อย่างยอดเยี่ยม แต่ไม่มี โซลูชันแบบเนทีฟสำหรับ shipping และนี่คือสาเหตุหลักที่ทำให้ ecosystem ของ jails ดูยังไม่สุกงอมเมื่อเทียบกับ ecosystem ของ Docker
  • ชุมชนก็รับรู้ถึงช่องว่างนี้เช่นกัน และมีเครื่องมือบางตัว (cbsd, bastille, pot, appjail ฯลฯ) ที่พยายามเลียนแบบ ecosystem คอนเทนเนอร์สมัยใหม่ ขณะเดียวกันก็ยังมี แนวทางอื่น ที่ใช้ประโยชน์จาก FreeBSD native primitives

เกริ่นถึงตอนถัดไป

  • ในตอนถัดไป ผู้เขียนจะพูดถึงความกระชับและความสง่างามของโครงสร้างพื้นฐานบน FreeBSD ตั้งแต่พื้นฐานของ jails และวิธีการทำงาน การลด boilerplate ผ่าน jail managers, การ provision และการดีพลอยด้วย Ansible, พลังของ ZFS snapshots และวิธีรวมทุกอย่างเข้าด้วยกันเพื่อสร้างโครงสร้างพื้นฐานที่แข็งแรงและขยายได้สำหรับ Hypha

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

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

 
GN⁺ 2026-02-24
ความคิดเห็นจาก Hacker News

  • แค่ความเหนือกว่าทางเทคนิคอย่างเดียวก็ไม่พอจะชนะใน สงคราม ecosystem
    ช่วงกลางทศวรรษ 90 Linux เติบโตได้เพราะการตัดสินใจที่รวดเร็ว, แรงแพร่ของไลเซนส์ GPL, และการสนับสนุนจากบริษัทอย่าง Red Hat กับ IBM
    ฉันติดตั้ง Linux ครั้งแรกในปี 1994 แต่ในชุมชน FreeBSD กลับเมินเครื่อง PC ราคา $3,500 ของฉันว่า “งั้นๆ”
    ตอนนั้นมีบั๊กในอินเทอร์เฟซ IDE แต่ Linux ออกวิธีเลี่ยงมาให้ภายในไม่กี่วัน ขณะที่ฝั่ง BSD เอาแต่บอกให้ไปซื้ออุปกรณ์ SCSI
    ตอนนั้นฉันยังเป็นนักศึกษาและไม่มีเงิน สุดท้าย Linux จึงเป็นตัวเลือกที่ใช้งานได้จริง
    ภายหลังฉันกลับไปลอง FreeBSD อีกครั้ง แต่ตอนนั้น Linux ก็ทำทุกอย่างที่ฉันต้องการได้อยู่แล้ว
    บั๊กที่เกี่ยวข้องมีสรุปไว้ใน บทความวิกิ CMD640

    • ฉันเองก็เป็นแฟน FreeBSD แต่รู้สึกว่ามี การบรรจบกันด้านฟังก์ชัน กับ Linux มากขึ้นเรื่อยๆ
      ถึงอย่างนั้นสิ่งที่ชอบใน FreeBSD คือ ความสม่ำเสมอ ของทั้งระบบมากกว่า และองค์ประกอบหลักอย่างเสียงหรือ event API ก็ยังถูกดูแลอย่างเสถียร
      การรองรับไดรเวอร์ฮาร์ดแวร์รุ่นใหม่ยังไง Linux ก็ยังดีกว่า แต่ก็หวังว่า FreeBSD จะไม่ “กลายเป็น Linux” มากเกินไป
    • ทุกวันนี้คนที่ใช้ BSD ส่วนใหญ่ก็มักใช้เพราะคุ้นเคย หรือไม่ก็ใช้เพราะมีนิสัย ขบถ
      เอาจริงๆ *nix สมัยใหม่ฝั่งไหนก็ทำอะไรได้แทบเหมือนกันหมดแล้ว ตอนนี้จึงเป็นเรื่องของ รสนิยมและความคุ้นมือ มากกว่าประสิทธิภาพ
    • ช่วงแรก Linux ได้รับ ความสนใจเชิงพาณิชย์ เลยทำให้การรองรับฮาร์ดแวร์ดีขึ้นแบบก้าวกระโดด
      ส่วน BSD ถูกบริษัทหลีกเลี่ยงเพราะคดีความกับ AT&T และในช่วงนั้น Linux ก็ยึดตลาดไปแล้ว
      แม้ตอนนี้จะยังมีบทความออกมาปกป้อง FreeBSD แต่ก็ยากจะพลิกแนวโน้มที่ถูกกำหนดไว้ตั้งแต่ยุค 90
    • อ่านเรื่องที่ฝั่ง BSD เคยหัวเราะเยาะ PC ของฉันแล้วก็ขำดี
      ถึงอย่างนั้นก็ยังคิดว่าการรองรับฮาร์ดแวร์ทุกวันนี้ยังมีช่องให้พัฒนาอีกมาก
    • ระหว่างปี 1992~1994 BSD อยู่ภายใต้ แรงกดดันจากการฟ้องร้อง ขณะที่ Linux เติบโตขึ้นเรื่อยๆ

  • บทความนี้น่าสนใจดี
    แต่ฉันไม่เห็นด้วยกับความเห็นที่ว่าพวก kernel primitive ของ Linux อย่าง namespaces, cgroups, seccomp ได้กลายเป็นระบบนิเวศของ abstraction ที่ซับซ้อนในที่สุด
    Linux ซับซ้อนขึ้นเพราะมันประสบความสำเร็จ ไม่ใช่เพราะเป็นการออกแบบที่ล้มเหลว
    ถ้า BSD เป็นกระแสหลัก ก็คงเกิด ecosystem แบบ “over-engineered” เหมือนกัน

    • FreeBSD มีแนวคิดแบบ เน้นวิศวกรรม มากกว่าวัฒนธรรมแฮ็กเกอร์
      container สุดท้ายก็เป็นแค่ VM แบบเบาๆ ดังนั้นฉันจึงคิดว่าใช้ VM จริงไปเลยจะดีกว่า
    • ถ้าเทียบ utility ฝั่ง BSD กับ GNU จะเห็น ความต่างด้านสไตล์ ชัดเจน
      ที่ Docker ได้รับความนิยมก็เพราะการนำกลับมาใช้ซ้ำได้และ ecosystem ไม่ใช่เพราะเรื่อง security isolation

  • jail ของ FreeBSD นั้นเรียบง่ายและสง่างาม แต่ OCI container ของ Linux ใช้งานง่ายกว่ามาก
    container ไม่ใช่ความสามารถเดี่ยวของเคอร์เนล แต่เป็นภาพลวงที่ประกอบขึ้นจากหลาย namespace, mount และการแยก process
    การออกแบบของ Linux เป็นสิ่งที่ตั้งใจไว้ และ cgroups กับ seccomp ก็ถูกใช้กว้างขวางนอกเหนือจาก container เช่นใน systemd หรือ flatpak

    • FreeBSD ยังมีจุดแข็งในด้านอย่างอุปกรณ์เครือข่ายหรือ storage controller
      ปรัชญา “cattle vs pets” สามารถนำไปใช้ได้ที่ระดับ VM และ orchestration
    • Linux container สร้างและรันได้เร็ว กว่า FreeBSD jail มาก
      คำบอกว่า jails ดีกว่านั้นฟังดูไม่ค่อยตรงกับความเป็นจริง

  • ที่ Docker ชนะได้ไม่ใช่เพราะ การแยกเชิงเทคนิค แต่เพราะ ecosystem
    ด้วยเครื่องมืออย่าง Dockerfile, public registry, และ compose ทำให้สร้างสภาพแวดล้อมที่พร้อมรันได้ภายใน 30 วินาที
    FreeBSD jail นั้นยอดเยี่ยมในเชิงเทคนิค แต่มีกำแพงการเริ่มต้นใช้งานสูง
    ช่วงหลังๆ ก็เริ่มเห็นกระแสอยากกลับไปหา jail หรือ VM ที่เรียบง่ายกว่า เพราะความซับซ้อนของ container stack

    • FreeBSD มีส่วนแบ่งตลาดระดับ 0.1% เลยไม่มีทาง “ชนะ” ได้
      แต่จริงๆ แล้วไม่ใช่เรื่องการแข่งขัน แค่แต่ละฝั่งมีบทบาทต่างกัน
    • ด้วย สถาปัตยกรรม client/server ของ Docker จึงทำให้มีสภาพแวดล้อมแบบรวมศูนย์อย่าง Docker Desktop ได้
      FreeBSD ไม่มีแนวคิดแบบนี้ และยังขาด ระบบ image ด้วย
    • สำหรับฉัน แค่ใช้ Docker Compose หรือ Swarm ก็เรียบง่ายพอแล้ว
      ถ้า FreeBSD ลงทุนกับ UX และ ecosystem แบบที่ Docker ทำ ฐานผู้ใช้อาจโตขึ้นหลายเท่า
    • แม้แต่ในต้นฉบับก็ยังย้ำคำว่า “ecosystem” ซ้ำหลายครั้ง

  • ราวปี 2005 ฉันเคยรันทั้งบริษัทบน FreeBSD
    แต่เมื่อเวลาผ่านไป Linux ก็ครองทั้งงานส่วนตัวและงานองค์กร
    ตอนนี้ Docker ก็ดีพอแล้ว และไม่มี เหตุผลเชิงตรรกะ ที่จะย้อนกลับไปอีก

    • ช่วงต้นยุค 2000 FreeBSD 4 มีประสิทธิภาพด้านเครือข่ายและสตอเรจยอดเยี่ยมมาก
      แต่ตอบสนองต่อยุค CPU แบบมัลติคอร์ช้าเกินไป เลยถูก Linux กับ Windows แซง
      ทุกวันนี้ประสิทธิภาพกลับมาดีแล้ว แต่ก็ยังเสียเปรียบจาก การขาดแคลนไดรเวอร์ และข้อจำกัดด้านจำนวนผู้พัฒนา
      ฉันใช้ Linux ในงานที่ต้องการ GPU หรือ CUDA และใช้ FreeBSD กับเซิร์ฟเวอร์ที่ต้องการความเสถียร
    • ฉันก็คิดคล้ายกัน ขนาด เม็ดเงินลงทุน ใน Linux มหาศาลจนข้อเสียหลายอย่างถูกกลบไป
      UX ของ FreeBSD สม่ำเสมอกว่า แต่ในโลกความจริง Linux กลายเป็น “เส้นทางที่มีความสุข” ไปแล้ว
    • ฉันยังสงสัยอยู่ดีว่าทำไม Satoshi ถึงใช้ Windows

  • ยินดีเสมอที่ได้เห็นบทความแนะนำ FreeBSD

  • แม้ FreeBSD จะนำ jail มาใช้ตั้งแต่ปี 2000 แต่ฝั่ง Linux ก็มีเทคโนโลยีคล้ายกันอย่าง OpenVZ และ VServer อยู่แล้ว

    • Virtuozzo เป็นซอฟต์แวร์ปิดเลยแพร่หลายได้ช้า ส่วน Linux-VServer ก็โฟกัสแค่เว็บโฮสติ้งจึงไม่เคยกลายเป็นกระแสหลัก
      สุดท้ายเมื่อ LXC ปรากฏขึ้นในช่วงปลายยุค 2000 จึงค่อยเกิดภาพจำว่า “FreeBSD นำหน้าอยู่ก่อนแล้ว”

  • ฉันสงสัยว่ามีบทความที่อธิบายเชิงเทคนิคเรื่อง วิธีการทำ isolation ของ container และ VM ไว้ไหม
    ไม่ใช่แค่ระดับที่บอกว่า “ใช้เคอร์เนลเดียวกันเลยอ่อนกว่า” แต่เป็นรายละเอียดการทำงานจริงๆ

  • ช่วงนี้ฟีเจอร์อย่าง systemd-oomd ทำให้ฉันอยากกลับไปใช้ FreeBSD
    แต่ก่อนฉันเคยเปิดหลาย process ไว้ในเทอร์มินัลพร้อมเก็บล็อกเพื่อทำงานพัฒนา
    ตอนนี้ systemd กลับ ฆ่า process ทั้งชุดในระดับ cgroup จนงานหายไปหมด
    การเปลี่ยนแปลงระบบที่ไม่เข้ากันแบบนี้ ทำลาย workflow การพัฒนา และน่าหงุดหงิดที่ต้องคอยใช้ systemd-run หรือ Docker ทุกครั้งเพื่อแยก process

  • หัวใจของความสำเร็จของ Linux คือ ความแพร่กระจายแบบติดเชื้อของ GPL และ network effect
    เมื่อผู้ใช้มองว่า Linux คือมาตรฐาน ผู้ผลิตฮาร์ดแวร์ก็เริ่มออกไดรเวอร์สำหรับ Linux ตามธรรมชาติ
    ด้วยความยืดหยุ่นของเคอร์เนล ecosystem ของไดรเวอร์โอเพนซอร์สจึงเติบโตอย่างระเบิดระเบ้อ