Библиотека девопса | DevOps, SRE, Sysadmin
Все самое полезное для девопсера в одном канале. Наши курсы: https://clc.to/ZJ7Z1w По рекламе: @tproger_sales_bot Для обратной связи: @proglibrary_feeedback_bot РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787 Заявка: 8137718351
显示更多📈 Telegram 频道 Библиотека девопса | DevOps, SRE, Sysadmin 的分析概览
频道 Библиотека девопса | DevOps, SRE, Sysadmin (@devopsslib) 俄语 语言赛道中的 是活跃参与者。目前社区聚集了 10 338 名订阅者,在 技术与应用 类别中位列第 11 827,并在 俄罗斯 地区排名第 61 477 位。
📊 受众指标与增长动态
自 невідомо 创建以来,项目保持高速增长,吸引了 10 338 名订阅者。
根据 27 十月, 2026 的最新数据,频道保持稳定运转。过去 30 天订阅人数变化为 -44,过去 24 小时变化为 -3,整体触达仍然可观。
- 认证状态: 未认证
- 互动率 (ER): 平均受众互动率为 10.79%。内容发布后 24 小时内通常能获得 4.87% 的反应,占订阅者总量。
- 帖子覆盖: 每篇帖子平均可获得 1 115 次浏览,首日通常累积 503 次浏览。
- 互动与反馈: 受众积极参与,单帖平均反应数为 2。
- 主题关注点: 内容集中在 devops'a, навигация, скрипт, docker, git 等核心主题上。
📝 描述与内容策略
作者将该频道定位为表达主观观点的平台:
“Все самое полезное для девопсера в одном канале.
Наши курсы: https://clc.to/ZJ7Z1w
По рекламе: @tproger_sales_bot
Для обратной связи: @proglibrary_feeedback_bot
РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787
Заявка: 8137718351”
凭借高频更新(最新数据采集于 28 十月, 2026),频道始终保持新鲜度与高覆盖。分析显示受众积极互动,使其成为 技术与应用 类别中的关键影响点。
RequestMirror. Реальный трафик продолжает идти через Ingress-NGINX, а его копия параллельно обрабатывается новым Gateway. Можно сравнивать ответы и выявлять расхождения без риска для продакшена.
Утилита ingress2gateway. Инструмент от сообщества Kubernetes конвертирует Ingress-ресурсы в HTTPRoute и показывает места, где автоматический перевод невозможен. Хорошая отправная точка, но не финальный результат.
Проверка приоритетов маршрутов. В Gateway API более специфичный путь имеет больший приоритет. В Ingress-NGINX логика другая. Если есть пересекающиеся маршруты, порядок их срабатывания после миграции может измениться незаметно.
Начните с одного маршрута, протестируйте его в тени, убедитесь в корректности — и только потом двигайтесь дальше. Чем больше у вас тестов, описывающих реальное поведение маршрутов, тем безопаснее переход.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженераpodman auto-update. Она проверяет контейнеры с нужным лейблом и обновляет их, если в реестре появился новый образ.
Чтобы контейнер участвовал в автообновлениях, ему нужен лейбл io.containers.autoupdate. Значение registry сравнивает дайджесты образов с реестром, local проверяет локально собранные образы.
Лейбл задаётся при создании контейнера:
podman run -d --name my-service \
--label "io.containers.autoupdate=registry" \
docker.io/library/nginx:latest
В Quadlet-файле достаточно одной строки в секции [Container]:
AutoUpdate=registryСамо обновление запускается через systemd-таймер. Включается он одной командой:
systemctl --user enable --now podman-auto-update.timer
Пример конфига для обновлений каждый понедельник в 3:30 ночи:
[Timer] OnCalendar=Mon *-*-* 03:30:00 RandomizedDelaySec=30mПеред тем как писать выражение для
OnCalendar, стоит проверить его через systemd-analyze calendar — он сразу покажет следующее время срабатывания и не даст ошибиться с форматом.
Podman не угадывает проблемы заранее, он реагирует. Последовательность такая: тянет новый образ, перезапускает сервис, смотрит, запустился ли контейнер. Не запустился — возвращает предыдущий образ.
Для этого нужно три условия:
• контейнер управляется через systemd
• флаг --rollback включён
• systemd может понять, что контейнер сломан.
Самый надёжный способ это обеспечить — health check с sdnotify. Контейнер сам сигналит systemd о готовности. Если сигнал не пришёл за отведённое время, systemd фиксирует сбой и Podman откатывается.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#root_promptproduction вскрывает серьёзные проблемы: разработчикам приходится бороться с непредсказуемыми галлюцинациями моделей, нестабильными API и сложной интеграцией в существующую архитектуру.
Сегодня в 19:00 МСК в рамках нашего курса «Разработка AI-агентов» мы проведём открытый вебинар «ИИ-агенты в продакшене: от хайпа к деньгам». Спикер — Полина Полунина, руководитель AI-направления в Альфа-Банке. Будем говорить о нейросетях с позиции жёсткой инженерии.
Разберём три реальных кейса из сурового банковского энтерпрайза, напишем и запустим агента прямо в эфире, честно обсудим грабли, на которые наступает бизнес при интеграции LLM.
Тем, кто придёт на эфир, дадим промокод AGENTS на скидку 10 000 ₽ на любой тариф курса.
👉 Занять место на вебинаре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
#арсенал_инженера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
#арсенал_инженера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 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
#арсенал_инженера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
#арсенал_инженераКоманда хранит state в S3 и периодически ловит его порчу при одновременных apply. Как исключить race condition?Подсказка: одного только версионирования S3 недостаточно. Нужен механизм, который не дает двум apply работать одновременно. ➡️ Проверить себя 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #задача_со_звёздочкой
/[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
#арсенал_инженера