เริ่ม Homelab ด้วย Docker Compose ก่อนก็ได้ไหม

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

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

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

วาดบริการที่ต้องอยู่ด้วยกันก่อน

สมมติแอปหนึ่งใช้ฐานข้อมูลและมีหน้าเว็บให้เข้าจากเบราว์เซอร์ เราควรระบุว่าใครต้องคุยกับใคร และส่วนใดต้องรับคำขอจากนอกเครื่อง การเริ่มจากภาพนี้ช่วยให้กำหนด service กับ network ได้ตรง ไม่เปิดพอร์ตทุกตัวเพียงเพราะแต่ละ image มีตัวอย่างให้เปิดไว้

Compose ใช้ service เป็นหน่วยอธิบายสิ่งที่จะรัน พร้อมตัวเลือกอย่าง image, environment, network และ volume การเก็บไว้ในไฟล์ทำให้เราเห็นส่วนประกอบร่วมกัน และใช้ชุดตั้งค่านั้นสร้างซ้ำได้ตามเงื่อนไขของเครื่องมือ

ภายใน network ที่ Compose จัดให้ บริการสามารถอ้างกันตามชื่อที่ตั้งไว้ได้ตามการตั้งค่า จึงควรใช้ปลายทางที่ตั้งใจ เช่น ชื่อ service ของฐานข้อมูล ไม่เอา localhost ของ container แอปไปใช้เหมือนกำลังเรียกอีก container หนึ่ง เพราะ localhost มองกลับมาที่พื้นที่เครือข่ายของตัวมันเอง

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

แยกสิ่งที่สร้างใหม่ได้กับสิ่งที่ต้องรักษาไว้

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

ให้จดว่า service ใดเขียน path ไหน แล้ว path นั้นถูกผูกกับ volume หรือ directory บน host อย่างไร การใส่ชื่อ volume ไว้ในไฟล์ช่วยจัดการได้ แต่เรายังต้องรู้ว่าทรัพยากรจริงที่ใช้อยู่ชื่ออะไรและอยู่ภายใต้ชุดใด

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

ส่วนไฟล์ตั้งค่ากับความลับควรมีทางส่งให้บริการที่เหมาะสม ไม่เก็บรหัสจริงไว้ในไฟล์ตัวอย่างที่นำเข้า version control แล้วเชื่อว่าการเป็น repo ส่วนตัวทำให้ไม่ต้องดูแลสิทธิ์ต่อ เพราะเส้นทางใช้งานกับเส้นทางแจกไฟล์อาจกว้างขึ้นภายหลัง

เริ่มก่อนหลังยังไม่เท่ากับพร้อมรับงาน

แอปอาจต้องใช้ฐานข้อมูลตั้งแต่เริ่ม แต่การสั่งให้ container ฐานข้อมูลเริ่มก่อนยังไม่ได้รับประกันว่ามันรับคำสั่งได้แล้ว Compose มีเงื่อนไข dependency กับ healthcheck ให้ใช้ตามรุ่นและรูปแบบที่รองรับ เพื่อบอกว่าควรรอหลักฐานใดก่อนเริ่มส่วนถัดไป

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

แม้จัดลำดับเริ่มได้แล้ว แอปก็ยังต้องรับมือการเชื่อมต่อที่หลุดระหว่างรัน เพราะฐานข้อมูลอาจเริ่มใหม่ภายหลังได้เหมือนกัน การรอเฉพาะตอน up จึงไม่ได้แทน retry หรือการจัด connection ของแอปตลอดอายุการทำงาน

นโยบาย restart ของ container ก็ควรอ่านความหมายตามเครื่องมือ ไม่สมมติว่าการติดป้าย unhealthy จะทำให้ทุกอย่างถูกกู้คืนเหมือนกันเสมอ และควรมีข้อมูลให้ดูว่าระบบกำลังวนเริ่มใหม่แทนการทำงานปกติหรือไม่

อัปเดตโดยรู้ว่ากำลังเปลี่ยนอะไร

เมื่อจะเปลี่ยน image ควรระบุรุ่นที่เลือกและตรวจข้อมูลการอัปเกรดของบริการนั้น โดยเฉพาะส่วนที่มีข้อมูลถาวร การเปลี่ยน tag เป็นค่าที่ลอยตามเวลาอาจทำให้การสั่งครั้งถัดไปได้รุ่นใหม่โดยที่ไฟล์ Compose ไม่ได้เปลี่ยนตามที่เรารู้ตัว

ก่อนอัปเดตให้มีข้อมูลว่ารุ่นเดิมคืออะไร มี backup ที่ใช้ได้หรือไม่ และถ้าต้องกลับรุ่น แอปเก่ายังอ่านข้อมูลหลังอัปเดตได้ไหม เพราะการเปลี่ยน container กลับไม่ได้ทำให้ schema ของข้อมูลย้อนตามเองทุกบริการ

การเก็บ Compose file ใน version control ช่วยย้อนดูการตั้งค่า แต่ควรเก็บรายการขั้นตอนที่เกิดนอกไฟล์ด้วย เช่น migration หรือการตั้งสิทธิ์ในแอป เพื่อให้การย้ายเครื่องหรือกู้ระบบมีข้อมูลครบกว่าตัวไฟล์เพียงอย่างเดียว

ขยับเครื่องมือเมื่อเห็นข้อจำกัดที่ต้องแก้

หากยังมีบริการไม่มากบนเครื่องเดียว Compose อาจช่วยให้เราเรียนรู้การดูแล log, network, volume และการกู้ได้ชัดก่อน แต่เมื่อเริ่มต้องย้ายงานระหว่างเครื่อง ดูแลความพร้อมหลายโหนด หรือมีข้อกำหนดปล่อยงานที่มากขึ้น ก็ควรจดข้อจำกัดเหล่านั้นเพื่อเลือกขั้นต่อไปตามเหตุผลจริง

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

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

สรุป

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