ใช้ Check Mode และ Diff Mode ตรวจ Playbook ก่อนรันจริง

check mode ประเมินการเปลี่ยนแปลงโดยไม่แก้เครื่อง และ diff mode แสดงรายละเอียดที่อาจเปลี่ยน เหมาะกับงานเปลี่ยน config จำนวนมากหรือการทบทวน pull request ด้าน infrastructure บทความนี้สรุปแนวคิดจากเอกสารทางการของ Ansible และจุดที่ควรตรวจเมื่อนำไปใช้จริง

ภาพรวม

Ansible ใช้ inventory และ playbook เพื่อจัดการเครื่องปลายทาง การรันซ้ำและตรวจว่าเครื่องเปลี่ยนจริงหรือไม่เป็นส่วนสำคัญของ automation

หัวข้อนี้ตอบโจทย์เฉพาะเรื่อง: check mode ประเมินการเปลี่ยนแปลงโดยไม่แก้เครื่อง และ diff mode แสดงรายละเอียดที่อาจเปลี่ยน จึงควรเริ่มจากปัญหาที่ต้องแก้และผลลัพธ์ที่คาดหวัง ไม่ใช่เพียงเปิดฟีเจอร์เพราะมีอยู่ในเครื่องมือ

หลักการทำงาน

ผู้ดูแลใช้ผลจำลองเพื่อตรวจขอบเขตของ playbook ก่อนกระทบ production

ให้ตรวจทั้งสถานะที่เครื่องมือรายงานและผลลัพธ์ปลายทางที่ผู้ใช้หรือระบบอื่นได้รับ หากสองส่วนไม่ตรงกัน ควรกลับไปตรวจค่าตั้งต้นและขอบเขตที่ฟีเจอร์นี้รับผิดชอบก่อนเปลี่ยนค่าเพิ่มเติม

เหมาะกับงานแบบไหน

เหมาะกับงานเปลี่ยน config จำนวนมากหรือการทบทวน pull request ด้าน infrastructure

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

ขั้นตอนนำไปใช้

1. จำกัด inventory ให้เป็นกลุ่มเครื่องทดลอง
2. ใช้ check mode เมื่อ module รองรับ แล้วอ่าน diff ก่อนรันจริง
3. รันซ้ำเพื่อตรวจว่า task ไม่เปลี่ยนเครื่องโดยไม่จำเป็น

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

ข้อควรระวัง

บาง module ไม่รองรับ check mode สมบูรณ์ และ diff อาจเผยข้อมูลลับได้

แปลงข้อควรระวังนี้เป็นรายการตรวจในการทบทวนงาน เพราะปัญหาจากค่าตั้งต้นอาจไม่แสดงทันทีในสภาพแวดล้อมทดสอบ

สรุป

check mode ประเมินการเปลี่ยนแปลงโดยไม่แก้เครื่อง และ diff mode แสดงรายละเอียดที่อาจเปลี่ยน เหมาะกับงานเปลี่ยน config จำนวนมากหรือการทบทวน pull request ด้าน infrastructure ก่อนนำไปใช้กับงานหลัก ควรตรวจผลตามขั้นตอนข้างต้นและทบทวนข้อจำกัดของระบบที่มีอยู่

อ่านเพิ่มเติม: เอกสารทางการของ Ansible