Konfigurowanie aplikacji języka Python dla systemu Linux dla Azure App Service

  • Artykuł

W tym artykule opisano, jak Azure App Service uruchamia aplikacje w języku Python, jak można migrować istniejące aplikacje na platformę Azure oraz jak dostosować zachowanie App Service w razie potrzeby. Aplikacje języka Python muszą być wdrażane ze wszystkimi wymaganymi modułami pip .

Aparat wdrażania App Service automatycznie aktywuje środowisko wirtualne i uruchamia pip install -r requirements.txt je podczas wdrażania repozytorium Git lub pakietu zipz włączoną automatyzacją kompilacji.

Ten przewodnik zawiera kluczowe pojęcia i instrukcje dla deweloperów języka Python, którzy korzystają z wbudowanego kontenera systemu Linux w App Service. Jeśli nigdy nie używasz Azure App Service, najpierw postępuj zgodnie z samouczkiem Szybki start dla języka Python i językiem Python z bazą danych PostgreSQL.

Do skonfigurowania można użyć Azure Portal lub interfejsu wiersza polecenia platformy Azure:

Uwaga

Linux jest jedyną opcją systemu operacyjnego do uruchamiania aplikacji języka Python w App Service. Język Python w systemie Windows nie jest już obsługiwany. Możesz jednak utworzyć własny niestandardowy obraz kontenera systemu Windows i uruchomić go w App Service. Aby uzyskać więcej informacji, zobacz Używanie niestandardowego obrazu platformy Docker.

Konfigurowanie wersji języka Python

  • Azure Portal: użyj karty Ustawienia ogólne na stronie Konfiguracja zgodnie z opisem w temacie Konfigurowanie ogólnych ustawień kontenerów systemu Linux.

  • Interfejs wiersza polecenia platformy Azure:

    • Pokaż bieżącą wersję języka Python za pomocą polecenia az webapp config show:

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

      Zastąp <resource-group-name> wartości i <app-name> nazwami odpowiednimi dla aplikacji internetowej.

    • Ustawianie wersji języka Python za pomocą polecenia az webapp config set

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

    • Pokaż wszystkie wersje języka Python obsługiwane w Azure App Service za pomocą polecenia az webapp list-runtimes:

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

Możesz uruchomić nieobsługiwaną wersję języka Python, kompilując w zamian własny obraz kontenera. Aby uzyskać więcej informacji, zobacz Używanie niestandardowego obrazu platformy Docker.

Dostosowywanie automatyzacji kompilacji

system kompilacji App Service o nazwie Oryx wykonuje następujące kroki podczas wdrażania aplikacji, jeśli ustawienie SCM_DO_BUILD_DURING_DEPLOYMENT aplikacji ma wartość 1:

  1. Uruchom niestandardowy skrypt przed kompilacją PRE_BUILD_COMMAND , jeśli zostanie określony przez ustawienie. (Skrypt może uruchamiać inne skrypty języka Python i Node.js, polecenia pip i npm oraz narzędzia oparte na węzłach, takie jak yarn, yarn install na przykład i yarn build.)

  2. Uruchom polecenie pip install -r requirements.txt. Plik requirements.txt musi znajdować się w folderze głównym projektu. W przeciwnym razie proces kompilacji zgłasza błąd: "Nie można odnaleźć setup.py lub requirements.txt; Nie można uruchomić instalacji narzędzia pip".

  3. Jeśli manage.py znajduje się w katalogu głównym repozytorium (wskazującym aplikację Django), uruchom polecenie manage.py collectstatic. Jeśli DISABLE_COLLECTSTATIC jednak ustawienie to true, ten krok zostanie pominięty.

  4. Uruchom niestandardowy skrypt po kompilacji POST_BUILD_COMMAND , jeśli zostanie określony przez ustawienie. (Ponownie skrypt może uruchamiać inne skrypty języka Python i Node.js, polecenia pip i npm oraz narzędzia oparte na węzłach).

Domyślnie PRE_BUILD_COMMANDustawienia , POST_BUILD_COMMANDi DISABLE_COLLECTSTATIC są puste.

  • Aby wyłączyć uruchamianie funkcji collectstatic podczas kompilowania aplikacji Django, ustaw DISABLE_COLLECTSTATIC ustawienie na true.

  • Aby uruchomić polecenia przed kompilacją, ustaw PRE_BUILD_COMMAND ustawienie tak, aby zawierało polecenie, takie jak echo Pre-build command, lub ścieżkę do pliku skryptu względem katalogu głównego projektu, na przykład scripts/prebuild.sh. Wszystkie polecenia muszą używać ścieżek względnych do folderu głównego projektu.

  • Aby uruchomić polecenia po kompilacji, ustaw POST_BUILD_COMMAND ustawienie tak, aby zawierało polecenie, takie jak echo Post-build command, lub ścieżkę do pliku skryptu względem katalogu głównego projektu, na przykład scripts/postbuild.sh. Wszystkie polecenia muszą używać ścieżek względnych do folderu głównego projektu.

Aby uzyskać informacje o innych ustawieniach, które dostosowują automatyzację kompilacji, zobacz Konfiguracja Oryx.

Aby uzyskać dostęp do dzienników kompilacji i wdrażania, zobacz Uzyskiwanie dostępu do dzienników wdrażania.

Aby uzyskać więcej informacji na temat sposobu uruchamiania i kompilowanie aplikacji języka Python w systemie Linux App Service, zobacz Jak oryx wykrywa i kompiluje aplikacje języka Python.

Uwaga

Ustawienia PRE_BUILD_SCRIPT_PATH i POST_BUILD_SCRIPT_PATH są identyczne z PRE_BUILD_COMMAND ustawieniami i POST_BUILD_COMMAND są obsługiwane w starszych celach.

Ustawienie o nazwie SCM_DO_BUILD_DURING_DEPLOYMENT, jeśli zawiera true wartość lub 1, wyzwala kompilację Oryx podczas wdrażania. To ustawienie ma wartość true podczas wdrażania przy użyciu narzędzia git, polecenia interfejsu wiersza polecenia az webapp upplatformy Azure i Visual Studio Code.

Uwaga

Zawsze używaj ścieżek względnych we wszystkich skryptach przed i po kompilacji, ponieważ kontener kompilacji, w którym działa Oryx, różni się od kontenera środowiska uruchomieniowego, w którym działa aplikacja. Nigdy nie polegaj na dokładnym umieszczeniu folderu projektu aplikacji w kontenerze (na przykład, że znajduje się on w folderze site/wwwroot).

Migrowanie istniejących aplikacji na platformę Azure

Istniejące aplikacje internetowe można ponownie wdrożyć na platformie Azure w następujący sposób:

  1. Repozytorium źródłowe: zachowaj kod źródłowy w odpowiednim repozytorium, takim jak GitHub, co umożliwia skonfigurowanie ciągłego wdrażania w dalszej części tego procesu.

    • Plik requirements.txt musi znajdować się w katalogu głównym repozytorium, aby App Service automatycznie instalować niezbędne pakiety.

  2. Baza danych: jeśli aplikacja zależy od bazy danych, utwórz również niezbędne zasoby na platformie Azure.

  3. Zasoby usługi App Service: utwórz grupę zasobów, plan App Service i App Service aplikację internetową do hostowania aplikacji. Możesz to łatwo zrobić, uruchamiając polecenie interfejsu wiersza polecenia az webapp upplatformy Azure . Możesz też utworzyć i wdrożyć zasoby, jak pokazano w temacie Samouczek: wdrażanie aplikacji internetowej w języku Python (Django lub Flask) przy użyciu bazy danych PostgreSQL. Zastąp nazwy grupy zasobów, App Service Plan i aplikacją internetową, aby bardziej pasować do aplikacji.

  4. Zmienne środowiskowe: jeśli aplikacja wymaga dowolnych zmiennych środowiskowych, utwórz równoważne App Service ustawienia aplikacji. Te ustawienia App Service są wyświetlane jako zmienne środowiskowe, zgodnie z opisem w temacie Access environment variables (Uzyskiwanie dostępu do zmiennych środowiskowych).

  5. Uruchamianie aplikacji: przejrzyj sekcję Proces uruchamiania kontenera w dalszej części tego artykułu, aby dowiedzieć się, jak App Service próbuje uruchomić aplikację. App Service domyślnie używa serwera sieci Web Gunicorn, który musi być w stanie znaleźć obiekt aplikacji lub folder wsgi.py. W razie potrzeby możesz dostosować polecenie uruchamiania.

  6. Ciągłe wdrażanie: skonfiguruj ciągłe wdrażanie z GitHub Actions, Bitbucket lub Azure Repos zgodnie z opisem w artykule Ciągłe wdrażanie do Azure App Service. Możesz też skonfigurować ciągłe wdrażanie z lokalnej usługi Git zgodnie z opisem w artykule Lokalne wdrożenie git w celu Azure App Service.

  7. Akcje niestandardowe: aby wykonać akcje w kontenerze App Service, który hostuje aplikację, na przykład migracje bazy danych Django, możesz nawiązać połączenie z kontenerem za pośrednictwem protokołu SSH. Przykład uruchamiania migracji baz danych Django można znaleźć w temacie Tutorial: Deploy a Django web app with PostgreSQL - generate database schema (Samouczek: wdrażanie aplikacji internetowej Django przy użyciu bazy danych PostgreSQL — generowanie schematu bazy danych).

Po wykonaniu tych kroków powinno być możliwe zatwierdzenie zmian w repozytorium źródłowym i automatyczne wdrożenie tych aktualizacji w App Service.

Ustawienia produkcyjne dla aplikacji Django

W przypadku środowiska produkcyjnego, takiego jak Azure App Service, aplikacje Django powinny być zgodne z listą kontrolną wdrożenia Django (djangoproject.com).

W poniższej tabeli opisano ustawienia produkcyjne, które są istotne dla platformy Azure. Te ustawienia są definiowane w pliku setting.py aplikacji.

Ustawienie Django Instrukcje dotyczące platformy Azure
SECRET_KEY Zapisz wartość w ustawieniu App Service zgodnie z opisem w temacie Access app settings as environment variables (Ustawienia aplikacji programu Access jako zmienne środowiskowe). Możesz również przechowywać wartość jako "wpis tajny" w usłudze Azure Key Vault.
DEBUG DEBUG Utwórz ustawienie dla App Service z wartością 0 (false), a następnie załaduj wartość jako zmienną środowiskową. W środowisku projektowym utwórz zmienną środowiskową DEBUG z wartością 1 (true).
ALLOWED_HOSTS W środowisku produkcyjnym platforma Django wymaga uwzględnienia adresu URL aplikacji w ALLOWED_HOSTS tablicy settings.py. Ten adres URL można pobrać w czasie wykonywania przy użyciu kodu os.environ['WEBSITE_HOSTNAME']. App Service automatycznie ustawia zmienną WEBSITE_HOSTNAME środowiskową na adres URL aplikacji.
DATABASES Zdefiniuj ustawienia w App Service dla połączenia z bazą danych i załaduj je jako zmienne środowiskowe w celu wypełnienia słownikaDATABASES. Możesz również przechowywać wartości (zwłaszcza nazwę użytkownika i hasło) jako wpisy tajne usługi Azure Key Vault.

Obsługa plików statycznych dla aplikacji Django

Jeśli aplikacja internetowa Django zawiera statyczne pliki frontonu, najpierw postępuj zgodnie z instrukcjami w temacie Zarządzanie plikami statycznymi w dokumentacji platformy Django.

W przypadku App Service należy wprowadzić następujące modyfikacje:

  1. Rozważ użycie zmiennych środowiskowych (na potrzeby programowania lokalnego) i ustawień aplikacji (podczas wdrażania w chmurze), aby dynamicznie ustawiać zmienne Django STATIC_URL i STATIC_ROOT . Przykład:

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

    DJANGO_STATIC_URL i DJANGO_STATIC_ROOT można je zmienić w razie potrzeby w środowiskach lokalnych i w chmurze. Jeśli na przykład proces kompilacji dla plików statycznych umieszcza je w folderze o nazwie django-static, możesz ustawić tak DJANGO_STATIC_URL , aby /django-static/ uniknąć używania wartości domyślnej.

  2. Jeśli masz skrypt przed kompilacją, który generuje pliki statyczne w innym folderze, uwzględnij ten folder w zmiennej Django, aby proces Django STATICFILES_DIRScollectstatic je znalazł. Jeśli na przykład uruchomisz polecenie yarn build w folderze frontonu, a usługa yarn wygeneruje build/static folder zawierający pliki statyczne, dołącz ten folder w następujący sposób:

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

    W tym miejscu należy FRONTEND_DIRutworzyć ścieżkę do miejsca, w którym jest uruchamiane narzędzie kompilacji, takie jak yarn. Możesz ponownie użyć zmiennej środowiskowej i ustawienia aplikacji zgodnie z potrzebami.

  3. Dodaj whitenoise element do pliku requirements.txt . Whitenoise (whitenoise.evans.io) to pakiet języka Python, który ułatwia obsługę własnych plików statycznych przez produkcyjną aplikację Django. Whitenoise konkretnie obsługuje te pliki, które znajdują się w folderze określonym przez zmienną Django STATIC_ROOT .

  4. W pliku settings.py dodaj następujący wiersz whitenoise:

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Zmodyfikuj również listy i INSTALLED_APPS , MIDDLEWARE aby zawierały whitenoise:

    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
]

Obsługa plików statycznych dla aplikacji platformy Flask

Jeśli aplikacja internetowa platformy Flask zawiera statyczne pliki frontonu, najpierw postępuj zgodnie z instrukcjami dotyczącymi zarządzania plikami statycznymi w dokumentacji platformy Flask. Aby zapoznać się z przykładem obsługi plików statycznych w aplikacji platformy Flask, zobacz przykładową aplikację flask z przewodnika Szybki start w witrynie GitHub.

Aby obsługiwać pliki statyczne bezpośrednio z trasy w aplikacji, możesz użyć send_from_directory metody :

from flask import send_from_directory

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

Właściwości kontenera

Po wdrożeniu w App Service aplikacje języka Python są uruchamiane w kontenerze platformy Docker systemu Linux zdefiniowanym w repozytorium GitHub App Service Python. Konfiguracje obrazów można znaleźć w katalogach specyficznych dla wersji.

Ten kontener ma następujące cechy:

  • Aplikacje są uruchamiane przy użyciu serwera HTTP Gunicorn WSGI przy użyciu dodatkowych argumentów --bind=0.0.0.0 --timeout 600.

    • Ustawienia konfiguracji dla serwera Gunicorn można podać , dostosowując polecenie uruchamiania.

    • Aby chronić aplikację internetową przed przypadkowymi lub celowymi atakami DDOS, serwer Gunicorn jest uruchamiany za zwrotnym serwerem proxy Nginx zgodnie z opisem w temacie Deploying Gunicorn (docs.gunicorn.org).

  • Domyślnie podstawowy obraz kontenera zawiera tylko strukturę internetową platformy Flask, ale kontener obsługuje inne struktury zgodne z usługą WSGI i zgodne z językiem Python 3.6 lub nowszym, takie jak Django.

  • Aby zainstalować inne pakiety, takie jak Django, utwórz plik requirements.txt w katalogu głównym projektu, który określa bezpośrednie zależności. App Service następnie automatycznie instaluje te zależności podczas wdrażania projektu.

    Plik requirements.txtmusi znajdować się w katalogu głównym projektu, aby można było zainstalować zależności. W przeciwnym razie proces kompilacji zgłasza błąd: "Nie można odnaleźć setup.py lub requirements.txt; Nie można uruchomić instalacji narzędzia pip". Jeśli wystąpi ten błąd, sprawdź lokalizację pliku wymagań.

  • App Service automatycznie definiuje zmienną środowiskową o nazwie przy użyciu WEBSITE_HOSTNAME adresu URL aplikacji internetowej, na przykład msdocs-hello-world.azurewebsites.net. Definiuje WEBSITE_SITE_NAME również nazwę aplikacji, na przykład msdocs-hello-world.

  • Narzędzia npm i Node.js są instalowane w kontenerze, aby można było uruchamiać narzędzia kompilacji oparte na węźle, takie jak yarn.

Proces uruchamiania kontenera

Podczas uruchamiania kontener usługi App Service w systemie Linux wykonuje następujące kroki:

  1. Użyj niestandardowego polecenia uruchomienia, jeśli zostało udostępnione.
  2. Sprawdź istnienie aplikacji Django, a następnie uruchom dla niej serwer Gunicorn, jeśli zostanie wykryta.
  3. Sprawdź istnienie aplikacji Flask, a następnie uruchom dla niej serwer Gunicorn, jeśli zostanie wykryta.
  4. Jeśli nie została znaleziona żadna inna aplikacja, uruchomienie domyślnej aplikacji wbudowanej w kontener.

Poniższe sekcje zawierają dodatkowe szczegóły dla każdej opcji.

Aplikacja platformy Django

W przypadku aplikacji Django usługa App Service szuka pliku o nazwie wsgi.py w kodzie aplikacji, a następnie uruchamia serwer Gunicorn przy użyciu następującego polecenia:

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

Jeśli chcesz mieć bardziej szczegółową kontrolę nad poleceniem uruchamiania, użyj niestandardowego polecenia uruchamiania, zastąp <module> ciąg nazwą folderu zawierającego wsgi.py i dodaj --chdir argument, jeśli ten moduł nie znajduje się w katalogu głównym projektu. Jeśli na przykład wsgi.py znajduje się w lokalizacji knboard/backend/config z katalogu głównego projektu, użyj argumentów --chdir knboard/backend config.wsgi.

Aby włączyć rejestrowanie produkcyjne, dodaj --access-logfile parametry i --error-logfile , jak pokazano w przykładach dla niestandardowych poleceń uruchamiania.

Aplikacja Flask

W przypadku aplikacji Flask usługa App Service szuka pliku o nazwie application.py lub app.py i uruchamia serwer Gunicorn w następujący sposób:

# 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

Jeśli główny moduł aplikacji znajduje się w innym pliku, użyj innej nazwy dla obiektu aplikacji lub chcesz podać inne argumenty dla serwera Gunicorn, użyj niestandardowego polecenia uruchamiania.

Zachowanie domyślne

Jeśli App Service nie znajdzie polecenia niestandardowego, aplikacji Django lub aplikacji Platformy Flask, zostanie uruchomiona domyślna aplikacja tylko do odczytu znajdująca się w folderze opt/defaultsite i pokazana na poniższej ilustracji.

Jeśli wdrożono kod i nadal widzisz aplikację domyślną, zobacz Rozwiązywanie problemów — aplikacja nie jest wyświetlana.

Zrzut ekranu przedstawiający domyślną stronę internetową App Service dla systemu Linux.

Ponownie, jeśli spodziewasz się, że zostanie wyświetlona wdrożona aplikacja zamiast aplikacji domyślnej, zobacz Rozwiązywanie problemów — aplikacja nie jest wyświetlana.

Dostosowywanie polecenia uruchamiania

Zachowanie uruchamiania kontenera można kontrolować, podając niestandardowe polecenie uruchamiania lub wiele poleceń w pliku poleceń uruchamiania. Plik polecenia uruchamiania może używać dowolnej wybranej nazwy, takiej jak startup.sh, startup.cmd, startup.txtitd.

Wszystkie polecenia muszą używać ścieżek względnych do folderu głównego projektu.

Aby określić polecenie uruchamiania lub plik polecenia:

  • Azure Portal: wybierz stronę Konfiguracja aplikacji, a następnie wybierz pozycję Ustawienia ogólne. W polu Polecenie uruchamiania umieść pełny tekst polecenia uruchamiania lub nazwę pliku polecenia uruchamiania. Następnie wybierz pozycję Zapisz , aby zastosować zmiany. Zobacz Konfigurowanie ustawień ogólnych dla kontenerów systemu Linux.

  • Interfejs wiersza polecenia platformy Azure: użyj polecenia az webapp config set z parametrem --startup-file , aby ustawić polecenie lub plik uruchamiania:

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

    Zastąp <custom-command> ciąg pełnym tekstem polecenia uruchamiania lub nazwą pliku polecenia uruchamiania.

App Service ignoruje wszelkie błędy występujące podczas przetwarzania niestandardowego polecenia lub pliku uruchamiania, a następnie kontynuuje proces uruchamiania, wyszukując aplikacje Django i Flask. Jeśli nie widzisz oczekiwanego zachowania, sprawdź, czy polecenie uruchamiania lub plik jest wolny od błędów i czy plik polecenia uruchamiania jest wdrażany w App Service wraz z kodem aplikacji. Możesz również sprawdzić dzienniki diagnostyczne , aby uzyskać więcej informacji. Sprawdź również stronę Diagnozowanie i rozwiązywanie problemów aplikacji na Azure Portal.

Przykładowe polecenia uruchamiania

  • Dodano argumenty gunicorn: Poniższy przykład dodaje --workers=4 element do wiersza polecenia Gunicorn do uruchamiania aplikacji Django:

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

    Aby uzyskać więcej informacji, zobacz Running Gunicorn (Uruchamianie serwera Gunicorn) (docs.gunicorn.org). Jeśli używasz reguł automatycznego skalowania do skalowania aplikacji internetowej w górę i w dół, należy również dynamicznie ustawić liczbę procesów roboczych gunicorn przy użyciu NUM_CORES zmiennej środowiskowej w poleceniu uruchamiania, na przykład: --workers $((($NUM_CORES*2)+1)). Aby uzyskać więcej informacji na temat ustawiania zalecanej liczby pracowników gunicorn, zobacz Często zadawane pytania dotyczące serwera Gunicorn

  • Włącz rejestrowanie produkcyjne dla platformy Django: dodaj --access-logfile '-' argumenty i --error-logfile '-' do wiersza polecenia:

    # '-' 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 '-'

    Te dzienniki będą wyświetlane w strumieniu dziennika App Service.

    Aby uzyskać więcej informacji, zobacz Rejestrowanie serwera Gunicorn (docs.gunicorn.org).

  • Niestandardowy moduł główny platformy Flask: domyślnie App Service zakłada, że główny moduł aplikacji Flask jest application.py lub app.py. Jeśli moduł główny używa innej nazwy, musisz dostosować polecenie uruchamiania. Jeśli na przykład masz aplikację Flask z modułem głównym hello.py, a obiekt aplikacji Flask w tym pliku nosi nazwę myapp, to polecenie wygląda następująco:

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

    Jeśli moduł główny znajduje się w podfolderze, takim jak website, określ ten folder za pomocą argumentu --chdir:

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

  • Użyj serwera innego niż Gunicorn: aby użyć innego serwera internetowego, takiego jak aiohttp, użyj odpowiedniego polecenia jako polecenia uruchamiania lub w pliku polecenia uruchamiania:

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

Uzyskiwanie dostępu do ustawień aplikacji jako zmiennych środowiskowych

Ustawienia aplikacji to wartości przechowywane w chmurze specjalnie dla aplikacji zgodnie z opisem w temacie Konfigurowanie ustawień aplikacji. Te ustawienia są dostępne dla kodu aplikacji jako zmienne środowiskowe i dostępne przy użyciu standardowego wzorca os.environ .

Jeśli na przykład utworzono ustawienie aplikacji o nazwie DATABASE_SERVER, następujący kod pobiera wartość tego ustawienia:

db_server = os.environ['DATABASE_SERVER']

Wykrywanie sesji protokołu HTTPS

W App Service zakończenie protokołu TLS/SSL (wikipedia.org) odbywa się w modułach równoważenia obciążenia sieciowego, dlatego wszystkie żądania HTTPS docierają do aplikacji jako niezaszyfrowane żądania HTTP. Jeśli logika aplikacji musi sprawdzać, czy żądania użytkownika są szyfrowane, czy nie, zbadaj nagłówek X-Forwarded-Proto.

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

Popularne platformy internetowe umożliwiają dostęp do informacji X-Forwarded-* w standardowym wzorcu aplikacji. Na przykład w Django możesz użyć SECURE_PROXY_SSL_HEADER , aby poinformować Django, aby użyć nagłówka X-Forwarded-Proto .

Uzyskiwanie dostępu do dzienników diagnostycznych

Dostęp do dzienników konsoli wygenerowanych z poziomu kontenera.

Najpierw włącz rejestrowanie kontenerów, uruchamiając następujące polecenie:

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

Zastąp <app-name> wartości i <resource-group-name> nazwami odpowiednimi dla aplikacji internetowej.

Po włączeniu rejestrowania kontenerów uruchom następujące polecenie, aby wyświetlić strumień dziennika:

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

Jeśli nie widzisz dzienników konsoli, sprawdź ponownie w ciągu 30 sekund.

Aby zatrzymać przesyłanie strumieniowe dzienników w dowolnym momencie, naciśnij klawisze Ctrl+C.

Możesz również sprawdzić pliki dziennika w przeglądarce pod adresem https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Aby uzyskać dostęp do dzienników za pośrednictwem Azure Portal, wybierz pozycjęStrumień dziennikamonitorowania> w menu po lewej stronie aplikacji.

Uzyskiwanie dostępu do dzienników wdrażania

Podczas wdrażania kodu App Service wykonuje proces kompilacji opisany wcześniej w sekcji Dostosowywanie automatyzacji kompilacji. Ponieważ kompilacja jest uruchamiana we własnym kontenerze, dzienniki kompilacji są przechowywane oddzielnie od dzienników diagnostycznych aplikacji.

Aby uzyskać dostęp do dzienników wdrażania, wykonaj następujące kroki:

  1. W Azure Portal aplikacji internetowej wybierz pozycję Centrum wdrażania> w menu po lewej stronie.
  2. Na karcie Dzienniki wybierz identyfikator zatwierdzenia dla ostatniego zatwierdzenia.
  3. Na wyświetlonej stronie Szczegóły dziennika wybierz link Pokaż dzienniki... wyświetlany obok pozycji "Uruchomiona kompilacja oryx...".

Problemy z kompilacją, takie jak nieprawidłowe zależności w requirements.txt i błędy w skryptach wstępnych lub po kompilacji, będą wyświetlane w tych dziennikach. Błędy są również wyświetlane, jeśli plik wymagań nie ma dokładnie nazwy requirements.txt lub nie jest wyświetlany w folderze głównym projektu.

Otwieranie sesji SSH w przeglądarce

Aby otworzyć bezpośrednią sesję SSH w kontenerze, należy uruchomić aplikację.

Wklej następujący adres URL do przeglądarki i zastąp wartość <app-name> nazwą swojej aplikacji:

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

Jeśli nie masz jeszcze uwierzytelnienia, musisz uwierzytelnić się w subskrypcji platformy Azure, aby nawiązać połączenie. Po uwierzytelnieniu zostanie wyświetlona powłoka w przeglądarce umożliwiająca uruchamianie poleceń w kontenerze.

Połączenie SSH

Uwaga

Wszelkie zmiany wprowadzone poza katalogiem /home są przechowywane w samym kontenerze i nie są zachowywane po ponownym uruchomieniu aplikacji.

Aby otworzyć zdalną sesję SSH z komputera lokalnego, zobacz Otwieranie sesji SSH z poziomu powłoki zdalnej.

Po pomyślnym nawiązaniu połączenia z sesją SSH w dolnej części okna powinien zostać wyświetlony komunikat "NAWIĄZANO POŁĄCZENIE SSH". Jeśli widzisz błędy, takie jak "SSH_CONNECTION_CLOSED" lub komunikat informujący o ponownym uruchomieniu kontenera, błąd może uniemożliwić uruchomienie kontenera aplikacji. Zobacz Rozwiązywanie problemów, aby zapoznać się z możliwymi problemami.

Rozwiązywanie problemów

Ogólnie rzecz biorąc, pierwszym krokiem rozwiązywania problemów jest użycie diagnostyki App Service:

  1. W Azure Portal aplikacji internetowej wybierz pozycję Diagnozuj i rozwiąż problemy z menu po lewej stronie.
  2. Wybierz pozycję Dostępność i wydajność.
  3. Zapoznaj się z informacjami w opcjach Dzienniki aplikacji, Awaria kontenera i Problemy z kontenerem , w których pojawią się najczęstsze problemy.

Następnie sprawdź zarówno dzienniki wdrażania , jak i dzienniki aplikacji pod kątem wszystkich komunikatów o błędach. Dzienniki te często identyfikują określone problemy, które mogą uniemożliwiać wdrażanie aplikacji lub uruchamianie aplikacji. Na przykład kompilacja może zakończyć się niepowodzeniem, jeśli plik requirements.txt ma nieprawidłową nazwę pliku lub nie jest obecny w folderze głównym projektu.

Poniższe sekcje zawierają wskazówki dotyczące określonych problemów.

Aplikacja nie jest wyświetlana

  • Po wdrożeniu własnego kodu aplikacji wyświetlana jest aplikacja domyślna. Zostanie wyświetlona aplikacja domyślna, ponieważ kod aplikacji nie został wdrożony do App Service lub App Service nie można odnaleźć kodu aplikacji i zamiast tego uruchomiła aplikację domyślną.

    • Uruchom ponownie usługę App Service, poczekaj 15–20 sekund i sprawdź ponownie aplikację.

    • Użyj protokołu SSH, aby połączyć się bezpośrednio z kontenerem App Service i sprawdzić, czy pliki istnieją w folderze site/wwwroot. Jeśli pliki nie istnieją, wykonaj następujące czynności:

      1. Utwórz ustawienie aplikacji o nazwie o SCM_DO_BUILD_DURING_DEPLOYMENT wartości 1, ponownie wdróż kod, zaczekaj kilka minut, a następnie spróbuj ponownie uzyskać dostęp do aplikacji. Aby uzyskać więcej informacji na temat tworzenia ustawień aplikacji, zobacz Konfigurowanie aplikacji App Service w Azure Portal.
      2. Przejrzyj proces wdrażania, sprawdź dzienniki wdrażania, popraw wszelkie błędy i ponownie wdróż aplikację.

    • Jeśli pliki istnieją, oznacza to, że usługa App Service nie mogła zidentyfikować określonego pliku startowego. Sprawdź, czy aplikacja jest ustrukturyzowana zgodnie z oczekiwaniami App Service dla platformy Django lub Flask, lub użyj niestandardowego polecenia uruchamiania.

  • W przeglądarce zostanie wyświetlony komunikat "Usługa niedostępna". Upłynął limit czasu przeglądarki w oczekiwaniu na odpowiedź z App Service, co oznacza, że App Service uruchomiono serwer Gunicorn, ale sama aplikacja nie została uruchomiona. Ten warunek może wskazywać, że argumenty Gunicorn są niepoprawne lub że w kodzie aplikacji występuje błąd.

    • Odśwież okno przeglądarki, zwłaszcza jeśli korzystasz z niższych warstw cenowych w planie usługi App Service. Na przykład podczas korzystania z warstw bezpłatnych aplikacja może być uruchamiana dłużej i zacznie odpowiadać po odświeżeniu okna przeglądarki.

    • Sprawdź, czy aplikacja jest ustrukturyzowana zgodnie z oczekiwaniami App Service dla platformy Django lub Flask, lub użyj niestandardowego polecenia uruchamiania.

    • Sprawdź strumień dziennika aplikacji pod kątem wszelkich komunikatów o błędach. Dzienniki będą zawierać błędy w kodzie aplikacji.

Nie można odnaleźć setup.py lub requirements.txt

  • Strumień dziennika pokazuje komunikat "Nie można odnaleźć setup.py lub requirements.txt; Nie uruchomiono instalacji narzędzia pip.": Proces kompilacji Oryx nie może odnaleźć pliku requirements.txt .

    • Nawiąż połączenie z kontenerem aplikacji internetowej za pośrednictwem protokołu SSH i sprawdź, czy requirements.txt jest poprawnie nazwana i istnieje bezpośrednio w folderze site/wwwroot. Jeśli nie istnieje, utwórz witrynę, aby plik istniał w repozytorium i został uwzględniony we wdrożeniu. Jeśli istnieje on w osobnym folderze, przenieś go do katalogu głównego.

ModuleNotFoundError podczas uruchamiania aplikacji

Jeśli zostanie wyświetlony błąd, taki jak ModuleNotFoundError: No module named 'example', język Python nie może odnaleźć co najmniej jednego modułu po uruchomieniu aplikacji. Ten błąd występuje najczęściej w przypadku wdrożenia środowiska wirtualnego przy użyciu kodu. Środowiska wirtualne nie są przenośne, więc środowisko wirtualne nie powinno być wdrażane przy użyciu kodu aplikacji. Zamiast tego pozwól oryxowi utworzyć środowisko wirtualne i zainstalować pakiety w aplikacji internetowej, tworząc ustawienie aplikacji , SCM_DO_BUILD_DURING_DEPLOYMENTi ustawiając je na 1. To ustawienie wymusi zainstalowanie pakietów przez program Oryx przy każdym wdrożeniu w App Service. Aby uzyskać więcej informacji, zobacz ten artykuł dotyczący przenośności środowiska wirtualnego.

Baza danych jest zablokowana

Podczas próby uruchomienia migracji bazy danych za pomocą aplikacji Django może zostać wyświetlony komunikat "sqlite3. OperationalError: baza danych jest zablokowana". Błąd wskazuje, że aplikacja używa bazy danych SQLite, dla której platforma Django jest domyślnie skonfigurowana zamiast używać bazy danych w chmurze, takiej jak PostgreSQL dla platformy Azure.

Sprawdź zmienną DATABASES w pliku settings.py aplikacji, aby upewnić się, że aplikacja używa bazy danych w chmurze zamiast SQLite.

Jeśli ten błąd występuje w przykładzie w artykule Samouczek: wdrażanie aplikacji internetowej Django za pomocą bazy danych PostgreSQL, sprawdź, czy zostały wykonane kroki opisane w artykule Weryfikowanie ustawień połączenia.

Inne problemy

  • Hasła nie są wyświetlane w sesji SSH podczas wpisywania: ze względów bezpieczeństwa sesja SSH przechowuje hasło ukryte podczas wpisywania. Znaki są rejestrowane, więc wpisz hasło w zwykły sposób i naciśnij klawisz Enter po zakończeniu.

  • Polecenia w sesji SSH wydają się być odcięte: Edytor może nie być poleceniami opakowującym wyrazy, ale nadal powinny działać poprawnie.

  • Zasoby statyczne nie są wyświetlane w aplikacji Django: upewnij się, że włączono moduł whitenoise

  • Zostanie wyświetlony komunikat "Krytyczne połączenie SSL jest wymagane": Sprawdź wszystkie nazwy użytkowników i hasła używane do uzyskiwania dostępu do zasobów (takich jak bazy danych) z poziomu aplikacji.

Więcej zasobów