Библиотека девопса | DevOps, SRE, Sysadmin
Все самое полезное для девопсера в одном канале. Наши курсы: https://clc.to/ZJ7Z1w По рекламе: @tproger_sales_bot Для обратной связи: @proglibrary_feeedback_bot РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787 Заявка: 8137718351
نمایش بیشتر📈 تحلیل کانال تلگرام Библиотека девопса | DevOps, SRE, Sysadmin
کانال Библиотека девопса | DevOps, SRE, Sysadmin (@devopsslib) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 10 338 مشترک است و جایگاه 11 827 را در دسته فناوری و برنامهها و رتبه 61 477 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 10 338 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 27 اکتبر, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر -44 و در ۲۴ ساعت گذشته برابر -3 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 10.79% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 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
#арсенал_инженера