В этой статье мы собрали best practices и наш опыт по миграции веб-проектов. Мы перевозим инфраструктуры уже примерно 10 лет. Надеемся, советы помогут избежать проблем и обойтись без бессонных ночей и новых седых волос для вашей IT-команды.
Для начала давайте вспомним базу.
Какими могут быть причины для миграции:
- интернет-магазин становится всё популярнее, и текущего серверного оборудования не хватает, чтобы качественно обслуживать всех пользователей;
- впереди «высокий сезон» («чёрная пятница» для e-commerce, новогодние праздники для кулинарных порталов и т.д.), и чтобы выдержать увеличение нагрузки, нужно временно переехать на большие мощности;
- требуется сменить хостинг-провайдера (ценовая политика, законодательные требования, например, о хранении персональных данных, уровень обслуживания, снижение кредита доверия и т.д.);
- архитектура проекта становится сложнее, и решено использовать вместо standalone-решений managed-сервисы от облачных провайдеров (базы данных, системы очередей, файловое хранилище, системы доставки контента) или полностью перенести проект с on-premise инфраструктуры в облако.
Миграция любого проекта — процесс, в ходе которого важно не потерять критичные данные и конфигурации всех компонентов системы. При этом для пользователей переезд должен быть по возможности «бесшовным». В идеальном варианте он вообще не должен сказаться на работоспособности проекта, либо время «даунтайма» должно быть минимальным.
Как проходит миграция инфраструктуры веб-проекта?
Она состоит из следующих основных этапов:
- подготовка новой инфраструктуры,
- развертывание в ней копии проекта,
- проверка работоспособности;
- работы перед переключением;
- пошаговое переключение (по конкретной последовательности шагов);
- проверка работоспособности проекта в новом окружении после переключения.
Здесь подробно рассмотрим 3 первых шага, а переключение и тестирование разбёрем в следующих частях.
Для конкретики возьмём пример типового интернет-магазина на Битриксе, работающего на популярном стеке: Linux — PHP — MySQL — Nginx, развернутого на on-premise железе. Переезжать будем на более мощные серверы в другой дата-центр.
Готовим новую систему
В новой инфраструктуре понадобится настроить всё, чем вы уже пользуетесь. Желательно в новых версиях, но не нарушая совместимость. Далее список того, что придется установить и настроить.
- Операционная система
- Базовое ПО
- Дополнительное ПО
- Кастомные сервисы Systemd и прочее.
- Файлы конфигураций
- Таймзоны в конфигурациях MySQL, PHP
- Директории для временных файлов, сессий.
- Пользователи и их ключи доступа на сайт
- IPTables.
Админ-панель из новой инфраструктуры лучше исключить. Она накладывает ограничения на стек используемых технологий и конфигураций.
Разворачиваемся на новом месте
Синхронизируем фалы. После этого разворачиваем последний файловый бэкап проекта. Затем устанавливаем систему контроля версий.
После того как вы перенесли исходный код и настроили его репликацию на новый сервер, аналогичные действия необходимо произвести и с базами данных.
Потом нужно перенести настройки Cron-заданий. Далее нужно перевезти почтовый сервер для e-mail-рассылок: локальный сервер или присоединить сервер текущего хостера,
DNS и его конфигурирование — один из последних этапов при подготовке к миграции инфраструктуры на новую площадку.
Финальные проверки
Когда мы полностью собрали новую рабочую площадку и развернули на ней копию проекта, нужно всё перепроверить. Минимальный набор необходимых действий выглядит так:
- произвести рестарт серверов — чтобы проверить, что после рестарта запускаются все необходимые сервисы и компоненты и не запускаются ненужные;
- проверить базовую работу сайта — страницы открываются, нет 404-ых ошибок на страницах конкретных новостей, товаров и т.д.;
- проверить аутентификацию/авторизацию на новой версии сайта — пользователей «не выкидывает» из админки сайта, на личные страницы подгружаются все данные профиля и можно полноценно пользоваться продуктом;
- провести тестовый запуск каких-нибудь задач по расписанию с тестовыми данными — чтобы уведомления о списании денег не ушли реальным живым пользователям.
В идеальном IT-мире вся инфраструктура подчиняется подходу Infrastructure as a Code, который снимает все перечисленные в статье проблемы и позволяет не настраивать новое окружение вручную.
Однако, исходя из нашей практики, мир далеко не идеален. Для этой статьи мы обобщили опыт многих наших инфраструктурных проектов: и по переезду, и по разворачиванию новых, и по обновлению. Надеемся, он окажется полезным и позволит обойти хотя бы некоторые подводные камни.
В следующих статьях продолжим обсуждать вопрос миграции, а пока можно посмотреть карту граблей в организации мониторинга или статью про организацию технической поддержки для вашего проекта.
