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

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

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:

Webauftritt mit Fehlermeldung 502.5

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:

  1. Aufruf der SCM – Konsole unter dotnetbern.scm.azurewebsites.net
  2. Wechseln auf die Debug console CMD über das obere Menü
  3. In der Verzeichnisübersicht unter site/wwwroot wechseln und die web.config-Datei bearbeiten
  4. Aktivieren des stdout-Log 
    Aktivierung von stdoutEnabled auf true
  5. 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.

Das Bild zeigt einen Protokollauszug mit dem Hinweis, dass auf Azure die aktuelle ASP.NET Core Version 2.2.6 nicht zur Verfügung steht und ein Downgrade notwendig ist.

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:

  1. Im Azure Portal zu prüfen, ob eine Extension aktiviert werden kann
  2. 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.

Bild zeigt die Ergänzung der gerade beschriebenen Argumente in der Build Pipeline im Task dotnet publish

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:

Mehr Dateien mit self-contained application erreicht ein Eintragslimit im localStorage

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:

  • Mit F12 die Entwicklertools öffnen
  • Tab Local Storage öffnen
  • Key/Value (maxViewItems = 600) eintragen
    Anpassung der maxViewItems ist auf jeden Client nötig, welcher mit der Debug console arbeitet

Mit dieser Anpassung ist die Fehlermeldung behoben und die web.config über die Debug console erreichbar.

Was für Erfahrungen, Tipps und Tricks hast du mit Azure gesammelt?

Dein Feedback interessiert mich!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Fill out this field
Fill out this field
Bitte gib eine gültige E-Mail-Adresse ein.

Menü