Нашли интересный проект — BLAFS — инструмент для «обезжиривания» Docker-контейнеров, который может сократить их размер на 65-95%.

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

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

Интересно, что подход работает на уровне файловой системы и сохраняет слоистую структуру Docker-образов. Это отличается от других решений вроде SlimToolkit.

Пробовали ли вы инструменты для оптимизации размера контейнеров? Какие результаты получали?

Новый выпуск DevOps Дефлопе — про платформы на Kubernetes

Готовые решения экономят время, но ограничивают. Самописные — дают свободу, но требуют ресурсов.

Разбираем:
- Как не ошибиться с выбором
- Как выбрать платформу с минимальными рисками в будущем
- Когда пора пересматривать архитектуру

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

Слушать:
на удобной площадке
на YouTube

Как вы уже заметили, мы стали чуть активнее и возродили подкаст. На всякий случай, для тех, кто только к нам присоединился, в паре слов расскажем о том, что происходит в этом канале.

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

Но если мы видим в этом потоке что-то, что с нашей точки зрения, действительно заслуживает внимания, мы приносим это сюда для друзей и коллег. Мы — это инженеры Фланта и Экспресс42, компаний, которые стояли у истоков DevOps в России.

Надеемся, что Девопс Дефлопе станет самым полезным девопс-каналом в вашей ленте!

Вышел первый серьёзный отчёт State of GitOps 2025 — исследование 660 команд о том, как GitOps работает в реальности.

Главное открытие неутешительное. Большинство команд думают, что делают GitOps, но на самом деле, кажется, просто коммитят скрипты в Git. 60% до сих пор используют императивную конфигурацию вместо декларативной.

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

Команды, которые используют все шесть практик, показывают лучшие результаты по метрикам DORA. Они чаще деплоят, быстрее доставляют изменения и реже сталкиваются с инцидентами в проде.

Интересный момент про медленный code review. Он указан как одна из основных причин, почему команды откатываются к ручным изменениям через kubectl. Ну а это подрывает принципы GitOps, потому что Git перестает быть единственным источником истины.

А вы с какими проблемами при использовании GitOps сталкиваетесь?

В свежем выпуске подкаста «DevOps Дефлопе» болтаем про пет-проекты:

- Любовь Павла к сбору информации и парсинг Steam, а также его бот для конференций.
- Зачем Сергей написал приложение под Android и как запускал Quake III на тормозном рабочем компе.
- Как Виталий получил опыт деплоя лямбда-функций через Terraform и сделал себе погодную станцию.

А ещё вспоминаем рождение NGINX и рассуждаем, зачем вообще нужна работа, за которую не платят.

Слушать:
на удобной площадке
на YouTube

Пока все увлечённо обсуждают очередные обновления от OpenAI и Anthropic, GitLab неделю назад запустил в публичную бету свою платформу AI-агентов.

Вместо очередного чат-бота GitLab создаёт платформу GitLab Duo, где AI-агенты работают как полноценные члены команды.

По сути, AI-агент выступает как младший разработчик, который требует проверки от сеньора. Благодаря тому, что GitLab объединяет задачи, код и CI/CD в одной системе, его агенты работают с полным контекстом проекта. Так агенты получают преимущество перед внешними AI-инструментами с их ограниченным контекстом.

А ещё можно создавать и подключать собственных агентов под свои задачи и автоматизировать цепочки действий через Flows (например, анализ инцидентов или миграции пайплайнов)

Правда, Gitlab Duo Agent Platform доступна только в бете для Premium/Ultimate клиентов gitlab.com и self-managed инсталляций, но документация, API и SDK уже есть в открытом доступе.
Направление логично — превратить GitLab из платформы для DevOps в DevOps-платформу с искусственным интеллектом.

Какие задачи вы уже делегировали AI-агентам?)

Чтобы каждая реплика LLM приходила за миллисекунды и не разоряла бюджет на GPU, инфраструктура должна быть столь же умной, как сама модель.

Сегодня для этого есть два зрелых Open Source-движка — vLLM и SGLang. Оба уже служат базой для корпоративных продуктов Red Hat и LMSYS, поэтому технологический риск минимален. Ниже — как каждый из них помогает бизнесу экономить и в каких сценариях их применять.

Почему это важно прямо сейчас? Стоимость GPU-минут растёт, а объём запросов к моделям увеличивается экспоненциально, что напрямую бьёт по TCO AI-инициатив.

vLLM — максимум пропускной способности

• PagedAttention устраняет 60-80% фрагментации памяти через блочные таблицы (как виртуальная память в ОС), давая до ×24 больше throughput, чем Hugging Face Transformers.
• Continuous Batching обрабатывает запросы по шагам генерации. Таким образом быстрые не ждут медленных, снижается latency и пропадает простой GPU (〜x23 прирост пропускной способности).
• Совместимость с OpenAI API позволяет мигрировать SaaS-сервисы без переписывания клиентского кода.

Именно vLLM лежит в основе Red Hat AI Inference Server для OpenShift, так что решение готово к production-кластерам. А ещё LMSYS сократил

парк

GPU на 50 %, одновременно увеличив число обслуживаемых запросов в 2–3 раза после миграции на vLLM.

SGLang — это экономия на связанных запросах

• RadixAttention строит древовидную структуру для переиспользования KV-кеша между запросами с общими префиксами. Если пользователь ведёт диалог, SGLang автоматически переиспользует уже вычисленные части контекста, ускоряя цепочки вызовов до ×5 и снижая вычислительные затраты.
• Строго заданный вывод: можно жёстко задать JSON-схему или грамматику, избегая дорогой поствалидации.
• Оптимальный выбор для диалоговых агентов, RAG-конвейеров и других сценариев, где соседние запросы делят контекст и важна точная структура ответа.

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

Итого
Разверните оба движка в одной инфраструктуре: vLLM — на «горячем» пути API для массовых запросов, SGLang — в сервисах с многошаговыми генерациями. Так вы получите быстрые ответы при минимальной стоимости GPU; именно то, что нужно бизнесу здесь и сейчас.

Традиционные WAF эффективны против классических веб-атак, но плохо справляются с современными угрозами API. Рассмотрим различия между WAF и WAAP подходами к защите.

В I квартале 2025 г. количество DDoS-атак на API в России выросло на 74% по сравнению с аналогичным периодом 2024 г. (данные StormWall), а традиционные WAF их попросту не видят. Хакеры больше не ломают двери, они используют правильные ключи в неправильном порядке.

Ваш WAF работает как охранник 90-х: проверяет документы по списку «плохих слов», но не понимает, зачем посетитель пришёл. Атакующий делает 1000 валидных запросов к /api/user/profile за секунду? WAF молчит, ведь каждый запрос синтаксически корректен. И атакующий спокойно вытаскивает персональные данные миллионов пользователей через некорректно защищенный эндпойнт.

Современные API-атаки выглядят совершенно легально: скрейпинг данных через легитимные GET-запросы в больших объёмах, обход бизнес-логики через неожиданную последовательность API-вызовов, злоупотребление функциональностью через комбинирование разрешённых операций. Все эти атаки возможны потому, что злоумышленники понимают бизнес-логику приложения лучше команды, которая её создала.

Web Application and API Protection не ищет «вредоносные» запросы. Вместо этого он изучает нормальные паттерны каждого API и детектирует аномалии поведения:

• ML-анализ в реальном времени.

Система знает, что пользователь обычно делает 3-5 запросов в минуту, а не 300

• Контекстное понимание workflow.

WAAP видит последовательности вызовов API и выявляет попытки обойти предполагаемые рабочие процессы.

• Автоматическое обнаружение API.

Мониторинг сетевого трафика находит «теневые» эндпоинты, о которых забыли документировать.

WAAP решает главную болевую точку CI/CD. С ним больше не нужно вручную настраивать правила для каждого нового эндпоинта. Выкатили новую версию API? WAAP автоматически анализирует трафик и настраивает защиту.

Есть и бонус для разработчиков. Вместо "security review" на две недели получаете автоматическую защиту с первого деплоя. Команда безопасности видит реальное поведение API, а не гадает на кофейной гуще по коду.

Как начать
• Аудит API-ландшафта. Соберите все эндпоинты в единый каталог с OpenAPI-спецификациями
• Стандартизация. Унифицируйте аутентификацию и error handling (WAAP лучше работает с консистентной архитектурой)
• Correlation ID. Добавьте во все запросы для отслеживания многоступенчатых атак
• Безопасность как код. Внедрите этот подход в API-фреймворки и CI/CD пайплайны

WAF защищал веб-сайты 15 лет назад, но сегодня у вас сотни микросервисов с тысячами API-эндпоинтов. WAF остается актуальным для защиты веб-интерфейсов, но API-инфраструктура требует дополнительных решений. Поэтому WAAP дополняет, а не заменяет существующую защиту, решая специфические задачи API-безопасности.

Внедряйте сейчас, пока атакующие не обошли ваши текущие «правила безопасности».

В начало поста ←

«Observability никому не нужно»

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

В этом выпуске Виталий Лихачёв, автор канала «Kubernetes и кот Лихачева», и Евгений Бастрыков, тимлид команды разработки Prom++, разберут:
- почему 90 % ваших алертов — мусор;
- как eBPF и OpenTelemetry пытаются спасти мир;
- можно ли получать метрики из… чего угодно (спойлер: да);
- почему «наблюдаемость» — это не про слежку, а про то, чтобы не сойти с ума.

И главное: кому вообще нужно это Observability, если Чак Норрис пишет код без багов?

Слушать:
на удобной площадке
YouTube
Яндекс Музыка

Помните, Apple представила открытые проекты container и containerization для нативной контейнеризации на macOS? Написано на Swift, оптимизировано для Apple Silicon и вызывает больше вопросов, чем восторга.

При чуть более внимательном рассмотрении, оказалось, что Apple снова выбрали свой путь. У них не неймспейсы и общий кернел, а мини-микро-нано-виртуалка под каждый контейнер. И, внимание, нет адекватной сетевой связности между контейнерами, а вдобавок к этому ещё и сложности при работе с оперативной памятью.

Вместо привычной модели с shared kernel, Apple создают отдельную ВМ для каждого контейнера через Virtualization.framework. Обещают sub-second startup и hypervisor-level изоляцию, но на практике работает только на Apple Silicon с macOS 26. Экосистемы никакой, ни сompose, ни оркестрации.

Оба проекта  находятся в активной разработке. macOS 26 выйдет только в сентябре-октябре, так что сейчас это скорее preview для энтузиастов.

Мы так и не смогли понять, зачем нужен эппловский container, если уже есть docker-desktop и lima с привычным докером. Непонятно, будет ли работать в docker/containerd то, что сделано в container.

Возможно, это заготовка под будущие задачи Apple в области cloud/edge computing. А может, просто очередной эксперимент, который останется нишевым инструментом для узкого круга задач на macOS.

DevOps Deflope теперь и на Spotify.
А все (реально все, даже RSS-фид для олдскульных) другие сервисы найдёте на Mave.
Будем рады вашим звёздам, сердечкам и отзывам. Stay tuned!

Книги от Google по SRE весьма полезны, но не у всех есть время прочесывать 1000+ страниц принципов и философии. Автор с Medium, Magsther, решил эту проблему — он прочитал всю трилогию и превратил массив теории в 100 практических уроков.

Каждый урок рассчитан на самостоятельное изучение. Есть и про философию, например, “Error budgets are the reliability currency”; и про практические правила — “No SLO? No reliability”.

Нет регистрации, рекламы или paywall. Ну круто же :)

Тем не менее, делимся и книгами, по которым и сделаны 100 уроков:

• Site Reliability Engineering (2016),
• The Site Reliability Workbook (2018),
• Building Secure & Reliable Systems (2020)

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

«Хилы, танки и дамагеры DevOps» — каждый понимает DevOps по-своему. В новом выпуске DevOps Deflope узнаете:

• Почему DevOps-инженеры сравнивают себя с героями WoW?
• Как пайплайны помогают печь круассаны?
• Зачем DevOps’у лезть в архитектуру приложений?
• Чему учат в магистратуре по DevOps и можно ли его считать методологией?

Гость выпуска Константин Дипеж — создатель магистратуры по DevOps, доцент МФТИ и автор канала DeusOps.

Слушайте:
на удобной площадке
на YouTube
на Яндекс Музыке
в Вконтакте

Новый выпуск — и он про безопасность!

В нём эксперт по Application Security из Positive Technologies Владимир Кочетков рассказывает:

• что будет, если вообще забить на безопасность;
• почему от уязвимостей бизнес-логики «никогда в жизни не защитит» даже самый крутой AF;
• правда ли, что хакеры теперь умнее нас из-за ИИ;
• как внедрить безопасность, чтобы тебя не возненавидели все разработчики.

Слушать →
на удобной площадке
на YouTube
на Яндекс Музыке
в Вконтакте

Наткнулись на kubesec-diagram — интерактивную карту угроз Kubernetes, созданную внутри Telenor Norway. И знаете что? Она реально хорошая :)

Это интерактивная SVG-схема, визуализирующая поверхность атаки Kubernetes-кластера. Всё заточено под on-prem, так что для облачных K8s-кластеров и managed-сервисов может быть не так актуальна. Но, в целом, диаграмма может помочь, когда нужно быстро разобраться в security-контексте K8s или объяснить джуну, почему RBAC — это не просто галочка в чек-листе.

Внутри живая схема с кликабельными элементами. Тыкаете на "Container Process", получаете детали про PodSecurityContext, syscall restrictions и runtime enforcement. В разделе RBAC наглядно показана работа role bindings и опасность группы “system:masters”.

Думаем, что инструмент может быть полезен для DevOps/SRE-инженеров как минимум в двух основных сценариях: обучение новичков и быстрый аудит во время инцидентов. Да, большинство информации можно найти в CIS Benchmark или официальной документации K8s, но когда нужно быстро освежить тему или показать коллеге связь между компонентами — почему нет?

Диаграмма местами перегружена деталями, и для продакшена все равно придется изучать каждый компонент отдельно. Но как starting point для понимания attack surface в кластере — вполне годится. Ещё можно сесть, покопаться и найти что-то новое.

Проект активен, последнее обновление — v9 от августа 2025 года. Это полезный вспомогательный инструмент, но не истина в последней инстанции.

Сохраните в закладки для командных обсуждений архитектуры, но, всё же, для полноценного аудита полагаться на специализированные средства, такие как kube-bench, kubeaudit или Falco.

Проект на GitHub: github.com/kubesec-diagram/kubesec-diagram.github.io

Быстро потестировать etcd или поковырять containerd без поднятия локального кластера? Собрали браузерные песочницы, где можно экспериментировать с инфраструктурным софтом без танцев вокруг Docker Desktop и minikube.

1. Etcd Playground — для тех, кто хочет понять мозг Kubernetes
Интерактивная песочница с полноценным (но, ясное дело, учебным) кластером etcd из трёх нод.

2. Kubernetes Playground — браузерная площадка с готовым многоузловым кластером Kubernetes
Кластер развёрнут через kubeadm с возможностью выбора контейнерного рантайма и сетевого плагина. Можно экспериментировать с настройками, отлаживать манифесты и тренироваться в администрировании.

3. Nerdctl Playground — containerd с человеческим лицом
Площадка позволяет работать с containerd через Docker‑совместимый CLI, который упрощает работу по сравнению с нативным ctr. Можно изучать namespaces, snapshotter’ы и жизненный цикл контейнеров без установки локального рантайма.

4. KodeKloud Playgrounds — готовые среды под задачу
Предварительно настроенные среды под конкретные курсы (Terraform, Docker, K8s, Ansible). Не нужно ничего поднимать, остаётся только выполнять задания.

5. LabEx — тренажёр с дорожной картой
Пошаговое обучение с автоматической проверкой заданий. Много практических сценариев от базового Linux до сложных тем в K8s и Cloud.

6. Helm Playground — песочница для Helm-чартов
Позволяет экспериментировать с шаблонами, values и структурой чарта, сразу видя итоговые YAML-манифесты. Удобно для быстрой проверки идей и отладки шаблонов.

Эти площадки не заменят продакшен-кластеры со всеми их перформанс-проблемами, конечно же. Но будут весьма полезны для обучения.

Используете что‑то интересное для экспериментов с Kubernetes и containerd? Пишите в комментариях :)

4 декабря в Москве пройдёт Kuber Conf от Ассоциации облачно-ориентированных технологий.

Флант, Yandex Cloud и VK Cloud создают АОТ, первую в России некоммерческую организацию для развития Cloud Native-технологий вне вендоров. И сразу делают конференцию, чтобы собрать всех, кто работает с Kubernetes и облаками.

На конфе представители ассоциации расскажут о проекте. Зачем всё это нужно и что хочется делать: стандартизировать компетенции, поддерживать Open Source, объединить сообщество.

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

Хотите стать спикером? Если работали с чем-то новым в Kubernetes, внедряли интересные решения в облаках или решали нетривиальные задачи — расскажите об этом. Рабочий опыт, сложные проблемы, даже провалы (они самые интересные и полезные). CFP ещё открыт.

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

Приходите, будет классно. Давно пора собраться и сделать что-то большое вместе.

До встречи 4 декабря!

ConfigHub официально запустился — это стартап от Brian Grant (оригинальный архитектор Kubernetes), Alexis Richardson (основатель RabbitMQ и Weaveworks) и Jesper Joergensen (бывший продуктовый лид Heroku и топ Twilio). Летом 2024 они были в режиме стелса и только набирали команду, теперь вышли с готовым продуктом.

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

ConfigHub предлагает подход Configuration as Data. Традиционные DevOps-тулы требуют, чтобы все изменения шли через пайплайн. ConfigHub позволяет в критической ситуации внести изменения напрямую, а затем автоматически привести всё в порядок и синхронизировать состояние в масштабе.

Продукт уже работает для пользователей Kubernetes, Helm и GitOps.

Учитывая, что команда уже создала Kubernetes, RabbitMQ и популяризировала GitOps, следить за их новым проектом точно стоит.

Источник — пост Alexis Richardson на LinkedIn.

Нельзя так просто взять и спарсить 150 тысяч вакансий… Или можно?

Можно. Именно это сделал автор проекта TrueIndex, чтобы составить альтернативный TIOBE рейтинг, который показывал бы картину спроса на технологии в России.

Проблема того же TIOBE в том, что он считает поисковые запросы в Google. Люди могут искать что угодно из любопытства, для учёбы, для решения legacy-проблем. Но это не показывает, что реально нужно работодателям прямо сейчас.

TrueIndex пошёл от обратного и взял не запросы, а вакансии. Парсер собирает данные с HeadHunter и Habr Career, анализируя сотни тысяч объявлений. На их основе он считает статистику по языкам, фреймворкам, базам данных и другим технологиям, которые упоминаются в требованиях.

Первый же срез данных показал неожиданную картину. Технологии, специфичные для российского рынка (например, 1С), оказываются в топе по спросу, хотя в TIOBE их вообще нет, потому что за границей о них не знают. Языки, которые все считают устаревшими, спокойно держатся в топ-10 по количеству вакансий. А что-то вроде Fortran и Assembly из международных рейтингов в массовом найме практически не встречается.

Сейчас TrueIndex собирает данные с HeadHunter и Habr Career, ежемесячно обновляет рейтинг и постепенно расширяет набор метрик.

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

Ну а дальше можно просто зайти на trueindex.ru и посмотреть на актуальный рейтинг своими глазами.

Kuber Conf уже завтра, но вы успеваете запрыгнуть.

Смотрите, программа там реально насыщенная. Мы пробежались по докладам и выбрали то, что зашло:

• Как мы строили платформу деплоя в Т.
Послушаем про опыт построения универсальной платформы деплоя на базе OAM и KubeVela. Основная идея — вынести сложность конфигурации инфраструктуры и взаимодействия с Kubernetes на сторону платформы, а разработчикам дать простой и удобный интерфейс для описания приложений. Отдельный плюс: платформа берёт на себя вопросы EoL и миграций, снижая необходимость в бесконечных согласованиях и ручных договорённостях с командами.

• Vitastor и Kubernetes: есть ли жизнь на Марсе. Посмотрим, как интегрировать распределённую СХД через CSI и что там с производительностью в реальных условиях.

• Обучаем LLM по клику: платформа распределённого обучения на HGX. Доклад про то, как в Avito строили MLOps-инфраструктуру для обучения LLM на множестве узлов в рамках платформы Aviflow. Нам расскажут, чем обучение LLM отличается от «обычного» ML, какие технологии нужны для распределённого обучения, и как обернуть это в удобный сценарий. А также и о самом железе (HGX), и его нюансах эксплуатации.

Ещё два доклада будут от нас:
• А вы точно уверены в SLA своего кластера Kubernetes? Владимир Гурьянов из Deckhouse Observability разберёт, почему метрики в состоянии покоя не показывают реальную картину и как правильно тестировать доступность кластера. Плюс практический чеклист для измерения SLA.

• Не Talos единым: как ограничения научили нас ставить Kubernetes поверх любой операционной системы. Денис Романенко из Deckhouse Core покажет, как автоматизировать развёртывание Kubernetes поверх любой ОС, когда современные K8s-дистрибутивы недоступны или не подходят.

Днём слушаем доклады, вечером общаемся на афтерпати. Конфа уже послезавтра, наша редакция тоже там будет.