DevOps FM

Релизы и прекращение поддержки: Kubespray, AWS LBC и проекты Linux

🚀Среда – маленькая дайджестная пятница. Сегодня обсудим, что меняется в Kubespray и AWS Load Balancer Controller, почему LFS и BLFS делают ставку на systemd, и как Debian GNU/Hurd из нишевого проекта выходит к стабильным релизам.

⏺Официальное заявление от служб Kubernetes
Если вы все-таки решили остаться с Ingress NGINX, у Kubernetes для вас плохие новости. После прекращения поддержки проекта – готовьтесь к атакам. Текущие версии развертывания будут продолжать работать, но без постоянного отслеживания изменений, вы узнаете о вредоносе слишком поздно. Подробнее – тут.

⏺Kubespray v.2.30.0 – поддержки Ingress NGINX больше не будет
В минорной версии Kubespray объявили о прекращении поддержки обновлений Ingress NGINX в следующих релизах, поместили в архив Dashboard, в качестве альтернативы предложен Headlamp. Опция containerd_discard_unpacked_layers доступна для containerd версии 2.1 и старше, а API адрес теперь определяется на основе переменной kube_apiserver_global_endpoint, поэтому убедитесь, что ваши endpoint-ы указаны правильно и к ним есть доступ со всех nod. Больше обновлений – здесь.

⏺Что нового в AWS Load Balancer Controller v.3.0.0?
В релизе представлена поддержка Gateway API v1.3.0, доступная для прода. В LBC поддерживаются маршруты L4 (NLBGatewayAPI), L7 (ALBGatewayAPI). В версию включили багфиксы, из важного в релизе – обновленные CRD-ы (включая Gateway CRD) и устранение критической ошибки при обновлении webhook-сертификатов (#4541). Если вы используете enableCertManager=true flag при развертывании в Helm, столкнетесь со сбоями в работе. В LBC v.3.0.0 – проблема уже решена. Подробнее о мажорной версии – тут.

⏺Изменения в Linux – LFS, BLFS переходят на systemd
Linux From Scratch (LFS), Beyond Linux From Scratch (BLFS) прекращают поддержку System V из-за повышенной нагрузки и особенностей новых требований от GNOME, Plasma от KDE.

Брюс Даббс сообщил, что в проекте работают волонтеры-энтузиасты, которые не справляются с нагрузкой. С сентября 2025 было сделано 70 коммитов в LFS и 1155 коммитов в BLFS. Даббс упоминает множественные этапы проверок при обновлениях пакетов и релизах – как для System V, так и для systemd. С требованиями от GNOME и KDE, которые ориентируются на функционал systemd, у редакции просто не будет хватать времени на миграцию и обход. Больше об анонсе – здесь

⏺Debian GNU/Hurd на FOSDEM'26 – стабильная работа и выход дистрибутивов
На FOSDEM разработчики Debian GNU/Hurd, платформы для разработки, сервера и настольной системы, представили доклад по этапам развития проекта и планам на 2026. Из отличительных особенностей – проект стабильно работает на архитектуре x86_64 с частичной поддержкой SMP, 75% пакетов теперь собираются для Hurd, добавили поддержку Rust, Go, OCaml, Java. Также нас ждёт выпуск дистрибутивов Guix/Hurd и Alpine/Hurd. Подробнее о проекте – тут.

#kubernetes #aws #linux #debian #opensource

Slash-команды в GitHub Copilot CLI

👩‍💻 Всем DevOps! Сегодня рассмотрим slash-команды, которые помогают быстрее работать с кодом и управлять контекстом прямо в терминале. Так, вы экономите время на тестировании, исправлении багов и переключении между задачами. Обзор команд – ниже.

👀Чем полезен инструмент?
GitHub Copilot CLI доступен в режиме public preview с сентября 2025 года. Инструмент пригодится при работе вне IDE: с серверами через SSH, контейнерами, CI/CD-пайплайнами, репозиториями. GitHub Copilot CLI нужен для взаимодействия внутри GitHub без переключения контекста. Подробнее – тут. Slash-команды обеспечивают быструю установку MCP-сервера, выбор ИИ-модели под текущий запрос. По сути, мы говорим о фиксированных промтах, инструкциях, которые вводим через префикс и / в CLI.

Подборка:
⏺Команды управления сессией:
/clear – очистить контекст текущей сессии. Используется при смене задач, репозиториев или если накопленный контекст начинает влиять на подсказки.
/exit, /quit – завершить сессии, выход из CLI
/session, /usage – посмотреть информацию о сессии и статистика использования. Полезны для аудита активности, мониторинга действий Copilot
⏺Работа с директориями и файлами:
/add-dir <directory> – добавить директорию для доступа Copilot. Ограничивает область видимости и повышает безопасность.
/list-dirs – показать список директорий, доступных Copilot.
/cwd [directory] – показать или сменить рабочую директорию.
⏺Настройки и конфигурация
/model [model] – выбрать модель Copilot для CLI.
/theme [show|set|list] – управлять темой терминала, единый стиль для команды.
/reset-allowed-tools – сбросить разрешения на использование инструментов. Полезна для аудита.
⏺Внешние сервисы
/agent – выбрать Copilot-агента для отдельных задач.
/delegate <prompt> – делегировать задачи агенту с pull-request-ом.
/share [file|gist] – экспортировать сессии в Markdown или GitHub Gist для документации или передачи коллегам.
/login, /logout – войти/выйти из CLI, управлять доступом, сменить пользователя
/mcp [show|add|edit|…] – управлять конфигурацией MCP-серверов, обновить CI/CD прокси-конфигурации и enterprise настройки.
/user [show|list|switch] – управлять пользователями GitHub в терминале.
/help – список всех команд.
/feedback — сообщить об ошибках команде GitHub.

📎Подробнее о каждой команде – здесь и в GitHub Docs.

#devops #github

Ingress NGINX: замены нет или миграция возможна?

👤На Reddit-е обсудили прекращение поддержки Ingress NGINX, работу кластеров, которые не получают обновления безопасности, а пользователи поделились своим негодованием и возможностями миграции. Статья CNCF по альтернативам – чуть выше, а полный тред – здесь.

Реакцию пользователей на новость можно уместить в один комментарий:

Kubrador
kubectl apply -f divorce.yaml
ах да, классическая смерть open source: «пожалуйста помогите нам» в течение 4-х лет –> «ладно, с нас хватит» –> «стоп, почему никто не помогает 🙁 » в то время, как 50% кластеров k8s внезапно понимают, что они живут в доме, построенном на фундаменте надежд и молитв.

⏺Теперь перейдем к решениям, инженеры разделились на два лагеря: первый не обновляется, т.к. не видит смысла в «лишней» работе:

32b1b46b6befce6ab149
Да ну конечно, люди используют Ingress NGINX. Я тоже не обновляюсь.
На данный момент никакого аналога с прежним функционалом нет и миграция займет много времени.
Полностью переехать на Gateway API нельзя, многие public чарты всё ещё используют Ingress. Лично я не нашёл такого аналога, чтобы точь-в-точь (если он вообще есть, потому что даже у nginx-ingress немного другие аннотации), поэтому пользуюсь тем, что есть.

Плюс, не вижу смысла, нельзя мигрировать без прерывания трафика.

Rahomka
Всё равно на проблему вообще, мы не обновляемся

⏺Второй – использует Gateway API и дает рекомендации по альтернативам:

mirrax
Вопрос к тем, кто не обновляется, в чем проблема? Что вы такого делаете, что прям зависит от аннотаций NGINX? Вы не сможете разобраться со всем этим у другого провайдера или использовать Gateway?

EpicDan
Вы же не обязаны использовать встроенные Ingress'ы в public чартах, можно для каждого приложения добавить HTTPRoute через Gateway API, работает нормально.

pilchardus_
Мне кажется, больше 50% k8s кластеров на NGINX, лол. Лично я переезжаю на Traefik на этой неделе.

me1337
Я переехал на F5 NGINX Ingress – без проблем, всё завелось.

FluidIdea
Лично мне нравятся Envoy Gateway (EG) или kgateway, по бенчмаркам хороши. Traefik – не единственный вариант.

edeltoaster
Я уже полностью переехал на Gateway API и Envoy Gateway. Плюс собрал свой кастомный образ с расширением Go-native от Coraza. Управление входящим трафиком стало заметно лучше, пока доволен.

👀Из интересного, Кэт Косгров (K8s Steering Committee) и Табита Сэйбл (SIG Security) в подкасте предположили, что не все инженеры в курсе, поддерживаются ли их кластеры Ingress NGINX, на что пользователи справедливо отметили:

Kabrandon
Не так легко узнать, работаете ли вы с Ingress NGINX? Может, вы не мейнтейнер? Если работаете с кластерами напрямую, вы по-любому знаете, на каком ingress контролере. Сомневаюсь, что вы работаете в таком случае.

Uncommon_senze
Легко понять, используете ли вы его, он не развертывается и не настраивается сам. Но да, проблема большая.

💬Что думаете об альтернативах, уже перешли на Gateway API? Делитесь опытом в комментариях.

#devops #reddit #k8s #ingress-nginx

Чем запомнился январь? Релизы Jenkins, Cluster API в Kubernetes и альтернативы Ingress-nginx

Всем DevOps! В эту среду сосредоточимся на изменения в политике безопасности Jenkins, новые сценарии обновлений в Cluster API и обсуждение альтернатив Ingress-nginx.

⏺Jenkins – изменения в политике безопасности, RPM-пакетировании для Red Hat и openSUSE
В релизе Jenkins 2.528.3 добавили поддержку Java 25 для контроллера и агентов, а также образы Windows Server 2022 для контейнеров. Для LTS RPM и DEB репозиториев введён новый GPG-ключ, который администраторам нужно принять при обновлении. Серьёзные изменения версии 2.528.3 коснулись управления Content Security Policy через интерфейс и API для плагинов. Пакеты Jenkins для Red Hat и openSUSE объединены в единый RPM-репозиторий с новым адресом: https://pkg.jenkins.io/rpm-stable/ . Для прошлых LTS-версий Jenkins (2.528.3 и раньше) сохранён отдельный архивный репозиторий: https://pkg.jenkins.io/redhat-stable-legacy/ .Больше о релизе – тут.

⏺Cluster API v1.12 – обновления «на месте» и «в цепочке»
В блоге Kubernetes вышла статья о новой версии Cluster API, инструменте для декларативного управления жизненным циклом кластеров. Подобно тому, как в Kubernetes можно использовать StatefulSets или Deployments для управления группой pod-ов, в Cluster API можно использовать MachineDeployments для управления группой nod-ов. В релизе представлены обновления in-place через update-extensions, теперь изменения применяются к существующим нодам без пересоздания, и chained upgrades для обновления несколько минорных версий без ручного вмешательства. Смотрите на GitHub – подробности о релизе, преимущества обновлений.

⏺Архив Ingress-nginx: какие альтернативы?
В уходящем году команда проекта Ingress-nginx сообщила о прекращении поддержки в марте 2026, подробнее писали тут. В блоге CNCF опубликовали статью о преимуществах и недостатках перехода на другой контроллер входящего трафика (Cilium Ingress, Traefik, HAProxy Ingress), или внедрения Kubernetes Gateway API. На примере Cilium Ingress первый вариант был признан самым быстрым: вы вносите минимальные изменения в манифесты приложений, CI/CD и работаете со встроенной функцией мониторинга. По версии CNCF переход на Gateway API от Cilium – самый оптимальный. Как мигрировать на Cillium Ingress – тут, а подробнее о переходе на Gateway API – здесь.

#devops #kubernetes #cloudnative #opensource

Новые Ops-ы: как мы дошли с Dev-а до Fin-a

В эту пятницу закрываем следующие таски: зачиллиться на дежурке (отдыхающим, просьба не завидовать 👨‍💻), не завалить прод и окунуться в историю. Если не задумывались, как от DevOps-а за 18 лет мы дошли до FinOps, зачем нам DevSec и ML – давайте разбираться вместе.

⏺DevOps умер, да здравствует DevOps!
Традиционно, считаем, что DevOps начал свой путь с модели Agile. Но мало кто упоминает пре-DevOps эру Waterfall (1970-1990-е), тёмное время для инженеров. Команды работали изолированно, Dev лишь «передавал» продукт Ops на запуск. Длинные циклы, редкие релизы, а ошибки дорого обнаруживать и ещё дороже исправлять. К счастью, в начале нулевых Agile сократил цикл от идеи до кода и дал возможность быстро тестировать гипотезы. Что было дальше, знаем: этапы роста первого (и основного) Ops-а – тут. Кстати, если вы думаете, что DevOps умирает, прочтите заметку о текущем «здоровье» – здесь.

Когда скорость разработки пришла в норму, появилась новая проблема – безопасность в CI/CD.

⏺Зачем нужна безопасность? Роль Sec-а в DevOps
Если DevOps-инженеры сосредоточены на том, как быстрее вывести приложение на рынок, этап тестирования безопасности, закономерно, уходит в конец рабочего цикла. В десятых годах 21-го века по мере совершенствования инструментов и развития процессов стало ясно – ни один отдел ИБ не успевает проверить все релизы. На помощь пришла методология DevSecOps которая устраняет уязвимости, обнаруженные в быстро меняющихся средах DevOps. В уходящем году мы успели поговорить о мифах DevSecOps, но главный вопрос открыт – что ждет DevSec сегодня? Всё об использовании инструментов 2026 читайте – тут, и там.

Как мы радовались первым чат-ботам и грезили о светлом будущем в мире ИИ. Стоило немного разобраться в его влиянии на воркфлоу и изменения цикла разработки.

⏺MLops – новый этап развития в поставке ПО
Казалось бы, процесс разработки отлажен, безопасность обеспечили, так еще и автоматизированные помощники появились. Около 8-ми лет назад компании радовались новой реальности и внедряли практики машинного обучения в рабочие процессы. Результат довольно предсказуем – около 85% проектов в области AI и ML так и не дошли до продакшена. В 2026 команды сталкиваются с техническими проблемами и сбоями в CI/CD пайплайнах и обновленной инфраструктуре (вектора DBs). Подробнее о развитии MLops – тут, а ТОП-10 инструментов ML в Ops 2026 года – здесь.

Наконец, проблемы решены, можем расслабиться… подумало сообщество, но «слишком хорошо» превратилось в «плохо».

⏺Что такое FinOps-культура и как она полезна команде?
Когда инфраструктура требовала масштабирования, её просто наращивали, и это почти не требовало объяснений. Теперь ресурсы растут соразмерно стоимости, и каждое техническое решение внезапно требует пояснений и обоснований. Оптимизация расходов – не дополнительная опция или задача под звездочкой, а новая реальность. FinOps Foundation отмечает, что компании, которые используют FinOps-практики, экономят 20–30% затрат в облаке и одновременно повышают вовлечённость команд. Team-lead инфраструктурного отдела, DevOps-инженер Nixys Пётр Рукин совместно с Практиками FinOps обозначили, кто должен заниматься внедрением культуры, как это осуществить и что с этого получают инженеры – на Habr.

А вы готовы к следующему Ops? Какие практики, по вашему мнению, станут обязательными в будущем?

#devops #devsecops #mlops #finops

Релизы и безопасность

Срединедельный DevOps! Поговорим о том, как Cozystack 0.41 добавляет MongoDB и улучшает стабильность Kubernetes, а MX Linux 25.1 возвращает поддержку dual-init-a.

⏺Cozystack v0.41.0: MongoDB
Вышел релиз версии Cozystack. В v0.41.0 добавили поддержку системы управления БД MongoDB. Она располагается наряду с PostgreSQL, MySQL и Redis. К ключевым особенностям относим интеграцию с хранилищем бэкэндов Cozystack, настраиваемые CPU, встроенный экспорт метрик для мониторинга. Чтобы развернуть MongoDB через Cozystack дашборд используйте первый и второй workflow. Также, в новой версии представлены улучшения в работы хранилища, патчи для piraeus-server, рефакторинг проверки RWX на уровне года, повышение стабильности работы Kubernetes за счет увеличения значений resourcesPreset apiServer по умолчанию до large и увеличения порог startup-probe для kube-apiserver. Подробнее о релизе – тут.

⏺Опасайтесь VoidLink
На портале Checkpoint Research опубликовали отчёт о мультифункциональном вредоносном ПО китайского происхождения. VoidLink включает 37 плагинов, среди которых есть модули для устранения следов, выхода из контейнеров, сбора SSH-ключей, токенов и API-ключей. Фреймворк ориентирован на cloud- и container-first-среды и способен стабильно работать в Kubernetes и Docker, адаптируя поведение под окружение. Используются LD_PRELOAD, загружаемые модули ядра (LKM) и eBPF. Подробнее - здесь.

⏺Бесконечность не предел: MX Linux 25.1 «Infinity»
Релиз MX Linux 25.1, Debian-based дистрибутива. Все сборки поставляются с ядром Linux 6.12 (Debian-ветка), за исключением Xfce-AHS, где используется ядро 6.18 с патчами liquorix. В AHS-сборках также обновлён Mesa до версии 25.3.3. Включены все обновления Debian до Debian 13.3 и все актуальные обновления из репозиториев MX. В релизе анонсировали возвращение поддержки dual-init (systemd + sysvinit) в едином ISO-образе, что сокращает количество сборок, systemd теперь обновляется через Debian, а не через отдельный MX-пакет, что упрощает поддержку. Для желающих установить – инструкция тут.

#devops #cozystack #mxlinux #kubernetes #platformengineering

Ко8мар в n8n: 𝗖𝗩𝗘-𝟮𝟬𝟮𝟲-𝟮𝟭𝟴𝟱𝟴

🚀Всем DevOps! Сегодня речь пойдёт о безопасности. Cyera Research Labs опубликовала отчет о CVE-2026–21858, коротко «Ni8mare», уязвимости CVSS 10.0. Пользователь Марио Кандела задеплоил кастомную ловушку в Beelzebub, чтобы отследить попытки взлома в n8n. Ниже – разбираем spray-атаку на n8n и даём рекомендации по её устранению. Полностью статью читайте – тут.

👀В чём суть проблемы?
Некорректная обработка HTTP-запросов в n8n Form Webhook.

Обычный флоу: пользователь загружает файл через форму, у запроса тип Content-Type: multipart/form-data . n8n использует Formidable для безопасного анализа загрузки, хранит файлы в случайной временной директории.
Флоу с уязвимостью: если злоумышленник меняет Content-Type на application/json, n8n использует другой парсер (`parseBody()`), который напрямую заполняет req.body.files значениями, и пользователь может взять над ними контроль.

Полная цепочка эксплуатации от Cyera здесь.

Журнал атаки:
⚫️7 января 2026: отчёт
Cyera Research Labs опубликовала подробный отчёт о Ni8mare уязвимости, которая позволяет выполнять неавторизованный удаленный код на локально развернутых экземплярах n8n.

⚫️9 января 2026, 06:58:32 UTC Начало конца
⏺Фаза 1: разведка


User-Agent: python-requests/2.32.5

Злоумышленник запрашивает /rest/settings для определения n8n-версии. Пользовательская ловушка предоставляет информацию – 1.120.0 (уязвимая)

⏺Фаза 2: spray-атака (06:58:33–06:58:35 UTC)
В течение нескольких секунд была запущена spray-атака на несколько endpoint-ов с идентичными вредоносными нагрузками



Content-Type: application/json
User-Agent: python-requests/2.32.5
{
  "data": {},
  "files": {
    "f-t8ebu1": {
      "filepath": "/etc/passwd",
      "originalFilename": "z0nojfcn.bin",
      "mimetype": "application/octet-stream",
      "size": 43492
    }
  }
}



⏺Анализируем payload
Точное совпадение с CVE-2026–21858. За 3 секунды 17 endpoint-ов подверглись атаке.

Ni8mare не даёт спать: уязвимость не требует аутентификации, легко воспроизводима и может привести к последующей полной компрометацией инстанса n8n. Censys оценивает 100.000 инстансов в сети как потенциально уязвимые. Есть ли среди них ваш?

⏺Что делать уже сейчас?
1. Немедленно обновитесь до версии 1.121.0 или более поздней
2. Закройте публичный доступ к n8n
3. Запрашивайте аутентификацию ко всем Form-ам и Webhook-ам
4. Отслеживайте логи на наличие Индикаторов Компроментации (IoCs): сетевые, HTTP-паттерны запроса, Sigma-правила

👩‍💻 Подборка полезного:
•CVE-2026–21858 — GitHub Advisory
•Конфигурация Beelzebub n8n honeypot

#devsecops #cybersecurity #vulnerability #cve

🎙️Слушаем пятничную подборку подкастов в DevOps FM!

⏺Flox, Nix, and Reproducible Software Systems от Software Engineering Daily. В новом выпуске затронули проблему воспроизводимости и безопасности в современной разработке ПО и обсудили, как подход Nix к управлению пакетами и зависимостями повышает воспроизводимость и безопасность, а также роль Flox в проектах. Болл предложил варианты деплоя без классических больших Docker-образов, поднял вопросы мультиархитектурных разрешений зависимостей (разрешение «closures» и групп пакетов) и их ограничения на практике. Узнать детали – здесь.

⏺We Broke Our EKS Cluster Autoscaler with the AL2023 Migration от Kube FM. Барт Фарелл разбирает инцидент, который возник при миграции EKS на Amazon Linux 2023. Почему после обновления AMI автоскейлер потерял AWS-права в кластере, как корректно внедрить IRSA (IAM Roles for Service Accounts), проверить зависимость конкретных подов от IAM-ролей нодов и очистить устаревшие IAM-разрешения, чтобы сократить атаки после миграции – слушайте тут.

⏺ Engineering Around Extreme S3 Scale with R. Tyler Croy от Last week in AWS. Р. Тайлер Крой, инженер Scribd, рассуждает с Кори Куинном о проблеме хранения миллиардов объектов в облачном объектном хранилище S3 и. Как организовать работу, когда простые задачи обходятся компании в 100 000 долларов. В подкасте услышите тезисы о распределении бюджета на инфраструктуру в облаке, опыт Scribd, накопленный за 18 лет на рынке. Крой настаивает – стандартные решения больше не работают при большом потоке вводных данных, нужно генерировать новые. Подробности – здесь.

Приятного прослушивания и пятниц без инцидентов🛡

#подкаст #devops #kubernetes #eks

Обновления 2026: Kubernetes 1.35, Debian 13.3, Zena и Argo

👨‍💻Уже среда? По расписанию – первый новостной дайджест этого года.

⏺Функции в Kubernetes 1.35
В начале месяца Kubernetes анонсировали функцию In-Place Pod Resize Graduates to Stable с изменением в CPU-лимитах и запросах. Отслеживайте ресурсы внутри работающего пода, без перезапуска контейнера. Также анонсировали две функции: Toleration операторов для числовых сравнений (alpha), Gt(больше чем) и Lt(меньше чем) spec.tolerations, и управления credential-плагинами для kubectl. Ознакомиться с use-кейсами по альфа-функции здесь а с полным описанием функций бета-версии тут.

⏺Обновленный Debian: исправили ошибки, добавили патчи
Вышло обновление в дистрибутиве Debian Trixie на базе ядра Linux 6.12.63-1 LTS. Команда подчеркивает – релиз не является новой версией и включает обновленный набор пакетов. В версию 13.3 были включены пакеты для ansible, apache, dpdk, flatpak,gnome-shell с upstream-релизами, исправлены ошибки в awfull, calibre, composer и др. Команда устранила комплекс проблем: переполнение целочисленных значений, некорректный анализ переменных окружения, ошибка отказа в обслуживании, инициализации длины буфера шифрования. Ознакомиться со списком пакетов тут, обновления безопасности и общая информация здесь.

⏺Мятный Linux 22.3 – что нового?
Состоялся релиз Linux Mint «Zena» на ядре Linux 6.14 и базе Ubuntu 24.04 LTS, поддержка версии осуществляется до 2029 года (LTS). В обновлении преобразовали инструмент «System Reports», актуальное название «System Information», добавили страницы для просмотра детализированного списка подключённых USB-устройств с типом, идентификатором и группировкой по контроллерам, информацию о PCI-устройствах, PCI ID и используемых драйверах. Также представили функцию управления «System Administration» со страницей «Boot menu», где вы можете задать время отображения и параметры загрузки. Подробнее об обновлении здесь, а инструкцию для сборки на Cinnamon 6.6, Xfce 4.18 и MATE 1.26 найдете тут.

⏺Argo CD Agent: управление кластерами и приложениями
Red Hat объявили о выходе Argo CD Agent совместно с релизом Red Hat OpenShift GitOps 1.19. Пользовательский интерфейс и API разворачиваются в централизованной control plane, а ключевые компоненты, такие как application-controller, – локально в каждом кластере. В релизе представлены два режима работы: управляемый и автономный. Для обеспечения отказустойчивой EDS ввели два компонента. Principle передает команды, статусы между Control hub и агентами управляющих кластеров, а Agent обеспечивает масштабируемость. Подробности обновления здесь, инструкция по установке агента тут.

#дайджест #kubernetes #linux #gitops #argocd

Начинаем год с обсуждения насущной проблемы – есть ли простой способ предоставления информации об используемых сертификатах TLS?

Вопрос цифровой безопасности волнует разработчиков, инженеров и администраторов из-за сокращения срока действия SSL/TLS-сертификатов. Процесс запущен ещё в апреле 2025, когда большинство участников CA/Browser Forum, в число которых входят Google, Apple, Mozilla и Microsoft, сообщили, что уже 15 марта использовать SSL/TLS-сертификаты по прошествии 200 дней будет невозможно. Крис Зибенманн рассуждает, в какие программы можно эффективно внедрить автоматическое отслеживание срока действия TLS-сертификатов и приходит к двум решениям:

1. В большинство приложений должна быть встроена автоматическая система отчетности в формате метрик, сообщений в логах или задан дополнительный параметр командной строки. Автор подчеркивает, что во встроенных метриках некоторых программ не хватает отчетности по времени ‘notAfter’.
2. В других, более «сложных» программах потребуется регистрировать имена файлов при первом использовании и надеяться, что они кэшируют загруженные сертификаты, а не «перечитывают» их каждый раз.

Подробнее читайте здесь.

#devops #tls

🖖Всем DevOps! Новогодние салаты кончаются, салюты отгремели, а исполнение желаний требует сил и планирования...с Новым 2026 годом!🎄

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

По результатам опроса коллег из State of DevOps, среднее количество задач на технического сотрудника выросло с 3,76 до 4,15. Жаль, не был замечен рост зарплаты... А если серьезно, на рабочем месте инженер всё больше и швец, и жнец, и на игре дудец. Помимо повышенной нагрузки возникают и другие проблемы. В крупных компаниях все действия и бездействия приходится согласовывать, а в компаниях малого и среднего бизнеса – брать больше задач и обучать джунов. Свои плюсы и минусы есть везде, но как выбрать из двух зол?

👨‍💻Если вы всё ещё в раздумьях, в какой компании можно развить компетенции и не умереть в 2026, пройдите наш тест "Я был рождён, чтобы работать в...", а в комментариях делитесь результатами.

Узнайте, где комфортно работать – тут.

P.S. для C-level и владельцев бизнесов: спасибо за ваш труд, тест – развлекательный, с юмором и стереотипами. Предлагаем поделиться мыслями в комментариях💬

Дед Мороз заглянул в 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

Channel photo updated

Обновленная версия 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