Библиотека девопса | DevOps, SRE, Sysadmin

💻 Аннотации Ingress-NGINX, для которых нет прямых аналогов в Gateway API Большая часть конфигурации Ingress-NGINX живёт в аннотациях — и именно здесь при переходе на Gateway API чаще всего возникают пробелы. В Gateway API нет системы аннотаций контроллера в том же смысле. Вместо них — фильтры внутри HTTPRoute, Policy Attachment и расширения конкретных реализаций. Это архитектурное решение, а не недоработка. Несколько конкретных примеров: nginx.ingress.kubernetes.io/limit-rps настраивает rate limiting. В Gateway API аналог реализуется через политики, привязанные к маршруту или gateway. Но синтаксис зависит от реализации — Istio, Envoy Gateway и Kgateway делают это по-разному. Единого стандарта пока нет. nginx.ingress.kubernetes.io/auth-url подключает внешнюю аутентификацию через subrequest. Аналог в Gateway API — внешние фильтры через ExtensionRef. Зависит от реализации и требует отдельной проверки. nginx.ingress.kubernetes.io/configuration-snippet позволяла вставлять произвольные директивы в конфиг NGINX. В Gateway API такого механизма нет — это намеренное решение ради безопасности. Если сниппеты активно использовались, нужно найти другой способ реализовать ту же логику. Составьте список всех аннотаций из текущих Ingress-ресурсов и проверьте их поддержку в выбранной реализации Gateway API. Лучше сделать это до выбора реализации, а не после. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🛠 Простой Prometheus-экспортер для мониторинга доступности Uptime Scope — это экспортер метрик на Go, который проверяет доступность URL и отдаёт результаты в формате Prometheus. Никакой лишней логики, никакой своей базы данных. Просто метрики на /metrics, которые Prometheus сам забирает по расписанию. В ToDo ещё висят динамическое обнаружение целей и retry-логика, так что на продакшн с миллионом урлов пока не рассчитан. Но для базового мониторинга своих сервисов подходит. В конфиг Prometheus добавляется стандартный scrape job. Можно сразу прописать несколько инстансов экспортера для разных регионов:

scrape_configs:
  - job_name: 'uptime_scope'
    scrape_interval: 30s
    static_configs:
      - targets:
          - 'uptimescope-eu-west:8181'
          - 'uptimescope-us-east:8181'
          - 'uptimescope-asia:8181'

Это удобный способ получить географически распределённый мониторинг доступности — запускаете агентов в разных регионах, Prometheus собирает метрики со всех. В комментариях к проекту уже подсветили несколько вещей. Во-первых, есть blackbox exporter от самой команды Prometheus — он решает похожую задачу и поддерживает динамическое обнаружение целей через сам Prometheus. Uptime Scope пока проще, но автор планирует добавить собственный dynamic discovery. Во-вторых, по коду есть несколько резонных замечаний: путь к конфигу лучше передавать флагом, интервал проверок сделать настраиваемым, добавить graceful shutdown и структурированное логирование через slog. Всё это стандартные практики для Go-сервисов. ➡️ Репозиторий 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

💿 Прочитать диск без дисковода Парень взял дешёвый USB микроскоп, посмотрел на старые диски и буквально прочитал текст, записанный на лазерном диске 40 лет назад. На лазерном диске спиралью расположены микроскопические борозды. По ним лазер считывает данные. Под обычным микроскопом видны эти борозды, как полосы. Но вот в чём кайф. Видно не просто какие-то линии. Видно структуру видеосигнала. Каждая строка видео это отдельная спираль на диске. Когда диск крутится, микроскоп видит одну строку за оборот. ➡️ Смотреть видео 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

DevOpsConf 2026: Фабрика инженерных решений 2–3 апреля, Москва. Главное событие для инженеров по автоматизации разработки, надежности и эксплуатации, архитекторов, системных администраторов, технических лидеров и ИТ-директоров. В этом году всё иначе - мы пересобрали привычный лекторий → в конструкторское бюро решений на DevOpsConf. Над чем работаем: 🔹 Работа с наследием (легаси). Поток для тех, кому достался "черный ящик" без документации. Командная игра "Почини сломанную систему на скорость" + воркшоп по анализу древнего кода с помощью ИИ. 🔹 Наблюдаемость без паники. От метрик до архитектуры и борьбы с ложными алертами. 🔹 Как говорить с госорганами и бизнесом. Про 152-ФЗ, ФСТЭК и ГОСТы для инженеров, а также мастер-классы по питчингу решений для руководства. Форматы: воркшопы, кейс‑игры, разбор инцидентов, экспертная зона. 👉 Изучить всю программу и забронировать билеты: https://tglink.io/3e56f4f5b86905?erid=2W5zFJBzVub #реклама О рекламодателе

📎 TLS в Ingress-NGINX: два режима с разным поведением при миграции Тема TLS выглядит простой, но здесь тоже есть нюансы, которые проявляются только после переключения трафика на Gateway API. Ingress-NGINX работает в двух принципиально разных режимах с TLS. _Первый_ — терминирование на уровне контроллера: сертификат прикреплён к Ingress через секрет, контроллер расшифровывает трафик и передаёт бэкенду по HTTP. В Gateway API это настраивается через listeners[].tls.mode: Terminate с указанием certificateRefs в ресурсе Gateway. _Второй_ — SSL passthrough через аннотацию nginx.ingress.kubernetes.io/ssl-passthrough: "true". Контроллер проксирует зашифрованный поток напрямую к поду, не расшифровывая его. В Gateway API для этого существует отдельный тип ресурса — TLSRoute. И здесь важный момент: при passthrough контроллер не видит HTTP-заголовки. Маршрутизация по пути или заголовкам недоступна — только по SNI. Если в текущей конфигурации для одного хоста одновременно используются passthrough и HTTP-маршрутизация — это признак того, что архитектуру придётся пересматривать, а не просто переписывать манифесты. Зафиксируйте для каждого хоста, какой режим TLS используется. Это определит не только синтаксис Gateway API, но и выбор реализации — не все из них поддерживают TLSRoute в полном объёме. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🐳 Контейнер падает при старте Когда Docker контейнер вылетает прямо после запуска, это всегда выглядит странно. Особенно если локально всё работало нормально. Давайте разберёмся, что чаще всего заставляет контейнер выходить с ошибкой. Первое правило: смотрите логи Контейнер существует ровно столько, сколько выполняется процесс внутри него. Если процесс завершился или вообще не запустился, контейнер упадёт. Это закономерно, но информация об ошибке может быть скрыта.

docker logs 

Запустите эту команду сразу, как только контейнер упал. Часто там будет сразу видно, что случилось. Если логов мало, добавьте флаг --tail 100 или посмотрите всё целиком через --all. Рабочая директория и файлы Очень частая причина. Если приложение ищет конфиг в /app/config, а в образе это лежит в /etc/app, всё сломается. Проверьте в Dockerfile:

WORKDIR /app
COPY . .

Убедитесь, что все нужные файлы скопированы на место и структура директорий совпадает с тем, что ожидает приложение. Переменные окружения Приложение может требовать DATABASE_URL или API_KEY, и если их нет, оно не запустится. При запуске передавайте всё нужное:

docker run -e DATABASE_URL=postgres://... -e API_KEY=secret myapp:latest

Или через файл:

docker run --env-file .env myapp:latest

Проверьте документацию вашего приложения на список обязательных переменных. Runtime и зависимости Иногда базовый образ не содержит то, что нужно. Вы собрали Go приложение, положили бинарник в контейнер на основе alpine:latest, но забыли нужную библиотеку. Результат предсказуем.

FROM golang:1.21 as builder
WORKDIR /build
COPY . .
RUN go build -o app .

FROM alpine:latest
RUN apk add --no-cache ca-certificates
COPY --from=builder /build/app /usr/local/bin/

Убедитесь, что в образе есть всё необходимое. Используйте docker run -it myimage sh и проверьте вручную, работает ли приложение. Порты и привилегии Контейнер может падать из-за проблем с портами или правами. Если приложение пытается слушать на порту ниже 1024, но не запущено от root, это не сработает.

USER appuser
EXPOSE 8080

Убедитесь, что пользователь имеет нужные привилегии и приложение слушает на доступном порту. Точка входа Проверьте, правильная ли у вас ENTRYPOINT или CMD:

ENTRYPOINT ["node", "server.js"]

Если здесь опечатка или путь неверный, контейнер не запустится. Команда должна существовать и быть исполняемой. Быстрая диагностика Запустите контейнер интерактивно с sh вместо основного процесса:

docker run -it myapp:latest /bin/sh

Теперь вы внутри контейнера. Проверьте рабочую директорию, переменные окружения, наличие файлов. Попробуйте запустить приложение вручную и посмотрите, что сломается. Что проверить в первую очередь 1. Логи контейнера через docker logs 2. Переменные окружения и их значения 3. Рабочая директория и наличие файлов 4. Запуск приложения вручную внутри контейнера через /bin/sh 5. Права доступа и привилегии пользователя Если контейнер падает, проблема почти всегда в одном из этих пунктов. Диагностика займёт несколько минут, если знать, где искать. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

💥 Открытый вебинар | ИИ-агенты в продакшене: от хайпа к деньгам Агенты уже везде. Но мало кто признаётся, сколько денег сжёг на бесконечных циклах, галлюцинациях в RAG и отсутствии мониторинга. Полина Полунина, руководитель AI-направления Альфа-Банка, расскажет честно: ▪️ Чем агент отличается от «просто GPT с промптом» и когда бизнесу достаточно обычного LLM ▪️ 3 реальных кейса из корпоративной среды: что взлетело, а что нет ▪️ Live-демо работающего агента ▪️ ТОП-5 граблей, на которые наступают команды при внедрении ⏱️ 10 марта в 19:00 (МСК) 🎁 Участники получат промокод на скидку на самый полный курс по ИИ-агентам 👉 Регистрируйся

👍 Весенние новости Совсем скоро всё оттает, а пока что вспоминаем первую неделю весны. — Linux 7.0 стартовал неспокойно — Хватит быть хорошим — elementary OS 8.1.1 — Nitrux 6.0.0 — Ingress-NGINX уходит 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #дайджест_недели

👨‍💻 Перезапись путей: скрытая логика, которая ломает маршрутизацию Продолжаем цикл о подводных камнях перед отставкой Ingress-NGINX. Сегодня — перезапись путей. Это одна из самых используемых функций контроллера и одна из самых болезненных при переносе на Gateway API. В Ingress-NGINX перезапись настраивается через аннотацию nginx.ingress.kubernetes.io/rewrite-target. Например, паттерн /api/(.*) с rewrite-target /$1 отрежет префикс /api и передаст бэкенду оставшуюся часть пути. Проблема в том, что Ingress-NGINX _переписывает весь путь целиком_, а не только совпавшую часть. Это отличается от поведения большинства других прокси. Если бэкенд ожидает определённую структуру пути — поведение после миграции может измениться даже при формально правильном переводе. В Gateway API перезапись реализована через фильтр URLRewrite. Логика другая: можно заменить префикс или весь путь. Прямого аналога подстановки через $1, $2 нет. Конфигурации с несколькими группами захвата придётся переосмыслить. Ещё одна деталь — приоритет пересекающихся маршрутов. В Gateway API он определяется специфичностью совпадения. В Ingress-NGINX логика другая. Если у вас несколько маршрутов с похожими путями, порядок их срабатывания может поменяться после миграции. Каждый маршрут с rewrite-target нужно разобрать вручную и убедиться, что бэкенд получит именно тот путь, который ожидает. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🧑‍💻 Linux From Scratch 13: больше компонентов, systemd по умолчанию LFS это руководство по сборке Linux с нуля. Вы компилируете каждый компонент сами, из исходников. Это едва ли полезно для production систем, но отлично работает как обучение. В Linux From Scratch 13.0 обновилось 36 компонентов. Вот самые заметные: ядро Linux 6.18.10, systemd 259.1, Python 3.14.3, OpenSSL 3.6.1, SQLite 3.50.4. Все обновлено и актуально. Главное изменение: LFS 13.0 полностью переходит на systemd. Старые версии 12.4 шли с SysVinit, и это было огромным минусом для обучения, потому что современный Linux это практически всегда systemd. ➡️ Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

🤔 Не гоняйте, пацаны Terraform-собеседование — и вот вам вопрос:

Команда хранит state в S3 и периодически ловит его порчу при одновременных apply. Как исключить race condition?

Подсказка: одного только версионирования S3 недостаточно. Нужен механизм, который не дает двум apply работать одновременно. ➡️ Проверить себя 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #задача_со_звёздочкой

👨‍💻 Регулярные выражения в Ingress-NGINX работают не так, как вы думаете Разбираем особенности Ingress-NGINX перед его отставкой. Одна из самых частых причин тихих сбоев при миграции — это поведение регулярных выражений в путях маршрутизации. Предположим, нужно направлять на бэкенд только запросы, путь которых состоит ровно из трёх заглавных букв. Пишете паттерн /[A-Z]{3}, включаете аннотацию nginx.ingress.kubernetes.io/use-regex: "true" и считаете задачу решённой. На деле Ingress-NGINX обрабатывает такой паттерн как _префикс без учёта регистра_. Запрос /uuid пройдёт — потому что три буквы в начале пути есть. /some-long-path тоже пройдёт. Именно это поведение было в продакшене, даже если вы об этом не знали. При переходе на Gateway API с типом матчинга RegularExpression всё меняется. Реализации на базе Envoy — Istio, Envoy Gateway, Kgateway — делают полное совпадение с учётом регистра. Паттерн /[A-Z]{3} уже не пропустит /uuid. Запросы, которые раньше работали, начнут возвращать 404. Чтобы сохранить прежнее поведение, паттерн нужно переписать явно: /[a-zA-Z]{3}.*. Либо использовать флаг (?i), если конкретная реализация его поддерживает. Перед миграцией пройдитесь по каждому регулярному выражению и проверьте, какие запросы оно реально пропускало. Не то, что написано в паттерне, а то, что фактически проходило в продакшене. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🧑‍💻 Безопасный способ вывести ноду из строя Надо обновить ноду, поменять железо или просто перезагрузить сервер. Проблема в том, что на ноде уже крутятся поды с реальной работой. Просто выключить её нельзя. Вот тут на помощь приходит kubectl drain. Команда:

kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

Kubernetes корректно выведет все поды с ноды, перенесёт их на другие ноды в кластере и отметит саму ноду как недоступную для новых подов. Workloads при этом не упадут, они просто переедут. --ignore-daemonsets говорит системе не трогать DaemonSets, потому что они крутятся на каждой ноде и переносить их бесполезно. --delete-emptydir-data удаляет поды с пустыми томами, которые нельзя перенести нормально. Drain работает только с управляемыми подами. Если у вас валяются standalone поды без контроллера, они просто удалятся. Поэтому перед drain проверьте, что важные поды находятся в Deployments, StatefulSets или других контроллерах. После drain нода остаётся в состоянии unschedulable. Когда закончите работу, верните её обратно:

kubectl uncordon <node-name>

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #root_prompt

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пятничный_деплой

👍 На курсе по контролируемой разработке AI-агентов мы будем разбирать ровно то, о чём говорит Владислав в голосовом, но уже в формате системной практики. 📅 Старт курса — 20 апреля. Если хотите разобраться, как строить управляемые агентные системы: ➡️ Присоединяйтесь. P.S. С первого занятия будет практика: код и разбор реальных ошибок, а не только теория.

🛠 Ingress-NGINX уходит В ноябре 2025 года Kubernetes официально объявил об отставке Ingress-NGINX. Март 2026 года — финальная дата. Если вы до сих пор не думали о миграции, самое время начать. И дело не только в том, чтобы переписать манифесты. Ingress-NGINX — один из самых распространённых ingress-контроллеров в экосистеме Kubernetes. За годы использования в нём накопилось немало неочевидных особенностей поведения. Именно они создают реальную угрозу при переходе на Gateway API. Важно понять одну вещь: Ingress-NGINX и NGINX Ingress — это два разных проекта. Ingress-NGINX поддерживает сообщество Kubernetes, и он уходит. NGINX Ingress от F5 продолжает существовать. Оба используют NGINX как dataplane, но в остальном они не связаны между собой. Основной риск миграции — не синтаксис, а семантика. Казалось бы корректный перевод Ingress-манифестов в HTTPRoute может изменить фактическое поведение маршрутизации. Готовим для вас цикл постов по подводным камням при миграции. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🔄 Nitrux 6.0.0 Nitrux позиционирует себя как дистрибутив для тех, кто хочет полный контроль над железом и не готов мириться с лишними слоями абстракции. Шестая версия продолжает эту логику. Ядро и низкоуровневые компоненты Система работает на ядре Linux 6.19.2 с патчами от CachyOS. Одно из заметных изменений на уровне ядра — NVMe-накопитель теперь не уходит в глубокий режим сна. Добавлена отдельная запись в GRUB под названием «Intel Xe Mode». Она позволяет принудительно использовать драйвер xe вместо i915 на поддерживаемых GPU Intel. VxM — виртуализация с проброской GPU VxM — утилита оркестрации гипервизора, написанная на C++. Она работает через VFIO PCI passthrough и IOMMU-изоляцию, что позволяет передавать дискретную видеокарту напрямую виртуальной машине. На практике это означает близкую к нативной производительность для гостевой ОС без эмуляционных накладных расходов. NUTS переписан на C++ Nitrux Update Tool System теперь реализована на C++. Прежняя версия на Shell Script заменена клиент-серверной архитектурой с интерфейсом на MauiKit и интеграцией PolicyKit для контроля привилегированных операций. Это релиз, в котором команда последовательно избавляется от legacy-кода и переводит ключевые компоненты на C++ с нативной Wayland-интеграцией. ➡️ Release Notes 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

Топ-вакансий для девопсов за неделю DevOps-инженер — от 345 000 ₽, офис в Москве DevOps Engineer — от 250 000 до 300 000 ₽, гибрид в Москве Middle DevOps Engineer — Удалёнка ➡️ Еще больше топовых вакансий — в нашем канале Devops Jobs 🐸Библиотека devops'a #вакансия_недели

🤔 Кажется, мониторинг окончательно перестал быть «графиками на всякий случай» и стал частью управления рисками и выручкой. Yandex B2B Tech запустила Monium — observability-платформу для мониторинга и управления состоянием ИТ-систем в реальном времени. Важно, что продукт вырос из внутренней платформы Яндекса, разработанной командой Yandex Infrastructure: его использовали для мониторинга критичных сервисов, а теперь он доступен внешним компаниям. Что внутри:

1. единый интерфейс для метрик, логов и трейсов — чтобы быстро собрать полную картину по системе 2. поиск инцидентов и первопричин (особенно полезно в микросервисной архитектуре) 3. гибкий алертинг и сценарии эскалации, включая уведомления и звонки ответственным 4. мониторинг приложений, инфраструктуры и ИИ-агентов — в облаке и в on-prem среде

Внутри Яндекса с платформой ежемесячно работают около 16 тысяч сотрудников. В систему каждую секунду записывается до 3 млрд семплов метрик, 44 млн спанов и 60 ГБ логов. Платформу уже тестируют ОТП Банк и крупная FMCG-компания — хороший сигнал для enterprise-сегмента. Observability всё чаще связывают с экономическим эффектом, потому что простои и деградации напрямую бьют по доходам, а скорость диагностики становится фактором конкурентоспособности. Где больнее всего мониторинг: микросервисы, legacy-монолит, on-prem, гибрид или облако? 👇