ใช้ tmux ทำงาน Deploy และ Debug ผ่าน SSH โดยไม่เสีย Session
แบ่ง pane ดู log รันคำสั่ง และสลับงานใน session เดียว พร้อม reconnect กลับมาทำต่อได้เมื่อ SSH หลุด ช่วยลดความเสี่ยงระหว่างดูแล production
ภาพรวม
tmux กับงาน Deploy และ Debug: ดู log ไปพร้อมกับรันคำสั่งโดยไม่ต้องเปิดหลาย SSH
เวลาระบบเริ่มมีอาการแปลกตอน deploy หลายคนจะเปิด SSH สองหรือสามหน้าต่าง หน้าต่างหนึ่ง tail log อีกหน้าต่างรัน migration อีกหน้าต่างเช็ก service หรือ curl health check
วิธีนี้ทำได้ แต่พอสลับหน้าต่างบ่อย ๆ เราจะเริ่มหลงว่า command ไหนกำลังรันอยู่ และที่แย่กว่าคืออาจปิด terminal ผิดบาน แล้วตัดงาน deploy ที่ยังไม่เสร็จ 😅
tmux ช่วยเปลี่ยน SSH หนึ่งการเชื่อมต่อให้เป็นพื้นที่ทำงานหลายส่วน เราแบ่งหน้าจอเป็น pane ได้ แต่ละ pane รันคำสั่งของตัวเอง และยังมองเห็นทุกอย่างพร้อมกัน
เริ่มจากเข้าเครื่องแล้วสร้าง session ที่ตั้งชื่อให้จำง่าย
tmux new -s deploy
ชื่อ session สำคัญกว่าที่คิด
ถ้าทีมมีหลายระบบ ลองใช้ชื่อแบบ deploy-api หรือ debug-worker
พอกลับมาในภายหลังจะรู้ทันทีว่า session นี้ทำงานอะไรอยู่
เมื่ออยู่ใน tmux แล้ว ให้แบ่ง pane แนวตั้งด้วย Ctrl-b %
หรือแบ่งแนวนอนด้วย Ctrl-b "
โดย Ctrl-b คือปุ่มนำคำสั่งของ tmux ไม่ใช่ต้องกดพร้อมกันทั้งหมด
ให้กด Ctrl-b ปล่อยมือ แล้วกดปุ่มถัดไป
ตัวอย่าง layout ที่ใช้ได้จริงระหว่าง deploy pane ซ้าย: รันคำสั่ง deploy หรือเปิด SSH ไปยังเครื่องหลัก pane ขวาบน: ดู application log แบบต่อเนื่อง pane ขวาล่าง: เช็กสถานะ service, container หรือ health endpoint
ใน pane สำหรับ log อาจใช้คำสั่งนี้
tail -f /var/log/myapp/app.log
ถ้าใช้ systemd ก็ใช้
journalctl -u myapp -f
ข้อดีของการวาง log ไว้ข้าง ๆ คือไม่ต้องเดาว่า deploy ผ่านหรือไม่ ทันทีที่รัน migration, restart service หรือสลับ release เราจะเห็น error, warning และข้อความ start สำเร็จในจังหวะเดียวกัน
pane สำหรับ deploy อาจรันตามลำดับ เช่น
git pull
npm ci
npm run build
npm run migrate
sudo systemctl restart myapp
ระหว่างคำสั่งเหล่านี้ทำงาน อย่าเพิ่งตีความแค่ exit code ว่า “จบแล้วปลอดภัย” ให้มอง log ประกอบเสมอ บางระบบ restart สำเร็จ แต่ process ล่มตามหลังเพราะ environment variable หาย หรือ migration ผ่าน แต่แอป query column ใหม่ก่อน replica จะพร้อม
ถ้าต้องสลับ pane ใช้ Ctrl-b แล้วตามด้วยปุ่มลูกศร
พยายามจัดตำแหน่งให้ pane log อยู่จุดเดิมทุกครั้ง
กล้ามเนื้อจำตำแหน่งได้ และช่วยให้ช่วง incident ทำงานเร็วขึ้นมาก
เคล็ดลับที่มีประโยชน์คือเปิด pane เพิ่มสำหรับ watch สถานะ
เช่น watch -n 2 'systemctl status myapp --no-pager'
หรือใช้ watch -n 2 'curl -fsS http://localhost:3000/health'
เมื่อมี log, คำสั่ง deploy และ health check บนจอเดียวกัน เราจะเห็นความสัมพันธ์ของเหตุการณ์ชัดขึ้น restart ตอน 14:05 แล้ว health check เริ่ม fail ตอน 14:05:03 log ใน pane ข้างกันอาจบอกตรง ๆ ว่าเชื่อมฐานข้อมูลไม่ได้
สำหรับ Docker ลองแยก pane เป็น
docker compose logs -f api
docker compose ps
และ pane ที่ใช้รัน docker compose up -d --build
อย่าดู log ของทุก container แบบกว้างเกินไปในช่วง debug เลือก service ที่เกี่ยวข้องก่อน เช่น api, worker หรือ nginx เพราะ log ที่ไหลเร็วเกินจะกลบ error สำคัญ และทำให้การไล่เหตุช้าลง
อีกความสามารถที่ทำให้ tmux เหมาะกับ server คือ detach session
ถ้าเน็ตหลุดหรือปิด laptop ไม่จำเป็นต้องให้ process ใน tmux หยุดตาม
กด Ctrl-b d เพื่อออกจาก session โดยปล่อยงานไว้บนเครื่องปลายทาง
กลับเข้ามาภายหลังด้วย
tmux attach -t deploy
หรือดูรายการ session ก่อนด้วย
tmux ls
แต่คำว่า detach ไม่ได้แปลว่าปลอดภัยโดยอัตโนมัติ ก่อนปล่อย session ควรบอกทีมว่ามี command อะไรกำลังทำงานอยู่ โดยเฉพาะ migration, backup, restore หรือ deploy ที่อาจกระทบผู้ใช้
ถ้าทำงานคู่กับคนอื่น อย่าแชร์ session แบบไร้ข้อตกลง กำหนดให้ชัดว่าใครเป็นคนรันคำสั่งที่มีผลต่อ production ส่วนอีกคนอาจทำหน้าที่อ่าน log, จดเวลา และตรวจ health check
แนวคิดนี้ช่วยลดการพิมพ์คำสั่งซ้ำซ้อน และลดโอกาสที่ทุกคนจะ “แก้พร้อมกัน” จนตามไม่ทันว่าอะไรทำให้ระบบเปลี่ยน
ก่อน deploy จริง ลองสร้าง layout เดียวกันใน staging ให้เป็นนิสัย ถ้ารู้ล่วงหน้าว่า log อยู่ pane ไหน และคำสั่ง rollback อยู่ตรงไหน ตอน production มีปัญหาจะไม่ต้องเสียเวลาจัดหน้าจอใหม่
อาจเตรียม pane สำหรับ rollback ไว้ แต่ยังไม่กด Enter เช่นคำสั่งสลับ release กลับ, restart เวอร์ชันเดิม หรือ scale service กลับค่าเดิม การเตรียมไว้ไม่ใช่การมองโลกแย่ แต่คือการลดเวลาตัดสินใจเมื่อสัญญาณผิดปกติมาเร็ว
tmux ไม่ได้ทำให้ deploy ปลอดภัยแทน pipeline, monitoring หรือ approval process แต่มันทำให้คนที่กำลังรับผิดชอบเหตุการณ์เห็นข้อมูลสำคัญพร้อมกันมากขึ้น
เริ่มจาก session เดียว แบ่งสาม pane และตั้งชื่อให้ดี เมื่อชินแล้ว SSH หนึ่งหน้าต่างจะกลายเป็น command center เล็ก ๆ ที่ช่วยให้ deploy และ debug อย่างมีสติ ไม่ต้องสลับหน้าจอจนพลาดรายละเอียดสำคัญ 🛠️
แนวทางนำไปใช้
- นำแนวคิดจากโพสต์นี้ไปทดลองกับงานจริงของคุณ
- แยกเป็นขั้นตอนเล็ก ๆ แล้วทำทีละส่วน
- บันทึกผลลัพธ์และสิ่งที่เรียนรู้เพื่อต่อยอด
สรุป
แบ่ง pane ดู log รันคำสั่ง และสลับงานใน session เดียว พร้อม reconnect กลับมาทำต่อได้เมื่อ SSH หลุด ช่วยลดความเสี่ยงระหว่างดูแล production