Udostępnij za pośrednictwem

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.

Mechanizm wdrażania usługi App Service automatycznie aktywuje środowisko wirtualne i uruchamia pip install -r requirements.txt, gdy wdrażasz repozytorium Git lub pakiet zipz włączoną automatyzacją kompilacji.

Uwaga

Obecnie App Service wymaga umieszczenia requirements.txt w katalogu głównym projektu, nawet jeśli posiadasz pyproject.toml. Aby uzyskać zalecane podejścia, zobacz Generate requirements.txt z pliku pyproject.toml.

Ten przewodnik zawiera kluczowe pojęcia i instrukcje dla deweloperów języka Python, którzy korzystają z wbudowanego kontenera systemu Linux w usłudze App Service. Jeśli nigdy nie korzystałeś z usługi Azure App Service, najpierw wykonaj samouczek Szybki start dla Pythona z platformami Flask, Django lub FastAPI oraz z PostgreSQL.

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

  • W witrynie Azure portal użyj strony Ustawienia>Konfiguracja aplikacji zgodnie z opisem w 'Konfigurowanie aplikacji usługi App Service w witrynie Azure portal'.

  • Interfejs wiersza polecenia platformy Azure: masz dwie opcje.

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

  • Portal Azure: użyj karty Ustawienia ogólne na stronie Konfiguracja, jak opisano w Konfigurowanie ogólnych ustawień dla kontenerów 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> i <app-name> nazwami odpowiednimi dla twojej aplikacji internetowej.

    • Ustaw wersję języka Python za pomocą 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, które są obsługiwane w usłudze Azure App Service, za pomocą 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.

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

Nieaktualne środowiska uruchomieniowe są wycofywane przez organizację nadzorującą 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. Alternatywy wdrażania umożliwiają tworzenie zdeprecjonowanych środowisk uruchomieniowych, które zostały usunięte 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ść zostanie wdrożona do /tmp/<uid> i będzie obsługiwana z tej lokacji, a nie w obszarze /home/site/wwwroot. Ten katalog treści można uzyskać poprzez zmienną środowiskową APP_PATH. Wszelkie dodatkowe pliki utworzone w czasie wykonywania powinny być zapisywane w lokalizacji w obszarze /home lub przy użyciu funkcji Bring Your Own Storage w celu utrzymania. Więcej informacji na temat tego zachowania można znaleźć tutaj.

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 sam uruchamiać inne skrypty w językach Python i Node.js, polecenia pip i npm, oraz narzędzia oparte na Node.js, takie jak np. yarn, yarn install i yarn build.)

  2. Uruchom 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 uruchamianie pip install."

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

  4. Uruchom niestandardowy skrypt po kompilacją, jeśli ten krok jest 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 funkcji 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 do 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 względnych do folderu głównego projektu.

Aby zapoznać się z innymi ustawieniami, które dostosują automatyzację kompilacji, zobacz Konfiguracja Oryx.

Aby uzyskać dostęp 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).

Generuj requirements.txt na podstawie pliku pyproject.toml

Obecnie usługa App Service nie obsługuje pyproject.toml bezpośrednio. Jeśli używasz narzędzi takich jak Poetry lub uv, zalecane jest wygenerowanie zgodnego requirements.txt przed wdrożeniem w katalogu głównym projektu.

Korzystanie z poezji

Używanie Poetry z wtyczką eksportu:


poetry export -f requirements.txt --output requirements.txt --without-hashes

Korzystanie z uv

Przy użyciu uv:


uv export --format requirements-txt --no-hashes --output-file requirements.txt

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.

    • Aby automatycznie zainstalować niezbędne pakiety, plik requirements.txt musi znajdować się w katalogu głównym repozytorium usługi App Service.

  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 do hostowania aplikacji. Możesz to łatwo zrobić, uruchamiając polecenie Azure CLI az webapp up. 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 aplikacji i aplikacji internetowej, by były bardziej odpowiednie dla Twojej 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 dowiedzieć się, jak usługa App Service próbuje uruchomić aplikację. Usługa App Service domyślnie używa serwera internetowego Gunicorn, który 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 lokalnej usługi Git zgodnie z opisem w artykule Lokalne wdrażanie 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 za pośrednictwem protokołu SSH. Aby zapoznać się z przykładem uruchamiania migracji baz danych Django, zobacz 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 usłudze 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.

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 Access app settings as environment variables (Ustawienia aplikacji programu Access jako zmienne środowiskowe). 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 projektowym utwórz zmienną środowiskową DEBUG o 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 za pomocą 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 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 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 (do lokalnego programowania) i ustawień aplikacji (podczas wdrażania w chmurze) w celu dynamicznego ustawiania zmiennych Django STATIC_URL i STATIC_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ć 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 frontendu, a yarn wygeneruje folder build/static 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')]

    FRONTEND_DIR W tym miejscu 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 zgodnie z potrzebami.

  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 w szczególności 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 dla funkcji WhiteNoise:

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Zmodyfikuj również listy MIDDLEWARE i INSTALLED_APPS tak, 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 przy użyciu serwera HTTP Gunicorn WSGI przy użyciu dodatkowych argumentów --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 Wdrażanie 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 w katalogu głównym projektu, który określa bezpośrednie zależności. Następnie usługa App Service 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 budowania zgłasza błąd: "Nie można odnaleźć setup.py lub requirements.txt; nie uruchomiono polecenia pip install." Jeśli wystąpi ten błąd, sprawdź lokalizację pliku requirements.

  • 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. Również określa WEBSITE_SITE_NAME jako nazwę twojej aplikacji, na przykład msdocs-hello-world.

  • Narzędzia npm oraz Node.js są zainstalowane w kontenerze, aby można było uruchamiać narzędzia kompilacyjne oparte na Node.js, 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 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 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ć logowanie produkcji, dodaj parametry --access-logfile 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, startup.txtitd.

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

Aby określić polecenie uruchamiania lub plik polecenia:

  • Witryna 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> 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, a plik polecenia uruchamiania jest wdrażany w usłudze 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 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 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 gunicornu). Jeśli używasz reguł automatycznego skalowania do zwiększania i zmniejszania rozmiaru swojej aplikacji internetowej, powinieneś również dynamicznie ustawić liczbę pracowników Gunicorn za pomocą zmiennej środowiskowej NUM_CORES 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, polecenie jest następujące:

    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 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 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 o użyciu nagłówka X-Forwarded-Proto .

Uzyskiwanie dostępu do dzienników diagnostycznych

Można uzyskać dostęp do dzienników konsoli wygenerowanych wewnątrz kontenera.

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 <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ć strumieniowanie logów w dowolnym momencie, naciśnij Ctrl+C.

Aby uzyskać dostęp do dzienników za pośrednictwem witryny Azure Portal, wybierz pozycję Monitorowanie>strumienia dziennika w menu po lewej stronie aplikacji.

Uzyskiwanie dostępu do dzienników wdrażania

Podczas wdrażania kodu usługa 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 czynności:

  1. W witrynie Azure Portal dla 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 przed kompilacją lub po kompilacji, zostaną wyświetlone w tych dziennikach. Błędy są również wyświetlane, jeśli plik wymagań nie ma 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 z kontenerem, aplikacja powinna być uruchomiona.

Użyj polecenia az webapp ssh .

Jeśli nie masz jeszcze uwierzytelnienia, musisz uwierzytelnić się w subskrypcji platformy Azure, aby nawiązać połączenie. Po uwierzytelnieniu zobaczysz powłokę w przeglądarce, w której możesz uruchamiać polecenia wewnątrz swojego 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 zapoznać się z możliwymi problemami.

Ponowne zapisywanie adresów URL

Podczas wdrażania aplikacji języka Python w usłudze Azure App Service dla systemu Linux może być konieczne obsłużenie przepisywania adresów URL wewnątrz aplikacji. Jest to szczególnie przydatne w przypadku zapewnienia, że określone wzorce adresów URL są przekierowywane do poprawnych punktów końcowych bez polegania na zewnętrznych konfiguracjach serwera internetowego. W przypadku aplikacji Flask można użyć procesorów URL i niestandardowego oprogramowania pośredniczącego, aby to osiągnąć. W aplikacjach Django niezawodny 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. W witrynie Azure Portal dla 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 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 requirements.txt ma nieprawidłową nazwę pliku lub nie jest obecny 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 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 usługi App Service i sprawdzić, czy pliki istnieją w witrynie /wwwroot. Jeśli pliki nie istnieją, wykonaj następujące kroki:

      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 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ą, oznacza to, że usługa App Service nie mogła zidentyfikować określonego pliku startowego. Sprawdź, czy aplikacja ma strukturę oczekiwaną przez usługę 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, co oznacza, ż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 bezpłatnych poziomów, a po odświeżeniu przeglądarki staje się responsywna.

    • Sprawdź, czy aplikacja ma strukturę oczekiwaną przez usługę 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 wyświetla komunikat "Nie można odnaleźć setup.py ani requirements.txt; Nie uruchomiono polecenia pip install.": Proces budowania Oryx nie może odnaleźć pliku requirements.txt.

    • Połącz się z kontenerem aplikacji internetowej za pośrednictwem protokołu SSH i sprawdź, czy requirements.txt jest poprawnie nazwana i istnieje bezpośrednio w obszarze 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 sprawi, że Oryx zainstaluje twoje pakiety za każdym razem, gdy wdrożysz do 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 w zwykły sposób 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ść