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ı bir sanal ortamı otomatik olarak etkinleştirir ve requirements.txt dağıttığınızda veya pyproject.toml bir setup.py dağıttığınızda , veya dosyasından bağımlılıkları yükler.

Bu makalede, App Service'te yerleşik linux kapsayıcısı kullanan Python geliştiricileri için temel kavramlar ve yönergeler sağlanır. App Service'i hiç kullanmadıysanız önce Python hızlı başlangıcını ve PostgreSQL ile Flask, Django veya FastAPI öğreticisini tamamlayın.

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

  • Azure portalı. Uygulamanın sol bölmesinde, Azure portalında App Service uygulamasını yapılandırma bölümünde açıklandığı gibi >Ortam değişkenleri'ni veya >Yapılandırması'nı seçin.

  • 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ükleyip az login kullanarak Azure'da oturum açarak komutları yerel olarak çalıştırı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. Ancak, kendi özel Windows kapsayıcı görüntünüzü derleyebilir ve App Service'te bu görüntüyü çalıştırabilirsiniz. Daha fazla bilgi için bkz. Özel Docker görüntüsü kullanma.

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

  • 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 komutunu kullanarak geçerli Python sürümünü gösterin:

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

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

    • az webapp config set komutunu kullanarak Python sürümünü ayarlayın:

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

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

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

Kendi kapsayıcı görüntünüzü oluşturarak desteklenmeyen bir Python sürümünü çalıştırabilirsiniz. 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ım dışı bırakılır veya önemli güvenlik açıklarına sahiptir. 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' yı, ARM şablonunu veya Bicep'i kullanın. Bu dağıtım alternatifleri, portaldan kaldırılan 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ı derleme otomasyonu ile dağıtıldığında, içerik altında /tmp/<uid>değil, uygulamasına dağıtılır ve uygulamasından /home/site/wwwrootsunulur. Ortam değişkenini kullanarak bu içerik dizinine APP_PATH erişebilirsiniz. Çalışma zamanında oluşturulan ek dosyaları kalıcılık için /home altında veya kullanarak bir konuma yazmanız gerekir. Bu davranış hakkında daha fazla bilgi için bkz. Python Derleme Değişiklikleri.

Uygulama ayarı SCM_DO_BUILD_DURING_DEPLOYMENT olarak ayarlandıysa 1, Uygulamanızı dağıtırken Oryx adlı App Service derleme sistemi 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 Düğüm tabanlı araçları (örneğin yarn install ve yarn build)) çalıştırabilir.

  2. Bağımlılıkları yükleyin. Derleme sistemi, proje kökünde aşağıdaki dosyaları denetler:

    • requirements.txt: çalıştırır pip install -r requirements.txt.
    • pyproject.toml ile uv.lock: uv kullanır.
    • pyproject.toml ile poetry.lock: Kullanırpoetry.
    • pyproject.toml: kullanır poetry.
    • setup.py: çalıştırır pip install ..

    Uyarı

    Pyproject.toml mevcutsa ancak uv.lock eksikse, Şiir.lock da eksik olsa bile App Service varsayılan olarak Şiir'i kullanır. uv kullanmak için, dağıtımınıza uv.lock eklemeniz gerekir.

    Bu dosyalardan hiçbiri bulunmazsa, derleme işlemi şu hatayı rapor eder: "setup.py veya requirements.txt bulunamadı; pip install çalıştırılamıyor."

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

  4. Ayarda POST_BUILD_COMMAND bu adım belirtilirse, derleme sonrası özel bir betik çalıştırın. (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ştururken çalıştırmayı collectstaticDISABLE_COLLECTSTATIC devre dışı bırakmak için ayarını olarak trueayarlayın.

  • Ö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ünün göreli yollarını 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 yolları kullanmalıdır.

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

Derleme ve dağıtım günlüklerine erişme hakkında bilgi 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ı

Oryx'in çalıştığı derleme kapsayıcısı, uygulamanın çalıştırıldığı çalışma zamanı kapsayıcısından farklı olduğundan, tüm derleme öncesi ve derleme sonrası betiklerde her zaman göreli yolları kullanın. 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.

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

Mevcut web uygulamalarını aşağıdaki gibi Azure'a yeniden dağıtabilirsiniz:

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

    • App Service'in gerekli paketleri otomatik olarak yüklemesini istiyorsanız bağımlılık dosyanız (requirements.txt, pyproject.toml veya setup.py gibi) deponuzun kökünde olmalıdır.

  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. Azure CLI komutunu az webapp upçalıştırarak bu kaynakları kolayca oluşturabilirsiniz. Alternatif olarak, PostgreSQL ile Flask, Django veya FastAPI öğreticisinde gösterildiği gibi kaynakları oluşturabilir ve dağıtabilirsiniz. Kaynak grubunun, App Service planının ve web uygulamasının adlarını uygulamanız için uygun adlarla 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ığı hakkında bilgi 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. Gunicorn'un uygulama nesnenizi veya wsgi.py klasörünüzü bulabilmesi gerekir. 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. Veya Azure App Service'e yerel Git dağıtımı makalesinde açıklandığı gibi yerel Git'ten sürekli dağıtım ayarlayın.

  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 kullanarak 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.

    • Sürekli dağıtım kullanırken, derleme otomasyonunu özelleştirme bölümünde daha önce açıklandığı gibi derleme sonrası komutlarını 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ı

App Service gibi bir üretim ortamı için Django uygulamaları Django'nun Dağıtım denetim listesindeki yönergeleri 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 Access uygulama ayarlarında ortam değişkenleri olarak açıklandığı gibi değeri bir App Service ayarında depolayın. Değerinizi alternatif olarak Azure Anahtar Kasası'nda bir sır olarak saklayabilirsiniz.
DEBUG App Service'te ()DEBUG değeriyle 0 bir false ayar oluşturun ve ardından değeri ortam değişkeni olarak yükleyin. Geliştirme ortamınızda(DEBUG değeriyle 1 bir true ortam değişkeni oluşturun.
ALLOWED_HOSTS Üretimde Django, uygulamanın URL'sini ALLOWED_HOSTS dizisine eklemenizi gerektirir. Bu URL'yi çalışma zamanında kodunu os.environ['WEBSITE_HOSTNAME']kullanarak 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) 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 değişkenleri dinamik olarak ayarlamak için ortam değişkenlerini (yerel geliştirme için) ve STATIC_ROOT uygulama ayarlarını (buluta dağıtırken) kullanmayı göz önünde bulundurun. Ö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 için derleme işlemi bunları adlı django-staticbir klasöre yerleştirirse, varsayılanı kullanmaktan kaçınmak için olarak ayarlayabilirsiniz DJANGO_STATIC_URL/django-static/ .

  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, ön uç klasörünüzde çalıştırırsanız yarn build ve Yarn statik dosyalar içeren bir build/static klasör oluşturursa, burada gösterildiği gibi bu klasörü ekleyin:

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

    Bu kodda, FRONTEND_DIR Yarn gibi bir derleme aracının çalıştırıldığı bir yol oluşturmak için kullanılır. İsterseniz bir ortam değişkeni ve uygulama ayarını yeniden 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 dosyaları sağlar.

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

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. MIDDLEWARE ve INSTALLED_APPS listelerini WhiteNoise 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ü dizinlerde bulabilirsiniz.

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

  • Uygulamalar Gunicorn WSGI HTTP Sunucusu tarafından ek bağımsız değişkenlerle ç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 dağıtımı bölümünde açıklandığı gibi, Gunicorn bir Nginx ters ara sunucusunun arkasında çalıştırılır.

  • Varsayılan olarak, temel kapsayıcı görüntüsü yalnızca Flask web çerçevesini içerir, ancak kapsayıcı WSGI uyumlu ve Python 3.6 ve üzeri ile uyumlu olan Django gibi diğer çerçeveleri 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, pyproject.toml veya setup.py dosyası oluşturun. Projenizi dağıttığınızda, App Service bu bağımlılıkları otomatik olarak yükler.

    Bağımlılık dosyasının proje kökünde olması gerekir, aksi durumda bağımlılıklar yüklenmez. Bu dosya kökte değilse, derleme işlemi "setup.py veya requirements.txtbulunamadı ; Pip yüklemesi çalıştırılmıyor." Bu hatayla karşılaşırsanız gereksinimler dosyanızın konumunu denetleyin.

  • App Service, web uygulamasının URL'sini içeren adlı WEBSITE_HOSTNAME ortam değişkenini (gibi) otomatik olarak msdocs-hello-world.azurewebsites.nettanımlar. Ayrıca uygulamanızın adını (gibiWEBSITE_SITE_NAME) içeren öğesini de tanımlarmsdocs-hello-world.

  • npm ve Node.js, Yarn gibi Düğüm tabanlı derleme araçlarını çalıştırabilmeniz için kapsayıcıya yüklenir.

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 Bunun için Gunicorn'ı başlatın.
  3. Bir Flask uygulamasının var olup olmadığını denetleyin ve algılanırsa Bunun için 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ı

App Service, Django uygulamaları için uygulama kodunuzda wsgi.py adlı bir dosya arar ve aşağıdaki komutu kullanarak Gunicorn'ı ç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 örneklerinde gösterildiği gibi ve --error-logfile parametrelerini 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 veya startup.txt gibi seçtiğiniz adı kullanabilir.

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

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

  • Azure portalı. Uygulama sayfasının sol bölmesindeki Ayarlar'ın altında Yapılandırma'yı ve ardından Genel ayarlar'ı seçin. Başlangıç Komutu kutusuna başlangıç komutunuzun tam metnini veya başlangıç komut dosyanızın adını girin. 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ıç komutu veya dosyası işlenirken oluşan hataları yoksayar ve ardından Django ve Flask uygulamalarını arayarak başlatma işlemine devam eder. Beklediğiniz davranışı görmüyorsanız başlangıç komutunuzun veya dosyanızın hatasız olduğunu ve uygulama kodunuzla birlikte App Service'e bir başlangıç komut dosyasının dağıtıldığını doğrulayın. 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 kontrol edebilirsiniz.

Ö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 that contains 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 büyütmek ve küçültmek için otomatik ölçeklendirme kuralları kullanıyorsanız, başlangıç komutunuzda ortam değişkenini NUM_CORES kullanarak Gunicorn çalışanlarının sayısını da dinamik olarak ayarlamanız gerekir. Ö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 myapp olarak adlandırılıyorsa, komut şu şekildedir:

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

    Ana modülünüz web sitesi gibi bir alt klasördeyse şu klasörü bağımsız değişkeniyle --chdir 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ını yapılandırma bölümünde açıklandığı gibi uygulama ayarları, ö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 aracılığıyla erişilir.

Örneğin, adlı DATABASE_SERVERbir uygulama ayarı oluşturursanız, aşağıdaki kod bu 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ın kullanıcı isteklerinin şifrelenip şifrelenmediğini denetlemesi gerekiyorsa üst bilgiyi inceleyin X-Forwarded-Proto :

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 düzeninizdeki bilgilere erişmenizi X-Forwarded-* sağlar. Örneğin, Django'da SECURE_PROXY_SSL_HEADER kullanarak Django'yu üst bilgiyi kullanacak X-Forwarded-Proto şekilde yapılandırabilirsiniz.

Tanı günlüklerine erişim

Kapsayıcının içinden oluşturulan 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> değerlerini 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 klavye kısayolu Ctrl+C'yi kullanın.

Azure portalındaki günlüklere erişmek için, uygulamanızın sol bölmesinde İzlemeGü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ı sayfasında, sol bölmede 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, Çalışıyor oryx derlemesi'nin yanında görünen Günlükleri Göster bağlantısını seçin.

Bağımlılık dosyanızdaki yanlış bağımlılıklar ve derleme öncesi veya derleme sonrası betiklerdeki hatalar gibi derleme sorunları bu günlüklerde görünür. Bağımlılık dosyanız projenizin kök klasöründe bulunmazsa da hatalar görüntülenir.

Tarayıcıda SSH oturumu açma

Kapsayıcınızla doğrudan SSH oturumu açmak istiyorsanız uygulamanız çalışıyor olmalıdır.

az webapp ssh komutunu kullanın.

Kimliğiniz doğrulanmamışsa bağlanmak için Azure aboneliğinizle kimlik doğrulaması yapmanız gerekir. Kimliğiniz doğrulandığında, kapsayıcınızın içinde komutları çalıştırabileceğiniz bir tarayıcı içi kabuk görürsünüz.

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 kapsayıcının yeniden başlatıldığını belirten bir ileti görürseniz, uygulama kapsayıcısının başlatılmasını engelleyen bir hata olabilir. Olası sorunları araştırma hakkında bilgi için bkz. Sorun giderme .

URL yeniden yazımları

Linux için App Service'te Python uygulamaları dağıtırken, uygulamanızda URL yeniden yazma işlemlerini işlemeniz gerekebilir. Bu yöntem özellikle dış web sunucusu yapılandırmalarına bağlı kalmadan belirli URL desenlerinin doğru uç noktalara yönlendirildiğinden emin olmak için kullanışlıdır. Flask uygulamalarında bunu başarmak için URL işlemcilerini ve özel ara yazılımları kullanabilirsiniz. Django uygulamalarında , 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ı sayfasında, sol bölmede Sorunları tanılama ve çözme'yi seçin.
  2. Kullanılabilirlik ve Performans'ı seçin.
  3. En yaygın sorunların göründüğü Uygulama Günlükleri, Kapsayıcı Kilitlenmesi ve Kapsayıcı Sorunları'ndaki 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, bağımlılık dosyanız 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 uygulama, uygulama kodunuzu App Service'e dağıtmadığınız veya App Service'in uygulama kodunuzu bulamadığından ve bunun yerine varsayılan uygulamayı çalıştırdığından görünür.

    • Uygulamayı yeniden başlatın, 20 saniye bekleyin ve uygulamayı yeniden denetleyin.

    • 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 yoksa aşağıdaki adımları uygulayın:

      1. değerine SCM_DO_BUILD_DURING_DEPLOYMENTsahip adlı 1 bir uygulama ayarı oluşturun, kodunuzu yeniden dağıtın, birkaç dakika bekleyin ve uygulamaya yeniden 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 başlangıç dosyanızı belirleyemedi. Uygulamanızın App Service'in Django veya Flask için beklediği şekilde yapılandırdığından emin olun 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şlatılmadığını gösterir. Bu koşul, Gunicorn bağımsız değişkenlerinin yanlış olduğunu veya uygulama kodunda bir hata olduğunu gösterebilir.

    • Tarayıcıyı yenileyin, özellikle App Service planınızda en düşük fiyat seviyelerini kullanıyorsanız. Örneğin ücretsiz katmanları kullandığınızda uygulamanın başlatılması daha uzun sürebilir ve tarayıcıyı yeniledikten sonra yanıt vermeye başlayabilir.

    • Uygulamanızın App Service'in Django veya Flask için beklediği şekilde yapılandırıldığını doğrulayın 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 yüklemesi çalıştırılmıyor." Oryx derleme işlemi requirements.txt, pyproject.toml veya setup.py dosyanızı bulamadı.

    • SSH aracılığıyla web uygulamasının kapsayıcısına bağlanın ve bağımlılık dosyanızın doğru şekilde 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

gibi ModuleNotFoundError: No module named 'example'bir hata görürseniz Uygulama başlatıldığında Python bir veya daha fazla modülünüzü bulamadı. 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ğıttığınızda Oryx'i paketlerinizi yüklemeye zorlar. 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ı kilitlendi." Hata, uygulamanızın PostgreSQL için Azure Veritabanı gibi bir bulut veritabanı kullanmak yerine varsayılan olarak Django'nun yapılandırıldığı bir SQLite veritabanı kullandığı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 işiniz bittiğinde 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

  • Last updated on