Aracılığıyla paylaş

Azure Uygulaması Hizmeti için Linux Python uygulaması yapılandırma

  • Makale

Bu makalede, Azure Uygulaması Hizmeti'nin 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 git deposu dağıttığınızda veya derleme otomasyonu etkin bir zip paketi dağıttığınızda sizin için çalışırpip install -r requirements.txt.

Bu kılavuz, App Service'te yerleşik bir Linux kapsayıcısı kullanan Python geliştiricileri için temel kavramlar ve yönergeler sağlar. Azure Uygulaması Hizmeti'ni hiç kullanmadıysanız önce Python hızlı başlangıcını ve PostgreSQL ile Python öğ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 Ayarlar>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.

Not

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 ile geçerli Python sürümünü göster:

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

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

    • 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 Uygulaması Service'te desteklenen tüm Python sürümlerini göster:

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

Bunun yerine 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.

Derleme otomasyonunu özelleştirme

Uygulama ayarı SCM_DO_BUILD_DURING_DEPLOYMENT olarak ayarlandıysa 1, Uygulamanızı dağıtırken App Service'in Oryx adlı derleme sistemi aşağıdaki adımları gerçekleştirir:

  1. Ayar tarafından PRE_BUILD_COMMAND bu adım belirtilirse, özel bir derleme öncesi 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ı (örneğin, yarn install ve yarn build)) çalıştırabilir.

  2. pip install -r requirements.txt'i çalıştırın. requirements.txt dosyası projenin kök klasöründe bulunmalıdır. Aksi takdirde, derleme işlemi şu hatayı bildirir: "setup.py veya requirements.txt bulunamadı; Pip yüklemesi ç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, ayar ise DISABLE_COLLECTSTATIC truebu adım atlanır.

  4. Bu adım ayar tarafından POST_BUILD_COMMAND belirtilirse özel derleme sonrası betiği çalıştırın. (Betik yine diğer Python ve Node.js betiklerini, pip ve npm komutlarını ve Düğüm tabanlı araçları çalıştırabilir.)

Varsayılan olarak , PRE_BUILD_COMMANDPOST_BUILD_COMMANDve DISABLE_COLLECTSTATIC ayarları boş olur.

  • Django uygulamaları oluştururken collectstatic çalıştırmayı DISABLE_COLLECTSTATIC devre dışı bırakmak için ayarını olarak trueayarlayın.

  • Derleme öncesi komutları çalıştırmak için, ayarı gibi proje köküne göre bir komut echo Pre-build commandveya bir betik dosyasının yolunu içerecek şekilde scripts/prebuild.shayarlayınPRE_BUILD_COMMAND. 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, ayarı proje kökünüze göre , gibi echo Post-build commandbir komut veya bir betik dosyasının yolunu içerecek şekilde scripts/postbuild.shayarlayınPOST_BUILD_COMMAND. Tüm komutlar proje kök klasörünün göreli yollarını 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.

Not

PRE_BUILD_SCRIPT_PATH ve POST_BUILD_SCRIPT_PATH ayarları ile aynıdır PRE_BUILD_COMMAND POST_BUILD_COMMAND ve eski amaçlarla desteklenir.

veya 1içeriyorsa true adlı SCM_DO_BUILD_DURING_DEPLOYMENTbir ayar, dağıtım sırasında gerçekleşen bir Oryx derlemesini tetikler. Bu ayar Git true , Azure CLI komutu az webapp upve Visual Studio Code kullanarak dağıtım yaptığınızda kullanılır.

Not

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

Mevcut web uygulamaları Azure'a aşağıdaki gibi 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. Azure CLI komutunu az webapp upçalıştırarak bunu kolayca yapabilirsiniz. Alternatif olarak, Öğretici: PostgreSQL ile Python (Django veya Flask) web uygulaması dağıtma bölümünde gösterildiği gibi kaynakları oluşturabilir ve dağıtabilirsiniz. Uygulamanıza daha uygun olması için 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.

    • Örneğin veritabanı bağlantıları genellikle Öğretici: PostgreSQL ile Django web uygulaması dağıtma - bağlantı ayarlarını doğrulama bölümünde gösterildiği gibi bu ayarlar aracılığıyla yönetilir.
    • Tipik Django uygulamaları için belirli ayarlar için bkz . Django uygulamaları için üretim ayarları.

  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 uygulama nesnenizi veya wsgi.py klasörünüzü bulabilmesi gereken Gunicorn web sunucusunu kullanır. Gerekirse başlangıç komutunu özelleştirebilirsiniz.

  6. Sürekli dağıtım: GitHub Actions, Bitbucket veya Azure Repos'tan sürekli dağıtımı, Azure Uygulaması Hizmetine sürekli dağıtım makalesinde açıklandığı gibi ayarlayın. Veya Yerel Git'ten Azure Uygulaması Hizmetine Yerel Git dağıtımı makalesinde açıklandığı gibi 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 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 tamamlandıktan sonra, değişiklikleri kaynak deponuza işleyebilmeniz ve bu güncelleştirmelerin App Service'e otomatik olarak dağıtılabilmesi gerekir.

Django uygulamaları için üretim ayarları

Azure Uygulaması Hizmeti 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 yönergeleri
SECRET_KEY Değeri, Access uygulama ayarlarında ortam değişkenleri olarak açıklandığı gibi bir App Service ayarında depolayın. Alternatif olarak değeri Azure Key Vault'ta gizli dizi olarak depolayabilirsiniz.
DEBUG App Service'te 0 (false) değeriyle bir DEBUG ayar oluşturun, ardından değeri ortam değişkeni olarak yükleyin. Geliştirme ortamınızda 1 (true) değeriyle bir DEBUG ortam değişkeni oluşturun.
ALLOWED_HOSTS Üretimde Django, uygulamanın URL'sini ALLOWED_HOSTS settings.py dizisine eklemenizi gerektirir. Bu URL'yi çalışma zamanında koduyla os.environ['WEBSITE_HOSTNAME']alabilirsiniz. App Service ortam değişkenini WEBSITE_HOSTNAME otomatik olarak uygulamanın URL'sine ayarlar.
DATABASES Veritabanı bağlantısı için App Service'te ayarları tanımlayın ve sözlüğü doldurmak DATABASES için ortam 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 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 şekilde 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 /django-static/ olarak ayarlayabilirsinizDJANGO_STATIC_URL.

  2. Farklı bir klasörde statik dosyalar oluşturan bir derleme öncesi betiğiniz varsa, Django'nun collectstatic işleminin bunları bulması için bu klasörü Django STATICFILES_DIRS 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, bu klasörü aşağıdaki gibi 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ığı bir yol oluşturmak için kullanılır. İstediğiniz gibi bir ortam değişkeni ve Uygulama Ayarı kullanabilirsiniz.

  3. requirements.txt dosyanıza ekleyinwhitenoise. 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 ve INSTALLED_APPS listelerini MIDDLEWARE 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ı doğrudan uygulamanızdaki bir yoldan sunmak için yöntemini send_from_directory kullanabilirsiniz:

from flask import send_from_directory

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

Kapsayıcı ö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 kapsayıcı 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 kapsayıcı görüntüsü yalnızca Flask web çerçevesini içerir, ancak kapsayıcı WSGI uyumlu ve Django gibi Python 3.6+ ile uyumlu 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 dosyası oluşturun. Ardından projenizi dağıttığınızda App Service bu bağımlılıkları otomatik olarak yükler.

    bağımlılıkların yüklenmesi için requirements.txt dosyasının proje kökünde olması gerekir . Aksi takdirde, derleme işlemi şu hatayı bildirir: "setup.py veya requirements.txt bulunamadı; 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'si ile adlı WEBSITE_HOSTNAME bir ortam değişkenini (gibi) otomatik olarak msdocs-hello-world.azurewebsites.nettanımlar. Ayrıca uygulamanızın adıyla (gibimsdocs-hello-world) tanımlarWEBSITE_SITE_NAME.

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

Kapsayıcı başlatma işlemi

Başlatma sırasında Linux'ta App Service kapsayıcısı şu adımları çalıştırır:

  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 yoksa kapsayıcıda bulunan varsayılan uygulamayı başlatır.

Aşağıdaki bölümlerde her seçenek için ek ayrıntılar sağlanır.

Django uygulaması

Django uygulamaları için App Service uygulama kodunuzda wsgi.py adlı bir dosya olup olmadığını denetler ve ardından şu 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 belirgin bir denetim istiyorsanız, özel bir başlangıç komutu kullanın, öğesini wsgi.py içeren klasörün adıyla değiştirin <module> ve modül proje kökünde 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 özel başlangıç komutlarının örneklerinde gösterildiği gibi ve --error-logfile parametrelerini ekleyin--access-logfile.

Flask uygulaması

Flask için App Service, application.py veya app.py adlı bir dosyayı 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 yer alırsa, 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.

Varsayılan Linux üzerinde App Service web sayfasının ekran görüntüsü.

Başlatmayı özelleştir komutu

Bir başlangıç komut dosyasında özel başlangıç komutu veya birden çok komut sağlayarak kapsayıcının başlatma davranışını denetleyebilirsiniz. Başlangıç komut dosyası startup.sh, startup.cmd, startup.txt gibi seçtiğiniz adı kullanabilir.

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

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>"

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

App Service, özel bir başlangıç komutu veya dosyası işlenirken oluşan hataları yoksayar, 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 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şlangıç komutları

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

    # <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 büyütmek ve küçültmek için otomatik ölçeklendirme kuralları kullanıyorsanız, başlangıç komutunuzda ortam değişkenini kullanarak NUM_CORES Gunicorn çalışanlarının sayısını dinamik olarak ayarlamanız gerekir. Örneğin: --workers $((($NUM_CORES*2)+1)). Önerilen Gunicorn işçisi 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 bkz . Gunicorn günlüğü.

  • Ö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ünün adı hello.py ve o dosyadaki Flask uygulama nesnesinin adı da myapp olan bir Flask uygulamanız varsa kullanmanız gereken komut şöyle olacaktır:

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

    Ana modülünüz website gibi bir alt klasör ise bu klasörü --chdir bağımsız değişkeniyle 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 ortam değişkenleri olarak erişme

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, adlı DATABASE_SERVERbir uygulama ayarı oluşturduysanız, aşağıdaki kod bu ayarın değerini alır:

db_server = os.environ['DATABASE_SERVER']

HTTPS oturumlarını algılama

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 şifrelenmiş olup olmadığını denetlemesi gerekiyorsa X-Forwarded-Proto üst bilgisini 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 düzeninizdeki bilgilere erişmenizi X-Forwarded-* sağlar. Örneğin, Django'da SECURE_PROXY_SSL_HEADER kullanarak Django'ya üst bilgiyi kullanmasını söyleyebilirsinizX-Forwarded-Proto.

Tanılama günlüklerine erişim

Kapsayıcının içinden oluşturulan konsol günlüklerine erişebilirsiniz.

İlk olarak, aşağıdaki komutu çalıştırarak kapsayıcı günlüğünü açın:

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

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

Kapsayıcı günlüğü açıldıktan sonra günlük akışını görmek 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üklerini hemen görmüyorsanız, 30 saniye içinde yeniden kontrol edin.

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

Günlük dosyalarını tarayıcıdan https://<app-name>.scm.azurewebsites.net/api/logs/dockerda inceleyebilirsiniz.

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

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

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. Derleme kendi kapsayıcısında çalıştığından, derleme günlükleri uygulamanın tanılama günlüklerinden ayrı olarak depolanır.

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

  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.

requirements.txt yanlış bağımlılıklar ve derleme öncesi veya sonrası betiklerdeki hatalar gibi derleme sorunları bu günlüklerde görünür. 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.

Tarayıcıda SSH oturumu açma

Kapsayıcınızda doğrudan SSH oturumu başlatabilmek için uygulamanızın çalışıyor olması gerekir.

Aşağıdaki URL'yi tarayıcınıza yapıştırın ve <app-name> yerine kendi uygulamanızın adını yazın:

https://<app-name>.scm.azurewebsites.net/webssh/host

Kimlik doğrulamasından geçmediyseniz bağlantıyı kurabilmek için Azure aboneliğinizle kimliğinizi doğrulamanız gerekir. Kimliğiniz doğrulandıktan sonra kapsayıcınızda komut çalıştırmak için kullanabileceğiniz tarayıcı içi kabuk ortamını görürsünüz.

SSH bağlantısı

Not

/home dizininin dışında yaptığınız değişiklikler kapsayıcıda depolanır ve uygulama yeniden başlatıldığında kalıcı olmaz.

Yerel makinenizden uzak SSH oturumu açmak için bkz. Uzak kabuktan SSH oturumu açma.

SSH oturumuna başarıyla bağlandığınızda pencerenin alt kısmında "SSH BAĞLANTISI KURULDU" iletisini görmeniz gerekir. "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 adımları için bkz . Sorun giderme .

URL yeniden yazmaları

Linux için Azure Uygulaması Hizmeti'ne Python uygulamaları dağıtırken, uygulamanızda URL yeniden yazma işlemlerini işlemeniz gerekebilir. Bu, ö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, 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 gidermenin 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 günlükler genellikle uygulama dağıtım veya uygulama başlatmayı 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üyorsunuz. Uygulama kodunuzu App Service'e dağıtmadığınızdan veya App Service bunun yerine uygulama kodunuzu bulamadığından ve varsayılan uygulamayı çalıştırdığından varsayılan uygulama görüntülenir.

    • App Service'i yeniden başlatın, 15-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ı kullanın:

      1. 1 değerine sahip adlı SCM_DO_BUILD_DURING_DEPLOYMENT bir uygulama ayarı oluşturun, kodunuzu yeniden dağıtın, birkaç dakika bekleyin ve ardından 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 oradaysa App Service başlangıç dosyanızı tanımlayamamış olabilir. Uygulamanızın App Service'in Django veya Flask için beklediği şekilde yapılandırılmış olduğundan emin olun veya özel 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 koşul, Gunicorn bağımsız değişkenlerinin yanlış olduğunu veya uygulama kodunda bir hata olduğunu gösterebilir.

    • Özellikle App Service planınızdaki en düşük fiyatlandırma katmanlarını kullanıyorsanız tarayıcıyı yenileyin. Ö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ılmış olduğundan emin olun veya özel başlangıç komutu kullanın.

    • Hata iletileri için uygulama günlük akışını inceleyin. Günlüklerde uygulama kodundaki hatalar gösterilir.

setup.py veya requirements.txt bulunamadı

  • Günlük akışı "setup.py veya requirements.txt bulunamadı; 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. Yoksa, dosyanın deponuzda bulunduğundan ve dağıtımınıza dahil olduğundan emin olun. Ayrı bir klasörde varsa köke taşıyın.

Uygulama başlatıldığında ModuleNotFoundError

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 dağıtırsanız oluşur. Sanal ortamlar taşınabilir değildir, bu nedenle bir sanal ortam uygulama kodunuzla dağıtılmamalıdır. Bunun yerine, Oryx'in bir sanal ortam oluşturmasına ve bir uygulama ayarı SCM_DO_BUILD_DURING_DEPLOYMENToluşturup bunu olarak ayarlayarak paketlerinizi web uygulamasına yüklemesine 1izin 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ı kilitlendi

Veritabanı geçişlerini bir Django uygulamasıyla çalıştırmaya çalışırken "sqlite3. 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 sorunlar

  • 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 oturumundaki komutlar kesilmiş gibi görünüyor: Düzenleyici sözcük kaydırma komutları olmayabilir, ancak 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