Udostępnij za pomocą

Skonfiguruj aplikację Python na Linuxie dla usługi Azure App Service

Wdrażanie na platformie Azure

W tym artykule opisano sposób uruchamiania aplikacji w języku Python przez usługę Azure App Service , sposobu migrowania istniejących aplikacji na platformę Azure oraz dostosowywania zachowania usługi App Service w razie potrzeby. Aplikacje języka Python muszą być wdrażane ze wszystkimi wymaganymi modułami pip.

Aparat wdrażania usługi App Service automatycznie aktywuje środowisko wirtualne i instaluje zależności z pliku requirements.txt, pyproject.toml lub setup.py podczas wdrażania repozytorium Git lub pakietu zip przy włączonej automatyzacji kompilacji.

Ten artykuł zawiera kluczowe pojęcia i instrukcje dla deweloperów języka Python korzystających z wbudowanego kontenera systemu Linux w usłudze App Service. Jeśli nigdy nie używasz usługi App Service, najpierw ukończ samouczek Szybki start dla języka Python i platformę Flask, Django lub FastAPI z usługą PostgreSQL.

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

Uwaga

Linux to jedyna opcja systemu operacyjnego do uruchamiania aplikacji języka Python w usłudze 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 usłudze App Service. Aby uzyskać więcej informacji, zobacz Używanie niestandardowego obrazu platformy Docker.

Konfigurowanie wersji języka Python

  • Witryna 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 przy użyciu 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.

    • Ustaw wersję języka Python przy użyciu polecenia az webapp config set:

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

    • Pokaż wszystkie wersje języka Python obsługiwane w usłudze App Service przy użyciu polecenia az webapp list-runtimes:

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

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

Co się stanie z nieaktualnymi środowiskami uruchomieniowymi w usłudze App Service?

Nieaktualne środowiska uruchomieniowe są przestarzałe przez utrzymanie organizacji lub mają znaczące luki w zabezpieczeniach. W związku z tym są one usuwane z tworzenia i konfigurowania stron w portalu. Gdy nieaktualne środowisko uruchomieniowe jest ukryte w portalu, każda aplikacja, która nadal korzysta z tego środowiska uruchomieniowego, będzie nadal działać.

Jeśli chcesz utworzyć aplikację z nieaktualną wersją środowiska uruchomieniowego, która nie jest już wyświetlana w portalu, użyj interfejsu wiersza polecenia platformy Azure, szablonu usługi ARM lub Bicep. Te alternatywy wdrażania umożliwiają tworzenie przestarzałych środowisk uruchomieniowych, które są usuwane z portalu, ale nadal są obsługiwane.

Jeśli środowisko uruchomieniowe zostanie w pełni usunięte z platformy App Service, właściciel subskrypcji platformy Azure otrzyma powiadomienie e-mail przed usunięciem.

Dostosowywanie automatyzacji kompilacji

Uwaga

Gdy aplikacje języka Python są wdrażane za pomocą automatyzacji kompilacji, zawartość jest wdrażana i obsługiwana z /tmp/<uid>programu , a nie w obszarze /home/site/wwwroot. Dostęp do tego katalogu zawartości można uzyskać przy użyciu zmiennej środowiskowej APP_PATH . Należy zapisać wszelkie dodatkowe pliki utworzone w czasie wykonywania w lokalizacji w obszarze /home lub przy użyciu funkcji Bring Your Own Storage w celu utrzymania. Aby uzyskać więcej informacji na temat tego zachowania, zobacz Zmiany kompilacji języka Python.

System kompilacji usługi App Service o nazwie Oryx wykonuje następujące kroki podczas wdrażania aplikacji, jeśli ustawienie SCM_DO_BUILD_DURING_DEPLOYMENT aplikacji jest ustawione na 1:

  1. Uruchom niestandardowy skrypt przed budowaniem, jeśli krok ten jest określony w PRE_BUILD_COMMAND ustawieniu. (Skrypt może uruchamiać inne skrypty języka Python i Node.js, polecenia i npm oraz narzędzia oparte na węźle, takie jak Yarn, yarn install na przykład i yarn build.)

  2. Instalowanie zależności. System kompilacji sprawdza następujące pliki w katalogu głównym projektu:

    • requirements.txt: uruchamia polecenie pip install -r requirements.txt.
    • pyproject.toml z uv.lock: używa uv.
    • pyproject.toml z poetry.lock: używa poetry.
    • pyproject.toml: używa elementu poetry.
    • setup.py: uruchamia pip install ..

    Uwaga

    Jeśli pyproject.toml jest obecny, ale brakuje uv.lock, App Service domyślnie używa Poetry, nawet jeśli brakuje również poetry.lock. Aby użyć programu uv, należy uwzględnić uv.lock w ramach wdrożenia.

    Jeśli żaden z tych plików nie zostanie znaleziony, proces kompilacji zgłasza błąd "Nie można odnaleźć setup.py lub requirements.txt; nie uruchomiono pip install".

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

  4. Uruchom niestandardowy skrypt po kompilacji, jeśli ten krok zostanie określony w ustawieniu POST_BUILD_COMMAND . (Ponownie, skrypt może uruchamiać inne skrypty Pythona i Node.js, komendy pip i npm oraz narzędzia oparte na Node).

Domyślnie PRE_BUILD_COMMANDustawienia , POST_BUILD_COMMANDi DISABLE_COLLECTSTATIC są puste.

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

  • Aby uruchomić polecenia przed kompilacją, ustaw PRE_BUILD_COMMAND 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 folderu głównego projektu.

  • Aby uruchomić polecenia po kompilacji, ustaw konfigurację POST_BUILD_COMMAND tak, aby zawierała 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 powiązanych z folderem głównym projektu.

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

Aby uzyskać informacje na temat uzyskiwania dostępu do dzienników kompilacji i wdrażania, zobacz Access deployment logs (Uzyskiwanie dostępu do dzienników wdrażania).

Aby uzyskać więcej informacji na temat uruchamiania i kompilowania aplikacji języka Python w systemie Linux, zobacz How Oryx detects and builds Python apps (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 i POST_BUILD_COMMAND i są obsługiwane ze względów zgodności.

Ustawienie o nazwie SCM_DO_BUILD_DURING_DEPLOYMENT, jeśli zawiera true lub 1, wyzwala kompilację Oryx, która odbywa się podczas wdrażania. To ustawienie jest true używane podczas wdrażania za pomocą Git, Azure CLI az webapp up i programu Visual Studio Code.

Uwaga

Zawsze używaj ścieżek względnych we wszystkich skryptach przed kompilacją 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 zależności (taki jak requirements.txt, pyproject.toml lub setup.py) musi znajdować się w katalogu głównym repozytorium, jeśli usługa App Service ma automatycznie zainstalować 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 usługi App Service i aplikację internetową usługi App Service w celu hostowania aplikacji. Te zasoby można łatwo utworzyć, uruchamiając polecenie interfejsu wiersza polecenia az webapp upplatformy Azure . Możesz też utworzyć i wdrożyć zasoby, jak pokazano w samouczku platformy Flask, Django lub FastAPI z usługą PostgreSQL. Zastąp nazwy grupy zasobów, planu usługi App Service i aplikacji internetowej nazwami odpowiednimi dla aplikacji.

  4. Zmienne środowiskowe. Jeśli aplikacja wymaga dowolnych zmiennych środowiskowych, utwórz równoważne ustawienia aplikacji usługi App Service. Ustawienia usługi App Service pojawiają się w Twoim kodzie jako zmienne środowiskowe, jak opisano w temacie 'Dostęp do zmiennych środowiskowych'.

  5. Uruchamianie aplikacji. Zapoznaj się z sekcją Proces uruchamiania kontenera w dalszej części tego artykułu, aby uzyskać informacje o tym, jak usługa App Service próbuje uruchomić aplikację. Usługa App Service domyślnie używa serwera internetowego Gunicorn. Gunicorn musi mieć możliwość znalezienia obiektu aplikacji lub folderu wsgi.py . Jeśli chcesz, możesz dostosować polecenie uruchamiania.

  6. Ciągłe wdrażanie. Skonfiguruj ciągłe wdrażanie z funkcji GitHub Actions, Bitbucket lub Azure Repos zgodnie z opisem w artykule Ciągłe wdrażanie w usłudze Azure App Service. Możesz też skonfigurować ciągłe wdrażanie z lokalnego narzędzia Git zgodnie z opisem w artykule Lokalne wdrażanie usługi Git w usłudze Azure App Service.

  7. Akcje niestandardowe. Aby wykonać akcje w kontenerze usługi App Service, który hostuje aplikację, na przykład migracje baz danych Django, możesz nawiązać połączenie z kontenerem przy użyciu protokołu SSH. Aby zapoznać się z przykładem uruchamiania migracji baz danych Django, zobacz Samouczek: wdrażanie aplikacji internetowej Django za pomocą bazy danych PostgreSQL.

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

Ustawienia produkcyjne dla aplikacji Django

W przypadku środowiska produkcyjnego, takiego jak App Service, aplikacje Django powinny postępować zgodnie ze wskazówkami na liście kontrolnej wdrażania platformy Django.

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 usługi App Service zgodnie z opisem w temacie Uzyskiwanie dostępu do ustawień aplikacji jako zmiennych środowiskowych. Możesz też przechowywać wartość jako wpis tajny w usłudze Azure Key Vault.
DEBUG DEBUG Utwórz ustawienie w usłudze App Service z wartością 0 (false), a następnie załaduj wartość jako zmienną środowiskową. W środowisku deweloperów 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']. Usługa App Service automatycznie ustawia zmienną WEBSITE_HOSTNAME środowiskową na adres URL aplikacji.
DATABASES Zdefiniuj ustawienia w usłudze App Service dla połączenia z bazą danych i załaduj DATABASES je jako zmienne środowiskowe, aby wypełnić słownik. Możesz również przechowywać wartości (zwłaszcza nazwę użytkownika i hasło) jako wpisy tajne usługi 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 dotyczącymi zarządzania plikami statycznymi w dokumentacji Django.

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

  1. Rozważ użycie zmiennych środowiskowych (na potrzeby lokalnego programowania) i ustawień aplikacji (podczas wdrażania w chmurze), aby dynamicznie ustawiać zmienne I Django STATIC_URLSTATIC_ROOT . Na 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 dostosować według potrzeb w lokalnych i chmurowych środowiskach. Jeśli na przykład proces kompilacji dla plików statycznych umieszcza je w folderze o nazwie django-static, możesz ustawić wartość DJANGO_STATIC_URL na /django-static/ , aby uniknąć używania wartości domyślnej.

  2. Jeśli masz skrypt przed kompilacją, który generuje pliki statyczne w innym folderze, dołącz ten folder do zmiennej Django, aby proces Django STATICFILES_DIRScollectstatic je znaleźć. 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, jak pokazano poniżej:

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

    W tym kodzie FRONTEND_DIR służy do tworzenia ścieżki, w której jest uruchamiane narzędzie kompilacji, takie jak Yarn. Możesz ponownie użyć zmiennej środowiskowej i ustawienia aplikacji, jeśli chcesz.

  3. Dodaj whitenoise do pliku requirements.txt . WhiteNoise (whitenoise.evans.io) to pakiet języka Python, który ułatwia tworzenie produkcyjnej aplikacji Django do obsługi własnych plików statycznych. WhiteNoise obsługuje pliki znajdujące się w folderze określonym przez zmienną Django STATIC_ROOT .

  4. W pliku settings.py dodaj następujący wiersz dla funkcji WhiteNoise:

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Zmodyfikuj listy iMIDDLEWARE, INSTALLED_APPS 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 flask, zobacz przykładową aplikację platformy Flask w witrynie GitHub.

Aby dostarczać pliki statyczne bezpośrednio z trasy w aplikacji, możesz użyć metody send_from_directory.

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 usłudze App Service aplikacje języka Python są uruchamiane w kontenerze platformy Docker systemu Linux zdefiniowanym w repozytorium GitHub usługi App Service w języku Python. Konfiguracje obrazów można znaleźć w katalogach specyficznych dla wersji.

Ten kontener ma następujące cechy:

  • Aplikacje są uruchamiane przez serwer HTTP Gunicorn WSGI z dodatkowymi argumentami --bind=0.0.0.0 --timeout 600.

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

    • Aby chronić aplikację internetową przed przypadkowymi lub celowymi atakami DDOS, gunicorn jest uruchamiany za zwrotnym serwerem proxy Nginx, zgodnie z opisem w temacie Wdrażanie serwera Gunicorn.

  • 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, pyproject.toml lub setup.py w katalogu głównym projektu, które określają twoje bezpośrednie zależności. Następnie usługa App Service automatycznie instaluje te zależności podczas wdrażania projektu.

    Plik zależności musi znajdować się w katalogu głównym projektu lub nie zostaną zainstalowane zależności. Jeśli ten plik nie znajduje się w katalogu głównym, proces kompilacji zgłasza błąd "Nie można odnaleźć setup.py lub requirements.txt; Nie uruchomiono instalacji narzędzia". Jeśli wystąpi ten błąd, sprawdź lokalizację pliku wymagań.

  • Usługa App Service automatycznie definiuje zmienną środowiskową o nazwie WEBSITE_HOSTNAME , która zawiera adres URL aplikacji internetowej, na przykład msdocs-hello-world.azurewebsites.net. Definiuje również element WEBSITE_SITE_NAME, który zawiera nazwę aplikacji, na przykład msdocs-hello-world.

  • Narzędzie npm i Node.js są instalowane w kontenerze, dzięki czemu można 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 niestandardowej komendy startowej, jeśli jest dostępna.
  2. Sprawdź istnienie aplikacji Django i uruchom dla niej aplikację Gunicorn, jeśli zostanie wykryta.
  3. Sprawdź istnienie aplikacji Flask i uruchom dla niej aplikację Gunicorn, jeśli zostanie wykryta.
  4. Jeśli nie została znaleziona żadna inna aplikacja, uruchom domyślną aplikację wbudowaną 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 aplikację 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 startowym, użyj niestandardowej komendy uruchamiania, zastąp nazwą folderu zawierającego <module> i dodaj argument , jeżeli 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 platformy Flask usługa App Service wyszukuje plik o nazwie application.py lub app.py i uruchamia aplikację 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. Jeśli chcesz podać dodatkowe argumenty do Gunicorn, użyj niestandardowego polecenia uruchamiania.

Zachowanie domyślne

Jeśli usługa App Service nie znajdzie polecenia niestandardowego, aplikacji Django lub aplikacji Platformy Flask, uruchamia domyślną aplikację tylko do odczytu znajdującą się w folderze opt/defaultsite i pokazanym na poniższej ilustracji.

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

Zrzut ekranu przedstawiający domyślną stronę internetową usługi App Service w systemie Linux.

Dostosowywanie polecenia uruchamiania

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

Wszystkie polecenia muszą używać ścieżek powiązanych z folderem głównym projektu.

Aby określić polecenie uruchamiania lub plik polecenia:

  • Portal Azure. W obszarze Ustawienia w lewym okienku strony aplikacji wybierz pozycję Konfiguracja, a następnie wybierz pozycję Ustawienia ogólne. W polu Polecenie uruchamiania wprowadź 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> pełnym tekstem swojego polecenia startowego lub nazwą pliku polecenia startowego.

Usługa 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 lub plik uruchamiania jest wolny od błędów i czy plik polecenia uruchamiania jest wdrożony w usłudze App Service wraz z kodem aplikacji. Możesz również sprawdzić dzienniki diagnostyczne , aby uzyskać więcej informacji. Możesz również sprawdzić stronę Diagnozowanie i rozwiązywanie problemów aplikacji w witrynie Azure Portal.

Przykładowe polecenia uruchamiania

  • Dodano argumenty Gunicorn: Poniższy przykład dodaje --workers=4 argument 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 that contains 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 gunicornu). Jeśli używasz reguł skalowania automatycznego 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 gunicornu.

  • Włącz rejestrowanie produkcyjne dla Django: dodaj argumenty --access-logfile '-' 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 dzienników App Service.

    Aby uzyskać więcej informacji, zobacz Rejestrowanie Gunicorn.

  • Niestandardowy moduł główny platformy Flask: domyślnie usługa 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ę platformy Flask, której głównym modułem jest hello.py , a obiekt aplikacji Flask w tym pliku nosi nazwę myapp, jest to polecenie:

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

    Jeśli moduł główny znajduje się w podfolderze, takim jak witryna internetowa, 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 za pośrednictwem standardowego wzorca os.environ .

Jeśli na przykład utworzysz 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 usłudze App Service kończenie żądań PROTOKOŁU TLS/SSL odbywa się w modułach równoważenia obciążenia sieciowego, więc wszystkie żądania HTTPS docierają do aplikacji jako niezaszyfrowane żądania HTTP. Jeśli logika aplikacji musi sprawdzić, czy żądania użytkownika są szyfrowane, sprawdź X-Forwarded-Proto nagłówek:

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

Popularne struktury internetowe umożliwiają dostęp X-Forwarded-* do informacji w standardowym wzorcu aplikacji. Na przykład w usłudze Django można użyć SECURE_PROXY_SSL_HEADER do skonfigurowania narzędzia Django do używania nagłówka X-Forwarded-Proto .

Uzyskiwanie dostępu do dzienników diagnostycznych

Dostęp do dzienników konsoli generowanych z poziomu kontenera można uzyskać.

Aby włączyć rejestrowanie kontenerów, uruchom następujące polecenie:

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

Zastąp wartości <app-name> i <resource-group-name> nazwami odpowiednimi dla swojej 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 dzienniki konsoli nie są wyświetlane natychmiast, sprawdź ponownie w ciągu 30 sekund.

Aby zatrzymać przesyłanie strumieniowe dzienników w dowolnym momencie, użyj skrótu klawiaturowego Ctrl+C.

Aby uzyskać dostęp do dzienników w witrynie Azure Portal, wybierz pozycję Monitorowanie>strumienia dziennika w okienku po lewej stronie aplikacji.

Uzyskiwanie dostępu do dzienników wdrażania

Podczas wdrażania kodu usługa App Service wykonuje opisany wcześniej proces kompilacji 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 czynności:

  1. Na stronie witryny Azure Portal aplikacji internetowej wybierz pozycję Centrum wdrażania> w okienku 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 pliku zależności i błędy w skryptach przed kompilacją lub po kompilacji, są wyświetlane w tych dziennikach. Błędy są również wyświetlane, jeśli plik zależności nie zostanie znaleziony w folderze głównym projektu.

Otwieranie sesji SSH w przeglądarce

Jeśli chcesz otworzyć bezpośrednią sesję SSH z kontenerem, aplikacja powinna być uruchomiona.

Użyj polecenia az webapp ssh .

Jeśli nie jesteś uwierzytelniony, musisz uwierzytelnić się w ramach subskrypcji platformy Azure, aby nawiązać połączenie. Po uwierzytelnieniu zostanie wyświetlona powłoka w przeglądarce, w której można uruchamiać polecenia wewnątrz kontenera.

Połączenie SSH

Uwaga

Wszelkie zmiany wprowadzone poza /home katalogiem są przechowywane w samym kontenerze i nie są utrwalane poza ponownym uruchomieniem aplikacji.

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

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 zobaczysz 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 uzyskać informacje na temat badania możliwych problemów.

Ponowne zapisywanie adresów URL

Podczas wdrażania aplikacji języka Python w usłudze App Service dla systemu Linux może być konieczne obsługiwanie ponownego zapisywania adresów URL w aplikacji. Ta metoda jest szczególnie przydatna do zapewnienia, że określone wzorce adresów URL są przekierowywane do poprawnych punktów końcowych bez polegania na konfiguracjach zewnętrznego serwera internetowego. W przypadku aplikacji platformy Flask można użyć procesorów adresów URL i niestandardowego oprogramowania pośredniczącego, aby to osiągnąć. W aplikacjach Django dyspozytor adresu URL umożliwia efektywne zarządzanie ponownym zapisywaniem adresów URL.

Rozwiązywanie problemów

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

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

Następnie sprawdź zarówno dzienniki wdrażania , jak i dzienniki aplikacji pod kątem wszelkich komunikatów o błędach. Te dzienniki często identyfikują określone problemy, które mogą uniemożliwić wdrażanie aplikacji lub uruchamianie aplikacji. Na przykład kompilacja może zakończyć się niepowodzeniem, jeśli plik zależności nie znajduje się w folderze głównym projektu.

Poniższe sekcje zawierają wskazówki dotyczące konkretnych problemów.

Aplikacja nie jest wyświetlana

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

    • Uruchom ponownie aplikację, zaczekaj 20 sekund, a następnie ponownie sprawdź aplikację.

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

      1. Utwórz ustawienie aplikacji o nazwie SCM_DO_BUILD_DURING_DEPLOYMENT z 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 usługi App Service w witrynie Azure Portal.
      2. Przejrzyj proces wdrażania, sprawdź dzienniki wdrażania, popraw wszelkie błędy i ponownie wdróż aplikację.

    • Jeśli pliki istnieją, usługa App Service nie mogła zidentyfikować pliku uruchamiania. Upewnij się, że aplikacja jest ustrukturyzowana zgodnie z oczekiwaniami usługi 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 usługi App Service. Oznacza to, że usługa App Service uruchomiła serwer Gunicorn, ale sama aplikacja nie została uruchomiona. Ten warunek może wskazywać, że argumenty Gunicorn są nieprawidłowe lub że w kodzie aplikacji występuje błąd.

    • Odśwież przeglądarkę, zwłaszcza jeśli używasz najniższych warstw cenowych w planie usługi App Service. Uruchomienie aplikacji może potrwać dłużej, jeśli na przykład korzystasz z warstw bezpłatnych, a po odświeżeniu przeglądarki stanie się responsywna.

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

    • Sprawdź strumień dziennika aplikacji pod kątem komunikatów o błędach. Dzienniki pokażą wszelkie błędy w kodzie aplikacji.

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

  • Strumień dziennika pokazuje: "Nie można odnaleźć setup.py ani requirements.txt; Nie uruchomiono polecenia pip install." Proces kompilacji Oryx nie może odnaleźć pliku requirements.txt, pyproject.toml lub setup.py.

    • Połącz się z kontenerem aplikacji internetowej za pośrednictwem protokołu SSH i sprawdź, czy plik zależności jest poprawnie nazwany i istnieje bezpośrednio w folderze site/wwwroot. Jeśli plik nie istnieje, upewnij się, że plik istnieje w repozytorium i jest uwzględniony we wdrożeniu. Jeśli istnieje 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 usłudze Oryx 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 wymusza zainstalowanie pakietów za każdym razem, gdy wdrażasz je w usłudze 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 z aplikacją 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 usługa Django jest domyślnie skonfigurowana, zamiast używać bazy danych w chmurze, takiej jak Azure Database for PostgreSQL.

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 przy użyciu 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 po wpisie: ze względów bezpieczeństwa sesja SSH przechowuje hasło ukryte podczas wpisywania. Znaki są jednak rejestrowane, więc wpisz hasło jak zwykle i wybierz Enter po zakończeniu.

  • Polecenia w sesji SSH wydają się być odcięte: Edytor może nie zawijać poleceń w wiersze, ale mimo to powinny działać bez problemu.

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

  • Zostanie wyświetlony komunikat "Wymagane jest krytyczne połączenie SSL": 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.

Powiązana zawartość

  • Last updated on