แยกหรือรวมดี? เจาะลึกการแยก Postgres และ Redis บน Directus กับ Coolify
บทความภาคต่อซีรีส์ Directus และ Coolify ว่าด้วยการตัดสินใจแยกบริการฐานข้อมูลและแคชออกจากสแต็กหลัก
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การตั้งค่าแบบมัดรวมในไฟล์ Docker Compose เดี่ยว เหมาะสำหรับแอปพลิเคชันเดี่ยวทั่วไป
- การรีสตาร์ทบริการและการสำรองข้อมูล S3 สามารถทำแยกกันได้แม้จะอยู่ใน Compose ไฟล์เดียวกัน
- ข้อจำกัดที่แท้จริงของการมัดรวมคือฟีเจอร์เก็บสถิติ CPU และ Memory และการแชร์ฐานข้อมูลข้ามแอป
นี่คือเนื้อหาภาคที่ 2 ของซีรีส์ Directus คู่กับ Coolify หากคุณเพิ่งเริ่มต้น ควรกลับไปดูบทความเกี่ยวกับการตั้งค่าความปลอดภัย VPS และวิธีแรกสุดแบบมัดรวมบริการทั้งหมดไว้ใน Docker Compose ไฟล์เดียว ซึ่งช่วยลดปัญหา Race Condition ระหว่างเริ่มระบบโดยอัตโนมัติ
สำหรับการรันแอปพลิเคชันเดี่ยว วิธีแบบมัดรวมคือแนวทางที่แนะนำบน VPS ที่จัดการด้วย Coolify แต่เดิมทีผู้เขียนคาดเดาว่าการแยกบริการออกจากกันน่าจะให้ประโยชน์มากกว่าในแง่ของการควบคุมการสำรองข้อมูล การตรวจสอบ และการรีสตาร์ท จึงได้ทดสอบข้อสมมติเหล่านี้บนระบบ Coolify จริง
ข้อแรกที่คาดไว้คือการรีสตาร์ท Directus จะทำให้ Redis และ Postgres ต้องรีสตาร์ทตามไปด้วย แต่ในความเป็นจริง Coolify มีปุ่ม Restart แยกอิสระสำหรับ Directus, Database และ Cache ในหน้าจอเดียวกัน ทำให้ไม่ต้องแยกบริการเพื่อเหตุผลนี้
ในส่วนของการสำรองข้อมูล แม้ Postgres จะถูกมัดรวมอยู่ใน Compose ไฟล์ของ Directus แต่ Coolify ก็ยังมีเมนู Backups แยกเฉพาะตัวพร้อมรองรับ S3 มาให้ตั้งแต่ต้น ไม่ใช่ฟีเจอร์สำหรับทรัพยากรแยกเดี่ยวเท่านั้น
เช่นเดียวกับเรื่องการตั้งเวลางาน Coolify มีแท็บ Scheduled Tasks แยกในแต่ละบริการ พร้อมเมนูดรอปดาวน์เลือกชื่อคอนเทนเนอร์เพื่อรัน Cron Job เฉพาะฐานข้อมูลหรือ Directus ได้ทันทีโดยไม่ต้องแยกสแต็ก
การทำความเข้าใจสถาปัตยกรรมของ Docker และ Coolify ช่วยให้ประหยัดทรัพยากรเซิร์ฟเวอร์ได้มาก การแยกบริการ (Decoupling) ไม่จำเป็นเสมอไปหากระบบจัดการคอนเทนเนอร์มีเครื่องมือเสริมที่ยืดหยุ่นรองรับการจัดการรายตัวอยู่แล้ว นักพัฒนาจึงควรชั่งน้ำหนักระหว่างความเรียบง่ายในการดูแลรักษากับความต้องการด้านสถาปัตยกรรมที่ซับซ้อน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
อย่างไรก็ตาม มีสองเหตุผลที่ทำให้การแยกบริการมีความจำเป็นจริงๆ เหตุผลแรกคือเรื่อง Metric ตามเอกสารอย่างเป็นทางการของ Coolify ระบุชัดเจนว่า การปรับแต่งผ่าน Docker Compose จะไม่เก็บบันทึกสถิติ CPU และ Memory หากต้องการดูการใช้ทรัพยากรผ่านระบบมอนิเตอร์ในตัว บริการนั้นต้องถูกสร้างเป็นทรัพยากรแบบสแตนด์อโลน
เหตุผลที่สองคือการแชร์ฐานข้อมูลให้หลายแอปพลิเคชันใช้งานร่วมกัน ซึ่งเป็นเรื่องของเครือข่าย Docker โดยฐานข้อมูลที่อยู่ใน Compose ของแอปหนึ่งจะมีเครือข่ายส่วนตัว แอปอื่นจะไม่สามารถเข้าถึงได้ เว้นแต่จะเชื่อมโยงเครือข่ายเข้าหากัน ดังนั้นหากมีทั้งแอปเดสก์ท็อปและมือถือที่ต้องต่อกับ Postgres ตัวเดียวกัน ฐานข้อมูลนั้นต้องถูกสร้างเป็นทรัพยากรแยกตั้งแต่วิธีแรก
สำหรับการตั้งค่าคอนฟิกของ Directus ในไฟล์ Docker Compose จะใช้ภาพ "directus/directus:12.2.0" เปิดพอร์ต 8055 ผูกโวลุ่มอัปโหลดและส่วนเสริม พร้อมตั้งค่า Healthcheck ด้วย URL "127.0.0.1:8055/server/ping" เพื่อป้องกัน บั๊กสถานะ Unhealthy ที่เคยเกิดขึ้นในภาคแรก
ข้อควรระวังสำหรับ URL ของ Redis คือรูปแบบการเชื่อมต่อคือ "redis://username:password@host:port" แต่เนื่องจาก Coolify กำหนดชื่อผู้ใช้มาด้วย (เช่น redis) ในขณะที่ Directus ต้องการเพียงรหัสผ่านเท่านั้น จึงต้องตัดส่วนชื่อผู้ใช้และเครื่องหมาย @ ออกให้เหลือเพียง "redis://:รหัสผ่านของคุณ"
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น