Первая летняя подборка новостей и релизов уже в эфире DevOps FM!
🟡 Зарелизили VirtualBox 7.1.10
Oracle выпустили VirtualBox 7.1.10, в которой исправили некоторые ошибки и улучшили производительность.
Из интересного:
• Добавлена поддержка Linux 6.15.
• Исправили проблемы с аварийным завершением VBoxManage на хостах Windows и завершением процесса VM Selector на базе Linux
• Исправлена проблема, не позволявшая вставлять данные из буфера обмена в гостевую систему, доступ к которой осуществляется при помощи протокола RDP.
⚫️ В блоге Kubernetes вышла статья о том, как обеспечить корректный порядок запуска контейнеров в поде, когда основное приложение зависит от sidecar-контейнера.
В материале рассматривается, почему даже при использовании нативных sidecar-контейнеров с r
⚫️ Линус Торвальдс распорядился заблокировать учётную запись лидера Ubuntu Security Team
Кеса Кука, одного из главных сторонников Rust в ядре, заблокировали за подмену информации об авторстве коммитов. Поводом стал pull-запрос в Linux 6.16, в котором использовался git-репозиторий с фиктивными изменениями — ряд коммитов в нём значились от имени самого Торвальдса, хотя он к ним не имел отношения.
Торвальдс расценил это как потенциально вредоносную активность и потребовал немедленной блокировки профиля Кука до выяснения обстоятельств. Кес объяснил инцидент неудачным восстановлением репозитория после сбоя SSD и ошибкой в использовании утилиты
Позже автор утилиты
🟡 На TheNewStack опубликовали результаты исследования от Google посвященное зрелости подхода платформенной инженерии и ее влияние на бизнес. Один из ключевых выводов — 65% времени разработчиков тратится на задачи, которые можно устранить с помощью платформенной инженерии — например, настройка инструментов, обновления, поддержка среды и т.д. Ознакомиться с остальными результатами можно здесь.
#devops #linux #kubermetes #platformengineering
🟡 Зарелизили VirtualBox 7.1.10
Oracle выпустили VirtualBox 7.1.10, в которой исправили некоторые ошибки и улучшили производительность.
Из интересного:
• Добавлена поддержка Linux 6.15.
• Исправили проблемы с аварийным завершением VBoxManage на хостах Windows и завершением процесса VM Selector на базе Linux
• Исправлена проблема, не позволявшая вставлять данные из буфера обмена в гостевую систему, доступ к которой осуществляется при помощи протокола RDP.
⚫️ В блоге Kubernetes вышла статья о том, как обеспечить корректный порядок запуска контейнеров в поде, когда основное приложение зависит от sidecar-контейнера.
В материале рассматривается, почему даже при использовании нативных sidecar-контейнеров с r
estartPolicy: Always нельзя гарантировать, что sidecar будет полностью готов до старта основного приложения. Автор показывает, как решить эту проблему с помощью startupProbe, postStart-хуков и других механизмов Kubernetes, чтобы добиться нужной последовательности запуска.⚫️ Линус Торвальдс распорядился заблокировать учётную запись лидера Ubuntu Security Team
Кеса Кука, одного из главных сторонников Rust в ядре, заблокировали за подмену информации об авторстве коммитов. Поводом стал pull-запрос в Linux 6.16, в котором использовался git-репозиторий с фиктивными изменениями — ряд коммитов в нём значились от имени самого Торвальдса, хотя он к ним не имел отношения.
Торвальдс расценил это как потенциально вредоносную активность и потребовал немедленной блокировки профиля Кука до выяснения обстоятельств. Кес объяснил инцидент неудачным восстановлением репозитория после сбоя SSD и ошибкой в использовании утилиты
git-filter-repo в связке с b4 trailers.Позже автор утилиты
b4 подтвердил, что подмена произошла без злого умысла и была следствием некорректного использования утилиты. Доступ Кука к инфраструктуре был восстановлен, а в b4 появится дополнительная проверка, предотвращающая подобные случаи в будущем.🟡 На TheNewStack опубликовали результаты исследования от Google посвященное зрелости подхода платформенной инженерии и ее влияние на бизнес. Один из ключевых выводов — 65% времени разработчиков тратится на задачи, которые можно устранить с помощью платформенной инженерии — например, настройка инструментов, обновления, поддержка среды и т.д. Ознакомиться с остальными результатами можно здесь.
#devops #linux #kubermetes #platformengineering
Релизы и безопасность
Срединедельный DevOps! Поговорим о том, как Cozystack 0.41 добавляет MongoDB и улучшает стабильность Kubernetes, а MX Linux 25.1 возвращает поддержку dual-init-a.
⏺ Cozystack v0.41.0: MongoDB
Вышел релиз версии Cozystack. В v0.41.0 добавили поддержку системы управления БД MongoDB. Она располагается наряду с PostgreSQL, MySQL и Redis. К ключевым особенностям относим интеграцию с хранилищем бэкэндов Cozystack, настраиваемые CPU, встроенный экспорт метрик для мониторинга. Чтобы развернуть MongoDB через Cozystack дашборд используйте первый и второй workflow. Также, в новой версии представлены улучшения в работы хранилища, патчи для piraeus-server, рефакторинг проверки RWX на уровне года, повышение стабильности работы Kubernetes за счет увеличения значений
⏺ Опасайтесь VoidLink
На портале Checkpoint Research опубликовали отчёт о мультифункциональном вредоносном ПО китайского происхождения. VoidLink включает 37 плагинов, среди которых есть модули для устранения следов, выхода из контейнеров, сбора SSH-ключей, токенов и API-ключей. Фреймворк ориентирован на cloud- и container-first-среды и способен стабильно работать в Kubernetes и Docker, адаптируя поведение под окружение. Используются
⏺ Бесконечность не предел: MX Linux 25.1 «Infinity»
Релиз MX Linux 25.1, Debian-based дистрибутива. Все сборки поставляются с ядром Linux 6.12 (Debian-ветка), за исключением Xfce-AHS, где используется ядро 6.18 с патчами liquorix. В AHS-сборках также обновлён Mesa до версии 25.3.3. Включены все обновления Debian до Debian 13.3 и все актуальные обновления из репозиториев MX. В релизе анонсировали возвращение поддержки
#devops #cozystack #mxlinux #kubernetes #platformengineering
Срединедельный DevOps! Поговорим о том, как Cozystack 0.41 добавляет MongoDB и улучшает стабильность Kubernetes, а MX Linux 25.1 возвращает поддержку dual-init-a.
Вышел релиз версии Cozystack. В v0.41.0 добавили поддержку системы управления БД MongoDB. Она располагается наряду с PostgreSQL, MySQL и Redis. К ключевым особенностям относим интеграцию с хранилищем бэкэндов Cozystack, настраиваемые CPU, встроенный экспорт метрик для мониторинга. Чтобы развернуть MongoDB через Cozystack дашборд используйте первый и второй workflow. Также, в новой версии представлены улучшения в работы хранилища, патчи для piraeus-server, рефакторинг проверки RWX на уровне года, повышение стабильности работы Kubernetes за счет увеличения значений
resourcesPreset apiServer по умолчанию до large и увеличения порог startup-probe для kube-apiserver. Подробнее о релизе – тут. На портале Checkpoint Research опубликовали отчёт о мультифункциональном вредоносном ПО китайского происхождения. VoidLink включает 37 плагинов, среди которых есть модули для устранения следов, выхода из контейнеров, сбора SSH-ключей, токенов и API-ключей. Фреймворк ориентирован на cloud- и container-first-среды и способен стабильно работать в Kubernetes и Docker, адаптируя поведение под окружение. Используются
LD_PRELOAD, загружаемые модули ядра (LKM) и eBPF. Подробнее - здесь. Релиз MX Linux 25.1, Debian-based дистрибутива. Все сборки поставляются с ядром Linux 6.12 (Debian-ветка), за исключением Xfce-AHS, где используется ядро 6.18 с патчами liquorix. В AHS-сборках также обновлён Mesa до версии 25.3.3. Включены все обновления Debian до Debian 13.3 и все актуальные обновления из репозиториев MX. В релизе анонсировали возвращение поддержки
dual-init (systemd + sysvinit) в едином ISO-образе, что сокращает количество сборок, systemd теперь обновляется через Debian, а не через отдельный MX-пакет, что упрощает поддержку. Для желающих установить – инструкция тут.#devops #cozystack #mxlinux #kubernetes #platformengineering
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍6❤2🔥2
🎙️ На волне DevOps FM!
Пятница — отличный повод немного отвлечься от рабочих задач и послушать что-нибудь интересное.
В прошлых подборках нас просили больше русскоязычного контента, поэтому собрали три выпуска, которые стоит добавить в список для прослушивания.
🗣 DevOps в 2026: Platform Engineering, AI-агенты и будущее джунов от DevOps Kitchen Talks. Что происходит, когда у вас уже 600 сервисов и 3600 пайплайнов? Обсуждают internal platform, её архитектуру и self-service-возможности для разработчиков, а также границы ответственности platform team. Отдельный фокус — AI-агенты и multi-agent workflows: что происходит, когда автоматизация начинает работать уже не только с инфраструктурой, но и непосредственно с engineering-процессами.
🗣 Kubernetes 2035: кто будет управлять инфраструктурой? от «В SREду на кухне» / AvitoTech. GitOps, Crossplane, автоматизация Kubernetes и развитие абстракций над инфраструктурой. Интересный вопрос выпуска — сколько деталей инфраструктуры разработчику действительно нужно видеть и какие операции со временем можно передать платформе и автоматизации.
🗣 Инфраструктура & MLOps от [I'ML]. Здесь уже про инфраструктуру для ML и AI-систем. Обсуждают ML Platform, Data Platform, вывод моделей в production и особенности эксплуатации AI workloads. Хороший выпуск, чтобы посмотреть, какие привычные DevOps-подходы приходится адаптировать для AI.
Желаем приятного прослушивания и дежурств без алертов!🛡
#пятничная_подборка #подкаст #DevOps #PlatformEngineering #AIEngineering
Пятница — отличный повод немного отвлечься от рабочих задач и послушать что-нибудь интересное.
В прошлых подборках нас просили больше русскоязычного контента, поэтому собрали три выпуска, которые стоит добавить в список для прослушивания.
Желаем приятного прослушивания и дежурств без алертов!
#пятничная_подборка #подкаст #DevOps #PlatformEngineering #AIEngineering
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤4👍4🔥3
Platform Engineering 2.0: как меняется роль внутренней платформы
Kubernetes, Terraform, GitOps, CI/CD, Backstage — классический стек Platform Engineering уже хорошо знаком.
Но что происходит с этой моделью, когда появляются AI-нагрузки и новые способы взаимодействия с инфраструктурой?
В материале CNCF автор предлагает рассматривать это как следующий этап — Platform Engineering 2.0.
При этом фундамент не меняется: Platform as a Product, удобство для разработчиков, готовые пути, самообслуживание и безопасность на ранних этапах остаются актуальными. Меняется масштаб задач платформы и круг её пользователей.
Что добавляется:
⏺ AI становится ещё одним типом нагрузки
Платформе теперь приходится учитывать GPU/TPU, запуск и обслуживание моделей, обработку запросов, жизненный цикл моделей, MCP-шлюзы и специальные механизмы защиты.
То есть AI — это не отдельный слой где-то рядом с платформой. Для platform team это ещё один класс нагрузки со своими требованиями к ресурсам, безопасности и управлению.
⏺ Пользователей становится больше
Помимо разработчиков и platform engineers, с платформой работают ML-инженеры, специалисты по данным, команды безопасности и соответствия требованиям, FinOps — и постепенно AI-агенты.
Отсюда практический вопрос: можно ли пользоваться платформой программно?
Интерфейс и Backstage отлично подходят человеку. Но автоматизации и агентам нужны интерфейсы через API: ресурсы, действия, права доступа и ограничения.
⏺ FinOps перемещается ближе к созданию ресурсов
Стоимость становится частью решения ещё до развёртывания.
Например: сколько будет стоить новая нагрузка, какой ресурс выбрать и можно ли вообще её создавать с учётом текущего бюджета и правил.
⏺ Безопасность уходит глубже в платформу
Меньше ручных проверок после развёртывания — больше политик и контроля непосредственно на уровне платформы и среды выполнения.
Для AI добавляются свои риски: неконтролируемое использование AI, prompt injection, отравление моделей, утечки данных при обработке запросов.
⏺ Платформа становится модульной
Отдельные возможности должны быть доступны через API и собираться в разные сценарии: интерфейс, CLI, CI/CD, автоматизация или агент.
По сути, архитектура начинает выглядеть так:
И здесь важно: Kubernetes, Terraform, GitOps, Backstage никуда не исчезают. Меняется слой над ними — платформа начинает решать задачи, которые раньше находились за пределами классического самообслуживания разработчиков.
В итоге из концепции Platform Engineering 2.0 можно сделать вполне практичную вещь — ревизию собственной платформы.
Спросить себя:
→ Можем ли мы быстро выдать специализированный ресурс?
→ Можем ли мы сделать это через API?
→ Знаем ли стоимость до развёртывания?
→ Можем ли мы применять политики на уровне платформы?
→ Может ли автоматизация или агент работать с платформой без человека?
Если где-то ответ «нет» — вот там и находится следующая задача для platform team⌨️
#DevOps #Platformengineering
Kubernetes, Terraform, GitOps, CI/CD, Backstage — классический стек Platform Engineering уже хорошо знаком.
Но что происходит с этой моделью, когда появляются AI-нагрузки и новые способы взаимодействия с инфраструктурой?
В материале CNCF автор предлагает рассматривать это как следующий этап — Platform Engineering 2.0.
При этом фундамент не меняется: Platform as a Product, удобство для разработчиков, готовые пути, самообслуживание и безопасность на ранних этапах остаются актуальными. Меняется масштаб задач платформы и круг её пользователей.
Что добавляется:
Платформе теперь приходится учитывать GPU/TPU, запуск и обслуживание моделей, обработку запросов, жизненный цикл моделей, MCP-шлюзы и специальные механизмы защиты.
То есть AI — это не отдельный слой где-то рядом с платформой. Для platform team это ещё один класс нагрузки со своими требованиями к ресурсам, безопасности и управлению.
Помимо разработчиков и platform engineers, с платформой работают ML-инженеры, специалисты по данным, команды безопасности и соответствия требованиям, FinOps — и постепенно AI-агенты.
Отсюда практический вопрос: можно ли пользоваться платформой программно?
Интерфейс и Backstage отлично подходят человеку. Но автоматизации и агентам нужны интерфейсы через API: ресурсы, действия, права доступа и ограничения.
Стоимость становится частью решения ещё до развёртывания.
Например: сколько будет стоить новая нагрузка, какой ресурс выбрать и можно ли вообще её создавать с учётом текущего бюджета и правил.
Меньше ручных проверок после развёртывания — больше политик и контроля непосредственно на уровне платформы и среды выполнения.
Для AI добавляются свои риски: неконтролируемое использование AI, prompt injection, отравление моделей, утечки данных при обработке запросов.
Отдельные возможности должны быть доступны через API и собираться в разные сценарии: интерфейс, CLI, CI/CD, автоматизация или агент.
По сути, архитектура начинает выглядеть так:
Developer / ML Engineer / Agent↓Platform APIs↓Identity / Policy / Cost↓Kubernetes / Cloud / GPU / AIИ здесь важно: Kubernetes, Terraform, GitOps, Backstage никуда не исчезают. Меняется слой над ними — платформа начинает решать задачи, которые раньше находились за пределами классического самообслуживания разработчиков.
В итоге из концепции Platform Engineering 2.0 можно сделать вполне практичную вещь — ревизию собственной платформы.
Спросить себя:
→ Можем ли мы быстро выдать специализированный ресурс?
→ Можем ли мы сделать это через API?
→ Знаем ли стоимость до развёртывания?
→ Можем ли мы применять политики на уровне платформы?
→ Может ли автоматизация или агент работать с платформой без человека?
Если где-то ответ «нет» — вот там и находится следующая задача для platform team
#DevOps #Platformengineering
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤5🔥4👍3