Valkey на VPS: ставим на Ubuntu 24.04, задаём пароль и ограничиваем память

В README вашего приложения написано «нужен Redis». Ладно. На Ubuntu 24.04 то, что говорит с ним на одном языке, ставится одной строкой apt: это Valkey, свободный форк. Я поставил его на чистый VPS и сделал скучные вещи по порядку: закрыл дверь, задал потолок памяти, а потом убил процесс через kill -9 и посмотрел, что осталось от данных. Всё ниже - вывод этого прогона.

Коротко. apt install valkey-server valkey-tools даёт службу, которая слушает только localhost. Пароль requirepass всё равно добавьте. Задайте maxmemory и политику: по умолчанию лимита нет вообще. Если нельзя терять последние минуты данных, включите appendonly yes. И никогда не выключайте защищённый режим.

Что такое Valkey и как он связан с Redis

Представьте словарь, который не выходит из оперативной памяти. Вы отдаёте ключ, а значение возвращается быстрее чем за миллисекунду, и время от времени копия сбрасывается на диск, чтобы после перезагрузки не начинать с пустого места. Чаще всего я встречаю его в роли хранилища сессий, очереди задач, счётчика запросов или кэша перед слишком медленной базой. История в одну строку: в 2024 году отделился от Redis 7.2.4, теперь живёт под Linux Foundation. В работе для вас ничего не меняется: те же команды, те же клиентские библиотеки, те же названия настроек, и сам сервер об этом сообщает: в его выводе стоит redis_version:7.2.4.

В Ubuntu 24.04 есть оба, что немного смешно. redis-server там 7.0.15, а valkey-server 7.2.13 (из universe, через noble-updates). Выберите один. Порт у обоих 6379, а приложению нужно одно хранилище.

Установка

Два пакета: сервер и пакет инструментов с valkey-cli (клиент командной строки), valkey-benchmark и проверялками файлов.

sudo apt update && sudo apt install -y valkey-server valkey-tools

При установке появляется пользователь valkey, включается служба systemd и сразу стартует. Загляните в юнит: там Restart=always, то есть упавший сервер поднимется сам, а от root ничего не работает. Какую версию мы получили и кто слушает порт? (Если флаги ss выглядят как шум, они расшифрованы здесь.)

Первая строка - valkey-server --version, две другие дала команда ss -ltnp | grep 6379. Оба сокета петлевые. С самой машины подключиться можно, откуда-либо ещё нельзя, и на время настройки это именно то, что нужно. Конфиг по умолчанию говорит об этом прямо: bind 127.0.0.1 -::1 и protected-mode yes.

Один раз загляните в журнал запуска. Это обычный файл, а не только journal:

sudo tail -n 20 /var/log/valkey/valkey-server.log

Наш журнал начался с жалобы: # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Предложенное лекарство, vm.overcommit_memory = 1 в /etc/sysctl.conf, я не применял: на этом сервере стоит 0. Считайте это пометкой из журнала, а не проверенным способом.

Первые команды: ключи, которые истекают

Запустите valkey-cli и потрогайте три вещи: значение со сроком жизни, счётчик и обращение после того, как срок вышел. Примерно этим весь день занят хранилище сессий или ограничитель частоты запросов.

EX 3 - три секунды жизни, ttl отсчитывает остаток. -2 значит, что ключа больше нет. -1 значило бы «живёт вечно», запомните это до раздела про память. incr создаёт ключ (со значением 1), если его не было, и прибавляет единицу на каждый вызов, причём атомарно, так что два одновременных запроса не съедят счёт друг друга.

Задайте пароль

Доступ только с localhost - уже неплохая защита. Пароль всё равно нужен: с открытым Valkey может поговорить любой локальный процесс и любой контейнер, который позже окажется в сети хоста. Не придумывайте пароль, сгенерируйте:

openssl rand -hex 24

Откройте /etc/valkey/valkey.conf в редакторе, добавьте requirepass ваша-сгенерированная-строка и перезапустите службу:

sudo systemctl restart valkey-server

Перезапуск обычный, вежливый: перед выходом сервер сохраняет данные на диск (в журнале видно Saving the final RDB snapshot before exiting), так что ничего не теряется. Теперь тот же клиент:

Четыре строки, три урока. Без пароля любая команда отскакивает. Ключ -a работает, и предупреждение выводится не зря: пока у меня была открыта сессия valkey-cli -a ..., ps aux показывал пароль целиком, а на общей машине это прочтёт кто угодно. Чтобы не светить пароль в командной строке, нужна переменная окружения, и тут подвох. В пакете из 24.04 она называется по-старому, REDISCLI_AUTH. Логично выглядящая VALKEYCLI_AUTH молча игнорируется, и клиент ведёт себя так, будто пароля нет вообще. На это у меня ушло несколько минут. Так себя ведёт valkey-cli 7.2.4 из этого пакета, в новых сборках могли исправить. valkey-benchmark переменную тоже не читает и требует -a.

Приложение подключается с тем же паролем, в строке подключения или настройках. Храните его в файле окружения или хранилище секретов, не в репозитории.

Не открывайте его в интернет

Типичная история открытого хранилища - не взлом хитрой уязвимости. Кто-то меняет bind, чтобы подключился второй сервер, забывает про остальное, и хранилище оказывается на публичном адресе без пароля. От этого у Valkey есть страховка, защищённый режим, и мы проверили, как она работает. Два пустых сетевых пространства имён изображают «сервер» и «другую машину», так что настоящая служба хоста наружу не торчала.

Адрес 10.77.0.1 - частный адрес лаборатории. Первый случай меня немного удивил: даже с bind 0.0.0.0 защищённый режим не пустил внешние подключения, потому что пароля не было. Страховка сработала. Второй случай показывает, как выглядит жизнь без неё: посторонний пишет ключи и читает настройки самого сервера (так же легко можно прочитать или стереть все данные, поэтому я остановился). Защищённый режим можно отключить строкой protected-mode no. Не пишите её. Третий случай - решение: пароль закрывает дверь, даже когда сокет открыт.

Нужен доступ с другой машины? Чище всего вообще без прямого доступа: через SSH-туннель, а сам Valkey оставить на петлевом адресе. Если приложение правда живёт на втором сервере, привяжитесь только к частному адресу, задайте пароль и пропустите в файрволе одного этого клиента, как в руководстве по nftables. TLS я здесь не проверял, поэтому как шифровать канал через публичный интернет, в статье нет.

Поставьте потолок памяти

Эту настройку пропускают чаще всего, и именно она кусается. «Из коробки» maxmemory равен 0 - «без лимита», а политика по умолчанию noeviction. Кэш, которому позволено расти бесконечно, ест память, пока OOM-киллер ядра не выберет жертву, и жертвой часто оказывается самый крупный процесс на машине: сам Valkey или база рядом (как отличить такую ситуацию от нехватки процессора).

Чинят это двумя настройками: maxmemory - потолок, maxmemory-policy - что делать, когда его достигли. Мы поставили нарочно маленький потолок 20 МБ и записали 30 000 значений по 1 КБ, по одному прогону на политику:

Это сводка трёх прогонов, каждый начинался с пустой базы. Что значат строки:

• noeviction (по умолчанию). Когда потолок достигнут, новые записи отклоняются с ошибкой OOM command not allowed, а чтение работает: key:1 остался на месте, а последний ключ не попал. Подходит для данных, которые нельзя выбрасывать, например для очереди задач, если приложение умеет обработать ошибку.
• allkeys-lru. Каждая запись проходит, а сервер тихо удаляет давно не использованные ключи, чтобы освободить место. После прогона key:1 исчез, а key:30000 был на месте. Это правильный выбор для чистого кэша, где потеря записи стоит лишь повторного вычисления.
• volatile-lru. Удаляет только ключи со сроком жизни (EX). У наших ключей срока не было, удалять было нечего, и политика вела себя в точности как noeviction. В этом ловушка: выбираете её ради «более безопасного вытеснения» и всё равно получаете ошибки OOM. Берите её, только если у каждого ключа кэша есть TTL.

Пара слов о цифре: в 20 МБ поместилось около 14 700 значений по 1 КБ, то есть запись стоит заметно дороже своего содержимого. Оставляйте запас. Valkey на сервере не один, а сохранение снимка на диск может ненадолго потребовать дополнительной памяти. Если машина и так впритык, файл подкачки выигрывает время, но не заменяет разумный потолок.

Что переживёт сбой

По умолчанию Valkey делает снимок (RDB), когда накопилось достаточно записей: config get save возвращает 3600 1 300 100 60 10000, то есть через час при хотя бы одном изменении, через пять минут при ста или через минуту при десяти тысячах. Всё, что записано после последнего снимка, пропадёт, если процесс умрёт жёстко. Другой режим - журнал команд (AOF): пишется каждая запись, и по умолчанию журнал сбрасывается на диск примерно раз в секунду. Юнит поднимает упавший сервер, поэтому мы убили процесс через kill -9, у него нет шанса сохраниться, и посмотрели на результат в обоих режимах:

После kill -9 ручной save спас один ключ, а следующая запись исчезла. С appendonly yes ключ выжил. В поставляемом конфиге стоит appendfsync everysec, поэтому при отключении питания или сбое ядра можно потерять примерно последнюю секунду записей. Я этого не моделировал, а простой kill -9 такой потери не показывает.

AOF или нет? Зависит от того, что вы храните. Кэш можно собрать заново, поэтому хватает снимков по умолчанию, и выключить сохранение вовсе было бы не безумием. Сессии, очереди и счётчики, которых будет жаль, стоят строки appendonly yes. Платите вы местом на диске и небольшим падением скорости записи.

Одна ловушка по дороге. CONFIG SET меняет только работающий сервер. Мы выполнили config set maxmemory 64mb, перезапустили службу, и maxmemory снова был 0. Единственное постоянное место - /etc/valkey/valkey.conf (в документации для сохранения изменений описан CONFIG REWRITE, я его не пробовал). CONFIG SET годится для опытов, а итоговые значения записывайте в файл.

Итоговый конфиг

Впишите эти строки в /etc/valkey/valkey.conf вместо совпадающих значений по умолчанию и перезапустите службу. Размер памяти - пример, выбирайте его по тому, сколько RAM нужно остальному серверу:

allkeys-lru - выбор для кэша, для очереди ставьте noeviction. После перезапуска проверьте каждую настройку через valkey-cli config get maxmemory и config get maxmemory-policy, а то, что сокет по-прежнему локальный, - через ss.

Насколько он быстр, примерно

Встроенный тест годится для проверки на дым после настройки. Обзором железа он не является.

valkey-benchmark -a '<password>' -q -n 100000 -c 20 -t set,get

На нашей машине с двумя vCPU клиент и сервер делили процессоры по петле. Вышло примерно от 40 000 до 50 000 SET и GET в секунду (в показанном прогоне 43 000 и 48 000), медианная задержка порядка четверти миллисекунды. С -P 16, то есть шестнадцатью командами в пачке, получились сотни тысяч (в том прогоне 365 000 и 529 000). От запуска к запуску цифры расходятся на десятки процентов. Настоящее приложение окажется между этими числами, смотря сколько обращений оно делает на один запрос. Одинокий Valkey на небольшом VPS редко тормозит вас сам. Чаще тормозит сетевой переход на каждую команду.

Частые вопросы

Можно ли заменить Redis на Valkey без переделок?

Почти для любого приложения да. Те же команды, тот же протокол, те же клиентские библиотеки. Боевую систему сначала проверьте на своём приложении и не запускайте оба хранилища на одном порту.

Почему приходит «NOAUTH Authentication required»?

Задан requirepass, а клиент пароль не отправил. Передайте его в строке подключения, командой AUTH после соединения или через REDISCLI_AUTH для valkey-cli из пакета Ubuntu 24.04.

Что будет, если у Valkey закончится память?

Зависит от политики. При noeviction записи падают, чтение работает. При allkeys-lru старые ключи уходят. Без maxmemory его ничто не остановит, пока не вмешается ядро.

Теряет ли Valkey данные при сбое сервера?

С настройками по умолчанию - всё после последнего снимка. С appendonly yes - около секунды при отключении питания или сбое ядра, чуть больше, если диск замешкался. Обычный перезапуск через systemd не теряет ничего.

Безопасно ли открывать Valkey на публичном адресе?

Нет. Держите его на петлевом адресе и заходите через SSH-туннель или частную сеть. Если всё же нужно привязать сетевой адрес, задайте пароль, оставьте защищённый режим и ограничьте порт в файрволе.

Что запомнить

• Ubuntu 24.04 даёт Valkey 7.2.13, он слушает только localhost.
• Задайте requirepass и отдавайте его valkey-cli через REDISCLI_AUTH, а не через -a.
• Оставьте защищённый режим включённым. В нашем тесте без него посторонний записал ключ одной командой.
• Задайте maxmemory: allkeys-lru для кэша, noeviction для очереди, volatile-lru никогда без TTL.
• Выбирайте сохранность осознанно и правьте файл, а не только CONFIG SET.