Привет, Хабр! Меня зовут Дмитрий Гоголев, я занимаюсь развитием платформы управления виртуальной и облачной инфраструктурой Cloudlink и направлением частного облака Orion Private Cloud (OPC) в Orion soft. Многое в ИТ-инфраструктуре можно сделать своими руками. Чем больше вы занимаетесь этим, тем лучше понимаете, как это сделать… но иногда легче все-таки с автоматизацией. 

В большинстве случаев у DevOps уже есть набор инструментов автоматизации. Практически все используют Ansible и Terraform или их аналоги для создания окружений. Многие переходят на IaC. Проблемы начинаются в крупных, иногда распределенных инфраструктурах. При отсутствии централизованной платформы, которой могут пользоваться не только сами инженеры, приходится тратить значительное время на согласования, ручные операции и разбор инфраструктурных ограничений. При отсутствии единого каталога типовых сервисов, включающего ВМ, Kubernetes-кластеры, namespaces, хранилища, сети, шаблоны окружений, создание окружения может занимать дни или недели, потому что требует ручных согласований.

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

Создание и поддержка окружений 

Любой DevOps-инженер уже имеет необходимые для развертывания окружений инструменты. Но в большинстве случаев воспользоваться ими может только он сам. Даже если у вас уже внедрена практика «инфраструктура как код», обучить пользователей работать, например, с Terraform будет непросто. В результате на поддержку существующей инфраструктуры уходит достаточно много времени. С этой точки зрения преимущество работы с частным облаком в том, что выдача нужных рабочих сред может происходить вообще без участия DevOps.

Через веб-интерфейс можно «накликать» готовый стенд ровно в 4 этапа. В такое окружение в случае Orion Private Cloud входит сам zVirt Hosted Engine, система аутентификации Keycloak с возможностью параметризации, а также отдельное хранилище с NFS-томами и кластер Nova Container Platform. Пользователь может кастомизировать этот набор, а может и не делать этого. Если инфраструктура типовая, то DevOps может так настроить стандартные параметры, чтобы она подходила практически каждому пользователю.

Если нужно создать что-то отличающееся от стандарта, процесс по-прежнему будет простым. Достаточно нажать кнопку «добавить» и указать название кластера, определить количество хостов. Этого уже достаточно, чтобы запустилась готовая рабочая среда с новым кластером, двумя хостами и доменами хранения. 

Единый контур для управления всеми средами виртуализации и контейнерами

DevOps-инженеры могут самостоятельно создать единое окно для работы со своими ресурсами. Но когда речь идет о масштабных инфраструктурах, в которых работают несколько сред виртуализации, legacy-приложения, базы данных, middleware, микросервисы, тестовые стенды и инфраструктурные компоненты, процесс управления начинает отнимать все больше времени и ресурсов. 

В Orion Private Cloud для решения этой задачи была создана консоль управления, а также графический интерфейс. И если даже вам удобнее управлять конкретной средой в режиме «инфраструктура как код», единый UI позволяет получить комплексный обзор всего, что есть в облаке, и быстрый доступ к инструментам управления параметрами.

Квоты и контроль потребления

Выше уже было сказано, что автоматизация для потребителей ИТ-ресурсов снижает нагрузку на инфраструктурные команды и делает процесс получения окружений прозрачным. Но на практике это не всегда дает DevOps-инженерам снять с себя часть ноши и заниматься другими делами. Ведь разработчики могут и ошибиться: заказать ВМ не в той сети, поставить лишний ноль к количеству CPU — предсказать все вероятные ошибки невозможно. Можно создать систему контроля на базе самой виртуализации, но это будут костыли, которые как минимум сложно поддерживать. 

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

В Cloudlink можно выделить квоту на организацию и назначать квоты отдельно конкретным пользователям. Terraform не позволяет сделать такое разделение настолько просто. Можно назначать лимиты, но нельзя делать это гибко. Если в разных проектах предусмотрены различные квоты, DevOps’ам будет тяжело поддерживать такой код. Придется заводить справочники, реализовать разделение.

Видим, что есть 2 разных проекта: Example и Sample.

В проекте Example доступен сетевой сегмент Example Network. Никакой другой выбрать нельзя.

Форма заказа со второго проекта, там уже недоступна сеть Example, но есть Sample.

За счет нативного управления проектной иерархией в Cloudlink не страшно, если кто-то ошибся или набрал себе лишнего специально. Инфраструктура не даст получить эти ресурсы. И если раньше нужно было валидировать и проверять, что происходит с квотами, в OPC это не допускается на уровне системы. Пользователь может и сам посмотреть, что ему доступно, потому что все квоты прозрачны. 

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

Инфраструктура как внутренний продукт

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

В случае с частным облаком ситуация упрощается. Если кому-то нужен стенд — не нужно искать существующий или развертывать его самостоятельно. Внутри Cloudlink, например, уже есть модуль, который из коробки умеет оперативно развернуть нужную инфраструктуру. То есть каждый сотрудник, имеющий на то квоту, может получить из маркетплейса нужную инфраструктуру. В итоге DevOps переходят от формата, когда нужно обрабатывать заявки и согласовывать их вручную, к формату, когда пользователь идет и делает. А инженеры инфраструктуры фактически переходят к модели «мы предоставляем внутренние продукты и сервисы».

Все в одном продукте

Безусловно, большинство DevOps-инженеров имеют достаточно квалификации, чтобы собирать автоматизированные системы на базе Open Source решений. Однако это требует большого количества сил и ресурсов. Если руководство хочет получить «маркетплейс из коробки», а также удобный инструментарий для создания новых продуктов, придется провести большую работу. Мне пока что известно только одно решение, подходящее для этой задачи. Оно называется Cozystack, но этот продукт вышел только в 2025 году. Крупных инсталляций пока нет, а инженеры, работающие с масштабными инфраструктурами, как правило не хотят полагаться на еще не проверенный Open Source — то есть оставаться без поддержки, референсов в разных сферах и на больших масштабах. 

Плюс Orion Private Cloud в том, что мы поддерживаем трехсущностную организационную структуру. Мы работаем с организациями, папками и проектами. Соответственно, в рамках организации может быть любое количество проектов.

В OpenStack, например, проекты разделены полностью. И если в департаменте есть несколько проектов, они будут полностью изолированы. Если вы в какой-то момент хотите централизовать управление или хотя бы мониторинг, это становится проблемой. В случае с частным облаком папки позволяют объединять облачную ИТ-инфраструктуру на уровне отделов. А это значит, что проекты могут разворачиваться в одном и том же контуре.

Заключение

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

Фактически все это достигается за счет работы zVirt, Cloudlink и Nova Container Platform не как трех отдельных продуктов, а как единой среды. Намного меньше ресурсов и сил уходит на развитие ИТ-инфраструктуры, управление ей и поддержку. В результате преимущества от корпоративного облака получает не только бизнес, который мыслит категориями «сделать больше при меньших затратах», но и те, кто непосредственно работает с инфраструктурой.