แปลเรื่อง Infrastructure as Code

หลังจากอ่านบทความเรื่อง Infrastructure as Code ที่ bliki ของคุณ Martin Fowler เป็นอีกหนึ่งแนวคิด และ เทคนิคที่น่าสนใจอย่างมาก สำหรับจัดการ infrastructure ของระบบ ทั้ง server และ network ยิ่งในยุคของ Cloud computing ด้วยแล้วยิ่งน่าสนใจขึ้นมาอีก จึงนำมาแปล และ สรุปไว้นิดหน่อย

Infrastructure as Code คืออะไร ?

เป็นวิธีการสำหรับการกำหนดและสร้าง server และ network ต่าง ๆ ขึ้นมาด้วย source code เป็นงานที่สร้างความเจ็บปวดให้กับการพัฒนาและติดตั้ง software เนื่องจากเรามักจะทำการติดตั้ง และ configuration พวก server และ network แบบ manual เอง !!

ดังนันวิธีการนี้จะช่วยลดปัญหาและความเจ็บปวดลงไปอย่างมาก

โดยการสร้าง environment ต่าง ๆ จะอยู่ใน source code นั่นหมายความว่า เราสามารถทำการตรวจสอบขั้นตอนการทำงานได้ เราสามารถทำการสร้างซ้ำแล้วซ้ำอีกได้ และต้องมีขั้นตอนการทดสอบระบบได้อีกด้วย มันสำคัญมาก ๆ เพราะว่าคนส่วนใหญ่มักละเลย เพื่อทดสอบว่าสิ่งที่สร้างขึ้นมามันถูกต้อง และ ระบบงานทำงานได้ถูกต้องบน environment ที่สร้างขึ้นมาหรือไม่ ? สิ่งต่าง ๆ เหล่านี้มันสนับสนุนแนวคิดของ Continuous Delivery (CD) นั่นเอง โดย Infrastructure ในปัจจุบันนิยมใช้บริการผ่านระบบ Cloud computing ซึ่งเป็นแบบ Dynamic Infrastructure หมายความว่า เราสามารถสร้าง server ด้วยคำสั่งง่าย ๆ ซึ่ง server ที่สร้างขึ้นมามักจะเป็น Virtual Machine (VM) หรือบางครั้งอาจจะเป็นเครื่องจริง ๆ ก็ได้ จากนั้นทำการ configuration และ ติดตั้ง software ต่าง ๆ ที่จำเป็น สุดท้ายสามารถทำลาย server เหล่านี้ได้ตามที่ต้องการ มันก็สะดวกดีนะ แต่ต้องเรียนรู้เพิ่มเติม

แนวปฏิบัติของ Infrastructure as Code เป็นอย่างไร ?

ประกอบไปด้วย

Use definition files

ขั้นตอนการทำงาน และ configuration ต่าง ๆ จะอยู่ในไฟล์ที่สามารถ execute ได้ เช่น shell script, docker file, ansible playbook, chef recipe และ puppet manifest เป็นต้น ดังนั้น ถ้าต้องการเปลี่ยนแปลงขั้นตอนการทำงาน ก็เพียงแก้ไข source code ในไฟล์ต่าง ๆ เหล่านี้เท่านั้น ทำให้สามารถนำ source code เหล่านี้ ไปสร้าง server จำนวนมากได้อย่างง่ายดาย ที่สำคัญมันรวดเร็วกว่าให้คนทำ !!

Self-documented system and processes

ปกติขั้นตอนการสร้าง และ configuration server นั้น มักจะเขียนไว้ในรูปแบบเอกสารต่าง ๆ เช่น Spreadsheet เพื่อเอาไว้ให้คนอ่าน และ ทำตาม ซึ่งคนมักสร้างความผิดพลาดอยู่เสมอ บ่อยครั้งก็ไม่ยอมทำตามเอกสาร !! แต่ถ้าปรับเปลี่ยนมาเขียนขั้นตอนเหล่านั้นด้วย code ทั้งให้คนอ่านง่าย ทั้งให้เครื่องคอมพิวเตอร์อ่านออก และ execute ได้ มันจะกลายเป็นเอกสารที่คนอ่านได้ง่าย แถมให้เครื่องคอมพิวเตอร์ทำงานตาม code เหล่านั้นได้อีกด้วย ชีวิตก็น่าจะดีขึ้นนะ

Version all the things

Source code ต่าง ๆ สำหรับการสร้าง และ configuration server นั้น จะต้องจัดเก็บไว้ใน source control เสมอ เพื่อทำให้เราสามารถจัดการ version รวมทั้งบันทึกการเปลี่ยนแปลงต่าง ๆ ได้ นั่นคือสามารถทำการ audit และ เห็นปัญหาต่าง ๆ ได้ง่ายอีกด้วย

Continuously test systems and processes

สิ่งที่ขาดไปไม่ได้เลย คือ การทดสอบ (Testing) ทำให้เราหาปัญหา และ ข้อผิดพลาดต่าง ๆ จากขั้นตอนการสร้าง และ configuration server ได้อย่างรวดเร็ว โดยขั้นตอนการสร้าง และ ทดสอบนั้น จะอยู่ใน deployment pipeline ของ Continuous Delivery นั่นเอง ดังนั้นถ้ามีการเปลี่ยน source code ต่าง ๆ ของการสร้าง server หรือ configuration ต่าง ๆ แล้ว จะทำการ execute code แบบอัตโนมัติ รวมทั้งทำการทดสอบอีกด้วย

Small changes rather than batches

ถ้าระบบ infrastructure มีขนาดใหญ่แล้ว ลองคิดดูสิว่า ถ้ามีการเปลี่ยนแปลงขึ้นมาแล้ว จะเกิดปัญหามากมายเพียงใด ? จะเกิดข้อผิดพลาดมากมายเพียงใด ? จะใช้เวลามากเท่าไรในการจัดการการเปลี่ยนแปลง ?

ตอบได้เลยว่า มากสุด ๆ

ดังนั้นแนะนำให้เปลี่ยนแนวคิด ด้วยการทำการเปลี่ยนแปลงแบบเล็ก ๆ และ บ่อย ๆ ดีกว่า เพื่อทำให้เราหาข้อผิดพลาดได้ง่าย เพื่อทำให้เราหาข้อผิดพลาดได้เร็ว และทำการแก้ไขได้รวดเร็ว ทั้งการเดินหน้าและถอยหลัง

Keep services availlable continuously

การเปลี่ยนแปลงต่าง ๆ ต้องไม่ส่งผลกระทบต่อการให้บริการของระบบ นั่นคือไม่มี downtime นั่นเอง หรือ ลดให้น้อยที่สุดเท่าที่จะเป็นไปได้ ซึ่งมีเทคนิคต่าง ๆ ให้นำมาใช้งานเช่น

• Blue Green Deployment
• Parallel change

ประโยชน์ที่ได้รับ มีอะไรบ้าง ?

แน่นอนว่าทำให้สามารถสร้างระบบ infrastruture ได้ตามที่ต้องการ รวมทั้งง่ายต่อการแก้ไขทั้งลดและเพิ่มสิ่งต่าง ๆ เข้าไป เช่น การเปลี่ยนแปลง configuration การเพิ่มหรือลดจำนวนเครื่อง server ยังไม่พอนะ เนื่องจากสามารถกำหนดค่าต่าง ๆ ใน source code ทำให้แต่ละเครื่องที่สร้างขึ้นมานั้นเหมือนกัน ทั้งเวอร์ชันของ OS ทั้งเวอร์ชันของ Web server ทั้งเวอร์ชันของ Database ทั้งเรื่องของชุดเครื่องมือ ทั้งเรื่องของ Library และ Framework ทั้งเรื่องของระบบ Monitoring ทั้งเรื่องของระบบ Network ทั้งเรื่องของการทำงานร่วมกันของส่วนต่าง ๆ ที่สำคัญยังช่วยลดความเสี่ยงต่าง ๆ ลงไปมากอีกด้วย ซึ่งมันเป็นปัญหาหลักของการสร้างเครื่องแบบ manual หรือให้คนทำ เมื่อเกิดปัญหาแล้ว หาสาเหตุได้ยากมาก ๆ ทั้งหมดทั้งมวล ก็เพื่อทำให้เราสามารถจัดการ server ที่เพิ่มขึ้นเป็นจำนวนมากได้ง่าย และ สะดวกขึ้น จากสถาปัตยกรรม Microservice ที่กำลังได้รับความนิยม

วันนี้เราพร้อมแล้วหรือยัง ?

สุดท้ายไปอ่านเพิ่มจากหนังสือ Infrastructure as Code