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.
Ben bu haberi okuduğumda ilk aklıma gelen şey hız değil, kontrol öldü. Çünkü 20+ yıldır sistem yönetimi ve bulut işlerinde gördüğüm en büyük dertlerden biri şu: geliştirme ortamı prod’a ne kadar benzerse, saçma hataları yakalama şansı o kadar artıyor. AZ-104. AZ-305 hazırlıklarında da bunu hep söylerim; doğru mimarı sadece servis seçmek değil, test yüzeyini de doğru kurmaktır. Kısacası, mesele biraz da zeminde bitiyor (ki bu çoğu kişinin gözünden kaçıyor)
Bunu biraz açayım.
Neden bu sürüm önemli?
Burada, azure Cosmos DB vNext emülatör artık genel kullanıma açılmış durumda ve bunu küçük bir masaüstü aracı gibi görmek bence eksik kalır. Bu şey doğrudan Docker image olarak geliyor; Linux, macOS ve Windows üzerinde çalışıyor. Üstelik x64 ile ARM64 desteği var. Yanı MacBook kullanan geliştirici de Windows laptop’ta çalışan ekip arkadaşı da aşağı yukarı aynı deneyimi alabiliyor.
Eskiden emülatör ya da lokal veri katmanı denince akla çoğu zaman “kurulum uğraşı” gelirdi. Şifreyi nereye koyacağım, endpoint nasıl bulunacak, seed script ne zaman çalışacak (ki bu çoğu kişinin gözünden kaçıyor). Hani klasik dertler. Burada hoşuma giden nokta şu: tek komutla ayağa kalkıyor ve yerel geliştirme döngüsünü bayağı rahatlatıyor. Basit dürüyor ama etkisi öyle hafif değil (bizzat test ettim)
Çok konuştum, örnekle göstereyim.
Bir de şu var: bunu yalnızca developer laptop’ı için düşünmeyin. Benim bakış açıma göre asıl değer CI tarafında çıkıyor. Kurumsal projelerde testlerin deterministik olması kritik,. Her pipeline koşusunda başka başlangıç verisi varsa sonuçlar da kayıyor. Bir bankacılık projesinde 2024 başında yaşadığımız senaryoda tam olarak buydu; seed mantığını container içine taşıyınca işler toparlandı, açık konuşayım ekip resmen nefes aldı.
Kurulum basit görünüyor, ama etkisi büyük
İlk kurulum komutları zaten oldukça sade:
docker pull mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-latest
docker run -p 8081:8081 -p 8080:8080 -p 1234:1234 mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-latestLafı gevelemeden söyleyeyim: bu sadelik kıymetli. Çünkü çoğu ekipte sorun teknoloji değil, operasyonel sürtünme oluyor. Bir şeyi kurmak kolay değilse kimse düzenli kullanmıyor. Hele startup tarafında iş daha sert; iki kişiyle yürüyen bir ekibin sabah dokuzda emülatör debug etmesine gerek yok. Onlar tek komutla çalışan çözümü ister, nokta.
Enterprise tarafta işe beklenti başka oluyor. Orada mesele sadece çalışması değil; güvenilir olması, tekrar edilebilir olması ve test paketine gömülebilmesi gerekiyor. Büyük kurumlarda ben genelde şöyle düşünüyorum: eğer QA ekibi ayrıysa. Release kapısı sıkıysa bu tip lokal emülatörler altın değerinde olur. Çünkü canlı hesaba dokunmadan entegrasyon testi yaparsınız, sonra kimse “ama prod’da farklıydı” diye zırlamaz.
Evet, doğru duydunuz.
Şö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.shBunun 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 Foundry" data-glossary-term="Azure AI Foundry">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.
İ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