DevOps FM
5.03K subscribers
669 photos
12 videos
10 files
783 links
♾️ Канал для тех, кто живёт слиянием разработки и эксплуатации (DevOps) и сис. администрированием.

Новости, статьи, практики, инструменты и развлекательный контент. Cloud Native, Docker, Kubernetes, БД, мониторинг и пр.

По вопросам — к Ладе @b_vls
Download Telegram
Чем запомнился январь? Релизы 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
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍9🔥54
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
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥84👍3👎1
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
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍3🔥21🤔1
🔧Чиним кластеры: игра по освоению Kubernetes

В эту пятницу отправляемся в приключение! На GitHub вышел K8sQuest для тех, кто устал читать доки и хочет разобраться, как дебажить в проде на практике. В игре представлены 5 миров и 50 уровней, где предстоит разбираться с реальными проблемами внутри кластера:
Мир 1: CrashLoopBackOff, ImagePullBackOff, pending поды, метки, порты
Мир 2: Deployments, HPA, пробы работспособности и готовности, откаты
Мир 3: Сервисы, DNS, Ingress, Сетевые политики
Мир 4: PVs, PVCs, StatefulSet-ы, ConfigMap-ы, Секреты

На 50-м уровне воцарится хаос: море ошибок, шторм неопределённости :) Будет интересно новичкам и опытным инженерам.

🚀Делитесь в комментариях, до какого уровня дошли! Желаем хороших выходных, а дежурным – спокойных смен.

#devops #k8s #пятница
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍17🔥105
Что меняется с Docker v29.1 и Docker Compose (v2.40) на GitHub-runner'ах?

Бодрый DevOps! 🖖Понедельник начинаем с анонса. GitHub анонсировал обновления Docker и Docker Compose на hosted-runner'ах, rollout стартует уже сегодня, 9 февраля.
Речь идёт о Docker Engine v29.1, Docker Compose v2.40.3. Обновление на runner-ах коснётся всех Windows и Ubuntu образов, кроме ubuntu-slim.

В ветке v29 были внесены изменения в Docker Engine API, вынесены Deprecated фичи и опции CLI. В заметках релизов указали – обязательно убрать %PROGRAMDATA%\Docker\cli-plugins из листа для CLI-плагинов на Windows, переместить на %ProgramFiles%\Docker\cli-plugins. При использовании GitHub Actions изменения могут затронуть текущие workflow’ы. Мы рекомендуем протестировать сборки на версии v29 до начала обновления runner’ов. Апдейт нацелен на повышение безопасности.

Что сделать уже сейчас:
Протестировать локально с Docker Engine v29.1 и Compose v2.40.3
Проверить сборки, пуш образы, docker-buildx, сети, volume-mounts.
Просмотреть свои workflow
Какие deprecated фичи и CLI-опции используются
Закреплять версии (pin) в критичных конвейерах или запускать тесты на self-hosted раннерах/локально перед 9 февраля.
Отсматривать изменения GitHub Actions runner images в репозитории actions/runner-images
Следить за подробностями и возможными изменениями окружений.

👀Подробнее об обновлениях читайте в:
•Docs Docker
•Репозитории

#devops #release #docker
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥84👍4🤔1
Как CPU weight влияет на Kubernetes: переход на cgroup v2

👩‍💻 Итамар Холдер из Red Hat разбирает новую формулу перехода CPU shares из cgroup v1 в CPU weight для cgroup v2. Ранее при простом пересчёте контейнеры с 1 CPU получали слишком низкий приоритет по сравнению с процессами вне Kubernetes, а мелкие CPU-запросы невозможно было точно распределять внутри под-cgroups. Новая формула восстанавливает приоритет по умолчанию.

⌨️Внедрение и практика
• Изменение реализовано на уровне OCI-рантаймов (runc ≥1.3.2, crun ≥1.23), а не в Kubernetes. Внедрение новой формулы зависит от того, какой OCI-рантайм используется в вашем кластере.
runc поддерживает новую формулу с версии 1.3.2
crun – с версии 1.23
• Перед применением тестируйте значения CPU weight в staging.
• Обратите внимание на инструменты мониторинга и кастомные системы управления ресурсами – прежние формулы могут дать неверные прогнозы и метрики.
Новая формула CPU weight нужна для расстановки приоритетов контейнеров, управления CPU-запросами и для предсказуемости распределение ресурсов, что особенно важно в работе с высокими нагрузками.

Что почитать дальше:
Kubernetes GitHub Issue #131216 – подробный технический разбор с примерами и обсуждением выбора формулы.
KEP-2254: cgroup v2 – исходник cgroup v2 в Kubernetes.
Документация по cgroup в Kubernetes – актуальные рекомендации по управлению ресурсами.

#devops #kubernetes #containers
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍42🔥2
Срединедельная подборка новостей

🗣До весны осталось… два новостных дайджеста. Что запомнилось по итогам недели?

Обновления Linux
В Linux 7.0 ускорили обработку сетевых пакетов. Разработчики вручную встроили функцию timecounter_cyc2time(), т.к. компилятор не справлялся с этим автоматически. В тестах это дало +12% производительности UDP на 100ГБ сетевых картах. Такая оптимизация важна для новых сетевых протоколов, которые требуют точных отметок времени, например для Swift congestion control в TCP. Кроме того, улучшили работу подсистемы таймеров при переходе сервера в режим ожидания. Коммит – здесь, подробности – тут.

Chrome 145 – обновления безопасности
Google анонсировала стабильную версию браузера. Традиционно, усилили безопасность и обновили sandbox. Также добавили DBSC (Device Bound Session Credentials) для привязки сессий к конкретному устройству. Ввели разделение прав доступа для защиты от CSRF-атак, устранили 11 уязвимостей, в том числе критические – CVE-2026-2313 (CSS), CVE-2026-2314 (Codecs), CVE-2026-2315 (WebGPU). Обратите внимание, в новой версии нельзя откатить User-Agent Reduction. Для корпоративных пользователей Google поддерживает ветку Extended Stable с 8-недельным циклом обновлений. Релиз следующей версии – 10 марта. Подробнее – тут.

Отчёт об инцидентах в GitHub
GitHub опубликовали отчёт за январь 2026, где описали два крупных инцидента. 13 января на 46 минут проблема возникла у Copilot Chat и интеграции с IDE из-за ошибки конфигурации при обновлении модели GPT‑4.1, а через два дня увеличились задержки и тайм-ауты в сервисах репозиториев, API, Actions, уведомлениях и при авторизации при обновлении инфраструктуры БД. Инциденты от 9 февраля войдут в отчёт марта, а подробнее о решениях – здесь.

В каких средах Kubernetes HPA менее эффективен?
На InfoQ выкатили статью о проблемах autoscaling-а приложений для edge-инфраструктуры в Kubernetes. В ней автор поясняет, Horizontal Pod Autoscaler (HPA) не работает для сценариев с низкой латентностью и ограниченными ресурсами. HPA использует пропорциональную формулу и опирается на метрики типа CPU, что в edge-среде ведет к позднему масштабированию и росту числа подов. Модели не хватает гибкости при нестабильной нагрузке (IoT-шлюзы, игровые серверы). В качестве решения автор делится опытом использования Custom Pod Autoscaler (CPA), описывает архитектуру, логику на Python, интеграцию с системой метрик Prometheus, а также демонстрирует результаты нагрузочного тестирования. По сравнению с HPA алгоритм обеспечивает меньшую амплитуду колебаний числа реплик, стабильную латентность, снижение потребления CPU. Подробнее – тут.

Оптимизация работы с дашбордами
Fiveonefour Docs разобрали, как снизить нагрузку на базы OLTP и улучшить производительность дашбордов. В гайде автор описывает настройку CDC (Debezium, ClickPipes), репликацию данных и безопасный переход на ClickHouse без изменения логики. В статье также описан ИИ-workflow через MooseStack, где ассистенты (Claude Code, Cursor, Codex) работают с проверкой запросов и тестированием на локальном окружении, что ускоряет миграцию. Почитать – здесь, разобрать гайд – тут.

#devops #kubernetes #linux #новостнаяподборка
Please open Telegram to view this post
VIEW IN TELEGRAM
15👍5🔥4
От пикселей до персонажа: ASCII-маскот в полёте

В эту пятницу знакомимся с интересным проектом от команды GitHub

👩‍💻 GitHub Copilot CLI получил анимированный ASCII-баннер, который оживляет терминал и превращает запуск CLI в перформанс.
Неочевидно, но анимация оказалась квестом: 3 секунды, 20 кадров и более 6 000 строк TypeScript. Зато! Маскот Copilot теперь красиво летает прямо в вашей консоли :)
У терминалов нет канвы, цвета ANSI ведут себя по-разному, а экранные читалки воспринимают быстро меняющиеся символы как шум. Поэтому анимация сделана в формате opt-in, цвета применяются через семантические роли (eyes, goggles, border и т.д.), а рендеринг через Ink. И баннер работает на разных ОС, терминалах, поддерживает светлые и тёмные темы, не мешает работать с CLI. К тому же, архитектура позволяет легко добавлять новые анимации, а инструмент вдохновил на создание open-source проекта ASCII Motion.

📔Читаем, смотрим, тестируем и вдохновляемся инженерным мастерством команды GitHub!

#devops #opensource
Please open Telegram to view this post
VIEW IN TELEGRAM
16👍5🔥4
Как Netflix удерживает внимание миллионов с помощью кэша

🖖В этот понедельник поговорим о высоких нагрузках. В прошлом мы уже рассмотрели, как устроена архитектура стримингового сервиса. Ежедневно Netflix обслуживает сотни миллионов пользователей по всему миру, и скорость публикации напрямую влияет на удержание. Ключевым инструментом статье от NewsLetter назвали EVCache – распределённое in-memory хранилище.

💻EVCache используется для разных задач, каждая из которых напрямую влияет на производительность. Саураб Дашора в статье описал принцип работы look-aside cache для часто используемых данных. Например, рекомендации или история просмотров. Когда приложение запрашивает данные, то проверяет кэш, если данных там нет — обращается к БД. Так, при открытии домашней страницы Netflix рекомендации и миниатюры подгружаются почти моментально.

Хранилище вмещает transient data, которая содержит информацию о текущей сессии. Данные о позиции видео, устройстве и действиях пользователя обновляются в реальном времени. Если вы ставите фильм на паузу на телефоне, то с легкостью возобновите просмотр на планшете или ноуте. Для некоторых задач EVCache работает как primary store. Например, персонализированные домашние страницы формируются ночью для каждого пользователя, а затем сохраняются в кэше. Больше о принципах работы – читайте тут.

Именно использование EVCache позволяет Netflix поддерживать масштабируемость и предоставляет комфортный UX даже при огромной аудитории и высоких нагрузках.

👩‍💻 Подробнее о характеристиках и релизах – читайте на GitHub

#архитектура #devops #кэширование
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥106👍4
Последний новостной дайджест...

... этой зимы. Сегодня разберем, как эволюционирует система алертинга в Grafana 12.4.0, что меняется после обновлений API в GitHub Actions, почему масштабирование etcd остаётся критическим фактором в Kubernetes.

Grafana 12.4.0 и прозрачное управление алертами
Выкатили релиз версии 12.4.0, в которую внесли изменения в Grafana Alerting, политики RBAC и datasource-стек. В обновлении представили политики routing (policy selector, вкладки конфигурации, навигация), импорт конфигураций через Wizard первой итерации. Из важного – добавили метки алертов в аннотации, улучшили тестирование receiver’ов (в сторону Kubernetes-style API), а также исправили неточности во временных расчетах. В версии 12.4.0 оптимизировали преобразование regex в label matchers для Prometheus, ввели поддержку serverless для Elasticsearch и переменных в Query editor для PostgreSQL и MySQL. Работа с метриками и логами стала более предсказуемой. Ознакомиться с релизом – здесь.

Что нового в GitHub Actions?
Внесли обновления в API workflow dispatch: теперь при ручном запуске вы получаете идентификатор и ссылки на созданный run. Благодаря параметру return_run_details вам возвращаются метаданные workflow_id, run API URL и workflow URL. Эта функция также поддерживается в GitHub CLI, начиная с версии v2.87.0. Представленные обновления значительно облегчили автоматизацию, больше никакого кастомного трекинга :) Подробнее – тут и в GitHub Actions documentation.

Что меняется с etcd при масштабировании в Kubernetes?
Если вы годами разворачиваете кластеры Kubernetes и всё еще не задумались о etcd – статья от Learnkube для вас. В Kubernetes только API-сервер напрямую взаимодействует с etcd. Планировщик, менеджер контроллеров, kubelet, kubectl и ваши операторы взаимодействуют с Kubernetes через API-сервер. Так, etcd в статье назвали частным бэкэндом. Etcd предоставляет строгую согласованность (strong consistency) через Raft, но имеет ограничения в масштабируемости. Зачем мониторить размер БД, нагрузку watch и поведение API-сервера – тут.

На портале DBI Service выкатили RAG-серию из двух статей.
В первой части сосредоточились на версионировании эбмеддингов и событийно-ориентированной архитектуре. Вместо полной переиндексации эмбеддингов Адриан Обернессер рекомендует использовать событийно-ориентированный (event-driven) подход для ИИ workflow: обновляйте только то, что меняется. Так, вы экономите деньги и снижаете нагрузку. В статье рассматриваются PostgreSQL, pgvector, Apache Flink и Debezium – но подход применим к любому векторному стеку. Всего представлено 3 уровня практических решений, под задачи проектов разной сложности. Читайте здесь.

Во второй части подборки Адриан Обернессер демонстрирует внедрение версионирования эмбедингов на примере реальной базы данных Википедии из репозитория pgvector_RAG_search_lab : 25 000 статей, триггеры, OpenAI API calls, реальные числа. Обязательно к прочтению для всех, кто хочет разобраться, как выглядят решения SKIP и EMBED на базе данных, как SELECT FOR UPDATE SKIP LOCKED работает c concurrent worker-ами и что интересного в отчёте об актуальности данных на практике. Рассмотреть – здесь. Весь код – в лабе.

#devops #opensource #postgresql #новостнаяподборка
Please open Telegram to view this post
VIEW IN TELEGRAM
17👍4🔥4🤔1
🤖«Я сыт по горло постами о магии ИИ»: агенты в разработке

В эту пятницу поговорим о наболевшем. Разработчик проекта iximiuz Labs поделился своим опытом работы с ИИ-агентами для генерации кода. Иван Величко не верит в сказки: невозможно написать абсолютно что угодно в кратчайшие сроки, без каких-либо знаний о домене или опыта программирования. В статье инженер поделился опытом работы с Claude Code и отметил, насколько инструмент реально ускоряет разработку и где дает сбой.

Оказалось, что агенты отлично работают с четко поставленными задачами, но не справляются со сложными требованиями. Например, при создании клиента для Google Cloud Storage с поддержкой SSE-C агенты долго не могли разобраться с заголовками и аутентификацией, а простая фронтенд-фича, редизайн дашборда, потребовала точных указаний и исправлений.

👀Вывод автора: агенты – мощный инструмент, но только в руках опытного разработчика, который умеет правильно декомпозировать задачи и проверять результат. Полностью автономная работа пока невозможна, особенно для сложных систем в проде.

Подробнее о плюсах и ограничениях работы с ИИ-агентами – в статье.

#DevOps #AI
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥7👍54
7 утилит Linux, которые ускорят работу в терминале

Всем DevOps! 🖖С началом весны возвращается заряд продуктивности. Сегодня собрали в подборку утилит CLI в Linux, которые ускорят загрузку, предоставят удобный мониторинг и просмотр файлов:

ripgrep (rg) – утилита для поиска по коду, логам, конфигам, инфраструктурным репозиториям. Быстрее grep, игнорирует файлы в .gitignore.
Установить на Debian/Ubuntu: sudo apt install ripgrep 
Репо: BurntSushi/ripgrep

fzf (Fuzzy Finder) – поисковая утилита для быстрого поиска файлов в больших репо, истории, выбора Git-веток и pod'ов
Установить на Debian/Ubuntu: sudo apt install fzf
Репо: junegunn/fzf

pv (Pipe Viewer) – утилита для просмотра прогресса в пайплайнах. Позволяет отследить индикатор прогресса, ожидаемое время завершения и скорость операций. Полезен для копирования больших файлов, tar/backup операций, при миграции данных и в CI скриптах.
Пример:

pv largefile.iso > /backup/largefile.iso

Подробнее – тут

aria2 — быстрый загрузчик (HTTP/FTP/BitTorrent), умеет разбивать загрузку на части и качать параллельно.
Пример использования:
aria2c -x4 http://example.com/large-iso-file.iso
Репо: aria2/aria2

duf — удобная альтернатива df: цветная табличка, графы с группировкой устройств.
Репо: muesli/duf

plocate — утилита для быстрого индексного поиска файлов (альтернатива mlocate )
Обновление базы: sudo updatedb; поиск: locate config
Подробнее – тут

🚀Желаем продуктивной недели! Делитесь вашей подборкой в комментариях.

#devops #linux
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍11🔥75
Сезоны сменяют друг друга, а наш дайджест выходит по расписанию.

👀Инцидент Trivy
1 марта зафиксировали атаку ИИ-бота: hackerbot-claw получил доступ к репозиториям в GitHub Actions. Пострадали несколько проектов Microsoft, DataDog и CNCF, а репозиторий Trivy был переименован в `aquasecurity/private-trivy `и вместо публичного кода был запушен пустой репо, массово удалены релизы, артефакты и обсуждения. Об инциденте – тут, а также в обсуждении.

На GitLab вышел патч-релиз 18.9.1, 18.8.5, 18.7.5
В релизе представлены исправления для обеспечения безопасности. Включили защиту от CVE-2026-0752 в Mermaid, и несколько DoS уязвимостей в контейнерах, Jira и обработке merge request’ов (CVE-2025-14511, CVE-2026-1662, CVE-2026-1388). Также устранили проблемы при лимите запросов в импортере Bitbucket Server, создании переменных для CI джобов и контролем доступа в пакетных репозиториях. Обратите внимание при обновлении: на одиночных nod-ах переход займет время, ожидайте downtime, на на множественных – применяйте принцип zero-downtime. Подробнее – на GitHub.

Шон Вэбб отчитался о проделанной в феврале 2026 в HardenedBSD.
Большая часть времени ушла на расследование kernel crash в ветке 15-STABLE. Ожидаем новых сборок на этой неделе или в рамках обновления 1 апреля 2026. По проекту mesh-сетей (Meshtastic + Reticulum + HardenedBSD) ведется работа по созданию proof-of-concept. Также опубликовали скрипт на Python для exec-over-meshtastic. В части инфраструктурой разработки приняли решение о постепенной миграции части репозиториев с self-hosted GitLab в Radicle. Отчёт– здесь.

На портале Percona вышел отчёт о серии уязвимостей, затрагивающих все версии Valkey.
Часть проблем исправлена в версиях valkey-server и valkey-bloom, поэтому мы настоятельно рекомендуем обновиться. Исправления затронули CVE-2025-67733, ошибки обработки символов null в скриптах Lua, CVE-2026-21864, некорректная обработка ошибок парсинга RDB в модулях, CVE-2026-21863, некорректной валидации пакетов в cluster bus и CVE-2026-27623, DoS перед аутентификацией.
Без обновления можете:
⁃ ограничить команды EVAL, EVALSHA, FCALL, RESTORE через ACL
⁃ изолировать cluster bus порт
⁃ проверить модули на корректную обработку IO-ошибок
Подробнее – здесь.

Не мигрируйте, пока не ознакомитесь
В блоге Kubernetes описали поведение Ingress-NGINX, которое важно учитывать при миграции на Gateway API. Автор уточняет, что речь пойдет исключительно об этом контроллере, а не NGINX Ingress от F5. Из основных особенностей работа с префиксами regex в Ingress-NGINX, которые не учитывает регистр. При переносе может пострадать маршрутизация. Следующая особенность – use-regex влияет на все Ingress с теми же хостами. Если хотя бы один Ingress для хоста содержит use-regex: "true", все пути считываются как regex. В Gateway API exact остаётся exact. После миграции такие запросы начнут возвращать 404. Также в статье упоминают автоматические редиректы и нормализацию URL перед matching. Как безопасно переехать – указали тут.

#devops #gitlab #valkey #kubernetes #новостная_подборка
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍8🔥42🤔1
Атака в GitHub Actions: Trivy, Microsoft, DataDog, CNCF

👩‍💻 ИИ-бот hackerbot-claw получил доступ к репозиториям в GitHub Actions, недавно писали об этом – здесь. Пользователи Reddit поделились мнением об атаке и собрали подборку советов для обеспечения безопасности в CI/CD.

Friendly-Ask6895
pull_request_target – это убийца. Проблема существует столько лет, но никто не хочет проверять конфиги, пока не стало поздно. Удивительно, что понадобился ИИ-бот, чтобы инженеры позаботились о безопасности в CI/CD.


Emotional-Drawing761
Безопасность в GitHub Actions о-очень важна, это порог входа. В нашей компании внедрили ротацию токенов, придерживаемся строгих политик для пайплайнов. Как в других компаниях обеспечивают безопасность?


Extra-Pomegranate-50
Комбо pull_request_target + checkout-of-fork уже много лет как оружие массового поражения, но атака на Trivy и Datadog все равно удивила.
Я, конечно, больше думаю о цепочках поставок. Если извлекли бинарники Trivy, запушили пустой репо, то сканер безопасности сам по себе становится вектором атаки.

davidadamns
Несмотря на негативные последствия, урок вышел ценным:
1. Проверяйте скачанные бинарники и контейнерные образы, подтверждайте подписи через Cosign/Sigstore.
2. Держите резервные инструменты безопасности (Checkov, Grype).
3. Используйте OIDC-токены вместо долгоживущих секретов.
4. Проводите аудит в GitHub Actions: не используйте pull_request_target с кодом форков, следите за ${{ }} в run.
5. Настройте автоматическую проверку зависимостей перед запуском.
6. Все образы должны быть подписаны.
7. Непроверенный код запускайте в изолированных средах (gVisor, Firecracker).
8. Включите аудит логов с хранением на несколько дней.

👩‍💻 И подборка репо:
zizmorcore/zizmor
boostsecurityio/poutine


Весь тред – найдете здесь.

👀А как вы следите за безопасностью в CI/CD? Делитесь опытом в комментариях!

#devops #reddit #инцидент
Please open Telegram to view this post
VIEW IN TELEGRAM
5👍73🔥3