Hacia el futuro con la integración del servicio Jenkins y Oracle APEX

En el proceso de gestión de grandes cantidades de datos y su visualización, nos enfrentamos cada vez más a la necesidad de introducir una herramienta única para acceder a la gestión funcional en el repositorio. Además, esta herramienta debería ser igualmente conveniente y comprensible para todos los empleados de la división de gestión de datos: administradores, analistas, desarrolladores y evaluadores.



Mi nombre es Vitaliy, soy responsable en Rostelecom de la dirección de pruebas de automatización e implementación de procesos DevOps. En este artículo, hablaré sobre una solución interesante a este problema en un gran almacén de datos de Rostelecom.

Y así es como llegamos a un conjunto de herramientas para resolver este problema.

Para empezar, un poco de historia. Anteriormente, escribí que escribimos nuestro propio módulo en Python para automatizar el proceso de instalación de objetos en un almacén de datos. Está controlado por Jenkins y le permite iniciar la funcionalidad necesaria, ya sea manualmente mediante un botón con la entrada de los parámetros de inicio necesarios, o de forma totalmente automática de acuerdo con un programa sin intervención del usuario. Además, nuestra compañía ya ha implementado una serie de aplicaciones escritas usando Oracle APEX.

¿Qué es Oracle Application Express (Oracle APEX)?

Oracle APEX: en versiones anteriores de la aplicación se llamaba HTML DB. Con esta herramienta, utilizando solo un navegador y teniendo experiencia en programación en lenguajes como PL / SQL y JavaScript, puede desarrollar aplicaciones web rápidas, escalables y seguras que posteriormente pueden implementarse fácilmente en cualquier circuito para su desarrollo, prueba y posterior implementación en producción .

Para crear un formulario de entrada de datos, no es necesario programar la interfaz de manera compleja. La aplicación tiene muchas plantillas listas para usar que se pueden reutilizar para desarrollar su propia solución. Los usuarios finales también obtienen acceso a la aplicación a través de un navegador, eliminando así la necesidad de instalar la aplicación en una computadora. Y con todas las ventajas anteriores, los metadatos (información sobre los datos utilizados) en nuestro repositorio se encuentran en la base de datos Oracle, por lo que no podemos ignorar esta herramienta.


Ejemplo de arquitectura de aplicación APEX

Oracle REST Data Services (ORDS) es un servicio de datos que reemplaza el servidor HTTP de Oracle y mod_plsql basado en Java EE . Proporciona interacción con objetos a través de RESTfull.

Un poco sobre Jenkins

Muchos, probablemente, ya saben qué tipo de bestia es, pero para aquellos que solo están mirando esta herramienta, les diré qué es y cómo la usamos en nuestro repositorio.

Jenkins es una herramienta de integración continua, que se utiliza con mayor frecuencia para el desarrollo de software y la implementación de aplicaciones en diferentes etapas del proceso de desarrollo. En términos simples, Jenkins proporciona un entorno de automatización de procesos. Debido a su flexibilidad y un gran conjunto de complementos, permite integrarse en cualquier aplicación o tecnología y admite trabajar con diferentes sistemas de control de versiones.

En nuestro departamento de gestión de datos con su ayuda, se implementan procesos de CI / CD con la ejecución de pruebas automatizadas. Y Jenkins gestiona varios módulos autoescritos, gracias a los cuales muchos procesos manuales están automatizados.


Ejemplo de interfaz de cliente web Jenkins, clicable

El problema del malentendido y su solución.

Habiendo implementado muchas tareas y automatizándolas, encontramos un problema: no solo los ingenieros de DevOps y los especialistas en pruebas tendrán que administrar estos procesos, sino también las personas que no encuentran tales herramientas, pero están involucradas en el proceso de desarrollo. Los usuarios finales eran todos empleados internos del departamento. La interfaz del cliente Jenkins, en mi opinión, es bastante simple y conveniente, pero la miro a través de los ojos de DevOps, y no todos pueden verla de la misma manera. Dado que los empleados tenían que ejecutar una serie de tareas en el botón, fue necesario crear una interfaz que fuera más amigable para el usuario. De hecho, hay un complemento para Jenkins llamado Blue Ocean , que le permite cambiar la representación de la herramienta en la interfaz de usuario.


Ejemplo de interfaz de cliente web Jenkins (complemento Blue Ocean), clicable

Este complemento no pudo resolver nuestro problema, pero como alternativa, si la interfaz estándar no es adecuada para usted, puede reconfigurarla. Muy a menudo, se hace necesario integrar el módulo en Jenkins, y no al revés. Este es el interés de resolver el problema. En el momento de su solución, como escribí, ya teníamos una serie de aplicaciones escritas usando Oracle APEX.


Ejemplo de interfaz de una de las aplicaciones APEX, clicable

Después de verificar que su interfaz es lo suficientemente amigable y que es posible administrarla, y que todos los parámetros para iniciar las tareas necesarias en Jenkins se almacenan en la base de datos Oracle, surgió la idea de lanzar una serie de tareas de Jenkins desde APEX.

Tomó bastante tiempo. La interacción entre las aplicaciones se implementó de acuerdo con el principio arquitectónico de construir sistemas orientados a servicios como REST. La arquitectura REST implica las reglas para la interacción de componentes de una aplicación distribuida en la red. La aplicación APEX le permite usar este estilo y proporciona una plantilla preparada para la formación del proceso de envío de solicitudes HTTP / HTTPs de tipo REST durante el desarrollo de la aplicación. Como resultado, levantamos rápidamente la aplicación para iniciar tales tareas, los datos para el lanzamiento comenzaron a extraerse directamente de la base de datos con la posibilidad de su selección, lo que eliminó la posibilidad de un error al ingresar los parámetros de inicio. La transmisión de parámetros para ejecutar tareas en Jenkins se lleva a cabo a través de una solicitud POST, en cuyo cuerpo se encuentra JSON con los parámetros necesarios.


Formulario de llamada REST al desarrollar una aplicación APEX, cliqueable

Ejemplo de JSON:

{"parameter":[{"name":"SERVER","labels":"master"},{"name":"INSTANCE","value":"DEV"},{"name":"SRC_CODE_START","value":"SRC_ID"},{"name":"SRC_CODE_END","value":"SRC_ID"},{"name":"MODEL_ID","value":"MODEL_ID"},{"name":"SAVE_DATA","value":"0"}],"statusCode":"303","redirectTo":"."} 

Un ejemplo de una aplicación APEX preparada para invocar procesos de Jenkins, clicable

El resultado de hacer clic en el botón "Ejecutar el proceso" será la transferencia de parámetros a la tarea de Jenkins y su posterior lanzamiento. Registros mostrados de lanzamientos exitosos y no exitosos, que se devuelve directamente desde la consola del proceso de ejecución de tareas de Jenkins. La tarea en sí puede contener cualquier proceso automatizado.

Al final

La integración de los datos de la aplicación en nuestro departamento mostró un excelente resultado. Ya no es necesario obligar a las personas que no deberían trabajar directamente con Jenkins a comprender el conjunto de herramientas de la aplicación. Pudimos diferenciar y dejar el control sobre la ejecución de tareas en el nivel de Jenkins utilizando una matriz de derechos personalizada para que los usuarios tuvieran la capacidad de crear tareas, pero no tenían la capacidad de editarlas.

Dado que este experimento fue reconocido como exitoso, las ideas de desarrollo aparecieron en la forma de escribir nuestros propios marcos de código abierto para simplificar la interacción con Jenkins y otras aplicaciones que trabajan con nosotros. Pero esta es una historia completamente diferente, que trataré de contar en futuros artículos.