JMeter (Jenkins + Github)
Table of Contents
Avanzado - This article is part of a series.
¿ Qué es Jenkins ? #
Jenkins es un herramienta de integración continua basada en el proyecto open source Hudson, el proyecto Hudson inició en el año 2004 por Sun Microsystems, pero como todos sabemos Oracle Corporation adquirió Sun Microsystems en el año 2010, por lo tanto los derechos de Hudson fueron reclamados por Oracle y en Enero del 2011 se decidió cambiar el nombre a Jenkins, aunque se continua con ambos proyectos hasta la fecha. Existen muchas similitudes entre ambas herramientas, pero la comunidad de Jenkins es mucho más grande. Algunas herramientas alternativas de integración continua son:
¿ Comó funciona Jenkins ? #
Básicamente con Jenkins puedes crear flujos o tuberias (pipelines) con múltiples etapas. Esto quiere decir, se pueden automatizar acciones (jobs) que pudieran estar conectados por etapas y sujetos a condiciones especificas, tales como que la acción sea exitosa o no. Por ejemplo si una acción tiene como un código de salida cero, indicaría que terminó correctamente; caso contrario si el código de salida fuera distinto de cero podría indicar un fallo en la compilación, construcción y/o ejecución de la acción. Por lo tanto se podría parar o detener toda la tubería o flujo.
Cabe destacar que existen muchos aditamentos que se pueden instalar en Jenkins, esto con la finalidad de integrar diversos canales de comunicación para alertar a las personas involucradas que la tubería o flujo se bloquearon por algún motivo. Ya dependerá de el proceso y el manejo del mismo si se vuelve a comenzar desde el inicio o se continua con errores, esto es posible si existe tolerancia a fallos.
¿ Qué es Github ? #
GitHub es una plataforma distribuida y colaborativa para el control de versiones de tipo Git, específicamente dirigido al manejo y administración del código fuente. GitHub está basado en el framework Ruby on Rails y escrito en el lenguaje de programación Ruby. En el año 2018 GitHub fue adquirido por el gigante Redmond Microsoft y con ello varias empresas que tenían su código fuente alojado en GitHub migraron a otras herramientas similares como:
Algo que vale la pena mencionar acerca de GitHub y que le dio mucha popularidad fue el hecho de que soportar uno de los mayores ataque de tipo DDoS (ataque de denegación de servicio distribuido) de la historia. El día 28 de Febrero del 2018, soportaron hasta 1.35 Tbps (Terabits por segundo) enviados a través de 126.9 millones de paquetes por segundo mediante el vector de ataque de al parecer 100,000 servidores Memcached y esto fue contenido exitosamente gracias al servicio Akamai Prolexic. Se tienen fuertes sospechas que la razón principal del ataque era para robar el código fuente de empresas grandes de software.
¿ Comó funciona GitHub ? #
GitHub funciona principalmente por medio de repositorios, cada repositorio tiene su página web en la plataforma, así como una Wiki. Una vez creado el repositorio se procede a subir los archivos al mismo mediante de los comandos git add, git commit y git push. Aquí puedes consultar todas las órdenes básicas de Git, esto es para el versionado de código. La herramienta también cuenta con otras funcionalidades como interfaz gráfica (GUI) disponible para Linux, MacOS y Window, plataforma web (GitHub.com), wiki, kanban e interacción de tipo red social, entre otras. Lo que nos interesa para esta publicación es poder crear un repositorio público para nuestra integración.
¿ Cómo funciona la integración Jenkins y GitHub con JMeter ? #
La integración es sencilla, basta con crear un repositorio público en GitHub, en dónde tengamos nuestro script de JMeter alojado, para que Jenkins pueda ir a clonar este repositorio localmente y tengamos la versión deseada del script para iniciar la ejecución. La ejecución se realizará por medio del esquema distribuido maestro-esclavo, pudiendo ser sobre una red privada (local) o pública. Los resultados se quedarían guardados dentro del área de trabajo (workspace) de Jenkins para poder ser consultados posteriormente y también se publicarán en formato HTML por medio de un servidor Web Apache.
- Actualizar nuestro script de JMeter (JMX) en GitHub.
- El proyecto de Jenkins solicita el clonado este repositorio localmente.
- GitHub permite el clonado repositorio (también puede ser un repositorio privado).
- Jenkins ejecuta localmente JMeter (controlador) en modo distribuido sobre el nodo.
- El nodo envía los resultados por RMI al servidor controlador (Jenkins) y estos resultados son almacenados en el área de trabajo.
- Los resultados son publicados en la carpeta del servidor Apache y son compartidos en formato HTML.
¿ Por qué utilizar GitHub en la integración ? #
El principal motivo por el cual se recomienda utilizar una plataforma de control de versiones, es para evitar actualizar el script de JMeter (JMX) directamente sobre el servidor Jenkins o el generador de carga. Esto debido a que pueden cometer errores en el proceso, como colocar manualmente el archivo incorrecto o versión incorrecta. Recordemos que entre menos accesos se tenga a esta infraestructura es mejor, pues se generaría mayor confianza en los resultados.
Cabe mencionar que el repositorio utilizado también puede ser privado, pero para ello se tendrán que configurar credenciales de acceso para el repositorio.
¿ Por qué utilizar un esquema distribuido de JMeter ? #
De ninguna manera recomendaría ejecutar la prueba desde el mismo servidor en dónde se encuentra alojado Jenkins, esta es una mala práctica muy popular. Creo que no tengo que listar los motivos por lo cual esto es una mala práctica, pero en caso de existir alguna duda favor de consultar esta publicación.
¿ Puedo usar alternativas a Jenkins o GitHub ? #
Si, la publicación abarca la configuración e idea general, por lo que puedes intercambiar Jenkins por alguna otra herramienta de intergación continua, o también alternar GitHub por cualquier otra herramienta de control de versiones.
¿ Que necesitamos ? #
Necesitamos un con Apache web server instalado que es basicamente correr un par de comandos; también debe tener instalado y configurado Jenkins para que podamos instalar manualmente el aditamento de Git. También requerimos un repositorio GIT en dónde se encontrará alojado nuestro script de JMeter, si el repositorio es público no ese necesario instalar nada adicional, en caso de ser repositorio privado se tendrá que instalar aditamento de autenticación de GitHub. Finalmente instalar y configurar JMeter en modo distribuido en Jenkins (controlador) y en el nodo (generador de carga) utlizando las guías antes mencionadas.
Receta de cocina #
1.- Crear un proyecto #
Vamos a crear un proyecto de estilo libre, y ahi mismo vamos a configurar el repositorio de GitHub. Para este ejemplo utilicé el repositorio JMeter_Script.
2.- Configurar el proyecto #
También vamos a configurar 4 parametros, que se encagarán de ajustar la cantidad de usarios concurrentes, el tiempo de la rampa y el tiempo de duración de la prueba. Por último también vamos a introducir la dirección IP del servidor remoto en dónde se ejecutarán las pruebas. Para realizar esta tarea vas tener que seguir las siguientes publicaciones depenediendo si te encuentras una red privada (local) o pública. Por último también el script debiera estar preparado para aceptar sobre escritura de parametros como se muestra en esta publicación.
Línea de comando para la ejecución de JMeter, como podrás ver el reporte se genera automáticamente al finalizar la prueba en el Workspace. Para esta prueba se descargo e instalo JMeter en el controlador (Jenkins) dentro de la carpeta JENKINS_HOME, con la finalidad de evitar problemas de permisos.
Comando para Jenkins Linux/Unix/MacOs
$JENKINS_HOME/JMeter/apache-jmeter-5.3/bin/jmeter.sh -n -t $WORKSPACE/JMeter_Script_Plugins.jmx -l $WORKSPACE/JMeter_Script_Plugins-$BUILD_NUMBER.jtl -Jthreads=$Threads -Jrampup=$RampUp -Jduration=$Duration -R $RemoteEngine -e -o $WORKSPACE/$BUILD_NUMBER
Comando para Jenkins Windows
%JENKINS_HOME%/JMeter/apache-jmeter-5.3/bin/jmeter.bat -n -t %WORKSPACE%/JMeter_Script_Plugins.jmx -l %WORKSPACE%/JMeter_Script_Plugins-%BUILD_NUMBER%.jtl -Jthreads=%Threads% -Jrampup=%RampUp% -Jduration=%Duration% -R %RemoteEngine% -e -o %WORKSPACE%/%BUILD_NUMBER%
Línea de comando para copiar los resultados del Workspace al servidor Apache, para que estén disponibles para todos desde cualquier sitio. Cabe mencionar que se debe crear la carpeta de reportes y otorgarle permisos al usuario de Jenkins para poder escribir en esa carpeta.
cp -R $WORKSPACE/$BUILD_NUMBER /var/www/html/reportes/
3.- Ejecutar el proyecto #
Ejecución de la prueba, para ello seleccionaremos la opción de “Build with Parameters” (Construir con parámetros), estos parámetros serán pre-llenados con los valores que indicamos por definición. Una vez en ejecución entraremos a los resultados de el build id en este caso #2 y revisaremos la salida del “Console Output”. Al finalizar la prueba, verificamos que los resultados esten almacenados en el área de trabajo (Workspace).
Lo mas recomendable es generar una imagen del servidor nodo para poder detenerlo cuando no estén ejecutando la prueba (para ahorrar costos) y cuando se necesite podremos iniciarlo y obtener la nueva dirección IP del servidor nodo para actualizar el valor en los parámetros antes de cada ejecución.
4.- Revisar resultados #
Para finalizar, pocederemos a revisar el reporte por medio de un navegador web:
Conclusión #
Esta solución es a mi parecer la mejor manera de ejecutar confiablemente tus pruebas de carga, y obtener resultados que puedas compartir o visualizar fuera de Jenkins, dado que si requiere revisar gráficas o resultados en particulares no necesitas ingresar a Jenkins para obtenerlos. También seria bastante sencillo obtener las tablas de resultados como pudimos observar en la última imagen web, por lo que comparar y exportar tablas de resultas seria de extrema utilidad. Si tuvieramos múltiples aplicaciones se podrían crear múltiples carpetas como /reportes/app1/ /reportes/app2/ etc. y podríamos acceder a cientos de resultados de manera fácil desde un navegador.
Debemos tener la certeza de que los archivos de resultados JTL del área de trabajo (Workspace) se encuentran resguardados y respaldados, esto es muy importante, dado que si el servidor Jenkins falla, se deben contar con copias de seguridad de estos valiosos resultados históricos. Cabe señalar que el área de oportunidad aquí reside en la seguridad y exposición de dichos resultados. No está de más siempre trabajar con los encargados de administrar Jenkins, Git o los servicios Web para reforzar la seguridad y permisos antes de exponer información sensible interna o exteramente.