1. Redis: volume или без
До этого места у нас уже есть базовый wiring: приложение видит Redis, профиль cache включается, а контейнеры поднимаются предсказуемо. Вопрос с volume для первого запуска не нужен. Но в локальной жизни он всплывает очень быстро: должен ли Redis переживать пересоздание контейнера, или выгоднее держать его disposable?
Когда вы впервые добавляете Redis в Compose-стек, рука и правда тянется сделать «как с PostgreSQL»: раз сервис, значит нужен volume, чтобы «ничего не потерялось». Рефлекс понятный, но для Redis в роли кэша он легко запутывает картину. Мы начинаем относиться к ускорителю чтений как к базе данных и тащим в локальную среду лишнее состояние там, где оно не обязательно.
У локальной среды есть два противоположных желания. С одной стороны, хочется, чтобы после перезапуска всё было «как вчера»: быстро, прогрето, удобно. С другой — хочется лёгкого reset: поднял окружение, поработал, снес, поднял снова и получил чистое, предсказуемое состояние без вчерашних хвостов. Redis как кэш чаще помогает второму сценарию.
Поэтому default-path здесь простой: сначала считаем Redis disposable. Это не мешает получить первый рабочий cache-path, а persisted-вариант рассматриваем как осознанную local policy, если он реально нужен.
2. Redis как кэш: потеря данных не страшна
Причина проста: в Container-Ready Catalog Service Redis хранит производные данные, а не источник правды. Источник правды остаётся в PostgreSQL. Если Redis пустой, следующий запрос просто делает cache miss, читает данные из базы и кладёт результат в кэш заново. Неприятно? Иногда да. Но это потеря ускорителя, а не потеря бизнес-данных.
Именно поэтому вопрос volume или без начинается не с «как бы ничего не потерять», а с «нужно ли нам вообще сохранять это состояние между пересозданиями контейнера».
/data и persistence в контейнере
Когда говорят «Redis хранит данные», у новичка в голове часто всплывает образ «файл с базой данных». На самом деле Redis в первую очередь держит данные в памяти процесса. То есть пока контейнер живёт и процесс Redis запущен — данные есть. Как только процесс перезапустился — память обнулилась. Но у Redis есть механизмы persistence, которые могут сохранять состояние на диск, чтобы потом при старте загрузиться обратно. И вот тут появляется папка /data.
В официальном Docker-образе Redis каталог /data используется как место, куда Redis может писать свои persistence-файлы (например, RDB snapshot или AOF, в зависимости от конфигурации). И дальше начинается самое Docker-важное: если /data остаётся внутри контейнера, то это всего лишь writable layer конкретного контейнера. Как только контейнер будет удалён и создан заново, это состояние исчезнет.
С named volume идея другая. Мы даём Redis отдельное место для хранения данных, которое живёт отдельно от контейнера. Контейнер можно пересоздавать сколько угодно, а volume останется. Если Redis настроен так, что реально пишет persistence-файлы в /data, то при следующем запуске он сможет их прочитать и восстановить состояние.
Полезно держать в голове простую схему:
flowchart TD
%% Идея: данные живут в памяти Redis, а /data — лишь место для (опциональной) записи persistence-файлов
A["Redis process (in memory)"] -->|optional persistence writes| B["/data внутри контейнера"]
B -->|если нет volume| C["writable layer контейнера"]
B -->|если есть named volume| D["named volume (живет отдельно)"]
Здесь специально написано «optional persistence writes», потому что persistence Redis — отдельная вселенная настроек. Нам не нужно уходить в глубину, но важно понимать: сам по себе volume ещё не делает Redis «вечным», он лишь даёт место, куда Redis может сохранить данные, если он это делает.
3. Вариант A: disposable Redis без volume
Если мы держим Redis в рамках роли «кэш для повторных чтений», то самым честным и простым вариантом является Redis без volume. Это означает, что кэш живёт ровно столько, сколько живёт конкретный контейнер, а при пересоздании окружения вы получаете «чистый кэш». В локальной разработке это даже приятно: вы часто хотите видеть поведение cache miss после старта, чтобы понимать, что кэш вообще работает, а не «просто вчера случайно осталось что-то и теперь кажется быстрым».
В compose.yaml этот вариант выглядит минимально. Обычно вы уже добавили healthcheck из прошлой лекции, поэтому покажу фрагмент именно в такой «взрослой» форме:
services:
redis:
image: redis:8.6.0
# В этом варианте мы НЕ монтируем /data: контейнер пересоздали — кэш «чистый»
# volumes: отсутствуют сознательно
healthcheck:
# Проверяем, что Redis реально отвечает, а не просто «контейнер запущен»
test: ["CMD", "redis-cli", "ping"]
interval: 5s
timeout: 3s
retries: 5Обратите внимание, что здесь нет volumes. Это не ошибка и не «забыли». Это сознательное решение: Redis как кэш допускает «потерю состояния», потому что состояние производное. Если вы сделаете docker compose down, контейнер Redis исчезнет. Когда вы сделаете docker compose up, Redis создастся заново. Кэш будет пустой, и дальше будет заполняться по мере запросов к вашему API.
Этот подход хорошо сочетается с дисциплиной reset окружения, которую мы отрабатывали на Flyway и PostgreSQL. База может жить в volume, потому что она — источник правды и вам часто важно сохранить данные между перезапусками. Redis же можно безболезненно выкинуть, потому что это всего лишь ускоритель, который сам «прогреется» естественным образом.
Если вам нужно быстро проверить, что Redis действительно жив, а не «вроде добавили в YAML и забыли», самый простой человеческий способ — пингнуть его через redis-cli прямо внутри контейнера:
# Выполняем команду внутри контейнера redis и ожидаем ответ PONG
docker compose exec redis redis-cli ping
# PONGЭто не превращает курс в «курс по Redis CLI», но даёт вам один простой и ясный индикатор readiness: Redis не только запустился, но и отвечает на базовую команду.
4. Вариант B: Redis с named volume
Иногда вам всё же хочется, чтобы Redis переживал пересоздание контейнера. Например, вы долго прогреваете кэш или хотите, чтобы после docker compose down и up локальная среда стартовала уже «тёплой». В таком случае Redis можно подключить к named volume. Это ровно тот же механизм, который мы используем для PostgreSQL, только мотивация другая: для Postgres это почти необходимость (иначе вы постоянно теряете данные), для Redis это осознанный выбор.
В Compose это выглядит так: Redis пишет в /data, мы монтируем туда named volume. Фрагмент:
services:
redis:
image: redis:8.6.0
volumes:
# Монтируем named volume в /data — сюда Redis МОЖЕТ писать persistence-файлы (если включено)
- redis-data:/data
healthcheck:
# Минимальная проверка доступности Redis
test: ["CMD", "redis-cli", "ping"]
volumes:
# Named volume живёт отдельно от контейнеров и переживает docker compose down (без -v)
redis-data:Смысл redis-data в том, что Docker хранит этот volume отдельно от контейнеров. Контейнер Redis можно удалить, а volume останется. Потом новый контейнер Redis снова примонтирует этот volume в /data.
Теперь — самая практическая часть: как это связано с down и down -v.
Когда вы делаете docker compose down, Compose удаляет контейнеры (и сеть), но named volumes по умолчанию не удаляет. Это значит, что redis-data останется. При следующем up он снова подключится.
Когда вы делаете docker compose down -v, Compose удаляет и контейнеры, и связанные named volumes. То есть redis-data исчезнет. При следующем up volume создастся заново, и Redis будет чистым, как будто вы его только что добавили.
Полезно один раз увидеть это как короткую «таблицу поведения», чтобы не держать всё в голове как магию YAML:
| Команда | Контейнер Redis | Named volume Redis | Что это значит для кэша |
|---|---|---|---|
|
удалён | остался | потенциально можно восстановить состояние (если Redis писал в /data) |
|
удалён | удалён | кэш точно станет пустым после следующего up |
И вот тут важно не попасть в ловушку ожиданий. Если вы подключили volume, это ещё не гарантия, что вы прямо «сохраняете кэш». Redis может не успеть записать persistence-файл до остановки, или persistence может быть настроен так, что он не сохраняет то, что вы ожидаете. Поэтому в рамках курса лучше относиться к volume так: это инструмент «дать Redis место для сохранения», но не обещание «кэш всегда будет переживать рестарты». Нам важнее инженерная дисциплина вокруг окружения и понятная модель жизни данных, чем абсолютная гарантия, что кэш после перезапуска будет тёплым.
Если вам хочется убедиться, что volume вообще существует и живёт своей отдельной жизнью, вы можете просто посмотреть список volumes:
# Смотрим все Docker volumes: здесь будет видно, пережил ли redis-data команду down
docker volume ls
# ... увидите что-то вроде:
# local docker-java-catalog-service_redis-dataНазвание будет с префиксом проекта Compose (обычно это имя директории), и это нормально: Docker старается не устраивать конфликтов между проектами.
5. Стратегия для app + postgres + redis
Выбор «volume или без volume» — это не вкусовщина, а продолжение архитектурной роли Redis в проекте. В сегодняшнем дне Redis — именно кэш. Это означает, что если вы сомневаетесь, начинайте с disposable-варианта. Он проще, честнее и лучше учит правильному отношению к кэшу: кэш должен улучшать жизнь, но не должен становиться второй базой данных, которую вы вынуждены спасать и бэкапить «потому что иначе всё сломается».
С disposable Redis у вас красивое разделение ответственности. PostgreSQL хранит реальное состояние каталога и export jobs, и именно поэтому у PostgreSQL есть named volume. Redis хранит только ускорители чтений, и поэтому Redis можно безболезненно пересоздавать, особенно в локальной среде, где reset окружения — нормальная ежедневная операция. Вы быстрее находите ошибки конфигурации, потому что вас не сбивают «остатки вчерашнего кэша», которые сегодня маскируют проблему.
Volume для Redis становится оправданным, когда у вас появляется конкретная причина. Например, вы хотите сравнить поведение после пересоздания окружения с «прогретым кэшем», или у вас такой локальный workflow, где вы поднимаете окружение раз в день и хотите, чтобы оно было быстрым уже сразу. Но даже в этом случае стоит держать в голове границы: Redis всё равно не источник правды, и вы не должны писать код так, будто Redis обязан помнить всё «навсегда». Если потеря Redis ломает смысл работы сервиса, значит вы незаметно сделали его основным хранилищем. Тогда меняется уже не только Compose-политика, но и вся модель приложения.
Ещё один практический момент — документирование. Если вы всё-таки включаете volume для Redis, это решение должно быть читаемым в compose.yaml. Не надо прятать его в десяти override-файлах или в «магических» скриптах. Пусть студент (или ваш будущий коллега) откроет YAML и сразу поймёт: Postgres хранит данные в volume, Redis тоже хранит что-то в volume, но по другой причине. В этом и есть ценность инфраструктурной дисциплины: она не только работает, но и объяснима.
6. Типичные ошибки при работе с Redis
Ошибка №1: автоматически делать Redis «как PostgreSQL», не осознавая разницу ролей.
Часто студент просто копирует паттерн «сервис → volume», и через пару дней начинает относиться к Redis как к месту, где «лежит что-то важное». Проблема не в volume как таковом, а в том, что мышление смещается: если Redis внезапно стал критичен, значит кэш перестал быть кэшем. В нашем проекте источник правды остаётся в PostgreSQL, а Redis хранит только производный результат чтения.
Ошибка №2: ожидать, что подключение volume гарантирует “после перезапуска кэш тёплый”.
Redis — in-memory хранилище, и факт существования volume ещё не означает, что данные туда постоянно и немедленно записываются. Persistence у Redis настраивается отдельно. Поэтому если после down/up вы видите пустой кэш, это не обязательно «Docker сломался». Это часто просто означает, что вы ожидали от кэша поведения базы данных, а он вам ничего такого не обещал.
Ошибка №3: путать restart и “пересоздание” контейнера, а затем удивляться, почему данные “то есть, то нет”.
Перезапуск одного и того же контейнера и удаление контейнера с созданием нового — разные истории. В первом случае может остаться writable layer (и даже какие-то файлы), во втором вы фактически начинаете с нуля. В Docker-окружении важно быть точным в терминах: «остановил/запустил» и «удалил/создал заново» — это разные сценарии.
Ошибка №4: случайно удалять нужные volumes командой down -v, а потом пытаться «восстановить» кэш как будто это база.
down -v — мощная команда, и она специально существует, чтобы вы могли гарантированно сбросить локальную среду. Но если вы включили persisted Redis ради удобства, а потом автоматически запускаете down -v “потому что так написано в привычке”, вы сами себе стираете состояние. Важно осознанно выбирать: вы сейчас делаете reset контейнеров или reset данных.
Ошибка №5: переносить persisted Redis в проект «по умолчанию», не оставляя простого disposable пути.
Для учебного проекта и для junior-уровня полезнее, когда базовый путь прост: Redis можно пересоздать и ничего страшного не случится. Persisted-вариант лучше оставлять как осознанное расширение, а не как единственный режим. Тогда окружение остаётся лёгким и предсказуемым, а кэш — действительно кэшем, а не второй скрытой базой данных.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ