ช่วงหลังไปงาน meetup มักจะได้ยินคำแปลก ๆ ใหม่ ๆ เยอะมาก
หนึ่งในนั้นก็คือ Blue-Green Deployment จาก Docker Meetup
ดังนั้น มาทำความรู้จักกันหน่อยสิ
ว่ามันคืออะไร ?
ว่ามันมีขั้นตอนการทำงานอย่างไร ?
ว่ามันมีประโยชน์อย่างไรบ้าง ?
มาดูรูปแบบการ deploy และ release ระบบงาน แบบเดิม ๆ กันก่อน
เมื่อต้องการ deploy ระบบงานใหม่ ๆ ขึ้นไปยัง production server
มักจะมีขั้นตอนดังนี้
- ต้องหยุดให้บริการระบบงานเดิมก่อน นั่นคือต้องปิดระบบกันก่อน
- ทำการ deploy ระบบงานใหม่ขึ้นไป
- ต้องทำการทดสอบภายในกันก่อน ว่าทำงานถูกต้องหรือไม่ ถ้าระบบซับซ้อนก็ใช้เวลานานหน่อย
- เมื่อทุกอย่างพร้อม ก็เปิดใช้งานระบบกันเลย (Release)
สิ่งที่เราจะได้รับจากวิธีการนี้คือ เวลา Downtime นั่นเอง
เราพยายามที่จะปรับปรุงขั้นตอนการ deploy ให้ใช้เวลาน้อยสุด ๆ
แต่อย่างไรก็ตามในโลกของระบบงานที่เป็น Monolithic
หรือทุกอย่างของระบบรวมกันอยู่ที่เดียวกันแบบใหญ่ ๆ
ก็ต้องพบปัญหา Downtime เป็นปกติ แถมหนักขึ้นทุกวันไปอีก
เนื่องจากระบบมีความซับซ้อนขึ้นในทุก ๆ วัน
ดังนั้นจึงมีแนวคิดในการ deploy งานแบบใหม่ ๆ ขึ้นมา
เพื่อลดเวลา Downtime ของการ deploy ลงไป
นั่นก็คือ Blue-Green Deployment
มาดูแนวคิดของ Blue-Green Deployment
เป็นแนวคิดที่เรียบง่ายมากคือ
เมื่อต้องการ deploy ระบบงานใหม่ ๆ ก็ไม่ต้องปิดระบบเดิม
ก็ปล่อยให้ระบบเดิมทำงานไป
และทำการ deploy ระบบใหม่ขึ้นไปแบบขนานเลย
โดยที่
- Blue คือ ระบบเดิม หรือ New Green
- Green คือ ระบบใหม่
แสดงดังรูป
จะสังเกตุได้ว่า พวก service หรือระบบงานต่าง ๆ
ต้องถูกกั้นด้วย proxy/router/load balance ซะ
เพื่อง่ายต่อการปรับเปลี่ยนการใช้งาน service ต่าง ๆ
โดยข้อดีของวิธีการนี้ประกอบไปด้วย
- ลดเวลา Downtime
- ลดความเสี่ยงในการ deploy
- สามารถทดสอบได้นานเท่าที่ต้องการจนกว่าจะมั่นใจ
แต่สิ่งที่ตามมา และ สิ่งที่ต้องปรับปรุง ก็มีเยอะเช่นกัน ตัวอย่างเช่น
- Environment ของระบบที่เพิ่มขึ้น
- กระบวนการทดสอบระบบที่รวดเร็วขึ้น เช่น Automated testing
- การออกแบบ service ในรูปแบบของ Microservice และ SOA เป็นต้น เพื่อให้แต่ละ service แยกออกจากกันอย่างชัดเจน เพื่อลดความซับซ้อนของระบบ และ ผลกระทบต่าง ๆ
ยิ่งในปัจจุบันมีทั้ง VM และ Docker ก็ยิ่งทำให้
การ deploy ระบบแบบ Blue-Green Deployment ทำได้ง่าย และ สะดวกมากยิ่งขึ้น
สิ่งที่น่าสนใจ และ สำคัญมาก ๆ คือ Database
บ่อยครั้งเราต้องการ update โครงสร้างของ database ทั้ง 2 version
ปัญหามักจะเกิดจากการ deploy และ release แต่ละครั้งนานจนเกินไป
ทำการทั้ง 2 version แตกต่างกันมากไป
และนั่นก็คือ ปัญหาใหญ่ !!
ดังนั้น การแก้ไขที่ง่าย และ ดีมาก ๆ คือ
ให้ทำการ deploy และ release database บ่อย ๆ สิ
จะทำให้เราสามารถดูแลและจัดการการเปลี่ยนแปลงของ database ได้ง่ายมากขึ้น
จำไว้เลยว่า ยิ่งเวลาแต่ละ deploy แต่ละ release
บ่อย ๆ ก็ยิ่งดีครับ
ปิดท้ายด้วย ขั้นตอนการทำงานของ Blue-Green Deployment
โดยใช้ตัวอย่างของ Microservice
ซึ่งถูกบรรจุไว้ใน container
มีขั้นตอนการทำงานดังนี้
1. เริ่มจากระบบการทำงานของระบบปัจจุบัน จะเรียกว่า Blue
ซึ่ง traffic การใช้งานจะผ่าน Proxy เสมอ
แสดงดังรูป
2. เมื่อต้องการ deploy ระบบใหม่ หรือเรียกว่า Green
จะทำการ deploy ระบบใหม่ขึ้นมาให้ทำงานแบบขนานกับของเดิมไปเลย
ซึ่งต้องทดสอบด้วยว่า ต้องไม่มีการใช้งานจากที่อื่นนะ
แน่นอนว่า ต้องไม่ส่งผลกระทบต่อระบบเดิมด้วย
แสดงดังรูป
3. เมื่อทดสอบระบบใหม่จนมั่นใจแล้ว ก็จะทำการ release ระบบงาน
ด้วยการเปลี่ยน configuration ที่ Proxy
เพื่อให้ traffic การใช้งานมายังระบบใหม่
แสดงดังรูป
4. เมื่อทุกอย่างเรียบร้อยก็ทำการ stop การทำงานของระบบเก่า หรือ ลบไปซะ
บางครั้งอาจจะยังไม่ลบออกไป
เนื่องจากเผื่อเอาไว้ใช้ rollback
เมื่อระบบใหม่ทำงานผิดพลาด
แสดงดังรูป
นี่คือความรู้พื้นฐานสำหรับการ deploy ระบบงานแบบ Blue-Green Deployment
น่าจะพอมีประโยชน์บ้างสำหรับการพัฒนา software
ซึ่ง Deployment != Release นะครับ
Reference Websites
http://technologyconversations.com/2016/02/08/blue-green-deployment/
https://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html
http://martinfowler.com/bliki/BlueGreenDeployment.html
