Перенос legacy Perl-приложения со старого сервера на UpCloud

В этом проекте нужно было перенести старое Perl web-приложение с одного физического сервера на более современную облачную инфраструктуру. Задача была не в том, чтобы переписать приложение с нуля, а в том, чтобы аккуратно перенести рабочую систему, разделить данные по нормальным инфраструктурным слоям и снизить операционные риски.

Исходная система была типичным production-окружением из 2000-х: один сервер, Apache, Perl-приложение, MySQL на той же машине и несколько гигабайт изображений на локальном диске. Код приложения был сравнительно небольшим, но вся система держалась на старых допущениях: локальных путях, правилах Apache, структуре файлов и особенностях старой MySQL-базы.

Для новой инфраструктуры выбрали UpCloud: приложение можно было вынести на отдельный compute, базу — в managed MySQL, а изображения — в object storage с S3-совместимым API. Такой вариант требовал больше аккуратной миграционной работы, чем перенос "как есть" на один VPS, зато давал более понятную поддержку после запуска.

Отправить бриф

Задача

Нужно было перевезти legacy-приложение на новую инфраструктуру без потери данных и без лишнего вмешательства в старую бизнес-логику. Для этого требовалось:

• разобрать старую связку Apache, Perl, MySQL и файлов изображений;
• подготовить целевое окружение на UpCloud;
• перенести MySQL-базу размером около 5 GB;
• подготовить перенос нескольких гигабайт изображений в object storage;
• сохранить работоспособность старых URL и правил отдачи файлов;
• согласовать момент заморозки данных перед финальным переключением;
• оставить старый сервер как fallback на период после go-live.

Почему это не просто копирование файлов

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

Старый сервер работал по схеме "всё в одном": приложение, база, web server и изображения жили на одной машине. Это удобно для первичного запуска, но со временем становится риском: обновления, бэкапы, восстановление, безопасность и диагностика завязаны на один узел.

Целевая схема разделяла ответственность:

• compute: runtime для Perl-приложения и web server;
• managed MySQL: отдельный управляемый слой для базы данных;
• object storage: отдельное хранилище для изображений;
• старый сервер: временный fallback на случай отката после переключения.

Рисунок 1. Перенос legacy Perl-приложения: приложение, база данных и изображения разделяются между compute, managed MySQL и object storage.

Миграционный план

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

1. Подготовить сервисы на UpCloud.
2. Сделать полный backup старой системы.
3. Поднять окружение для Perl-приложения.
4. Импортировать базу в UpCloud Managed MySQL.
5. Перенести изображения в object storage.
6. Проверить приложение, URL и отдачу файлов.
7. При необходимости сделать финальную синхронизацию.
8. Согласовать переключение production-трафика.
9. Мониторить систему после запуска.
10. Сохранять старый сервер доступным как fallback.

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

MySQL: проблема старой схемы

Самая неприятная часть оказалась не в Perl-коде, а в несовпадении допущений старой базы и managed MySQL. В legacy-базе были таблицы без primary key. На старом self-hosted MySQL это работало, но управляемый MySQL-сервис может быть строже из-за требований к репликации, бэкапам и восстановлению.

Поэтому простой импорт dump не всегда проходит напрямую. Если в сервисе включено требование primary key, старую схему приходится адаптировать: добавлять surrogate primary key в проблемные таблицы и аккуратно приводить dump к новой структуре.

Здесь есть важная техническая ловушка. Если добавить новую колонку с primary key, старые выражения вида INSERT INTO table VALUES (...) могут сломаться: количество и порядок колонок больше не совпадает со старым dump. Поэтому для таких таблиц нужно переписывать insert в форму с явным списком колонок.

INSERT INTO old_table (old_column_1, old_column_2, old_column_3)
VALUES (...);

Это небольшой пример того, почему миграция старой базы в managed-сервис — не только вопрос скорости импорта. Нужно проверить, какие технические допущения старый MySQL прощал годами, а новое окружение уже не принимает.

Изображения и object storage

Отдельным пластом были изображения. В старой системе они лежали на локальном диске и отдавались через Apache rules. При этом правила доступа на старом сервере могли мешать нормальной отдаче картинок, поэтому проверять нужно было не только наличие файлов, но и весь путь от URL до ответа web server.

В новой схеме изображения планировалось вынести в UpCloud Object Storage. Это S3-совместимое хранилище, поэтому для загрузки можно использовать привычные инструменты вроде AWS CLI, но с endpoint и credentials UpCloud.

На практике "S3-compatible" не означает, что любой клиент с дефолтными настройками сразу идеально работает с любым хранилищем. При upload всплывала ошибка XAmzContentSHA256Mismatch на PutObject. Такие проблемы нужно отлавливать на реальных файлах, потому что они завязаны на подпись запроса, checksum, payload signing и особенности конкретного S3-compatible endpoint.

Для проекта это означало, что перенос изображений нельзя было считать простым rsync. Нужно было продумать layout bucket, сопоставление старых путей с новыми URL и отдельно проверить отдачу файлов после переноса.

Почему UpCloud

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

Вариант с UpCloud был интересен именно как более управляемая инфраструктура: приложение остаётся небольшим compute-слоем, база уходит в managed MySQL, а тяжёлые файлы переезжают в object storage. Для старого, но всё ещё рабочего приложения это часто разумный компромисс между "переписать всё" и "оставить как было".

Результат

• Был разобран старый single-server setup с Apache, Perl, MySQL и локальными изображениями.
• Подготовлена целевая схема переноса на UpCloud с разделением приложения, базы и файлового хранилища.
• Проработан перенос MySQL dump около 5 GB с учётом таблиц без primary key.
• Описан подход к адаптации dump: surrogate primary keys и явные списки колонок в insert.
• Разобран перенос изображений в S3-compatible object storage и связанные с ним edge cases.
• Для заказчика был зафиксирован migration plan: backup, import, test, cutover, monitoring и fallback.
• Отдельно обозначен freeze point, чтобы при переключении не потерять изменения, сделанные на старом сервере после backup.

Кому подходит такой формат

• Проектам на Perl, PHP или другом legacy-стеке, которые всё ещё работают и приносят пользу.
• Системам, где всё исторически живёт на одном сервере: приложение, база, файлы и web server.
• Владельцам проектов, которым нужен перенос без полной переписки бизнес-логики.
• Командам, которые хотят вынести базу в managed-сервис, а файлы — в object storage.
• Проектам, где важно заранее спланировать downtime, синхронизацию данных и fallback.

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

Отправить бриф