Solucionar problemas con tu Node.js sin servidor no tiene por qué ser doloroso

Bienvenidos a la conferencia DevOpsJS, y gracias por asistir a mi charla, solucionar los problemas de tu nodo sin servidor no tiene por qué ser doloroso. Mi nombre es Jeff Hopper y soy el líder técnico de crecimiento en Rollbar. Comencé a trabajar en Rollbar en septiembre pasado. Puedes encontrarme en GitHub como udimos para aquellos que estén familiarizados con el área de Los Ángeles, California, y las personas que viven aquí saben. Soy una persona bastante rara que en realidad nació y creció en Los Ángeles, específicamente en Santa Mónica, y todavía vivo en Los Ángeles en una parte diferente de la ciudad. Así que tengo un problema. Me gusta incluir algo de estilo cuando doy un 'looks good to me' en un PR. Y desafortunadamente, el sitio al que solía recurrir para estos GIFs específicos, LGTM.io, cerró hace un par de años. Tengo otro problema. Soy perezoso. No es solo que no quiera buscar un buen GIF de LGTM para un PR en GitHub. También necesito responder en Slack al compañero de equipo que solicitó mi revisión. Quiero hacerlo todo al mismo tiempo. Así que se me ocurrió una solución, un bot de Slack llamado LGTM ReplyGIF que combina uno de mis sitios favoritos de GIFs, replygif.net con un comando de Slack para publicar en mi nombre. Lo construí en nodeJS y lo implementé en AWS Lambda donde llamará a la API de replygif, seleccionará un GIF al azar, publicará un comentario en el PR de GitHub y responderá al canal de Slack con un mensaje para nuestro solicitante. Suena genial, ¿verdad? Entonces, ¿qué salió mal? Vamos a solucionar eso juntos, ¿de acuerdo? Lo primero que debemos recordar sobre las funciones de Lambda es que eso es exactamente lo que son,

Desde la consola web de AWS, llegamos al área de lambda, encontramos nuestra función, y echamos un vistazo a esta pestaña de monitoreo aquí. Ahora, nos dará una lista de invocaciones recientes, y nos dirá en qué flujo de registro se encuentran. Estas invocaciones recientes son interesantes, pero realmente no nos están dando información de solución de problemas. Así que vamos a verificar nuestros registros de CloudWatch directamente. Ahora, cargando aquí, cargando en los flujos, nuestro más reciente está en la parte superior. Vamos a echar un vistazo allí y vemos que nuestra única invocación está ocurriendo en este flujo y vemos este mensaje de error aquí. N no es una función. Así que eso es bueno. Encontramos el error. Tomemos

Una cosa que podríamos hacer es echar un vistazo a la vista como texto, que expande todos estos elementos. Entonces, vemos un historial de ejecución largo. Ahora, es posible que al solucionar problemas de eventos de registro en CloudWatch desde lambdas, se mezclen cuando tienes múltiples invocaciones ocurriendo al mismo tiempo. Entonces, lo que resulta útil es tomar este ID de solicitud aquí. Lo vemos en todos los registros y ponerlo en la búsqueda. Volvamos y busquemos en todos nuestros flujos. Asegúrate de poner comillas porque los guiones funcionarán como negadores para los términos de búsqueda si no lo haces. Ahora vemos la misma vista donde todo está relacionado con nuestra única invocación.

Veamos nuestra implementación. Está lista. Así que probemos nuevamente nuestro Slack bot. Ahora busquemos un registro que nos pueda dar la información que necesitamos. Esperemos que sea el más reciente. Sí, vemos aquí, Fetch línea 69, columna 3. Ahora nuestros mapas de origen están funcionando. Podemos echar un vistazo al código aquí y dice que este signo de dólar no es una función. Y eso es porque debería haber llamado a Cheerio.load en lugar de solo Cheerio como una función. Así que corregimos eso, volvemos a implementar. Y lo intentamos nuevamente. Aún obteniendo un error de envío fallido. Entonces, ¿qué está saliendo mal aquí? Estamos extrayendo imágenes de la página de ReplyGIF. Pero ahora veamos la solución de problemas en registros agregados. Como revisar cada registro individualmente no es muy eficiente, hay algunas capacidades de filtrado que vimos. Pero si estás acostumbrado a herramientas de agregación de registros como ElasticSearch y ya tienes tus otras aplicaciones conectadas a ella, querrás usar eso también para la agregación de registros de tu función Lambda.

Entonces, la diferencia es que en tus aplicaciones que se ejecutan en un servidor, o dentro de un contenedor, tienes algún proceso que está leyendo un archivo de registro que estás escribiendo, o está leyendo desde stdout y lo está enviando a Elasticsearch.

En el entorno serverless, no tienes ningún proceso en ejecución continua que haga esto por ti, porque nuestras funciones serverless son efímeras por design.

Por lo tanto, necesitamos enviar nuestros registros de CloudWatch que ya recibimos instrumentados por AWS a nuestro clúster de Elasticsearch.

Una forma de hacer esto, si ya estás utilizando Elasticsearch como servicio en AWS, es ir a tu grupo de registros. Selecciona el grupo de registros en el que estás interesado y crea un filtro de suscripción a Elasticsearch.

Aquí seleccionas a qué clúster quieres que vaya. Puedes elegir un formato de registro. En este caso, estamos usando Lambda. Pero puedes hacerlo con cualquier cosa en la que estés registrando. Y puedes analizarlo. Así que vamos a seguir con Lambda. Nos da este patrón de filtro incorporado. Debes darle un nombre. Y puedes probarlo con tus datos de registro existentes. Así que vamos a probar el patrón. Sí, vemos que están llegando. Así que comienza a transmitir. Ya lo he habilitado. Y lo que se crea para ti es otra función Lambda que lee tus registros de CloudWatch y es la encargada de enviarlos a Elasticsearch.

Echemos un vistazo aquí. Y lo bueno de tener Elasticsearch en lugar de solo CloudWatch es que tenemos estas columnas agradables que podemos agregar y que nos ayudan a enfocarnos en lo que está sucediendo. Así que echemos un vistazo aquí. Veamos. Muy bien. Así que tenemos un error de credenciales incorrectas que aparece en nuestra última solicitud. Podemos echar un vistazo y tenemos las propiedades disponibles que esperas en Elasticsearch. Así que las ha tomado todas por ti. Y vemos el token, no puedes ver cuál es el token. Pero noté que está bien. Cuando desarrollamos localmente,

Y hemos subido nuestros mapas de origen. Ahora vemos 'no encontrado'. Obtenemos una respuesta cuando hacemos la llamada a GitHub para el problema 88. Bueno, eso no existe. Ese es el PR incorrecto. Pero no lo estamos manejando correctamente. Así que vamos a corregir ese código. Y antes de hacerlo, vamos a resolver esto. Ahora volvemos. Intentémoslo de nuevo. Todavía falló. Así que esta vez vamos a verificar primero el PR. Asegurémonos de que esté ahí. Y si no lo está, le decimos a la persona que no existe o que el bot no tiene acceso. Ahora, si hacemos un PR que sí existe, funciona. Entonces, en nuestra nueva solución, obtenemos el PR de GitHub, proporcionamos una respuesta amigable en Slack que solo es visible para el solicitante, y también obtenemos el autor y nos aseguramos de mencionarlo en nuestro comentario. Así que reciben una alerta de GitHub y Slack, para que no puedan escapar de nuestro LGTM. Si quieres aprender más sobre la plataforma de mejora continua de código de Rollbar, asegúrate de revisar el taller de David, con una deep dive y un tutorial que te permitirá configurarlo y ejecutarlo por tu cuenta. Puedes encontrar el código fuente del bot de Slack LGTM ReplyGIF en GitHub aquí. Y muchas gracias por asistir. Si te registras para obtener una cuenta nueva en Rollbar, utiliza esta URL con el código promocional de Git Nation para obtener un mes completo gratis más allá del período de prueba normal.

Hola Jeff, gracias por unirte. Hola Mitten, ¿cómo estás? Muy bien, gracias. Entonces, hiciste la pregunta, ¿dónde despliegas tu aplicación? Y el 65% ha respondido a un PaaS y solo el 25% a un clúster de Kubernetes y el 19% a máquinas virtuales. ¿Cómo te sientes al respecto? ¿Es algo que esperabas? En su mayor parte, en realidad me sorprende que el clúster de Kubernetes no sea más alto, pero para mí tiene sentido. Sí, parece que tenemos una audiencia bastante moderna, así que gracias por eso.

Ahora tenemos tiempo para responder las preguntas de nuestra audiencia, y vamos a dar a nuestra audiencia tiempo para presentar sus preguntas, por supuesto. Lo que me intrigaba es que trabajas en Rollbar y normalmente cuando veo personas de una empresa de productos, una empresa de productos para desarrolladores, hablarán de su producto, pero tú no lo hiciste. Entonces, ¿por qué decidiste ir completamente fuera de la empresa? Bueno, no quería ir completamente fuera. Si te fijas, progresé hacia Rollbar y mi objetivo era mostrar las diferentes formas en que las personas que no están familiarizadas con el sin servidor pueden involucrarse y cómo podrían solucionar problemas. Y luego algunas personas pueden haber estado trabajando en sin servidor, pero no sabían que podían enviar sus registros a una búsqueda agregada. Y al mismo tiempo, eventualmente te gustaría estar en un sistema como Rollbar porque simplemente facilita todo. Incluyes el SDK, funciona directamente desde Lambda, y no necesitas configurar todas estas otras cosas, y tienes la capacidad de ir directamente a tu panel de control, puedes configurar alertas. Y tenemos una masterclass próximamente, que profundiza mucho con David Waller. Y para aquellos interesados en aprender más sobre Rollbar, es un gran lugar para ir y configurar tu cuenta, configurar tu código con Rollbar.

Sí, es una herramienta muy útil. La he utilizado en varias empresas en el pasado, así que gracias por tu trabajo. Una pregunta de la audiencia. Si le preguntas a 10 personas qué es el sin servidor, básicamente obtendrás 10 respuestas diferentes. Entonces, si te preguntara a ti, que eres la persona número 11, ¿qué dirías que es el sin servidor? Yo caracterizaría el sin servidor básicamente por la restricción de que estás entregando código a cualquier proveedor de sin servidor y no estás administrando ninguna de las infraestructuras involucradas. Lo estás desplegando en este sistema y él decide dónde, cuándo y cómo ejecutar tu código. Y todas las formas en que se hace esto están abstraídas para ti, por lo que no sabes si se está ejecutando en una VM, en un contenedor, en metal desnudo, para ti no importa. Simplemente estás entregando una función y luego, cuando tienes un punto final, llamas a ese punto final, tu función se ejecutará. Esa es la garantía que proporcionan. Entonces, para mí, como desarrollador front-end, digamos que quiero iniciar una startup o un proyecto personal, ¿siempre recomendarías ir sin servidor, para que puedas centrarte en hacer lo que sabes, que es el front-end? Y sé que esto a veces es una barrera para las personas que conozco como desarrolladores front-end para hacer más que desarrollar algo en su máquina local y sacarlo de su host local. Creo que abordarlo desde un punto de vista sin servidor, al principio, es en realidad un enfoque muy bueno, porque una de las cosas que te obliga a hacer es centrarte y pensar en estar más encapsulado en tus llamadas de API. Y siempre puedes tomar un montón de funciones sin servidor y combinarlas en una API si quieres ejecutar eso en un servidor. Es más difícil hacerlo al revés. Entonces, comenzar con sin servidor en realidad reduce tu tiempo de inicio, o sea, disminuye tu tiempo de inicio, te lleva a una unidad desplegable más rápido y, al mismo tiempo, siempre puedes moverte en una dirección más consolidada. Y también te proporciona algunas mejores prácticas en torno a la programación y el enfoque en las entradas y salidas y en cómo debería verse tu API en cada punto final individual. Genial.

Entonces, recibimos un comentario de Hannah que dice: Me encanta el Slackbot. Tal vez lo mencionaste y me lo perdí en la charla, pero ¿podemos usarlo o debemos alojarlo nosotros mismos o básicamente utilizar una plataforma de alojamiento sin servidor para eso, por supuesto, pero ¿podemos usar el bot ya? Necesita algunas piezas más. Sabes, hice trampa en eso. Autoricé el Slackbot. Autoricé la aplicación a través de GitHub y siempre está publicando como yo. Así que hay algunas correcciones y está disponible. Así que si alguien quiere bifurcarlo y mejorarlo y hacerlo más aplicable, estaré encantado de hacerlo. Estoy dispuesto a aceptar cualquier solicitud de extracción si alguien quiere agregar código y enviar una solicitud de extracción y tal vez podamos construir esto juntos como una comunidad. Creo que sería divertido tenerlo. Ciertamente estaba resolviendo mi propio problema con esto. Bueno, así es como se hacen 9 de cada 10 inventos, supongo, ¿verdad? Así es. Identifica un problema y es posible que seas el único en el mundo que tenga este problema, pero al menos tienes a alguien que se identifica con este problema, Anna. Entonces, Anna, ¿puedes ayudar a Jeff, verdad? Se aceptan las solicitudes de extracción. Absolutamente.

Muy bien, así que no tenemos más preguntas de nuestra audiencia. Oh, Anna dice, muy bien. Gracias. Gracias, Anna. ¿Puedes mencionar tu cuenta de GitHub una vez más para que Anna pueda encontrarte? Sí, es E-U-D-A-I-M-O-S. Muy bien, Anna, espero que hayas entendido eso y Jeff estará en su sala de conferencias justo después de esto. Jeff, quiero agradecerte por tu tiempo y espero verte en persona algún día pronto. Eso sería genial. Que tengas un buen día. Adiós. Gracias, hombre. Adiós.