Итак, я решил перенести свои старые сайты на новый сервер. Их примерно 10 штук, самый старый, пожалуй, это yadyra.ru. Домен зарегистрирован в далеком 2009 году.
Переезды
Небольшая история про переезд этого сайта. Вначале он был собран на shared-хостинге. Несколько раз переезжал. Наконец, был перевезен на печально известный VDS-хостинг iHor. В какой-то момент сервера неожиданно выключились, и я потерял возможность что-то с этим сделать. Да, у меня были какие-то бекапы, но было лень все это восстанавливать.
Докеризация
В конце концов хостер включил сервера, и я по-быстрому перевез все сайты на новый VDS. И в этот момент захотелось сделать какую-то систему, которая давала возможность автоматически снимать бекапы и делать переезд легким. Для этого я докеризировал PHP и прочую обвязку, и подрубил исходные коды в контейнеры. Выглядело примерно так:
version: '3'
services:
php54-fpm:
build: ./php54-fpm
hostname: php54-fpm
restart: always
volumes:
# config
- ./php54-fpm/etc:/usr/local/etc
# logs
- ./var/log/php54-fpm:/var/log/php54-fpm
# sites
- /home/hub/www:/var/www
env_file:
- .env
А базы данных находились в монтируемых томах (volume):
mysql-5.7:
image: mysql:5.7.28
command: --default-authentication-plugin=mysql_native_password --character-set-server=utf8 --collation-server=utf8_general_ci --sql_mode=STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
hostname: mysql-5.7
restart: always
# ports:
# - 3306:3306
volumes:
# DB
- ./mysql-5.7/var:/var/lib/mysql
# config
- ./mysql-5.7/custom.cnf:/etc/mysql/conf.d/custom.cnf
# Tools
- ./mysql-5.7/srv:/srv
# Dumps
- ./var/dump/mysql:/var/dump/mysql
env_file:
- .env
Также был скрипт архивирования файлов и снятия дампа со всех баз:
ls mysql-5.7/srv/
backup-all-db.sh create-user-db.sh create-user.sh export-db.sh import-db.sh make-db.sh
Ну что же, время проверить, насколько переезд будет легким!
Переезд и его проблемы
По-идее процесс переезда должен быть таким:
- разворачивание всех файлов из архива
- билдежка и запуск контейнеров из docker-compose.yml
- восстановление баз данных из дампов
Я все это сделал совсем по-другому. Скрипт бекапа не запускал совсем. Вместо этого остановил все контейнеры, а затем заархивировал все сорцы сайтов и данные из volume:
time sudo tar -cf - ./www | pigz > www.tgz
time sudo tar -cf - ./lamp | pigz > lamp.tgz
Полученные архивы перенес на новый сервер и развернул. Затем поправил некоторые моменты, которые хотелось бы улучшить:
- перенес volume из «./mysql-5.7/var» в «/var/v-lamp»
- убрал 443 порт, теперь весь SSL-трафик будет ходить через Caddy в режиме реверс-прокси
- переделал структуру проекта — объединил два каталога www (сорцы) и lamp (сервисы) в один каталог
Теперь — с какими проблемами я столкнулся
Не известна версия образа
Версии PHP и MySQL были указана с помощью тега, поэтому вопроса «какой базовый образ?» с ними не было. А вот с mongo такой вопрос появился. Вот бы был способ сделать docker inspect, и по полученному sha256 найти точный тег. К сожалению, так найти не получилось. Пришлось заходить на старый сервер и смотреть в контейнере версию сервера. После чего — искать соответствующий тег на hub.docker.com.
Не собирается образ
При пересборке контейнера на базе php:5.4-fpm возникла проблема с этой командой:
apt-get install -y libjpeg-dev libpng++-dev libfreetype6-dev
Репозитории пакетов переехали, причем неоднократно. Также закончили свое действие ключи (expired), их обновлять уже никто не будет. Завел тред на форуме.
В данный момент не ставил эти пакеты, они, кажется, используются только для каптчи при регистрации.
Caddy не получает сертификат от Let’s Encrypt
Я думаю, что это связано с кешем DNS и проблема временная. Нужно было дождаться смены IP адреса в A-записи, после чего перезагружать Caddy, чтобы он запросил новый сертификат.
В конечном счете сертификат был получен, хотя в журнале появлялись сообщения сначала о невозможности проверки, а затем — о превышении лимита на выпуск сертификатов. Заодно выяснил, что лимит равен 5:
5 failures per account, per hostname, per hour
Наконец, yadyra.ru заработала на новом сервере, но оказалось, что не все ресурсы загружаются по HTTPS.
Смешанное содержимое
Чтобы наконец https заработал как надо, пришлось копаться в админке и PHP-скриптах. Получилось не сразу, и по коду пришлось разбросать хаки. Такая ситуация оказалась не только с этим сайтом, но и с большинством других, включая WordPress.
Для докувики пришлось редактировать некоторые материалы, заменяя ссылки на безопасные. А также сбрасывать кеш для некоторых страниц.
Перестал работать поиск на Sphinx
Этот поисковый движок используется сразу на нескольких моих сайтах. И пришлось разбираться, как я сделал, чтобы это работало.
А работает так:
- cron-задачи в контейнере с PHP запускают скрипты, которые создают XML-файлы для xmlpipe2. Файлы кладутся в volume, который расшарен между Сфинксом и прочими сервисами.
- Есть cron-задача, которая запускает переиндексацию.
Перестало работать потому что индексы строятся редко — 1 раз в сутки. Чтобы ускорить этот процесс, нужно зайти в контейнер PHP и запустить xmlpipe2 примерно так:
chmod 777 /var/sphinx-xmlpipe2/ && php /var/www/propest.ru/catalog-pipe.php > /var/sphinx-xmlpipe2/propest.ru.xml
Затем в контейнере Сфинкса запустить переиндексацию:
indexer -c /etc/sphinx.conf --rotate pest_catalog
После этого поиск заработал, но не везде. Не работал поиск на индексах, которые создаются через SQL. К счастью, тут также перезапуск индексации решил проблему.
Итоги переезда
Переезд занял ~ 1 день работы. Каких-то блокирующих ошибок не было. Каждая доработка напильником брала свое время, поэтому набежало на целый день.
Также время заняло проверка различных страниц, например пройтись по DokuWiki и поправить смешанное содержимое. А также прочекать в Sape, что на страницах расставлены ссылки. Нужно потом посмотреть, как отреагирует эта биржа.
Была и дополнительная работа в виде причесывания проектов:
- удалил старые конфиги Nginx от заброшенных доменов, выпилил Let’s Enctypt
- удалил каталог deprecated и другие похожие — в них были скрипты, цель которых стала непонятной