ทำไม AI Coding Agent ไม่ควรแตะต้อง Dockerfiles ของคุณ
เจาะลึกปัญหาเมื่อ AI แก้ไข Dockerfile และไฟล์ที่สร้างอัตโนมัติ พร้อมแนวทางป้องกันด้วยเครื่องมือ Flisk ที่ช่วยควบคุมระบบโครงสร้างพื้นฐาน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- AI Coding Agent มักสร้างปัญหาโดยการแก้ไขไฟล์ Dockerfile หรือไฟล์ที่ถูกสร้างอัตโนมัติโดยไม่เข้าใจบริบทที่แท้จริง
- เครื่องมือ Flisk ช่วยจัดการโครงสร้างบริการผ่าน service.json และบล็อกการสตาร์ทระบบหากพบว่าไฟล์ที่สร้างถูกแก้ไขด้วยมือ
- การแก้ปัญหาที่ถูกต้องคือให้แก้ไขที่ไฟล์ต้นทางอย่าง service.json แล้วปล่อยให้ระบบจัดการสร้างไฟล์ที่เหลือขึ้นใหม่
- ควรแยกโค้ดแอปพลิเคชันออกจากสภาพแวดล้อมจำลองการพัฒนาในเครื่อง เพื่อไม่ให้ระบบผูกติดกับโครงสร้างทดสอบ
การปล่อยให้ AI Coding Agent เข้ามามีส่วนร่วมในการเขียนโค้ดและจัดการไฟล์ระบบ อาจเทียบได้กับการปล่อยให้ฝึกงานช่วยแก้เอกสารวิกิ ที่มักจะทำด้วยความมั่นใจ ทำในเครื่องตัวเอง และไม่มีความทรงจำหลงเหลืออยู่เลยว่าคนก่อนหน้าเคยทำอะไรไว้บ้าง สิ่งนี้อาจไม่ใช่ปัญหาใหญ่ในที่เก็บโค้ดขนาดเล็กที่มีเพียงสามบริการ แต่จะกลายเป็นอุบัติเหตุที่เกิดขึ้นอย่างช้าๆ ในระบบที่มีสถาปัตยกรรมซับซ้อน เช่นเดียวกับ Flisk ที่มีไฟล์ Dockerfile ถึงสองชุดในระบบ แต่คำสั่ง flisk up จะทำการบิลด์เพียงแค่ไฟล์เดียวเท่านั้น
หาก AI agent ของคุณไม่สามารถแยกแยะความแตกต่างระหว่างไฟล์ทั้งสองนี้ได้ มันก็ไม่ควรได้รับอนุญาตให้แตะต้องไฟล์ใดเลยทั้งสิ้น ตัว Dockerfile ตัวหนึ่งนั้นไม่สามารถบิลด์บนแล็ปท็อปหรือในระบบ CI ที่ยังไม่ได้ทำการบิลด์เลเยอร์พื้นฐานมาก่อนได้ โดยขั้นตอนสุดท้ายจะรันภายใต้ผู้ใช้ bun แท็กสำหรับรันในเครื่องคือ shop_orders-api:dev ในขณะที่เป้าหมายสำหรับการพัฒนาและโปรดักชันในไฟล์นั้นคือสเตจเดียวกัน ซึ่งเป็นอิมเมจที่ใช้ภายในเครื่องเท่านั้น
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
นอกจากนี้ Flisk ยังทำการสร้างไฟล์ Dockerfile แบบธรรมดาควบคู่ไปกับไฟล์ service.json อีกด้วย พร้อมทั้งมีคอมเมนต์ระบุไว้อย่างชัดเจน แต่คำสั่ง flisk up จะไม่นำไฟล์นี้ไปใช้งาน โดยค่าพอร์ต (PORT), การเปิดพอร์ต (EXPOSE) และเส้นทางตรวจสอบสุขภาพระบบ (health check) จะอ้างอิงตามค่าพอร์ตในไฟล์ service.json เท่านั้น หากปล่อยให้ AI เข้ามาทำความสะอาดไฟล์ มันอาจเผลอนำค่าพอร์ตที่ไม่ตรงกันกลับเข้ามาจนสร้างความเสียหายได้
ในความเป็นจริง AI มีความเก่งกาจในส่วนที่อยู่ภายในคอนเทนเนอร์ เช่น การเขียนฟังก์ชันจัดการคำขอ การเขียนคิวรี่ การแก้ไขเทสต์ที่พัง หรือการเรียกใช้เครื่องมือต่างๆ แต่มันมักจะทำได้ไม่ดีในส่วนที่อยู่รอบๆ คอนเทนเนอร์ เนื่องจากสิ่งเหล่านั้นจำเป็นต้องมีความสอดคล้องกันในทุกๆ บริการของระบบ
การทำงานร่วมกับ AI Agent ในงานโครงสร้างพื้นฐาน (Infrastructure) มักมีความเสี่ยงสูงเนื่องจาก AI ขาดภาพรวมระดับระบบ (System-wide context) มันมองเห็นเฉพาะไฟล์ที่เปิดอยู่ตรงหน้าและพยายามแก้ไขให้สำเร็จลุล่วงโดยไม่รู้ว่าการเปลี่ยนแปลงนั้นจะไปกระทบกับการตั้งค่าในส่วนอื่น เช่น ไฟล์คอนฟิกของ Helm หรือไฟล์สแนปชอตเบื้องหลัง การจำกัดสิทธิ์ของ AI ไม่ให้เข้าถึงไฟล์คอนฟิกหลักจึงเป็นหัวใจสำคัญในการรักษาความเสถียรของระบบ
การแก้ไขข้อผิดพลาดในลักษณะนี้ถือเป็นเรื่องน่าเบื่อแต่จำเป็นอย่างยิ่ง วิธีการที่ถูกต้องคือให้นำการเปลี่ยนแปลงที่ต้องการไปใส่ไว้ในไฟล์ service.json จากนั้นรันคำสั่ง flisk up เพื่อให้ระบบทำการสร้างไฟล์เอาต์พุตขึ้นใหม่ทั้งหมด หากไฟล์บริการถูกแก้ไขด้วยมือ ระบบจะทำการบล็อกการทำงานต่อไปจนกว่าการแก้ไขนั้นจะถูกถอดถอนออกไป หรือทำการข้ามผ่านกระบวนการดังกล่าวโดยการตัดสินใจของมนุษย์เท่านั้น
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น