DOU Labs: как в EPAM создали Delivery Platform – акселератор для старта проектов
В рубрике DOU Labs мы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на Данный адрес e-mail защищен от спам-ботов, Вам необходимо включить Javascript для его просмотра. .
Привет. Меня зовут Евгений Моспан, работаю Solution Architect в компании EPAM. Сегодня я хочу рассказать о проекте под названием EPAM Delivery Platform, целью которого — минимизировать время для построения на проекте эффективных CI/CD практик.
Идея проекта
Наверняка каждый из вас наблюдал такую картину. Начинается новый проект, у всех амбициозные планы сделать мир лучше, использовать проверенные практики с предыдущих проектов, построить CI/CD своей мечты. В общем, за все хорошее, против всего плохого. Уверен, что есть проекты, на которых получается воплотить эти мечты в реальность, но есть и такие, на которых это не удается в силу разных причин. Например, команда не может договориться, потому что у всех разное представление о хорошем, у заказчика специфичная инфраструктура и т. д. и т. п. В итоге имеем шансы примерно 50/50: либо получится, либо нет. Рано или поздно, в рамках какой-либо инициативы возникает стремление склонить чаши весов в сторону более успешных запусков проектов.
В EPAM одной из таких инициатив стал наш проект под названием EPAM Delivery Platform (далее по тексту сокращенно EDP). Сама идея возникла в конце 2017 года. Основная задача EDP — обеспечить минимальное время для так называемого спринта 0, когда и происходит формирование основных практик на проекте, конфигурирование CI/CD и другие процессы. После этого приступить в спринте 1 к разработке бизнес-фич, которые можно демонстрировать заказчику, автоматизировано тестировать и пропускать через конфигурируемые Quality Gates на различных этапах CI/CD процесса.
Цель EDP: сделать длительность спринта 0 — максимум в 2 недели, которые включают в себя разворачивание инфраструктуры, настройку CI/CD под конкретный проект, обучение команды тем инструментам и pipelines, которые используются в решении.
Команда: в ней собраны архитекторы и инженеры (software engineers, DevOps, testing engineers), которые имеют достаточно глубокую экспертизу и опыт разработки проектов на Java, JavaScript, .NET с использованием современных CI/CD практик.
Девиз: «Business value from Sprint 1».
Основные технологии, выбранные для проекта
Естественно, для обеспечения столь амбициозной цели и повторяемого результата мы сделали целый ряд важных решений. С одной стороны, они сужают применение EDP для конкретных проектов, с другой — обеспечивают повторение решения и возможность создать критический набор обучающих материалов.
Основные технологии EDP:
- Контейнеризация на основе Docker.
- Оркестрирование контейнеров посредством Kubernetes.
- Platform as a Service поверх Kubernetes — OpenShift.
Схематично решение можно представить в виде следующего набора слоев. Установка на любую инфраструктуру, где есть возможность использовать 3 технологии, описанные выше.
Опытные пользователи OpenShift или Kubernetes заметят, что существует немало уже готовых решений или референсных статей, таких как:
- CI/CD with OpenShift;
- Continuous Integration and Continuous Delivery with Fabric8;
- OpenShift.io;
- И, например, очень свежее решение на основе Kubernetes и Istio.
При ближайшем рассмотрении адаптации этих решений возникает целый ряд сложностей. Так, CI/CD от OpenShift описывает лишь базовые принципы, как CI/CD может быть организовано на базе платформы и не детализирует реализацию и специфику использования.
Команда Fabric8, с другой стороны, проделала огромный, я бы даже сказал титанический объем работы по адаптации Java-приложений на базе Spring Cloud + Netflix, обещая возможность деплоймента микросервисных решений как в OpenShift, так и в Kubernetes. К слову, именно этот продукт оказал наибольшее влияние на архитектуру и возможности EDP.
В тоже время с точки зрения конечного пользователя Fabric8 не выглядит легким в применении. Анализируя возможности Fabric8, команда EDP даже шутила, что это the most bleeding cutting edge they’ve ever seen. Причиной этому была банальная невозможность проинсталлировать стабильную версию платформы, будь то на minikube/minishift или полноценные кластеры OpenShift и Kubernetes. Возможно, это связано с тем, что судя по саммитам Red Hat (например, это видео) команда разработчиков Fabric8 помогает строить OpenShift.io, что повлекло за собой снижение темпов разработки самого Fabric8.
OpenShift.io выглядит очень многообещающей платформой, в которой, однако, есть пару важных «но»:
- Интегрированная система управления проектом значительно уступает привычным Jira, Rally, Trello и т. д. Многие ли захотят использовать новый инструмент с отсутствием уже привычного функционала?
- Разработка в браузере на основе Eclipse Che выглядит очень привлекательно с точки зрения менеджера и Ops, но мне сложно представить там радостно работающих senior developers, привыкших к взрослым полнофункциональным IDE.
OpenShift.io заслуживает более детального изучения и отдельной статьи. Как, впрочем и новая восходящая звезда — KNative. Говорить много об этой технологии пока рано, посмотрим, насколько далеко они смогут зайти. Начало выглядит многообещающим.
Из чего состоит и как работает EPAM Delivery Platform
Для дальнейшего рассказа об архитектуре и пользе EDP для стартующих проектов в EPAM, стоит сразу описать ее основные функции:
- Интегрированный набор инструментов для организации CI/CD, с возможностью заменять инструменты аналогами.
- Централизованная система аутентификации и авторизации. Организация SSO для всех CI/CD инструментов и интеграция с корпоративным SSO. RBAC-контроль доступа к ресурсам платформы.
- Прозрачная интеграция source code приложений в CI/CD инструменты.
- Конфигурируемый continuous delivery pipeline с возможностью настройки последовательности его этапов (stages).
- Обеспечение автоматизированного тестирования (functional, security, performance etc) каждого из этапов CD pipeline, а также конфигурация и контроль quality gates для каждого из них.
- Мониторинг кластера для разработки и централизованный сбор логов.
Архитектура EDP представляет из себя набор взаимосвязанных абстрактных компонентов и API для них. С их помощью имплементируются основные функции платформы. Компоненты можно разбить на 3 крупных логических блока:
- Инструменты для организации CI/CD.
- Компоненты для запуска автоматизированных тестов.
- Continuous delivery pipeline, состоящая из произвольного набора stage. В их рамках производится запуск автоматизированных тестов и контроль прохождения посредством анализа quality gates.
Список инструментов для организации CI/CD, их назначение и поддерживаемые имплементации представлены в таблице ниже:
| Компонент | Назначение | Имплементации |
| VCS | Система контроля и управления версиями. Она обеспечивает надёжное хранение в отдельных репозиториях кода приложений, которые добавляются в платформу. | GitLab, Bitbucket |
| IdentityService | Сервис, который хранит данные пользователей EDP, а также роли и привилегии, которыми они обладают в каждом из инструментов. Является сервисом аутентификации пользователей, позволяя делегировать аутентификацию другим IdentityService. | KeyCloak |
| AutorizationServer | Сервер, который управляет правами пользователей, обеспечивая центральный и первичный источник информации IdentityService. В IdentityService полученные права или роли преобразуются в те, которые используются в компонентах EDP. | LDAP |
| CorporateSSO | Благодаря этому серверу пользователи могут единоразово ввести пароль и получить доступ ко всем зарегистрированным ресурсам в соответствии со своими привилегиями. | ADFS |
| CodeReview | Основной компонент для валидации исходного кода. Все изменения участниками команды в репозиториях своих приложений проходят через Code Review процесс. Помимо ручного шага (выполненного лидером команды, например), включает в себя также автоматизированные шаги (проверка компилируемости, запуск unit тестов и т.д.)
EDP определяет набор привилегий для CodeReview, посредством которых можно разграничить возможности членов команды по управлению изменениями в исходном коде. Например:
| Gerrit |
| CICDServer | Центральный компонент для исполнения различного рода задач, связанных с жизненным циклом разработки. | Jenkins |
| СodeAnalyzer | Анализатор статического кода. Позволяет контролировать его качество с точки зрения различных quality attributes (maintainability, security и т. д). Это происходит на основании сконфигурированных правил и порогов (quality gates). Такой инструмент также позволяет анализировать исторические данные и понимать тренд по изменению качества кода. | SonarQube |
| ArtifactsStorage | Хранилище всех «бинарных» артефактов (jar, zip и т. д.) которые создаются CI сервером во время запуска pipelines на основании событий из CodeReview или VCS. | Nexus |
| DockerStorage | Хранилище для docker images, которые создаются | Docker Registry |
| BinaryPackager | Инструменты для создания «бинарных» артефактов из исходного кода. | Maven, NPM |
| DockerPacager | Инструменты для создания docker images на основании «бинарных» артефактов. | OpenShift Source to Image |
| Cockpit | Инструмент EDP, позволяющий добавлять приложения и автоматизированные тесты для них из существующих репозиториев и интегрировать их в инструменты перечисленные выше. | EDP custom tool |
| CentralizedLogging | Хранилище для логов из всех запускаемых приложений в OpenShift, включая инструменты самого EDP. | EFK |
| Monitoring | Инструмент для мониторинга cluster nodes и dockers, запускаемых в кластере. | Prometheus |
Диаграмма ниже представляет собой логический дизайн EDP на базе описанного выше набора инструментов:
Как видно из таблицы и диаграммы выше, EDP опирается на известные и широко применяемые opensource инструменты, посредством которых обычно строят CI/CD на большинстве проектов. Основной added value EDP — это стандартизация API по интеграции и взаимодействие этих инструментов как во время инсталляции платформы, так и при ее использовании. Основная цель — предоставление точек расширения для пользователей EDP и возможности замены компонентов, которые входят в платформу. Рассмотрим более конкретные примеры. Как уже было сказано выше, EDP выделяет два основных вида API:
- Integration. Каждый инструмент необходимо установить в платформу, сконфигурировать, интегрировать в SSO. Поэтому базовые функции такие:
install()configure()integrateWithSSO()
uploadEdpQualityProfiles()registerCIServerFunctionalUser()
- Runtime. После установки платформы пользователи могут добавлять свои приложения и конфигурировать для них CD pipeline. Эти возможности составляют вторую часть API, которую EDP предоставляет для описанных инструментов. Из наиболее понятных примеров можно привести следующие:
- CodeReview:
registerNewApplication(), который позволяет зарегистрировать новое приложение и осуществлять процесс code review.
- CICDServer:
registerFeatureBranchPipeline(), который обеспечивает добавление CI pipeline для запуска на каждый commit в feature branch.registerPullRequestPipeline()регистрирует pipeline для каждого добавленного приложения, который отвечает за его сборку после подтверждения pull request.addStageToPipeline()позволяет добавить новый stage в CD pipeline, обеспечивая механизм автоматического промоушена между stage.
Схематично компоненты EDP и их API можно представить в виде следующей high-level диаграммы:
Выше была затронута тема CI/CD pipeline, рекомендуемую EDP, которую можно представить следующим образом:
Как видим, EDP выделяет два основных этапа для CI:
- интеграция и проверка кода, который создаётся в feature branch;
- интеграция, проверка и сборка кода после сабмита pull request.
EDP поддерживает возможность не только интеграции кода на двух описанных выше этапах, но и их установки на временные environments. Последние доступны либо конкретному разработчику, либо команде. Стоит отметить, что такой подход к разработке может оказаться достаточно ресурсоемким с точки зрения инфраструктуры. Поэтому рекомендацией по умолчанию от EDP является использование ограниченного количества environment, куда производится deploy последних версий приложений и осуществляется контроль их качества. С одной стороны, это экономит ресурсы инфраструктуры с другой стороны — уменьшает так называемый «integration hell». По умолчанию EDP рекомендует следующий набор shared environment для основной ветки разработки:
Где
- SIT — System Integration testing — этап, на котором рекомендуется запуск автоматизированных тестов.
- QA — Quality Assurance — этап, на котором осуществляется верификация новой функциональности разрабатываемых приложений.
- UAT — User Acceptance testing — этап для демонстрации приложения конечным пользователям и предоставление им возможности самостоятельно поработать с новой функциональностью.
Для каждого из этапов осуществляется deployment всех приложений на выделенный environment. После успешного deployment осуществляется запуск автоматизированных тестов, настроенных для этого этапа и контроль quality gates. Схематично pipeline можно представить в виде следующих высокоуровневых шагов:
Отдельного внимания заслуживает EDP Cockpit, который представляет из себя web-интерфейс для Runtime API EDP. Cockpit позволяет осуществлять добавление новых приложений, конфигурировать последовательность этапов для CD pipeline, определять, какие автоматизированные тесты запускать на том или ином этапе и т. д. Работа с Cockpit начинается с прохождения wizard, который позволяет настроить EDP под конкретные нужды:
Далее можно добавить приложения, платформенные сервисы и проекты с автотестами:
Завершается работа wizard конфигурированием CI/CD Pipeline:
Давайте подытожим, что же получает пользователь EDP после установки в OpenShift кластер:
- Интегрированный набор CI/CD инструментов с настроенным SSO, централизованной аутентификацией и авторизацией. Это облегчает доступ конечных пользователей к ресурсам платформы и позволяет гибко контролировать уровень этого доступа.
- Исходный код EDP с возможностью его кастомизации под нужды проектов.
- Быстро добавлять исходный код приложений и проекты с автоматизированными теста посредством Cockpit.
- Настраивать CD pipeline, управлять набором автоматизированных тестов, запускаемых на каждом этапе, а также назначать quality gates для обеспечения контроля качества.
- Инструменты для централизованного сбора логов и мониторинга.
Более того, несколько экземпляров EDP могут быть проинсталлированы в один OpenShift кластер, что позволяет разрабатывать несколько проектов на одной инфраструктуре.
Что сейчас и что дальше
EDP сейчас уже не просто внутренняя инициатива EPAM. Теперь это платформа, на которой имплементировано несколько проектов и начинаются новые. Один из них предполагает размер команды до 100 человек с различной экспертизой, что повышает уровень сложности и ответственности настройки платформы. AWS и Azure являются Cloud Provider для этих проектов, а потому команды EDP получают важный опыт по управлению кластерами OpenShift в public cloud в соответствии с последними рекомендациями Red Hat.
Естественно, команда EDP не планирует останавливаться на достигнутом. Наши следующие шаги:
- Добавление новых инструментов, которые реализуют API компонентов EDP.
- Более тонкая настройка pipeline на этапе их добавления.
- Расширение списка поддерживаемых технологий для разработки и framework.
- Более тесная интеграция c managed services of public clouds.
- Развитие инфраструктуры и конфигурации кластера OpenShift для соответствия самым строгим security стандартам.
- Интеграция серверов для хранения и анализа результатов performance и security тестирования и многое другое.
Важным моментом развития EDP является внедрение этой платформы для проектов, которые разрабатываются в рамках EPAM RD (Resource Development). Это позволяет молодым специалистам сразу привыкать к самым высоким стандартам разработки кода на современных проектах.
Спасибо вам за внимание и прочтение данной статьи. На возникшие вопросы по мере сил постараюсь ответить в комментариях :)
- CodeReview:
