Programas, procesos, scripts, hilos ¿qué son los Webjobs de Azure? ¿cómo podemos implementarlos? ¿cómo podemos desplegarlos? ¿qué opciones de configuración hay?

Si recordáis aquello que hablamos sobre la historia de Azure, recordaréis que al principio, solo había un sistema de «procesos» que se conocía (y se conoce) como roles. Había dos tipos, los web roles que tenían exposición a Internet para recibir peticiones web y los worker roles que eran esas tareas de background que necesitan casi todos los sistemas. Además, para tener el tan buen SLA que te da Microsoft de tres nueves y pico, necesitas (y necesitabas) tener dos instancias de cada rol que mantuvieras. Cuando tienes mucha carga es todo muy sensato, pero cuando aun no la tienes… tener 4 (o más) máquinas rulando y pagando por ellas no tiene mucho sentido. Para esos casos había que ser un poco creativo optimizando el uso de los roles y así reducir la factura al máximo mientras mantenías la flexibilidad y la posibilidad de escalar.

Cuando en Azure se lanzan los Websites, que ahora quedan englobados dentro de las Webapps, estaban pensados para montar sitios web de un modo fácil y económico, que se ajuste a cada caso. Pero con estos pasaba lo mismo que con los roles, que hacía falta realizar algunas tareas en background, y no tenía sentido montar máquinas sólo para redimensionar unas fotos o para cualquier tarea que no deba realizarse en el hilo de ejecución principal que tiene que devolver una respuesta. Para cubrir esta necesidad, manteniendo el espíritu de los Websites aparecen los Webjobs.

¿Y qué son? Los Webjobs son procesos que se ejecutan en las mismas instancias en las que está corriendo el servicio web. «Fisicamente» (en el disco duro) son un programa ejecutable compilado o no (un archivo de tipo .exe, .cmd, .bat, .sh, .php, .py o .js) y todas las librerías y demás archivos que necesite para funcionar.

Como veis puede ser cualquier programa que ya tengas hecho, pero si vas a hacer uno nuevo es recomendable usar las plantillas de Visual Studio y el JobHost que nos proporciona el SDK aprovechando los bindings que nos proporciona, aunque eso ya lo veremos otro día porque tiene miga. Tomes la opción que tomes, ten en cuenta que debería ser un programa que no requiera interacción con un usuario y que debe saber de donde coger la configuración, sus datos de entrada y sus datos de salida.

A la hora de desplegarlos -siempre pensando en un caso muy básico, si queremos crecer podríamos desplegarlos en un worker rol, pero esa ya es otra historia que tendrá que ser contada en otro momento- tenemos múltiples opciones, pero yo os voy a mencionar sólo tres que creo que son las más básicas y aun sin meternos en temas de integración continua, os darán la base necesaria para lanzaros al ruedo con cualquier opción:

• Puedes subirlo con Visual Studio, aunque hay opciones individuales, si despliegas el Website desde VS, este se fijará en el archivo Properties/webjobs-list.json del proyecto de la Webapp para ver que Webjobs debe desplegar. Para ver cómo tiene que configurar cada Webjob se fijará en el archivo Properties/webjob-publish-settings.json de cada uno -luego vemos como van las configuraciones-.
• Puedes subirlo a maneja, compilas el proyecto y metes todo el contenido de la carpeta Release en un zip y lo subes a través del portal. En el momento de subirlo te pedirá la configuración adecuada para echarlo a andar.
• Puedes subirlo mediante Git. Las Webapps de Azure tienen asociado un repositorio Git, y cuando haces push de tu código a ese repositorio es «Azure» el que se encarga de compilar y colocar cada cosa en su sitio. Para la configuración en este caso también se usa el archivo webjob-publish-settings.json con una excepción bastante importante -ahora, ahora-.

La configuración de los Webjobs es un poco… como decirlo… un pan con hostias lleno de excepciones. Sí, sé que no ha quedado muy fino, pero es la mejor manera que se me ocurre de explicarlo. No hablo de los settings y connection strings del programa, que van en el App.config y se sobrescriben con lo que se encuentra en el apartado Configuración de la Webapp dentro del portal de Azure. Eso es muy normal. El tema más delicado es el de como debe ejecutarse.

Los Webjobs pueden ser de dos tipos y medio. Pueden ser «Continuos» o «Triggered», pero hay un tercer tipo que es el «Triggered» camuflado como «Scheduled». El primero es el que está corriendo todo el rato, el segundo es el que se lanza a petición de algo/alguien y el tercero se lanza a petición de una programación temporal establecida.

Parece sencillo ¿verdad? Esta configuración se establece en el archivo webjob-publish-settings.json y si lo subes con el Visual Studio se pone sola. Ahora bien, los continuos no serán continuos si tu app está en el nivel Gratis o Compartido -no se si es la traducción adecuada para tier, pero seguro que me entendéis- y tampoco los disparados se dispararán en todos los casos, ya que en esos dos niveles las aplicaciones puede que se paren de ejecutar. Para garantizar que tienes tu aplicación levantada todo el rato tendrás que tenerla en el modo Básico, Standard o Premium -sí, hay un premium aunque no lo veas- y tendrás que tener activado el parámetro Always On. Independientemente de lo que pongas en el archivo en cuestión, si subes el Webjob a mano a través del portal lo que prevalecerá será la configuración que establezcas en ese momento. Si lo despliegas mediante Git (y pasa lo mismo con ftp y otras opciones) se establecerá la configuración adecuada si es una de los dos primeros tipos, pero no si es scheduled. En este caso puedes crear un archivo settings.job para poner una programación al estilo de cron, pero esa programación Kudu (que es el sistema que maneja todo en bambalinas) sólo la tendrá en cuenta y lanzará los trabajos si tu Webapp está en las capas Standard o Premium. Además si los servicios existían previamente porque los habías creado a mano por ejemplo, y haces un push con Git, no hace caso de lo que digan los archivos de configuración y tomará la configuración que se creó a mano… ¿a que ahora ya no es tan sencillo?

Tal vez cuando hablemos del JobHost hablemos un poco más de como se ejecutan las cosas y que hilos se levantan, pero por no complicar las cosas diremos que:

• Trabajos continuos: si es vital que funcionen siempre acuérdate de tener la aplicación corriendo al menos en el nivel básico y con el Always On activo.
• Trabajos disparados: no te preocupes en exceso de ellos, además supongo que serán cosas que corras muy puntualmente ¿o no?
• Trabajos programados: si vas a funcionar en Standard o Premium usa el settings.job y cuando tu sistema de integración continua despliegue todo funcionará. Si vas a estar por debajo de esos niveles, déjalos como triggered y crea inicialmente los trabajos a mano. Cuando se despliegue, esa configuración inicial se mantendrá. Puedes crearles antes de programarlos subiendo un zip con cualquier programa.

Con esto tenéis información más que de sobra para empezar a meterle mano a los Webjobs y para optimizar el uso de vuestras instancias corriendo en background esas tareas que hacen que el usuario tarde en obtener una respuesta. Preguntas, comentarios, críticas o lo que sea, pegad una voz.

Post By Javi López (27 Posts)

Arquitecto/desarrollador, creativo, buscador de nuevas soluciones y modelos de negocio, crítico constructivo y ex muchas cosas

Website: → JaviLopezG

Connect

Azure, Webapps, Webjobs