Хозяйство росло годами и расползлось: учётная система на одном арендованном сервере, облако на втором, боты на третьем, тестовые контуры на четвёртом. Разные хостеры, разные счета, разные привычки администрирования. В конце июля мы собрали всё это на одну машину.
Что выбирали
Считали не «побольше ядер», а по профилю нагрузки: база данных любит быструю дисковую подсистему и память, облако — объём диска, контейнеры ботов — почти ничего. Сошлись на выделенном сервере с серверным процессором, 64 ГБ памяти и парой NVMe. Система — Debian, всё прикладное — в Docker, чтобы следующий переезд был копированием томов, а не сборкой заново.
Базовая настройка до переезда
Сервер сначала закрыли, а потом наполняли: вход только по ключам, файрвол с явным белым списком портов, автоблокировка перебора паролей, отдельные тома под данные каждого сервиса. Бэкапы принципиально уезжают на другую машину — резервная копия, лежащая рядом с оригиналом, спасает только от «случайно удалил», но не от потери сервера.
Переезд без «чёрного окна»
Самое неприятное в переезде — не копирование данных, а клиенты, которые ещё помнят старый адрес. Поэтому старый сервер не гасили: на нём подняли универсальный форвардер на новый адрес, включая веб-сокеты — без них чат и звонки в облаке молчат, хотя страницы открываются. Пока DNS расходится по кэшам, всё работает с обеих сторон.
Одна находка по дороге
После переезда учётной системы в контейнер часть вложений перестала открываться — ошибка сервера на любом файле с пробелом или кириллицей в имени. Причина оказалась не в приложении: в контейнере не была задана UTF-8-локаль, и веб-слой пытался кодировать путь в ASCII. Две переменные окружения в описании сервиса — и всё вернулось. Такие вещи не ловятся тестом «сайт открывается», только реальными файлами.
Итог
Вместо пяти арендованных машин — одна, с понятной структурой томов, закрытым периметром и бэкапами на стороне. Освободившиеся серверы гасим по очереди, оставляя последний как путь отката.