จัดระเบียบ Docker Compose ด้วย Profiles แยก dev/test ให้ชัดเจน

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

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

ทางออกที่เรียบง่าย แต่หลายคนมองข้าม คือ Docker Compose Profiles ซึ่งช่วยให้เราเปิดใช้งานเฉพาะ service ตามบริบทงานได้อย่างเป็นระเบียบ โดยยังคงใช้ไฟล์หลักเพียงไฟล์เดียว

Compose Profiles คืออะไร

Compose Profiles เป็นความสามารถของ Docker Compose ที่ให้เรากำหนดว่า service ใดควรถูกเปิดใช้งานในสถานการณ์แบบไหน เช่น

• โหมด dev สำหรับงานพัฒนา
• โหมด test สำหรับงานทดสอบ
• หรือเปิดหลาย profile พร้อมกันเมื่อจำเป็น

แนวคิดสำคัญคือ service ที่ใช้เสมอสามารถอยู่แบบกลาง ๆ ได้โดยไม่ต้องผูก profile ส่วน service เสริมให้กำหนด profile ตามบทบาทของมันอย่างชัดเจน

วิธีนี้ทำให้ไฟล์เดียวรองรับหลายโหมดได้ โดยไม่ต้องแตกไฟล์ compose หลายชุดจนกระจัดกระจาย

ตัวอย่างการจัด service ตามบริบท

ภาพการใช้งานที่เห็นได้ชัดคือ แต่ละ environment มีความต้องการไม่เหมือนกัน

สำหรับงานพัฒนา อาจต้องมีเครื่องมืออย่าง

• hot reload
• mail catcher
• admin UI

สำหรับงานทดสอบ อาจต้องมี

• mock server
• coverage tool
• isolated database

แต่ใน production ไม่ควรมี service เหล่านี้ติดไปด้วย เพราะเพิ่มทั้งภาระ ความซับซ้อน และความเสี่ยงโดยไม่จำเป็น

ตัวอย่างการแบ่ง service ที่เข้าใจง่าย เช่น

• api ใช้งานทุก profile
• db ใช้งานทุก profile
• mailhog เปิดเฉพาะ dev
• adminer เปิดเฉพาะ dev
• mock-api เปิดเฉพาะ test
• coverage เปิดเฉพาะ test

service กลางอย่าง api หรือ db ที่ต้องใช้เสมอ ไม่จำเป็นต้องกำหนด profile ก็ได้ ส่วน service เสริมให้ใส่ profiles ลงไปตามหน้าที่

ตัวอย่างแนวทางใน compose.yml

แนวทางของ Compose Profiles คือการติด profiles ให้แต่ละ service ที่ต้องการจำกัดการใช้งาน เช่น

• mailhog ใส่ profiles: ["dev"]
• mock-api ใส่ profiles: ["test"]

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

คำสั่งที่ใช้บ่อย ได้แก่

docker compose --profile dev up -d
docker compose --profile test up -d
docker compose --profile dev --profile test up -d

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

ข้อดีที่เห็นชัดสำหรับการทำงานเป็นทีม

เมื่อเริ่มใช้ Compose Profiles อย่างจริงจัง ทีมมักเห็นผลลัพธ์ได้ค่อนข้างเร็ว ทั้งในแง่ประสิทธิภาพและความเป็นระเบียบ

ข้อดีที่เด่นมีดังนี้

• ลดจำนวนไฟล์ compose ที่กระจัดกระจาย
• อ่านโครงสร้างระบบง่ายขึ้น
• onboarding สมาชิกใหม่ได้เร็วขึ้น
• แยก service สำหรับ CI และ test ได้ชัดเจน
• ลดการรัน service ที่ไม่จำเป็นบนเครื่องนักพัฒนา
• ทำให้การ debug ปัญหาทำได้ง่ายขึ้น เพราะขอบเขตของ service แคบลง

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

ใช้ร่วมกับ env file แล้วลงตัวยิ่งขึ้น

อีกแนวทางที่ช่วยให้การจัดการ environment ชัดเจนยิ่งขึ้น คือใช้ Compose Profiles ร่วมกับ env file แยกตามบริบท เช่น

• dev ใช้ .env.dev
• test ใช้ .env.test

รูปแบบนี้ช่วยให้เราแยกค่าคอนฟิกตามการใช้งานได้ แต่ยังคงควบคุมโครงสร้างหลักทั้งหมดผ่าน compose.yml ไฟล์เดียว ทำให้ทุกคนในทีมมองภาพเดียวกัน และแก้ไขได้จากจุดศูนย์กลาง

ใช้กับงาน Frontend ก็มีประโยชน์มาก

หลายคนมักนึกถึง Compose Profiles ในบริบท backend หรือ infrastructure เท่านั้น แต่จริง ๆ แล้วฝั่ง frontend ก็ได้ประโยชน์มากเช่นกัน

ตัวอย่างเช่น

• เปิด storybook เฉพาะตอนพัฒนา
• เปิด service สำหรับ visual regression เฉพาะตอนทดสอบ
• แยก UI tooling ออกจาก flow ปกติของแอป

วิธีนี้ช่วยให้ stack ของ frontend ไม่ปะปนกับ service หลักโดยไม่จำเป็น และทำให้ workflow ชัดเจนขึ้นมาก

เทคนิคการตั้งชื่อ service ให้ทีมเข้าใจตรงกัน

นอกจากการใช้ profile แล้ว การตั้งชื่อ service ก็มีผลต่อความเข้าใจของทีมอย่างมาก

ควรตั้งชื่อให้สื่อหน้าที่โดยตรง เช่น

• mock-api ดีกว่า test-service
• coverage ดีกว่า tool-container

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

แนวทางจัดระเบียบไฟล์ที่แนะนำ

ถ้าต้องการให้ compose.yml อ่านง่ายในระยะยาว ควรจัดลำดับ service อย่างมีโครงสร้าง เช่น

1. วาง service หลักที่ใช้ทุกวันไว้ด้านบน
2. ตามด้วยเครื่องมือสำหรับ dev
3. ตามด้วยเครื่องมือสำหรับ test
4. ใส่คอมเมนต์เท่าที่จำเป็นเพื่อช่วยอธิบายภาพรวม

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

สิ่งที่ควรระวังในการใช้งาน

แม้ Compose Profiles จะเรียบง่าย แต่ก็ควรใช้อย่างพอดี

ข้อควรระวังที่สำคัญ ได้แก่

• อย่าเอา secret ไปผูกไว้ตรง ๆ ใน compose
• อย่าใส่ profile เยอะเกินจนทีมจำไม่ได้
• อย่าแยก service ยิบย่อยเกินไป ถ้ายังไม่มี use case ที่ชัดเจน

หลักคิดสำคัญคือ การใช้ Profiles ควรทำให้ระบบ ใช้ง่ายขึ้น ไม่ใช่ทำให้ซับซ้อนกว่าเดิม

ทำไมแนวคิดนี้จึงช่วยลดปัญหา “รันได้บนเครื่องฉัน”

หนึ่งในปัญหาคลาสสิกของทีมพัฒนาคือแต่ละคนรัน environment ไม่เหมือนกัน บางคนเปิด container เพิ่มเอง บางคนปิดบาง service ไปโดยไม่บอก ทำให้เวลามีปัญหาเกิดขึ้น การเทียบสภาพแวดล้อมกันทำได้ยาก

Compose Profiles ช่วยแก้เรื่องนี้ได้ เพราะทีมสามารถตกลงใช้คำสั่งมาตรฐานร่วมกัน เช่น

• งานพัฒนาใช้ profile dev
• งานทดสอบใช้ profile test

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

สรุป

Docker Compose Profiles เป็นฟีเจอร์เล็ก ๆ ที่ให้ผลลัพธ์ใหญ่กว่าที่หลายคนคาดคิด มันช่วยให้เราเปิดใช้งานเฉพาะ service ที่จำเป็นในแต่ละบริบท ลดความหนักของเครื่อง ลดความสับสนของทีม และทำให้ compose.yml ไฟล์เดียวรองรับหลายรูปแบบการทำงานได้อย่างเป็นระเบียบ

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

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