DevOps by REBRAIN

Топ программ 2025/2026 со скидкой до -30% Недавно смотрели, какие практикумы были популярны в 2025 году, и заметили: часть этого топа так же уверенно держится и в 2026-м. Собрали 7 практикумов, которые инженеры выбирают второй год подряд. Самые популярные практикумы 2025/2026 🟢 №1 Kubernetes Base Развернёте кластер с нуля, настроите деплойменты, сервисы и сетевое взаимодействие подов на рабочей инфраструктуре. 🟢 №2 Прикладной LLM для инженеров Изучите LLM, от архитектуры Transformer до инференса (vLLM). Освойте RAG (LlamaIndex) и Fine-Tuning. Создайте Агентов с Function Calling (LangChain, n8n). 🟢№3 Networks Разберёте, как трафик реально ходит между серверами: маршрутизацию, VLAN и firewall на практике. 🟢 №4 Ansible Настроите автоматизацию серверов через плейбуки и роли — от установки пакетов до раскатки конфигов на десятки машин. 🟢№5 PostgreSQL Настроите репликацию и бэкапы, разберётесь с поведением базы под нагрузкой и типовыми задачами администрирования. 🟢№6 Grafana Соберёте дашборды с метриками инфраструктуры и настроите алерты на конкретные пороговые значения. 🟢№7 Prometheus Настроите сбор метрик с серверов и сервисов и создадите алерты, которые сработают раньше, чем упадёт прод. Скидки действуют и на остальные программы, полный список доступен на платформе или на нашем сайте🤍 К большинству практикумов есть демодоступ: можно попробовать бесплатно и понять, подходит ли программа. ↘️ Смотреть все практикумы со скидкой ⌚Распродажа закрывается уже завтра. Сейчас отличный момент, чтобы освоить новые технологии 🤍

Чек-лист для бесшовного релоада в продакшене ✅ Всегда валидируйте конфиг через nginx -t перед отправкой сигнала. ✅ Не рестартуйте контейнеры, если изменился только nginx.conf — используйте docker kill -s HUP. ✅ Настройте мониторинг процессов: после релоада количество старых воркеров (в статусе *is shutting down*) должно постепенно снижаться до нуля. Проверить состояние процессов можно командой ps ax | grep nginx. ✅ Закладывайте время жизни соединений в worker_shutdown_timeout в зависимости от специфики вашего трафика. Чтобы глубже разобраться в архитектуре веб-серверов, настроить отказоустойчивую балансировку, кэширование и работу с SSL/TLS без даунтайма, 🔥попробуйте бесплатно на демодоступе🔥 🔹Nginx - производительность, архитектура процессов, релоады и тюнинг под высокие нагрузки. 🔹Docker - сигналы процессов, управление контейнерами, PID 1 и лучшие практики. 🔹Bash - автоматизация рутины, написание безопасных скриптов деплоя и обработка ошибок.

Динамическое конфигурирование: как перезагрузить Nginx без потери соединений Поменяли конфиг Nginx, выполнили nginx -s reload — и в логах посыпались ошибки от клиентов. WebSocket-сессии упали, загрузка больших файлов прервалась, а пользователи обновляют страницы. Вроде бы сделали reload, а не restart, но часть соединений всё равно потерялась. Почему так происходит и как сделать перезагрузку по-настоящему бесшовной? Давайте разбираться. 💡 Как работает Graceful Reload Когда вы отправляете сигнал nginx -s reload, главный процесс (Master) получает сигнал SIGHUP и запускает целую цепочку событий: 1️⃣ Проверка: Master-процесс проверяет синтаксис новой конфигурации. Если там ошибка, релоад отменяется, а Nginx продолжает работать на старом конфиге (это встроенная защита). 2️⃣ Запуск новых воркеров: Если всё ок, Master запускает новые рабочие процессы (Workers) с обновленной конфигурацией. 3️⃣ Мгновенный подхват трафика: Новые воркеры сразу начинают принимать новые запросы. Им не нужно заново занимать порты — слушающие сокеты всегда удерживает Master-процесс. 4️⃣ Увядание старых воркеров: Старые процессы получают сигнал на закрытие. Они перестают принимать новые соединения (выходят из цикла `accept`) и занимаются только обслуживанием уже открытых сессий. ❓ Почему рвутся соединения Если схема идеальна, откуда ошибки? Причин обычно две: 🔹 Директива worker_shutdown_timeout: По умолчанию старые воркеры ждут завершения всех своих соединений бесконечно. Но во многих конфигах (или дефолтных чартах Kubernetes) выставляют этот таймаут (например, 5 минут). Как только время истекает, старый воркер принудительно завершается, убивая все живые WebSocket-сессии и недокачанные файлы. 🔹 Специфика HTTP/2 и HTTP/3: При релоаде Nginx отправляет клиентам фрейм GOAWAY. Это вежливое «переподключитесь, пожалуйста». Большинство современных браузеров делают это незаметно, но самописные клиенты или старые библиотеки могут выдать ошибку соединения. 😎 Правильный пайплайн обновления конфигурации Чтобы минимизировать риски в продакшене, автоматизация (CI/CD, Ansible, Bash) должна следовать строгому алгоритму. 1️⃣ Атомарная проверка и перезагрузка Никогда не делайте reload вслепую. Сначала — валидация. Пример безопасного Bash-скрипта для продакшена:

#!/bin/bash
set -e

# Проверяем синтаксис конфигурации
if nginx -t > /dev/null 2>&1; then
    echo " Настройка корректна. Перезапускаем воркеры..."
    nginx -s reload
    echo " Релоад успешно выполнен."
else
    echo " Ошибка в конфиге! Отмена операции."
    nginx -t # Выводим ошибку в консоль для логирования
    exit 1
fi

2️⃣ Особенности работы в Docker и Kubernetes В контейнерах Nginx обычно работает как PID 1. Перезапускать сам контейнер ради смены конфига — плохая идея (это гарантированный даунтайн). Вместо этого отправляйте сигнал прямо в контейнер:

docker kill -s HUP <container_name_or_id>

Совет: если вы используете динамическую генерацию конфигов (например, через consul-template или envsubst`), обязательно прогоняйте `docker exec <container> nginx -t перед тем, как слать сигнал HUP. Настройка баланса: `worker_shutdown_timeout` Внесите эту директиву в главный блок nginx.conf (на уровне main, рядом с `worker_processes`), чтобы контролировать жизненный цикл старых процессов:

worker_processes auto;
worker_shutdown_timeout 15m; # Даем старым воркерам 15 минут на завершение долгих скачиваний

🔹 Если у вас много WebSocket/EventSource соединений, ставьте таймаут больше или не ставьте вовсе (но следите за потреблением памяти старыми процессами). 🔹 Если у вас обычный REST API — достаточно 10–30 секунд, чтобы «долить» долгие запросы.

🟡 Анонс открытых практикумов на следующую неделю 1️⃣ CI/CD, который собирается 40 минут. Как ускорить? ↘ Регистрация Время проведения: 28 июля 2026, вторник, 19:00 по МСК Программа практикума: 🟢Анализ: какой этап жрет больше всего (сборка, тесты, сборка образа) 🟢Кэширование зависимостей (npm, go mod, pip) — настройка cache: key 🟢Артефакты: как не таскать туда-сюда гигабайты node_modules Кто ведёт? Дмитрий Куликов — DevOps-инженер с 7+ лет опыта в IT. Специализация: построение и автоматизация IT-инфраструктуры. --------------------------------------------------------------------------------------- 2️⃣ Как я уронил prod в пятницу вечером и что мне за это было (Postmortem) ↘ Регистрация Время проведения: 29 июля 2026, среда, 20:00 по МСК Программа практикума: 🟢Разбор реального инцидента: почему git push сломал всё, а не только код 🟢Правила написания ""Blameless Postmortem"" — отчет, после которого не увольняют 🟢3 главных правила, чтобы не повторить мою ошибку (CI/CD гейты, canary deployment) Кто ведёт? Илья Сачков — DevOps-инженер в «Аптеки — Плюс» и автор курса «Linux Basics» Rebrain. Его стек — AWS, Яндекс Облако, Kubernetes, Terraform, Ansible, а наличие сертификатов IBS по Kubernetes и MTCNA подтверждает высокий уровень владения инфраструктурными решениями. --------------------------------------------------------------------------------------- 3️⃣ Ошибки как значения: философия обработки ошибок в Go ↘ Регистрация Время проведения: 30 июля 2026, четверг, 20:00 по МСК Программа практикума: 🟢Ошибка — это значение, а не исключение 🟢Явная обработка ошибок 🟢Простота и предсказуемость 🟢Контекст ошибок 🟢Паника не заменяет ошибки 🟢Влияние на качество кода Кто ведёт? Дмитрий Гордеев — тимлид разработки облачных решений в X5 Tech с опытом работы в Go больше 5 лет

Если бы герои сериала «Пацаны» работали в IT, кем бы они были и на какие практикумы пошли бы учиться? (пока действует скидка -30%) У Воут вместо отдела инфраструктуры работает отдел по управлению репутацией: любую проблему тут решают пресс-релизом, а не диагностикой. Расписали, кем бы герои были в реальном IT-отделе. 🥊 Билли Бутчер | SRE-инженер | Практикум: Ansible Любую проблему решает вручную и с наскока, по десятому разу повторяя одну и ту же операцию. Один нормальный плейбук сэкономил бы ему пол сезона. 🎧 Хьюи Кэмпбелл | Junior-инженер | Практикум: Linux Basics Обычный парень из магазина электроники, которого бросили сразу в прод без единого дня подготовки: ему бы пригодился путь с нуля, а не выживание на месте. 🇺🇸 Хоумлендер | Senior-разработчик с легаси в проде | Практикум: Gitlab CI Годами прячет проблемы за фасадом пиар-отдела, но ни один pull request так просто не спрячешь. Нормально настроенный пайплайн ловит баги раньше, чем они долетают до прод-релиза. 🤟 Кимико | Инженер мониторинга | Практикум: Zabbix Не произносит ни слова, но всегда точно даёт понять, что что-то пошло не так: ровно так работает система алертов, которая не говорит лишнего, но обязательно предупредит о проблеме. 🧪 Французик | DevOps-инженер | Практикум: Docker Swarm Умеет за пять минут собрать случайных людей и разрозненные ресурсы в одну рабочую команду прямо в разгар кризиса. Примерно то же самое делает Docker Swarm с кластером нод. 🐟 Подводный | Junior DevOps-инженер | Практикум: Kubernetes Base Всю дорогу пытается доказать, что он не бесполезный балласт команды: прежде чем лезть в сложную оркестрацию, ему бы точно не помешало для начала разобраться с основами. Ставьте 🔥 если смотрели сериал. До 28 июля у нас действует скидка до -30% на все практикумы в честь дня сисадмина. И до -35% при полной оплате. Почти на всех практикумах есть демодоступ - можно начать бесплатно. ↘️ Выбрать практикум

❗ Открытый практикум DockerCustom Image идёт уже 30 минут Если вы ещё не с нами, скорее подключайтесь! Ссылка для входа: https://my.rebrainme.com/live-class/524 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

❗Начало Открытого практикума DockerCustom Image уже через 5 минут Встречаемся в 19:00 МСК. Ссылка для входа: https://my.rebrainme.com/live-class/524 Также вы можете подключиться к вебинару через личный кабинет, в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

Открытый практикум DockerCustom Image начнётся сегодня в 19:00 МСК. Практикум будет проходить на площадке Zoom.US Важно!!! Чтобы вы смогли без проблем к нам присоединиться, заранее протестируйте комнату по ссылке: https://zoom.us/test Ссылку для доступа отправим вам за 5 минут до начала. Либо заходите через личный кабинет в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

Bash: скрипты, которые не разваливаются в проде Bash-скрипты есть в каждой Linux-инфраструктуре: бэкапы, деплой, мониторинг, cron-джобы. Большинство пишут скрипты без строгого режима отладки, обработки сигналов и без защиты от повторного запуска, поэтому они непредсказуемо падают в проде. Мы собрали практикум по Bash, чтобы инженеры писали безопасные, отказоустойчивые скрипты для инфраструктуры: от строгого режима отладки до парсинга логов без Python. Вас ждёт: 🟢Уверенное написание скриптов с использованием ветвлений, циклов и функций 🟢Применение строгого режима отладки (set -euo pipefail) для предотвращения скрытых ошибок 🟢Профессиональный парсинг и трансформация логов с помощью sed и awk 🟢Безопасная обработка пользовательского ввода, аргументов командной строки и сигналов ОС 🟢Автоматизация выполнения скриптов через системные планировщики с защитой от параллельного запуска ↘️ Подробная программа В финальном проекте вы соберёте production-ready утилиту мониторинга дискового пространства и inode: пороги алертов через getopts, lock-файл против повторного запуска, логирование в syslog, обработка сигналов завершения через trap и запуск по расписанию cron. Практикум уровня Junior/Middle: нужна уверенная работа в командной строке Linux и опыт работы с любым консольным текстовым редактором (Nano, Vim). Отдельно добавили пять тренажёров, более сложные практические задачи: настройка веб-сервера в интерактивном режиме, аудит конфигураций, сбор диагностических данных, проверка доступности сервисов и умная очистка диска. 🎁 До 28 июля на практикум действует скидка -30% ↘️ Купить практикум Bash ↘️ Купить практикум Bash + тренажёры Напоминаем, что у нас до 28 июля действует скидка до -30% на все программы, начать можно с бесплатного демодоступа 🤍 ↘️ Выбрать практикум

🗓️ Расписание вебинаров на сегодня ⏰ 19:00 МСК - DockerCustom Image 🔗 Регистрация и программа О вебинаре напомним за 5 минут до начала на этом канале. Также вы сможете зайти через личный кабинет. 🔥 Задать вопросы и обсудить детали можно в нашем чате

❗ Открытый практикум Для чего усложнять работу с дисками? Знакомство в LVM идёт уже 30 минут Если вы ещё не с нами, скорее подключайтесь! Ссылка для входа: https://my.rebrainme.com/live-class/500 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

❗Начало Открытого практикума Для чего усложнять работу с дисками? Знакомство в LVM уже через 5 минут Встречаемся в 20:00 МСК. Ссылка для входа: https://my.rebrainme.com/live-class/500 Также вы можете подключиться к вебинару через личный кабинет, в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

🗓️ Расписание вебинаров на сегодня ⏰ 20:00 МСК - Для чего усложнять работу с дисками? Знакомство в LVM 🔗 Регистрация и программа О вебинаре напомним за 5 минут до начала на этом канале. Также вы сможете зайти через личный кабинет. 🔥 Задать вопросы и обсудить детали можно в нашем чате

Эта политика применяется к подам с лейблом app: backend и разрешает входящий трафик на порт 8080 только от подов с лейблом app: frontend в рамках того же неймспейса. Если вам нужно разрешить доступ из подов, находящихся в другом неймспейсе (например, сбор метрик Прометеусом), мы комбинируем селекторы:

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: monitoring
    podSelector:
      matchLabels:
        app: prometheus

Обратите внимание на синтаксис: когда podSelector и namespaceSelector находятся внутри одного элемента списка (как выше), они работают по логике И (под с лейблом prometheus *внутри* неймспейса monitoring). Если бы они начинались с разных дефисов (`-`) - это была бы логика ИЛИ. Практический план внедрения в продакшен 1. Проверить CNI: убедитесь, что ваш сетевой плагин (Calico, Cilium, Antrea) физически умеет обрабатывать NetworkPolicy. 2. Начните с тестового контура: не раскатывайте default-deny-all сразу на весь продакшен кластер. Выберите один некритичный неймспейс. 3. Включите логирование (если позволяет CNI): Cilium и Calico умеют логировать отброшенные пакеты (dropped packets). Это поможет увидеть, какой легитимный трафик вы случайно заблокировали. 4. Внедрите deny-all и DNS: изолируйте неймспейс и сразу дайте доступ к порту 53 CoreDNS. 5. Опишите явные взаимосвязи: переведите архитектуру приложения в YAML-манифесты политик. 6. Протестируйте доступность: используйте kubectl exec для финальной проверки:

kubectl exec -it <pod-frontend> -n production -- curl http://backend:8080

Важные правила на заметку: 🔹 Если к поду применяется несколько NetworkPolicy, разрешённым считается объединение (*Union*) всех правил. Вы не можете одной политикой «перекрыть» или запретить то, что уже разрешено другой. 🔹 Если вы включили default-deny-all для всего неймспейса, то для успешного соединения под-источник должен иметь разрешение на egress (исходящий трафик), а под-получатель - на ingress (входящий трафик). 🔹 Обратите внимание, это справедливо в рамках одного namespace. Если у вас открыт доступ в соседний неймспейс, а там нет сетевых политик, то доступ будет разрешён. 🔹 Для удобства запоминания: внутри kubernetes доступ чаще всего открывается парно egress/ingress, а вот наружу открывается только egress правило. Чтобы освоить сетевую безопасность в Kubernetes на практике, включая тонкости работы с CNI, Network Policies, Service Mesh и концепцией Zero-Trust, 🔥открывай демодоступы бесплатно🔥 и прокачивай навыки: * Kubernetes Admin - администрирование кластера, сеть, безопасность, политики. * Networks Basics - основы сетей, CNI, маршрутизация трафика внутри K8s. * Container Security - безопасность контейнеризации, изоляция сред, политики доступа.

Настройка Network Policies в Kubernetes для изоляции сервисов Кластер работает, все поды зелёные, приложения отвечают. Потом приходит пентестер или, хуже того, реальный злоумышленник. Оказывается, что любой под в кластере может достучаться до любого другого. База данных, которая должна быть закрыта от внешнего мира, доступна из каждого неймспейса. Redis, который держит кэш пользовательских сессий, можно просканировать из случайного пода-нарушителя. По умолчанию Kubernetes не ограничивает сетевой трафик между подами. Все поды в кластере могут свободно общаться друг с другом. Это удобно для разработки, но в продакшене создаёт колоссальную поверхность атаки. Один скомпрометированный под - и злоумышленник получает доступ ко всей внутренней сети кластера. Network Policies решают эту проблему. Это механизм, который позволяет определить, какие поды могут общаться друг с другом, а какие - нет. NetworkPolicy работает на уровне L3/L4 (IP/порты) и фильтрует входящий (`ingress`) и исходящий (`egress`) трафик. Важный нюанс: NetworkPolicy - это API-объект, спецификацию которого должен принудительно исполнять ваш CNI-плагин. Cilium и Calico - поддерживают политики из коробки. Популярный Flannel - нет. Если CNI не поддерживает NetworkPolicy, вы можете создать сколько угодно таких объектов, но они просто будут игнорироваться. Первым делом проверяем, какой CNI управляет сетью:

kubectl get pods -n kube-system -l k8s-app=calico-node
# или проверяем наличие Cilium
kubectl get pods -n kube-system -l app.kubernetes.io/name=cilium-agent

1️⃣Главный принцип: Deny by Default Основной подход при работе с Network Policies - deny by default, allow explicitly (запрещено по умолчанию, разрешено только явно). Вместо того чтобы пытаться точечно блокировать опасные направления, мы сначала закрываем вообще всё, а затем аккуратно открываем нужные доступы. Создаём политику, которая полностью блокирует весь входящий и исходящий трафик для всех подов в неймспейсе production:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}  # Пустой селектор выбирает ВСЕ поды в данном неймспейсе
  policyTypes:
  - Ingress
  - Egress

podSelector: {} указывает, что правило применяется ко всем без исключения подам в неймспейсе production. А пустые блоки ingress и egress (так как мы их не описали ниже) означают полный запрет. После применения этой политики поды в production оказываются в полной изоляции. У них перестают работать даже DNS-запросы, потому что это тоже исходящий (`egress`) трафик. Исправляем это. Шаг 2️⃣: разрешаем DNS-резолв Добавляем политику, которая позволит подам отправлять DNS-запросы к CoreDNS. Без этого приложения не смогут разрешить имена соседних сервисов:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {} # Применяется ко всем подам в production
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
         matchLabels:
           k8s-app: kube-dns

    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

Здесь мы используем встроенный системный лейбл kubernetes.io/metadata.name: kube-system. Он автоматически присваивается неймспейсам в Kubernetes, что избавляет нас от необходимости маркировать kube-system вручную. PodSelector позволяет задать конкретный поды с dns и открыть трафик только к ним. Шаг3️⃣: точечный доступ (Связываем Frontend и Backend) Теперь разрешаем нашему фронтенду обращаться к бэкенду. Нам нужно настроить Ingress-правило для бэкенда:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

❗ Открытый практикум Введение в протокол IPv6 идёт уже 30 минут Если вы ещё не с нами, скорее подключайтесь! Ссылка для входа: https://my.rebrainme.com/live-class/504 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

❗Начало Открытого практикума Введение в протокол IPv6 уже через 5 минут Встречаемся в 19:00 МСК. Ссылка для входа: https://my.rebrainme.com/live-class/504 Также вы можете подключиться к вебинару через личный кабинет, в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

Открытый практикум Введение в протокол IPv6 начнётся сегодня в 19:00 МСК. Практикум будет проходить на площадке Zoom.US Важно!!! Чтобы вы смогли без проблем к нам присоединиться, заранее протестируйте комнату по ссылке: https://zoom.us/test Ссылку для доступа отправим вам за 5 минут до начала. Либо заходите через личный кабинет в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

Показываем фрагмент первого эфира интенсива «ИИ-агенты для инженеров» с Артуром Сапрыкиным 👀 На видео база, без которой дальше никуда: как LLM вызывает инструменты read, search, shell, edit и git, и что модель получает на каждом шаге: задачу, файлы, историю, результаты вызовов. Отдельно разобрали permissions и compaction: они защищают проект от опасных действий и не дают контексту разрастись до бесконечности. Дальше больше 🔥 Присоединиться к интенсиву можно и сейчас, запись первого занятия уже открыта участникам. ↘️ Присоединиться к интенсиву

🗓️ Расписание вебинаров на сегодня ⏰ 19:00 МСК - Введение в протокол IPv6 🔗 Регистрация и программа О вебинаре напомним за 5 минут до начала на этом канале. Также вы сможете зайти через личный кабинет. 🔥 Задать вопросы и обсудить детали можно в нашем чате