«Лаборатория Касперского» объявила о коммерческом запуске в России Kaspersky Vulnerability Management (Kaspersky VM) — программного комплекса, интегрированного с платформой Kaspersky Security Сenter и предназначенного для централизованного поиска и управления уязвимостями в IT-инфраструктуре предприятия. Продукт помогает сократить поверхность атаки, повысить прозрачность активов и снизить нагрузку на службы информационной безопасности.

Kaspersky VM позволяет выявлять и устранять бреши в корпоративной среде, приоритизировать их с учётом реальных рисков, а также автоматизировать процессы исправления и развёртывания патчей. В составе продукта представлены средства автоматического обнаружения устройств, операционных систем и установленного ПО (Windows, Linux), функции оценки соответствия используемых конфигураций стандартам безопасности и регуляторным требованиям, инструменты патч-менеджмента для управления обновлениями Windows и открытый API, с помощью которого можно передавать сведения об обнаруженных угрозах в сторонние SIEM-системы. Решение позволяет использовать существующие агенты Kaspersky Endpoint Security для анализа уязвимостей на рабочих станциях и серверах, а также поддерживает безагентное сетевое сканирование портов и сервисов.

Архитектура Kaspersky Vulnerability Management (источник изображения: kaspersky.ru)

База знаний Kaspersky Vulnerability Management постоянно пополняется и в настоящий момент насчитывает свыше 370 тысяч обнаруженных уязвимостей и более 600 правил для проверки IT-активов на соответствие отраслевым стандартам и внутренним корпоративным правилам кибербезопасности.

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

В планах «Лаборатории Касперского» — расширение функциональных возможностей Kaspersky VM, включение продукта в реестр отечественного ПО и проведение сертификационных испытаний ФСТЭК России.

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

Теперь корректировка цен с учётом обменного курса будет ежегодно производиться 1 января, «за исключением ограниченных исключительных обстоятельств». Уведомления о предстоящей корректировке цен в текущем финансовом году, который начался 1 июля, будут заранее рассылаться партнёрам Microsoft в ноябре. При этом о любых корректировках цен на конкретные продукты и о любых обновлениях цен для потребителей будет по-прежнему сообщаться отдельно. Впрочем, рассчитывать на снижение затрат в резлуьтате

Источник изображения: Praswin Prakashan/unsplash.com

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

РТК-ЦОД, ведущий ИТ-сервис-провайдер полного цикла, сертифицировал инфраструктуру «Облака КИИ» по международному стандарту безопасности данных платёжных карт PCI DSS (Payment Card Industry Data Security Standard). Успешное прохождение сертификации подтверждает готовность платформы к размещению ИТ-систем организаций финансового сектора, ритейла и интернет-торговли.

Благодаря наличию сертификата PCI DSS, возможность размещать свои ИТ-ресурсы в «Облаке КИИ» получили организации, ежедневно обрабатывающие данные платёжных карт. В их число входят платёжные шлюзы, выполняющие маршрутизацию транзакций, платёжные процессоры, обеспечивающие авторизацию и проведение расчётов, а также поставщики платёжных услуг, действующие как агенты и посредники в международных и локальных расчётах. Кроме того, развернуть свои ИТ-системы на платформе могут банки-эквайеры и интернет-площадки, принимающие онлайн-оплаты.

Источник изображения: РТК-ЦОД

Для прохождения сертификации специалисты РТК-ЦОД совместно с аккредитованными аудиторами провели полный цикл инструментальных проверок инфраструктуры «Облака КИИ». Аудит охватил все уровни системы, также был выполнен тест сегментации, подтвердивший изолированность платформы от недоверенной сети, и проведено ASV-сканирование уязвимостей — внешнее сканирование инфраструктуры. Кроме того, были организованы внутренний и внешний пентесты, моделирующие действия реальных злоумышленников. Завершающим этапом стал QSA-аудит — оценка соответствия квалифицированным аудитором платёжной индустрии.

Ранее в этом году РТК-ЦОД подтвердил соответствие инфраструктуры «Облака КИИ» стандарту ГОСТ 57580, регулирующему защиту информации при проведении банковских и финансовых операций. Прохождение сертификации позволило использовать платформу «Облако КИИ» для размещения информационных систем организаций, чья деятельность регулируется Банком России.

«Подтвердив соответствие инфраструктуры "Облака КИИ" стандарту ГОСТ 57580, мы сделали следующий важный шаг и получили сертификат международного стандарта PCI DSS. Это говорит о том, что наша платформа отвечает самым жёстким требованиям безопасности как со стороны Банка России, так и со стороны международной платёжной индустрии. Для наших клиентов из финансового сектора наличие у "Облака КИИ" сертификата PCI DSS означает, что они могут значительно упростить соблюдение нормативных требований, размещая свои ИТ-системы на нашей платформе», — заявил директор по продуктам РТК-ЦОД Александр Обухов.

PCI DSS (Payment Card Industry Data Security Standard) — международный стандарт, устанавливающий требования к обеспечению безопасности данных держателей платёжных карт при их передаче, обработке и хранении.

Европейская комиссия одобрила обязательства SAP по устранению проблем, связанных с оказываемыми ею услугами послепродажной поддержки для локального ПО ERP, которые ограничивать конкуренцию на общеевропейском рынке. Эти обязательства теперь имеют обязательную юридическую силу в соответствии с антимонопольным законодательством ЕС. Ранее компанию неоднократно критиковали за попытки перевести клиентов в облако, лишая пользователей локальных версий поддержки и обновлений, а также стремясь ограничить возможности сторонних разработчиков.

В частности, SAP обязуется уточнить условия разделения услуг SAP клиентам на отдельные части, позволяя им выбирать различных поставщиков услуг технического обслуживания и поддержки (M&S), различные уровни поддержки от SAP или не предоставлять никакой поддержки для каждой части, а также разрешить клиентам расторгать свои лицензии и соответствующие сборы за M&S в следующих конкретных сценариях:

• для продуктов на заключительном этапе M&S, на котором SAP предоставляет сокращённый объём услуг;
• для проектов внедрения с отрицательным результатом, где ответственность за неудачу лежит на SAP;
• в случае неплатежеспособности или банкротства клиентов;
• в случае сокращения численности персонала на 10 % или более в течение двух лет клиенты будут иметь возможность сократить на 10 % свои лицензии и связанные с ними расходы на M&S.

Источник изображения: Guillaume Périgois/unsplash.com

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

Также компания обязуется:

• предоставить больше возможностей заключения договоров с единым показателем, которые обеспечивают альтернативный способ расчёта лицензионных сборов, на основе которых, в свою очередь, рассчитываются сборы за мониторинг и сбыт;
• разъяснить договорные положения относительно первоначального срока действия лицензии, в течение которого клиенты не могут расторгать свои договоры на поддержку, и воздержаться от возобновления действия нового срока действия при каждой дополнительной покупке лицензии;
• отменить плату за восстановление и снизить плату за обслуживание, взимаемую с клиентов, которые возвращаются в службу поддержки SAP после периода отсутствия;
• создать внутреннюю структуру клиринга, к которой клиенты смогут обратиться, если сочтут, что SAP не выполняет свои обязательства должным образом.

В сентябре 2025 года Еврокомиссия начала официальное расследование и предварительно установила, что SAP прибегала к методам, которые могут ограничивать конкуренцию на общеевропейском рынке услуг технического обслуживания и сбыта для локального ERP-программного обеспечения SAP. Еврокомиссия заподозрила SAP в злоупотреблении своим доминирующим положением, поскольку она:

• не допускала прекращения клиентами услуг технического обслуживания и поддержки неиспользуемых лицензий на ПО, что могло привести к тому, что клиенты SAP платили за нежелательные услуги;
• взимала плату за восстановление и повторное техническое обслуживание с клиентов после периода отсутствия. В некоторых случаях эти сборы соответствовали сумме, которую клиенты заплатили бы, если бы оставались с SAP с самого начала;
• систематически меняла первоначальный срок действия локальных лицензий на ERP-системы, в течение которого прекращение услуг технического обслуживания и поддержки было невозможно;
• требовала от своих клиентов обращаться за услугами технического обслуживания и поддержки для всего локального ПО ERP SAP на одинаковых ценовых условиях, что могло помешать им «комбинировать» услуги технического обслуживания и поддержки от разных поставщиков по разным ценам и уровням поддержки, несмотря на то, что это было для них удобнее.

По мнению Еврокомиссии этим SAP могла ограничивать конкуренцию на рынке услуг технического обслуживания и поддержки для локального программного обеспечения ERP SAP, нарушая статью 102 Договора о функционировании ЕС и статью 54 Соглашения о Европейской экономической зоне (ЕЭЗ), которые запрещают злоупотребление доминирующим положением, способное повлиять на торговлю и предотвратить или ограничить конкуренцию на едином рынке.

Обязательства, предложенные SAP, будут действовать во всем мире в течение десяти лет. За их выполнением будет следить контролирующий орган, который будет регулярно предоставлять Еврокомиссии отчёт в течение всего срока действия обязательств. В случае невыполнения обязательств, Еврокомиссия может наложить штраф в размере до 10 % от годового мирового оборота SAP, без необходимости установления факта нарушения антимонопольных правил ЕС, или периодический штраф в размере 5 % от её ежедневного оборота за каждый день несоблюдения обязательств.

«Группа Астра», Axiom JDK и Haulmont сообщили о доступности корпоративной версии отечественной интегрированной среды разработки OpenIDE Pro. Продукт представляет собой альтернативу востребованным в профессиональной среде IDE-инструментам компании JetBrains, которая прекратила продлевать российским пользователям лицензии на своё ПО.

OpenIDE Pro является дальнейшим развитием открытой версии Community Edition, которая была выпущена в апреле 2025 года. В числе особенностей коммерческой редакции среды разработки — расширенная поддержка языков программирования, полный набор функций, техническая поддержка, понятная модель лицензирования и предсказуемость обновлений. Платформа поддерживает Java, Kotlin, Go, JavaScript, TypeScript, Python, PHP и оснащена встроенным DB-клиентом, позволяющим подключаться к базам данных, работать с SQL-консолью, просматривать результаты запросов в табличном виде, визуально редактировать данные и строить диаграммы схемы БД. В настоящий момент поддерживается подключение к СУБД PostgreSQL, MySQL/MariaDB и ClickHouse. В перспективе будет реализована возможность работы с SQLite, SQL Server, Redis и MongoDB.

Источник изображения: openide.ru

В составе Pro-версии OpenIDE также представлен инструментарий для взаимодействия с ИИ-системами и агентами на базе нейронных сетей. С целью расширения функциональных возможностей платформы предусмотрены средства подключения плагинов и соответствующий маркетплейс, насчитывающий свыше 300 программных модулей.

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

Корпоративные лицензии OpenIDE Pro уже доступны для покупки и пилотирования в компаниях. Стоимость лицензии — 45 тыс. руб. на одного разработчика в год. Поддерживается работа в средах Windows, macOS и Linux.

Со следующей недели Microsoft, Google, Amazon и Oracle будут находиться под прямым надзором британских регуляторов после того, как Министерство финансов признало четыре крупнейшие американские технологические группы критически важными поставщиками услуг для британского сектора финансовых услуг. Министерство заявило, что применяет «целенаправленный и соразмерный подход» и что со временем в список могут быть включены и другие компании, «если это будет необходимо для защиты устойчивости Великобритании».

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

Решением британского правительства статус критически важных сторонних организаций с 13 июля присвоен Microsoft Ireland Operations Ltd, Google Cloud EMEA Ltd, Amazon Web Services EMEA SARL и Oracle Corporation UK Ltd. Надзор ними будет осуществляться Банком Англии (BoE) совместно с Управлением пруденциального регулирования (PRA) и Управлением по финансовому регулированию и надзору (FCA).

Право определять компании, предоставляющие жизненно важные услуги финансовому сектору Великобритании, как «критически важных третьих лиц», Министерство финансов Великобритании имеет с января 2025 года. Этот режим позволяет регуляторам предъявлять к поставщикам облачных услуг и ИИ-моделей более жёсткие требования по поводу раскрытия информации, включая проведение ежегодной самооценки и регулярное «сценарное тестирование» своей способности предоставлять критически важные услуги во время серьёзных сбоев, а также необходимость сообщать о крупных инцидентах.

Источник изображения: Chanel Chomse/unsplash.com

Рэйчел Блейк (Rachel Blake), экономический секретарь Казначейства Великобритании, заявила: «Эти определения помогут обеспечить устойчивость критически важных услуг, на которые полагаются финансовые компании, защищая потребителей и предприятия и поддерживая рост экономики в целом», пишет The Financial Times. Вместе с тем финансовые компании по-прежнему будут нести ответственность за управление рисками, возникающими в связи с их сторонними поставщиками. Надзор регуляторов за поставщиками ИТ-сервисов будет ограничен системными услугами, которые они предоставляют сектору.

Регуляторы обеспокоены тем, в какой мере финансовые компании зависят от услуг, предоставляемых на аутсорсинге небольшим числом технологических гигантов, в том числе в области облачных вычислений, хранения данных и ИИ-моделей. Согласно исследованию, проведенному Банком Англии и FCA два года назад, на три крупнейшие группы компаний, предоставляющие ИТ-услуги — Amazon, Google и Microsoft — приходилось 73 % услуг облачных вычислений, предоставляемых британским финансовым компаниям.

Обеспокоенность по этому вопросу усилилась после конфликта Anthropic с администрацией президента США и последующим запретом предоставлять европейским компаниям доступ к своим самым продвинутым моделям Fable 5 и Mythos 5. Подход Великобритании заметно отличается от ЕС, выбравшего в ноябре прошлого года целых 19 поставщиков ИТ-услуг для прямого надзора со стороны регуляторов блока, включая Bloomberg, Accenture, IBM, NTT Data, SAP и Tata Consultancy Services.

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

С материалов исков о принадлежности прав на интеллектуальную собственность на UNIX периодически сдувают пыль, возобновляя тяжбы. С момента первого обращения в суд прошло много времени, но новый истец — компания Xinuos, похоже, не опускает рук, пытаясь призвать к ответу IBM, хотя и не особенно успешно, сообщает The Register.

Альянс, включавший IBM, Santa Cruz Operation (SCO), Intel и Sequent в конце 1990-х сформировали инициативу Project Monterey в попытке создать «унифицированную» версию UNIX, способную работать с разными процессорами. К 2001 году в рамках этого проекта была создана версия платформы, использующая код IBM и SCO. Однако к этому моменту стало понятно, что проект не очень жизнеспособен. В 1999 году IBM купила Sequent, в 2000 году UNIX-бизнес SCO был куплен Caldera Systems и переименован в SCO Group, а Intel была занята не слишком удачной попыткой развития Itanium.

К тому времени Linux уже стал популярным, и IBM решила сделать ставку именно на него. В корпоративной переписке, вскрывшейся в ходе судебных разбирательств, IBM открыто признала, что на практике Project Monterey оказался никому не нужен и никто не готов был его покупать. Компания прекратила участие в Project Monterey и, по некоторым данным, перенесла оттуда часть кода в Linux и собственные ОС AIX и z/OS. SCO, считавшая, что ей принадлежит часть кода, подала на IBM в суд. Хотя положение SCO и её союзников на тот момент было плачевным, заинтересованные стороны не отказывались от иска, поскольку возможность отсудить часть прав на код Linux и ОС IBM потенциально открывало большие финансовые перспективы.

Источник изображения: Docusign/unsplash.com

В итоге компании, после ряда проигранных SCO процессов, пришли к мировому соглашению в 2021 году, по имеющимся сведениям, IBM заплатила истцам $14 млн, не признав своей неправоты. Тем не менее, к тому времени SCO уже продала права на своё ПО компании Xinuos, которая, хотя и обещала ранее не претендовать на связанные с UNIX активы, подала собственный иск против IBM, связанный как с антимонопольными обвинениями в адрес техногиганта (в том числе в связи с покупкой Red Hat), так и с новыми претензиями, касающимися прав на интеллектуальную собственность.

Сообщается, что ещё в 2025 году окружной суд Нью-Йорка отклонил иск, поскольку Xinuos вообще не смогла доказать, что именно ей принадлежат код и права на судебное преследование IBM. Впрочем, истец не смирился и подал апелляцию. 22 июня состоялись слушания, в которых Xinuos утверждала, что вопрос не в принадлежности кода, а в том, что IBM незаконно использовала код SCO без лицензии. Сама IBM считает, что все права у неё имеются, а затронутые в ходе разбирательства вопросы давно рассмотрены.

Ключевой проблемой является то, что Xinuos, вероятно, вообще не имеет прав на какие-либо судебные споры по данному вопросу. Так или иначе, суд рассматривал фактически процессуальные вопросы — правильно ли суд первой инстанции квалифицировал требования относительно Linux и есть ли у компании права действительно продолжать спор. Дело нередко называют «зомби-иском», поскольку оно уже более 20 лет неоднократно признаётся завершённым, но его снова и снова возвращают в суд.

Meta✴ полностью перестроила своё хранилище для ИИ, чтобы предотвратить простой ускорителей. Как сообщает SDxCentral, система, лежащая в основе её операций с ИИ, позволила кратно сократить время, необходимое исследователям для перемещения обучающих данных ИИ между регионами. Согласно опубликованным аналитическим выкладкам, скорость работы имеющихся СХД не поспевала за растущими вычислительными мощностями GPU, которые примерно утраивались каждые два года.

Стремясь устранить этот разрыв и обеспечить поддержку кластеров хранения данных, охватывающих все продукты Meta✴, включая Meta✴ AI, Reality Labs, платформы социальных сетей и потребности потенциальных облачных клиентов, специалисты компании перестроили слой хранения BLOB-объектов (Binary Large Object), работающий поверх её глобальной многопользовательской СХД Tectonic, обслуживающей экзабайты данных.

Загрузка данных на два GPU (Источник изображений: Meta✴)

Компания отметила, что хотя устаревшая архитектура BLOB-хранилищ Meta✴ вполне подходила для веб-приложений, таких как Facebook✴ и Instagram✴, для обучения ИИ она оказалась неэффективной. У неё было слишком много слоёв сервисов, и она должна была выполнять множественные запросы к метаданным на нескольких уровнях, прежде чем определить путь к файлу и его фактическое местоположение в хранилище, что увеличивало задержку и отражалось на производительности.

Прежний алгоритм обработки запросов для API getObject

Перестройка СХД была основана на трёх ключевых изменениях. Во-первых, разрозненная система метаданных была объединена в единую схему, поддерживаемую ZippyDB, что позволило сделать практически мгновенным поиск путей. Во-вторых, были убраны прослойки, не позволявшие передавать байты напрямую с серверов хранения (fat client), что повысило энергоэффективность и снизило задержку. В-третьих, был осуществлён переход от глобальной модели развёртывания к региональной, в рамках которой хранилище данных размещается рядом с GPU, которые в нём действительно нуждаются. Всё это позволило свести к нулю накладные расходы при работе с Tectonic, уложиться в бюджет по энергопотреблению и упростить архитектуру хранения. Более того, Meta✴ задействовала свободную память GPU для распределённого кеша «горячих» данных.

Новый алгоритм обработки запросов для API getObject

Команда воспользовалась опытом разработки Owl — системой дистрибуции больших объектов, которая сочетает децентрализованную P2P-плоскость данных с централизованной плоскостью управления. Специалисты интегрировали логику однорангового обмена из Owl SDK на уровне клиента, что снизило частоту запросов GPU к хранилищу. Также был добавлен отдельный кеш метаданных, который возвращает адреса часто запрашиваемых файлов за 1–2 мс. Это позволило справляться с пиками обращений, например, когда GPU одновременно запрашивают одни и те же «горячие» веса модели, а также улучшить задержку, поскольку данные берутся из памяти, а не с диска.

Эволюция архитектуры загрузки данных

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

Также в Meta✴ решили проблему доставки данных исследователям. Поскольку вычислительные мощности были разбросаны по регионам, сотрудникам регулярно приходилось часами ждать, пока наборы данных будут скопированы и отправлены в конкретный регион мира, где будет выполняться их задача обучения. Для этого была создана многоуровневая система кеширования. RAM и SSD на GPU-хостах выступают в качестве самого быстрого слоя, которые получают данные от региональных флеш-хранилищ BLOB-объектов, куда, в свою очередь, данные попадают из глобальных озёр данных на базе HDD.

Для ускорения используется механизм предвыборки, который заранее загружает данные, которые исследователь собирается использовать. Эта схема уже позволила значительно сократить время загрузки во всех рабочих нагрузках Meta✴. В среднем время загрузки сократилось со 150 мин. до всего 10 мин. (сокращение на 93 %). Meta✴ зафиксировала максимальное сокращение времени загрузки с 89 ч. до всего 182 мин.

Корпорация Microsoft приняла решение продлить выпуск так называемых «горячих» обновлений (Hotpatch) для Windows Server 2022 вплоть до октября 2027 года. Основная поддержка этой программной платформы заканчивается 13 октября 2026-го, тогда как расширенная будет осуществляться до 14 октября 2031 года.

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

Как отмечает The Register, обычно выпуск «горячих обновлений» заканчивается с прекращением основной поддержки программного продукта. Но в случае Windows Server 2022 корпорация Microsoft продолжит доставлять Hotpatch-апдейты дополнительно в течение года.

Источник изображения: unsplash.com / Clint Patterson

Правда, распространение «горячих обновлений» будет осуществляться только для редакции Windows Server 2022 Datacenter: Azure Edition. Это специализированная версия ОС, оптимизированная для запуска в облачной инфраструктуре Microsoft Azure или на локальных узлах Azure Local (Azure Stack HCI). Данная версия платформы предлагает дополнительные облачные функции для повышения надёжности, безопасности и удобства администрирования. Пользователям других модификаций Windows Server 2022 обновления в режиме Hotpatch после 2026 года станут недоступны.

«Базис» (входит в ГК РТК-ЦОД) объявил о выпуске обновления Basis Digital Energy — платформы для управления полным жизненным циклом кластеров на базе Kubernetes.

В выпуске Basis Digital Energy 1.7 были добавлены такие функции, как развёртывание кластеров из пользовательских шаблонов и расширение сценариев работы с гипервизором Basis vCore, а также появилась поддержка управления хранилищем артефактов из веб-интерфейса.

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

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

Источник изображений: «Базис» Сохранённые шаблоны для создания кластера

Особое внимание в релизе уделено обеспечению комфортной работы в закрытых контурах. В веб-интерфейсе Basis Digital Energy был добавлен раздел управления системным хранилищем артефактов iStore, благодаря чему администратор платформы сможет просматривать и редактировать списки образов и helm-чартов, а также отслеживать действия пользователей через журнал операций. Хранилище iStore обеспечивает возможность работы приложений и кластеров Kubernetes без доступа в интернет, гарантируя конфиденциальность при работе в изолированных средах.

Также на Basis Digital Energy с vCore, собственном гипервизоре «Базиса», входящем в единую экосистему продуктов компании, теперь можно как разворачивать саму платформу Basis Digital Energy, так и создавать управляемые кластеры. При создании кластера, а также при добавлении новых узлов и балансировщиков на физических серверах (Bare Metal) теперь можно задавать собственные имена узлов и балансировщиков нагрузки.

Также с выходом Basis Digital Energy 1.7 были расширены возможности по установке приложений. Через новый пользовательский каталог теперь можно устанавливать в кластер собственные приложения из кастомных helm-чартов, помимо набора сертифицированных инструментов. Также в каталог был добавлен APISIX — API-шлюз для маршрутизации, защиты и управления трафиком в кластере Kubernetes.

Пользовательский каталог приложений Basis Digital Energy

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

«По данным аналитиков iKS Consulting, следующие 5 лет сегмент российской контейнеризации будет расти примерно на 25 % год к году, и это одна из причин, почему мы вкладываем значительные ресурсы в развитие Basis Digital Energy. Другая, не менее важная причина — потребность заказчиков в решении для работы с контейнерами как части виртуальной инфраструктуры, включающей также серверные и VDI-решения. Именно поэтому мы развиваем наши продукты как единую экосистему», — сообщил Дмитрий Сорокин, технический директор «Базис».