За небольшой промежуток времени DevOps в Программе «Единая фронтальная система» (ЕФС) прошел огромный путь, охватив ежедневную практику всех команд. Но интенсивные работы по развитию DevOps продолжаются, и в недалеком будущем жизненный цикл ЕФС претерпит новые изменения, направленные на ускорение ввода в эксплуатацию программного обеспечения (continuous delivery) и улучшения его качества (сквозное автотестирование). Но об этом чуть позже, а пока немного истории.
Часть первая. Continuous Integration (CI) и Continuous Deployment (CD)
Было время, когда все приложения Программы ЕФС собирались локально и деплоились на DEV среду вручную:
- Java-приложения с помощью Apache Maven на сервера приложений IBM WebSphere Application Server;
- JS-код — с помощью npm+webpack/gulp на nginx.
Функциональных подсистем, из которых состоит ЕФС, становилось все больше, добавлялись общие элементы архитектуры — IBM WebSphere eXtreme Scale, БД Oracle. Команды стали переходить на хранение кода в Atlassian Bitbucket, где сразу же выстраивали работу с ветками на основе gitflow.
Появилась необходимость в частых сборках и автоматическом деплое. В качестве системы непрерывной интеграции остановились на Jenkins — благодаря удобной интеграции с Bitbucket, простоте конфигурирования, множеству дополнительных плагинов.
Первые сборки в Jenkins запускались при появлении нового pull request’a и просто собирали Java или JS код, отправляя уведомление в Bitbucket об успешности или неуспешности прохождения сборки.
Следующим шагом стали сборки дистрибутивов в NEXUS для последующего деплоя отдельных подсистем на стенды тестирования, запуск в Sonar’е Unit тестов и статического анализа.
Наш Continuous Deployment начался с конца – с наката на промышленные среды. В начале июня 2017 г. прилетела срочная задача – нужно раскатать все функциональные подсистемы ЕФС на промышленные среды в течение месяца. Но у нас с собой было работающее решение -Инсталлятор, которое позволяло устанавливать системы подобного уровня на любые среды на IBM WAS надежно и с гарантией установки.
В принципе Инсталлятор уже был готов для внедрения абстрактных систем банка любого размера, но нужно было выполнить следующие шаги:
- найти информацию и контакты разработчиков каждой отдельной функциональной подсистемы;
- сконфигурировать конфигурационные файлы;
- оттестировать решение и …
- … собственно внедрить!
Поиск всех необходимых контактов и получение информации заняли около двух недель, параллельно разработчики начали заполнять конфигурации. Оставалось их только выверить, поправить ошибки и отдать на тестирование. Тестирование и отладка конфигураций заняли еще две недели. И 8 июля 2017 г. мы вышли в промышленную эксплуатацию.
Как так быстро получилось?
Все дело в парадигме построения Инсталлятора: модульность и отделение кода ядра от инструкций, а уже инструкций от конечных конфигураций.
Система состоит из трех компонентов:
- ядро, большей частью на Jython, которое интерпретирует инструкции и конфигурации;
- инструкции в формате Json, где каждый объект, это какая-то сущность в IBM WAS, будь то DataSource или MQ или что-то еще;
- конфигурации в простейшем формате java properties, которые сами по себе являются парами «ключ-значение».
Ядро принимает в качестве параметра вызова код подсистемы, который необходимо установить. Далее по коду системы находит набор инструкций в соответствующем JSON файле и параметры конкретной среды из property-файлов. Объединяясь, все объекты начинают интерпретироваться, фактически отдавая управление той или иной библиотечной функции.
Преимущества такой системы:
- отделение кода от инструкций дает возможность накатывать настройки и автоматизировано выверять их. Эту особенность Инсталлятора на текущий момент не предоставляет ни одно из решений, доступных для IBM WAS на рынке;
- реально быстрый старт: на обучение разработчиков уходят десятки минут, а не дни. А с новой системой GUI интерфейса, которая бы позволила делать все эти процедуры по клику, разработчиков вообще не пришлось бы отвлекать от бизнес-задач;
- надежность: отлаженный однажды код можно переиспользовать многократно и быть уверенным, что он точно и безошибочно обслужит среду.
Максимально актуально для промышленных сред.
Часть вторая. Сегодня
Система скриптов Деплоя или гибридные скрипты
Исходные данные
Функциональные подсистемы ЕФС в количестве 70 штук, жаждущие перейти со стадии CI к стадии CD.
Соответственно, дистрибутив в составе каталогов:
- BH – бинарные war-файлы для установки приложений на WAS;
- PL – статичные JavaScript CSS, картинки, шрифты, подлежащие кэшированию средствами NGINX;
- DB – содержит SQL процедуры для создания объектов БД и наполнения их данными, завернутые в liquibase;
- XS – бинарные war-файлы для установки приложений, обеспечивающих конфигурацию для работы с сервером eXtreme Scale.
Системное программное обеспечение для корректного функционирования разрабатываемого прикладного программного обеспечения в составе:
- ОС;
- СУБД Oracle;
- сервер приложений (IBM WebSphere Application Server (WAS));
- программное обеспечение класса MiddleWare, обеспечивающее гарантированную доставку сообщений (IBM WebSphere MQ);
- распределенный кэш для кэширования неперсистентных данных (IBM WebSphere eXtreme Scale);
- веб-сервер, обеспечивающий раздачу статики и балансировку на сервера приложений (Nginx).
Ключевые задачи при разработке системы скриптов деплоя
- Управление конфигурацией программного обеспечения класса MiddleWare;
- Развертывание дистрибутива функциональных подсистем;
- Автоматизированный рабочий процесс — для непрерывной доставки результата труда разработчика на все среды (dev, test, prod).
Для реализации библиотек настройки ресурсов WAS и деплоя приложений используется Jython (Java-реализация языка сценариев). Для выполнения всех остальных задач, а также запуска скриптов Jython (хранятся в виде шаблонов Jinja) используется Ansible.
Почему Ansible?
Появившись позднее других аналогичных решений на рынке продуктов для конфигурационного управления, Ansible предлагает самый низкий порог вхождения. Обучиться работе с Ansible можно за достаточно короткое время. Создание отдельных модулей, расширяющих возможности продукта, не представляет большого труда, так как код продукта написан на Python. Язык сценариев – playbooks — достаточно прост и использует в качестве основы язык разметки YAML.
Также важным преимуществом является использование SSH для управления узлами, отсутствие на узлах дополнительных агентов.
Архитектура системы скриптов деплоя (ССД)
Система скриптов деплоя функциональных подсистем представляет собой пакет скриптов, включающий в себя функционал, реализованный в виде ролевой модели, и конфигурационные параметры, состоящие из двух блоков: параметры среды и параметры функциональной подсистемы.
Модель работы системы скриптов деплоя полностью соответствует концепции DevOps и предполагает интеграцию кода скриптов и дистрибутива приложения для продвижения по конвейеру от разработки до промышленной эксплуатации. Работа и интеграция скриптов основана на связке программных средств Ansible-Nexus-Jenkins.
Схема крупнее.
Рассмотрим подробнее функции и компоненты ССД.
Основные функции:
- установка ресурсов для серверов приложений WAS (DataSource, фабрики и очереди MQ и подобные);
- управление приложениями функциональных подсистем ЕФС: установка, удаление, обновление, старт-стоп;
- установка и настройка базовых и тонких настроек серверов приложений WAS;
- обновление таблиц базы данных, используемых приложениями ЕФС;
- обновление статики приложений ЕФС для сервера Nginx;
- детальное логирование всех процессов выполнения вышеописанного функционала;
- шифрование всей конфиденциальной информации с возможностью разграничения доступа к зашифрованной информации.
Пакет системы скриптов развертывания можно разделить условно на 4 фрагмента, интересующие различные группы, участвующие в цикле IT-систем:
- Ядро – программная часть, функционал, разрабатываемый в рамках отдельных ролей Ansible. Реализуется разработчиками скриптов.
- Плейбуки Ansible – раннеры для запуска определенного функционала, реализованного в ролях с использованием параметров конкретной функциональной подсистемы. Используются системными администраторами для запуска скриптов, а также при интеграции с Jenkins. Запуск плейбука основан на соответствующем инвентори функциональной подсистемы, описывающем состав хостов и конфигурационных параметрах, используемых для отработки ролей.
Роль – отдельный модуль, разрабатывающийся независимо и реализующий ограниченный функционал. Такая гибкость позволяет как наращивать дополнительный функционал для использования раннерами, так и использовать только тот функционал, который необходим администратору в данный момент. Например, задеплоить только статику, обновить только приложения, произвести рестарт серверов и т.д.
- Параметры разработчиков – это файлы параметров, предназначенные для разработчиков функциональных подсистем для реализации определения ресурсов, необходимых для их приложений. Входят в состав дистрибутива поставляемой функциональной подсистемы (каталог conf).
- Системные настройки – настройки для системных администраторов конкретной среды: параметры подключения к веб-серверам, URL БД, логины, пароли и т.д., пароли хранятся в зашифрованном виде.
Параметры администраторов среды состоят из параметров конкретной функциональной подсистемы, хранящейся в инвентаре (настройки топологии WAS, настройки WAS конкретной ФП и т.д.), и общих параметров (справочник среды), используемых всеми функциональными подсистемами ЕФС и хранящихся на уровне среды (шифрованные файла паролей и аутентификации ресурсов, коннекты к необходимым серверам, названия очередей и т.д.).
Максимальное количество настроек, используемых администраторами среды, вынесено на уровень среды и правятся не в каждой отдельной функциональной подсистеме, а в справочнике среды.
Продолжение следует
В ближайшем будущем мы планируем доработку процесса DevOps с целью сделать его более автоматизированным, более дружелюбным для всех участников — разработчиков, тестировщиков, админов dev и test сред, админов прома, а самое главное – более надежным. Мы планируем внедрить множество графических систем, помогающих на каждом шагу и берущих рутинные действия сотрудников на себя, для руководства – панель управления и мониторинга, где в режиме реального времени можно будет видеть движение процесса разработки, динамику автодеплоя на стенды тестирования, прохождение автотестов.
Для нас построение DevOps — новый интересный процесс, у которого нет универсальной инструкции. Будем рады пообщаться, обсудить ваш опыт и ответить на вопросы в комментариях!
Автор: EFS_programm
