Перенос приложения с Fly.io на VPS: тома, сеть и экземпляры

MAATRIX · 17 октября 2026 · 8 мин чтения

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

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

Один сервер вместо нескольких: осознанное упрощение

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

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

Если база остаётся на Fly.io, а приложение переезжает, проверьте задержку между ними. Страница, выполняющая много последовательных запросов к базе, чувствительна к расстоянию сильнее, чем статическая картинка. Иногда разумнее сначала перенести оба компонента рядом, а распределение статики решать отдельно.

Разберите fly.toml по смыслу

Файл конфигурации содержит сведения о портах, процессах, проверках, томах и поведении запуска. Справочник fly.toml помогает отличить параметры приложения от возможностей платформы. На VPS этот файл сам по себе ничего не настроит.

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

Проверьте автоматическую остановку и запуск машин. Постоянно работающий процесс на VPS не обязан повторять это поведение. Если приложение раньше ожидало «холодный старт», изменятся характер нагрузки и расход ресурсов. Если оно полагалось на платформенный запуск по запросу, теперь нужен собственный управляющий процесс.

Сохраните тот же коммит и версии зависимостей. Архитектуру процессора контейнера сопоставьте с целевым VPS. Образ, собранный для другой архитектуры, может не запуститься либо потребовать отдельной сборки. Проверяйте это до переноса пользовательских данных.

Внутренние адреса не путешествуют вместе с кодом

Fly.io использует частную сеть и собственное разрешение адресов .internal; особенности описаны в руководстве по private networking. На обычном VPS такие имена не становятся доступными автоматически.

В новой схеме задайте понятные адреса. Сервисы на одном сервере могут общаться через локальный интерфейс или внутреннюю контейнерную сеть. Сервисы на разных серверах — через отдельно настроенную защищённую сеть. Открытие базы всему интернету ради быстрого переезда не заменяет проектирование доступа.

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

Проверьте доверие к заголовкам прокси. Приложение должно знать, от какого посредника принимает сведения об исходном адресе и HTTPS. Слепое доверие любому клиенту позволяет подделать эти значения. Настройка должна соответствовать реальной цепочке нового окружения.

Тома: найдите источник истины

Том Fly.io связан с конкретным местом размещения; наличие нескольких томов не означает автоматическое объединение данных. В обзоре Fly Volumes описана их модель. Поэтому перед экспортом определите, какой том содержит актуальную информацию и есть ли репликация на уровне приложения.

Если используются SQLite и механизм репликации, получите согласованную копию через предусмотренный приложением или базой способ. Копирование одного файла во время записи может не включить данные журнала. Если используется PostgreSQL, подготовьте штатный экспорт или совместимую резервную копию. Тип данных важнее удобства доступа к каталогу.

Пользовательские файлы переносите отдельно от базы. Сохраните относительные пути и проверьте доступ владельцев. Для выгрузки отдельных файлов Fly предоставляет инструменты SSH и SFTP; конкретный способ выбирайте по объёму и доступам. Большой архив лучше формировать и передавать с контролем целостности, а не скачивать вслепую до первого разрыва связи.

Запишите размер исходных данных и оставьте запас места на VPS. Во время восстановления могут одновременно существовать архив, распакованные файлы и временные данные. «Диск ровно по размеру базы» часто заканчивается остановкой на последнем, самом интересном шаге.

Репетиция с понятными критериями

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

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

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

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

Остановка записи и переключение

Назначьте окно обслуживания. Остановите создание новых данных на исходной площадке, дождитесь или корректно остановите фоновые задания. Снимите финальную согласованную копию, догрузите файлы и восстановите её на VPS. Выполните короткую проверку до изменения DNS.

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

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

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

Проверьте одну запись через все уровни

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

Подбор VPS MAATRIX для новой схемы

Для пилота приложения с локальной базой и фоновым процессом рассмотрите Heka Standard с 4 vCPU и 8 ГБ памяти. Более простой сервис можно проверить на Uab Start. Если вы объединяете несколько машин, складывать их память механически недостаточно: часть ресурсов была резервом, а часть процессов теперь будет конкурировать за один диск.

Выбирайте локацию по аудитории и зависимостям, затем проверяйте задержку. Поддерживаемые Ubuntu и Debian подходят при совместимости образов и библиотек. Данные и резервные копии рассчитывайте отдельно, а копию храните вне рабочего VPS.

Сервер MAATRIX имеет смысл подбирать после описания целевой архитектуры. Тогда переезд с Fly.io становится сознательным упрощением: меньше скрытых связей, понятные каталоги и адреса, воспроизводимый выпуск. Именно эта ясность помогает сопровождать приложение после того, как радость от успешной миграции сменится обычным рабочим понедельником.