Платформа Цифровых Продуктов Ростелеком. Как это устроено
Датой создания Платформы Цифровых Продуктов (ПЦП) можно считать лето 2017. Старое название - Digital Sandbox, или просто Песочница.
В основе инфраструктуры лежат два тенанта на базе виртуализации OpenStack-KVM, размещенных в независимых ЦОДах Национальной облачной платформы: продуктивный стенд ПЦП на М9, стенд разработки на М10.
Из-за обособленности подразделений общества разработке нужен был инструмент с предварительными интеграциями с основными сервисами и продуктами Ростелекома и возможностью мгновенной организации рабочего места. Таким инструментом и стала ПЦП.
Создание платформы позволило существенно сэкономить время на разработке цифровых сервисов и продуктов, упростив их разработку и эксплуатацию за счет того, что теперь не нужна подготовка инфраструктуры “с нуля”. Появилась возможность легко, быстро и эффективно создавать сайты, веб-приложения, чат-боты, различные интеграционные сервисы, а у команды разработки внутри ПЦП - прототипировать, развёртывать и администрировать приложения без необходимости настройки какой-либо инфраструктуры и технологий. Время предоставления готового стенда сократилось до нескольких часов. Все это помогло сделать ПЦП центром IT ядра Ростелекома.
Сетевой сегмент DMZ-КСПД-НОП позволил нам интегрироваться с системами Ростелекома, что в дальнейшем помогло запускать сервисы, работающие с персональными данными по ФЗ-152.
Благодаря всему этому мы смогли сделать ПЦП оптимальным решением для российского рынка, так как ядро платформы построено на базе Open source с применением технологий OpenShift, Kubernetes, Docker, не требующих приобретения дополнительных лицензий, так как являются свободно распространяемым ПО, на ресурсах НОП с набором готовых к работе сервисов.
Для наглядности приведем пример ниже:
Инструментарий ПЦП позволяет управлять CloudNative-приложениями в едином DevOps-цикле, полностью реализуя технологические практики CI/CD (речь о которых пойдет чуть позже).
Каждый продукт (проект) имеет собственный набор полномочий и лимитов ресурсов на ПЦП, при этом стандартизированы архитектурные требования, правила выделения ресурсов, ролевая модель доступа, подходы к публикации и тиражированию сервисов.
Не стоит забывать, что общие подсистемы сбора метрик и мониторинга обеспечивают как эксплуатацию самой платформы, так и единые стандарты мониторинга каждого экземпляра, сервиса, приложения. Это позволяет экономить ресурсы эксплуатации, так как нет необходимости развёртывания отдельного технологического “обвеса” по сбору метрик и мониторингу под каждый продукт/проект, а также разработки, от которой требуется обеспечить выгрузку своих метрик и логирование сервисов в определенных форматах.
В заключение хотим упомянуть, что в качестве хранилищ данных в проектах применяются СУБД различных типов, определяемых архитектурой конкретного сервиса: RDBMS (PostgreSQL, Oracle), NoSQL (Redis, MongoDB, Elasticsearch, OrientDB, Reindexer, ClickHouse), Time-series (Prometheus). Для продакшн-контуров, как правило, эти хранилища располагаются на отдельных виртуальных машинах. Здесь все зависит от требований бизнеса по части обеспечения доступности и отказоустойчивости сервисов того или иного проекта, а также соответствия принятым в Обществе регламентам информационной безопасности. Звучит занудно, но эту часть нашей кроваво-энтерпрайзной жизни с помощью практик, инструментов ПЦП и чувства юмора мы сводим к минимуму.
Как мы работаем на уровне процессов и инструментов CI/CD
На разных стадиях цикла CI/CD мы применяем специализированные решения, интегрированные в ПЦП, которые обеспечивают автоматизацию процесса:
Разработка, тестирование, отладка
Jira + Confluence - управление требованиями и задачами, база знаний каждого из проектов в ПЦП.
Gitlab - хранение кода и конфигураций, интегрирована с Jira.
Nexus - репозиторий артефактов.
Rundeck - управление build-test-release стадиями.
Gitlab CI/CD, Gitlab Runner - автоматизация процессов CI/CD.
Публикация приложений на стендах
Docker - технология упаковки приложений в контейнеры, исполняемые в средах контейнеризации.
OpenShift - среда публикации и управления контейнеризированными приложениями (Pods на базе docker-образов), сервисами и кластерами.
Эксплуатация
Graylog, Sentry - сбор и анализ логов и ошибок, аудит событий.
Prometheus, Zabbix, Grafana - мониторинг.
Широкий спектр решений автотестирования на всех уровнях (например, unit тесты в коде, скрипты автотестов на базе Selenium для UI или тест-кейсов, Jmeter или Gatling для нагрузочных тестов и т. п.).
Общий процесс CI/CD на примере ПЦП выглядит так:
Управление рисками в процессе работ. CI/CD
Непрерывная интеграция (CI)
Обновления в код вносятся регулярно, до нескольких раз в день.
Инструменты CI (GitLab Runner, Rundeck и т.п.) исполняют скрипты автоматической сборки тестирования кода для каждого загруженного в репозиторий изменения.
Сначала проверку проходит новое изменение отдельно (feature-ветки, unit-тестирование и т.п.), после чего, пройдя merge request, оно вносится в код в основную ветку (release), затем тестируется уже целиком (интеграционные тесты, регрессионное тестирование и т.д.).
Непрерывная доставка + Непрерывное развертывание (CD)
Протестированное ПО развёртывается на тестовом, препродуктивном или продуктивном окружении.
CD подразумевает автоматическое развертывание кода (с возможным ручным подтверждением установки релиза) сразу после каждой новой интеграции.
В идеале CD — полностью автоматический процесс, проходящий без контроля со стороны команды, когда в случае неуспешного обновления экземпляра сервиса он откатывается до предыдущего состояния, а кластерные конфигурации обновляются веерным способом, без длительной остановки сервисов. В большинстве случаев пайплайны запускаются автоматически по изменению кода в соответствующей ветке. Однако, для некоторых специфичных кейсов пайплайн на тестовые контуры может запустить вручную сам разработчик или тестировщик из интерфейса Git’а. Для продуктивной среды развёртывание инициируется из интерфейса Rundeck менеджером проекта или тем, кому дали такое право. После этого Rundeck берёт из репозитария Nexus проверенный ранее на тестовых контурах и пре-прода артефакт и выполняет непосредственное его развёртывание. Важно! Сборка кода на данном этапе уже не выполняется.
Виртуализация серверов, контейнеризация приложений и Cloud Native архитектура
В архитектуре решений и CI/CD применяются подходы Infrastructure as Code, Cloud Native, Continuous configuration automation и т.п.
Применяется виртуализация серверного ландшафта как IaaS в частном облаке, включая автоматизацию развертывания ВМ (Ansible, Terraform) и централизованный мониторинг инфраструктуры ВМ.
Приложения (сервисы) упаковываются в docker-контейнеры со всеми локальными зависимостями, сервисы реализуются по принципам Cloud Native.
Контейнеры развёртываются в инфраструктуре OpenShift, или в простых случаях - через docker-compose, swarm и т.п.
Для работы с изменениями в схемах БД может применяться инструментарий автоматизации (Liquibase, Flyway и т.п.).
Принципы архитектуры приложений Cloud Native
Выделим наиболее существенные с нашей точки зрения и опыта:
Разделяем друг от друга приложения с сохранением состояния и без сохранения (Stateless). Каждый запрос атомарен и может быть выполнен любым экземпляром stateless-приложения.
Работаем в кластерной конфигурации с возможностью быстрого тиражирования экземпляров сервиса, маршрутизацией запросов и автообнаружением экземпляров.
Производим конфигурирование сервисов через переменные среды, self API или config maps в OpenShift.
Реализуем конечную точку проверки работоспособности своих сервисов или приложений, чтобы системы контейнеризации и оркестрации могли проверять состояние приложения и реагировать соответствующим образом (пишутся healthcheck’и).
Постоянно публикуются данные логов и телеметрии, которые будут храниться и анализироваться такими системами, как Graylog, Elastic Stack (Elastic+FluentBit), Prometheus.
Интегрируемся с Sentry (как backend-часть сервиса, так и его frontend при его наличии). Важно: с помощью данного инструмента команда разработки плотнее вовлекается в процессы эксплуатации своих сервисов на продуктивных средах.
Корректно обрабатываем ошибки, чтобы система оркестрации могла восстановиться, перезапустив или заменив приложение новой копией.
Не требуем вмешательства человека для запуска и начала работы.
Интеграция Git CI и OpenShift – диаграмма процессов
И для примера пара пайплайнов:
Пайплайн проекта “Система Управления Знаниями” (СУЗ)
Данный пример позволяет посмотреть, как реализован процесс на проекте с препродуктовой средой, находящейся во внешнем периметре. Также проект СУЗ показывает опыт внедрения CI/CD в зрелую легаси-систему с проведением рефакторинга и разделением ядра на компоненты.
Пайплайн проекта “Мотивационно-Обучающий Портал менеджеров продаж Ростелекома”
Данный пример позволяет посмотреть, как реализован процесс на проекте, где пре-продуктовые и продуктовые ветки полностью находятся в периметре ПЦП и управляются командой разработки.
Внедрение процессов CI/CD идет поэтапно, в Ростелекоме разработана универсальная методика и регламент внедрения в проекты и системы любой степени зрелости и состояния. Об этом мы расскажем в следующей и заключительной части наших материалов о продвижении CI/CD & DevOps в Enterprise.
Следите за новостями Ростелеком ИТ!
