DevOps FM

Дед Мороз заглянул в DevOps FM... Чтобы поздравить подписчиков с наступающим Новым годом!🎄Как снегурочки-администраторы мы благодарим вас за участие в обсуждениях, пересылки гайдов (и не только) коллегам, внесение правок и коррективов в посты о штурвалах и кораблях 👩‍💻 И говорим спасибо за то, что вы есть! В 2026 году желаем спокойных смен, реализации самых смелых идей и движения вперёд к поставленным целям! В качестве благодарности за вашу активность, продолжаем традицию дарить открытки. Если возникнет желание порадовать коллегу в офисе, версия для печати – здесь. ⏺А чтобы было чем заняться на январских, подготовили подборку постов за 2025: •Использование скрытых каталогов Unix •Слышали про bundle-uri в Git? •Стратегии по disaster recovery с Terraform •Как подготовиться к облачным инцидентам: рассказали подробнее •Выбор in-memory БД в 2025: Redis, Valkey, DragonflyDB и KeyDB •Логирование и мониторинг — топ-3 инструмента для DevOps в 2025 •От values-файлов к управлению вариантами конфигураций в ConfigHub: как перестать рендерить вслепую С наступающим Новым годом и до встречи в 2025+1👩‍💻

Как DDoS повлиял на Arch Linux и что нового в релизах Kitty Terminal, Angie? Последний новостной дайджест… в этом году. Что приготовили обновления последних дней 2025-го? ⏺Arch Linux и DDoS атаки: доступ по IPv6 Arch Linux временно отключил доступ к web-сервисам на домене archlinux.org по IPv4 в ответ на DDoS-атаку. Cайт остаётся доступным по IPv6, и сервисы AUR, Wiki, форум и GitLab продолжают работать. Если основным репозиториям недоступен доступ по IPv4, рекомендуем переключиться на зеркала, перечисленные в pacman-mirrorlist, чтобы продолжить обновления и установки. Подробнее о статусе можете прочесть здесь ,больше о доступе найдете в треде. ⏺Kitty Terminal 0.45 – стабильность и расширенные возможности превью Состоялся релиз терминала Kitty 0.45. Многофункциональная версия, с поддержкой опции GPU‑accelerated, кроссплатформенного эмулятора ориентирована на стабильность. Исходный код проекта написан на Python, C и Go и опубликован на GitHub под лицензией GNU General Public License v3.0. В версии 0.45 представили опцию choose-files для выбора файлов с интерфейсом, ориентированным на клавиатуру, и поддержкой предварительного просмотра содержимого. Новая версия решения в значительной степени ориентирована на стабильность, в ней исправлены ранее найденные некритичные ошибки. Подробнее читайте здесь. ⏺Веб-сервер Angie 1.11.0, созданный бывшей командой Nginx 24 декабря 2025 года разработчики из компании «Веб-Сервер» выпустили веб-сервер Angie 1.11.0. Форк Nginx получил сертификаты совместимости с российскими ОС «Ред ОС», Astra Linux Special Edition, «Роса Хром Сервер», «Альт» и «ФСТЭК‑версии Альт». В Angie 1.11.0 команда сосредоточилась на observability и надёжности: появился новый модуль метрик для сбора и агрегации в реальном времени с выходом в Prometheus/JSON, что упрощает детекторинг узких мест; параллельно решены проблемы с HTTP/3 и улучшена маршрутизация QUIC через BPF-доработки, а также расширена поддержка ACME (включая ALPN и отчёт о перевыпуске сертификатов в API/Prometheus), что делает работу с TLS более предсказуемой. Подробнее о релизе читайте здесь или в обзоре. #archlinux #ipv6 #linux #kittyterminal

🛡Безопасность в Docker: SBOM и выявление уязвимостей Сегодня разбираем, как обеспечить безопасность цепочки поставок в Docker на примере практического гайда Shamsher Khan: Advanced Docker Security: From Supply Chain Transparency to Network Defense. Подробно разберем обеспечение прозрачности цепочки поставок с помощью SBOM, спецификации ПО (Lab 07), а подробнее об установке эшелонированной защиты от DDoS и ботов (Lab 08) можете прочесть здесь. 👀Почему тема важна в сообществе? • В 2021 инцидент с Log4Shell, ошибкой в библиотеке Log4j, указал на большую проблему современной разработки – незнание состава контейнеров. • Кибератака SolarWinds произошла в том же году, что инцидент выше. ⏺В статье представлены две лабы, задеплоить можно уже сегодня: 1. Обеспечение прозрачности цепочки поставок с помощью SBOM (Lab 07) 2. Эшелонированная защита от DDoS и ботов (Lab 08) 💬Обеспечиваем безопасность цепочки поставок со SBOM (Lab 07) Рассмотрим Dockerfile:

FROM python:3.11-slim 
COPY requirements.txt . 
RUN pip install -r requirements.txt 
COPY app.py . CMD ["python", "app.py"]

Вопрос знатокам: какие пакеты в этом образе? Без SBOM мы можем догадаться: e.g. Python 3.11, requirements.txt и OS уязвимости. SBOM позволяет получить полный список всех компонентов, версий и лицензий, сгенерированный за секунды. 🚀На старт, внимание, SBOM В статье представлен демо-скрипт для выполнения с последовательностью из 12-ти шагов. 💬Шаг 1: установка инструментов.

# Install Syft (SBOM generation) 
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin 

# Install Grype (vulnerability scanning) 
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin 

# Verify installation 
syft version grype version

💬Шаг 2: установка SBOM

From a Docker image
syft nginx:alpine -o spdx-json > nginx-sbom.json

# From a directory
syft dir:./myapp -o cyclonedx-json > myapp-sbom.json

# Multiple formats at once
syft nginx:alpine -o spdx-json=sbom.spdx.json -o cyclonedx-json=sbom.cdx.json

💬Шаг 3: выявляем уязвимости

# Scan the SBOM
grype sbom:./nginx-sbom.json

# Or scan image directly
grype nginx:alpine

💬Шаг 4: сравниваем версии SBOM

# Generate SBOMs for two versions
syft myapp:v1.0 -o json > v1.0-sbom.json
syft myapp:v2.0 -o json > v2.0-sbom.json

# Compare (using provided script)
./compare-sboms.sh v1.0-sbom.json v2.0-sbom.json

💬Шаг 5: выявляем уязвимости в SBOM

# Scan the SBOM
grype sbom:./nginx-sbom.spdx.json

# Or scan image directly
grype nginx:alpine

💬Шаг 6: определяем типы уязвимостей по параметрам

# Only show CRITICAL and HIGH
grype nginx:alpine --fail-on high

# Only show CRITICAL
grype nginx:alpine --fail-on critical

# Show only specific severity
grype nginx:alpine -o json | jq '.matches[] | select(.vulnerability.severity == "High")'

# Export vulnerabilities to JSON
grype nginx:alpine -o json > vulnerabilities.json

В шагах 7 и 8 сравниваем версии SBOM и ищем конкретные пакеты, а в 9 – рассматривает отчёт/журнал SBOM 💬Финальный шаг, 12: интеграция в CI/CD (Azure DevOps) azure-pipeline.yml

- task: Docker@2
  inputs:
    command: build
    dockerfile: '**/Dockerfile'
    tags: $(Build.BuildId)

- script: |
    syft $(imageName):$(Build.BuildId) -o spdx-json > sbom.json
  displayName: 'Generate SBOM'

- script: |
    grype sbom:./sbom.json --fail-on high
  displayName: 'Scan for Vulnerabilities'

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: 'sbom.json'
    artifactName: 'SBOM'

👨‍💻В результате, скорость реагирования при обнаружении уязвимостей сокращается с 14 до 2 дней, осуществляется поддержка 3-х форматов (SPDX, CycloneDX, Syft JSON) и гарантируется полное соответствие требованиям – EO 14028. 👩‍💻Делимся репозиториями: • Syft – установка SBOM • Grype – выявление уязвимостей • Docker Security Practical Guide – полный гайд с Lab 07 и Lab 08 #devsecops #SBOM #zerotrust #kubernetes

CPU limits в работе с Kubernetes 💬В одном из недавних постов мы рассмотрели, как объяснить особенности Kubernetes CPU & Memory Requests, Limits по-человечески, сегодня обсудим опыт пользователей Reddit в работе с лимитами в проде. Весь тред можете прочесть здесь. 🗣По результатам опроса, в котором приняло участие 247 человек, ~54% используют CPU limits, но с небольшими оговорками:

ThePapanoob В вопросе не отражены нюансы. Существует множество кейсов и в некоторых действительно нужно применять CPU limits, в других они только мешают работе

lulzmachine

Обычно начинаю без них, но всегда добавляю позже. Всеми способами избегаю «шумных соседей» (поды или контейнеры, которые

потребляют много ресурсов

и мешают другим подам нормально работать на том же ноде)

Xeroxxx

Да, мы используем лимиты в проде. Requests и Limits устанавливаются одинаково. Для скейлинга используем karpenter.

⏺Чуть меньше половины опрошенных не видит смысла в CPU limits при наличии CPU requests:

romeo_pentium

CPU limits становится причиной троттлинга и неиспользованных CPU. Мы всегда можем работать с CPU requests. Преимущество в том, что контейнер не будет использовать CPU request другого контейнера. Linux kernel троттлит ваш CPU по мере его приближения к лимиту. Без лимитов производительность выше, и я не нашел преимуществ в их установке.

Ariquitaun

CPU limits обычно приводят к снижению производительности. Нам нужны только CPU requests для гарантии базового уровня производительности на проде. С памятью дела обстоят по-другому – ООМ приведет к прекращению рабочих нагрузок в самое неподходящее время, а иногда к «убийству» нодов.

th0th

Я преимущественно использую requests, limits очень редко. Я предпочитаю следить за фактическим использованием и обвновлять request по необходимости. У меня установлены алерты на превышение CPU в нодах, использовании памяти. Мне кажется, безопаснее опираться на систему оповещений, чем на последствия использования лимитов, по типу троттлинга.

Какой алгоритм работы в проде используете вы и ваши коллеги? Делитесь опытом в комментариях👀 #kubernetes #cpu #cpu_limits #cpu_requests

Обновленная версия systemd, архитектура Debian и доступ к Docker Hardened Images (DHI) 👀Новостная среда по расписанию. Выкатываем дайджест с основными событиями за прошедшую неделю. ⏺Релиз systemd 259: что представлено в обновлении Доступна версия системного менеджера systemd 259, комплексной системы инициализации и управления, скелета современных дистрибутивов Linux. В релиз включена частичная поддержка стандартной библиотеки Musl, альтернативной библиотеки C, опция --empower в run0 для выполнения привилегированных действий без перехода на root, динамическая загрузка зависимостей libsystemd (libacl, libblkid, libseccomp и др.), встроенная работа с TAR в systemd-importd и измененный режим хранения журнала. Подробнее о новой версии читайте в статье или переходите на GitHub. ⏺LoongArch (loong64) в Debian: официальная поддержка архитектуры Более чем через два года после первоначального запуска в Ports, loong64 стала официальной архитектурой в Debian. Разработчики проекта поделились планами на включение архитектурных особенностей в предстоящий релиз Debian 14 («forky»). Адриан фон Биддер сообщил о сборке и импорте начального набора из 112 пакетов для создания начального chroot-окружения и настройки сборочного сервиса buildd. Подробный комментарий Адриана можно найти здесь, а статус buildd от loong64 тут. ⏺Открыто и бесплатно: DHI под Apache 2.0 На портале The New Stack вышла статья о предоставлении свободного доступа к защищенным образам Docker Hardened Images (DHI). DHI минимизируют риски для поставок на уровне контейнеров. Без root-прав, без лишних компонентов, без уязвимостей – и с поддержкой стандарта VEX. По результатам внутренней статистики Docker Hub фиксирует более 20 миллиардов pull-запросов в месяц. Компания стремится предоставить безопасную, готовую к продакшену платформу и установить новый отраслевой стандарт для разработчиков. Подробности о фичах в статье. А получить доступ к полному каталогу DHI и вариантам подписки можно здесь. #новостнаясреда #docker #dhi #debian

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

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

Пятничное чтиво от 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

Анонсы и прогнозы: 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

Анонсы и прогнозы: 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

Анонсы и прогнозы: 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

От 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

Не делайте так: мой пятничный деплой 👀Снова пятница, пора сворачиваться и надеяться, что ни один 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

Свежие новостные релизы, которые ещё не успели настояться Срединедельный 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

Как развернуть 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

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 #лонгрид

Вопрос-ответ от инженера 🗣Пятничный 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 #лонгрид

🎉 Результаты розыгрыша: 🏆 Победители: 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) ✔️Проверить результаты

Где тонко – там 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