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