Azure App Service – 502.5 ANCM Out-of-Process Startup Failure

vor 5 Jahren

Wo du sicher bist, setze Fragezeichen.
Wieslaw Brudzinski

Die Cloud ist zwischenzeitlich überall ein Thema. Viele positive Charaktereigenschaften werden hier zugeschrieben. Eine davon, dass diese immer auf den aktuellen Stand der Software ist. Ein schönes Marketing-Instrument.

Was war passiert?

Die Seite www.dnug-bern.ch bekam von uns ein Update von ASP.NET Core auf die Version 2.2.6. Auf zwei Entwicklungsrechnern und der Build-Pipeline lief die Anpassung erfolgreich durch. Unser Auftritt lief mit der aktuellen Version jedoch nicht mehr im Azure App Service.

Folgende Meldung begrüsste uns:

In einer Teamviewer-Session machten wir uns daran, den Fehler gemeinsam zu analysieren. Nach einem Moment des Rätselratens aktivierten wir das stdlog, damit wir nähere Details zum Problem bekamen.

Zum Aktivieren führten wir folgende Schritte aus:

Aufruf der SCM – Konsole unter dotnetbern.scm.azurewebsites.net
Wechseln auf die Debug console CMD über das obere Menü
In der Verzeichnisübersicht unter site/wwwroot wechseln und die web.config-Datei bearbeiten
Aktivieren des stdout-Log
Web.config speichern und Seite neu aufrufen

Im Ordner site/wwwroot/logs werden ab diesen Zeitpunkt aussagekräftige Fehlermeldungen protokolliert. In unserem Szenario war es die Meldung, dass die Version 2.2.6 für unseren App Service nicht zur Verfügung steht.

Unsere erste Idee war ein Downgrade der ASP.NET Core Version auf 2.2.5, entschieden uns dann aber das Release vor dem Versionsupdate wieder zu publizieren. Das ging in Azure DevOps mit einem Klick.

Unser Ziel war eigentlich die aktuelle Version einzuspielen. Ein Downgrade auf 2.2.5 war für uns aus dem Blickwinkel der Qualitätskriterien wie zum Beispiel Sicherheit nicht die favorisierte Lösungsvariante.

Das Einspielen des vorherigen Releases verschaffte uns mehr Zeit, weitere Lösungsvarianten zu suchen. Es nahm uns die Hektik, die sonst unnötige Fehler produziert hätte, während der Webauftritt nicht zur Verfügung stand.

Zur Lösung unseres Problems hatten wir zwei Varianten:

Im Azure Portal zu prüfen, ob eine Extension aktiviert werden kann
Die ASP.NET Core Version mit dem Auftritt ausliefern (Self-contained application)

Zu Punkt 1, dass verging uns sehr schnell. Im Portal kann man viel Zeit mit suchen als mit lösen verbringen. Zudem würde es für dieses Szenario unseren Wartungsaufwand erhöhen und sogar verteilen. Bisher dachten wir, diesen Aufwand würde uns der Azure App Service, als externe Abhängigkeit, vollständig abnehmen.

Wenn wir künftig die ASP.NET Core Version mit ausliefern, benötigen wir zwar etwas mehr Platz, die Wartung bleibt jedoch an einem zentralen Ort und weitere Szenarien sind denkbar.

Was ist dazu nötig?

In unserem Fall mussten wir die Build-Pipeline anpassen. Der Publish-Task benötigte weitere Argumente. Zum einen –self-contained der die nötige .NET Core Version packt und für die Runtime die entsprechende Angabe –runtime win-x64, da unser App Service auf Windows läuft.

Das 502.5 Problem konnten wir so lösen, ohne ein Downgrade von ASP.NET Core auf 2.2.5 vornehmen zu müssen.

Unser nächster Schritt wird die Überführung unserer Build-Pipeline in YAML sein. Dann liegt diese auch in unserem Repository und es existiert ein Backup der Pipeline.

Zu unseren Erfahrungen gehört mittlerweile auch ein Gewitter, dass ein Datencenter lahmlegte und wir in diesen Zeitraum keine Releases ausliefern konnten. Da jüngst auch ein Cloud-Anbieter unwiderruflich Daten einiger seiner Kunden löschte, haben wir so alles zusammen.

Zum Schluss, als .NET Core in unserer Anwendung eingebettet war, erschien in der Debug console/CMD folgende Fehlermeldung:

Dies benötigt eine Anpassung des Clients, da die web.config so nicht erreichbar ist. Das stdout-Log ist sehr hilfreich bei Problemen und es wird sicherlich nicht das letzte mal sein, dass wir es zur Analyse benötigen.

Dazu ist am Beispiel des Chrome-Browsers folgende Anpassung notwendig: