HTTP Error 500.30 ANCM In-Process Start Failure en Microsoft Azure

Introducción

Los videos, entradas de mi blog, al igual que las charlas que doy, corresponden a casos reales y prácticos que me han ocurrido y que me gusta compartir, y éste es el caso que comparto en esta ocasión.

En esta entrada voy a contar un caso particular o experiencia personal que nos ha ocurrido en la empresa y que comparto por si a alguien le pasa y le sirve para resolver el problema.

Situación

Tenemos una Web API empresarial compleja que ataca a su vez a varios servicios.
El desarrollo requiere de bastantes archivos de configuración que entre otras cosas y pese a su complejidad, aporta igualmente cierta flexibilidad al propio desarrollo.

Otra de las tareas internas para esa Web API y que hemos abordado hace meses, era desplegar la Web API migrada de ASP.NET Core 2.2 a ASP.NET Core 3.1.

Dentro de la organización, seguimos ciertas pautas y buenas prácticas.
Desde Azure DevOps llevamos todo el proceso ALM incluyendo el despliegue a Azure dentro de un slot de STAGING, para acometer posteriormente el swap cuando esté listo.

Todo muy controlado y parametrizado.
Tener todo procedimentado y organizado es fundamental para no estar luego corriendo de un lado a otro gritando ¡fuego!.
Sin embargo, y esto es algo que todos sabemos, siempre pueden ocurrir «peros», problemas o imprevistos, algunos no procedimentados o no tan controlados.
Redefinir y refinar los procedimientos es algo natural, y a nadie le debe extrañar ni preocupar.

Voy a exponer aquí una forma de resolver uno de esos problemas (que no deberían darse) y cómo saber qué está pasando.

El error 500.30

Tras desplegar sobre el slot de STAGING, pasamos los tests correspondientes en el entorno que nos permita determinar que está ready to go.

Los elementos estáticos de la Web API funcionan y responden correctamente.

Pero la Web API en sí, nos devuelve un genérico error 500.30.

Indudablemente, todo en el proceso general de desarrollo en local, compilación en Azure DevOps y testings han pasado, y el despliegue en el slot se ha realizado correctamente, pero a la hora de acceder a la Web API, recibimos este error.

Evaluación

Es indudable que algo no es correcto y seguramente nos hayamos olvidado de incluir algo.

Revisamos todo el entorno (métricas, configuraciones, etc.), y nos da la «sensación» de que todo está en orden (en realidad no lo estaba, pero eso lo veremos al final).

La primera acción que acometemos es ir a Application Insights y ver si allí tenemos alguna pista, pero la verdad es que ¡no hay nada!.
Bien… vamos un poco a ciegas entonces para determinar el problema.

Aunque sirve de poco, una de las cosas que todo informático que se precie piensa primero es apagar y encender, así que hacemos eso con la máquina de Azure, pero eso no resuelve nada.

Ya un poco más en serio, abrimos la consola y comprobamos las versiones de .NET Core (recordemos que una de las cosas que hemos realizado es la migración de .NET Core 2.2 a .NET Core 3.1).
Lanzamos el comando dotnet –info y observamos que los runtimes de .NET Core son correctos.

El que tenga cierta experiencia con .NET Core sabe (o debería saberlo) que la mayoría de los problemas en el arranque de una aplicación web y en este caso de una Web API suele estar en Startup.cs.
Pero aunque sepamos esto, como digo, la Web API de la que hablo es compleja y todo parece estar en orden.

El caso es que seguimos con el error y la investigación continua.

Por suerte, tenemos muchísimas más posibilidades de chequeo, y llegados a este punto vamos con una que es «lógica» pero que a veces podemos pasar por alto.

Lanzar la Web API «manualmente»

Este es el punto clave (al menos en este caso que comparto).

¿Cómo lanzamos una aplicación de .NET Core manualmente?.

Pues exactamente ese es el quiz de cómo (en este caso) hemos detectado el problema real que teníamos.

En nuestro caso estamos ante una aplicación Web (una Web API), y tiene una dependencia con el Framework que va a ser resuelta automáticamente.

Anteriormente veíamos que el framework de Azure parecía estar bien configurado e instalado (y así es).

Así que la forma de tratar de saber cuál es el problema que tenemos es acceder en Azure a nuestro App Service, y abrir allí una consola.

Dentro de la consola nos situaremos dentro de la ruta en la que tenemos nuestra Web API (normalmente D:\home\site\wwwroot\).

Y allí, escribiremos el comando:

dotnet .\ASSEMBLY.dll

(siendo ASSEMBLY el nombre del ensamblado de nuestra aplicación web o Web API).

Haremos lo mismo que haríamos a mano en nuestro ordenador local.

En mi caso, aparece información de log dentro de la pantalla que nos da la pista del problema.

Aunque dentro de nuestra Web API tenemos un proceso que se encarga de chequear la configuración de toda la Web API para evitar precisamente el despiste de un parámetro, había habido un pequeño error humano en un cambio dentro de la configuración de Producción que no había sido replicado correctamente, y que desencadenaba un error en el Startup.cs del entorno.

Aunque éste es un caso muy concreto, lo importante en esta ocasión bajo mi punto de vista, es que dentro de todas las herramientas que Azure tiene para determinar problemas en nuestras aplicaciones, hay acciones como estas, que no están documentadas y que nos pueden salvar de muchas horas de investigación.
De hecho, he tardado en escribir todo esto más que lo que ha sido encontrar el problema, pero a veces en la vida vale más saber qué hacer que el problema en sí.

Espero que esta entrada te ayude en el caso de que te encuentres con algún problema en el futuro.

No obstante, hay dentro de la documentación de Microsoft un interesante artículo que comparto, y que tiene que ver con las diferentes formas que podemos tener dentro de Azure para encontrar un problema.
Precisamente la que comparto, sale en ese documento.
Puedes acceder a esta información en este enlace

Happy Coding!