Udostępnij za pośrednictwem


Jak działa WebJobs w usłudze Azure App Service

Usługa Azure WebJobs umożliwia uruchamianie zadań w tle w aplikacji usługi App Service bez konieczności oddzielnej infrastruktury. Te zadania są wykrywane i zarządzane przez silnik Kudu, wbudowaną usługę wdrażania i zarządzania środowiskiem uruchomieniowym w ramach App Service. Kudu obsługuje wykonywanie zadań WebJob, dostęp do systemu plików, diagnostykę oraz zbieranie dzienników w tle.

W tym artykule wyjaśniono, jak są odnajdywane zadania WebJob, jak środowisko uruchomieniowe decyduje o tym, co należy wykonać, i jak można skonfigurować zachowanie przy użyciu opcjonalnego settings.job pliku.

Uwagi specyficzne dla platformy

Zadania WebJobs obsługują różne formaty skryptów i plików wykonywalnych w zależności od środowiska hostingu aplikacji App Service. Typy plików, które można uruchamiać — i dostępne środowiska uruchomieniowe — różnią się nieznacznie w zależności od tego, czy używasz kodu systemu Windows, kodu systemu Linux czy kontenerów niestandardowych. Ogólnie rzecz biorąc, wbudowane środowiska uruchomieniowe są dostępne dla typowych języków skryptów, a dodatkowe typy plików są obsługiwane w przypadku dopasowania środowiska uruchomieniowego języka aplikacji lub kontenera.

Obsługiwane typy plików dla skryptów lub programów

Następujące typy plików są obsługiwane:

  • Przy użyciu narzędzia cmd systemu Windows: .cmd, .bat, .exe
  • Korzystanie z programu PowerShell: .ps1
  • Korzystanie z powłoki Bash: .sh
  • Korzystanie z Node.js: .js
  • Korzystanie z języka Java: .jar

Środowiska uruchomieniowe niezbędne do uruchamiania tych typów plików są już zainstalowane w instancji aplikacji webowej.

Ważne

Zadania WebJob, które są ciągłe, zaplanowane lub sterowane zdarzeniami, mogą przestać działać, jeśli aplikacja internetowa hostująca je stanie się bezczynna. Aplikacje internetowe mogą zakończyć działanie po 20 minutach braku aktywności, a tylko bezpośrednie żądania do aplikacji resetują ten czasomierz bezczynności. Działania takie jak przeglądanie portalu lub uzyskiwanie dostępu do narzędzi Kudu nie utrzymują aplikacji aktywnej. Aby zapewnić niezawodne uruchamianie zadań WebJobs, włącz ustawienie Zawsze włączone w sekcji konfiguracji usługi App Service. To ustawienie jest dostępne tylko w warstwach cenowych Podstawowa, Standardowa i Premium.

Odnajdywanie zadań i struktura folderów

Zadania WebJobs są przechowywane w site/wwwroot/App_Data/jobs/ folderze Twojej aplikacji w usłudze App Service. Istnieją dwa podfoldery:

  • continuous/: w przypadku długotrwałych zadań, które są uruchamiane automatycznie i działają w sposób ciągły.
  • triggered/: w przypadku zadań uruchamianych na żądanie lub zgodnie z harmonogramem.

Każde zadanie ma własny podfolder w odpowiadającym typowi folderze, nazwany po zadaniu WebJob. Przykład:

App_Data/jobs/triggered/myjob/
App_Data/jobs/continuous/myjob/

W folderze zadania silnik Kudu szuka pliku, który ma zostać wykonany. Ten plik może być skryptem lub plikiem wykonywalnym.

Wykrywanie punktu wejścia

Środowisko uruchomieniowe zadań WebJob używa pliku o nazwie run.* (na przykład run.py, run.shlub run.js) jako jawnego punktu wejścia dla zadania. Ten plik informuje platformę, który skrypt lub plik binarny ma zostać wykonany jako pierwszy, zapewniając spójne i przewidywalne zachowanie we wszystkich środowiskach.

Nazwa pliku musi być dokładnie run.*, aby została wykryta automatycznie. Pliki takie jak start.sh lub job.py zostaną zignorowane, chyba że zostaną uruchomione ręcznie. Jeśli nie znaleziono pliku run.*, platforma próbuje wykryć zapasowy punkt wejścia, wybierając pierwszy obsługiwany plik na podstawie platformy językowej WebJob. Przykład:

  • Usługa WebJob Python z wieloma .py plikami (na przykład file1.py, file2.py) wykona pierwszy .py plik, który znajdzie w archiwum.
  • Node.js WebJob szuka pierwszego pliku .js.
  • Usługa WebJob oparta na powłoce Bash szuka pierwszego .sh skryptu.

To zachowanie rezerwowe może prowadzić do nieprzewidywalnego wykonywania, gdy istnieje wiele plików skryptów — szczególnie w projektach wielo plikowych — dlatego zaleca się dołączenie run.* pliku do jawnego zdefiniowania punktu wejścia.

W przypadku zadań WebJobs działających na systemie Linux, skrypty muszą zawierać shebang (#!) i być oznaczone jako pliki wykonywalne.

Konfiguracja zadania „WebJob” z plikiem ustawień „settings.job”

Możesz dostosować zachowanie WebJob, używając opcjonalnego pliku settings.job (w formacie JSON) umieszczonego w folderze głównym zadania. Ten plik obsługuje kilka właściwości:

Majątek Opis
schedule (ciąg) Wyrażenie CRON używane do planowania wyzwalanego zadania. Przykład: "0 */15 * * * *". Dotyczy tylko wyzwolonych zadań.
is_singleton (bool) Gwarantuje, że tylko jedno wystąpienie zadania jest uruchamiane we wszystkich wystąpieniach skalowanych w poziomie. Ustawienie domyślne: true dla zadań ciągłych, false dla wyzwalanych/na żądanie.
stopping_wait_time (liczba, sekundy) Okres prolongaty (domyślnie 5s) nadany skryptowi przed jego zabiciem po zatrzymaniu zadania WebJob (na przykład podczas zamian witryny lub ponownego uruchamiania).
shutdownGraceTimeLimit (liczba, sekundy) Maksymalny czas (wartość domyślna 0, co oznacza brak limitu) dla całego zamknięcia procesu zadania WebJob, w tym parametru stopping_wait_time, przed wymuszonym zakończeniem.
run_mode (ciąg) Wartości: continuous, scheduled, on_demand. Zastępuje wykrywanie typu zadania na podstawie folderu.

Uwaga / Notatka

stopping_wait_time ma zastosowanie w szczególności do okresu prolongaty uruchomionego skryptu, podczas gdy shutdownGraceTimeLimit definiuje ogólny limit czasu zamknięcia procesu. Zapoznaj się z dokumentacją kudu , aby uzyskać szczegółowe informacje o zachowaniu.

Przykład

{
  "schedule": "0 0 * * * *", // Run once at the top of every hour
  "is_singleton": true,
  "stopping_wait_time": 60,
  "shutdownGraceTimeLimit": 120
}

Rejestrowanie i diagnostyka

Dzienniki zadań WebJob są obsługiwane przez silnik Kudu i są dostępne pod folderem App_Data/jobs/<type>/<jobname> . Ponadto dzienniki można wyświetlić w witrynie Azure Portal lub uzyskać do tego dostępu za pośrednictwem punktu końcowego SCM (Kudu):

https://<your-app>.scm.azurewebsites.net/api/triggeredwebjobs/<job>/history

Aby uzyskać bardziej zaawansowane funkcje monitorowania i wykonywania zapytań, rozważ integrację z usługą Application Insights.

Wyzwalane zadania WebJob obejmują pełną historię wykonań. WebJobs przesyłają strumieniowo dzienniki w czasie rzeczywistym.

Wskazówki dotyczące rozwiązywania problemów

  • Nie można uruchomić zadania WebJob: Sprawdź brakujący lub błędnie nazwany run.* plik. Upewnij się, że znajduje się on w prawidłowym folderze zadania (triggered lub continuous).
  • Błąd uprawnień (Linux): Upewnij się, że skrypt ma uprawnienia do wykonywania (chmod +x run.sh) i zawiera prawidłowy shebang (np. #!/bin/bash).
  • Zadanie nie jest zatrzymywane z pewnością: Użyj settings.job polecenia , aby zdefiniować stopping_wait_time i potencjalnie shutdownGraceTimeLimit.
  • Zaplanowane zadanie nie działa: Sprawdź, czy wyrażenie CRON w settings.job jest poprawne oraz czy Plan usługi App Service ma włączoną opcję "Always On," jeśli jest to konieczne.
  • Sprawdź dzienniki Kudu: Przeanalizuj szczegółowe dzienniki wykonania oraz dzienniki wdrażania dostępne w konsoli Kudu (https://<your-app>.scm.azurewebsites.net/) w sekcji Narzędzia > WebJobs, a także ewentualnie strumień dzienników.

Dalsze kroki