Udostępnij za pośrednictwem

Konfigurowanie aplikacji języka Python dla systemu Linux dla usługi aplikacja systemu Azure Service

  • Artykuł

W tym artykule opisano sposób uruchamiania aplikacji języka Python przez usługę aplikacja systemu Azure, 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 .

Aparat wdrażania usługi App Service automatycznie aktywuje środowisko wirtualne i uruchamia pip install -r requirements.txt je podczas wdrażania repozytorium Git lub pakietu zip z 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 usłudze App Service. Jeśli nigdy nie używasz usługi aplikacja systemu Azure Service, najpierw postępuj zgodnie z samouczkiem Szybki start dla języka Python i językiem Python 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 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 usłudze aplikacja systemu Azure 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 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 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 i npm oraz narzędzia oparte na węźle, takie jak yarn, yarn install na przykład i yarn build.)

  2. Uruchom program 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 uruchomiono instalacji narzędzia".

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

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

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 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 ustawieniami i POST_BUILD_COMMAND są obsługiwane w starszych celach.

Ustawienie o nazwie SCM_DO_BUILD_DURING_DEPLOYMENT, jeśli zawiera true lub 1, wyzwala kompilację Oryx odbywa się podczas wdrażania. To ustawienie jest prawdziwe podczas wdrażania przy użyciu narzędzia git, polecenia interfejsu wiersza polecenia az webapp upplatformy Azure 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.

    • 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 zrobić łatwo, uruchamiając polecenie interfejsu wiersza polecenia az webapp upplatformy Azure . Możesz też utworzyć i wdrożyć zasoby, jak pokazano w artykule Samouczek: wdrażanie aplikacji internetowej w języku Python (Django lub Flask) przy użyciu bazy danych PostgreSQL. Zastąp nazwy grupy zasobów, planu usługi App Service i aplikacji internetowej, aby być bardziej odpowiednie dla aplikacji.

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

  5. Uruchamianie aplikacji: przejrzyj 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 . W razie potrzeby możesz dostosować polecenie uruchamiania.

  6. Ciągłe wdrażanie: skonfiguruj ciągłe wdrażanie z usługi GitHub Actions, Bitbucket lub Azure Repos zgodnie z opisem w artykule Ciągłe wdrażanie w usłudze aplikacja systemu Azure Service. Możesz też skonfigurować ciągłe wdrażanie z lokalnego narzędzia Git zgodnie z opisem w artykule Lokalne wdrażanie git w usłudze aplikacja systemu Azure 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 usługa aplikacja systemu Azure 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 usługi 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 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 platformy Django.

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

  1. Rozważ użycie zmiennych środowiskowych (programowania lokalnego) i ustawień aplikacji (podczas wdrażania w chmurze) w celu dynamicznego ustawiania zmiennych I STATIC_ROOT DjangoSTATIC_URL. 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 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ć wartość 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, dołącz ten folder do zmiennej Django, aby proces Django STATICFILES_DIRS collectstatic 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 w następujący sposób:

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

    Tutaj , FRONTEND_DIRaby skompilować ś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 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 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 dla funkcji Whitenoise:

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Zmodyfikuj również listy iINSTALLED_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 flask, zobacz przykładową aplikację platformy 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 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 gunicorn można podać, dostosowując polecenie uruchamiania.

    • Aby chronić aplikację internetową przed przypadkowymi lub celowymi atakami DDOS, 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. Następnie usługa App Service automatycznie instaluje te zależności podczas wdrażania projektu.

    Plik requirements.txt musi 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 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 przy użyciu WEBSITE_HOSTNAME adresu URL aplikacji internetowej, takiej jak msdocs-hello-world.azurewebsites.net. Definiuje WEBSITE_SITE_NAME również nazwę aplikacji, na przykład msdocs-hello-world.

  • Narzędzie 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, który zawiera 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 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ą App Service dla systemu Linux.

Ponownie, jeśli spodziewasz się zobaczyć wdrożonej aplikacji zamiast domyślnej aplikacji, 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 polecenia uruchamiania. Plik polecenia uruchamiania może używać dowolnej wybranej nazwy, takiej jak startup.sh, startup.cmd, startup.txt itd.

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> ciąg pełnym tekstem polecenia uruchamiania lub nazwą pliku polecenia uruchamiania.

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 element do wiersza polecenia Gunicorn na potrzeby 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 Gunicorn FAQ

  • 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 usługi App Service.

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

  • 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ę 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 usłudze App Service kończenie żądań PROTOKOŁU TLS/SSL (wikipedia.org) 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

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

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, wpisz 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 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, będą wyświetlane w tych dziennikach. Błędy są również wyświetlane, jeśli plik wymagań nie jest dokładnie nazwany 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 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 aplikacja systemu Azure dla systemu Linux może być konieczne obsługa ponownego zapisywania adresów URL w 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 platformy Flask można użyć procesorów adresó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ę zgodną z oczekiwaniami usługi App Service dla platformy Django lub Flask, albo 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ż 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 ma strukturę zgodną z oczekiwaniami usługi App Service dla platformy Django lub Flask, albo użyj niestandardowego polecenia uruchamiania.

    • Sprawdź strumień dziennika aplikacji pod kątem 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 przedstawia komunikat "Nie można odnaleźć setup.py ani requirements.txt; Nie uruchomiono instalacji.": Proces kompilacji 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 nie istnieje, utwórz witrynę, aby plik istniał w repozytorium i został 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 wymusi zainstalowanie pakietów za każdym razem, gdy zostanie wdrożone 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 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 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 naciśnij 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 "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.

Więcej zasobów