- PVSM.RU - https://www.pvsm.ru -
За небольшой промежуток времени DevOps в Программе «Единая фронтальная система» (ЕФС) прошел огромный путь, охватив ежедневную практику всех команд. Но интенсивные работы по развитию DevOps продолжаются, и в недалеком будущем жизненный цикл ЕФС претерпит новые изменения, направленные на ускорение ввода в эксплуатацию программного обеспечения (continuous delivery) и улучшения его качества (сквозное автотестирование). Но об этом чуть позже, а пока немного истории.
Было время, когда все приложения Программы ЕФС собирались локально и деплоились на DEV среду вручную:
Функциональных подсистем, из которых состоит ЕФС, становилось все больше, добавлялись общие элементы архитектуры — 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 г. мы вышли в промышленную эксплуатацию.
Как так быстро получилось?
Все дело в парадигме построения Инсталлятора: модульность и отделение кода ядра от инструкций, а уже инструкций от конечных конфигураций.
Система состоит из трех компонентов:
Ядро принимает в качестве параметра вызова код подсистемы, который необходимо установить. Далее по коду системы находит набор инструкций в соответствующем JSON файле и параметры конкретной среды из property-файлов. Объединяясь, все объекты начинают интерпретироваться, фактически отдавая управление той или иной библиотечной функции.
Преимущества такой системы:
Максимально актуально для промышленных сред.
Функциональные подсистемы ЕФС в количестве 70 штук, жаждущие перейти со стадии CI к стадии CD.
Соответственно, дистрибутив в составе каталогов:
Системное программное обеспечение для корректного функционирования разрабатываемого прикладного программного обеспечения в составе:
Для реализации библиотек настройки ресурсов WAS и деплоя приложений используется Jython (Java-реализация языка сценариев). Для выполнения всех остальных задач, а также запуска скриптов Jython (хранятся в виде шаблонов Jinja) используется Ansible.
Почему Ansible?
Появившись позднее других аналогичных решений на рынке продуктов для конфигурационного управления, Ansible предлагает самый низкий порог вхождения. Обучиться работе с Ansible можно за достаточно короткое время. Создание отдельных модулей, расширяющих возможности продукта, не представляет большого труда, так как код продукта написан на Python. Язык сценариев – playbooks — достаточно прост и использует в качестве основы язык разметки YAML.
Также важным преимуществом является использование SSH для управления узлами, отсутствие на узлах дополнительных агентов.
Система скриптов деплоя функциональных подсистем представляет собой пакет скриптов, включающий в себя функционал, реализованный в виде ролевой модели, и конфигурационные параметры, состоящие из двух блоков: параметры среды и параметры функциональной подсистемы.
Модель работы системы скриптов деплоя полностью соответствует концепции DevOps и предполагает интеграцию кода скриптов и дистрибутива приложения для продвижения по конвейеру от разработки до промышленной эксплуатации. Работа и интеграция скриптов основана на связке программных средств Ansible-Nexus-Jenkins.
Схема крупнее. [1]
Рассмотрим подробнее функции и компоненты ССД.
Пакет системы скриптов развертывания можно разделить условно на 4 фрагмента, интересующие различные группы, участвующие в цикле IT-систем:
Роль – отдельный модуль, разрабатывающийся независимо и реализующий ограниченный функционал. Такая гибкость позволяет как наращивать дополнительный функционал для использования раннерами, так и использовать только тот функционал, который необходим администратору в данный момент. Например, задеплоить только статику, обновить только приложения, произвести рестарт серверов и т.д.
Параметры администраторов среды состоят из параметров конкретной функциональной подсистемы, хранящейся в инвентаре (настройки топологии WAS, настройки WAS конкретной ФП и т.д.), и общих параметров (справочник среды), используемых всеми функциональными подсистемами ЕФС и хранящихся на уровне среды (шифрованные файла паролей и аутентификации ресурсов, коннекты к необходимым серверам, названия очередей и т.д.).
Максимальное количество настроек, используемых администраторами среды, вынесено на уровень среды и правятся не в каждой отдельной функциональной подсистеме, а в справочнике среды.
В ближайшем будущем мы планируем доработку процесса DevOps с целью сделать его более автоматизированным, более дружелюбным для всех участников — разработчиков, тестировщиков, админов dev и test сред, админов прома, а самое главное – более надежным. Мы планируем внедрить множество графических систем, помогающих на каждом шагу и берущих рутинные действия сотрудников на себя, для руководства – панель управления и мониторинга, где в режиме реального времени можно будет видеть движение процесса разработки, динамику автодеплоя на стенды тестирования, прохождение автотестов.
Для нас построение DevOps — новый интересный процесс, у которого нет универсальной инструкции. Будем рады пообщаться, обсудить ваш опыт и ответить на вопросы в комментариях!
Автор: EFS_programm
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/devops/264102
Ссылки в тексте:
[1] крупнее.: https://hsto.org/web/3a1/74b/364/3a174b3648ed4befb9b6015e30079895.jpg
[2] Источник: https://habrahabr.ru/post/338228/
Нажмите здесь для печати.