Azure App Service için Linux Python uygulaması yapılandırma

Bu makalede Azure App Service Python uygulamalarını nasıl çalıştırdığı, mevcut uygulamaları Azure'a nasıl geçirebileceğiniz ve gerektiğinde App Service 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 bir Git deposu veya derleme otomasyonu etkinleştirilmiş bir zip paketi dağıttığınızda sizin için çalışırpip install -r requirements.txt.

Bu kılavuz, App Service'da yerleşik bir Linux kapsayıcısı kullanan Python geliştiricileri için temel kavramlar ve yönergeler sağlar. Azure App Service 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 veya Azure CLI kullanabilirsiniz:

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

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

  • Azure Cloud Shell komutlarını ç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.

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> değerini 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 App Service desteklenen tüm Python sürümlerini gösterin:

    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 otomasyonlarını özelleştirme

App Service'nin Oryx adlı derleme sistemi, uygulama ayarı SCM_DO_BUILD_DURING_DEPLOYMENT olarak ayarlanırsa 1uygulamanızı dağıtırken aşağıdaki adımları gerçekleştirir:

1. Ayar tarafından PRE_BUILD_COMMAND belirtilirse özel bir derleme öncesi betiği çalıştırın. (Betiğin kendisi 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 öğesini ç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_COLLECTSTATICtruebu adım atlanır.

4. 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 bir komut echo Pre-build commandveya proje kökünüze göre 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ı gibi bir komut echo Post-build commandveya proje kökünüze göre bir betik dosyasının yolunu (gibi) 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'nin Linux'ta Python uygulamalarını nasıl çalıştırıp derlediğini öğrenmek için bkz. Oryx Python uygulamalarını nasıl algılar ve oluşturur?

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 devamında sürekli dağıtım ayarlayabilirsiniz.

   • App Service gerekli paketleri otomatik olarak yükleyebilmesi için requirements.txt dosyanızın 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, plan App Service ve web uygulaması App Service oluşturun. Azure CLI komutunu az webapp upçalıştırarak bunu kolayca yapabilirsiniz. Ya da Öğ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 grubu, plan App Service 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 kodunuzda 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: Uygulamanızı çalıştırmaya App Service 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, 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 için sürekli dağıtım makalesinde açıklandığı gibi GitHub Actions, Bitbucket veya Azure Repos sürekli dağıtımı ayarlayın. Alternatif olarak, Azure App Service 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 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ığında, değişiklikleri kaynak deponuza işleyebilmeli ve bu güncelleştirmelerin otomatik olarak App Service dağıtılabilmesi gerekir.

Django uygulamaları için üretim ayarları

Azure App Service gibi bir üretim ortamı için Django uygulamalarının Django'nun Dağıtım denetim listesini (djangoproject.com) izlemesi gerekir.

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

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. Örnek:

   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_DIRyarn gibi bir derleme aracının çalıştırıldığı bir yol oluşturmak için. Bir ortam değişkenini ve Uygulama Ayarını istediğiniz gibi yeniden kullanabilirsiniz.

3. requirements.txt dosyanıza ekleyinwhitenoise. Whitenoise (whitenoise.evans.io), üretim Django uygulamasının kendi statik dosyalarına hizmet vermesini basitleştiren bir Python paketidir. Whitenoise özellikle Django STATIC_ROOT değişkeni tarafından belirtilen klasörde bulunan dosyalara 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 Whitenoise içerecek şekilde değiştirinMIDDLEWARE:

   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'da hızlı başlangıç örnek Flask uygulamasına bakın.

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

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 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şkenleri 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 (docs.gunicorn.org) konusunda 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. App Service sonra projenizi dağıttığınızda bu bağımlılıkları otomatik olarak yükler.

  Bağımlılıkların yüklenebilmesi içinrequirements.txtdosyası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 otomatik olarak tanımlar, örneğinmsdocs-hello-world.azurewebsites.net. Ayrıca uygulamanızın adıyla (örneğinmsdocs-hello-world) tanımlarWEBSITE_SITE_NAME.

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

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. Sağlandıysa özel bir başlangıç komutu kullanın.
2. Bir Django uygulamasının olup olmadığını denetleyin ve algılanırsa Bunun için Gunicorn'u başlatın.
3. Bir Flask uygulamasının olup olmadığını denetleyin ve algılanırsa Bunun için Gunicorn'u 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ünüzün 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 dosya arar ve Gunicorn'u ş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 veya 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.

Yine, varsayılan uygulama yerine dağıtılan bir uygulama görmeyi bekliyorsanız bkz . Sorun Giderme - Uygulama görünmüyor.

Başlatmayı özelleştir komutu

Bir başlangıç komut dosyasında özel bir 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.txtgibi 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 için 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 uygulamanın Sorunları tanılama ve çözme sayfasına da göz atın.

Örnek başlangıç komutları

• Gunicorn bağımsız değişkenleri eklendi: Aşağıdaki örnek, bir Django uygulamasını başlatmak için öğesini bir 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'u Çalıştırma (docs.gunicorn.org). 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ı da dinamik olarak ayarlamanız gerekir, örneğin: --workers $((($NUM_CORES*2)+1)). Önerilen sayıda gunicorn çalışanı 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üğü (docs.gunicorn.org).

• Özel Flask ana modülü: Varsayılan olarak, App Service 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 tarafından 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'de ağ yük dengeleyicilerinde TLS/SSL sonlandırma (wikipedia.org) gerçekleşir, böylece tüm HTTPS istekleri uygulamanıza şifrelenmemiş HTTP istekleri olarak 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'ya üst bilgiyi kullanmasını söyleyebilirsiniz X-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> değerini 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ı adresinden https://<app-name>.scm.azurewebsites.net/api/logs/dockerbir tarayıcıda da inceleyebilirsiniz.

Azure portal üzerinden günlüklere erişmek için uygulamanızın sol tarafındakimenüden Günlük akışınıizleme'yi> 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 soldaki menüde 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..." ifadesinin 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 tam olarak 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.

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 en altında "SSH CONNECTION ESTABLISHED" 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 .

Sorun giderme

Genel olarak, sorun gidermenin ilk adımı App Service Tanılama'yı kullanmaktır:

1. Web uygulamanızın Azure portal 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 - varsayılan uygulama göster
• Uygulama görünmüyor - "hizmet kullanılamıyor" iletisi
• setup.py veya requirements.txtbulunamadı
• Başlatma sırasında ModuleNotFoundError
• Veritabanı kilitli
• Parolalar yazıldığında SSH oturumunda görünmüyor
• SSH oturumundaki komutlar kesilmiş gibi görünüyor
• Statik varlıklar Django uygulamasında görünmez
• Önemli SSL Bağlantısı Gerekli

Uygulama görünmüyor

• Kendi uygulama kodunuzu dağıttıktan sonra varsayılan uygulamayı görüyorsunuz. Varsayılan uygulama, uygulama kodunuzu App Service'a dağıtmadığınızdan veya App Service uygulama kodunuzu bulamadığından ve bunun yerine varsayılan uygulamayı çalıştırdığından görünür.

  • 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ğeriyle 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 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 yanıt beklerken zaman aşımına uğradı. Bu durum, App Service Gunicorn sunucusunu başlattığını ancak uygulamanın başlamadığını gösteriyor. 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ızda en düşük fiyatlandırma katmanlarını kullanıyorsanız tarayıcıyı yenileyin. Ücretsiz katmanları kullandığınızda uygulamanın başlaması daha uzun sürebilir ve tarayıcıyı yenilediğinizde yanıt verebilir.

  • 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ükler, uygulama kodundaki hataları gösterir.

setup.py veya requirements.txt bulunamadı

• Günlük akışında "setup.py veya requirements.txt bulunamadı; Pip yüklemesi ç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, siteyi dosyanın deponuzda var olmasını ve dağıtımınıza dahil olmasını sağlayın. Ayrı bir klasörde varsa kök klasörüne taşıyın.

Uygulama başlatıldığında ModuleNotFoundError

gibi ModuleNotFoundError: No module named 'example'bir hata görürseniz Python, uygulama başlatıldığında modüllerinizden birini veya daha fazlasını bulamadı. Bu hata genellikle sanal ortamınızı kodunuzla dağıtırsanız oluşur. Sanal ortamlar taşınabilir olmadığından, uygulama kodunuzla sanal ortam 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 her dağıttığınızda Oryx'i paketlerinizi yüklemeye zorlar. Daha fazla bilgi için lütfen 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. OperationalError: veritabanı kilitli." Hata, uygulamanızın Azure için PostgreSQL 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 içindeki örnekte bu hatayla karşılaşıyorsanız Bağlantı ayarlarını doğrulama altındaki adımları tamamladığınızdan emin olun.

Diğer sorunlar

• Parolalar yazıldığında SSH oturumunda görünmez: Güvenlik nedenleriyle, SSH oturumu yazdığınızda 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: Beyaz zehir modülünü etkinleştirdiğinizden emin olun

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

Diğer kaynaklar

• Öğretici: PostgreSQL ile Python uygulaması
• Öğretici: Özel kapsayıcı deposundan dağıtma
• App Service Linux Hakkında SSS
• Ortam değişkenleri ve uygulama ayarları başvurusu