Перенос проектов между ЦОДами. Часть 1

Как часто вам приходилось мигрировать проекты на единую платформу? А как часто вы перевозите проекты с 20-летней истрией и огромной базой пользователей? Как это сделать и не собрать все шишки? Расскажу вам про наш опыт переноса и все те проблемы, которые мы решали.

Проект

Проект, который мы переносили из ЦОД Нижнего Новгорода в ЦОД Урал - это сайт nn.ru. Сайт с долгой историей и сложной судьбой. Часть проекта написанна на php5.6 и под капотом имеет огромное количество легаси. Сотни захардкоженых ip, не понятная схема организации приложения, отсутсвие роутинга, apache .htaccess 20+ директориям. Другая часть написана на php7 с использованием laravel/lumen. Правда это особо не помогло…

Итак, диспозиция - есть 1 человек, который примерно представляет как работает старый проект и команда из 4х инженеров, которым надо провести переезд в другой цод и на новую инфраструктуру. Время на перенос проекта - 3 месяца, так как мы ограничены доступом в ЦОД и возможностью обслуживания там оборудования. Возможно кто-то возразит, что надо было везти как есть, а потом переводить на инфраструтуру. Тут есть несколько доводов: - очень запутаная схема работы - вакханалия из виртуалок (xen, kvm, qemu) - отсутствие ресурсов для поддержки 2х версия проекта - отсутствие дев инфраструктуры - частичное покрытие мониторингом

Что требуется мигрировать:

• Mysql (Percona) размером в 600GB, Percona xtradb cluster
• около 20 различных сервисов на php5.6-7.1
• 20TB статики в openstack swift
• 20GB sphinx2
• rabbitmq
• sphinx
• memcached

Что мы импользуем в своей работе:

• полное повтрение prod окружения в dev за счет спецификаций LXC контейнеров
• набор спецификации контейнеров по ролям, которые необходимы проекту (dev, prod окружение)
• при создании окружения прописываются все связи между контейнерами и ресурсами
• ArchLinux + ZFS, mirror list stabled

Что хотим получить:

• проект работает на нашей инфраструктуре и на наших решениях
• рабочее дев окружение
• все данные смигрированы
• проект работает стабильно
• все ключеве метрики мониторятся, настроены алерты

Мы начали с того, что необходимо было получить рабочее dev окружение. Под этим мы понимаем следуюшее: у нас есть рабочая копия данных из БД, поднят openstack swift, memcached, sphinx, и тд. Есть описаный набор ролей для контейнеров (профиль среды) - что дает нам возможность легко повторять боевое окружение. Дисклеймер - приходилось постоянно копаться в том, как тот или иной функционал должен работать, так как хранителей знаний почти не осталось.

Проблемы

Отсутствие знаний у команды, а как должно все работать.

Из за того, что у нас arch, то части пакетов необходимых, которые используются проектом, нет. Например php5.6 в официальных репах отсутствуют. Вариантов 2 - бустануть работу проекта на свежей версии php или собрать пакет с php5.6. При попытке завести все на php7, начались проблемы с работой проекта. Мы решили собрать необходимые версии php под arch. Собирать пакеты под arch легко, поэтому у нас получилось сделать это достаточно быстро. Проект худо-бедно завелся на наших dev-контейнерах.

Percona не ставится на archlinux. Поэтому контейнеры с бд пришлось сделать на ubuntu 16.04 и поставить туда Percona, в связке с percona extradb cluster.

Openstack swift. Модное s3 хранилище, которое часто используют в энтерпрайзе. Что это значит для простых смертных - дока на официпльном сайте и в wiki. Проблемы, которые с ним возникают просто не гуглятся. Как обычно, документации, все легко и просто. Поэтому, чтобы с ним разобраться, потребуется большое количество времени. С наскока взять эту крепость не получится.

Абсолютно непонятна связь между компонентами проекта. Все используют 1 базу, но некоторые различные ресурсы. Обращаются друг к другу по разному: ip, dns, хардкод в /etc/hosts, etc. А еще в проекте есть nginx, который вызывает apache. Что это значит? А то, что по всему проекту раскиданы файлы .htaccess, в которых тоже много логики…

Представили масштаб трагедии? Что мы со всем этим делали, в следующей части.