Terminalde JSON Sihirbazlığı: Azure CLI JMESPath
Terminalde JSON Sihirbazlığı: Azure CLI JMESPath
JSON Çorbasında Boğulmaya Son: Neden JMESPath?
Şunu kabul etmek lazım; terminali açtığında ve eline geçen ilk JSON çıktıda havlu atan sadece sen değilsin. En çok da bulut yönetimiyle uğraşıyorsan, çıkan veri sanki “denk gelmişken gömül” diyor (ben de ilk duyduğumda şaşırmıştım). Kendi başıma çok yaşadım: azd ile alınan dataya bakarken gözümde şimşekler çakıyor — nereye bakacağımı şaşırıyorum bazen! Hani “Ya, acaba kolay yolu var mı?” diye soruyorsun kendine… Neyse işte; tam burada JMESPath’ın olayı devreye giriyor – bir anda “bulamadım” derdi ortadan kalkıyor!
Açıkçası,
Peki ya bu JMESPath neyin nesi? Duymayanlar için kısa bir özet patlatayım hemen: JSON yapısında gezinebilmeni sağlayan böl filtreli, esnek. -inandırıcı bulmasam da söylüyorum – güçlü bir sorgu dili. AWS CLI tarafında yıllardır vardı mesela (kıskandıysan normal),. Azure Developer CLI (azd)’ye yeni geldi sayılır. Geçen ay gerçek ortamda bir müşterinin otuz farklı environment’ından yalnızca default olanı seçmem gerekiyordu — jq ile iki takla atıyordum eskiden; şimdi işe tek bayrak yeterli oluyor diyebilirim.
JMESPath Sorgularına Giriş
JMESPath ile en temel düzeyde yapabileceklerini öğrenmek büyük rahatlık. Bir örnek vereyim: bir JSON dizisinden sadece belirli bir alanı çekmek, bazen hayat kurtaracak kadar hızlı işler görüyor. İlk bakışta yabancı gelebilir; ama alışınca asla bırakamıyorsun. Bir keresinde (2023 yazıydı) bir projede Azure Function uygulamalarının listesini çekmem, sadece ‘name’ alanına ihtiyacım vardı. Koca JSON içinden tek satırda şöyle çekebildim:
azd functionapp list - o json --query "[].name"
Bence,
Bunu jq ile kırk takla atarak yapmak yerine, JMESPath ile tek atışta hallettim desem abartı olmaz!
Azure’da JMESPath’in Yükselişi
Ne yalan söyleyeyim,
AWS camiasında başından beri olan JMESPath, Azure tarafında işe son iki yılda adeta “kapanmamış bir borcu” yerine getirmiş gibi. Benim gibi hem AWS hem Azure kullananlar, “nihayet Azure da uyandı!” diyor. Mesela 2022’nın sonlarına doğru bir çok müşterim Azure CLI ile custom scriptlere gömülüp veri çekip filtrelemeye çalışıyordu. Herkes jq yüklüyor, bash dosyaları birbirine giriyordu. Şimdi çoğunu çöpe attık!
--query Bayrağıyla Terminalde Data Avcılığı
Bilen Bilir: Otomasyonun Kalbi Doğrudan Çıktıda Saklıdır
Otomasyonsuz duramayanlardan mısın? Ben şahsen script yazmadan yaşayamıyorum galiba… Artık azd’nın “-o json –query” kombinasyonu hayat kurtarıyor — hem de hiç kasmaya gerek yok! Mesela environment isimleri lazım dedin ya; JSON veriyi alıp başka programdan geçirmene aslında gerek yok artık.
(evet, doğru duydunuz)
JMESPath desteği azd 1.23.4 ve sonrası sürümlerde bulunuyor! Senden düşük versiyon çıkaramazsın yanı.
- Sadece ihtiyacın olan alan:
azd config show - o json --query "template.sources"Emir verdikten sonra platforma ait sadeleşmiş bir çıktı geliyor:
{ "awesome-azd": { "key": "awesome-azd", "location": "https://aka.ms/awesome-azd/templates.json", "name": "Awesome AZD", "type": "awesome-azd" } }Devasa JSON çöplüklerinde boğulanlar bilir — sadece asıl merak ettiğin bölümü net alıyorsun burdan.
- Sık kullandığım automation trick’i:
Kendime not gibi davranırım bazen — varsayılan environment adını shell’e almak istersen:ENV_NAME=$(azd env list - o json --query "[?IsDefault].Name | [0]")Koy pipeline’a — bitti gitti!
Gerçek Hayattan Otomasyon Senaryosu
2024’te bir müşterimde, 120’den fazla resource group’u olan bir ortamda, belirli isimdeki service’lerin lokasyonunu çekmem gerekti (kendi tecrübem). Eskiden jq ile uzun satırlarla uğraşmak gerekiyordu; şimdi işe şöyle bir satır yetiyor:
(buna dikkat edin)
az resource list - o json --query "[?type=='Microsoft.Web/sites'].{name:name, location:location}"
Bunu pipeline’da kullanınca bana zaman kazandırdı ve kod okunabilirliği arttı.
Farklı Platformlarda JMESPath Kullanımı
JMESPath sadece azd’de değil, klasik Azure CLI (az) komutlarında da kullanılabiliyor. Misal, Azure AD kullanıcılarını alabildiğin gibi output’u sadeleştirebilirsin:
az ad user list --query "[].{DisplayName:displayName, User:userPrincipalName}"
Böylece, PowerShell ve Bash scriptlerinde JSON parse etmeye uğraşmadan aradığın veriye doğrudan erişiyorsun.
Kendi Deneyimlerimle JMESPath’in İncelikleri ve Tuzakları
Açıkçası Her Şey Masal Gibi Değil… Pratikte Karşılaştıklarım:
Geçen gün canlıdaki garip bir authentication mesajını hızlıca çekmem gerekti o telaşta. Açık konuşayım önceden koca log’u indirmekten üşengeçlik yüzünden işi uzatırdım… Şimdi işe: Bu konuyla ilgili Birden Fazla Veritabanını Tek API ile Bağlamak: Data API Builder’ın Multi-Source Sihri yazımıza da göz atmanızı tavsiye ederim.
azd auth token - o json --query "data.message"
Bingo!
“nERROR: not logged in, run `azd auth login` to loginn”
Çok Katmanlı JSON ile Baş Etme Yöntemlerim
Tabiî şu unutulmamalı— çok katmanlı nested yapılarda yanlış tırnaklarla veya { köşe parantezi } karmasıyla arada kafanı duvara vurabilirsin (neredeyse kod yazacağıma CSV export edesim geliyordu!). Bir de eski azd komutlarında her şey daha entegre çalışmıyor olabilir; örneğin komuttan dönen output gerçekten JSON mu diye kontrol etmeden umuda güvenip ilerleme…
Gerçekten bazısı dümdüz metinle tokatlıyor insanı!
2022 Eylül ayında yaşadığım bir olay: Bir müşterinin kaynağında nested bir array içinde aranan anahtar hep null dönüyordu. Kendi yazdığım query’de küçük bir karakter hatası, 20 dakika aramamı sağladı. JMESPath’de noktayı, köşeli parantezi yanlış yere koyarsanız sonuç bazen bomboş geliyor. Hemen jmespath.org‘da online deneme yapmaya geçtim!
Filtreleme, Haritalama ve Pipe: Derinlemesine Kontrol
Bak şimdi,
JMESPath’in [?] (filter), []. (haritalama) ve | (pipe) operatörleriyle toplu işlemler hayli kolay. Örnek bir query:
az network vnet list - o json --query "[?contains(name, 'prod')].[name, location]"
prod adını içeren VNet’leri hızlıca dökebiliyorsun. Bu tip fonksiyonellik, filtreleme ve toplama işlemlerini çok pratik kılıyor, kod karışıklığının önüne geçiyor.
Peki Ya Dezavantajları ve İpuçları?
Dürüst anlatımlar önemli bence… Evet kulağa cool geliyor ama her şey yolunda mı gidiyor dersiniz? Daha fazla bilgi için azure ile ilgili önceki yazımız bakabilirsiniz.
- Karmaşık Sorgularda Kafa Karışıklığı:
Birbirinin içine geçmiş data varsa ilk başlarda “Eyvah nerede yanlış yaptım?” sendromu kaçınılmaz oluyor. - Dökümansız Alanlar:
Mesela bazı kendi çıkardığın custom çıktılarda hangi property nerde bitiyor tahmin zor! Durup “Buraya hangi anahtar düşüyor?” demişliğim çoktur. - Sürüm Uyumluluğu:
Aklınızda olsun — script paylaşıyorsan kesinlikle önce azd versiyonunu kontrol etsin kullanıcılar (aksi hâlde niye hata verdiğini saatlerce sorgularsınız). - Kavrayana Kadar Zaman Kaybı:
Söylemesi ayıp hâlâ ben bile dönüp jmespath sitesini kurcalarım. Kırıksız kod yoktur sonuçta…
JMESPath’in fonksiyonlarına ufaktan göz atmayı ihmal etmeyin! Filtreleme ([?]), haritalama ([].alanAdı) veya pipe kullanmak mümkün – yavaş ilerleyin daha kolay öğrenirsiniz.
Küçük hedeflerle başlayın derim.
Büyük toplamlar küçük hamlelerden çıkar…
(Klişe öldü ama doğru.)
Bence deneyimle sabit; özellikle CI/CD akışlarında yahut Azure Developer CLI’de Şubat 2026 Bombaları’nda anlattığım gibi mizahı dertlerin olduğu yerlerde kodu zayıf halkası olmadan dönüştürmek büyük nimet (inanın bana) (Ben hâlâ ara sıra açarım).
| Scriptler başka makinede direkt patladı 😬 | Azd sürümüne tekrar bakılması gerektiğini hatırlat! Minimum version bilgisini özellikle belirtmeni öneririm. |
| Hata mesajının içinden öz bilgi alamıyorsun (mesela auth error’da) | Yeni düzende hep “data.message”‘a odaklanmak mantıklı çözüm sunabilir. |
Pratik İpuçları ve Sıkça Sorulan Sorular
JMESPath ile starts_with veya contains gibi fonksiyonları nasıl kullanırım?
En çok sorulanlardan biri… Mesela “prod” ile başlayan kaynakları bulmak için şöyle bir sorgu işini görür:
az group list --query "[?starts_with(name, 'prod')].[name, location]"
Ya da içinde “web” geçenleri:
az resource list --query "[?contains(name, 'web')].[name, location]"
Çok pratik!
Nested (iç içe) JSON’da istediğim alanı nasıl alabilirim?
İç içe objelerde noktayla gezebilirsin. Örneğin:
azd project show - o json --query "project.metadata.owner.email"
Ama bazen bir array içindeyse, []. operatörüyle çoklu değerler döndürür.
Hata alınca örnek JSON’u görüp ona göre sorgu geliştirme önemli.
JMESPath ile filtre sonuçlarını sıralayabilir mıyım?
Maalesef “sort_by” fonksiyonu Azure CLI’da tam desteklenmiyor (en azından benim deneyimim böyle). Ama mümkün olan durumlarda; örneğin:
az group list --query "sort_by([], & name)[].name"
Ama bazı karmaşık objelerde native sıralama beklediğin gibi çalışmayabilir. Alternatif olarak output’u bash veya PowerShell ile sıralayabilirsin.
Neden bazen çıktım boş geliyor? Nerede hata yapıyorum?
Genelde JSON’un yapısıyla query’nın uyumsuzluğu bu sorunu çıkarıyor.
İpucu: azd komutunu - o json ile sade çekip, JMESPath online aracı ile deneysel sorgu yapabilirsin (evet, doğru duydunuz). Böylece nerede hata yaptığını bulmak kolaylaşıyor.
JMESPath ile dönen değeri shell değişkenine atamak için ipucu var mı?
Evet! Bunu çoğunlukla şöyle kullanıyorum:
RG_NAME=$(az group list - o json --query "[0].name" -r)
Buradaki -r (resource) parametresiyle düz string döndürür. Bunu pipeline’lara koymak çok kolay.
Birkaç Son Söz & Geleceğe Kısa Bakış…
Laf lafı açtı tabiî. Eninde sonunda şuna bağlayacağım konuyu:
JMESPath desteğiyle birlikte azd sadece geliştiricilerin panel butonu değil bence,
aynı zamanda otomasyon bağımlılarının sabah kahvesi!
Neden derseniz;
artık kompleks yapıların altında kaybolmadan iş akışı rahatlatılıyor,
ancak pratikte biraz kafa patlatmanız şart,
aksi durumda gene kaybolmak garanti:)
Gerçekten.
Bana sorarsanız;
En sevdiğim yönü ne biliyor musunuz:
Yan araçlarla oyalanmadan
terminalden ihtiyaç duyduğun spesifik sonucu nokta atışı çekebiliyorsun artık.
Farklı ekiplerle çalışırken herkes kendi query’sını şekillendirirse işler su gibi akar…
Sen hangi CLI’da böyle yenilik görmek isterdin?
Veya seni en son hangi çıktı sinirlendirdi?
Bence aşağıya yazalım tartışalım hani…
Kaynak isteyenler için hazır link bıraktım:
Azure Developer CLI’de Şubat 2026 Bombaları.
Sorunuz olsa DM’ye de beklerim 😊
Güncel Azure gelişmelerinden anlık haberdar olmak istiyorsan takipten ayrılmayın derim…
(Kapatmadan önce not düşeyim.)
Yanı yollar açık — dene yanıl paylaş!
Özet bu…
Kaynaklar ve İleri Okuma
- JMESPath support comes to azd JSON output (Resmî Azure Bloğu)
- Azure Developer CLI — Config ve Query Kullanımı
- JMESPath Resmî Tutorial ve Dokümantasyon
- Azure CLI’da –query Bayrağı Kullanımı
- JMESPath Python Kütüphanesi (GitHub)
İçeriği paylaş:
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