Fluid - Claude Code สำหรับอินฟรา

 (fluid.sh)
5 คะแนน โดย GN⁺ 2026-02-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เครื่องมือแบบเทอร์มินัลที่สร้าง สภาพแวดล้อมแซนด์บ็อกซ์แบบโคลน เพื่อให้ AI เอเจนต์สามารถจัดการอินฟราจริงได้อย่างปลอดภัย
  • รันคำสั่ง แก้ไขไฟล์ และทดสอบการเชื่อมต่อบน VM ที่โคลนมาหรือ Kubernetes cluster พร้อมสร้างผลลัพธ์ออกมาเป็น Ansible Playbook โดยอัตโนมัติ
  • ต่างจากแนวทางที่ให้ LLM สร้างโค้ดอย่างเดียว โดยจะโคลนสภาพแวดล้อมจริงเพื่อสร้าง IaC (Infra-as-Code) ที่ผ่านการทดสอบและตรวจสอบแล้ว
  • ใช้ ephemeral SSH certificates เพื่อรันคำสั่งอย่างปลอดภัย และต้องมี ขั้นตอนการอนุมัติโดยมนุษย์ เมื่อเข้าถึงอินเทอร์เน็ตหรือทำงานบนโฮสต์ที่ทรัพยากรไม่เพียงพอ
  • ทุกคำสั่งและการเปลี่ยนแปลงจะถูก ติดตามใน audit log และเป็นเครื่องมือที่ช่วยให้นักพัฒนาทดลองอินฟราในเครื่องและสร้างการตั้งค่าที่ทำซ้ำได้

ภาพรวมของ Fluid

  • Fluid คือ terminal agent ที่ให้ AI ทำงานในแซนด์บ็อกซ์ซึ่งโคลนมาจาก production infrastructure (เช่น VM, K8s cluster)
    • AI agent สามารถรันคำสั่ง ทดสอบการเชื่อมต่อ และแก้ไขไฟล์ได้
    • จากนั้นจะแปลงผลลัพธ์เป็น Ansible Playbook เพื่อนำไปใช้กับสภาพแวดล้อม production ได้
  • วิธีนี้ทำให้ AI ไม่ต้องเดาโครงสร้างของระบบจริง แต่สามารถ ทดลองได้โดยตรงในสภาพแวดล้อมที่โคลนมา

ความต่างจากการสร้าง IaC แบบเดิมที่อิง LLM

  • LLM สามารถสร้างโค้ดอย่าง Terraform, OpenTofu, Ansible ได้ดี แต่ ไม่สามารถเข้าใจการทำงานของสภาพแวดล้อม production จริงได้อย่างแม่นยำเสมอไป
  • Fluid เข้าถึงอินฟราที่โคลนมาเพื่อ รันคำสั่งและทดสอบก่อน แล้วจึงเขียน IaC จากผลลัพธ์ที่ได้
  • แนวทางนี้ทำให้สามารถ ตรวจสอบและทดลองก่อน deploy ได้

จุดต่างจาก Claude Code และการออกแบบด้านความปลอดภัย

  • Fluid ถูกออกแบบมาเพื่อไม่ให้ Claude Code SSH เข้า production server โดยตรงจากเครื่อง local
  • ทุกงานจะ รันอยู่ภายในแซนด์บ็อกซ์เท่านั้น และ Fluid เป็นผู้จัดการทั้งหมด
  • ใช้ ephemeral SSH certificates และแสดงผลการรันคำสั่งแบบเรียลไทม์
  • การเข้าถึงอินเทอร์เน็ต การติดตั้งแพ็กเกจ หรือการทำงานบนโฮสต์ที่มีหน่วยความจำหรือ CPU ต่ำ จะต้องผ่าน ขั้นตอนการอนุมัติโดยมนุษย์

ความสามารถหลัก

  • Sandbox Isolation: โคลน VM ได้ทันทีเพื่อทดสอบการเปลี่ยนแปลงโดยไม่กระทบ production
  • Context-Aware: สำรวจ OS, แพ็กเกจ และเครื่องมือ CLI ของโฮสต์เพื่อทำงานให้เหมาะกับสภาพแวดล้อม
  • Full Audit Trail: บันทึกทุกคำสั่งและการเปลี่ยนแปลงเพื่อให้ ตรวจสอบและทบทวนได้
  • สร้าง Ansible Playbook อัตโนมัติ: สร้าง โค้ดอินฟราที่ทำซ้ำได้ จากงานที่ทำในแซนด์บ็อกซ์

ตัวอย่างการใช้งาน

  • Fluid สร้างแซนด์บ็อกซ์ด้วยคำสั่ง v create_sandbox และแสดง IP กับสถานะ
  • ใช้ v run_command เพื่อรันคำสั่ง โดยตัวอย่างเป็นการ ติดตั้งและรัน Apache HTTP Server บน Ubuntu 22.04
  • ใช้ curl localhost เพื่อตรวจสอบว่าเว็บเซิร์ฟเวอร์ทำงาน
  • จากนั้นใช้ v create_playbook เพื่อสร้างเพลย์บุ๊ก httpd-setup
    • มี 4 tasks: อัปเดต apt cache, ติดตั้ง Apache, สร้าง index.html, และเริ่มพร้อมเปิดใช้งานบริการ Apache
  • เพลย์บุ๊กที่สร้างขึ้นสามารถ ทำซ้ำการตั้งค่าเดียวกันบน Ubuntu server อื่นได้

การติดตั้งและการรัน

  • อยู่ในรูปแบบ terminal agent ที่ติดตั้งบน local workstation
  • หลังติดตั้งแล้วสามารถสร้างแซนด์บ็อกซ์และทดสอบจากสภาพแวดล้อม local ได้ทันที

สรุป

  • Fluid เป็นเครื่องมือที่ผสาน ระบบอัตโนมัติของอินฟราด้วย AI เข้ากับ การแยกสภาพแวดล้อมเพื่อความปลอดภัย
  • รองรับการรันคำสั่งแบบเรียลไทม์ การติดตาม audit และการสร้างโค้ด Ansible เพื่อช่วยให้ การจัดการอินฟราปลอดภัยและทำซ้ำได้
  • เป็น Claude Code เวอร์ชันสำหรับอินฟรา ที่นำเสนอแนวทางใหม่ให้ทั้งนักพัฒนาและผู้ดูแลระบบสามารถทดลองบนสภาพแวดล้อมที่เลียนแบบ production ได้

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2026-02-06
ความคิดเห็นจาก Hacker News

  • ช่วงนี้เหมือนมีแต่เครื่องมือสำหรับสร้างอะไรสักอย่างเต็มไปหมด แต่กลับรู้สึกว่าไม่มีอะไรให้สร้างจริง ๆ
    มันเหมือนทุกผลิตภัณฑ์เป็นเพียงส่วนหนึ่งของพีระมิดที่สร้างขึ้นมาเพื่อขาย build tool ให้กับ build tool อีกที
    ไม่ได้จะบ่นเรื่อง fluid.sh นะ แค่ฉันเองก็กำลังคิดอยู่ว่าควรจะสร้างอะไรดี

    • ตอนกระแสแอป Facebook บูมในปี 2007 ฉันทำงานอยู่ที่สตาร์ทอัปแห่งหนึ่ง แล้วทุกบริษัทแอปก็มีโมเดลแบบขายโฆษณาให้แอปอื่น
      ecosystem ของแอปตอนนั้นหมุนกันเป็นเศรษฐกิจแบบปิดโดยสมบูรณ์ ไม่มีคุณค่าจริงให้ผู้ใช้หรือแหล่งรายได้ที่แท้จริง สุดท้ายก็อยู่ได้ไม่นาน
    • ปัญหาคือนักพัฒนาหลายคนลงลึกกับเทคนิคซอฟต์แวร์โดยไม่มีความรู้โดเมน
    • ฉันเองก็ทำงานในอุตสาหกรรมที่ไม่ใช่เทคมา 1 ปีแล้ว แล้วด้วยทักษะเขียนโค้ด เพื่อนร่วมงานก็มองเหมือนเป็นพ่อมด
      พอแก้ปัญหาจริงไปเรื่อย ๆ codebase ก็เริ่มพัฒนาเป็นความสามารถที่นำกลับมาใช้ซ้ำได้
      ตอนนี้เลยเริ่มลองทำคอนซัลต์จากประสบการณ์นี้ และคิดว่าสักวันคงเจอสิ่งที่เรียกว่า “ผลิตภัณฑ์” ได้
    • ถ้ามองเชิงมหภาค เศรษฐกิจจะมีช่วงที่เมื่อเทคโนโลยีพัฒนาเร็วเกินไปกลับทำให้ผลผลิตลดลง
      กระแสเครื่องมือ AI ตอนนี้ก็ดูคล้ายกัน ทุกคนกำลังกลับไปเรียนรู้ใหม่ท่ามกลางความเปลี่ยนแปลงที่เร็วเกินไป
      สุดท้ายเราก็เหมือนกำลังสร้างฐานบนผืนทรายที่เคลื่อนไหวตลอดเวลา
    • ฉันก็เคยคิดแบบเดียวกัน แต่ช่วงหลังเริ่มใช้เครื่องมือพวกนี้กับงานreverse engineering
      อย่างเช่นฉันไม่ชอบคุณภาพการพิมพ์บน Linux ของเครื่องพิมพ์ฉลากจากจีน เลยเขียนสคริปต์ Go ที่พิมพ์ตรงผ่าน BLE เอง
      แทนที่จะ decompile แอป Android เอง ก็โยนให้ Agentic AI ทำ ตอนนี้มีทั้งเวอร์ชันเบราว์เซอร์และเวอร์ชัน ESP32 แล้ว
      เขียนไว้ที่ Making a label printer work under Linux using Agentic AI

  • เหตุผลที่ฉันหัวเราะเมื่อเห็นคำสั่ง curl -fsSL https://fluid.sh/install.sh | bash ก็เพราะ
    เดิมทีเจตนาคือจะปิดกั้นการเข้าถึงผ่าน SSH เพื่อความปลอดภัย แต่สุดท้ายกลับต้องรันสคริปต์ติดตั้งที่เสี่ยงกว่า เป็นความย้อนแย้งดี
    ทวีตที่เกี่ยวข้องดูได้ที่นี่

    • ทุกวันนี้เป็นโลกที่มีการวางยาพิษอินเทอร์เน็ตเพื่อให้LLM แนะนำ URL อันตรายได้แล้ว ช่างเป็นยุคสมัยที่น่าทึ่งจริง ๆ

  • ฉันคือ Collin และกำลังสร้าง fluid.sh
    จะมองว่าเป็นเวอร์ชันสำหรับอินฟราของ Claude Code ก็ได้
    Fluid จะสร้างสำเนา sandbox ของ production infrastructure (เช่น VM, K8s) เพื่อให้ AI agent รันคำสั่ง แก้ไฟล์ ทดสอบ แล้วค่อยสร้าง IaC อย่าง Ansible Playbook ออกมา
    แกนสำคัญคือทำให้ LLM ไม่ได้แค่สร้าง Terraform แบบเดาสุ่ม แต่สามารถสำรวจสภาพแวดล้อมจริงและเข้าใจบริบทได้
    ด้วยเหตุผลด้านความปลอดภัย เราออกแบบไม่ให้ Claude Code SSH เข้า production โดยตรง
    และใช้ephemeral SSH certificate เพื่อให้ติดตามการรันคำสั่งได้
    ถ้าเป็นโฮสต์ทรัพยากรต่ำหรือมีการเข้าถึงเครือข่ายภายนอก จะต้องมีการอนุมัติจากมนุษย์
    ยินดีรับฟีดแบ็ก!

    • สงสัยว่าทำไมไม่ใส่คำอธิบายแบบนี้ไว้บนหน้าเว็บหลัก
      ตอนนี้ในเว็บเขียนแค่ประมาณว่า “Claude Code for infrastructure”
      สำหรับวิศวกรอินฟรา มันไม่เป็นมิตรพอเลยถ้าจะให้ติดตั้งด้วย bash บรรทัดเดียว
    • การเปิดอินฟราหลายสำเนาแล้วปล่อย agent ไปวิ่งดูเหมือนสิ้นเปลืองค่าใช้จ่าย
      ในมุมคนทำ DevOps มันไม่มีประสิทธิภาพ
    • การตั้งค่าด้วยมือใน remote sandbox มันขัดกับปรัชญา Infrastructure as Code
      ฉันใช้ Pulumi, Tilt และ Kubernetes ก็อัตโนมัติได้เพียงพอแล้ว
      Claude ก็ทำงานในสภาพแวดล้อมนี้ได้ดีอยู่แล้ว ไม่จำเป็นต้องไปจับผ่าน SSH โดยตรง
    • ถ้าอย่างนั้นก็ยังไม่เห็นว่าต่างจากการเอา Claude Code ไป deploy รันบน VM เดิมอย่างไร
      ทุกวันนี้ก็มีวิธี sandbox อยู่หลายแบบแล้ว เลยอยากรู้ว่าจุดต่างคืออะไร
    • ใช้ Terraformer ก็ทำสำเนาอินฟราที่มีอยู่ได้
      ถ้าระบบอัตโนมัติพื้นฐานของ IaC ยังไม่มี แบบนั้นทีม DevOps ต่างหากที่มีปัญหา
    • ทุกวันนี้ก็ใช้งานแบบ “สั่ง Claude Code ให้รันคำสั่ง kubectl แล้วไปแก้ Helm chart” กันอยู่แล้ว
      ใช้ CLI ปกติก็ทำงานได้ดีพอ
      • เครื่องมือที่อิง LLM หลายตัวช่วงนี้ก็เป็นแค่ตัวห่อ promptระดับหนึ่งเท่านั้น ยังไม่มีความต่างที่เป็นแก่นจริง ๆ
      • ฉันก็รู้สึกคล้ายกัน แต่โปรเจกต์นี้ดูมีเป้าหมายเพื่อเพิ่มความปลอดภัยในสภาพแวดล้อมขนาดใหญ่
        เวลาต้องดูแลระดับหลายร้อย VM การแค่เฝ้าดูอย่างเดียวอาจไม่พอ
      • ฉันก็รัน Claude ด้วยบัญชีแบบอ่านอย่างเดียว และมันก็เชื่อมกับ Terraform หรือ AWS CLI ได้ดี
        ไม่ได้รู้สึกว่าจำเป็นต้องมีเครื่องมือใหม่
      • ฉันก็จำกัดด้วย kubeconfig แบบอ่านอย่างเดียว แล้วเขียน SKILL.md ดี ๆ ก็ปลอดภัยพอแล้ว
      • ต่อให้เปิดเป็น read-only ก็ไม่ค่อยมีปัญหาใหญ่
        แต่โปรเจกต์นี้ดูจะเน้นเรื่องการทำซ้ำได้และความปลอดภัยมากกว่า
    • การทำ production clone ไม่ใช่เรื่องง่าย การต่อ DB หรือทำสำเนาทั้งสแตกจริง ๆ นั้นยากในทางปฏิบัติ
      ฉันกลับคิดว่าให้ AI เข้าใจโครงสร้าง production แล้วแก้ตรงนั้นโดยตรงอาจดีกว่า
      ทุกวันนี้โมเดลต่าง ๆ ก็เก่งพอในการเขียน IaC อยู่แล้ว
    • ไอเดียน่าสนใจ ช่วงนี้สายoperations และ observabilityกำลังมาแรง
      ฉันเองตอนดูแล Kubernetes ก็ให้ Claude เข้าถึง Grafana เพื่อช่วย debug
      มันช่วยประหยัดเวลาไปได้หลายสิบชั่วโมง
      แนวทางที่สร้าง Ansible Playbook อัตโนมัติก็ยอดเยี่ยมในแง่auditabilityด้วย
      • แต่ถ้าระบบอัตโนมัติแบบนี้แพร่หลายขึ้น ก็อาจเพิ่มความไม่มั่นคงของงานสายปฏิบัติการ
        ตอนนี้ก็เริ่มมีกรณีที่วิศวกรฝีมือดีตกงานแล้ว
      • เห็นว่ามีแผนรองรับ Kubernetes ก็น่าตื่นเต้น ชอบไอเดียนี้
    • พูดตรง ๆ ฉันคิดว่านี่เป็นปัญหาที่ถูกแก้ไปแล้ว
      ส่วนใหญ่คนก็สร้างอินฟราด้วย IaC ตั้งแต่แรก และถ้าจำเป็นก็ประกอบย้อนกลับได้
      แค่รัน Claude ในบัญชี sandbox ผ่าน IAM role ก็เพียงพอแล้ว
    • ฉันไม่เห็นด้วยกับข้ออ้างว่า “LLM เดา production system ได้ไม่ดี”
      IaC สามารถ query อินฟราผ่าน API ได้ และมีข้อดีด้านการใช้ซ้ำและการจัดการเวอร์ชัน
      • ฉันเห็นด้วยว่าระบบ DevOps ของแต่ละบริษัทต่างกันมาก และทำให้เป็นมาตรฐานทั่วไปได้ยาก
        สตาร์ทอัประดับมากมายก็ยังติดหล่มอยู่แค่กับ HCL หรือ YAML
    • คำพูดแนว “เพื่อความปลอดภัย ให้รัน curl script นี้” ฟังดูย้อนแย้งดี
    • หรือว่าระบบนี้คือใช้ libvirt ควบคุม KVM แล้วออก SSH key ให้ LLM เข้า VM?
      Ansible Playbook ถูกสร้างจากการเปลี่ยนแปลงภายใน VM หรือว่าทุกอย่างถูกจัดการผ่าน Ansible อย่างเดียว?
      อยากรู้ว่ามันมีความสามารถที่ต่างออกไปจากการรัน Ansible ซ้ำ ๆ แบบธรรมดาตรงไหน