Сбой Cloudflare, EOL Ingress NGINX и релиз Sprout

Свежий новостной дайджест от DevOps FM.
⏺Масштабный сбой в облаке – Cloudflare
Cloudflare объявила, что сбой 18 ноября, из-за которого частично не работали ChatGPT, Claude, Spotify, X и другие сервисы, был вызван latent bug в компоненте, который отвечает за защиту от ботов. Пользователи по всему миру наблюдали ошибки 500 Internal Server Error при попытке зайти на сайт. Подробнее о проблеме здесь.

⏺Ingress NGINX уходит в прошлое: что нас ждёт
В настоящий момент проект находится на best-effort-поддержке, а уже в марте 2026 года поддержка Ingress NGINX будет остановлена, дальнейшие релизы, исправление багов прекращаются. Репозитории GitHub сохранятся в режиме read-only. SIG Network и Security Response Committee рекомендуют всем пользователям немедленно начать миграцию на Gateway API или другой Ingress-контроллер. Почему – читайте здесь.

⏺Edera выпускает open-source версию Sprout
Edera, компания известная своими решениями в области безопасности, такими как Protect Kubernetes, анонсировала выход open-source версии Sprout, загрузчика ОС на базе Rust. По словам Edera, Sprout обеспечивает высокий уровень безопасности, запуск системы за <50 мс и простой механизм управления для любой ОС, про особенности читайте здесь.

#Cloudflare #Sprout #Rust #NGINX

DevOps FM празднует!

🎙Завтра, 22.11.25, исполняется 4 года с тех пор, как мы делимся с вами свежими релизами и подборками из мира DevOps и администрирования!

Спасибо, что читаете нас, даёте обратную связь в комментариях, ставите реакции и репостите актуальные материалы 💟А мы продолжим совершенствоваться: делать посты еще полезнее и увлекательнее :)

Мы всегда рады услышать ваше мнение: по всем пожеланиям и предложениям пишите в комментарии или напрямую → @b_vls.

Cделаем DevOps FM лучше вместе 🤝

Логирование и мониторинг — топ-3 инструмента для DevOps в 2025

🗣Несложно представить ситуацию: трафик на пике, API выдает 500-е ошибки. Вы заходите на сервер по SSH, суматошно переходите из директории в директорию, пытаетесь разобраться в веренице логов микросервисов и в конце находите виновника. Спустя время сбой устранили, но вопрос остался – «неужели нельзя проще?». Отвечаем – можно, с инструментами observability.

🚀Топ-3 инструмента для логирования и мониторинга:

1.Grafana Loki
Плюсы:
• Минимальные расходы: Loki не индексирует содержимое логов, используя только метки (labels) — как в Prometheus. Это снижает потребление CPU, RAM и дискового пространства.
• Тесная интеграция с Prometheus и Grafana: Если вы уже используете Grafana или Prometheus, например в рамках KubePrometheusStack, то вам может быть полезна возможность просматривать логи там же, где и метрики.
• Простота развёртывания и масштабирования: monolithic mode идеально подходит для старта, так как объединяет в рамках одно бинарного файла все компоненты Loki. Но как только вам его не хватает, советуем перейти на микросервисный режим, разделив Distributor, Ingester, Querier и Compactor на отдельные сервисы
• Гибкий язык запросов: LogQL похож на PromQL, что позволяет проводить агрегаций и подсчёт ошибок за период времени, а затем выводить панели с количеством ошибок, рейтами и распределениями в Grafana.
💬Что учесть
Однако, Loki разработан для фильтрации логов на основе меток и регулярных выражений, а не для глубокого полнотекстового поиска и не позволяет справляться со сложным анализом логов.

2. Elastic Stack
Плюсы:
• Настройка на всех уровнях: от сбора данных с помощью Logstash или Beats до запросов и дашбордов в Kibana — почти все можно настроить
• Мощный поиск и аналитика: Elasticsearch обеспечивает быстрый полнотекстовый поиск и агрегацию в больших масштабах
• Работа в реальном времени: данные индексируются и становятся доступны для поиска почти мгновенно
Гибкость индексации и управления данными: в Elasticsearch есть возможность настраивать ILM (Index Lifecycle Management) - автоматически перемещать "тёплые" и "холодные" данные между нодами, удалять старые индексы по политике.
💬Что учесть:
Операционные затраты могут быть высокими, а расходы на облачные услуги быстро растут при производственном масштабе.

3. OpenSearch
Плюсы:
• Полный open-source: OpenSearch является решением с открытым кодом без лицензионных рисков.
• Гибкость в сборе и анализе логов: поддерживает SQL и PPL, а также обладает встроенным observability-стеком
• Alerting-plugin — в отличие от ElasticSearch, OpenSearch из коробки позволяет строить гибкие триггеры и уведомления.
• Активное сообщество и поддержка AWS: он поддерживается AWS, Capital One, Red Hat, SAP и другими.

👩‍💻 Подборки репозиториев:
https://github.com/grafana/grafana – интеграция с Grafana с дашбордами и алертингом;
https://github.com/grafana/loki – репозиторий для агрегации логов
https://github.com/elastic – у Elastic на GitHub свыше 800 репозиториев, включая ядро Elasticsearch и множество интеграций и плагинов.

#DevOps #Observability #Grafana #Elastic

Релизы недели: Opus 4.5, OpenAI Chats и Log Analytics Query Builder

В традиционной подборке три ключевых релиза: групповые чаты ChatGPT меняют сценарии совместной работы, Opus 4.5 составит конкуренцию Google Gemini 3, Log Analytics Query Builder для извлечения данных из BigQuery.

⏺Групповые чаты в ChatGPT
OpenAI объявила о глобальном запуске групповых чатов в ChatGPT для пользователей планов Free, Go, Plus и Pro; ранее пилот представили в Японии и Новой Зеландии. Функция объединяет совместную беседу с участием до 20 человек (при принятии приглашения) и нужна для совместного планирования и принятия решений при поддержке ChatGPT как ассистента. Подробности тут.

⏺Релиз Opus 4.5 от Anthropic
Anthropic выпустила Opus 4.5, новейшую языковую модель, конкурент OpenAI GPT-5.1 и Google Gemini 3. Opus 4.5 стала первой моделью, которая продемонстрировала более 80 % точности на SWE-Bench Verified и получила улучшенные способности к работе с вычислениями и электронными таблицами. Anthropic расширяет доступ к продуктам Claude for Chrome для пользователей Max и Claude for Excel для Max, Team и Enterprise. Что нового в версии – читайте здесь.

⏺ Log Analytics Query Builder от Google
Google представила Log Analytics Query Builder – инструмент для упрощённого доступа к данным в Google Cloud и автоматической генерации SQL-запросов к логам, другим типам телеметрии и таблицам в BigQuery. Конструктор поддерживает поиск по всем полям, автоматическое обнаружение JSON-схем. Подключен Log Analytics Query Builder и результаты работы можно визуализировать, сохранить на дашборд. Подробнее о релизе здесь.

#claude #claudeexcel #chatgpt #opus

Лучшие из худших сообщений коммитов

⏺Всем DevOps! Хорошие новости – сегодня пятница, значит скоро нас ждет перерыв от дейликов. Плохие – всё еще нужно писать сообщения коммитов после деплоя и релизов. Представляем зал славы лучших из худших сообщений коммитов, где собраны нестандартные варианты из рабочих репозиториев. Расширенный сборник найдёте здесь.

👀Вот сейчас точно исправил


"fix"
"fix-final"
"ok final fix"
"fix final final"
"fixed previous fix"

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

👀Всё, что надо было, сделал

"did the needful"

Классическое сообщение тиммейтов при поступлении срочной задачи, которую закрыть надо было ещё вчера.

👀Хроники борьбы с билдом

"attempt to fix the build"
"ok, fix the build"

Попыток было в разы больше.

👀Пожалуйста, работай…

"please work"

Признайтесь, были и такие моменты в работе.

👀Эпоха до ESLint

"added a coma, now works fine"

Кто бы что ни говорил, а проблема «казнить нельзя помиловать» актуальна.

Какие находки из коммитов помните вы?

#git #commits #commitmessages #devops

Good practices: конфигурации в Kubernetes

Конфигурации – основа рабочей нагрузки Kubernetes. Опытные инженеры знают, что достаточно пропущенной кавычки, неактуальной API-версии или смещённого отступа в YAML для возникновения проблемы при деплое. Представляем подборку good practices с советами по стабилизации кластера — для новичков и опытных пользователей. Подробнее читайте здесь.👀

Общие practices:
⏺Используйте актуальную версию API
Kubernetes быстро развивается и обновляется. Менее актуальные API не работают корректно и приводят к сбоям при деплое. Проверяйте версию API, используя следующую команду:

kubectl api-resources 

⏺Храните конфиги под версионным контролем
Не применяйте файлы манифеста с десктопа, храните их в системе контроля версий, например, в Git. Если что-то сломается – вы быстро откатитесь к прошлому коммиту.
⏺Пишите конфиги в YAML, не в JSON
Технически работают оба формата для обмена и хранения данных, но YAML более удобен, по словам автора. В YAML используйте только true/false, т.к. yes/no/on/off могут парситься по-разному. Для надёжности берите в кавычки всё, что похоже на булево значение (например, "yes").
⏺Группируйте связанные объекты
Если ресурсы – часть одного сервиса, храните их в одном файле YAML-манифеста. Так легче отслеживать, ревьювить и разворачивать изменения.
Применяйте эту команду, чтобы задеплоить всё в папке:

kubectl apply -f configs/ 

🚀Стандартизированные конфигурации упрощают управление кластером и берегут нервы администратора. Следуйте базовым принципам: контроль версий, единая система меток, отказ от использования отдельных Pod-ов без контроллеров. Так, вы значительно сократите время на диагностику и устранение ошибок.

#kubernetes #k8s #clustermanagment #devops

Приглашаем к коллегам на Kuber Conf

Всем DevOps!🚀

Разыгрываем 15 билетов на Kuber Conf – первую некоммерческую конференцию по k8s в России.
Организаторы "Ассоциации облачно-ориентированных технологий" – VK Cloud, Yandex Cloud и Флант.

📅 Когда: 4 декабря, Москва.

⏺Что представлено? Доклады от мейнтейнеров Open Source-проектов, лидеров продуктовых команд и основателей инфраструктурных компаний. Участникам будут доступны два трека:

1. Основной: эволюция Managed Kubernetes от "лодки" до "крейсера", кейс по построению расширяемой платформы деплоя от Т-Банка, полный путь кастомизации Talos Linux deep-dive по CNI и прочие кейсы. Концентрация пользы и опыта специалистов Beget, Т-Банка, Фланта, Yandex Cloud и Avito.

2. Второй, интригующий: Cluster API и её новая версия v1beta2, кейс Vitastor о преимуществах и недостатках разных способов подключения блочных устройств к контейнерам (nbd, vduse, ublk), развертывание Gatekeeper в k8s-in-k8s, Talos-подобная Базальт СПО.

Регистрируйтесь и смотрите полную программу здесь.

Чтобы участвовать:
1. Убедитесь, что вы на нас подписаны, @DevOps_FM.
2. Нажмите «Участвую!» под этим постом.

🗓 Итоги мы подведём случайным образом, а результаты объявим уже сегодня!

Важно: один билет = один гость.

Успейте принять участие! 🚀

#партнёрский_пост

Где тонко – там ChatGPT, где Docker – там патч

Из срочного – сообщаем о массовом сбое в работе ChatGPT 2 декабря. Пользователи из США, Канады, Великобритании, Индии и других стран направили запросы о превышении времени ожидания ответов в приложении в 22:11 Мск. Уже через час проблему устранили, но с чем были связаны неполадки до сих пор неизвестно.

⏺Анонс Kubernetes v1.35
В сникпике версии v1.35 Kubernetes прекращает поддержку cgroup v1, ipvs в kube-proxy и containerd 1.x, что требует обновления инфраструктуры для корректной работы кластера. Релиз включает в себя in-place обновление ресурсов подов, node declared features, расширенные возможности taints, user namespaces и нативное управление сертификатами подов, повышающие безопасность и надёжность.

⏺GitLab Patch Release: 18.6.1, 18.5.3, 18.4.5
Патч-релизы GitLab устранят множество багов и уязвимостей, поэтому рекомендуем обновиться. Среди исправлений – небезопасная многопоточность при кешировании CI/CD, DoS-уязвимости валидации JSON, проблема обхода аутентификации при регистрации.

⏺Docker и CVE-2025-12735.
Docker устранили критическую уязвимость CVE-2025-12735 (удалённое выполнение кода в Kibana). Команда не только выпустила патч для пользователей, но и внесла исправление в LangChain.js в upstream, чем повысила безопасность для всех проектов, использующих эту библиотеку. Такой подход направлен на защиту всей экосистемы.

#kubernetes #gitlab #docker #chatgpt

🎉 Результаты розыгрыша:

Поздравляем победителей!

🏆 Победители:
1. Oleg (@brbch)
2. Konstantin (@Kostik_Man)
3. V (@add_me_number)
4. zaskhat (@zaskhat)
5. Павел (@archivat)
6. Vladislav (@kennytomato)
7. Valeriy (@Emelyanov_Valeriy)
8. Ruslan (@gainanovrus)
9. Mans (@Zerstoler)
10. Denis (@Denispv82)
11. Максим (@spidermanstruation)
12. KotDimos (@KotDimos)
13. Valeria (@yo_hojb)
14. Глеб (@DirtyCheater)
15. Oleg (@bos_one)

✔️Проверить результаты

Вопрос-ответ от инженера

🗣Пятничный DevOps!
В прошлом месяце мы начали разговор об отечественных операционных системах. В ходе обсуждения стало ясно: практических вопросов гораздо больше, чем готовых решений, а значит пора передать слово специалисту.
Тимлид инфраструктурного отдела Nixys Роман Емельянов дал комментарии об особенностях использования Astra Linux в DevOps.

💬Насколько привычен интерфейс?
У Astra Linux есть графическая оболочка Fly (интерфейс на Qt), которая напоминает классический Windows-десктоп: панели, меню, проводник. Но для DevOps главное - консоль.
В основе Astra лежит Debian (привычный apt и всё остальное), но когда мы говорим о работе в консоли, отмечаем следующие особенности: редакция CE использует стандартную дискреционную модель доступа (Linux), а SE включает мандатную модель безопасности MLS, реализованную в ядре и распространяющуюся на процессы, файлы и механизмы межпроцессного взаимодействия. Из-за MLS системные службы, включая D-Bus, запускаются с мандатными метками и работают под ограничениями политики безопасности. Такой механизм работы влияет на взаимодействие сервисов, контейнеров и доступ к ресурсам внутри системы. Astra Linux представлена как отечественная альтернатива классическим Linux-дистрибутивам, поэтому компании чаще внедряют именно SE, чтобы соответствовать требованиям ФСТЭК и закрывать регуляторные задачи.

💬Контейнеры на Астре. Есть ли нюансы?
В Astra SE контейнеры, как и прочие элементы, работают под политикой MLS. PARSEC назначает метки безопасности процессам, файлам и IPC внутри контейнера, контролирует взаимодействие этого добра с ресурсами системы. Контейнеризация работоспособна, но её поведение жёстче, чем в обычном Debian. Часть capabilities блокируется, доступ к файловым системам и namespace-операциям ограничен, а root внутри контейнера действует в рамках политики безопасности (а не как в Docker на Ubuntu).
Ну и чуть сильнее сердечко инженера могут заставить биться контейнеры, которые зависят от systemd и ля-классик init-окружения. В целом, в контейнерах поведение systemd обусловено рантаймом, его режимом (rootless / rootfool) и моделью cgroups. Работа systemd с Podman на cgroups v1 обычно более предсказуема, в то время как Docker на cgroups v2 часто не запускает systemd корректно, что подтверждается тестами на Debian/Ubuntu.

Поговорим о кейсе, который не связан напрямую с ограничениями MLS от Астры, но в нём есть свои особенности.

1/1

#лонгрид

FreeIPA на Astra SE: что пошло не так и как всё исправили

Нам нужно было поднять FreeIPA в контейнере на Astra SE по требованиям заказчика. Стоит учитывать, что контейнер использует минимальное systemd-окружение и опирается на корректную работу dbus, cgroup delegation. Именно этот кейс разберем сегодня.

⏺Что делали?
Мы использовали официальный образ и пробовали запуск через Docker, затем через Podman – но ipa-server-install сразу падал.
🤡И началось веселье: внутри контейнера случился мрак – systemd не мог корректно сформировать cgroup-иерархию, а dbus-брокер аварийно завершался с сообщением sockopt_get_peersec: Invalid argument. В результате не запускались зависимые сервисы: certmonger, pki-tomcatd завершался при инициализации, и установка разваливалась.

Это совпадало с описанным в issue FreeIPA – на Debian-based конфигурациях systemd и dbus в контейнере работают некорректно.
Переключение на cgroups v1 дало надежду: systemd внутри контейнера стал запускаться, но это не решило проблему с dbus. Вместе с коллегами мы перебрали разные рантаймы и конфигурации: Docker, Podman, «голый» containerd, варианты монтирования /sys/fs/cgroup (ro / rw). Итог один: dbus в контейнере на Astra SE так и не ожил, а без него FreeIPA не запускалась.

⏺Как решили проблему?
Пошли вглубь и попытались пересобрать systemd (🤡). Старую версию (как в CE) собрать не удалось – зависимости были сломаны. Собрали текущую версию с модификацией dbuspolicydir, установить её, и… Astra перестала загружаться.
И, наконец «волшебство» произошло: запуск в rootless Podman при использовании cgroups v1 позволил systemd и dbus внутри контейнера заработать и установка FreeIPA прошла успешно.

🚀Вывод из кейса: при запуске FreeIPA в контейнере на Astra SE обращайте внимание на комбинацию рантаймов, их режимов и версию cgroup.

Обсудим вместе, сталкивались с подобными кейсами?

2/2

#лонгрид

Как развернуть Prometheus через systemd и запустить базовый мониторинг
👨‍💻Возвращаемся с инструментами по observability и SRE. Prometheus – это система мониторинга с открытым исходным кодом, которую можно использовать для сбора и отслеживания различных метрик из экспортеров в Time Series Database (TSDB). Сегодня разберем, как настроить и запустить Prometheus и управлять через systemd на сервере Ubuntu или Debian. Для инженеров single-node установка позволяет использовать Prometheus как базовую систему мониторинга без лишних инфраструктурных настроек.

⏺Шаг 1. Подготовка пользователя и загрузка Prometheus
Создаем отдельного пользователя для Prometheus:

sudo useradd -M -U prometheus

Выбираем версию для вашей системы и скачиваем бинарь:

wget https://github.com/prometheus/prometheus/releases/download/v2.40.0-rc.0/prometheus-2.40.0-rc.0.linux-amd64.tar.gz
tar -xzvf prometheus-2.40.0-rc.0.linux-amd64.tar.gz
sudo mv prometheus-2.40.0-rc.0.linux-amd64 /opt/prometheus

Меняем права на папку, чтобы Prometheus мог работать безопасно:

sudo chown prometheus:prometheus -R /opt/prometheus

⏺Шаг 2. Настройка systemd-сервиса
Создаем файл /etc/systemd/system/prometheus.service с таким содержимым:

[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Restart=on-failure
ExecStart=/opt/prometheus/prometheus \
  --config.file=/opt/prometheus/prometheus.yml \
  --storage.tsdb.path=/opt/prometheus/data \
  --storage.tsdb.retention.time=30d

[Install]
WantedBy=multi-user.target

⏺Шаг 3. Запуск и управление Prometheus
Активируем сервис и запускаем его:

sudo systemctl daemon-reload

sudo systemctl start prometheus.service

sudo systemctl enable prometheus.service



Проверяем статус и логи сервиса:

sudo systemctl status prometheus.service

sudo journalctl -u prometheus.service -f

Теперь Prometheus работает как системный сервис, собирает метрики и готов к подключению экспортеров.

⏺Шаг 4. Дальнейшие шаги
⁃ Настройка AlertManager для уведомлений.
⁃ Подключение экспортеров для серверов, контейнеров и приложений.
⁃ Использование Grafana для визуализации метрик.

🗂Подробнее о настройке алертов: Prometheus Alerting

Вывод: такой минимальный setup позволяет быстро поднять Prometheus для тестов и PoC, понять, как работает TSDB, и интегрировать систему мониторинга в DevOps-процессы.

#sre #observability #prometheus #monitoring #devops

Свежие новостные релизы, которые ещё не успели настояться

Срединедельный DevOps! 🚀Сегодня поговорим о сбое Cloudflare, рассмотрим превью AWS DevOps Agent и релизы AWS re:Invent 2025 в области безопасности.

⏺Не опять, а снова: сбой в Cloudflare, ошибка 500
Cloudflare частично оказалась недоступной на 25 минут в прошлую пятницу. Во время инцидента примерно треть запросов вела на пустую страницы с кодом ошибки 500. В этот раз, причиной стала проблема в коде на языке Lua, которая применяется в системе фильтрации трафика WAF для блокирования вредоносных запросов. В логах отображалось:

[lua] Failed to run module rulesets callback late_routing: /usr/local/nginx-fl/lua/modules/init.lua:314: attempt to index field 'execute' (a nil value)

Изменение было отменено в 09:12 UTC, и после отката нормальная обработка трафика восстановилась.

⏺AWS DevOps Agent (preview): выявление и локализация причин инцидентов.
AWS представила превью AWS DevOps Agent, ИИ-агента для расследования и предотвращения инцидентов.
Интеграция с Datadog MCP Server обеспечивает доступ к логам, метрикам и трассировкам, что позволяет агенту автоматически сопоставлять данные из AWS и Datadog. В демонстрации агент за минуты выявил суть проблемы всплеска 5XX ошибок API Gateway. Ранние пользователи отмечают сокращение MTTR с часов до минут. Подробнее здесь.

⏺re:Invent 2025: релизы инструментов и обновления
На re:Invent 2025 AWS представила ряд обновлений в области безопасности, управления идентификацией, тарификации, а также состоялись релизы тулзов: IAM Policy Autopilot, инструмент для генерации IAM-политик на основе детерминированного анализа приложений, Org-level S3 Block Public Access, расширение блокировки публичного доступа на уровне организации, TLS Proxy, новый сервис прокси для TLS-инспекции. Прочитать об обновлениях можно здесь.

#devops #cloudflare #aws #awsdevopsagent

Не делайте так: мой пятничный деплой

👀Снова пятница, пора сворачиваться и надеяться, что ни один pipeline не применит изменения, способные снести пол-инфры. Расскажем поучительную историю о DevOps-инженере, который решил выполнить развертывание в пятницу, после рефакторинга Terraform-модулей. Не судите автора статьи слишком строго, он обычный человек, который на кофеине нажал «Deploy».

💬Что произошло в пятницу?

•15:47 – запуск развертывания после рефактора Terraform-модулей.
Изменение – автор переименовал одну переменную, которая используется в сорока семи местах, в трёх окружениях. Но проверка линтером пройдена. Что может пойти не так?
•16:02 – запуск GitHub Actions, а дальше...пайплайн упал, в Terraform появился неожиданный destroy -план. Уведомления в Slack накрыли волной.
•16:07 – сообщения о падении staging и подозрительные изменения в проде, возгласы: "КТО ДЕПЛОИЛ В ПЯТНИЦУ?!". Автор попытался отключить роутер, но было поздно – имя уже в коммите.
•16:11 – созвон в зуме, SRE подключился со вздохом, бэкэнд-разработчик присоединился с пивом, CTO – с пляжа на Бали.
•16:20-16:45 – откат коммита, повторный прогон пайплайна, окружение восстановлено.

После – постмортем без прямых обвинений с коллективной критикой в виде смайликов и пассивно-агрессивных мемов.

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

✅Уроки, которые автор не усвоил (а должен был):

•Не деплоить в пятницу
•Всегда перепроверять terraform plan для каждого окружения перед применением.
•Подготовить воспроизводимый плана отката, желательно, без слёз.
•Внедрить автоматическую валидацию переменных и контрактов модулей (schema/validation) и тесты на согласованность именований.

Пятничный деплой: храбрость или безрассудство? Делитесь вашими историями ниже.

#deploy #devops #terraform #postmortem

От values-файлов к управлению вариантами конфигураций в ConfigHub: как перестать рендерить вслепую

В этот понедельник поговорим о переходе от классического Helm-подхода с values.yaml к модели Configuration as Data, которая реализует себя в ConfigHub. Если вы всё ещё храните values.yaml для разных сред, при аварийных запросах запускаете helm template и парсите YAML – рекомендуем сменить подход. В ConfigHub реализуется модель «конфигурация как данные»: вместо того чтобы каждый раз генерировать YAML из шаблонов по запросу, вы создаёте готовый манифест один раз.

Как внедрить подход?
⏺Развертывание базового окружения (Infra Space)

1. Добавляем репозиторий Helm:

helm repo update

2. Разворачиваем базовое окружение для инфраструктуры:

cub space create infra

3. Устанавливаем Helm-чарт через ConfigHub:

cub helm install --space infra \
  --use-placeholder=false \
  --namespace monitoring \
  prometheus prometheus-community/kube-prometheus-stack \
  --version 79.6.1

• ConfigHub использует движок Helm для однократного рендеринга чарта.
• Результат сохраняется как материализованный, версионируемый и индексируемый артефакт (Config Unit).

⏺Создание пространств для окружений (Spaces)
1. Создаем пространства для каждого целевого окружения:
cub space create dev
cub space create prod
2. В качестве альтернативы – создаем пространства через UI ConfigHub, используем кнопку [Add] на странице списка Spaces.
3. Каждое пространство будет содержать копии базовых конфигураций для конкретного окружения.

⏺Клонирование и создание Вариантов (Variants)
Variant – это копия Config Unit, которая создается через операцию Clone.

1. Создаем Dev Variant из базового окружения:
2. Выбираем чарты в infra space.
3. Выбираем dev space как цель.
4. Нажимаем [Clone Units].
5. Создаем Prod Variant из Dev Variant аналогично.

⬆️Так, мы получаем цепочку конфигураций:
[infra's Helm charts] → [dev's Helm charts] → [prod's Helm charts]

Аналогичную концепцию можем использовать в Kustomize. Мы начинаем с базовых ресурсов, а затем добавляем к ним «Dev Overlays».

⏺Мгновенный доступ к конфигурациям
1. После клонирования не требуется повторный рендеринг.
2. Получаем точные манифесты для окружений:

Dev

cub unit get --space dev prometheus --data-only

Prod

cub unit get --space prod prometheus --data-only

Получаем готовый YAML, а не шаблон или переменную.

⏺Решение сценариев «Fire Drill»
1. Так как конфигурации сохранены как данные, можно выполнять поиск и анализ без повторного рендеринга:

Поиск уязвимых образов

cub unit list --space "*" \
  --resource-type monitoring.coreos.com/v1/Prometheus \
  --where-data "spec.image ~ '.*registry.compromised.com.*'"

Поиск образов

cub unit list --space "*" \
  --resource-type monitoring.coreos.com/v1/Prometheus \
  --where-data "spec.image ~ '.*quay.io.*'"

👀Подводные камни и что делать:
• Нативные зависимости и postinstall хуки. При рендере учитывайте, что некоторые чарты рассчитывают поведение во время выполнения. Обязательный этап – прогон тестов в staging.
• Избежание версионных конфликтов Helm чартов, за счет фиксирования версий чарта; используйте lock-файлы чарта или helmfile для управления групповыми релизами.

Делимся полезными ресурсами:
⚙️Интеграция ConfigHub-workflow с CI/CD (build → render → store → apply), примеры для GitHub Actions/GitLab CI и рекомендации по кэшированию здесь.
❕How-to по Variants и GitOps (ArgoCD/Flux) – синхронизация «данных-конфигураций» с Git и кластерами (Kustomize в ArgoCD), подробнее тут.

#confighub #kubernetes #helm #devops

Анонсы и прогнозы: Docker с Dynamic MCP, Rust в Linux, тренды.

Срединедельный DevOps! Обсудим прогнозы и ключевые события уходящего года: развитие DevOps-инструментов, Rust в Linux, рост трафика с ИИ и лучшие кейсы цифровизации.

⏺Docker Desktop 4.5 и Dynamic MCP
Docker Desktop – приложение для локальной разработки, которое позволяет разработчику собирать, запускать и администрировать контейнеризованные приложения. Представили экспериментальную функцию Dynamic MCP в версии Docker Desktop 4.5. При её использовании ИИ-агенты находят и подключают MCP-серверы в реальном времени. Dynamic MCP начинает работу при подключении клиента к MCP Toolkit, а шлюз MCP предоставляет агентам набор инструментов (mcp-find, mcp-add и др.), с помощью которых им удается обнаружить, добавить и управлять серверами в ходе работы. Подробнее об особенностях функции читайте тут, а с примером использования – на GitHub.

⏺Эксперимент признан успешным: Rust в проекте ядра Linux
Эксперимент по внедрению Rust в ядро Linux, начатый в версии 6.1 в 2022 году и в котором приняли участие 173 разработчика, официально завершён. Ведущий разработчик Rust для Linux Мигель Охеда опубликовал патч для удаления из документации к ядру предупреждения о характере поддержки. Язык уже используется в производственной среде, поддерживается рядом крупных дистрибутивов Linux. Стоит учитывать, что поддержка Rust пока не охватывает все возможные конфигурации ядра, архитектуры и инструментальные цепочки. Так, часть сценариев, включая смешанные сборки с GCC и LLVM, полноценная поддержку GCC остаётся экспериментальной. Значительный объём работы предстоит как в самом ядре, так и в смежных проектах – upstream Rust, GCC и других компонентах экосистемы. Ознакомиться с комментарием можно здесь.

⏺Cloudflare: 19% годового роста трафика и растущая доля ИИ-ботов
По результатам отчёта Cloudflare за 2025 год наблюдается рост глобального интернет-трафика на 19%. Из ключевых особенностей выделяем автоматизированных агентов и сервисов ИИ, которые составляют значительную часть прироста. Подобные изменения сказываются на структуре трафика и порождают требования к новой, безопасной инфраструктуре. В отчёте представлена информация по усилению угроз безопасности и снижению устойчивости сервисов. Cloudflare зафиксировала 25 крупных распределённых DDoS-атак, которые привели к сбоям и ограничению доступа сервисов. В качестве оптимального решения компания внедрила постквантовое шифрование для 52% TLS 1.3-трафика. Подготовка к будущему, в котором квантовые компьютеры обойдут системы шифрования, началась уже сейчас. Подробности об интернет сервисах, HTTP версиях, IPv6 можете прочесть здесь.

⏺«Лидеры Цифрофизации – 2025»: номинация лучший кейс
Внедрение цифровых технологий в процессы бизнеса и управления не потеряют актуальности в 2026-м. Портал TECH совместно с бизнес-клубом Global при поддержке «Деловой России» и «Ассоциация "Руссофт"» опубликовал результаты рейтинга «Лидеры Цифрофизации – 2025», задачей которого являлось отображение лидирующих российских IT-компаний в сфере финансовых услуг, научно-исследовательской деятельности, инженерии и разработки. Победителем в лидеры номинации «Лучший кейс» стал проект по внедрению 1С, системы ML Sense в ММНИО. В число лидеров вошёл кейс «TargetADS» IT-интегратора Nixys по разработке сервиса проверки качества инвентаря, антифрода с выявлением неревантных показов, кликов, что позволило оптимизировать расход рекламного бюджета. Ознакомиться с результатами рейтинга TECH можно здесь.

#docker #dynamicmcp #rust #linux #devops

Пятничное чтиво от DevOps FM

Сегодня поговорим об инфраструктурных мелочах с большими последствиями.

👀Что могло пойти не так, но с версией Kubernetes 1.35 будет работать корректно
• Под уверенно занял порт на хосте, а потом мы выяснили, что все процессы внутри работали как root. Хорошо, что теперь это можно настроить.
• Для распределённой задачи требуется 10 рабочих подов, а запустилось только 5. Что с этим делает Kubernetes 1.35?
• Образ на узле, ресурсов хватает, но под не стартует – kubelet проверяет наличие imagePullSecrets.
• Кластер не поднялся после обновления узлов. При чём тут cgroup v1 и релиз 1.35? Читайте в статье.

👀5 ошибок DevOps стартапа (версия 2025)
• DevOps как набор инструментов
Контуры процессов, технический стек внедрены, а совместной ответственности и быстрой обратной связи всё ещё нет.
• Команды работают разрозненно
Разработка, эксплуатация и безопасность живут в своих мирах – потом долго ищут виноватых и чинят одно и то же.
• Гонка за скоростью без прозрачности.
Релизы частые, но без мониторинга и логов проблемы находят пользователи, а не команда.
• Ручные операции там, где давно нужна автоматизация.
Деплой «по инструкции», инфраструктура «на память», подборка ошибок – человеческих и повторяющихся.
• Безопасность на «потом»
Сканирование, политики и контроль доступа подключают после инцидента, когда уже поздно.
Подробности читайте здесь.

👀Побойтесь DevOps-а…
Компания искала DevOps-инженера, чтобы навести порядок в инфраструктуре, и наняла специалиста с полными правами на продовые серверы. Прошло время и сотрудничество прекратили: доступы отозвали, пароли сменили, учётки заблокировали. Спустя пять дней прод внезапно упал: сервисы недоступны, логи выглядели «разорванными», массовая утечка данных. В ходе внутреннего расследования выяснили – до увольнения был создан скрытый пользователь с правами root, через VPN добавлена отложенная cron-задача на уничтожение системы, а после срабатывания последовал шантаж с требованием выкупа. Как всё закончилось? Читайте здесь.

🚀Приятного чтения! Пусть все инциденты сегодня будут только на Habr.

#пятничноечтиво #kubernetes #devops #security

Kubernetes CPU & Memory Requests/Limits – объясняем по-человечески

В Kubernetes YAML разделы requests и limits задают минимальные и максимальные ресурсы пода, и их неверная настройка может вызвать троттлинг CPU, OOMKill и принудительное удаление пода с узла при высоких нагрузках. Грамотная конфигурация этих параметров необходима для корректного шедулинга подов и поддержания стабильности кластера. В статье автор использует сравнение Kubernetes с отелем для наглядного объяснения.

👩‍💻Kubernetes можно представить как отель:
Под = гость отеля
Узел = здание отеля с ограниченным количеством ресурсов

⏺Каждому «гостю» нужно указать:
1. Requests – минимальные ресурсы, необходимые для корректной работы
2. Limits – максимальные ресурсы, которые под может потреблять

⏺Какая роль здесь отведена CPU?
• Request – гарантированное количество CPU, влияет на планирование, но не ограничивая максимум. Под может использовать больше CPU при наличии свободных ресурсов.
• Limit задаёт жёсткое ограничение на потребление CPU. Превышение лимита приводит к троттлингу.

Итак: request = минимальное количество электричества для работы 💡; limit = предел, который выдержит предохранитель ⚡️.

⏺Как настроить requests/limits в Kubernetes

Шаг 1: Измеряем среднее и пиковое потребление CPU/памяти (kubectl top pod, Prometheus/Grafana).

Шаг 2: Requests = Среднее × 1.2 → гарантируем стабильную работу без троттлинга.

Шаг 3: Limits = Пик × 1.3–1.5 → оставляем запас, чтобы под не падал из-за OOM.

⏺Что еще необходимо помнить при задании ресурсов приложению: QoS

Quality of Service (QoS) – это механизм, с помощью которого Kubernetes классифицирует Pods по уровню гарантии ресурсов на основе заданных requests и limits.

• Guaranteed Pods
Под получает строго равные значения request и limit для CPU и памяти. Kubernetes гарантирует, что Pod не будет уничтожен до тех пор, пока не превысит свои лимиты или не будут доступны приоритетные Pods.
• Burstable Pods
Могут использовать ресурсы сверх request при свободных ресурсах узла, но при давлении на узел они уничтожаются после Guaranteed и чаще получают OOMKill.
• BestEffort
Самый низкий уровень QoS: присваивается, если у Pod‑а нет ни requests, ни limits для CPU и памяти. Такие Pods используют остаточные ресурсов узла, и в случае дефицита именно они будут удалены первыми.

🚀Понимание и правильная настройка параметров requests и limits позволяет избежать непредвиденных завершений подов и поддерживать стабильность работы кластера.

#k8s #requests #limits #cpu