Дано: некоторый сайт на WordPress и немного трафика. Сайт периодически не справляется со всеми запросами и начинает страшно тормозить. Все кеши включены, CDN настроены.

Пришло время расти горизонтально.

Если вдруг кто-то не знает, есть два очень простых способа справляться с нагрузкой:

Вертикальное масштабирование - тупо наращиваем мощности сервера. Докупаем больше памяти, увеличиваем процессор и т.д.

Горизонтальное масштабирование - тупо покупаем второй сервер.

И очень часто получается так, что купить два сервера выгоднее, чем раздуть один. Поразмыслив с нашим DevOps, так и решили. Надо создать две ноды с сайтом. Это и быстро, и перезапускать ничего не надо, ведь трафик идет. Еще и можно сказать всем, что у нас отказоустойчивая архитектура: если одна нода ляжет, вторая перед тем, как тоже лечь, немного поработает.

Сказано - сделано. Выполняю команду для увеличения количества инстансов нашего сайта: kubectl -n apps scale deployment site --replicas 2. Наблюдаю в консоли deployment.apps/site scaled и иду проверять все это в Lens (очень удобная штука для просмотра, как там поживает кубер через GUI, а не через консоль). Там вижу два сайта.

Идем проверять, что все работает, как задумывалось. Сайт открывается, логин в админку открывается, после логина в админку летим на страницу 404. Тут надо сделать небольшое отступление - на сайте настроена штука, которая прячет админку и в случае разлогина или попытки сразу попасть в админку WordPress, редиректит на 404. Вот она и срабатывает, получается, что мы не можем авторизоваться в админке сайта.

Звучит вроде правильно, инстанса 2, если мы заходим на одном, второй про нас ничего не знает, надо их научить общаться. Ставим плагин для хранения всех сессий WordPress в Redis, поднимаем рядом Redis в Kubernetes, вписываем доступы к нему, перезапускаем - не работает. Все еще получаем 404.

Тут DevOps предлагает сравнить конфиги. И действительно, смотрим в файл wp-config.php и видим там разные ключи шифрования `AUTH_KEY`, `SECURE_AUTH_KEY` и т.д. Проблема найдена, осознана и готова быть решенной. Генерим новые ключи через стандартный генератор https://api.wordpress.org/secret-key/1.1/salt/, вписываем их в хранилища Kubernetes и прокидываем через специальные переменные Docker образа WordPress с префиксом `WORDPRESS_`. На этом моменте будьте внимательны: первый раз мы прокинули их через `WORDPRESS_CONFIG_EXTRA` и долго не могли понять, что не так, а нужно их объявить через `WORDPRESS_AUTH_KEY`, а не просто `AUTH_KEY` в `WORDPRESS_CONFIG_EXTRA`. Конфиги обновлены, приведены к одному виду, пришло время проверить плоды наших трудов.

Передеплоим сайт, чтобы все конфиги подтянулись, снова ставим 2 реплики и проверяем админку - вход работает, разлогина больше нет. Радуемся, отправляем друг другу сердечки и поцелуйчики и идем отчитываться, что все сделано, проверено и готово к релизу. О релизе в прод расскажу в понедельник, если будет что рассказать, потому что такие штуки в пятницу в прод не катят.

Спасибо за внимание.