เขียน Ansible Playbook ให้รันซ้ำแล้วได้ผลเดิม
playbook บรรยายสถานะที่ต้องการของระบบเป็น task และ module อธิบายหลักการใช้งาน กรณีที่เหมาะ และข้อควรระวังจากเอกสารทางการ
playbook บรรยายสถานะที่ต้องการของระบบเป็น task และ module เหมาะกับการตั้งค่าเซิร์ฟเวอร์จำนวนมากและต้องรันซ้ำอย่างมั่นใจ บทความนี้สรุปแนวคิดจากเอกสารทางการของ Ansible และจุดที่ควรตรวจเมื่อนำไปใช้จริง
ภาพรวม
Ansible ใช้ inventory และ playbook เพื่อจัดการเครื่องปลายทาง การรันซ้ำและตรวจว่าเครื่องเปลี่ยนจริงหรือไม่เป็นส่วนสำคัญของ automation
หัวข้อนี้ตอบโจทย์เฉพาะเรื่อง: playbook บรรยายสถานะที่ต้องการของระบบเป็น task และ module จึงควรเริ่มจากปัญหาที่ต้องแก้และผลลัพธ์ที่คาดหวัง ไม่ใช่เพียงเปิดฟีเจอร์เพราะมีอยู่ในเครื่องมือ
หลักการทำงาน
module ตรวจสภาพก่อนเปลี่ยน ทำให้การรันครั้งถัดไปไม่ต้องแก้สิ่งที่ตรงตามเป้าหมายแล้ว
ให้ตรวจทั้งสถานะที่เครื่องมือรายงานและผลลัพธ์ปลายทางที่ผู้ใช้หรือระบบอื่นได้รับ หากสองส่วนไม่ตรงกัน ควรกลับไปตรวจค่าตั้งต้นและขอบเขตที่ฟีเจอร์นี้รับผิดชอบก่อนเปลี่ยนค่าเพิ่มเติม
เหมาะกับงานแบบไหน
เหมาะกับการตั้งค่าเซิร์ฟเวอร์จำนวนมากและต้องรันซ้ำอย่างมั่นใจ
ก่อนทดลอง ให้ระบุสิ่งที่จะใช้วัดผล เช่น เวลาตอบสนอง ความพร้อมใช้งาน ความถูกต้องของข้อมูล หรือภาระการดูแล แล้วเทียบกับสภาพเดิม วิธีนี้ช่วยให้รู้ว่าฟีเจอร์แก้ปัญหาจริงหรือย้ายภาระไปอีกจุดหนึ่ง
ขั้นตอนนำไปใช้
- จำกัด inventory ให้เป็นกลุ่มเครื่องทดลอง
- ใช้ check mode เมื่อ module รองรับ แล้วอ่าน diff ก่อนรันจริง
- รันซ้ำเพื่อตรวจว่า task ไม่เปลี่ยนเครื่องโดยไม่จำเป็น
เริ่มจากขอบเขตเล็กและเก็บผลทดสอบไว้กับการเปลี่ยนแปลง หากจะใช้ใน production ให้กำหนดผู้ติดตามผลและเงื่อนไขที่จะหยุดการขยายการใช้งาน
ข้อควรระวัง
คำสั่ง shell ที่เขียนเองอาจไม่ idempotent ต้องกำหนดเงื่อนไขและตรวจ changed ให้ถูก
แปลงข้อควรระวังนี้เป็นรายการตรวจในการทบทวนงาน เพราะปัญหาจากค่าตั้งต้นอาจไม่แสดงทันทีในสภาพแวดล้อมทดสอบ
สรุป
playbook บรรยายสถานะที่ต้องการของระบบเป็น task และ module เหมาะกับการตั้งค่าเซิร์ฟเวอร์จำนวนมากและต้องรันซ้ำอย่างมั่นใจ ก่อนนำไปใช้กับงานหลัก ควรตรวจผลตามขั้นตอนข้างต้นและทบทวนข้อจำกัดของระบบที่มีอยู่
อ่านเพิ่มเติม: เอกสารทางการของ Ansible