Video Summary and Transcription
Bienvenidos a la conferencia DevOpsJS donde Jeff Hopper presenta su bot de Slack llamado LGTM ReplyGIF para publicar GIFs en su nombre. Soluciona problemas con el código Node sin servidor, utiliza registros de CloudWatch y trazas de pila para depurar, y envía registros a Elasticsearch para su análisis. Jeff explora opciones de solución de problemas con Rollbar y discute recomendaciones de implementación sin servidor. Se invita a la audiencia a contribuir al proyecto del bot de Slack, y la sesión concluye con agradecimientos de Jeff.
1. Introducción a la solución de problemas de Node sin servidor
Bienvenidos a la conferencia DevOpsJS. Mi nombre es Jeff Hopper y soy el líder técnico de crecimiento en Rollbar. Tengo un problema. Me gusta incluir algo de estilo cuando doy un 'looks good to me' en un PR. 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. Se me ocurrió una solución, un bot de Slack llamado LGTM ReplyGIF que combina replygif.net con un comando de Slack para publicar en mi nombre. Vamos a solucionar eso juntos, ¿de acuerdo?
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,
2. Solución de problemas de Node sin servidor
Estoy importando algunas cosas, haciendo algunas cosas en el cuerpo y devolviendo una respuesta. El controlador es una función que recibe un evento y opcionalmente un contexto. Ejecutamos una pila local y encontramos un error 500 en la API de reply-gif. Cambiamos a hacer scraping del sitio web usando Cheerio. Después de probar localmente, publicamos el código en AWS y probamos nuestro SlackBot. Encontramos un error de fallo de envío y solucionamos el problema utilizando los registros de CloudWatch, donde encontramos el mensaje de error 'N no es una función' en la traza de la pila.
son solo funciones. Estoy importando algunas cosas, estoy haciendo algunas cosas aquí en el cuerpo, la lógica relacionada con mi función, y luego estoy devolviendo una respuesta. Pero al final, es un controlador que es una función, recibe un evento y opcionalmente un contexto. Así que puedo importarlo en mis pruebas. Puedo incluirlo, puedo requerirlo en el REPL de Node. O puedo ejecutar la pila local y escribir algunos comandos curl contra ella. Así que hagamos eso primero. Así que estoy ejecutando una pila local en el lado izquierdo. Y en el lado derecho, estamos llamando a nuestro comando curl. Nos damos cuenta de que obtenemos un error 500 y luego no estamos devolviendo ninguna respuesta. Resulta que los errores 500 provienen de la API de reply-gif, que en realidad no funciona, no se mantiene y devuelve un error 500 en cualquier solicitud a cualquiera de los puntos finales. Así que sabiendo que la API de reply-gif no funciona, pero vi que el sitio web sí lo hace, cambié a hacer scraping de la página con un paquete de Node llamado Cheerio que nos proporciona una API de jQuery para obtener las URL de las imágenes. Así que hemos probado localmente y las cosas parecen funcionar bien. Publicamos el código en AWS utilizando nuestro comando de implementación y luego probamos nuestro SlackBot. Así que vamos a intentarlo. Mi amigo Demo Slack me envió una solicitud a través de Slack para revisar su PR. Así que voy a decir que le di una revisión, decir lgtm. Recibo mis indicaciones para decirme cómo escribir el comando. Entonces, identifico el repositorio, identifico el PR, les doy un pequeño reconocimiento de la aplicación. Y obtenemos un error de fallo de envío, que es un error predeterminado de Slack cuando no sabe qué decir. Entonces, veamos cómo solucionamos esto en la cloud utilizando CloudWatch.
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
3. Solución de problemas con Stack Trace y CloudWatch
Veamos la traza de la pila y habilitemos los mapas de origen para solucionar problemas. Podemos usar CloudWatch para buscar registros relacionados con nuestra invocación utilizando el ID de solicitud. Después de implementar la corrección del código, aún encontramos un error de envío fallido. Exploremos la solución de problemas en registros agregados utilizando herramientas de agregación de registros como ElasticSearch.
Veamos la traza de la pila. Es de nuestro archivo de índice. Es la línea dos, columna 570,000. Bueno, para solucionar esto, vamos a necesitar algunos mapas de origen. Así que vamos a habilitarlos y volver a implementar. Mientras eso sucede, exploremos un poco más CloudWatch para conocerlo mejor.
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.
4. Envío de registros de CloudWatch a Elasticsearch
En el entorno serverless, no hay procesos en ejecución continua para enviar registros a Elasticsearch. Para enviar registros de CloudWatch a Elasticsearch, crea un filtro de suscripción en tu grupo de registros. Selecciona el clúster, el formato de registro y prueba el patrón. Otra función Lambda lee los registros de CloudWatch y los envía a Elasticsearch. Elasticsearch proporciona columnas para analizar los registros. Encontramos un error de credenciales incorrectas en nuestra última solicitud, que podemos investigar utilizando las propiedades de Elasticsearch. Localmente, usamos un archivo .env.
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,
5. Troubleshooting Slack Bot and Rollbar
Al igual que con Heroku, debemos agregar variables de entorno para evitar incluir credenciales en el repositorio. Hemos publicado con éxito una respuesta a un PR de Github en mi nombre. Podemos monitorear los registros para detectar errores y asegurarnos de que el bot de Slack esté funcionando. Si alguien más encuentra un error, no lo sabremos a menos que nos lo informen. Veamos Rollbar como otra opción para solucionar problemas. Podemos ver el error más reciente, un error HTTP no encontrado, y analizarlo en detalle.
Estamos usando un archivo .env. Al igual que con Heroku, debemos agregar eso porque no queremos incluir esas credenciales en el repositorio. Así que debemos asegurarnos de tener las variables de entorno allí. Muy bien. Ahora intentémoslo de nuevo. Ok. Y funcionó. Muy bien. Ahora tenemos nuestro mensaje de Slack, que dice, llamando a nuestro amigo, Demo Slack, diciendo que hemos publicado una respuesta a su PR en mi nombre, y se ve bien para mí. Y si hago clic en este enlace, me llevará a mi comentario en el problema. Mi comentario en el PR que les avisa. Así que hemos publicado el comentario en el PR de Github, respondemos a Slack con el mensaje en el canal. Ahora ponemos nuestro bot de Slack en el mundo, ¿y cómo sabemos si está funcionando? Podríamos monitorear los registros regularmente y esperar detectar errores de manera oportuna y poder hacer algo al respecto. Digamos que alguien más obtiene un error al usar el bot de Slack, y como no somos nosotros quienes escribimos el comando, no podemos ver el error, ni siquiera que hubo un error. Así que intentémoslo de nuevo aquí. Oh, sí. Esa solicitud falló. Y notamos que el número de PR está equivocado. ¿Qué está pasando? Echemos un vistazo a otra opción para solucionar problemas, y esa es la plataforma de mejora continua de código de Rollbar. Entonces, si vamos a Rollbar, ya hemos instrumentado la aplicación. Vemos que aparece este error. Es el más reciente. Y notamos que es un error HTTP no encontrado. Ahora, si lo intento de nuevo, porque soy terco. Y una vez más. Observa que nuestro total ha aumentado a 5. Pero si miramos Elasticsearch, veríamos que solo aparecen un montón de estos aquí. Solo sigue golpeándolo. Esto se muestra muy bien como un único elemento de línea para nosotros. Podemos profundizar en ello. Y porque podemos conectarnos con GitHub, en realidad tenemos código fuente aquí.
6. Solución de problemas con PR y Slack
Hemos solucionado el problema con el PR incorrecto y mejorado nuestra solución obteniendo el PR de GitHub y proporcionando una respuesta amigable en Slack. Asiste al taller de David para aprender más sobre la plataforma de mejora continua de código de Rollbar. Encuentra el código fuente del bot de Slack LGTM ReplyGIF en GitHub. Regístrate para obtener una cuenta nueva en Rollbar utilizando el código promocional de Git Nation para obtener un mes completo gratis.
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.
7. Despliegue sin servidor y recomendaciones
Hola Jeff, gracias por unirte. Hola Mitten, ¿cómo estás? Hiciste la pregunta, ¿dónde despliegas tu aplicación? Y el 65% respondió a un PaaS, el 25% a un clúster de Kubernetes y el 19% a máquinas virtuales. Me sorprende que el clúster de Kubernetes no sea más alto, pero tiene sentido. Ahora tenemos tiempo para responder las preguntas de nuestra audiencia. Trabajas en Rollbar, ¿por qué decidiste ir completamente fuera de la empresa? Quería mostrar diferentes formas de solucionar problemas con el sin servidor, incluido el envío de registros a una búsqueda agregada. Rollbar facilita todo con su SDK, integración con Lambda y panel de control. Hay una masterclass próximamente para aquellos interesados en aprender más. Si te preguntara, ¿qué dirías que es el sin servidor? El sin servidor es entregar código a un proveedor sin administrar la infraestructura. Decide dónde y cómo ejecutar tu código. Para los desarrolladores front-end, comenzar con el sin servidor es un enfoque excelente para centrarse en llamadas de API encapsuladas. Siempre puedes pasar a una dirección más consolidada más adelante. Proporciona mejores prácticas y simplifica el despliegue.
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.
8. Using and Contributing to the Slackbot
Hannah preguntó si se puede usar el Slackbot y si debe ser alojado o utilizar una plataforma de alojamiento sin servidor. El bot todavía necesita algunas correcciones y cualquiera puede contribuir bifurcando el proyecto y enviando solicitudes de extracción. Jeff fomenta la colaboración y menciona que resolver su propio problema llevó a esta invención. Anna expresa interés en ayudar y Jeff comparte su cuenta de GitHub con ella. La sesión de preguntas y respuestas concluye y Jeff agradece a la audiencia por su tiempo.
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.
Comments