Привет, Хабр. Я Михаил Фучко, технический продакт-менеджер SDN и Terraform в команде zVirt. Я продолжаю серию статей о пути, который мы проделали в процессе разработки собственного провайдера инфраструктуры для Terraform. В предыдущей части мы поговорили о принципиальных причинах неудач и проблем открытого провайдера terraform-provider-ovirt, сделали выводы. Пятая статья цикла будет посвящена ключевым решениям, принятым в ходе разработки собственного закрытого провайдера инфраструктуры zVirt для Terraform. Эта статья может быть полезна всем, кому предстоит разработка провайдера под специфичный API, слабо совместимый с концепциями Terraform. Мы разберем основные архитектурные решения, обозначим сознательные концептуальные ограничения и приведем пример построения не самой тривиальной «системы поверх системы» для улучшения пользовательского опыта.

Всем привет! Меня зовут Никита Векессер, я занимаюсь продуктами в области AI-инфраструктуры.

За последний год большие языковые модели в enterprise прошли короткий, но заметный путь: от экспериментов в отдельных командах до интеграции в рабочие процессы. ИТ-команды поднимают локальные модели, бизнес-пользователи ходят в облачные сервисы, разработчики подключают AI-агентов к IDE, а внутренние продукты начинают использовать LLM как часть своей логики.

Именно под эту задачу мы делаем StarGuard AI — шлюз безопасности для больших языковых моделей.

Всем привет! Меня зовут Дима Матушкин, я инженер в команде Nova и занимаюсь развитием Nova AI.

В этой статье разберем одну из задач, с которой сталкивается почти любая команда, запускающая AI/ML-нагрузки в Kubernetes: как эффективно использовать GPU в кластере, где одновременно живут инференс, обучение, эксперименты, ноутбуки дата-сайентистов и batch-задачи.

На старте кажется, что достаточно установить NVIDIA GPU Operator, прокинуть видеокарты в Kubernetes и начать указывать nvidia.com/gpu в манифестах. Для простых сценариев этого действительно хватает. Но как только нагрузок становится больше, а GPU начинают конкурировать между собой, выясняется, что проблема не только в том, чтобы "выдать видеокарту" конкретному поду.

Нужно уметь запускать связанные поды как единое целое, управлять очередями, учитывать приоритеты, не ломать распределенные задачи из-за сетевой топологии и делить GPU так, чтобы дорогие ресурсы не простаивали. Обычный планировщик Kubernetes не закрывает эти сценарии комплексно, поэтому для Nova AI мы начали смотреть в сторону специализированных планировщиков для AI/ML нагрузок.

Разработка безопасного программного обеспечения — одна из самых распространенных тем, связанных с ИБ, в 2026 году. Вокруг нее мы все чаще слышим слова «управление секретами», «безопасная доставка секретов» и т.д. Мы уже писали практическую статью тут, но, как показывает практика, системы управления секретами не крутятся только вокруг key-value значений или динамических секретов для database. Я Руслан Гайфутдинов, ведущий пресейл-инженер системы управления секретами StarVault в Orion soft. В этой статье предлагаю рассмотреть еще один (не забытый, а, скорее, не известный) механизм секретов LDAP. 

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

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

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

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

Меня зовут Даниил Рахновский, я ведущий архитектор в Orion soft. В этой статье мы поговорим о том, почему опасно доверять секреты контейнерам, рассмотрим, как упорядочить работу с секретами в Kubernetes с помощью системы управления секретами и какие встроенные инструменты в этом помогают.

Привет, Хабр! Меня зовут Антон Фоломкин, я SDET-инженер в Orion soft. В этой статье я хочу поделиться опытом формирования экспертизы в тестах, которая называется SDET. Проблема качественного тестирования стоит сегодня достаточно остро. Все мы видим сырые продукты, невыловленные баги в привычных приложениях, и часто даже размышляем: «А стоит ли вообще обновляться?». Подобная ситуация сложилась потому, что старые практики тестирования перестают работать в новых условиях. 

Наша компания занимается различными инфраструктурными продуктами — создаем решения для виртуализации, терминального доступа, контейнеризации, управления виртуальной и облачной инфраструктурой, работы с ML/AL. Разрабатывать все это безумно интересно, но долго и сложно. Релизный цикл в среднем составляет полгода, и это значит, что перед выходом каждой новой версии необходимо провести ее комплексное тестирование. Учитывая нарастающую сложность продуктов и их связей между ними, мы решили выращивать в компании тестировщиков нового типа. В этой статье я расскажу подробнее о том, как мы помогаем ребятам становиться SDET-инженерами и что из этого получается.

Привет, Хабр. Я Михаил Фучко, технический продакт-менеджер SDN и Terraform в команде zVirt. Я продолжаю серию статей о пути, который мы проделали в процессе разработки собственного провайдера инфраструктуры для Terraform. В предыдущей части мы честно попробовали воспользоваться опенсорс-провайдером Terraform для oVirt и получили неоднозначные результаты (на самом деле вполне однозначные).  

Эта статья посвящена анализу провала проекта terraform-provider-ovirt. Посмотрим на принятые решения, поищем первопричину, оценим, как надо и как не надо делать, и выработаем основные концептуальные решения перед реализацией своего провайдера. 

Эта статья может быть полезна всем, кому предстоит написание своего Terraform-провайдера. Работа с унаследованным API, попытки натянуть одну модель управления ресурсами на абсолютно другую и необходимость предусматривать гораздо больше, чем изначально вложено в систему — все это погубило terraform-provider-ovirt и всего этого следует опасаться любому разработчику подобного решения. 

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

В Nova Container Platform для таких задач развивается Cluster Manager: он показывает список кластеров, хранит часть параметров и позволяет запускать операции через интерфейс и API.

Меня зовут Семен Месилов, я технический лидер Nova Container Platform. В статье расскажу, как мы подошли к этой задаче, и что уже получилось сделать в Cluster Manager.

Привет, Хабр! Меня зовут Дмитрий Гоголев, я директор по развитию платформы для управления виртуальной и облачной инфраструктурой Cloudlink в Orion soft. За последний год это решение прошло довольно заметную эволюцию. Если раньше это была классическая CMP (Cloud Management Platform) для управления виртуализацией, то сейчас платформа все больше становится универсальным слоем управления инфраструктурой и сервисами — как для on-prem, так и для публичных облаков.

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

Привет, Хабр! При работе с виртуальными машинами нередко возникает необходимость просмотреть или внести изменения в содержимое диска, не запуская саму ВМ. Это может понадобиться для диагностики, восстановления данных или точечной правки конфигурационных файлов. В zVirt такая задача решается несколькими способами: например можно напрямую подключиться к диску виртуальной машины как к блочному устройству и смонтировать его на уровне хост-системы. Это позволяет получить доступ к файловой системе образа без запуска ВМ. Далее рассмотрим основные подходы к тому, как это можно сделать на практике.

Меня зовут Павел Князькин, я системный архитектор в команде zVirt Orion soft. Этот материал мы готовили вместе с моим коллегой Игорем Владимировым, системным инженером из нашей команды. Надеемся, что он окажется полезным для пользователей платформы.

Привет, Хабр. Я Михаил Фучко, технический продакт-менеджер SDN и Terraform в команде zVirt. Я продолжаю серию статей о пути, который мы проделали в процессе разработки собственного провайдера инфраструктуры для Terraform. В предыдущих частях мы разобрали, что же такое Terraform, осознали границу между ответственностью HashiCorp и вендора и сформировали примерный облик решения — провайдера инфраструктуры.  

Третья статья этого цикла будет посвящена обзору достижений (и злоключений) других людей — тех, кто уже попытался привнести IaC в oVirt и не достиг успеха. Что у них получилось? А что не получилось и почему? Ответим на эти вопросы чуть ниже. 

Статья может быть полезна всем, кому предстоит написание своего Terraform-провайдера. Работа с унаследованным API, попытки натянуть одну модель управления ресурсами на абсолютно другую и необходимость предусматривать гораздо больше, чем изначально вложено в систему, — все это серьезно сказалось на terraform-provider-ovirt.

Во многих командах сегодня все выглядит «как положено»: Kubernetes, CI/CD, Terraform, DevOps-команда на месте.

Но по мере роста системы появляется другой эффект: разработка тормозит не из-за кода, а из-за инфраструктуры. Любое изменение проходит через одну точку — DevOps.

И дело не в том, что команда работает плохо. Просто через нее проходит все: задача уходит в очередь, возвращается на доработку и снова ждет. Бизнес давит на скорость, но инфраструктура не успевает.

Привет, Хабр! Меня зовут Павел Лавров, я owner нового продукта в экосистеме Orion soft — GitOps-платформы HyperDrive. И в этой статье я расскажу, почему проблема не в людях и не в инструментах — она в самой модели работы с инфраструктурой. Давайте разберемся, как возникает это узкое место и что меняется, если его убрать.

Привет, Хабр! Я Михаил Фучко, технический продакт-менеджер SDN и Terraform в команде zVirt. Я продолжаю серию статей о пути, который мы проделали в процессе разработки собственного провайдера инфраструктуры для zVirt. В первой части мы определились с терминологией, обсудили основные концептуальные подходы автоматизации и сформировали образ «светлого будущего» — программно-определяемая инфраструктура серверной виртуализации на основе Terraform. Теперь пришло время обсудить проектирование самого решения. 

Начнем с определения — что, собственно, нужно делать?  Поговорим подробнее, что из себя представляет Terraform и где проходит граница ответственности между HashiCorp как изначальным разработчиком ПО и теми, который пишет собственный провайдер.

Эта статья может быть полезна всем, кому предстоит написание своего Terraform-провайдера (или кто об этом задумывается). Мы попытаемся разложить задачу на конкретные модули и получим примерное понимание интерфейса. 

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

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

Меня зовут Михаил Фучко, я архитектор SDN и технический менеджер Terraform-провайдера виртуализации zVirt. В этой серии статей я расскажу о пути, который проделала наша команда в процессе разработки собственного провайдера инфраструктуры для Terraform. Поговорим об успехах и трудностях, о том, всегда ли можно положиться на решение с открытым исходным кодом, и о том, как запущенные десять лет назад «бумеранги» возвращаются, но не тем, кто их запустил. 

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

Со стороны сертификация ФСТЭК России часто воспринимается как преимущественно бюрократический процесс. Но при более близком знакомстве быстро становится понятно: ключевая сложность не в документах как таковых.

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

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

Всем привет! В этой статье я расскажу, как мы запускаем большие языковые модели на Kubernetes-платформе Nova AI. Разобьем материал на две части: сначала посмотрим, с помощью чего это реализовано (архитектура и компоненты), а затем — что это позволяет делать (сценарии использования и практические кейсы).

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

Багбаунти (bug bounty) — это программа денежных вознаграждений за найденные уязвимости. В ноябре 2024 года мы в команде Orion soft запустили такую программу для нашей платформы виртуализации zVirt на площадке Standoff Bug Bounty.

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

Привет, Хабр! Меня зовут Павел Князькин, я системный архитектор в Orion soft, занимаюсь развитием платформы виртуализации zVirt. Сегодня мы поговорим о миграции виртуальной инфраструктуры. 

Миграция с иностранных платформ виртуализации, таких как VMware, HyperV, XEN, а иногда даже и с других отечественных систем виртуализации становится актуальной задачей для многих организаций. Но их останавливают трудности перехода: нужно каким-то образом переместить ВМ из одной платформы виртуализации в другую.

В этой статье я подробно разберу механизмы миграции в zVirt и покажу, что перенести ВМ можно достаточно быстро, удобно и без лишних сложностей. Сравню агентский и безагентский подходы, расскажу, как произвести конвертацию физического сервера в ВМ (P2V) и объясню, почему необязательно платить за миграцию каждой «машины».

Весной этого года NVIDIA открыла исходный код KAI Scheduler — Kubernetes-нативного планировщика GPU-нагрузок, который раньше входил в состав платформы Run:ai и теперь распространяется под лицензией Apache 2.0. Интерес к этому проекту закономерен: планировщик давно работает в продакшене и решает ряд проблем, с которыми сталкивается любая команда, пытающаяся эффективно распределять GPU-ресурсы в кластере.

Мы в Orion soft изучили технические детали KAI Scheduler, чтобы понять, как он устроен изнутри, какие задачи закрывает и какие идеи могут быть полезны инженерам, работающим с Kubernetes, ML-нагрузками и распределёнными GPU-оркестраторами. Ниже — разбор архитектуры, базовых сущностей и цикла планирования.Преимущества KAI Scheduler

Управление AI-нагрузками на GPU и CPU сталкивается с рядом задач, которые традиционные планировщики ресурсов не всегда способны решать. KAI Scheduler был разработан специально для того, чтобы закрыть эти проблемы: