Чек-лист для бесшовного релоада в продакшене
✅ Всегда валидируйте конфиг через 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 - автоматизация рутины, написание безопасных скриптов деплоя и обработка ошибок.

🔧 Дайджест правок июля

Привет, на связи команда Rebrain! 👋
За месяц закрыли 232 задачи: исправляли материалы и автопроверки, разбирали обратную связь студентов и менторов.
Больше всего работы пришлось на Ceph, DevOps, Linux, Kubernetes и RabbitMQ.

1️⃣ Ceph
Разобрали серию расхождений между условиями заданий, окружениями и автопроверками. Уточнили требования к именам файлов, IQN и ACL для iSCSI, CRUSH-правилам, настройкам Prometheus и Grafana. Исправили команду получения публичного ключа Ceph.
Отдельно поправили проверки, которые ожидали конкретные названия или содержимое файлов, хотя в заданиях это не было указано. Разобрались с проблемами из-за разных версий Ceph на узлах и уже развёрнутых кластеров. Учли обратную связь о необходимости обновить версию курса.

2️⃣ DevOps
Поправили автопроверки, привязанные к устаревшей инфраструктуре или одному конкретному варианту решения. Также разобрали проблемы с GitLab-токеном и повторяющимися проверками. Уточнили формулировки про git rebase, Terraform-модули и финальное задание по Terragrunt, где было неясно, сколько окружений и проектов нужно создать.

3️⃣ Kafka Admin
По итогам бета-теста доработали урок по настройке Kafka в режиме KRaft. Синхронизировали теорию и практику: уточнили параметры, которые должны различаться на нодах, добавили пропущенные проверки кластера и исправили несовпадение имени каталога после распаковки Kafka.

4️⃣ Gateway API
Уточнили проверку сервиса через внешний IP, исправили названия ресурсов и расхождение между gateway-system и фактическим envoy-gateway-system.

5️⃣ Kubernetes для Yandex Cloud
Починили команду добавления ключа Helm, ссылку на Metrics Server, порядок модулей и пример с helm template.

6️⃣ Kubernetes Admin
Обновили ссылки и разобрали замечания по ресурсам кластера, ingress и порядку обновления control plane и worker-узлов.

7️⃣ Linux Basics
Поправили опечатки, противоречия в командах и некорректные параметры find. Уточнили инструкции по SSH, установке операционной системы и созданию пользователей. Смягчили проверки, которые принимали только один способ выполнения задания, хотя корректных вариантов было несколько.

8️⃣ Linux: анализ производительности и тюнинг
Исправили ошибки в скриптах и обновили устаревшие названия показателей. Уточнили материалы про tcp_tw_reuse, ionice, cgroups, systemd и файлы в /etc/sysctl.d/. Поправили задания, где автопроверка ожидала конкретный файл или службу без явного требования в условии.

9️⃣ RabbitMQ
Исправили содержательную ошибку в примере маршрутизации: сообщения с ключами вида logs.auth.error не соответствовали указанному binding *.error.#. Уточнили роли брокера и потребителя при подтверждении доставки и поправили проверку, которая искала exchange с другим именем.

🔟 Bind
Cмягчили проверки, зависевшие от пробелов, переносов строк, комментариев и конкретных названий объектов. Расширили пояснения по TSIG, конфигурационным файлам и split-horizon DNS. Также починили отображение Mermaid-схемы.

1️⃣1️⃣ Grafana
Поправили проверки, чувствительные к пробелам и точному виду JSON, обновили параметры API и уточнили задания по Data Links, Loki и переменным дашбордов. Исправили расхождения в названиях панелей и папок.


1️⃣2️⃣ HAProxy
Доработали проверку sticky-сессий с nocache, права доступа экспортера к сокету и пример модификации HTTP-запросов, где в условии и выводе использовались разные пути.

1️⃣3️⃣ Terraform
Разобрали проблемы с квотами Yandex Cloud, расположением outputs и неочевидной необходимостью выполнить terraform plan после принудительного пересоздания ресурса.

Спасибо за вашу обратную связь💗мы ее читаем и внедряем изменения🤝

🔥 Июльские модули уже на платформе!

Материалы залиты на платформу, инфра настроена, менторы готовы отвечать на вопросы.
Не откладывайте обучение - заходите в личный кабинет и начинайте проходить курсы:

🤖 Интенсив AI Agents 👉 О практикуме
Первые вебинары уже прошли, но еще можно присоединиться, если кто-то был в отпуске или никак не решался.

🔐 Keycloak + тренажеры 👉 О практикуме
Разворачиваем SSO, настраиваем управление идентификацией и разграничение доступа в enterprise-инфраструктуре на реальных серверах.

⚡ Linux Performance & HighLoad Fundamentals + тренажеры 👉 О практикуме
Учимся находить узкие места системы, оптимизировать ядро, дисковую подсистему и готовить инфраструктуру к высоким нагрузкам.

💻 Bash + тренажеры 👉 О практикуме
Автоматизация повседневных задач инженера: от чистых скриптов до сложной обработки логов и работы с API напрямую из консоли. Всем, у кого ранее был куплен bash, вам по почте напишет поддержка с инструкцией как 🔥бесплатно🔥 обновить практикум до новой версии.

🛠️ Управление инфраструктурой и рабочими станциями 👉 О практикуме
Централизованное управление, автоматическое конфигурирование и масштабирование парка серверов и рабочих мест.

💡 Всё ещё сомневаетесь и не знаете, подойдет ли вам формат?
Мы понимаем, что перед стартом хочется «потрогать» всё руками. Уже в августе на платформе появятся бесплатные демодоступы к этим модулям. Вы сможете лично протестировать боевую инфраструктуру, оценить формат «меньше теории - больше консоли» и решить первые задачи абсолютно бесплатно.

Следите за анонсами, а тем, кто уже с нами - продуктивной практики и до встречи на платформе! 🚀

🔥 Кэширование на скорости: Redis как прокси для ускорения тяжелых SQL-запросов

🤪Отчёт по продажам за последний квартал генерируется 30 секунд.
🤪Пользователи жалуются на долгую загрузку страницы с рейтингом товаров.
🤪Аналитический дашборд открывается минуту.

Ты смотришь в мониторинг и видишь: база данных загружена на 100%, одинаковые запросы выполняются сотни раз в минуту.

Каждый тяжёлый запрос идёт напрямую в PostgreSQL или MySQL. Ресурсы базы ограничены: чем больше одновременных запросов, тем выше задержка. Часть запросов повторяется: одни и те же данные снова и снова нагружают диск, процессор и сеть.

Увеличение ресурсов БД может временно снизить задержки, но само по себе не устраняет повторяющиеся чтения и часто обходится дорого. Для таких запросов стоит рассмотреть кэширование.

Один из вариантов - паттерн Cache-Aside. Redis здесь работает как управляемый приложением кэш, а не как прозрачный прокси. Приложение сначала проверяет Redis и только при промахе кэша (*cache miss*) выполняет тяжёлый запрос к базе. Затем результат сохраняется в Redis с заданным временем жизни (TTL), а повторные запросы могут обслуживаться из кэша.

Реализация безопасного кэширования на Python выглядит так:

import json
import logging
import redis
import psycopg2
from psycopg2.extras import RealDictCursor


# Настраиваем логирование для отслеживания проблем с кэшем
logger = logging.getLogger(__name__)


class CacheService:
    def __init__(self):
        # В реальном приложении параметры передаются через конфигурацию/env
        self.redis_client = redis.Redis(
            host='redis.example.com',
            port=6379,
            decode_responses=True,
            socket_timeout=0.5,          # Быстрый отрыв, если Redis занят
            socket_connect_timeout=1.0
        )
        self.db_conn = psycopg2.connect(
            host='postgres.example.com',
            database='appdb',
            user='appuser',
            password='password'
        )
    
    def get_user_data(self, user_id):
        cache_key = f"user:{user_id}"
        
        # 1. Проверяем Redis с обработкой ошибок (Graceful Degradation)
        try:
            cached_data = self.redis_client.get(cache_key)
            if cached_data:
                return json.loads(cached_data)
        except redis.RedisError as e:
            logger.error(f"Redis error on get: {e}. Falling back to DB.")
        
        # 2. Cache miss или отказ Redis - идём в базу данных
        # RealDictCursor автоматически собирает строки в удобные dict
        with self.db_conn.cursor(cursor_factory=RealDictCursor) as cur:
            cur.execute(
                "SELECT id, name, email, last_login FROM users WHERE id = %s",
                (user_id,)
            )
            row = cur.fetchone()
            if not row:
                return None
            
            data = dict(row)
            if data.get('last_login'):
                data['last_login'] = data['last_login'].isoformat()
        
        # 3. Пытаемся сохранить данные в Redis с TTL 1 час
        try:
            self.redis_client.setex(cache_key, 3600, json.dumps(data))
        except redis.RedisError as e:
            logger.error(f"Failed to write to Redis: {e}")
            
        return data

📌 Ключевые моменты в этом коде:
🔹 Обработка ошибок (graceful degradation) — если Redis недоступен, приложение логирует ошибку и обращается к базе напрямую. Такой переход безопасен, только если база выдержит дополнительный трафик: в продакшене также нужны короткие тайм-ауты, ограничение параллелизма и защита от каскадного отказа.
🔹TTL (время жизни) — устанавливается разумный срок (в примере — 1 час). Если данные обновляются часто, TTL должен быть меньше.
🔹Сериализация — данные переводятся в JSON-строку. Это универсальный, компактный и читаемый формат для хранения структур в Redis.

Для более сложных сценариев, например, кэширования тяжёлых списков с фильтрацией и агрегацией, паттерн остается прежним. Добавим в наш сервис метод получения топа товаров:

    def get_top_products(self, category, limit=10):
        cache_key = f"top:products:{category}"
        
        try:
            cached = self.redis_client.get(cache_key)
            if cached:
                return json.loads(cached)
        except redis.RedisError as e:
            logger.error(f"Redis error on get top products: {e}")
        
        # Тяжелый SQL-запрос с сортировкой и агрегацией
        with self.db_conn.cursor(cursor_factory=RealDictCursor) as cur:
            cur.execute("""
                SELECT id, name, sales_count, rating
                FROM products
                WHERE category = %s AND active = true
                ORDER BY sales_count DESC, rating DESC
                LIMIT %s
            """, (category, limit))
            products = [dict(row) for row in cur.fetchall()]
        
        # Кэшируем результат на 10 минут
        try:
            self.redis_client.setex(cache_key, 600, json.dumps(products))
        except redis.RedisError as e:
            logger.error(f"Failed to cache top products: {e}")
            
        return products

🔄 Как поддерживать кэш в актуальном состоянии?

Для инвалидации кэша (когда данные в БД меняются) используют две основные стратегии:

1️⃣ TTL-based (Пассивная): данные сами удаляются по истечении времени. Метод прост, но есть бизнес-риск какое-то время отдавать пользователям устаревшую информацию.
2️⃣ Event-based (Активная): при любом изменении данных в БД приложение принудительно удаляет или обновляет соответствующий ключ в Redis.

Реализуем активную инвалидацию при обновлении товара:

    def update_product(self, product_id, data):
        # 1. Обновляем основную базу данных
        with self.db_conn.cursor() as cur:
            cur.execute(
                "UPDATE products SET name = %s, price = %s WHERE id = %s",
                (data['name'], data['price'], product_id)
            )
            self.db_conn.commit()
        
        # 2. Сбрасываем устаревший кэш (Инвалидация)
        try:
            self.redis_client.delete(f"product:{product_id}")
            self.redis_client.delete(f"top:products:{data['category']}")
        except redis.RedisError as e:
            # Логируем, чтобы не блокировать выполнение основной бизнес-логики
            logger.error(f"Cache invalidation failed: {e}. Cache might be stale.")

🗓️ Расписание вебинаров на сегодня

⏰ 20:00 МСК - Как взлом CI/CD приводит к компрометации Kubernetes. Разбираем реальную атаку.
🔗 Регистрация и программа

О вебинаре напомним за 5 минут до начала на этом канале.
Также вы сможете зайти через личный кабинет.

🔥 Задать вопросы и обсудить детали можно в нашем чате