Aracılığıyla paylaş

Azure App Service için bir Linux Python uygulaması yapılandırın

Azure'a dağıtma

Bu makalede Azure App Service'in Python uygulamalarını nasıl çalıştırdığı, mevcut uygulamaları Azure'a nasıl geçirebileceğiniz ve gerektiğinde App Service'in davranışını nasıl özelleştirebileceğiniz açıklanır. Python uygulamaları tüm gerekli pip modülleriyle dağıtılmalıdır.

App Service dağıtım altyapısı otomatik olarak bir sanal ortamı etkinleştirir ve pip install -r requirements.txt dağıttığınızda veya derleme otomasyonu etkin bir zip paketi dağıttığınızda sizin için çalışır.

Uyarı

Hâlihazırda App Service, projenizin kök dizininde requirements.txt bulunmasını gerektiriyor, hatta pyproject.toml olsa bile. Önerilen yaklaşımlar için bkz. pyproject.toml dosyasından requirements.txt oluşturma .

Bu kılavuz, App Service'de yerleşik bir Linux kapsayıcısı kullanan Python geliştiricileri için temel kavramlar ve talimatlar sunar. Azure App Service'i hiç kullanmadıysanız önce Python hızlı başlangıcını ve PostgreSQL ile Flask, Django veya FastAPI öğreticisini izleyin.

Yapılandırma için Azure portalını veya Azure CLI'yi kullanabilirsiniz:

  • Azure portalında App Service uygulamasını yapılandırma bölümünde açıklandığı gibi uygulamanın >Yapılandırma sayfasını kullanın.

  • Azure CLI: İki seçeneğiniz vardır.

    • Azure Cloud Shell'de komutlar çalıştırın.
    • Azure CLI'nın en son sürümünü yükleyerek komutları yerel olarak çalıştırın, ardından az login kullanarak Azure'da oturum açın.

Uyarı

Linux, App Service'te Python uygulamalarını çalıştırmak için tek işletim sistemi seçeneğidir. Windows üzerinde Python artık desteklenmiyor. Özel Windows konteyner görüntünüzü oluşturabilir ve bunu Uygulama Hizmetinde çalıştırabilirsiniz. Daha fazla bilgi için bkz. Özel Docker görüntüsü kullanma.

Python sürümünü yapılandır

  • Azure portalı: Linux kapsayıcıları için genel ayarları yapılandırma bölümünde açıklandığı gibi Yapılandırma sayfasındaki Genel ayarlar sekmesini kullanın.

  • Azure CLI:

    • az webapp config show ile geçerli Python sürümünü göster:

      az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

      <resource-group-name> ve <app-name> öğelerini web uygulamanıza uygun isimlerle değiştirin.

    • Az webapp config set ile Python sürümünü ayarlama

      az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "PYTHON|3.11"

    • Az webapp list-runtimes ile Azure App Service'te desteklenen tüm Python sürümlerini gösterin:

      az webapp list-runtimes --os linux | grep PYTHON

Desteklenmeyen bir Python sürümünü çalıştırmak için, kendi konteyner imajınızı oluşturarak bunu yapabilirsiniz. Daha fazla bilgi için bkz. Özel Docker görüntüsü kullanma.

App Service'te eski çalışma zamanlarına ne olur?

Eski çalışma zamanları, bakım kuruluşu tarafından kullanımdan kaldırılmıştır veya önemli güvenlik açıkları olduğu tespit edilir. Buna göre, portaldaki oluşturma ve yapılandırma sayfalarından kaldırılırlar. Süresi geçmiş bir çalışma zamanı portaldan gizlendiğinde, bu çalışma zamanını kullanmaya devam eden tüm uygulamalar çalışmaya devam eder.

Portalda artık gösterilmemiş bir eski çalışma zamanı sürümüne sahip bir uygulama oluşturmak istiyorsanız Azure CLI, ARM şablonu veya Bicep'i kullanın. Bu dağıtım alternatifleri, portalda kaldırılmış ancak hala desteklenmeye devam eden kullanım dışı çalışma zamanları oluşturmanıza olanak tanır.

Bir çalışma zamanı App Service platformundan tamamen kaldırılırsa, Azure aboneliği sahibiniz kaldırmadan önce bir e-posta bildirimi alır.

Yapı otomasyonunu özelleştir

Uyarı

Python uygulamaları yapı otomasyonu ile dağıtıldığında, içerik /tmp/<uid> altında değil, /home/site/wwwroot konumuna dağıtılacak ve buradan sunulacaktır. Bu içerik dizinine APP_PATH ortam değişkeni aracılığıyla erişilebilir. Çalışma zamanında oluşturulan tüm ek dosyalar, kalıcılık için /home altında veya kullanılarak bir konuma yazılmalıdır. Bu davranış hakkında daha fazla bilgiyi burada bulabilirsiniz.

App Service'in Oryx adlı derleme sistemi, uygulamanızı dağıttığınızda ve uygulama ayarı SCM_DO_BUILD_DURING_DEPLOYMENT olarak 1 ayarlandığında aşağıdaki adımları gerçekleştirir:

  1. Belirtilmişse, PRE_BUILD_COMMAND ayarı tarafından belirtilen özel bir ön yapı betiği çalıştırın. (Betik, diğer Python ve Node.js betiklerini, pip ve npm komutlarını, ve yarn gibi Node tabanlı araçları kendisi çalıştırabilir, örneğin yarn install ve yarn build.)

  2. Çalıştır pip install -r requirements.txt. requirements.txt dosyası projenin kök klasöründe bulunmalıdır. Aksi takdirde, derleme süreci şu hatayı bildirir: "setup.py veya requirements.txt dosyası bulunamadı; pip install çalıştırılmıyor."

  3. manage.py deponun kökünde bulunursa ( Django uygulamasını gösterir), collectstatic manage.py çalıştırın. Ancak, DISABLE_COLLECTSTATIC ayarı true ise, bu adım atlanır.

  4. Belirtilen bu adım POST_BUILD_COMMAND ayarıyla varsa, özel yapım sonrası betiğini çalıştır. (Yine, betik diğer Python ve Node.js betiklerini, pip ve npm komutlarını ve Node tabanlı araçları çalıştırabilir.)

Varsayılan olarak, PRE_BUILD_COMMAND, POST_BUILD_COMMAND ve DISABLE_COLLECTSTATIC ayarları boştur.

  • Django uygulamaları oluşturulurken collectstatic çalıştırılmasını devre dışı bırakmak için, DISABLE_COLLECTSTATIC ayarını true olarak belirleyin.

  • Önyükleme komutlarını çalıştırmak için, PRE_BUILD_COMMAND ayarını echo Pre-build command gibi bir komut veya projenizin kök dizinine göre scripts/prebuild.sh gibi bir betik dosyasının yolunu içerecek şekilde ayarlayın. Tüm komutlar proje kök klasörüne göre göreli yollar kullanmalıdır.

  • Derleme sonrası komutları çalıştırmak için, POST_BUILD_COMMAND ayarını echo Post-build command gibi bir komut veya projenizin köküne göre göreli olan bir betik dosyası yolu, scripts/postbuild.sh gibi bir içerik içerecek şekilde ayarlayın. Tüm komutlar proje kök klasörüne göre göreli yollar kullanmalıdır.

Derleme otomasyonlarını özelleştiren diğer ayarlar için bkz. Oryx yapılandırması.

Derleme ve dağıtım günlüklerine erişmek için bkz. Dağıtım günlüklerine erişme.

App Service'in Linux'ta Python uygulamalarını çalıştırma ve derleme hakkında daha fazla bilgi için bkz. Oryx, Python uygulamalarını nasıl algılar ve oluşturur.

Uyarı

PRE_BUILD_SCRIPT_PATH ve POST_BUILD_SCRIPT_PATH ayarları, PRE_BUILD_COMMAND ve POST_BUILD_COMMAND ile aynıdır ve eski sistemlerle uyumluluk sağlamak amacıyla desteklenmektedir.

SCM_DO_BUILD_DURING_DEPLOYMENT adlı bir ayar, true veya 1 içeriyorsa, dağıtım sırasında gerçekleşen bir Oryx yapısını tetikler. true ayarı, Git, Azure CLI komutu az webapp up ve Visual Studio Code kullanılarak dağıtıldığında yapılıyor.

Uyarı

Her zaman tüm öncesi ve sonrası derleme betiklerinde göreceli yolları kullanın çünkü Oryx'in çalıştığı derleme konteyneri, uygulamanın çalıştığı çalışma zamanı konteynerinden farklıdır. Uygulama proje klasörünüzün kapsayıcı içindeki tam yerleşimini (örneğin, site/wwwroot altına yerleştirilmiş) hiçbir zaman güvenmeyin.

requirements.txt dosyasını pyproject.toml'dan oluştur

App Hizmeti şu anda pyproject.toml için doğrudan destek sağlamıyor. Eğer Poetry veya uv gibi araçlar kullanıyorsanız, önerilen yaklaşım, projelerinizin kök dizininde uyumlu bir requirements.txt oluşturmaktır.

Şiiri Kullanmak

Poetrydışarı aktarma eklentisiyle kullanma:


poetry export -f requirements.txt --output requirements.txt --without-hashes

Uv kullanma

uv kullanma:


uv export --format requirements-txt --no-hashes --output-file requirements.txt

Mevcut uygulamaları Azure'a taşıyın

Mevcut web uygulamaları aşağıdaki şekilde Azure'a yeniden dağıtılabilir:

  1. Kaynak depo: Kaynak kodunuzu GitHub gibi uygun bir depoda tutarak bu işlemin ilerleyen bölümlerinde sürekli dağıtım ayarlayabilirsiniz.

    • requirements.txt dosyanızın, app service'in gerekli paketleri otomatik olarak yükleyebilmesi için deponuzun kökünde olması gerekir.

  2. Veritabanı: Uygulamanız bir veritabanına bağımlıysa, Azure'da da gerekli kaynakları oluşturun.

  3. App Service kaynakları: Uygulamanızı barındırmak için bir kaynak grubu, App Service planı ve App Service web uygulaması oluşturun. Bunu kolayca Azure CLI komutunu az webapp up çalıştırarak yapabilirsiniz. Alternatif olarak, Flask, Django veya FastAPI ile PostgreSQL öğreticisinde gösterildiği gibi kaynakları oluşturabilir ve dağıtabilirsiniz. Uygulamanız için daha uygun olacak şekilde kaynak grubunun, App Service planının ve web uygulamasının adlarını değiştirin.

  4. Ortam değişkenleri: Uygulamanız herhangi bir ortam değişkeni gerektiriyorsa eşdeğer App Service uygulama ayarları oluşturun. Bu App Service ayarları, Access ortam değişkenlerinde açıklandığı gibi kodunuz için ortam değişkenleri olarak görünür.

  5. Uygulama başlatma: App Service'in uygulamanızı çalıştırmaya nasıl çalıştığını anlamak için bu makalenin devamında Yer alan Kapsayıcı başlatma işlemi bölümünü gözden geçirin. App Service varsayılan olarak Gunicorn web sunucusunu kullanır. Bu sunucu, uygulama nesnenizi veya wsgi.py klasörünüzü bulabilmelidir. Gerekirse başlangıç komutunu özelleştirebilirsiniz.

  6. Sürekli dağıtım: Azure App Service'e sürekli dağıtım makalesinde açıklandığı gibi GitHub Actions, Bitbucket veya Azure Repos'tan sürekli dağıtımı ayarlayın. Alternatif olarak, Azure App Service'e yerel Git dağıtımı makalesinde açıklandığı gibi Yerel Git'ten sürekli dağıtım da ayarlayabilirsiniz.

  7. Özel eylemler: Uygulamanızı barındıran App Service kapsayıcısı içinde Django veritabanı geçişleri gibi eylemler gerçekleştirmek için SSH aracılığıyla kapsayıcıya bağlanabilirsiniz. Django veritabanı geçişlerini çalıştırma örneği için bkz . Öğretici: PostgreSQL ile Django web uygulaması dağıtma - veritabanı şeması oluşturma.

    • Sürekli dağıtım kullanırken, derleme otomasyonlarını özelleştirme altında daha önce açıklandığı gibi derleme sonrası komutları kullanarak bu eylemleri gerçekleştirebilirsiniz.

Bu adımları tamamladıktan sonra, kaynak deposunuza değişiklikleri kaydedebilmeli ve bu güncellemelerin App Service'e otomatik olarak yüklenmesini sağlamalısınız.

Django uygulamaları için üretim ayarları

Azure App Service gibi bir üretim ortamı için Django uygulamaları Django'nun Dağıtım denetim listesini izlemelidir.

Aşağıdaki tabloda Azure ile ilgili üretim ayarları açıklanmaktadır. Bu ayarlar uygulamanın setting.py dosyasında tanımlanır.

Django ayarı Azure için Talimatlar
SECRET_KEY Değeri , Access uygulama ayarlarında ortam değişkenleri olarak açıklandığı gibi bir App Service ayarında depolayın. Değerinizi alternatif olarak Azure Anahtar Kasası'nda bir sır olarak saklayabilirsiniz.
DEBUG App Service üzerinde değerini 0 (false) olarak ayarlayın, ardından bu değeri bir ortam değişkeni olarak yükleyin. Geliştirme ortamınızda, değer 1 (doğru) olan DEBUG ortam değişkeni oluşturun.
ALLOWED_HOSTS Üretimde Django, uygulamanın URL'sini ALLOWED_HOSTS dizisine eklemenizi gerektirir. Çalışma zamanında bu URL'yi os.environ['WEBSITE_HOSTNAME'] koduyla alabilirsiniz. App Service, WEBSITE_HOSTNAME çevre değişkenini uygulamanın URL'sine otomatik olarak ayarlar.
DATABASES Uygulama Hizmetinde veritabanı bağlantısı için ayarları tanımlayın ve DATABASES sözlüğünü doldurmak için çevre değişkenleri olarak yükleyin. Alternatif olarak değerleri (özellikle kullanıcı adı ve parola) Azure Key Vault gizli dizileri olarak depolayabilirsiniz.

Django uygulamaları için statik dosyalar sunma

Django web uygulamanız statik ön uç dosyaları içeriyorsa, önce Django belgelerindeki statik dosyaları yönetme yönergelerini izleyin.

App Service için aşağıdaki değişiklikleri yaparsınız:

  1. Django STATIC_URL ve STATIC_ROOT değişkenlerini dinamik olarak ayarlamak için (yerel geliştirme için) çevre değişkenlerini ve (buluta dağıtım yaparken) Uygulama Ayarlarını kullanmayı düşünün. Örneğin:

    STATIC_URL = os.environ.get("DJANGO_STATIC_URL", "/static/")
STATIC_ROOT = os.environ.get("DJANGO_STATIC_ROOT", "./static/")

    DJANGO_STATIC_URL ve DJANGO_STATIC_ROOT yerel ve bulut ortamlarınız için gerektiği gibi değiştirilebilir. Örneğin, statik dosyalarınızı adınıdjango-static olarak belirlediğiniz bir klasöre yerleştiriyorsa, DJANGO_STATIC_URL ayarını /django-static/ olarak belirleyerek varsayılan ayarı kullanmaktan kaçınabilirsiniz.

  2. Farklı bir klasörde statik dosyalar oluşturan bir derleme öncesi betiğiniz varsa, Django'nun STATICFILES_DIRS işleminin bunları bulması için bu klasörü Django collectstatic değişkenine ekleyin. Örneğin, yarn build komutunu ön uç klasörünüzde çalıştırdığınızda ve yarn, statik dosyalar içeren bir build/static klasörü oluşturduğunda, bu klasörü aşağıdaki şekilde ekleyin:

    FRONTEND_DIR = "path-to-frontend-folder" 
STATICFILES_DIRS = [os.path.join(FRONTEND_DIR, 'build', 'static')]

    Burada, FRONTEND_DIR, yarn gibi bir derleme aracının çalıştırıldığı yere giden bir yol oluşturmak için kullanılır. Çevre değişkenini ve Uygulama Ayarını istediğiniz gibi tekrar kullanabilirsiniz.

  3. whitenoise'ı requirements.txt dosyanıza ekleyin. WhiteNoise (whitenoise.evans.io), üretim Django uygulamasının kendi statik dosyalarına hizmet vermesini kolaylaştıran bir Python paketidir. WhiteNoise, Django STATIC_ROOT değişkeni tarafından belirtilen klasörde bulunan dosyalara özel olarak hizmet eder.

  4. settings.py dosyanıza WhiteNoise için aşağıdaki satırı ekleyin:

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Ayrıca MIDDLEWARE ve INSTALLED_APPS listelerini, WhiteNoise'u içerecek şekilde değiştirin:

    MIDDLEWARE = [                                                                   
    'django.middleware.security.SecurityMiddleware',
    # Add whitenoise middleware after the security middleware                             
    'whitenoise.middleware.WhiteNoiseMiddleware',
    # Other values follow
]

INSTALLED_APPS = [
    "whitenoise.runserver_nostatic",
    # Other values follow
]

Flask uygulamaları için statik dosyalar sunma

Flask web uygulamanız statik ön uç dosyaları içeriyorsa, önce Flask belgelerindeki statik dosyaları yönetme yönergelerini izleyin. Flask uygulamasında statik dosyalar sunma örneği için GitHub'daki örnek Flask uygulamasına bakın.

Statik dosyaları uygulamanızdaki bir yoldan doğrudan sunmak için send_from_directory yöntemini kullanabilirsiniz.

from flask import send_from_directory

@app.route('/reports/<path:path>')
def send_report(path):
    return send_from_directory('reports', path)

Konteyner özellikleri

App Service'e dağıtıldığında, Python uygulamaları App Service Python GitHub deposunda tanımlanan bir Linux Docker kapsayıcısı içinde çalışır. Görüntü yapılandırmalarını sürüme özgü dizinlerin içinde bulabilirsiniz.

Bu kap aşağıdaki özelliklere sahiptir:

  • Uygulamalar, ek bağımsız değişkenler kullanılarak Gunicorn WSGI HTTP Sunucusu kullanılarak çalıştırılır --bind=0.0.0.0 --timeout 600.

    • Başlangıç komutunu özelleştirerek Gunicorn için yapılandırma ayarları sağlayabilirsiniz.

    • Web uygulamanızı yanlışlıkla veya kasıtlı DDOS saldırılarına karşı korumak için Gunicorn, Gunicorn Dağıtma bölümünde açıklandığı gibi bir Nginx ters ara sunucusunun arkasında çalıştırılır.

  • Varsayılan olarak, temel konteyner imajı yalnızca Flask web çatısını içerir, ancak konteyner, WSGI uyumlu ve Python 3.6+ ile uyumlu olan diğer çatıları, örneğin Django, destekler.

  • Django gibi diğer paketleri yüklemek için projenizin kökünde doğrudan bağımlılıklarınızı belirten bir requirements.txt dosyası oluşturun. Projenizi dağıttığınızda, App Service bu bağımlılıkları otomatik olarak yükler.

    Bağımlılıkların yüklenmesi içinrequirements.txtdosyasının proje kökünde olması gerekir. Aksi takdirde, derleme işlemi şu hatayı raporlar: "setup.py veya requirements.txt bulunamadı; pip install çalıştırılmıyor." Bu hatayı alırsanız, gereksinim dosyanızın konumunu kontrol edin.

  • App Service, WEBSITE_HOSTNAME adlı bir ortam değişkenini otomatik olarak tanımlar ve bu değişkenin değeri, msdocs-hello-world.azurewebsites.net gibi web uygulamasının URL'sidir. Uygulamanızın adıyla, örneğin WEBSITE_SITE_NAME, msdocs-hello-world öğesini de tanımlar.

  • npm ve Node.js, yarn gibi Node.js tabanlı derleme araçlarını çalıştırabilmeniz için kapsayıcıya yüklenmiştir.

Konteyner başlatma süreci

Başlangıç sırasında, Linux konteynerindeki Uygulama Hizmeti şu adımları gerçekleştirir:

  1. Özel bir başlangıç komutu (varsa) kullanın.
  2. Bir Django uygulamasının var olup olmadığını denetleyin ve algılanırsa Gunicorn'ı başlatın.
  3. Bir Flask uygulamasının var olup olmadığını denetleyin ve algılanırsa Gunicorn'ı başlatın.
  4. Başka bir uygulama bulunamazsa, konteynerin içine yerleştirilmiş bir varsayılan uygulamayı başlatın.

Aşağıdaki bölümler, her seçenek için ek detaylar sağlar.

Django uygulaması

Django uygulamaları için, App Service, uygulama kodunuz içerisinde adında wsgi.py olan bir dosya arar ve ardından aşağıdaki komutu kullanarak Gunicorn'u çalıştırır.

# <module> is the name of the folder that contains wsgi.py
gunicorn --bind=0.0.0.0 --timeout 600 <module>.wsgi

Başlangıç komutu üzerinde daha belirli bir denetim istiyorsanız, özel bir başlangıç komutu kullanın, <module> öğesini wsgi.py içeren klasörün adıyla değiştirin ve modül proje kök dizininde değilse bir --chdir bağımsız değişken ekleyin. Örneğin, wsgi.py proje kökünden knboard/backend/config altında bulunuyorsa, bağımsız değişkenlerini --chdir knboard/backend config.wsgikullanın.

Üretim günlüğünü etkinleştirmek için, --access-logfile ve --error-logfile parametrelerini özel başlangıç komutlarının örneklerinde gösterildiği gibi ekleyin.

Flask uygulaması

Flask için App Service , application.py veya app.py adlı bir dosya arar ve Gunicorn'ı şu şekilde başlatır:

# If application.py
gunicorn --bind=0.0.0.0 --timeout 600 application:app

# If app.py
gunicorn --bind=0.0.0.0 --timeout 600 app:app

Ana uygulama modülünüz farklı bir dosyada bulunuyorsa, uygulama nesnesi için farklı bir ad kullanın. Gunicorn'a başka bağımsız değişkenler sağlamak istiyorsanız , özel bir başlangıç komutu kullanın.

Varsayılan davranış

App Service özel bir komut, Django uygulaması veya Flask uygulaması bulamazsa, opt/defaultsite klasöründe bulunan ve aşağıdaki görüntüde gösterilen varsayılan salt okunur bir uygulama çalıştırır.

Kod dağıttıysanız ve yine de varsayılan uygulamayı görüyorsanız bkz . Sorun giderme - Uygulama görünmüyor.

Linux'ta varsayılan App Service web sayfasının ekran görüntüsü.

Başlangıç komutunu özelleştir

Konteynerin başlatma davranışını, özel bir başlatma komutu veya başlatma komut dosyasında birden fazla komut sağlayarak kontrol edebilirsiniz. Başlangıç komut dosyası startup.sh, startup.cmd, startup.txt gibi seçtiğiniz adı kullanabilir.

Tüm komutlar proje kök klasörüne göre göreli yollar kullanmalıdır.

Bir başlangıç komutu veya komut dosyası belirtmek için:

  • Azure portalı: Uygulamanın Yapılandırma sayfasını ve ardından Genel ayarlar'ı seçin. Başlangıç Komutu alanına başlangıç komutunuzun tam metnini veya başlangıç komut dosyanızın adını yerleştirin. Ardından değişiklikleri uygulamak için Kaydet'i seçin. Bkz. Linux kapsayıcıları için genel ayarları yapılandırma .

  • Azure CLI: başlangıç komutunu veya dosyasını ayarlamak için az webapp config set komutunu parametresiyle --startup-file birlikte kullanın:

    az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<custom-command>"

    <custom-command> öğesini, başlangıç komutunuzun tam metniyle veya başlangıç komutunuz dosyanızın adıyla değiştirin.

App Service, özel bir başlangıç komutunu veya dosyasını işlerken oluşan hataları görmezden gelir ve sonra, Django ve Flask uygulamalarını arayarak başlangıç sürecine devam eder. Beklediğiniz davranışı görmüyorsanız başlangıç komutunuzun veya dosyanızın hatasız olup olmadığını ve uygulama kodunuzla birlikte App Service'e bir başlangıç komut dosyasının dağıtılıp dağıtılmadığını denetleyin. Daha fazla bilgi için tanılama günlüklerini de kontrol edebilirsiniz. Ayrıca Azure portalında uygulamanın Sorunları tanılama ve çözme sayfasını da gözden geçirin.

Örnek başlatma komutları

  • Gunicorn bağımsız değişkenleri eklendi: Aşağıdaki örnek, Django uygulamasını başlatmak için --workers=4 bağımsız değişkenini Gunicorn komut satırına ekler:

    # <module-path> is the relative path to the folder that contains the module
# that contains wsgi.py; <module> is the name of the folder containing wsgi.py.
gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi

    Daha fazla bilgi için bkz Gunicorn Çalıştırma. Web uygulamanızın ölçeğini otomatik ölçekleme kuralları kullanarak büyütüp küçültüyorsanız, başlatma komutunuzda NUM_CORES ortam değişkenini kullanarak Gunicorn işçi sayısını da dinamik olarak ayarlamalısınız, örneğin: --workers $((($NUM_CORES*2)+1)). Önerilen Gunicorn çalışan sayısını ayarlama hakkında daha fazla bilgi için bkz. Gunicorn SSS.

  • Django için üretim günlüğünü etkinleştirme: komut satırına --access-logfile '-' ve --error-logfile '-' bağımsız değişkenlerini ekleyin:

    # '-' for the log files means stdout for --access-logfile and stderr for --error-logfile.
gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi --access-logfile '-' --error-logfile '-'

    Bu günlükler App Service günlük akışında görünür.

    Daha fazla bilgi için Gunicorn günlüğü kısmına bakın.

  • Özel Flask ana modülü: App Service varsayılan olarak flask uygulamasının ana modülünün application.py veya app.py olduğunu varsayar. Ana modülünüz farklı bir ad kullanıyorsa, başlangıç komutunu özelleştirmeniz gerekir. Örneğin, ana modülü hello.py olan bir Flask uygulamanız varsa ve bu dosyadaki Flask uygulama nesnesi olarak adlandırılıyorsa myapp, komut aşağıdaki gibidir:

    gunicorn --bind=0.0.0.0 --timeout 600 hello:myapp

    Ana modülünüz website gibi bir alt klasördeyse, --chdir argümanıyla o klasörü belirtin.

    gunicorn --bind=0.0.0.0 --timeout 600 --chdir website hello:myapp

  • Gunicorn olmayan bir sunucu kullanın: Aiohttp gibi farklı bir web sunucusu kullanmak için başlangıç komutu olarak veya başlangıç komut dosyasında uygun komutu kullanın:

    python3.7 -m aiohttp.web -H localhost -P 8080 package.module:init_func

Uygulama ayarlarına çevresel değişkenler olarak erişin.

Uygulama ayarları, Uygulama ayarlarını yapılandırma bölümünde açıklandığı gibi, özellikle uygulamanız için bulutta depolanan değerlerdir. Bu ayarlar uygulama kodunuz için ortam değişkenleri olarak kullanılabilir ve standart os.environ deseni kullanılarak erişilir.

** Örneğin, DATABASE_SERVER adında bir uygulama ayarı oluşturduysanız, aşağıdaki kod o ayarın değerini alır:

db_server = os.environ['DATABASE_SERVER']

HTTPS oturumunu algıla

App Service'te TLS/SSL sonlandırma ağ yük dengeleyicilerinde gerçekleşir, bu nedenle tüm HTTPS istekleri şifrelenmemiş HTTP istekleri olarak uygulamanıza ulaşır. Uygulama mantığınız, kullanıcı isteklerinin şifreli olup olmadığını kontrol etmesi gerekiyorsa, X-Forwarded-Proto başlığını inceleyin.

if 'X-Forwarded-Proto' in request.headers and request.headers['X-Forwarded-Proto'] == 'https':
# Do something when HTTPS is used

Popüler web çerçeveleri, standart uygulama modelinizde X-Forwarded-* bilgilerine erişmenizi sağlıyor. Örneğin, Django'da SECURE_PROXY_SSL_HEADER kullanarak Django'ya X-Forwarded-Proto üst bilgisini kullanması gerektiğini söyleyebilirsiniz.

Tanı günlüklerine erişim

Kabın içinden üretilen konsol günlüklerine erişebilirsiniz.

Kapsayıcı kaydını açmak için aşağıdaki komutu çalıştırın:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

<app-name> ve <resource-group-name> öğelerini web uygulamanız için uygun adlarla değiştirin.

Container günlüğünü açtıktan sonra günlük akışını görüntülemek için aşağıdaki komutu çalıştırın:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Konsol günlükleri hemen görünmüyorsa 30 saniye içinde yeniden denetleyin.

Günlük akışını istediğiniz zaman durdurmak için Ctrl+C tuşlarına basın.

Azure portalı üzerinden günlüklere erişmek için, uygulamanızın sol tarafındaki menüdeİzleme Günlüğü akışı'nı>.

Dağıtım günlüklerine erişim

Kodunuzu dağıttığınızda App Service, derleme otomasyonunu özelleştirme bölümünde daha önce açıklanan derleme işlemini gerçekleştirir. Yapı kendi konteynerinde çalıştığı için yapı günlükleri, uygulamanın teşhis günlüklerinden ayrı olarak saklanır.

Dağıtım günlüklerine erişmek için aşağıdaki adımları izleyin:

  1. Web uygulamanızın Azure portalında soldaki menüden Dağıtım>Dağıtım Merkezi'ni seçin.
  2. Günlükler sekmesinde, en son işleme için İşleme Kimliği'ni seçin.
  3. Görüntülenen Günlük ayrıntıları sayfasında, "Oryx derlemesi çalıştırılıyor..." seçeneğinin yanında görünen Günlükleri Göster bağlantısını seçin.

Derleme sorunları, örneğin requirements.txt içindeki yanlış bağımlılıklar ve derleme öncesi veya sonrası betiklerdeki hatalar, bu günlüklerde gösterilir. Gereksinimler dosyanız requirements.txt olarak adlandırılmıyorsa veya projenizin kök klasöründe görünmüyorsa da hatalar görüntülenir.

SSH oturumunu tarayıcıda aç

Kapsayıcınızla doğrudan SSH oturumu açmak için uygulamanızın çalışıyor olması gerekir.

az webapp ssh komutunu kullanın.

Henüz kimlik doğrulaması yapmadıysanız, bağlantı kurmak için Azure aboneliğinizle kimlik doğrulaması yapmanız gerekmektedir. Kimlik doğrulaması yapıldıktan sonra, tarayıcı içi bir kabuk görürsünüz ve burada kabınızın içinde komutlar çalıştırabilirsiniz.

SSH bağlantısı

Uyarı

Dizin dışında /home yaptığınız tüm değişiklikler kapsayıcının kendisinde depolanır ve uygulama yeniden başlatma işleminin ötesinde kalıcı olmaz.

Yerel makinenizden bir uzak SSH oturumu açmak için bkz. Uzak kabuktan SSH oturumu başlatma.

SSH oturumuna başarıyla bağlandığınızda, pencerenin altında "SSH CONNECTION ESTABLISHED" mesajını görmelisiniz. "SSH_CONNECTION_CLOSED" gibi hatalar veya konteynerin yeniden başlatıldığına dair bir mesaj görüyorsanız, uygulama konteynerinin başlamasını engelleyen bir hata olabilir. Olası sorunları araştırma adımları için bkz. Sorun giderme .

URL yeniden yazımları

Python uygulamalarını Azure App Service for Linux üzerinde dağıtırken, uygulamanız içinde URL yeniden yazım işlemlerini yönetmeniz gerekebilir. Bu, özellikle belirli URL desenlerinin, dış web sunucusu yapılandırmalarına güvenmeden doğru uç noktalara yönlendirilmesini sağlamak için kullanışlıdır. Flask uygulamalarında, url işlemcileri ve özel ara yazılım bunu başarmak için kullanılabilir. Django uygulamalarında, sağlam URL dağıtıcısı URL yeniden yazmalarının verimli bir şekilde yönetilmesini sağlar.

Sorun Giderme

Genel olarak, sorun giderme işleminin ilk adımı App Service tanılamasını kullanmaktır.

  1. Web uygulamanızın Azure portalında soldaki menüden Sorunları tanıla ve çöz'e tıklayın.
  2. Kullanılabilirlik ve Performans'ı seçin.
  3. En yaygın sorunların görüntülendiği Uygulama Günlükleri, Kapsayıcı Kilitlenmesi ve Kapsayıcı Sorunları seçeneklerindeki bilgileri inceleyin.

Ardından, tüm hata iletileri için hem dağıtım günlüklerini hem de uygulama günlüklerini inceleyin. Bu kayıtlar genellikle uygulama dağıtımını veya uygulama başlatılmasını engelleyebilecek belirli sorunları tanımlar. Örneğin, requirements.txt dosyanızın dosya adı yanlışsa veya proje kök klasörünüzde yoksa derleme başarısız olabilir.

Aşağıdaki bölümler belirli sorunlar için rehberlik sağlar.

Uygulama görünmüyor

  • Kendi uygulama kodunuzu dağıttıktan sonra varsayılan uygulamayı görürsünüz. Varsayılan uygulamanın görünmesinin nedeni, ya uygulama kodunuzu App Service'e dağıtmamış olmanız, ya da App Service'in uygulama kodunuzu bulamayıp, bunun yerine varsayılan uygulamayı çalıştırmış olmasıdır.

    • Uygulama Hizmetini (App Service) yeniden başlatın, 15-20 saniye bekleyin ve uygulamayı tekrar kontrol edin.

    • Doğrudan App Service kapsayıcısına bağlanmak ve dosyalarınızın site/wwwroot altında mevcut olduğunu doğrulamak için SSH kullanın. Dosyalarınız mevcut değilse, aşağıdaki adımları uygulayın:

      1. SCM_DO_BUILD_DURING_DEPLOYMENT adlı bir uygulama ayarı oluşturun, değeri 1 olarak ayarlayın, kodunuzu yeniden dağıtın, birkaç dakika bekleyin, ardından uygulamaya tekrar erişmeyi deneyin. Uygulama ayarları oluşturma hakkında daha fazla bilgi için bkz. Azure portalında App Service uygulaması yapılandırma.
      2. Dağıtım işleminizi gözden geçirin, dağıtım günlüklerini denetleyin, hataları düzeltin ve uygulamayı yeniden dağıtın.

    • Dosyalarınız varsa App Service belirli bir başlangıç dosyanızı belirleyemedi. Uygulamanızın App Service'in Django veya Flask için beklediği şekilde yapılandırıldığını denetleyin veya özel bir başlangıç komutu kullanın.

  • Tarayıcıda "Hizmet Kullanılamıyor" iletisini görürsünüz. Tarayıcı, App Service'ten yanıt beklerken zaman aşımına uğradı. Bu, App Service'in Gunicorn sunucusunu başlattığını ancak uygulamanın kendisinin başlamadığını gösterir. Bu durum, Gunicorn argümanlarının yanlış olduğunu veya uygulama kodunda bir hata bulunduğunu gösterebilir.

    • Tarayıcıyı yenileyin, özellikle App Service planınızda en düşük fiyat seviyelerini kullanıyorsanız. Uygulama, ücretsiz katmanları kullandığınızda, örneğin, başlamak için daha uzun sürebilir ve tarayıcıyı yeniledikten sonra daha duyarlı hale gelir.

    • Uygulamanızın App Service'in Django veya Flask için beklediği şekilde yapılandırıldığını denetleyin veya özel bir başlangıç komutu kullanın.

    • Hata iletileri için uygulama günlük akışını inceleyin. Uygulama kodundaki hataları günlükler gösterecektir.

setup.py veya requirements.txt bulunamadı

  • Günlük akışı "setup.py veya requirements.txtbulunamadı ; Pip install çalıştırılmıyor.": Oryx derleme işlemi requirements.txt dosyanızı bulamadı.

    • SSH aracılığıyla web uygulamasının kapsayıcısına bağlanın ve requirements.txt doğru adlandırıldığını ve doğrudan site/wwwroot altında mevcut olduğunu doğrulayın. Dosya mevcut değilse, deponuzda bulunduğundan ve dağıtımınıza dahil edildiğinden emin olun. Eğer ayrı bir klasörde bulunuyorsa, onu kök dizine taşıyın.

ModuleNotFoundError uygulama başlatıldığında

Uygulama başlatıldığında ModuleNotFoundError: No module named 'example' gibi bir hata görürseniz, Python modüllerinizden bir veya birden fazlasını bulamamış demektir. Bu hata genellikle sanal ortamınızı kodunuzla birlikte dağıttığınızda meydana gelir. Sanal ortamlar taşınabilir değildir, bu yüzden sanal bir ortam uygulama kodunuzla birlikte dağıtılmamalıdır. Bunun yerine, Oryx'in sanal bir ortam oluşturmasına ve bir uygulama ayarı, SCM_DO_BUILD_DURING_DEPLOYMENT, oluşturarak ve bunu 1 olarak ayarlayarak paketlerinizi web uygulamasına yüklemesine izin verin. Bu ayar, App Service'e her dağıtım yaptığınızda Oryx'in paketlerinizi yüklemesini zorlayacaktır. Daha fazla bilgi için sanal ortam taşınabilirliği hakkındaki bu makaleye bakın.

Veritabanı kilitli

Veritabanı geçişlerini bir Django uygulamasıyla çalıştırmaya çalışırken "sqlite3" ifadesini görebilirsiniz. OperationalError: veritabanı kilitli. Bu hata, uygulamanızın, varsayılan olarak Django için yapılandırılan bir SQLite veritabanı kullandığını, Azure Database for PostgreSQL gibi bir bulut veritabanı kullanmadığını gösterir.

Uygulamanızın DATABASES SQLite yerine bulut veritabanı kullandığından emin olmak için uygulamanın settings.py dosyasındaki değişkeni denetleyin.

Öğretici: PostgreSQL ile Django web uygulaması dağıtma'daki örnekte bu hatayla karşılaşıyorsanız Bağlantı ayarlarını doğrulama bölümünde yer alan adımları tamamladığınızdan emin olun.

Diğer konular

  • Parolalar yazıldığında SSH oturumunda görünmez: Güvenlik nedenleriyle, yazdığınız sırada SSH oturumu parolanızı gizli tutar. Ancak karakterler kaydediliyor, bu nedenle parolanızı her zamanki gibi yazın ve bitirdiğinizde Enter tuşuna basın.

  • SSH oturumunda komutlar kesilmiş gibi görünüyor: Düzenleyici metin kaydırmayı yapmıyor olabilir, ancak komutlar yine de doğru şekilde çalıştırılmalıdır.

  • Statik varlıklar Django uygulamasında görünmez: WhiteNoise modülünü etkinleştirdiğinizden emin olun.

  • "Önemli SSL Bağlantısı Gerekli" iletisini görürsünüz: Uygulamanın içinden kaynaklara (veritabanları gibi) erişmek için kullanılan tüm kullanıcı adlarını ve parolaları denetleyin.

İlgili içerik