В процессе управления большими объемами данных и их визуализацией мы все чаще сталкиваемся с необходимостью внедрения единого инструмента доступа к управлению функционалом в хранилище. Причем этот инструмент должен быть одинаково удобен и понятен всем сотрудникам подразделения по управлению данными: администраторам, аналитикам, разработчикам и тестировщикам.
Меня зовут Виталий, я отвечаю в Ростелекоме за направление автоматизации тестирования и внедрение DevOps процессов. В данной статье я расскажу об интересном решении данной проблемы в крупном хранилище данных компании Ростелеком.
И вот как мы пришли к такому набору инструментов для решения данной задачи.
Для начала небольшая предыстория. Ранее я писал о том, что мы написали собственный модуль на Python для автоматизации процесса инсталляции объектов в хранилище данных. Он управляется Jenkins-ом и позволяет запускать необходимый функционал как вручную по кнопке с вводом необходимых параметров запуска, так и полностью автоматически по расписанию без участия пользователя. Также в нашей компании уже был реализован ряд приложений, написанных при помощи Oracle APEX.
Oracle APEX – в более ранних версиях приложения имел название HTML DB. При помощи данного инструмента, используя только браузер и имея опыт программирования на таких языках как PL/SQL и JavaScript, можно разрабатывать быстрые, масштабируемые и безопасные веб-приложения, которые впоследствии легко развернуть на любом контуре для проведения разработки, тестирования и последующей имплементации в продакшн.
Для построения формы ввода данных отсутствует необходимость программировать интерфейс сложным способом. В приложении есть много готовых шаблонов, которые можно переиспользовать для разработки собственного решения. Конечные пользователи также получают доступ к приложению через браузер, тем самым отпадает необходимость установки приложения на компьютер. И при всех вышеперечисленных плюсах метаданные (информация об используемых данных) в нашем хранилище лежат в БД Oracle, поэтому данный инструмент мы никак не могли обойти стороной.
Пример архитектуры APEX-приложения
Oracle REST Data Services (ORDS) — это сервис данных, заменяющий Oracle HTTP server и mod_plsql, основанный на Java EE. Он предоставляет взаимодействие с объектами посредством RESTfull
Многие, наверное, уже в курсе, что это за зверь, но для тех кто только присматривается к этому инструменту, я расскажу, что это и как мы его используем в нашем хранилище.
Jenkins – это инструмент непрерывной интеграции, чаще всего используется для разработки программного обеспечения и развертывания приложений на разных этапах процесса разработки. Если говорить простыми словами, то Jenkins предоставляет среду автоматизации процессов. Благодаря своей гибкости и большому набору плагинов он дает возможность интегрироваться в любое приложение или технологию и поддерживает работу с разными системами контроля версий.
В нашем департаменте управления данными с его помощью реализованы CI/CD процессы с прогоном автоматизированных тестов. А еще Jenkins управляет несколькими самописными модулями, благодаря которым автоматизированы многие ручные процессы.
Пример интерфейса 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. REST-архитектура подразумевает под собой правила взаимодействия компонентов распределенного приложения в сети. APEX-приложение позволяет использовать данный стиль и предоставляет уже готовый шаблон для формирования процесса отправки HTTP/HTTPs-запросов типа REST при разработке приложения. В результате мы быстро подняли приложение для запуска подобного рода задач, данные для запуска стали подтягиваться напрямую из базы с возможностью их выбора, что исключило возможность ошибки ввода параметров запуска. Сама передача параметров для запуска заданий в Jenkins осуществляется посредством POST-запроса, в теле которого лежит JSON с необходимыми параметрами.
Форма вызова REST при разработке APEX-приложения, кликабельно
Пример JSON:
Пример готового APEX-приложения для вызова процессов Jenkins, кликабельно
Результатом нажатия кнопки “Запустить процесс” будет передача параметров в Jenkins задание и последующий его запуск. Реализовано и отображение логов успешного и неуспешного запусков, которое напрямую возвращается из консоли процесса выполнения Jenkins-задания. Само задание может содержать любой автоматизированный процесс.
Интеграция данных приложений в нашем департаменте показала отличный результат. Отпала необходимость заставлять разбираться в инструментарии приложения Jenkins тех людей, которые не должны напрямую с ним работать. Мы смогли разграничить и оставить контроль выполнения задач на уровне Jenkins с использованием настраиваемой матрицы прав, чтобы у пользователей была возможность сборки задач, но не было возможности ее редактирования.
Так как данный эксперимент был признан успешным, появились идеи развития в виде написания собственных open source фреймворков для упрощения взаимодействия с Jenkins и с другими работающими у нас приложениями. Но это уже совсем другая история, о которой я постараюсь рассказать в следующих статьях.
Меня зовут Виталий, я отвечаю в Ростелекоме за направление автоматизации тестирования и внедрение DevOps процессов. В данной статье я расскажу об интересном решении данной проблемы в крупном хранилище данных компании Ростелеком.
И вот как мы пришли к такому набору инструментов для решения данной задачи.
Для начала небольшая предыстория. Ранее я писал о том, что мы написали собственный модуль на Python для автоматизации процесса инсталляции объектов в хранилище данных. Он управляется Jenkins-ом и позволяет запускать необходимый функционал как вручную по кнопке с вводом необходимых параметров запуска, так и полностью автоматически по расписанию без участия пользователя. Также в нашей компании уже был реализован ряд приложений, написанных при помощи Oracle APEX.
Что же такое Oracle Application Express (Oracle APEX)?
Oracle APEX – в более ранних версиях приложения имел название HTML DB. При помощи данного инструмента, используя только браузер и имея опыт программирования на таких языках как PL/SQL и JavaScript, можно разрабатывать быстрые, масштабируемые и безопасные веб-приложения, которые впоследствии легко развернуть на любом контуре для проведения разработки, тестирования и последующей имплементации в продакшн.
Для построения формы ввода данных отсутствует необходимость программировать интерфейс сложным способом. В приложении есть много готовых шаблонов, которые можно переиспользовать для разработки собственного решения. Конечные пользователи также получают доступ к приложению через браузер, тем самым отпадает необходимость установки приложения на компьютер. И при всех вышеперечисленных плюсах метаданные (информация об используемых данных) в нашем хранилище лежат в БД Oracle, поэтому данный инструмент мы никак не могли обойти стороной.
Пример архитектуры APEX-приложения
Oracle REST Data Services (ORDS) — это сервис данных, заменяющий Oracle HTTP server и mod_plsql, основанный на Java EE. Он предоставляет взаимодействие с объектами посредством RESTfull
Немного о Jenkins
Многие, наверное, уже в курсе, что это за зверь, но для тех кто только присматривается к этому инструменту, я расскажу, что это и как мы его используем в нашем хранилище.
Jenkins – это инструмент непрерывной интеграции, чаще всего используется для разработки программного обеспечения и развертывания приложений на разных этапах процесса разработки. Если говорить простыми словами, то Jenkins предоставляет среду автоматизации процессов. Благодаря своей гибкости и большому набору плагинов он дает возможность интегрироваться в любое приложение или технологию и поддерживает работу с разными системами контроля версий.
В нашем департаменте управления данными с его помощью реализованы CI/CD процессы с прогоном автоматизированных тестов. А еще Jenkins управляет несколькими самописными модулями, благодаря которым автоматизированы многие ручные процессы.
Пример интерфейса 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. REST-архитектура подразумевает под собой правила взаимодействия компонентов распределенного приложения в сети. APEX-приложение позволяет использовать данный стиль и предоставляет уже готовый шаблон для формирования процесса отправки HTTP/HTTPs-запросов типа REST при разработке приложения. В результате мы быстро подняли приложение для запуска подобного рода задач, данные для запуска стали подтягиваться напрямую из базы с возможностью их выбора, что исключило возможность ошибки ввода параметров запуска. Сама передача параметров для запуска заданий в Jenkins осуществляется посредством POST-запроса, в теле которого лежит JSON с необходимыми параметрами.
Форма вызова REST при разработке APEX-приложения, кликабельно
Пример 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":"."}
Пример готового APEX-приложения для вызова процессов Jenkins, кликабельно
Результатом нажатия кнопки “Запустить процесс” будет передача параметров в Jenkins задание и последующий его запуск. Реализовано и отображение логов успешного и неуспешного запусков, которое напрямую возвращается из консоли процесса выполнения Jenkins-задания. Само задание может содержать любой автоматизированный процесс.
В итоге
Интеграция данных приложений в нашем департаменте показала отличный результат. Отпала необходимость заставлять разбираться в инструментарии приложения Jenkins тех людей, которые не должны напрямую с ним работать. Мы смогли разграничить и оставить контроль выполнения задач на уровне Jenkins с использованием настраиваемой матрицы прав, чтобы у пользователей была возможность сборки задач, но не было возможности ее редактирования.
Так как данный эксперимент был признан успешным, появились идеи развития в виде написания собственных open source фреймворков для упрощения взаимодействия с Jenkins и с другими работающими у нас приложениями. Но это уже совсем другая история, о которой я постараюсь рассказать в следующих статьях.
