Azure Cosmos DB Shell Public Preview: CLI’a AI Geldi
Açık konuşayım: Cosmos DB ile uğraşan ekiplerin çoğunda aynı sıkıntı var. Portal açık, bir yanda SDK örneği, terminalde yarım kalmış bir Python script’i, arkada da eski bir PowerShell penceresi… Tek bir cevabı bulmak için dört yere bakıyorsun, sonra insan ister istemez “ben neyi kaçırdım?” diye soruyor (ciddiyim). Ben bunu Logosoft’ta, geçen yıl bir e-ticaret müşterisinde baya net yaşadım — basit görünen bir partition key dağılımını kontrol etmek için harcadığım vakit, asıl problemi çözmekten daha uzun sürdü.
İşte tam burada Microsoft, geçtiğimiz günlerde Azure Cosmos DB Shell’in public preview’ını duyurdu. Açık kaynak, bash benzeri sözdizimi olan, üstüne MCP server desteğiyle gelen bir CLI. Yanı sadece “yeni bir komut satırı aracı” değil; biraz daha ileri gidip söyleyeyim, agentic AI tarafında Cosmos DB’ye giden yolu kısaltan bir köprü gibi dürüyor. Evet, ilk bakışta sade görünüyor.
Şimdi durun bir saniye. Bu cümleyi okurken “ya işte yine bir CLI” diye düşündüyseniz haklısınız, ama bu sefer iş biraz farklı. Hatta ilk refleksim (belki yanılıyorum ama) de öyle öldü; sonra detaylara bakınca fikir değişti, çünkü mesele sadece komut çalıştırmak değil (asıl olay bağlamı tek yerde toplamak),. Bu küçük fark pratikte can sıkıcı dolaşmayı ciddi biçimde azaltabiliyor. Önü açayım.
Neden Yeni Bir Shell? Hem de Açık Kaynak?
Cosmos DB ile yıllardır uğraşıyorum. AZ-305’e hazırlanırken bile, işin operasyon tarafının ne kadar parçalı kaldığını görmüştüm; Data Explorer var, Azure CLI’da az cosmosdb komutları var, SDK’lar var, bir de her dil için ayrı tooling çıkıyor. Hepsi bir şeyler yapıyor ama akış dediğin şey, hani biraz sürtüyor.
Çok konuştum, örnekle göstereyim.
Peki neden yeni bir shell? Bak şimdi, bence mesele tam burada. Cosmos DB Shell’in çıkış fikri baya yerinde: developer’ın muscle memory’sine yaslanıyor. Yanı cd, ls, pwd komutlarını veritabanı hiyerarşisinde kullanıyorsun; database klasör gibi, container alt klasör gibi, item da dosya gibi dürüyor. Çok şaşırtıcı değil ama insanın kafasında oturuyor.
İtiraf edeyim, Açık kaynak kısmı işe başka bir hikâye. Ben yıllarca hosting tarafında çalıştım, o yüzden şunu açık konuşayım: kapalı kutu araçlar enterprise dünyasında bazen gereksiz bir tedirginlik yaratıyor. “Bu komut arka planda ne yapıyor?” sorusunun cevabını koddan görebilmek — hele finansal sektörde bir müşteriye danışmanlık verirken — gerçekten iş görüyor.
Kısa bir not düşeyim buraya.
“Cosmos DB Shell’i ilk denediğimde aklıma gelen ilk şey şuydu: keşke 2021’deki o migration projesinde bu olsaydı. 3 hafta sürmezdi, 3 günde biterdi.”
Bash Benzeri Sözdizimi: Pratikte Nasıl?
Hemen bir örnekle gireyim. Diyelim ki elinizde retail database’i var, içinde de orders container’ı dürüyor ve sız son 24 saatte kaç sipariş geldiğini görmek istiyorsunuz. Eskiden ne yapardınız? Büyük ihtimalle Data Explorer’a girer, query yazardınız; ya da SDK ile ufak bir script patlatırdınız. Şimdi iş biraz farklı, hatta baya rahatlıyor:
$ cosmos
cosmos:/> cd retail
cosmos:/retail> cd orders
cosmos:/retail/orders> query "SELECT VALUE COUNT(1) FROM c WHERE c.createdAt > '2026-01-15'"
[ 14782 ]
cosmos:/retail/orders> ls
itemId-001 itemId-002 itemId-003...Yanı bildiğiniz filesystem gibi geziyorsunuz. pwd dediğinizde nerede olduğunuzu görüyorsunuz, cd ile konteyner değiştiriyorsunuz, sonra da sorguyu çakıp çıkıyorsunuz. Küçük detay gibi dürüyor, ama günde 50 kere bağlam değiştiren bir DBA için resmen nefes aldırıyor. Bir bakıma, peki neden? Çünkü kafa sürekli “hangi subscription’daydım, hangi account’taydım” diye bölünmüyor (şaşırtıcı ama gerçek)
Peki neden?
Evet.
CI/CD Pipeline’larda Yeri
Bir de pipeline tarafı var ki, orada işler çoğu zaman gereksiz yere dolaşıyor. Azure DevOps ya da Actions" data-glossary-term="GitHub Actions">GitHub Actions içinde Cosmos DB ile ilgili bir şey yapmak istediğinizde ya REST API’yi dürtüyorsunuz ya da bir Node.js script’i yazıyorsunuz, sonra da debug ederken yarım gün gidiyor (özellikle env var’lar saçmalarsa). Cosmos DB Shell burada bash script’i yazar gibi akıyor, o kısmı idare eder.
Logosoft’ta bir bankacılık müşterimizde şöyle bir durum vardı: her deployment sonrası reference data container’ının senkronize edilmesi gerekiyordu. Bunun için yazılmış 200 satırlık bir TypeScript dosyası vardı; açık konuşayım, bakımına bakan kişinin yüzü pek gülmüyordu. Sonra bunu 15 satırlık bir shell script’e indirmek mümkün öldü, hem de işin mantığını bozmadan. Bakım maliyeti? Yerlerde. Hatta az önce “sadece kolaylık” dedim ama aslında asıl fark hızdan çok sadelikte çıktı.
Neyse, çok dağıttım, konumuza dönelim (ciddiyim). Böyle bir yaklaşımın güzel yanı şu: ekip içindeki herkes aynı dili konuşabiliyor. Birisi Bash biliyor, diğeri PowerShell seviyor, öbürü de terminalden çıkmıyor; hepsi için ortak zemin oluşuyor. Şey yanı, bazen küçük görünen bu tarz sözdizimi değişiklikleri büyük mimarı kararlardan daha çok etki ediyor.
Asıl mesele: MCP Server entegrasyonu
Vallahi, Şimdi işin biraz daha sert tarafına gelelim. İşte, cosmos DB Shell’in en ilginç yanı, içinde gelen Model Context Protocol server desteği. MCP’yi duymayanlar için kısaca söyleyeyim: AI ajanlarının dış sistemlerle konuşması için Anthropic’in başlattığı, sonra da epey yaygınlaşan bir protokol bu.
Peki ne işe yarıyor? Claude’a, Copilot’a ya da başka bir AI agent’a “production ortamındaki orders container’ında son 1 saatte hata alan kayıtları getir” dediğinizde, agent bunu Cosmos DB Shell üzerinden gerçekten çalıştırabiliyor (en azından benim deneyimim böyle). Shell’deki komutlar da tek tek MCP tool olarak dışarı açılıyor, yanı iş sadece konuşmada kalmıyor. Bu konuyla ilgili Durable Workflows ile Microsoft Agent Framework: Gerçek Hayatta Ne İşe Yarıyor? yazımıza da göz atmanızı tavsiye ederim.
Çok konuştum, örnekle göstereyim.
Aslında — dur, bunu biraz daha net anlatayım. MCP Tool Çağrılarını.NET’te Yönetmek: AGT ile Pratik Yol yazımda MCP’nın nasıl aktığını detaylıca anlatmıştım, oraya bakabilirsiniz. Buradaki fark şu: artık MCP server’ı sıfırdan yazma derdi yok, Cosmos DB tarafında hazır geliyor; bu da açık konuşayım baya iş görüyor.
MCP tool’ları olarak görünen komutlar
Shell’in agent’a verdiği yetenekleri kabaca şöyle ayırıyorum:
- Navigation:
cd,ls,pwd— agent veritabanı hiyerarşisinde dolaşıyor - Query:
querykomutu ile SQL çalıştırma, structured sonuç döndürme - Data manipulation:
create item,update,rm - Schema management:
mkdb,mkcon,rmdb,rmcon - Inspection:
endpoint, account ve connection bilgilerini gösterme
rm
Türkiye’deki Şirketler İçin Ne Anlama Geliyor?
Burası önemli, biraz yavaşlayalım (inanın bana). Türkiye’de Cosmos DB benimsenmesi son 2-3 yılda ciddi şekilde hızlandı, özellikle perakende ve fintech tarafında; ama işin ilginç kısmı şu: operasyonel olgunluk hâlâ Avrupa’nın biraz gerisinde kalıyor, çoğu ekip Cosmos DB’yi MongoDB API ile kullanıyor ve native NoSQL API’ye geçiş de açık konuşayım, pek hızlı gitmiyor (inanın bana)
Burada, cosmos DB Shell bu noktada bence iki şeyi aynı anda yapacak:
- Adoption barrier’ı düşürecek: bash bilen biri bunu 10 dakikada kavrıyor, yanı yeni bir ekip üyesinin onboarding süresi de doğal olarak kısalıyor.
- AI-driven operasyonu mainstream yapacak: Türkiye’de “AI agent ile veritabanı yönetimi” muhabbeti daha çok startup tarafında dönüyor; bu shell işe konuyu enterprise’a taşıyabilir çünkü tooling artık resmî ve open-source, garip ama işe yarıyor gibi.
Enterprise vs Startup: Hangisi İçin Daha Mantıklı?
Bakın, Açıkçası küçük bir startup’sanız, 2-3 kişilik developer ekibiniz varsa, Cosmos DB Shell’i bugün bile production’da denemeye başlayabilirsiniz. Risk düşük, kazanç fena değil; CI/CD’ye bütünleşik edin, lokal development’ta da kullanın, sonra gerisini zamana bırakın. Bu konuyla ilgili Visual Studio’da Bulut Ajanları: Kod Akışını Değiştiren Güncelleme yazımıza da göz atmanızı tavsiye ederim.
Şunu fark ettim: Ama 200+ kişilik bir engineering organizasyonundaysanız, burada biraz frene basmak lazım. Public preview’da olması tek başına yetiyor zaten; (belki yanılıyorum ama) SLA yok. Audit trail tarafında eksikler var (son baktığımda detaylı operation logging henüz yoktu, bu değişmiş olabilir), o yüzden compliance isteyen ortamlarda — GDPR, KVKK, BDDK — önce staging’de test edin, sonra üretime alın. E peki, sonuç ne öldü? Evet.
Peki neden?
Maliyet Tarafı: Beklenmedik Sürprizler
Araya gireyim: Bir şeyi atlamayalım: shell ücretsiz, açık kaynak. Ama altta çalışan Cosmos DB account’unuz değil. Burada ufak gibi görünen bir detay, sonra faturada tokat gibi geri dönebiliyor.
Shell üzerinden agent’a query yetkisi verdiğinizde, agent her ne kadar zeki olsa da bazen çok RU tüketen sorgular çalıştırabiliyor. Geçen ay bir test ortamında AI agent’a “şu container’daki tüm anomalileri bul” dedim, agent SELECT * FROM c çekti — yaklaşık 800.000 RU. Test ortamı olduğu için sorun yoktu ama production’da olsa, ay sonu faturası insanın suratını biraz ekşitirdi yanı. Daha fazla bilgi için SIG Architecture API Governance: Kubernetes’in Sessiz Kahramanı yazımıza bakabilirsiniz.
Şunu söyleyeyim, Bu yüzden benim önerim şu: agent’a expose ettiğiniz MCP tool’larında bir RU budget mekanizması düşünün. Neden önemli bu? Ya da en azından query’lerin TOP N ile sınırlandırılmasını zorunlu kılın, çünkü bazen işin aslı performans değil maliyet oluyor, ikisi aynı anda patlayınca da kimse keyif almıyor.
| Senaryo | Önerilen Yaklaşım | Risk Seviyesi |
|---|---|---|
| Lokal development | Tam yetki, MCP açık | Düşük |
| CI/CD pipeline | Service principal, scoped RBAC | Orta |
| AI agent (production) | Read-only, RU budget, audit log | Yüksek |
| Compliance ortamları | Preview’da kullanmayın, GA bekleyin | Çok Yüksek |
Evet. Bu tabloyu ben de ilk bakışta hafif abartılı bulmuştum. Sonra birkaç deneme yaptım; lokal tarafta rahat olan şeyler production’da bir anda can sıkıcı hâle geliyor, özellikle de agent elini kolunu sallaya sallaya veri taramaya başlıyorsa.
Burada, peki neden? Çünkü burada mesele sadece erişim değil, kontrol de istiyorsunuz. Açık konuşayım, read-only demek tek başına yetmiyor; audit log, scope daraltma ve mümkünse limit koyma işini birlikte düşünmek gerekiyor. Daha fazla bilgi için GitHub Copilot Modernize 101: Kodun Yorgunluğunu Kırmanın Yeni Yolu yazımıza bakabilirsiniz.
Güvenlik Tarafı: RBAC ve Authentication
Shell, Azure RBAC ile çalışıyor. Yanı az login ile bağlandığınız identity, shell tarafında da geçerli oluyor; ayrı bir credential kovalamıyorsunuz, bu da işin aslı baya rahatlatıyor.
Ben Cosmos DB’nın RBAC entegrasyonunu yıllardır izliyorum. Cosmos DB Azure RBAC Entegrasyonu: İki Dünya Birleşiyor yazımda bunu detaylandırmıştım — kısacası data plane RBAC artık fena değil, hatta bazı senaryolarda beklediğimden daha düzenli ilerliyor. Shell de tam bu zeminin üstüne kurulmuş durumda.
Ama burada küçük bir pürüz var. İlk denediğimde “Custom rol yok” hatasını gördüm, biraz duraksadım açıkçası; sonra çözümün Cosmos DB account’a Cosmos DB Built-in Data Contributor rolünü atamak olduğunu fark ettim (default gelmiyor, elle vermek gerekiyor), yanı olayın kilidi burada açılıyor. Microsoft dokümantasyonu bu noktada biraz dağınık kalmış, ona göre ilerleyin.
Kişisel Görüş: Beklediğim Kadar Olgun mu?
Ne yalan söyleyeyim, Acil konuşayım, public preview lafının altını kalın çizmek lazım. Shell baya umut veriyor ama işin içi o kadar da pürüzsüz değil, hani ilk bakışta “tamam bu olmuş” diyorsun, sonra birkaç köşede takılınca insan biraz geri adım atıyor. Birkaç eksiklik var:
- Multi-account context switching biraz hantal. Aynı anda 2 farklı subscription’daki Cosmos hesapları arasında geçiş yaparken yeniden login istemesi can sıkıyor, çünkü tam akışa girdim derken bir anda oturum ekranına düşüyorsun.
- Output formatting bazı edge case’lerde tuhaf — özellikle nested JSON’larda terminal okunabilirliği iyi değil, yanı veri var ama gözün önü ayıklamak için ekstra efor harcıyor.
- Windows tarafında bazı renderer sorunları var. WSL’de daha stabil çalışıyor; açıkçası ben de bunu görünce “tamam, Windows’ta biraz naz yapıyor” dedim.
Bence bu araç şu an %70 olgunlukta, ne fazla ne az. Yol haritası fena durmuyor, topluluk geri bildirimi de alıyorlar, GitHub repo’şuna baktığımda issue’lara dönüş süresi de idare eder seviyede. Dur bir saniye — asıl mesele şu: — ki bu tartışılır — bu tip ürünlerde kağıt üstündeki plan değil, günlük kullanımda kaç kere sınır bozduğu belirliyor tabloyu. 6 ay sonra GA’ya geldiğinde bambaşka bir araç olacak gibi geliyor bana, tabiî her şey yolunda giderse.
İlk Adımlar: Bugün Başlamak Için Ne Yapmalı?
Hadi lafı gevelemeden gireyim. Eğer Cosmos DB Shell’i bugün kurcalamak istiyorsanız, önce ortamı biraz toparlayın; yoksa yarım saat sonra “neden bağlanmıyor bu şey?” diye ekrana bakıp kalıyorsunuz (evet, doğru duydunuz)
- Azure CLI’nızın güncel olduğundan emin olun (
az --version) (bence en önemlisi) - npm üzerinden shell’i kurun:
npm install -g @azure/cosmosdb-shell - Bir test Cosmos DB hesabı oluşturun (production’da değil!)
- Hesaba Cosmos DB Built-in Data Contributor rolü atayın
cosmos --endpoint https://xxx.documents.azure.comile bağlanın- MCP entegrasyonunu denemek için Claude Desktop veya VS Code Copilot Chat’i konfigüre edin
Şunu söyleyeyim, İşin aslı, bu adımlar ilk bakışta basit dürüyor ama arada minicik pürüzler çıkabiliyor; mesela rol ataması gecikirse ya da endpoint’i yanlış kopyalarsanız, shell gayet sakın bir şekilde sizi kapıda bırakıyor. Ben olsam önce bunu test hesabında denerim, sonra production tarafına hiç bulaşmadan rahatça ilerlerim.
Bunu yaşayan biri olarak söyleyeyim, Evet.
İlk 1 saatinizi shell’de geçirince, neyin nereye oturduğu daha net oluyor. Önce ls, cd, query üçlüsünü ezber gibi değil de el alışkanlığı gibi kullanın. Açık konuşayım, muscle memory kısmı oturunca iş baya kolaylaşıyor. Sonra MCP’ye geçin, ama hemen her şeyi otomatikleştirmeye çalışmayın — önce temel akışın tadını çıkarın.
Peki neden?
İnanın, Çünkü bazen en faydalı kısım, en gösterişli yer olmuyor. Shell içinde iki üç komut atıp veri yapısını görmek, koleksiyonlar arasında dolaşmak ve sorgu sonucunu gözle okumak, sonradan eklenecek entegrasyonların da ne kadar mantıklı olduğunu size daha net gösteriyor. Sız ne dersiniz? Neyse, çok uzatmayayım; önce temel otursun, geri kalan zaten geliyor.
Sıkça Sorulan Sorular
Cosmos DB Shell, Azure CLI’ın yerini mi alıyor?
Hayır, öyle bir şey yok. Azure CLI hani hesap oluşturma, region ekleme, throughput ayarlama gibi account-level işler için hâlâ en doğru araç. Shell işe aslında başka bir şeye odaklanıyor — query çalıştırma, item’larla uğraşma, container yönetimi gibi data-plane işleri. Yanı ikisi birbirini tamamlıyor, biri diğerinin yerini almıyor.
MCP server’ı production’da kullanmak güvenli mi?
Açıkçası şu an public preview’da olduğu için kritik production sistemlerinde önermem. Ama mesela internal tooling, staging ortamları ya da developer productivity senaryolarında bugün bile rahatça kullanabilirsiniz. Bence read-only mod ve scoped RBAC ile riskleri iyi yönetirseniz gayet makul bir tercih.
MongoDB API veya Cassandra API ile çalışıyor mu?
Şu anki preview yalnızca NoSQL API’ye odaklanmış. MongoDB ve Cassandra API desteği roadmap’te var ama henüz gelmiş değil. Bu API’leri kullanıyorsanız şimdilik mevcut tooling’inizle devam etmeniz gerekiyor, maalesef.
Açık kaynak olduğuna göre fork edip değiştirebilir mıyım?
Tabiî ki, MIT lisansı altında istediğinizi yapabilirsiniz (şaşırtıcı ama gerçek). Mesela birçok platform ekibi kendi kurumsal standartlarına bir düşüneyim… göre custom komutlar ekliyor, internal authentication mekanizmalarına entegre ediyor. Tecrübeme göre Türkiye’deki büyük kurumlar için KVKK uyumluluğu amacıyla fork etmek gerçekten mantıklı bir yol olabilir (kendi tecrübem)
Performans olarak SDK kullanmaktan ne kadar yavaş?
Eh, Tek tek sorgularda fark yok denecek kadar az — altta zaten aynı SDK çalışıyor (evet, doğru duydunuz). Ama bulk operasyonlarda, yanı binlerce item insert/update gibi işlerde, doğrudan SDK kullanmak hâlâ daha performanslı. Aslında Shell zaten operasyonel ve interactive iş yükleri için tasarlanmış; ETL senaryoları için değil, bunu göz önünde bulundurmak lazım.
Kaynaklar ve İleri Okuma
Bakın, şunu fark ettim: Resmî Duyuru: Azure Cosmos DB Shell Public Preview
İnanın, Azure Cosmos DB Resmî Dokümantasyonu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder