Перенос приложения на новый Linux-сервер: что проверить до смены адреса

Старый сервер нужно освободить, а приложение продолжает принимать заказы. Код лежит в Git, поэтому перенос кажется коротким: получить репозиторий, установить зависимости и изменить DNS. Затем выясняется, что фотографии сохранялись рядом с приложением, ежедневная выгрузка запускалась от другого пользователя, а почта отправлялась через доступный только старому серверу адрес.

Перенос удобно начинать с карты работающего сервиса. Она отвечает на четыре вопроса: какой процесс обслуживает запросы, откуда он получает настройки, куда пишет данные и кто вызывает его помимо посетителей. Для небольшого проекта достаточно одного документа с путями и именами. Сами пароли туда не попадают: указывается источник конфигурации и человек или процесс, который имеет к нему доступ.

Снимите описание текущего состояния

На старой машине найдите systemd unit приложения, пользователя запуска и рабочий каталог. Посмотрите связанные timer units, настройки прокси и список слушающих портов. Команды ниже читают состояние; имя shop.service замените именем своего сервиса. Вывод unit может содержать чувствительную конфигурацию, поэтому сохраняйте его в принятом для проекта закрытом месте.

systemctl cat shop.service
systemctl show shop.service -p User -p WorkingDirectory -p ExecStart
systemctl list-timers --all
ss -lntp

Сопоставьте найденные порты с конфигурацией приложения. У базы есть отдельный адрес? Прокси обращается к loopback или к Unix socket? Доступ к внешнему API разрешён по исходящему IP? В последнем случае исправный новый сервер получит отказ, пока владелец интеграции не разрешит его адрес. Такая зависимость не обнаружится простым копированием файлов.

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

Проверьте новый сервер без переключения посетителей

Создайте того же служебного пользователя и необходимые каталоги, установите совместимую версию runtime. Зафиксируйте commit приложения. Секреты передайте штатным способом, затем убедитесь, что unit ссылается на новый источник настроек. Привычный домашний каталог администратора не должен незаметно становиться частью запуска сервиса.

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

Для проверки HTTPS до изменения DNS используйте имя сайта вместе с адресом нового сервера. У curl параметр --resolve сохраняет имя в URL, проверку сертификата и выбор виртуального сервера. В примере адрес из диапазона для документации: подставьте реальный адрес подготовленного узла.

curl --fail --show-error --resolve shop.example.org:443:192.0.2.20 https://shop.example.org/health

Если балансировщик или CDN терминирует TLS отдельно, проверяйте соответствующий участок маршрута и его реальную конфигурацию. Ответ нового узла сравните с ожиданием приложения: статус, версию и доступность нужных зависимостей. Одного успешного TCP-соединения для решения о переносе недостаточно.

Выберите одного владельца записи

Перед финальной синхронизацией данных остановите запись на старой стороне: например, включите предусмотренный приложением режим обслуживания и приостановите фоновые обработчики. Дождитесь завершения операций, перенесите остаток данных, проверьте новый узел и только затем откройте запись там. Конкретный способ зависит от базы; если нужна непрерывная работа, потребуется отдельная схема репликации и переключения.

После смены DNS часть клиентов ещё некоторое время обращается к прежнему адресу. Старый сервер должен показывать понятное обслуживание либо направлять запросы по согласованной схеме. Нельзя позволять двум независимым копиям базы принимать новые заказы. Уменьшение TTL заранее сокращает время кэширования, но не превращает переключение в одновременное действие всех клиентов.

Сохраните критерий возврата и порядок действий с данными. До первой записи на новом сервере возврат обычно проще. После неё нужно учитывать уже появившиеся изменения; переключение DNS обратно само их не перенесёт. Именно эта граница определяет, сколько времени можно спокойно проверять перенос и кто принимает решение о его завершении.

Сделайте следующий перенос воспроизводимым

Если новое окружение собирается в контейнерах, заранее разберите источники переменных Docker Compose: старое значение адреса базы способно связать новый узел с прежними данными.

Итог работы — инструкция запуска с чистой машины и карта зависимостей. Если команды пока приходится собирать по истории терминала, начните с курса «Bash Linux + Git». В программе есть управление процессами, сетевые команды curl и wget, разрешения файлов и управление пользователями, а затем работа с Git. Эти навыки нужны, чтобы разобраться с окружением сервиса и сохранить проверенные команды в репозитории. Откройте программу и закрепите основу, на которой строится сопровождение сервера.