1 คะแนน โดย GN⁺ 2025-02-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • VSCode และการแก้ไขงานจากระยะไกล

    • VSCode มีความสามารถรองรับการแก้ไขงานจากระยะไกลผ่าน SSH
    • ผู้ใช้จำนวนมากใช้ VSCode ร่วมกับ LLM (โมเดลภาษาขนาดใหญ่) เพื่อสร้างโค้ด
    • เมื่อ LLM สร้างโค้ดผิดพลาด กรณีนี้เรียกว่า "หลอน" และเพื่อแก้ปัญหานี้ การปิดลูประหว่าง LLM กับสภาพแวดล้อมการรันผ่านการตั้งค่า "เอเจนต์" จึงเป็นสิ่งสำคัญ
    • กระบวนการนี้ทำงานโดยให้ LLM สร้างโค้ด จากนั้นเอเจนต์นำโค้ดไปรัน สร้างข้อผิดพลาด แล้วส่งผลย้อนกลับให้ LLM เพื่อทำซ้ำต่อไป
  • ปัญหาในสภาพแวดล้อมการพัฒนา

    • ไม่ใช่เรื่องที่พึงประสงค์นักหากกระบวนการพัฒนาแบบวนซ้ำเช่นนี้เกิดขึ้นบนแล็ปท็อปของนักพัฒนา
    • เนื่องจาก LLM อาจส่งผลต่อการตั้งค่าระบบได้ จึงควรทำงานลักษณะนี้บน Linux instance ที่อยู่ในสภาพสะอาด
  • Emacs และ Tramp

    • Emacs รองรับระบบแก้ไขงานจากระยะไกลผ่าน Elisp ที่มีประโยชน์ชื่อ Tramp
    • Tramp สามารถเชื่อมต่อกับสภาพแวดล้อมแบบโต้ตอบที่รันคำสั่ง Bourne shell ผ่าน SSH session ได้
  • แนวทางของ VSCode

    • VSCode มีความสามารถคล้าย Tramp แต่ต่างจาก Tramp ตรงที่พยายามแทรกตัวเข้าไปอย่างลึกในฝั่งรีโมต
    • มันรัน Bash snippet stager เพื่อดาวน์โหลดเอเจนต์ และรวมถึงการติดตั้งไบนารีของ Node
    • เอเจนต์จะทำงานผ่าน SSH ที่มีการทำ port forwarding และเชื่อมต่อกับฟรอนต์เอนด์ของ VSCode ผ่านการเชื่อมต่อ WebSockets
    • โปรโตคอลพื้นฐานของการเชื่อมต่อนี้สามารถท่องระบบไฟล์ แก้ไขไฟล์ใดก็ได้ตามต้องการ เริ่มต้น shell PTY process ของตัวเอง และคงอยู่ต่อเนื่องได้
  • ข้อกังวลด้านความปลอดภัย

    • การใช้ VSCode เพื่อแก้ไขงานจากระยะไกลบนเซิร์ฟเวอร์พัฒนาอย่างไม่ระมัดระวัง อาจก่อปัญหาต่อข้อมูลอ่อนไหวหรือการปกป้องโครงสร้างพื้นฐานได้
    • โดยเฉพาะเมื่อเกิดปัญหาในสภาพแวดล้อมใช้งานจริง (production) ก็มีความกังวลว่าการใช้ VSCode remote editing จะมีความเสี่ยงสูงมาก
  • บทสรุป

    • ภายใน Fly.io เอง วิธีซับซ้อนแบบนี้ที่ใช้เอเจนต์อาจไม่จำเป็นเสมอไปสำหรับการเชื่อมต่อ Fly Machine กับ VSCode โดยตรง
    • อย่างไรก็ตาม ผู้เขียนได้มาศึกษาวิธีการเชื่อมต่อระยะไกลของ VSCode เพื่อจุดประสงค์ในการเขียนบล็อก และระหว่างการสำรวจก็พบข้อเท็จจริงตามที่กล่าวมาข้างต้น

1 ความคิดเห็น

 
GN⁺ 2025-02-09
ความคิดเห็นใน Hacker News
  • ตลอดหนึ่งเดือนที่ผ่านมาอยากเขียนบทความยาวเกี่ยวกับซอฟต์แวร์ Kurt ก็กังวลว่าไม่ได้เขียนบล็อก เลยตัดสินใจว่าจะเขียนอะไรสั้น ๆ คิดว่าน่าจะเขียนเสร็จได้ภายใน 30 นาที

    • จึงเขียนสั้น ๆ เกี่ยวกับซอฟต์แวร์ที่เรากำลังจัดการอยู่
  • ยิ่งรู้ว่า VSCode ทำงานอย่างไร ก็ยิ่งรู้สึกว่าเหมือนยังประคองอยู่ด้วยวิธีแก้ขัด แค่ดูส่วนขยาย SSH ก็จะเห็นว่า workspace URI มีอยู่สองรูปแบบ

    • มีชื่อโฮสต์กับเอกสาร JSON ที่เข้ารหัสเป็นเลขฐานสิบหก
    • ถ้าชื่อโฮสต์มีตัวพิมพ์ใหญ่ ก็ต้องมีข้อมูลเพิ่มเติม
    • การเชื่อมต่อ SSH สามารถตั้งค่าส่วนขยายที่จะติดตั้งบนเซิร์ฟเวอร์ได้ แต่ถ้าติดตั้งมากเกินไปจะเชื่อมต่อกับโฮสต์ Windows ไม่ได้
  • ผมไม่เข้าใจประเด็นด้านความปลอดภัย ถ้าสามารถเข้าเครื่องผ่าน SSH และทำ socket forwarding ได้ ก็น่าจะทำอย่างอื่นได้ด้วย

    • เลยสงสัยว่าปัญหาคือคนอื่นในเครือข่ายเดียวกันสามารถเชื่อมต่อพอร์ตที่ถูก forward ไว้ได้โดยไม่ต้องใช้ SSH หรือไม่
    • ในฐานะผู้ใช้ ผมชอบที่ระบบ SSH ของ VSCode ทำงานได้ดี
  • ผมดูแลเซิร์ฟเวอร์เครือข่าย และปัญหาใหญ่คือเหล่านักศึกษาไม่เข้าใจ OpenSSH client

    • ผมแจ้งนักศึกษาว่าอย่าใช้ปลั๊กอิน remote server ของ VSCode
    • นักศึกษาที่ใช้ดิสก์เกิน 100MB ทุกคนล้วนเป็นผู้ใช้ VSCode
    • ผมตั้งลิมิตโปรเซสต่อผู้ใช้ไว้ที่ 45 ถ้านักศึกษาเมินคำเตือนก็จะชนลิมิตโปรเซส
    • ผมใช้สคริปต์ที่คอยปิดโปรเซส .vscode-server ทุก ๆ 10 วินาที
  • ฟีเจอร์แก้ไขผ่าน SSH ของ VSCode ทำงานได้ดีมาก เลยไม่ต้องใช้ vim, nano, micro บนเครื่องระยะไกลอีก

    • เอเจนต์ไม่มารบกวน ทำให้งานลื่นขึ้น
    • อาจมีความเสี่ยงด้านความปลอดภัย แต่ประสบการณ์การพัฒนานั้นยอดเยี่ยม
  • ผมได้เรียนรู้ว่ามันสามารถรันโค้ดจากระยะไกลได้ ความไว้ใจผิด ๆ ต่อเครื่องมือพัฒนามักนำไปสู่ความเสียใจภายหลัง

    • SSH เป็นโซลูชันจากยุค 90 เป็นเหมือน Telnet ที่เพิ่มฟีเจอร์เข้าไปเล็กน้อย
    • หลายสิ่งที่สร้างผ่าน SSH นั้นไม่มีประสิทธิภาพ
    • เราไม่ได้สร้างเครื่องมือที่เหมาะสม แต่กลับเติมฟีเจอร์เพิ่มเข้าไปในเครื่องมือเดิม
  • คำว่า "SSH agent" ทำให้งง เพราะปกติจะหมายถึงเดมอนที่แคชโทเคนสำหรับยืนยันตัวตน

  • คนที่แนะนำ sshfs นั้นไม่เข้าใจข้อดีของสภาพแวดล้อม VSCode SSH Remote

    • มันทำให้รันสภาพแวดล้อมการพัฒนาทั้งหมดจากระยะไกลได้เหมือนเป็นเครื่องโลคัล
    • สามารถเปลี่ยนเครื่องเก่าหรือ thin client ให้กลายเป็นเวิร์กสเตชันเต็มรูปแบบได้
    • ใน VSCode Marketplace มีปลั๊กอินจำนวนมากที่เป็นภัยด้านความปลอดภัย แต่ SSH Remote หรือ VS Tunnel ไม่ใช่แบบนั้น
  • ผมรู้สึกไม่สบายใจที่จะอนุญาตให้ใช้ VSCode remote editing บนเซิร์ฟเวอร์สำหรับพัฒนา และยิ่งกว่านั้นกับเซิร์ฟเวอร์โปรดักชัน

    • การใช้ VSCode remote บนเซิร์ฟเวอร์โปรดักชันเป็นเรื่องบ้าบอ
    • ฟีเจอร์อื่น ๆ ถือเป็นความสามารถที่คาดหมายได้
  • อินสแตนซ์ VSCode บนเครื่องโลคัลจะกลายเป็น thin client ส่วนอินสแตนซ์ฝั่งรีโมตจะจัดการงานหนัก

    • เหมาะกับกรณีใช้โน้ตบุ๊กเล็ก ๆ SSH เข้าไปยังเวิร์กสเตชันทรงพลัง
    • แต่ถ้าใช้เวิร์กสเตชันทรงพลัง SSH เข้าไปยัง VM/VPS ขนาดเล็ก แนะนำให้ใช้ sshfs หรือเมานต์ระบบไฟล์ระยะไกลแบบอื่น