Привет, Хабр! Мы в Страховом Доме ВСК хотим рассказать о своей платформе автоматизации с некоторыми дополнительными возможностями.

Кратко о том, как мы выбирали название. Инфраструктура любой большой корпорации представляет собой целый океан различных подсистем. Где-то водятся тривиальные бухгалтерские программы, где-то высоконагруженные фронтенды, и над всем этим плавают хищные акулы отдела безопасности. Нам нужно было что-то нейтральное, но в то же время чтобы у всех команд возникали ассоциации с быстротой и ловкостью. На наш взгляд, название «Марлин» идеально для этого подходит.

История создания

Где-то до 2018 года в компании использовалось около ста пятидесяти различных IT-подсистем, так или иначе связанных между собой. Но для того чтобы выяснить, кто с кем взаимодействует, приходилось тратить целые дни на совещания.

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

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

Сначала смотрели в сторону известных на тот момент платформ. Очень понравилась система Low-code app development от Pega, но у нее был большой недостаток – очень дорого.

Поэтому мы приняли решение о создании собственного единого корпоративного архитектурного репозитория всех приложений. При этом в основе должны были лежать opensource-проекты, хорошо зарекомендовавшие себя. Опять же, для экономии средств.

На разработку первой бета-версии ушло два года, и осенью 2020 года мы получили продукт, с которым можно работать. Январь 2021 – дата формирования первой команды +  официального запуска первого приложения с кодовым названием «Сервисный хаб» в промышленную эксплуатацию на новой платформе.

Общая схема Marlin

Чтобы понимать, какое место система Marlin занимает в инфраструктуре компании, мы сделали краткое описание.

Marlin является архитектурным репозиторием. На данный момент используется следующий стек технологий:

• контроллер на Ruby (планируем мигрировать на Java);

• портал разработчика на React;

• набор Jenkins’ов под управлением контроллера, за которыми стоит множество сервисов для разработчиков.

С точки зрения пользователя, Marlin представляет собой портал – единое окно для разработчика, где можно получить весь спектр услуг, закрывающий потребности на любом этапе разработки и эксплуатации: создавать репозитории для хранения кода, выполнять компиляцию и сборку приложения, разворачивать его на контролируемых платформой средах исполнения OpenShift/OKD, запускать тестирование и получать обратную связь через инструменты журналирования и мониторинга. 

Для реализации автоматической настройки предоставляемых ресурсов, команда разработки описывает структуру приложения, указывает зависимости между микросервисами, описывает необходимые публикации. 

Тестированием приложений занимается отдельная информационная система, в которую через портал передается информация о готовности приложений к проверкам. По окончании работы отчёты о результатах тестирования оказываются доступны в интерфейсе платформы.

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

На платформе реализованы четыре среды: development, testing, staging, production, каждая их которых имеют уникальную специфику и место в общем IT-ландшафте компании.

Этапы работ от старта до запуска в эксплуатацию

Давайте представим менеджера проекта, который только недавно устроился в компанию, изучил документацию и ему поручили создать простое приложение Hello World.

Приложение будет на NodeJS: https://github.com/rumantic/node-hello.git

Предположим что HelloWorld это комплексная информационная система.

Регистрация нового приложения

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

Сначала указываем название, код и выбираем, привязывать ли приложение к CMDB-каталогу. 

Формирование команды

После создания проекта можно приступить к этапу добавления участников команды. Здесь у каждого есть свои роли: бизнес-владелец, разработчик, отдел эксплуатации. Как видите, есть небольшие отличия от традиционных scrum-ролей. Это связано с тем, что в обычной разработке команда после завершения работы передает продукт заказчику. Но в нашем случае это с самого начала внутренний продукт компании, поэтому добавляется специальная роль отдела эксплуатации.

После того как команда сформирована, портал обращается к Gitlab, в котором создается группа с этими участниками. Чтобы в дальнейшем, все репозитории, которые будут создаваться в группе были доступны этим участникам.

Формализация проекта микросервисами

Команда разработчиков разбирает техническое задание и определяет, какие микросервисы потребуются для реализации. 

При добавлении очередного сервиса можно выбрать следующие параметры:

• Тип сервиса: Legacy, MONO (монолит), backend, Front, Kafka

• Стек технологий: dotNet 3.1, Java11, NodeJS, Nginx

В нашем примере приложение будет использовать только один микросервис.

Естественно в дальнейшем можно будет добавлять новые зависимости, если того потребует процесс.

Зависимости

Практически любой проект нуждается в каких-либо инфраструктурных ресурсах. Для разработчиков у нас доступен широкий набор уже известных сервисов с открытым исходным кодом, но вместе с ними можно выбирать и наши собственные специализированные разработки, которые мы применяем только внутри компании.

Вот перечень этих ресурсов:

1. Кластеры OpenShift и OKD. Надежное решение от RedHat. Имеет богатый набор различных отлаженных инструментов для управления, логирования, резервного копирования.

2. PostgreSQL – мы выбрали эту базу данных, так как она отвечает всем нашим требованиям и является проектом с открытым кодом. 

3. Keycloak межсервисной аутентификации. С его помощью все наши сервисы при создании API реализовывают современные механизмы аутентификации.

4. Keyсloak пользовательской аутентификации, так же как и для приложений, для пользователей мы используем эту технологию.

5. MinIO PaaS – объектное хранилище с актуальным, удобным протоколом S3, при этом с открытым исходным кодом.

6. Kafka - мы выбрали этот брокер сообщений, так как на момент разработки это было оптимальное решение. Надежность и хорошая документация позволили быстро интегрировать его с нашими сервисами.

7. MongoDB - в качестве решения NoSQL для хранения документов в нашем случае тоже отлично подошла.

Если в процессе работы выясняется, что наше приложение потребляет больше ресурсов чем мы изначально требовали, можем дозаказать дополнительные ресурсы. На примере MinIO можно дозаказать ресурсы на среде, где разворачивается сервис. Нужно выбирать: Dev, Test, Stage и Production. При разработке и тестировании это может быть небольшой объем, но когда приложение выводится в Production, система позволит нам её масштабировать.

Стоит заметить, что до внедрения Marlin процедуру запроса на получение и открытие доступа к новым ресурсам приходилось делать через HelpDesk в соответствующую службу. Теперь всё делается через интерфейс портала Marlin в автоматизированном режиме.

Разворачиваемые ресурсы будут доступны приложению через параметры подключения, переданные в контейнер через механизм переменных окружения или конфигурационные файлы. Например, если мы запросили базу данных PostgreSQL, в результате нам будет доступен JDBC connection string и/или набор параметров подключения (host, port, username и т.д).

Подписки

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

Для решения этой задачи наш архитектурный каталог реализует технологию подписок на API.

Сегодня механизм подписок решает задачу документирования и автоматизации настройки приложений, но не влечёт за собой жёстких ограничений и связанных с ними проверок. 

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

• После подписки на какой-либо сервис, портал начинает контролировать совместимость версий и предоставляет при запуске нашего сервиса адреса для подключения к экземпляру совместимой версии.

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

• Служба информационной безопасности будет апрувить запросы на взаимодействие между сервисами двух разных приложений.

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

Отдельно стоит сказать про так называемые legacy-приложения. Большое количество приложений физически невозможно или не представляется необходимым перенести на платформу. Для них создаются простые регистрационные записи, для обеспечения учёта связей между сервисами платформы и внешними ресурсами (функция архитектурного репозитория).

Написание кода

Теперь всё готово к тому, чтобы участники группы разработки начали писать код. Все коммиты происходят в GitLab-репозиторий. 

Когда руководитель команды решает, что разработчики подготовили очередной релиз, создается тег или ветка в репозитории, из которой можно создать docker-образ.

Создание docker-образа

При создании docker-образа мы указываем: версию сервиса и название ветки GitLab, из которой будет забирать готовый код.

У нас разработано несколько стандартных процедур контроля качества приложения. На основе этих стандартов, мы разработали несколько инструментов. Мы можем включать их, чтобы происходила автоматическая проверка приложения. 

Вот список этих инструментов:

• build – включена по умолчанию (сама процедура сборки);

• SonarQube (статический анализ может не пропустить эту сборку при непрохождении гейтов по количеству уязвимостей, багов, степени покрытия кода тестами и т. п.);

• план-Факт (соответствие реального API сервиса и декларации этого API);

• авторизация (наш портал забирает на себя вопросы межсервисной и пользовательской аутентификации). Мы предоставляем Keycloak (реализует OAuth), которые даём как PaaS для приложений. Если два приложения собираются общаться между собой, тогда наше архитектурное решение обеспечивает, чтобы это взаимодействие было аутентифицированным. И этот инструмент проверяет, действительно ли сервис реализовал аутентификацию и правильно ли это сделал).

Не все инструменты обязательны для включения, так как некоторые ещё не до конца проработаны, а некоторые могут сбоить. 

После запуска сборки в один из Jenkins’ов поступает команда: собери нам это приложение из такого-то репозитория и положи туда-то результат этой сборки (docker image или иной артефакт). Туда-то – это набор Nexus’ов, хранилищ артефактов. Из нексусов они попадают в среду исполнения.

Пока идет сборка, отображается статус «в процессе».

В самом Jenkins можно посмотреть процесс сборки.

Пользователям Marlin доступна кнопка просмотра логов

Когда сборка закончена, индикатор меняется на зеленый. В хранилище артефактов появился новый образ.

Развертывание

Дальше команда может развернуть этот сервис на какой-либо среде. Для этого есть вкладка «Поставки»:

Поставка — это абстракция, которая указывает на версию и доступность сред исполнения для  собранного приложения, по умолчанию это development (по мере прохождения гейтов, поставка получит возможность быть развернутой в testing -> staging -> production). 

Теперь мы можем запустить развертывание:

На старте можно выбрать развертывание только в dev-среде:

Dev-среда это набор из нескольких кластеров, где есть все инфраструктурные элементы: базы данных, файловые хранилища, среды исполнения.

В итоге:

• Заранее зарезервирован набор адресов, на которых приложение будет доступно в сети компании.

• Контроль над версиями приложения будет построен так, чтобы не допустить разворачивание версии сервиса, нарушающей обратную совместимость с его текущими подписчиками.

• Статус «валидность» указывает на то, что все требуемые для сервиса ресурсы (PaaS’ы развертывания сервисов, от которых зависит текущий) в настоящий момент подготовлены и доступны.

• После того как Dev-версия будет готова, появится возможность разворачивать в других средах. На Test, Stage и Production.

Тестирование

Важным этапом при разработке является тестирование. После того как сервис развернут, в интерфейсе Marlin появляется кнопка «Тестирование». При нажатии в информационную систему, занимающуюся управлением процессом тестирования, передается сигнал о том, что сборка готова к запуску тестов.

Сейчас у нас есть отдельная информационная система, которая занимается тестированием. Для Marlin это представляется неким чёрным ящиком, и наш портал просто сообщает,  что сервис готов к тестированию, а дальше получаем отчёт о статусе этого тестирования.

Если тестирование успешно, тогда появляется возможность переходить на следующую среду.

Вывод

Система Marlin позволила нам упорядочить хаос целого зоопарка разрозненных приложений, каждое из которых использует свой стек технологий. Теперь мы можем расширять систему новыми надстройками. В будущем планируем внедрить управление бизнес-процессами и взаимодействие с командой ИБ.

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

• нужно постоянно соблюдать баланс между желанием угодить всем командам, но в тоже время оставить платформу простой в использовании;

• также некоторые команды до сих пор действуют по старинке и не хотят активно использовать платформу Marlin, поэтому необходимо продвигать платформу, чтобы она окончательно стала стандартом для всех информационных отделов компании.

В комментариях будем рады ответить на ваши вопросы по нашей системе.