Хабрахабр

В будущее с интеграцией сервисов Jenkins & Oracle APEX

В процессе управления большими объемами данных и их визуализацией мы все чаще сталкиваемся с необходимостью внедрения единого инструмента доступа к управлению функционалом в хранилище. Причем этот инструмент должен быть одинаково удобен и понятен всем сотрудникам подразделения по управлению данными: администраторам, аналитикам, разработчикам и тестировщикам.

В данной статье я расскажу об интересном решении данной проблемы в крупном хранилище данных компании Ростелеком. Меня зовут Виталий, я отвечаю в Ростелекоме за направление автоматизации тестирования и внедрение DevOps процессов.

Ранее я писал о том, что мы написали собственный модуль на Python для автоматизации процесса инсталляции объектов в хранилище данных. И вот как мы пришли к такому набору инструментов для решения данной задачи.
Для начала небольшая предыстория. Также в нашей компании уже был реализован ряд приложений, написанных при помощи Oracle APEX. Он управляется Jenkins-ом и позволяет запускать необходимый функционал как вручную по кнопке с вводом необходимых параметров запуска, так и полностью автоматически по расписанию без участия пользователя.

Что же такое Oracle Application Express (Oracle APEX)?

Oracle APEX – в более ранних версиях приложения имел название HTML DB. При помощи данного инструмента, используя только браузер и имея опыт программирования на таких языках как PL/SQL и JavaScript, можно разрабатывать быстрые, масштабируемые и безопасные веб-приложения, которые впоследствии легко развернуть на любом контуре для проведения разработки, тестирования и последующей имплементации в продакшн.

В приложении есть много готовых шаблонов, которые можно переиспользовать для разработки собственного решения. Для построения формы ввода данных отсутствует необходимость программировать интерфейс сложным способом. И при всех вышеперечисленных плюсах метаданные (информация об используемых данных) в нашем хранилище лежат в БД Oracle, поэтому данный инструмент мы никак не могли обойти стороной. Конечные пользователи также получают доступ к приложению через браузер, тем самым отпадает необходимость установки приложения на компьютер.


Пример архитектуры APEX-приложения

Он предоставляет взаимодействие с объектами посредством RESTfull Oracle REST Data Services (ORDS) — это сервис данных, заменяющий Oracle HTTP server и mod_plsql, основанный на Java EE.

Немного о Jenkins

Многие, наверное, уже в курсе, что это за зверь, но для тех кто только присматривается к этому инструменту, я расскажу, что это и как мы его используем в нашем хранилище.

Если говорить простыми словами, то Jenkins предоставляет среду автоматизации процессов. Jenkins – это инструмент непрерывной интеграции, чаще всего используется для разработки программного обеспечения и развертывания приложений на разных этапах процесса разработки. Благодаря своей гибкости и большому набору плагинов он дает возможность интегрироваться в любое приложение или технологию и поддерживает работу с разными системами контроля версий.

А еще Jenkins управляет несколькими самописными модулями, благодаря которым автоматизированы многие ручные процессы. В нашем департаменте управления данными с его помощью реализованы CI/CD процессы с прогоном автоматизированных тестов.


Пример интерфейса web-client Jenkins, кликабельно

Проблема непонимания и ее решение

Реализовав многие задачи и автоматизировав их, мы столкнулись с проблемой: управлять этими процессами придется не только DevOps-инженерам и специалистам по тестированию, но и людям, не сталкивающимся с подобного рода инструментами, но участвующими в процессе разработки. Конечными пользователями оказались все внутренние сотрудники департамента. Интерфейс Jenkins-клиента, на мой взгляд, достаточно прост и удобен, но я смотрю на него глазами DevOps, и не все могут посмотреть на него так же. Так как ряд задач у нас должен был запускаться по кнопке сотрудниками, возникла необходимость придумать интерфейс, который был бы дружелюбнее для пользователя. На самом деле, существует плагин для Jenkins под названием Blue Ocean, который позволяет изменить UI представление инструмента.


Пример интерфейса web-client Jenkins (Blue Ocean plugin), кликабельно

Чаще всего возникает необходимость интегрировать модуль в Jenkins, а не наоборот. Нашу задачу данный плагин решить не смог, но в качестве альтернативы, если стандартный интерфейс не устраивает, его можно перенастроить. На момент ее решения, как я и писал, у нас уже существовал ряд приложений, написанных при помощи Oracle APEX. В этом и заключается интересность решаемой задачи.


Пример интерфейса одного из APEX-приложений, кликабельно

Проверив, что его интерфейс достаточно дружелюбен и имеется возможность им управлять, а все параметры для запуска необходимых задач в Jenkins хранятся в БД Oracle, возникла идея запускать ряд задач Jenkins из APEX.

Взаимодействие между приложениями было реализовано по архитектурному принципу построения сервис-ориентированных систем типа REST. Для этого потребовалось совсем немного времени. APEX-приложение позволяет использовать данный стиль и предоставляет уже готовый шаблон для формирования процесса отправки HTTP/HTTPs-запросов типа REST при разработке приложения. REST-архитектура подразумевает под собой правила взаимодействия компонентов распределенного приложения в сети. Сама передача параметров для запуска заданий в Jenkins осуществляется посредством POST-запроса, в теле которого лежит JSON с необходимыми параметрами. В результате мы быстро подняли приложение для запуска подобного рода задач, данные для запуска стали подтягиваться напрямую из базы с возможностью их выбора, что исключило возможность ошибки ввода параметров запуска.


Форма вызова REST при разработке APEX-приложения, кликабельно

Пример JSON:

,{"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":"."}


Пример готового APEX-приложения для вызова процессов Jenkins, кликабельно

Реализовано и отображение логов успешного и неуспешного запусков, которое напрямую возвращается из консоли процесса выполнения Jenkins-задания. Результатом нажатия кнопки “Запустить процесс” будет передача параметров в Jenkins задание и последующий его запуск. Само задание может содержать любой автоматизированный процесс.

В итоге

Интеграция данных приложений в нашем департаменте показала отличный результат. Отпала необходимость заставлять разбираться в инструментарии приложения Jenkins тех людей, которые не должны напрямую с ним работать. Мы смогли разграничить и оставить контроль выполнения задач на уровне Jenkins с использованием настраиваемой матрицы прав, чтобы у пользователей была возможность сборки задач, но не было возможности ее редактирования.

Но это уже совсем другая история, о которой я постараюсь рассказать в следующих статьях. Так как данный эксперимент был признан успешным, появились идеи развития в виде написания собственных open source фреймворков для упрощения взаимодействия с Jenkins и с другими работающими у нас приложениями.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть