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

infrastructure-as-code-01

นั่นหมายความว่า
เราสามารถทำการตรวจสอบขั้นตอนการทำงานได้
เราสามารถทำการสร้างซ้ำแล้วซ้ำอีกได้
และต้องมีขั้นตอนการทดสอบระบบได้อีกด้วย
มันสำคัญมาก ๆ เพราะว่าคนส่วนใหญ่มักละเลย
เพื่อทดสอบว่าสิ่งที่สร้างขึ้นมามันถูกต้อง
และ ระบบงานทำงานได้ถูกต้องบน 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

newrules