Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird erläutert, wie Azure App Service das Betriebssystem (OS) und die Runtimesoftware aktualisiert, wie Sie Versionsinformationen abrufen können und wie Sie manuell auf neue Versionen aktualisieren können.
App Service ist eine Platform-as-a-Service (PaaS), sodass Azure das Betriebssystem und den Anwendungsstapel für Sie verwaltet. Sie verwalten nur Ihre Anwendung und deren Daten. Wenn Sie mehr Kontrolle über das Betriebssystem und den Anwendungsstapel benötigen, können Sie Azure-VMs verwenden.
Es ist weiterhin hilfreich für Sie als App Service-Benutzer, die folgenden Informationen zu kennen:
- Wie und wann Betriebssystemupdates angewendet werden.
- Wie App Service anhand erheblicher und Zero-Day-Sicherheitsrisiken gepatcht wird.
- Wann unterstützte Language Runtimes aktualisiert, hinzugefügt oder veraltet sind.
- Wie man die Laufzeit-Patch-Aktualisierungszeit mit dem Platform Release Channel (Linux) steuert.
- Wie Sie herausfinden, welche Betriebssystem- und Runtimeversionen Ihre Apps ausführen.
Dieser Artikel macht den Prozess transparent und hilft Ihnen, auf sicherheitsrelevante Ankündigungen und Runtimeupdates auf dem Laufenden zu bleiben. Aus Sicherheitsgründen werden bestimmte Sicherheitsinformationen nicht veröffentlicht.
Wie und wann werden Betriebssystemupdates angewendet?
Azure verwaltet Betriebssystempatches sowohl für die physischen Server als auch für die Gast-VMs, die die App Service-Ressourcen ausführen. Beide Computerebenen werden monatlich zum monatlichen Patch-Dienstag-Zeitplan aktualisiert.
Diese Updates werden automatisch angewendet, während die Vereinbarung zum Servicelevel für hohe Verfügbarkeit für Azure-Dienste garantiert wird. Das Patchen des Azure App Service-Betriebssystems folgt SDP (Safe Deployment Practices) und einem Ansatz, der zuerst verfügbar ist. Die neuesten Patches werden so schnell wie möglich installiert, jedoch kann es vorkommen, dass die Installation von Betriebssystempatches zeitweise verlangsamt oder angehalten wird, um Auswirkungen auf Anwendungen und Ausfälle zu vermeiden.
Ausführliche Informationen zur Anwendung von Updates finden Sie unter Demystifying the magic behind App Service OS updates (Entmystifizierung des hinter App Service-Betriebssystemupdates steckenden Zaubers).
Wie geht Azure mit erheblichen Sicherheitsrisiken um?
Wenn hochprioritäre Probleme wie Zero-Day-Schwachstellen sofortige Patches erfordern, behandelt Azure die Updates von Fall zu Fall. Wenn Sie mit kritischen Azure-Sicherheitsankündigungen auf dem laufenden bleiben möchten, lesen Sie den Azure Security-Blog.
Wann werden unterstützte Language Runtimes aktualisiert, hinzugefügt, oder wann sind sie veraltet?
Neue stabile Haupt-, Neben- oder Patchversionen der Language Runtimes werden in regelmäßigen Abständen den App Service-Instanzen hinzugefügt. Einige Updates überschreiben die vorhandene Installation, während andere parallel zu vorhandenen Versionen installiert werden.
Eine überschreibende Installation bedeutet, dass Ihre App automatisch auf der aktualisierten Runtime ausgeführt wird. Eine parallele Installation bedeutet, dass Sie Ihre App manuell migrieren müssen, um eine neue Version der Runtime zu nutzen. Weitere Informationen finden Sie in den folgenden Abschnitten.
Hinweis
Diese Informationen gelten für Language Runtimes, die in einer App Service-App integriert sind. Eine benutzerdefinierte Runtime, die Sie in App Service hochladen, bleibt z.B. unverändert, solange Sie sie nicht manuell aktualisieren.
Neue Patchupdates
Patchupdates für .NET-, PHP-, Java SDK- oder Tomcat-Version werden automatisch durch Überschreiben der vorhandenen Installation mit der aktuellen Version angewendet. Node.js-Patchupdates werden parallel zu den vorhandenen Versionen installiert (ähnlich wie Haupt- und Nebenversionen). Neue Python-Patchversionen können manuell über Websiteerweiterungen parallel zu integrierten Python-Installationen installiert werden.
Neue Haupt- und Nebenversionen
Neue Haupt- oder Nebenversionen werden parallel zu vorhandenen Versionen installiert. Sie können Ihre App manuell auf die neue Version aktualisieren.
Wenn Sie die Runtimeversion in einer Konfigurationsdatei wie web.config oder package.json konfiguriert haben, müssen Sie ein Upgrade mit derselben Methode durchführen. Bei Verwendung einer App Service-Einstellung zum Konfigurieren der Runtimeversion können Sie sie im Azure-Portal oder durch Ausführen eines Azure CLI-Befehls in der Azure Cloud Shell ändern.
Die folgenden Beispiele zeigen Azure CLI-Konfigurationsbefehle für verschiedene unterstützte Sprachlaufzeiten. Sie ersetzen <appname> die <groupname> Namen Ihrer App und deren Ressourcengruppe.
az webapp config set --net-framework-version v4.7 --resource-group <groupname> --name <appname>
az webapp config set --php-version 7.0 --resource-group <groupname> --name <appname>
az webapp config appsettings set --settings WEBSITE_NODE_DEFAULT_VERSION=~24 --resource-group <groupname> --name <appname>
az webapp config set --python-version 3.14 --resource-group <groupname> --name <appname>
az webapp config set --java-version 1.8 --java-container Tomcat --java-container-version 9.0 --resource-group <groupname> --name <appname>
Hinweis
In diesem Node.js-Beispiel wird die empfohlene Tildensyntax verwendet, um die neueste verfügbare Version der Node.js 24-Runtime für App Service als Ziel zu verwenden.
Kontrolle die Laufzeit-Patch-Aktualisierungszeit mit Platform Release Channel
Hinweis
Die Funktion Platform Release Channel ist nur für Linux App Service verfügbar.
Standardmäßig wendet das System automatisch Laufzeit-Patch-Updates an, sobald diese verfügbar sind. Für den Linux App Service ermöglicht die Platform Release Channel-Einstellung , den Rhythmus zu steuern, in dem Laufzeit-Patch-Updates an Ihre App geliefert werden. Diese Steuerung ist nützlich, wenn man mehr Vorhersehbarkeit und Zeit für Validierungen möchte, bevor ein neuer Laufzeit-Patch in der Produktion übernommen wird.
Verfügbare Kanäle
Wählen Sie aus drei Kanälen:
| Channel | Description | Empfohlen für |
|---|---|---|
| Latest | Liefert Laufzeit-Patch-Updates, sobald sie verfügbar sind. | Apps, bei denen sofortiger Zugriff auf die neuesten Sicherheitsupdates erforderlich ist. Wird für Produktionsarbeitslasten allgemein nicht empfohlen. |
| Standard | Updates folgen dem Standard-Release-Rhythmus und balancieren Währung und Stabilität aus. Dieser Kanal ist der Standard. | Die meisten Produktions-Apps. |
| Erweiterte | Liegt in der Regel eine Version hinter Standard zurück, was den Workloads mehr Zeit für die Validierung gibt, bevor ein neuer Laufzeit-Patch eingeführt wird. | Produktionsworkloads, die zusätzliche Validierungszeit benötigen, bevor ein neuer Laufzeit-Patch übernommen wird. |
Wenn ein neuer Laufzeit-Patch veröffentlicht wird, durchläuft er die Kanäle in der Reihenfolge: Latest → Standard → Extended. Dieser Fluss bedeutet, dass ein Update, das sofort auf Latest verfügbar ist, nach weiterer Validierung Standard erreicht und dann nach zusätzlicher Validierung erweitert wird.
Zum Beispiel könnte für .NET 10 derselbe Zeitpunkt so aussehen:
| Channel | .NET-Version |
|---|---|
| Neueste | 10.0.7 |
| Standard | 10.0.4 |
| Erweitert | 10.0.2 |
Tip
Wenn deine App strenge Stabilitätsanforderungen hat, nutze den erweiterten Kanal , um die Häufigkeit automatischer Laufzeit-Patch-Updates zu reduzieren. Wenn deine App so schnell wie möglich die neuesten Sicherheitslösungen benötigt, nutze Latest.
Konfigurieren Sie den Plattform-Release-Kanal
- Wechseln Sie im Azure-Portal zu Ihrer App Service-App.
- Im linken Menü wählen Sie Einstellungen Stapeln.
- Unter Platform Release Channel wählen Sie den gewünschten Kanal: Neues, Standard oder Erweitertes.
- Klicken Sie auf Speichern.
Weitere Informationen zu dieser Funktion finden Sie in der Platform Release Channel Blogankündigung.
Wie kann ich den Updatestatus von Betriebssystem und Runtime auf meinen Instanzen abfragen?
Mit der Kudu-Konsole können Sie die Betriebssystemversion und Runtimeversionen Ihrer App Service-Instanzen abfragen. Für wichtige Betriebssysteminformationen ist der Zugriff gesperrt. Weitere Informationen finden Sie unter Betriebssystemfunktionen für Azure App Service.
In der folgenden Tabelle wird gezeigt, wie Sie Kudu- oder Cloud Shell-Befehle verwenden, um die Windows- und Language Runtimeversionen zu finden, die Ihre Apps ausführen. Ersetzen Sie <appname> und <groupname> durch Ihre App- und Ressourcengruppennamen.
| Information | Ort |
|---|---|
| Windows-Version | Siehe https://<appname>.scm.azurewebsites.net/Env#sysinfo. |
| .NET-Version | Führen Sie bei https://<appname>.scm.azurewebsites.net/DebugConsole in der Eingabeaufforderung den folgenden Befehl aus: reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full". |
| .NET Core-Version | Führen Sie bei https://<appname>.scm.azurewebsites.net/DebugConsoledotnet --version aus. |
| PHP-Version | Führen Sie bei https://<appname>.scm.azurewebsites.net/DebugConsolephp --version aus. |
| Standardmäßige Node.js-Version | Führen Sie in der Cloud Shell-Instanz folgenden Befehl aus: az webapp config appsettings list --resource-group <groupname> --name <appname> --query "[?name=='WEBSITE_NODE_DEFAULT_VERSION']". |
| Python-Version | Führen Sie bei https://<appname>.scm.azurewebsites.net/DebugConsolepython --version aus. |
| Java-Version | Führen Sie bei https://<appname>.scm.azurewebsites.net/DebugConsolejava -version aus. |
Hinweis
Der Zugriff auf den Registrierungsspeicherort HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages, an dem Informationen zu Sicherheitsbulletins gespeichert sind, ist gesperrt.