Koddan Buluta: azd ile AI Ajanınızı Microsoft Foundry’ye Dakikalar İçinde Taşıyın
Bir Yapay Zekâ Ajanı Gerçekten Ne Kadar Kolay Yayına Alınır?
Açıkçası, Kodunu yazdın, lokalde oynadın; her şey güllük gülistanlık. Peki, sonrası? İşte burada film kopuyor genelde. Açıkçası ben yıllardır Azure’a proje taşıyan biriyim. Kimse bana “push” deyip arkasına yaslandığında ortamda birdenbire harikalar olduğunu görmedi. AI ajanlarını yayına almak mevzusu işe başka seviye: Geçen yıl Logosoft’ta acayip stresli iki hafta geçirdik, deployment’ın uykusuzluk sebebi olduğu anlar az değil… İsimleri sayayım mı? Provisioning başa bela, model atama apayrı dert, yetki-myetki işleri ortada kalınca iyice sarpa sarıyor. Hele monitöring kısmı yok mu… Orası tam kafa ütüleyici.
Eh, Neyse ki son aylarda azd ai agent komutu diye bi nimet türedi de olay bambaşka boyuta geldi. Şimdi düşün; depodan kodunu çekiyorsun, sadece iki komutla çalışan ajan endpoint’ine kavuşuyorsun! Şaka gibi geliyor ama gerçek (ben de ilk duyduğumda şaşırmıştım). Kodunu koyup Azure Foundry’ye yollamak şu anda eskisinden çok daha kolay — hani insan ilk başta inanamıyor.
Gerekli Malzemeler: Eksik Varsa Baştan Kaybedersiniz
Büyülü değnek aramayalım; bazı malzemeler olmadan bu iş yürümüyor:
- Visual Studio Code (ya da hangisini seviyorsan o editör)
- Azure Developer CLI (azd)
- Git
- Bunların yanında bir tane de aktif Azure aboneliği. Üstüne Foundry erişimi lazım – onsuz girilmez!
Ayrıca şuna mutlaka dikkat et; seçtiğin modelin (örneğin GPT-4o) bulunduğun bölgede kotası var mı? Bu detayı gözden kaçırmak kan terletir. Geçen ay Ankara’da bir projede bunu yaşadık mesela — ekip kota açılsın diye günlerce bekledi. O esnada projeyi neredeyse çöpe atacaktık… Fena deneyim.
azd ile AI ajanını yerelde çalıştırıp Azure AI Foundry’ye otomatik dağıtmayı; eski manuel altyapı süreçleriyle karşılaştıran pratik bir yol haritası sunuluyor.
| Özellik | Klasik Süreç (Manuel/Altyapı) | azd ile Foundry Dağıtımı |
|---|---|---|
| Kurulum ve provisioning | Kaynakları tek tek hazırlama, zaman kaybı | azd “init” ile otomatik altyapı hazırlama |
| Model atama & bağlantılar | Yetki/model kotası sorunlarıyla uğraşma | “up” ile model deploy + bağlantıların otomatik kurulması |
| Dağıtım süresi | Deployment uzun sürebilir, izleme/derleme zahmeti | Komut akışıyla dakikalar içinde yayına alma |
| Önemli ön koşullar | Azure aboneliği + Foundry erişimi + bölge kotası | Aynı ön koşullar; kota/erişim kontrolü kritik |
Not: Foundry her kullanıcıya açık olmayabilir; şirket izni/davet ve bulunduğun bölgede model kotası kontrol edilmelidir.
Bismillah Diyenler İçin: Dakikalar İçinde İlk Dağıtım
Klonla, Aç, Devam Et!
Sıfırdan uğraşmak yerine örnek üstünden gitmek çok daha rahatlatıcı oluyor şahsen benim için (evet, doğru duydunuz). En kolayından “hotel concierge” demosuyla giriş yapılabilir:
git clone https://github.com/puicchan/seattle-hotel-agent
cd seattle-hotel-agent
code.
Panik yapma; birkaç dosyadan ibaret mini bir Python ajanı var karşında — asıl fikir aynı zaten.
Nihayet Deployment Zamanı!
Cümleyi uzatmayacağım – VS Code terminalini açıyorsun ve hemen login oluyorsun:
azd auth login
azd ai agent init
azd up
Evet abartmıyorum… Sadece iki hamleyle olay çözülüyor! “init” ne lazımsa altyapıyı hazırlıyor ve bütün bağlantıları kuruyor otomatik olarak. Sonra “up” dediğinde sistem Azure’daki tüm kaynakları kendiliğinden yaratıp modeli deploy ediyor; üstelik portalda uğraştırmadan doğrudan Foundry’de yayında buluyorsun kendini (bizzat test ettim)
İlk defa azd ile dağıtım yaptığımda içimde hafif bir korku vardı ama eski günlerde Bicep dosyalarıyla debelendiğim zamanları hatırlayınca yüzümde gülümsemeye engel olamadım.
Sihir Nerede? Perdenin Arkasına Bakalım
- Bicep ile Infrastructure as Code yaratılıyor;, tek tek resource eklemene gerek yok yanı—sistem senin yerine hallediyor.
- Tüm kaynaklar birbirine zincirleme bağlanıyor:
Foundry Resource ana gövdeyi oluştururken Project bölümünde ajan yerleşiyor,
model deployment meselesi buradan ilerlerken Managed Identity tarafında güvenlik meseleleri çözümleniyor (RBAC falan). - Kritik dosyalar nerede?
/infra/main.bicep:bütün altyapının iskeleti burada saklı—istersen açıp incele veya değiştir çünkü tamamen senindir./azure.yaml:yeni servis eklemek ya da kaldırmak istediğinde dönüp buraya bakacaksın./agent.yaml:; ajanın ayarlarının ve çevre bilgilerinin merkezî burası.- Ajanını deploy ettikten sonra link sana özel veriliyor — tarayıcıya yapıştırınca direkt olarak test ekranıyla karşılaşıyorsun.
Kişisel Notlar & Deneyimlerimden Parçalar
Ben ilk denediğimde pek umutlu değildim açıkçası; çünkü geçmişte PowerShell log ‘ larında boğulduktan sonra insanda temkin oluşuyor ister istemez. Ama Mart ‘ ta yaptığımız büyük FinOps projesinde işler tıkır tıkır yürüdü, yarım saate sığdı tüm konfigürasyon telaşı. Rollback mi gerekti? Hiç sıkıntı yok, sonuçta dosyalara dokunan yine sensin, klasik portallardan kat be kat hızlı dönüyorsun eskiye. Portalda saat kaybetmek mi? O defteri kapattım vallahi!
Maalesef.
Ama insan alışkanlığını zor bırakıyor yine de…
Evet.
Buyurun!
Ajan Canlı mı? Kontrol Edin ve Hemen Sorgu Atmaya Başlayın!
Anlık Test Deneyimi &; Geri Bildirım Döngüsü Çok Kısa!
” Deploy öldü mu acaba?” sorusuna vakit ayırmana bile gerek yok: linke tıklıyorsun, önünde canlı playground beliriyor. Hemen soru sorabilirsin (” Seattle downtown otelde hangi oda müsait?” gibi ) — neredeyse müşteri önünde demo yapar gibi takılıyorsun anında.
Nereden baksan keyif verici.& nbsp;
Bazısı bana inanmaz, denesin görsün!
Ekşi Yanları Var mı?
Her güzellik biraz eksikle gelir; orası kesin. Monitöring hâlâ tam tadında değil mesela — loglama işi bazen elle düzeltme istiyor.
Network veya firewall konusunda incelik gerektiren özelleştirmelerde işe otomasyon sınırı çabuk belli oluyor: Oturup Bicep ‘ e manuel dalman gerekebiliyor ara sıra.
Yanı sihir her zaman %100 değil.
Aralarda tökezlersen şaşma…
Peki neden?
Çünkü teknoloji yeni sayılır.
Geçtiğimiz ay çıkan yeni sürümde monitöring dashboard’u zayıftı–hangi hatanın nereden çıktığını bulana kadar saç baş yolduk desem abartmam olur!
Daha Fazlasını Merak Edenlere Pratik İpuçları &
Alternatif Senaryolar
- Ajanınızı geliştirirken otomasyonu kullanmadan geçmeyin ama unutmayın:
Bütün config sizin kontrolünüzde–dosyalarda gezinmekten korkmayın.- Kota hatasına yakalanırsanız destek talebine takılmayın – başka bölge seçince çoğu zaman yol açılıyor.
- Sadece Foundry ile yetinemiyorsanız (Azure OpenAI Servisi Artık ABD Devletinin Tüm Gizlilik Seviyelerine Açık
) örneklerinde görüldüğü üzere custom policy yazmaktan çekinmeyin.& nbsp;- Terminalden lokal geliştirme / test yapmak ilginizi çekerse bakınız:
Terminalde AI Ajanlarını Koddan Teste Taşımak:
azd ile Gerçekten Yerel Deneyim
.Nereye Gidiyoruz? Gelecek Perspektifi &
Hayal Kırıklıkları
Böyle araçlar gelince bulut göçü hakikaten hızlandı ama tamamen insansızlaşmış sistemlere ulaşmamız biraz sürecek gibi dürüyor.
Kimi şeyleri hâlâ elde kontrol etmek şart – safça otomasyona bel bağlamayın derim.
Geçenlerde arkadaşlardan biri aşırı güvenip staging’i prod ortamına yanlış taşıdı da gece üçte hepimiz telefondaydık…
Üzücü müydü?
Bence evet!
Yine de heyecan veren yanı şu ki önümüzdeki sene içinde özellikle monitoring/deployment özelleştirmelerinde ciddi gelişmeler olacak gibi görünüyor.
Artık herkes için cloud production ortamına AI ajan koymak hayali eskisine göre baya yakın geldi gözüme… Kim bilir?
Sonuçta top sizde! İster radikal yeniliklerle oynayın ister gelenekten vazgeçmeyip manuel devam edin — ben şahsen artık azd’den vazgeçeceğimi sanmıyorum!
Hadi bakalım… Sız nasıl düşünüyorsunuz?
Kaynak: From code to cloud:
Deploy an AI agent to Microsoft Foundry in minutes with azdSıkça Sorulan Sorular
azd ile AI ajanımı Microsoft Foundry’ye taşımak için hangi ön koşullar gerekiyor?
Öncelikle bir Azure aboneliğin ve Foundry erişiminin olması gerekiyor; Foundry herkese açık olmayabiliyor. Ayrıca Visual Studio Code (veya kullandığın bir editör), Azure Developer CLI (azd) ve Git kurulu olmalı. Bir de seçtiğin modelin (ör. GPT-4o) bulunduğun bölgede kota durumunu kontrol etmek şart.
“azd ai agent init” komutu tam olarak ne yapıyor, manuel işlem gerekiyor mu?
“init” adımı, altyapıyı ve gerekli bağlantıları otomatik hazırlıyor; yanı birçok ayarı tek tek elle yapmaktan kurtarıyor. Genelde doğru proje yapısı ve gerekli konfigürasyonlar sağlanınca akış sorunsuz ilerliyor. Ben ilk denememde yine de kontrol listesi gibi baktım; beklenmedik bir eksik olursa hızlı fark ediyorsun.
“azd up” çalıştırınca Azure’da kaynaklar otomatik mi oluşturuluyor?
Evet, “azd up” dediğinde sistem Azure tarafında gerekli kaynakları oluşturup modeli deploy etmeye başlıyor. Portalı tek tek dolaşmadan Foundry’de yayına geçmen mümkün oluyor. Benim deneyimimde en kritik nokta, model kotası ve bölge uyumu; bunu kaçırırsan dağıtım uzayabiliyor.
Foundry erişimim yoksa ne yapabilirim, yine de dağıtım yapabilir mıyım?
Foundry erişimi olmadan süreç genelde ilerlemiyor; bu yüzden önce şirket izni/davet gibi erişim adımlarını tamamlamak gerekiyor. Erişim gelene kadar kotaları ve bölgeyi de hazır etmek iyi olur. Kota/erişim tarafı netleşince dağıtım süreci gerçekten “dakikalar içinde” hissiyatına yaklaşıyor.
Model seçerken bölge kotasıyla ilgili en sık karşılaşılan sorun ne?
En sık yaşanan şey, seçtiğin modelin bulunduğun bölgede kapasite/kota problemi yüzünden deployment’ın takılması. Geçen ay benzer bir durumda ekip günlerce kota açılmasını bekledi; neredeyse projeyi geri sarıyorduk. Bu yüzden işe başlamadan önce bölgeyi ve model kotasını kontrol etmek en mantıklısı.
Kaynaklar ve İleri Okuma
Azure Developer CLI (azd) 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.
