Azure App Service Linux’ta FastAPI Dağıtımı Sadeleşti

Azure App Service for Linux üzerinde FastAPI uygulamalarını çalıştırmak, uzun süredir küçük ama can sıkıcı bir ek adım gerektiriyordu: ASGI destekli bir sunucunun devreye girebilmesi için elle startup command tanımlamak. Azure App Service ekibinin duyurduğu son iyileştirmeyle bu adım ortadan kalkıyor. Platform artık FastAPI uygulamalarını otomatik tanıyıp uygun başlatma davranışını kendisi yapılandırıyor.

İlgili içerik: Azure Portal'dan ZIP ile App Service Dağıtımı Kolaylaştı

İlgili içerik: Azure App Service Linux'ta Deferred Kudu Recycle ile

Bu yazıda kaynak duyuruya dayanarak neyin değiştiğine, tespit mantığının nasıl çalıştığına, uygulamanızı hangi komutun ayağa kaldırdığına ve birden fazla framework belirtisi olduğunda önceliklendirmenin nasıl yürüdüğüne bakacağız.

Önceki durumda ne yapmak gerekiyordu?

FastAPI, ASGI (Asynchronous Server Gateway Interface) tabanlı bir Python web framework’ü. Bu yüzden klasik WSGI sunucularıyla doğrudan çalışmaz; önünde Uvicorn gibi bir ASGI sunucusu ya da Uvicorn worker sınıfını kullanan bir Gunicorn yapılandırması bulunması gerekir.

App Service üzerinde Python uygulaması yayınlandığında bu yapılandırma otomatik yapılmıyordu. Geliştiricinin, uygulamanın doğru başlatılabilmesi için özel bir başlatma komutu girmesi bekleniyordu. FastAPI’yi App Service üzerinde ilk kez deneyen kullanıcılar için ek bir sürtünme noktasıydı bu.

Neyin değiştiği: Otomatik FastAPI tespiti

Azure App Service ekibinin duyurusuna göre platforma yerleşik bir tespit mantığı eklendi. Bir Python uygulaması dağıtıldığında App Service, yaygın giriş noktası dosyalarını tarayarak uygulamanın FastAPI olup olmadığını anlamaya çalışıyor.

Taranan dosya adları şunlar:

• main.py
• app.py
• application.py
• server.py
• asgi.py
• api.py
• index.py
• run.py

Bu dosyalardan herhangi biri from fastapi ya da import fastapi ifadesiyle FastAPI’yi içe aktarıyorsa App Service uygulamayı FastAPI olarak sınıflandırıyor.

Yanlış pozitiflerin önüne geçmek için bir güvenlik önlemi de var: Aynı dosyada Flask de içe aktarılmışsa, o dosya FastAPI tespiti sırasında atlanıyor. Böylece aynı projede iki framework’ün ipuçları birlikte bulunduğunda yanlış tanıma engellenmiş oluyor.

Uygulamanız nasıl başlatılıyor?

FastAPI olarak algılanan bir uygulama tespit edildiğinde App Service, Gunicorn’u Uvicorn worker sınıfıyla çalıştırıyor. Otomatik kullanılan komut şu:

gunicorn -k uvicorn_worker.UvicornWorker

Bu yapılandırma, FastAPI’nin ihtiyaç duyduğu ASGI desteğini doğrudan sağlıyor. Geliştiricinin bu komutu elle tanımlamasına gerek kalmıyor; runtime akışı uygun sunucu yapılandırmasını kendiliğinden devreye alıyor.

Birden fazla framework varsa öncelik sırası

Gerçek dünya projelerinde bir Python deposu içinde birden çok framework’e ait dosya ya da içe aktarma ifadesi bulunabilir. Bu tür durumlar için App Service’in izlediği bir öncelik sırası tanımlı:

1. Django
2. FastAPI
3. Flask

Django, hem FastAPI hem Flask’a göre öncelikli. Özellikle bir alt dizinde wsgi.py dosyası bulunduğunda Django önceliği korunuyor. FastAPI ise Flask’ın önüne geçiyor. Bu sıralama, karışık ya da geçiş halindeki projelerde platformun hangi framework davranışını uygulayacağını belirlemek açısından önemli.

Bu değişiklik sizin için ne anlama geliyor?

Pratik sonuç net: Azure App Service for Linux üzerine bir FastAPI uygulaması dağıtırken, desteklenen runtime akışında artık özel bir startup command tanımlamanız gerekmiyor. Oryx build sistemi uygulamayı FastAPI olarak algılıyor ve başlatma davranışını otomatik yapılandırıyor.

Özellikle şu senaryolarda faydalı:

• FastAPI’yi App Service üzerinde ilk kez deneyen geliştiriciler için giriş engelinin azalması.
• CI/CD boru hatlarında startup command yönetimine ayrılan ek yapılandırmanın sadeleşmesi.
• Şablon veya hızlı başlangıç projelerinde manuel adımların gerekmemesi.

Kurulum sırasında atlanması gereken bir adım daha ortadan kalkıyor ve FastAPI uygulamalarını App Service üzerinde ayağa kaldırmak daha az sürtünmeli hale geliyor.

Kullanılabilirlik

Duyuruya göre bu iyileştirme şimdilik Python 3.14 ve sonraki sürümler için etkinleştirilmiş durumda. Ek Python sürümlerine yönelik desteğin ilerleyen bir dağıtımla devreye alınacağı belirtiliyor. Daha eski Python sürümlerinde çalışan FastAPI uygulamalarının halihazırdaki startup command yaklaşımını sürdürmesi gerekiyor.

Özet

Azure App Service ekibinin FastAPI için eklediği otomatik tespit ve başlatma yapılandırması, Python geliştiricileri açısından küçük ama etkili bir kalite iyileştirmesi. Belirli dosya adlarında FastAPI içe aktarmasının bulunması yeterli; platform uygulamayı Gunicorn üzerinden Uvicorn worker’ı ile başlatıyor. Django önceliği korunurken FastAPI, Flask’ın önüne geçen bir konumda tanımlı. Değişiklik Python 3.14 ile kullanılabilir; gelecek dağıtımlarda daha geniş bir sürüm yelpazesine ulaşması planlanıyor.

Kaynaklar ve İleri Okuma

• Simplifying FastAPI Deployments on Azure App Service for Linux — Azure App Service Blog
• Azure App Service Python Quickstart — Microsoft Learn
• Python AI Uygulamalarında Azure App Service: Hız Kazandıran Sessiz Değişim
• Azure App Service Linux’ta Startup Log Komutları
• Kudu’da Log Görüntüleme: Linux App Service için Yeni Sayfa