Freigeben über

Funktionsweise von WebJobs in Azure App Service

Mit Azure WebJobs können Sie Hintergrundaufgaben innerhalb Ihrer App Service-App ausführen, ohne dass eine separate Infrastruktur erforderlich ist. Diese Aufgaben werden vom Kudu-Modul, dem integrierten App Service-Bereitstellungs- und Laufzeitverwaltungsdienst ermittelt und verwaltet. Kudu behandelt webJob-Ausführung, Dateisystemzugriff, Diagnose und Protokollsammlung hinter den Kulissen.

In diesem Artikel wird erläutert, wie WebJobs ermittelt werden, wie die Laufzeit entscheidet, was ausgeführt werden soll, und wie Sie das Verhalten mithilfe der optionalen settings.job Datei konfigurieren können.

Plattformspezifische Hinweise

WebJobs unterstützen eine Vielzahl von Skript- und ausführbaren Formaten, je nach App Service-Hostingumgebung. Die Dateitypen, die Sie ausführen können – und die verfügbaren Laufzeiten – variieren geringfügig, je nachdem, ob Sie Windows-Code, Linux-Code oder benutzerdefinierte Container verwenden. Im Allgemeinen sind integrierte Laufzeiten für allgemeine Skriptsprachen verfügbar, und zusätzliche Dateitypen werden unterstützt, wenn sie mit der Sprachlaufzeit Ihrer App oder Ihres Containers übereinstimmen.

Unterstützte Dateitypen für Skripts oder Programme

Folgende Dateitypen werden unterstützt:

  • Verwenden von Windows cmd: .cmd, .bat, .exe
  • Verwenden von PowerShell: .ps1
  • Verwenden von Bash: .sh
  • Verwenden von Node.js: .js
  • Verwenden von Java: .jar

Die für die Ausführung dieser Dateitypen erforderlichen Laufzeiten sind bereits auf der Web-App-Instanz installiert.

Von Bedeutung

WebJobs, die fortlaufend, geplant oder ereignisgesteuert sind, können nicht mehr ausgeführt werden, wenn die Web-App, die sie hostet, im Leerlauf ist. Web-Apps können nach 20 Minuten Inaktivität in den Ruhezustand wechseln, und nur direkte Anfragen an die App setzen diesen Leerlauftimer zurück. Aktionen wie das Anzeigen des Portals oder das Zugreifen auf die Kudu-Tools halten die App nicht aktiv. Um sicherzustellen, dass WebJobs zuverlässig ausgeführt werden, aktivieren Sie die Einstellung "Immer aktivieren" im Konfigurationsbereich Ihres App-Diensts. Diese Einstellung ist nur in den Tarifen "Basic", "Standard" und "Premium" verfügbar.

Aufgabenentdeckung und Ordnerstruktur

WebJobs werden im site/wwwroot/App_Data/jobs/ Ordner Ihrer App Service-App gespeichert. Es gibt zwei Unterordner:

  • continuous/: Bei lang andauernden Aufträgen, die automatisch gestartet und kontinuierlich ausgeführt werden.
  • triggered/: Für Aufträge, die bei Bedarf oder in einem Zeitplan ausgeführt werden.

Jeder Job hat einen eigenen Unterordner im entsprechenden Typordner, der nach dem WebJob benannt ist. Beispiel:

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

Innerhalb des Auftragsordners sucht das Kudu-Modul nach einer auszuführenden Datei. Diese Datei kann ein Skript oder eine ausführbare Datei sein.

Erkennung des Einstiegspunkts

Die WebJobs-Laufzeit verwendet eine Datei namens run.* (z. B. run.py, run.sh oder run.js) als expliziten Einstiegspunkt für einen Job. Diese Datei teilt der Plattform mit, welches Skript oder welche Binärdatei zuerst ausgeführt werden soll, um ein konsistentes und vorhersagbares Verhalten in allen Umgebungen sicherzustellen.

Der Dateiname muss genau run.* sein, damit er automatisch erkannt wird. Dateien wie start.sh oder job.py werden ignoriert, es sei denn, manuell ausgelöst. Wenn keine run.* Datei gefunden wird, versucht die Plattform, einen Fallbackeinstiegspunkt zu erkennen, indem die erste unterstützte Datei basierend auf der Sprachplattform des WebJob ausgewählt wird. Beispiel:

  • Ein Python-WebJob mit mehreren .py-Dateien (z. B. file1.py, file2.py) führt die erste .py-Datei aus, die es im Archiv findet.
  • Ein Node.js WebJob sucht nach der ersten .js Datei.
  • Ein bashbasierter WebJob sucht nach dem ersten .sh Skript.

Dieses Fallbackverhalten kann zu unvorhersehbarer Ausführung führen, wenn mehrere Skriptdateien vorhanden sind , insbesondere in Projekten mit mehreren Dateien, daher empfiehlt es sich, eine run.* Datei einzuschließen, um den Einstiegspunkt explizit zu definieren.

Bei Linux-basierten WebJobs müssen .sh-Skripts einen Shebang (#!) enthalten und als ausführbar gekennzeichnet sein.

WebJob-Konfiguration mit „settings.job“

Sie können das Verhalten eines WebJobs mithilfe einer optionalen settings.job-Datei im JSON-Format anpassen, die im Stammordner des Jobs platziert wird. Diese Datei unterstützt mehrere Eigenschaften:

Eigentum BESCHREIBUNG
schedule (Zeichenfolge) Ein CRON-Ausdruck, der zum Planen eines ausgelösten Auftrags verwendet wird Beispiel: "0 */15 * * * *". Gilt nur für ausgelöste Aufträge.
is_singleton (Boolescher Wert) Stellt sicher, dass auf allen skalierten Instanzen nur eine Instanz des Auftrags ausgeführt wird Standard: true für fortlaufende Aufträge, false für ausgelöste/bedarfsgestuerte Aufträge
stopping_wait_time (Zahl, Sekunden) Karenzzeit (Standard 5s), die dem Skript zugewiesen wird, bevor es beendet wird, wenn der WebJob beendet wird (z. B. während des Seitentauschs oder Neustarts).
shutdownGraceTimeLimit (Zahl, Sekunden) Maximale Zeit (Standard 0s, d. h. keine Beschränkung), die für das gesamte Herunterfahren des WebJob-Prozesses angegeben wird, einschließlich des stopping_wait_time, bevor er erzwungen beendet wird.
run_mode (Zeichenfolge) Werte: continuous, scheduled, on_demand. Überschreibt die Auftragstyperkennung basierend auf dem Ordner

Hinweis

stopping_wait_time gilt speziell für die Karenzzeit des ausgeführten Skripts, während shutdownGraceTimeLimit das Gesamtzeitlimit für das Herunterfahren des Prozesses definiert wird. Detailliertes Verhalten finden Sie in der Kudu-Dokumentation .

Beispiel

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

Protokollierung und Diagnose

WebJob-Protokolle werden vom Kudu-Modul behandelt und stehen unter dem App_Data/jobs/<type>/<jobname> Ordner zur Verfügung. Darüber hinaus können Protokolle im Azure-Portal angezeigt oder über den SCM (Kudu)-Endpunkt aufgerufen werden:

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

Für erweiterte Überwachungs- und Abfragefunktionen sollten Sie die Integration in Application Insights in Betracht ziehen.

Ausgelöste WebJobs enthalten einen vollständigen Verlauf der Ausführungen. Fortlaufende WebJobs-Streamprotokolle in Echtzeit

Tipps zur Problembehandlung

  • WebJob wird nicht gestartet: Suchen Sie nach einer fehlenden oder falsch benannten run.* Datei. Stellen Sie sicher, dass sie sich im richtigen Auftragsordner (triggered oder continuous) befindet.
  • Berechtigungsfehler (Linux): Stellen Sie sicher, dass das Skript über Ausführungsberechtigungen verfügt (chmod +x run.sh) und einen gültigen Shebang enthält (z. B. #!/bin/bash).
  • Auftrag nicht ordnungsgemäß beendet: Verwenden Sie settings.job zum Definieren von stopping_wait_time und ggf. shutdownGraceTimeLimit.
  • Geplanter Auftrag wird nicht ausgeführt: Überprüfen Sie, ob der CRON-Ausdruck in settings.job korrekt ist und der App Service-Plan, falls erforderlich, "Always On" aktiviert hat.
  • Kudu-Protokolle überprüfen: Untersuchen Sie die detaillierten Ausführungsprotokolle und Bereitstellungsprotokolle, die in der Kudu-Konsole (https://<your-app>.scm.azurewebsites.net/) unter Tools > WebJobs und potenziell Protokolldatenstrom verfügbar sind.

Nächste Schritte