Сложная ИТ‑инфраструктура неизбежно вызывает множество проблем: нужно обеспечивать её масштабируемость и работоспособность, сдерживать рост затрат на сопровождение и поддержку, повышать прозрачность использования инфраструктуры и работающего на ней ПО.

Привет, Хабр! Меня зовут Юрий Самойлов, я директор по продукту MWS B2B Store. Сегодня поговорим о том, как управлять сложными инфраструктурными и ИТ‑ландшафтами в целом, обсудим проблемы стандартизации, упаковки и развёртывания ПО, а также вопросы контроля лицензий, в том числе уже приобретённых у разных вендоров. Кроме того, мы посмотрим, как эти задачи решаются в MWS.

За помощь в подготовке материала спасибо Евгению Тетенчуку, техлиду команды MWS B2B Store. Эта статья — текстовая версия вебинара.

Вызовы при сложном ИТ‑ландшафте

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

В «лоскутном» ИТ‑ландшафте сложно обеспечивать прозрачность затрат на ПО. При закупке софта или лицензий ИТ‑директорам и финансовым руководителям важно понимать, насколько полно используется приобретённый продукт, задействованы ли все оплаченные лицензии или их число избыточно. Типичная ситуация: куплена лицензия на 1000 пользователей, а фактически работают только 500.

MWS B2B Store представляет собой комплексную платформу для управления различными типами инфраструктуры и ПО, включающую функциональность маркетплейса с open‑source‑решениями, PaaS‑сервисами, а также платными продуктами от российских разработчиков.

Платформа поддерживает широкий спектр гипервизоров. В ИТ‑ландшафте заказчика могут одновременно присутствовать несколько технологических стеков: OpenStack, VMware, Proxmox, кластеры Kubernetes. Возможна также работа с одним типом гипервизора, развёрнутым в нескольких инсталляциях: например, несколько независимых сред VMware под управлением vCenter без vCloud Director.

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

MWS B2B Store решает вопрос нестандартных кастомных инсталляций. Именно они во многом приводят к росту затрат на эксплуатацию и поддержку ИТ‑ландшафта. Даже такую распространённую систему, как PostgreSQL, можно установить и настроить множеством различных способов. Исключение уникальных конфигураций существенно упрощает управление и эксплуатацию инфраструктуры. При стандартизованных сервисах, упакованных единым и понятным образом, тратится значительно меньше времени на разбор инцидентов и проблем.

В нашем маркетплейсе можно запустить множественную инсталляцию софта, чтобы развернуть готовый стенд из нескольких типовых продуктов. Сам MWS B2B Store построен по принципу Everything is an API, поэтому платформа предоставляет полный API‑интерфейс, который позволяет запускать множество инсталляций, включая связанные. Например, если для какого‑то софта требуется зависимый сервис в виде PostgreSQL, можно сначала развернуть СУБД, а затем — целевой продукт, например MWS Tables, при установке on‑premises.

Цели упаковки ПО

MWS B2B Store стандартизирует упаковку ПО за счёт четырёх базовых принципов.

1. Выразимость

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

2. Вариативность

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

3. Формализуемость

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

Стандартный бандл включает:

● описание продукта в формате YAML: информацию о самом продукте, данные о его планах и их параметрах;

● описание развёртывания на бэкенде для каждого плана.

└── <имя_бандла>

├── static # Папка со статичными данными продукта

│ ├── description.md

│ ├── eula.pdf

│ ├── icon.png

│ ├── license.pdf

│ ├── support.md

│ └── tutorial.md

├── plans # Папка с планами продукта

│ ├── <имя_плана_1> # Техническое имя плана

│ │ ├── static # Статичные данные плана

│ │ │ └── description.md

│ │ ├── manifest # Папка с манифестами Terraform

│ │ │ ├── main.tf

│ │ │ └──...

│ │ ├── backends.yaml

│ │ ├── parameters.yaml

│ │ ├── plan.yaml

│ │ ├── wizard.yaml

│ │ └── billing.yaml # Создаётся, если для работы с продуктом требуется лицензия

│ ├── <имя_плана_2>

│ │ └──...

│ └──...

├── artifacts.yaml

└── product.yaml

4. Гибкость

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

Функции MWS B2B Store

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

Описание продукта неразрывно связано с тем, что непосредственно устанавливается: образами виртуальных машин, Docker‑образами, Helm‑чартами и сопутствующими файлами. Хранение этих артефактов также обеспечивает MWS B2B Store.

Следующий основополагающий компонент — разворачивание сервисов, — который в платформе называется Terraform as a Service (TaaS). TaaS отвечает за установку ПО на целевую инфраструктуру: позволяет разворачивать виртуальные машины, деплоить Kubernetes‑кластеры и поды на них.

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

Взаимодействие сервисов

Вендор загружает бандл и соответствующие артефакты в MWS B2B Store, где эти сущности распределяются по нескольким компонентам:

• в Catalog сохраняется метаинформация, описывающая сам продукт, порядок его установки и содержащиеся в нём планы;

• в Artifactory сохраняются артефакты для дальнейшего использования: образы виртуальных машин, Docker‑образы, Helm‑чарты и так далее;

• в TaaS сохраняются инструкции Terraform для последующего выполнения.

Далее пользователь выбирает из каталога необходимый продукт и инициирует установку. В этот момент Artifactiry загружает артефакт (в примере образ виртуальной машины для VMware Cloud Director) в целевую среду. Во время разворачивания виртуальной машины на неё устанавливается агент, который напрямую взаимодействует с Provisioner и получает от него инструкции по дальнейшим действиям: донастройке продукта, применению параметров, заданных пользователем в мастере установки, и так далее

В итоге у пользователя появляется виртуальная машина с развёрнутым продуктом и установленным агентом, а в Cloud Director размещён артефакт, который при повторных установках уже не будет скачиваться заново.

MWS B2B Store со стороны вендора

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

В разделе Продукты, кликнув на Demo k3s, можно посмотреть статус продукта.

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

Выбрав один из планов (Single), откроем параметры настройки инфраструктуры. Параметры не зашиты жёстко в платформу — вендор самостоятельно описывает, как выглядит мастер установки, какие поля в нём используются и какие параметры запрашиваются у пользователя.

Дополнительная возможность — использование датасорсов. Можно выбрать бэкенд и динамически подтягивать из него актуальные данные: например, список доступных сетей, в которые будет развёрнуто ПО.

Аналогичным образом устроено и демо для Kubernetes, но под капотом задействуются другие провайдеры, необходимые для развёртывания кластера. Для продукта также доступна карточка с описанием, планы установки и параметры, задаваемые при развёртывании. В описании продукта можно использовать изображения, ссылки и другие артефакты, чтобы пользователю было проще понять назначение продукта и способы работы с ним.

Раздел Инстансы в нашем примере пустой — вендор ничего не развернул.

Артефакты хранятся в отдельном сервисе Artifactory и могут быть представлены в различных форматах: zip‑архивах, Docker‑образах, Helm‑чартах или сырых файлах, необходимых для установки. В текущем примере в Artifactory размещены zip‑файлы, используемые для развёртывания кластера Kubernetes.

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

В разделе Бэкенды в качестве целевых сред могут использоваться Kubernetes‑кластеры, OpenStack или VMware Cloud Director. После создания бэкенда ни пользователям, ни вендорам недоступно его редактирование, за исключением изменения названия. Такое ограничение исключает несанкционированное изменение параметров.

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

MWS B2B Store со стороны пользователя

Теперь перейдём к демонстрации пользовательской части платформы. В данном случае представлен администратор организации Webinar Demo. Организация является верхнеуровневой структурой и может содержать несколько отдельных проектов.

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

В разделе Проекты можно создать свой проект.

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

Далее перейдём в раздел Каталог, где представлены реальные проекты. Сейчас в конце списка проектов появился наш Demo k3s. Каталог полностью кастомизирован: мы можем добавлять или убирать решения в зависимости от потребностей заказчика.

В карточке проекта Demo k3s доступна практически та же информация, что мы видели со стороны вендора.

Также работает подгрузка данных из бэкэнда.

И в карточке Demo Kubernetes информация представлена аналогично тому, как это выглядит у вендора.

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

В разделе Инстансы отображается, что развёрнут кластер k3s и продукт Demo Kubernetes. Просто установить продукт недостаточно — платформа должна предоставлять информацию о нём: текущее состояние, метрики, параметры установки и другие данные, необходимые для дальнейшего управления и эксплуатации.

В разделе Об инстансе доступна информация об используемых бэкендах Demo k3s. Если для продукта предусмотрены лицензии, они также отображаются здесь. Дополнительно в карточке инстанса представлено описание самого продукта.

Если в процессе развёртывания Terraform‑скрипт опубликовал какие‑либо значения через output‑параметры, они также будут доступны в карточке инстанса (раздел Доступы). При этом секретные данные, помеченные в Terraform как sensitive, не отображаются в открытом виде.

Параметры, с какими развёрнуто наше приложение.

В разделе Мониторинг отображаются базовые параметры, собираемые агентом: загрузка процессора, использование памяти, использование swap и другие показатели. Глубина хранения метрик — один месяц.

В разделе Ресурсы можно посмотреть, какие ресурсы были задействованы и созданы в процессе развёртывания с помощью Terraform. Это справочная информация, позволяющая понять, что именно происходило во время развёртывания. Каждый элемент на схеме представляет собой ресурс Terraform. Данные подтягиваются динамически из планов развёртывания.

По клику на карточку ресурса можно получить больше информации.

Для Demo Kubernetes аналогично доступна информация об инстансе.

С какими параметрами развёрнут сервер.

Раздел мониторинга в целом похож на представленный для Demo k3s, но имеет свои особенности. Здесь отображаются нагрузка на CPU, использование памяти, дисковые операции, сетевой трафик, а также ошибки, которые предоставляет Summary API Kubernetes.

В разделе Ресурсы отображается перечень объектов, созданных в процессе выполнения Terraform‑инструкций.

Логи аудита

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

Управление лицензиями

Процесс состоит из трёх шагов.

На первом шаге вендор создаёт лицензию в определённом формате, указывая её название, тип и условия:

• временная — ограничена сроком действия;

• количественная — рассчитана на определённое число пользователей или инсталляций;

• безлимитная — разрешает все действия.

Вендор также задаёт уникальный идентификатор SKU, который в дальнейшем используется внутри его продукта для проверки прав.

На втором шаге вендор публикует лицензию в MWS B2B Store.

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

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

Обзор интерфейса

В разделе Лицензии администратор может просматривать все доступные лицензии с указанием их типов и уровней:

• нераспределённые — находятся в свободном состоянии и пока никому не выделены;

• свободные — выданы определённым группам или проектам и готовы к использованию;

• используемые — закреплены за конкретными продуктами и в данный момент кем‑то применяются.

Дополнительно предусмотрены фильтры по типу лицензий: безлимитные и поштучные.

Со стороны пользователя управление лицензиями реализовано в разделе Лицензии в навигационной панели слева. В нём отображаются лицензии, доступные конкретному проекту внутри организации. В текущем примере имеется безлимитная лицензия сроком на 365 дней, выданная на весь маркетплейс, то есть доступная любому проекту в MWS B2B Store. Кроме того, показаны две лицензии, выданные исключительно на определённый бэкенд. Использовать их можно только при выборе соответствующего бэкенда.

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

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

Заключение

MWS B2B Store позволяет централизованно управлять софтом в сложной распределённой ИТ‑инфраструктуре, снижать затраты на сопровождение за счёт стандартизации упаковки и развёртывания продуктов, обеспечивать полную прозрачность использования лицензий по модели FinOps и управлять как open‑source, так и платными решениями.

Платформа поддерживает мультигипервизорные среды, автоматизирует деплой через Terraform as a Service, предоставляет мониторинг, журнал аудита и гибкое распределение лицензий по проектам и бэкендам.

По ссылке вы можете разместить свой B2B‑продукт в нашей экосистеме.