5 puan yazan GN⁺ 2026-02-06 | 1 yorum | WhatsApp'ta paylaş
  • Yapay zeka ajanlarının gerçek altyapıyı güvenle kullanabilmesi için sandbox kopya ortamı oluşturan terminal tabanlı bir araç
  • Kopyalanmış VM veya Kubernetes kümesinde komut çalıştırma, dosya düzenleme, bağlantı testi yapma ve sonuçları otomatik olarak Ansible Playbook biçiminde üretme
  • Sadece LLM'in kod üretmesine dayanan yaklaşımdan farklı olarak, gerçek ortamı kopyalayıp test ve doğrulamadan geçmiş IaC (Infra-as-Code) üretir
  • Geçici SSH sertifikaları kullanarak komutları güvenli biçimde çalıştırır; kaynağı kısıtlı host'larda veya internet erişimi gerektiğinde insan onay süreci gerekir
  • Tüm komutlar ve değişiklikler denetim günlüğüyle izlenir; geliştiricilerin yerel ortamda altyapıyı deneyip yeniden üretilebilir yapılandırmalar oluşturmasına yardımcı olan bir araç

Fluid'e genel bakış

  • Fluid, üretim altyapısını (örn. VM, K8s kümesi) kopyalayan bir sandbox içinde yapay zekanın çalışmasını sağlayan bir terminal ajanıdır
    • Yapay zeka ajanı komut çalıştırabilir, bağlantı testi yapabilir ve dosya düzenleyebilir
    • Ardından sonuçları Ansible Playbook biçimine dönüştürerek üretim ortamına uygulanabilir hale getirir
  • Bu yaklaşım, yapay zekanın gerçek sistem yapısını tahmin etmesi yerine kopyalanmış ortamda doğrudan deney yapabilmesini sağlar

Mevcut LLM tabanlı IaC üretiminden farkı

  • LLM'ler Terraform, OpenTofu, Ansible gibi araçlar için kod üretmede başarılı olsa da gerçek üretim ortamının davranışını tam olarak kavrayamaz
  • Fluid, kopyalanmış altyapıya erişim üzerinden önce komut çalıştırma ve test yapar, ardından bu sonuçlara dayanarak IaC yazar
  • Bu yaklaşım dağıtımdan önce doğrulama ve deney yapılmasını mümkün kılar

Claude Code'dan ayrışan yönleri ve güvenlik tasarımı

  • Fluid, Claude Code'un yerelden doğrudan üretim sunucularına SSH ile bağlanmaması için tasarlanmıştır
  • Tüm işlemler yalnızca sandbox içinde yürütülür ve bunu Fluid yönetir
  • Geçici SSH sertifikaları kullanılarak komut yürütme sonuçları gerçek zamanlı gösterilir
  • Belleği veya CPU'su düşük host'lar, internet erişimi, paket kurulumu gibi işlemler için insan onay süreci gerekir

Başlıca özellikler

  • Sandbox Isolation: VM'leri anında kopyalayarak üretimi etkilemeden değişiklikleri test eder
  • Context-Aware: Host'un işletim sistemi, paketleri ve CLI araçlarını keşfederek ortama uygun davranır
  • Full Audit Trail: Tüm komutları ve değişiklikleri kaydederek denetim ve inceleme olanağı sağlar
  • Ansible Playbook otomatik üretimi: Sandbox içinde yapılan işlemlere dayanarak yeniden üretilebilir altyapı kodu oluşturur

Kullanım örneği

  • Fluid, v create_sandbox komutuyla bir sandbox oluşturur ve IP ile durumu gösterir
  • v run_command ile komut çalıştırılır; örnekte Ubuntu 22.04 ortamında Apache HTTP Server kurulumu ve çalıştırılması yer alır
  • curl localhost ile web sunucusunun çalıştığı doğrulanır
  • Ardından v create_playbook ile httpd-setup playbook'u oluşturulur
    • 4 görev içerir: apt önbelleğini güncelleme, Apache kurma, index.html oluşturma, Apache servisini başlatma ve etkinleştirme
  • Oluşturulan playbook, diğer Ubuntu sunucularında da aynı yapılandırmayı yeniden üretebilir

Kurulum ve çalıştırma

  • Yerel iş istasyonuna kurulan terminal ajanı biçimindedir
  • Kurulumdan sonra yerel ortamda doğrudan sandbox oluşturup test yapılabilir

Özet

  • Fluid, yapay zeka tabanlı altyapı otomasyonu ile güvenli izolasyonu birleştiren bir araçtır
  • Gerçek zamanlı komut yürütme, denetim takibi ve Ansible kodu üretimi sayesinde güvenli ve yeniden üretilebilir altyapı yönetimini destekler
  • Claude Code'un altyapı sürümü olarak, geliştirici ve operasyon ekiplerinin üretim ortamını taklit ederek deney yapmasına yönelik yeni bir yaklaşım sunar

1 yorum

 
GN⁺ 2026-02-06
Hacker News görüşleri
  • Bu aralar bir şeyler yapmak için araç bolluğu var, ama ortada gerçekten yapılacak bir şey yokmuş gibi geliyor
    Sanki tüm ürünler, başka bir build tool için kurulmuş bir piramit yapısının parçası gibi
    Bu, fluid.sh’e özel bir şikayet değil; ben de ne yapmam gerektiğini düşünüyorum

    • 2007’deki Facebook uygulama patlaması sırasında bir startup’ta çalışıyordum; tüm uygulama şirketleri aslında başka uygulamaların reklamını satıyordu
      Uygulama ekosistemi tamamen döngüsel bir ekonomi gibi işliyordu ve gerçek kullanıcı değeri ya da gelir kaynağı yoktu. Sonunda uzun ömürlü olmadı
    • Sorun, birçok geliştiricinin alan bilgisi olmadan sadece yazılım tekniğini derinlemesine öğrenmesinde
    • Ben de bir yıldır teknoloji dışı bir sektörde çalışıyorum ve kod yazabilmem sayesinde iş arkadaşlarım bana sihirbaz gibi davranıyor
      Gerçek problemleri çözerken kod tabanı giderek yeniden kullanılabilir özelliklere dönüşüyor
      Şimdi bu deneyim üzerinden danışmanlık vermeyi deniyorum; bir gün “ürün” diyebileceğim bir şey bulacağımı düşünüyorum
    • Makroekonomik açıdan bakınca, teknoloji fazla hızlı ilerlediğinde çıktının azaldığı bir dönem olabiliyor
      Şu anki AI araç patlaması da buna benziyor. Herkes bu hızlı değişim içinde yeniden öğreniyor
      Sonuçta hepimiz hareketli kumun üstüne temel atıyoruz
    • Ben de aynı şeyi düşünüyordum ama son zamanlarda bu araçları tersine mühendislik için kullanmaya başladım
      Örneğin, Çin malı bir etiket yazıcısının Linux’taki baskı kalitesini beğenmediğim için BLE üzerinden doğrudan çıktı alan bir Go script’i yazdım
      Android uygulamasını decompile etmek yerine bunu Agentic AI’a yaptırdım; şimdi tarayıcı sürümü ve ESP32 sürümü bile var
      İlgili yazıyı Making a label printer work under Linux using Agentic AI içinde topladım
  • curl -fsSL https://fluid.sh/install.sh | bash komutunu görünce gülmemin nedeni şuydu:
    Başta amaç güvenlik nedeniyle SSH erişimini engellemekti, ama sonuçta daha da riskli bir kurulum script’ini çalıştırmış oluyorsun; ironik olan da bu
    İlgili tweet’i burada görebilirsiniz

    • Artık internetin, LLM’lerin kötü amaçlı URL’ler önermesini sağlamak için zehirlendiği bir çağdayız. Gerçekten inanılmaz zamanlar
  • Ben Collin, fluid.sh üzerinde çalışıyorum
    Bunu Claude Code’un altyapı sürümü gibi düşünebilirsiniz.
    Fluid, üretim altyapısının (VM, K8s vb.) sandbox kopyalarını oluşturuyor; böylece AI ajanları komut çalıştırıp dosya düzenleyebiliyor, test yapabiliyor
    ve ardından Ansible Playbook gibi IaC’ler üretebiliyor
    Temel fikir, LLM’in sadece Terraform üretmesi yerine gerçek ortamı keşfederek bağlamı anlamasını sağlamak
    Güvenlik nedeniyle Claude Code’un doğrudan production’a SSH ile bağlanmaması için tasarlandı
    ve ephemeral SSH sertifikaları ile komut yürütme işlemleri izlenebilir hale getiriliyor
    Kaynağı az olan host’larda ya da dış ağa erişim gerektiğinde insan onayı isteniyor
    Geri bildirimlere açığım!

    • Bu açıklamaları neden ana sayfaya koymadığınızı merak ediyorum.
      Şu an sitede sadece “Claude Code for infrastructure” gibi bir ifade var
      bir altyapı mühendisinin tek satırlık bash komutuyla kurulum yapması için fazla yetersiz
    • Birden çok altyapı kopyası ayağa kaldırıp ajanları oralarda dolaştırmak maliyet israfı gibi görünüyor
      DevOps yapan biri olarak bu bana verimsiz geliyor
    • Uzak sandbox içinde elle yapılandırma yapmak, Infrastructure as Code felsefesiyle pek uyuşmuyor
      Ben Pulumi, Tilt ve Kubernetes kombinasyonuyla yeterince otomasyon sağlıyorum
      Claude da bu ortamda gayet iyi çalışıyor. SSH ile doğrudan dokunmaya gerek yok
    • O halde bunun, mevcut bir VM’e Claude Code dağıtıp çalıştırmaktan farkının ne olduğunu anlayamadım
      Zaten çeşitli sandbox yöntemleri var. Ayırt edici farkın ne olduğunu merak ediyorum
    • Mevcut altyapıyı Terraformer ile de kopyalayabilirsiniz
      Eğer böyle temel IaC otomasyonu bile yoksa sorun DevOps ekibindedir
    • Ben zaten “Claude Code’a kubectl komutları verdirip Helm chart’ı düzelttirme” gibi şeyler yapıyorum
      Normal CLI ile de yeterince iyi çalışıyor
      • Bu günlerde LLM tabanlı araçların önemli bir kısmı böyle prompt wrapper seviyesinde. Temelde bir fark yok
      • Ben de kısmen öyle hissediyorum ama bu projenin amacı büyük ölçekli ortamlarda güvenliği sağlamak gibi görünüyor
        Yüzlerce VM ile çalışırken sadece basit gözetim yeterli olmuyor
      • Ben de Claude’u salt okunur bir hesapla çalıştırıyorum; Terraform ya da AWS CLI ile de gayet iyi entegre oluyor
        Yeni bir araca mecbur değilim
      • Ben de salt okunur kubeconfig ile kısıtlama koyuyorum; SKILL.md iyi yazılmışsa yeterince güvenli çalışıyor
      • Salt okunur erişimi açık bırakmak da büyük sorun yaratmadı
        Ama bu proje galiba yeniden üretilebilirlik ve güvenlik tarafını daha fazla vurguluyor
    • Production kopyalamak kolay değil. DB bağlantıları ya da tüm stack’in kopyasını çıkarmak pratikte zor
      Bence AI’ın production yapısını anlayıp doğrudan değişiklik yapması daha mantıklı
      Modeller zaten artık IaC yazma konusunda yeterince yetkin
    • Fikir ilginç. Son zamanlarda operasyon ve gözlemlenebilirlik (Observability) alanı yükselişte
      Ben de Kubernetes operasyonlarında Claude’a Grafana erişimi verip debug’a yardım ettiriyorum
      Bu sayede onlarca saat kazandım.
      Ansible Playbook’u otomatik üretme yaklaşımı, denetim izi oluşturma açısından da harika
      • Ama bu tür otomasyon yaygınlaşırsa, operasyon ekiplerinin istikrarsızlığı artabilir
        Gerçekten de deneyimli mühendislerin işlerini kaybettiği örnekler ortaya çıkmaya başladı
      • Kubernetes desteği planladığınızı duymak sevindirici. Fikri beğendim
    • Açıkçası bunun zaten çözülmüş bir problem olduğunu düşünüyorum
      Çoğu kişi altyapıyı baştan IaC ile kuruyor, gerekirse sonradan tersine de çıkarabiliyor
      Claude’u bir sandbox hesapta IAM rolüyle çalıştırmak yeterli
    • “LLM production sistemi iyi tahmin edemez” iddiasına katılmıyorum
      IaC ile API üzerinden altyapıyı sorgulayabilirsiniz ve bunun avantajı yeniden kullanılabilirlik ile sürüm kontrolüdür
      • DevOps ortamlarının şirketten şirkete değiştiği ve genelleştirmenin zor olduğu konusunda ise katılıyorum
        Çoğu startup hâlâ HCL ya da YAML seviyesinde zorlanıyor
    • “Güvenli olması için curl script’ini çalıştırın” ifadesi bana ironik geliyor
    • Bu yapı, KVM’i libvirt ile kontrol edip SSH anahtarları vererek LLM’in VM’lere erişmesini sağlama modeli mi?
      Ansible Playbook, VM içindeki değişikliklere bakılarak mı üretiliyor, yoksa tüm işlemler sadece Ansible üzerinden mi yapılıyor merak ediyorum
      Basitçe Ansible’ı tekrar tekrar çalıştırmaktan farklı olarak hangi ayırt edici özellikleri sunduğunu bilmek isterim