Azure Cosmos DB vNext Emulator: Yerelde Gerçek Gibi Test Etmek
Şunu fark ettim: Geçen hafta bir müşteride, İstanbul’daki ekip ile Frankfurt’taki CI hattı aynı testi farklı sonuçlarla verince yine o eski soru açıldı: “Sorun kodda mı, altyapıda mı?” İşin aslı şu, dağıtık sistemlerde bu soruya tek cümleyle cevap vermek zor oluyor. Azure Cosmos DB tarafında da tablo değişmiyor; canlı hesabı test için kullanmak istemiyorsunuz, ama yerelde de gerçek davranışa yakın bir ortam arıyorsunuz. Tam burada vNext emülatör devreye giriyor.
Şöyle söyleyeyim, Bunu geçen ay Ankara’daki bir müşteri görüşmesinde de konuştuk. Ekip.NET tabanlı birkaç mikroservis yazıyordu. Cosmos DB bağımlılığı yüzünden integration testleri pahalıya patlıyordu — hem süre uzuyor hem de ortam kirleniyordu (evet, kirleniyor). Emülatör sayesinde testi lokalde koşturup hatayı daha kod yazarken görmek mümkün hâle geldi. Küçük görünen değişiklikler bazen en çok buradan vuruyor.
Shell entegrasyonu işin tadını değiştiriyor
Bana kalırsa en iyi yeniliklerden biri gömülü Cosmos DB Shell. Eskiden veri yüklemek için ayrı script’ler yazılırdı; önce gateway ayağa kalksın diye beklersiniz, sonra database oluşturursunuz, sonra container açarsınız… Derken yarım saat giderdi. Şimdi shell doğrudan container içinde kullanılabiliyor. Şey gibi değil artık; daha az dolambaçlı.
Konteynere bağlanıp kabuk üzerinden işlem yapmak bana biraz eski usül sysadmin günlerini hatırlattı — hani SSH atıp içeride işi halledersiniz ya (en azından benim deneyimim böyle). Aynı hissiyatın modern hali gibi düşünebilirsiniz: (ciddiyim)
docker exec -it <container-name> cosmoshell.sh
Bunun pratik sonucu şu: seed verisini uygulama dışına çıkarıyorsunuz. Bu küçük gibi görünen detay aslında önemli çünkü bootstrap mantığını koddan ayırıyor. Kodunuz temiz kalıyor, test setup’ınız işe konteynerin parçası oluyor. Hatta bazen tam tersi bile işe yarar; önce veriyi konteynerde hazırlarsınız, sonra uygulamayı üstüne oturtursunuz.
Dürüst olmak gerekirse, Bir dakika, şunu da ekleyeyim: benim gözümde bu yaklaşım demo hazırlayan ekipler için de bayağı işe yarar. 2019’da İzmir’de bir satış demosu hazırlarken boş veri ekranından kurtulmak için gece yarısı elle JSON doldurduğumu hatırlıyorum… Neden önemli bu? şimdi böyle şeylere gerek kalmaması güzel ama insanın içinden “nihayet” demesi de normal doğrusu.
/init klasörü neden önemli?
vNext emülatör top-level /init altındaki .csh dosyalarını alfabetik sırayla çalıştırabiliyor. Yanı sız container ayağa kalkmadan önce database oluşturma ve data yükleme işini konteynere bırakıyorsunuz. Bu yaklaşım özellikle CI job’larında tatlı çalışır çünkü her koşuda aynı başlangıç noktasına dönersiniz. Peki neden? Çünkü tekrarlanabilirlik orada para ediyor.
Aşağıdaki örnek yapı gayet anlaşılır:
| Aşama | Neler olur? | Neden iyi? |
|---|---|---|
| 01-init.csh | Database ve container oluşturulur | Tekrarlanabilir başlangıç sağlar |
| 02-load.csh | Kullanıcı ve sipariş verileri yüklenir | Demosuz kuru ortam kalmaz |
| -rm ile reset | Konteyner silinir ve yeniden başlar | Taze laboratuvar gibi davranır |
Yerel emülatörün asıl değeri hızdan çok güven verir; prod’a gitmeden önce davranışı görürsünüz.
Sadece CRUD değil, yeni nesil kullanım alanları da var
Burada, şunu fark ettim: Açık konuşayım, eskiden emülatör deyince akla çoğu zaman sadece temel create/read/update/delete gelirirdi. Bu sürümde tablo biraz genişlemiş durumda:
- daha geniş API kapsaması — ciddi fark yaratıyor
- daha fazla özellik eşleşmesi (bu kritik)
- vector search
- OpenTelemetry support — bunu es geçmeyin
- dahili shell deneyimi
Bunlar kulağa teknik katalog maddesi gibi gelebilir ama pratikte karşılığı var.
Bilhassa vector search tarafı dikkat çekici.
Ben son dönemde Azure AI Foundry ile birlikte veri katmanını tasarlarken şunu sık görüyorum:
uygulama metni anlamaya başlayınca altında yatan datastore’un da buna hazır olması gerekiyor.
Yanı mesele yalnızca belge saklamak değil;
arama,
benzerlik,
öneri,
hatta ajan akışlarına zemin hazırlamak…
E tabi burada ufak bir hayal kırıklığı notu düşeyim:
her yeni özellik ilk günden kusursuz olmuyor.
Emülatör güzel ilerlemiş ama bazı üretim senaryolarının birebir aynısını beklemek fazla iyimser olur.
Kağıt üstünde süper,
pratikte göreceğiz artık.
Ben yine de doğru yönde atılmış ciddi bir adım olduğunu düşünüyorum.
Küçük ekip mi büyük kurum mu?
Şöyle ki, Küçük ekipseniz hedefiniz net olmalı: hızlı geri bildirım döngüsü kurun.
Mesela startup iseniz local dev + Docker Compose + emülatör kombinasyonu sizi bayağı ileri taşır.
Çünkü burada amaç ölçekten önce çevikliktir.
Büyük kurumsal yapıda işe iş biraz daha ağır akar.
Orada önerim şu olur:
emülatör’u doğrudan CI gate’in parçası yapın,
seed dataset’i standartlaştırın,
test çıktısını merkezî loglama ile toplayın.
Aksi hâlde herkes kendi makinesinde “bende çalıştı” der durur…
ve biliyoruz ki o cümle pek sevilmez!
Bende bıraktığı izlenim ve sahadaki karşılığı
Maliyet açısından nasıl düşünmeli?
Maliyet tarafında ilginç bir durum var.
Emülatör’un kendisi yerelde çalıştığı için doğrudan servis maliyetinizi artırmaz;
asıl kazanç yanlış yerde yapılan testleri azaltmanızdan gelir.
Bir müşteride Ocak 2025’te yaptığımız hesapta,
entegrasyon testlerinin %30’u gereksiz canlı bağlantıya gidiyordu.
Bunu emülatöre taşıdığımızda sadece maliyet düşmedi;
pipeline süresi de kısaldı.
TL bazında bakınca fark küçük görünür belki,
ama aylara vurunca can yakar.
Eğer bütçe kısıtlıysa ilk yatırımınız pahalı gözlem araçları değil,
iyi hazırlanmış lokal test altyapısı olsun derim.
Hatta bazı senaryolarda managed olmayan basit Docker tabanlı yaklaşım bile yeterli.
Mesela de PoC aşamasında bunun faydasını çok gördüm;
önce modeli oturtun,
sonra büyütün.
Şişirmeye gerek yok yanı.
İşini görüyorsa tamamdır (inanın bana)
Zorlandığım nokta neydi?
This part needs to be in Turkish only? Tabiî Türkçe devam edelim.
Ben bu servisi ilk denediğimde endpoint keşfi sırasında ufak bir hata aldım;
konteyner ayağa kalkmıştı ama shell tarafı beklediğim şekilde bağlanmamıştı.
Sebep basitti:
port mapping’i kontrol etmemiştim.
Çözüm şuydu:
dokümantasyondaki port eşleşmesini birebir uyguladım
ve wrapper’ın otomatik endpoint algılama mantığını tekrar denedim.
Klasik ama öğretici bir an öldü doğrusu.
Peki kim hemen kullanmalı?
- Cosmos DB kullanan.NET veya JavaScript ekipleri.
- CI/CD pipeline içinde integration test yapan takımlar.
- Demosunda gerçekçi veri göstermek isteyen danışmanlar.
- Ajan ya da AI uygulamalarında düşük gecikmeli lokal veri katmanı isteyenler.
- Cihaz bağımsız geliştirme yapan hibrit ekipler (Maç + Windows karışık yapı).
/ol>
Benim görüşüm net: Cosmos DB vNext emülatör production yerine geçmez ama development disiplinini ciddi biçimde yükseltir.
Sıkça Sorulan Sorular
Cosmos DB vNext emülatör canlı hesap yerine kullanılabilir mi?
Eh, Hayır, birebir üretim ortamının yerine geçmiyor. Ama yanı geliştirme, demo ve entegrasyon testi için gerçekten çok işe yarıyor. Aslında canlı hesaba hiç dokunmadan hızlı denemeler yapmak istiyorsanız bence doğru seçim bu.
Kendi bilgisayarımda ARM64 Maç ile çalıştırabilir mıyım?
Evet, destekleniyor. Apple Silicon tabanlı Maç cihazlarda da Docker image üzerinden kullanılabiliyor. Yanı mesela çapraz platform ekiplerde bu açıdan oldukça kullanım kolaylığı sağlıyor.
Docker init scripts ne işe yarar?
/init altındaki.csh dosyaları konteyner başlamadan önce sırasıyla çalışıyor. Böylece database oluşturma, container açma ve örnek veri yükleme işleri otomatik hâle geliyor. Tecrübeme göre özellikle CI job’larında tekrar eden kurulum adımlarını ciddi ölçüde azaltıyor.
Bunu küçük proje mi yoksa enterprise ortam mı daha çok sevmeli?
Bi saniye — Küçük projeler hız kazanıyor, enterprise yapılar işe standardizasyon elde ediyor. Açıkçası ben özellikle orta-büyük yapılarda CI (söylemesi ayıp) entegrasyonuyla birlikte kullanıldığında değerinin arttığını düşünüyorum. Tek başına mucize yaratmıyor, ama iyi kurgulanırsa bayağı fark ettiriyor (yanlış duymadınız)
Kaynaklar ve İleri Okuma
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.
2 comments