Компания, в которой я сейчас работаю, уже около года использует HipChat Server для внутренних коммуникаций в команде разработчиков и админов. Причем, это именно self-hosted виртуальная машина на KVM с qcow2 образом диска. И вот, недавно возникла необходимость перевозить внутренние сервисы на AWS, я стал искать пути. Вариантов на самом деле было немного:
— Конвертация qcow2 > raw > ami.
— Официальный подход — экспорт чатов, пользователей, комнат и файлов (без паролей, интеграций и ключей апи).
— третий вариант, который опишу ниже.

Я решил отложить первые два варианта на потом. Официальный метод мне не хотелось рассматривать, поскольку очень не хотелось иметь проблемы с восстановлением паролей и ключей, хоть это не заняло бы много времени в моем случае. А вариант с конвертацией в AMI-образ просто менее интересный.

Исходные данные — сервер HipChat 1.4.1 на источнике и на приемнике. Источник — виртуальная машина kvm/qcow2. Приемник — чистый (без пользователей, не считая меня) EC2-инстанс HipChat Server но с выполненной первоначальной настройкой и пробной лицензией. Конфигурация одинаковая, размер дисков одинаковый (1 CPU, 2Gb RAM, 50Gb HDD).

# VARS
SOURCE=hipchat.example.com
DEST=new_hipchat.example.com

Итак, я решил немного покопаться во внутренностях сервера и разобраться какие файлы и настройки каких сервисов нужно переносить. Беглый обзор выявил что используется следующий стек технологий:
— nginx,
— php5-fpm,
— mysql,
— elasticsearch,
— redis,
— gearman-job-server,
— memcached,
— и еще несколько сопутствующих сервисов.
Плюс ряд сриптов на python, ruby, chef-solo.
Знакомо?
Далеко копать я не стал, мне просто нужно было выяснить что нужно переносить и как.

Можно было сделать дамп БД (mysql, elasticsearch, redis), но я решил что в любом случае буду полностью останавливать все сервисы на источнике и на приемнике поэтому просто буду просто копировать файлы с источника на приемник.
Прежде чем начать нужно (да, нужно бы) предупредить команду, что хипчат будет недоступен n-часов (логичнее делать это в нерабочее время), затем сделать остановку всех сервисов (как на источнике так и на приемнике) из списка ниже:

# ON $DEST AND $SOURCE
/etc/init.d/cron stop
/etc/init.d/monit stop
/etc/init.d/nginx stop
/etc/init.d/php5-fpm stop
/etc/init.d/hipchat stop
/etc/init.d/integrations-0 stop
/etc/init.d/tetra-proxy stop
/etc/init.d/tetra-proxy-0 stop
/etc/init.d/tetra-app-0 stop
/etc/init.d/barb-0 stop
/etc/init.d/coral-0 stop
/etc/init.d/crowd stop
/etc/init.d/cumulus stop
/etc/init.d/curler stop
/etc/init.d/elasticsearch stop
/etc/init.d/gearman-job-server stop
/etc/init.d/memcached stop
/etc/init.d/redisserver stop
/etc/init.d/mysql stop

Про крон я не сразу догадался, оказалось есть таск который периодически проверяет monit, а тот в свою очередь проверяет остальные сервисы (в общем-то всё логично, молодцы). На самом деле не все сервисы из этого списка работают — tetra-proxy например и какой-то еще, не запомнил.

Пролистав содержимое директорий я собрал список нужного (не с первого раза, что-то эмпирически):

# Copy all files from $SOURCE to $DEST
rsync -avz /etc/nginx/ $DEST:/etc/nginx/
rsync -avz /etc/mariadb_grants $DEST:/etc/mariadb_grants
rsync -avz /etc/chef/ $DEST:/etc/chef/
rsync -avz /etc/crowd/ $DEST:/etc/crowd/
rsync -avz /etc/mysql/debian.cnf $DEST:/etc/mysql/debian.cnf
rsync -avz --del /chat_history/ $DEST:/chat_history/
rsync -avz --del /data_bags/ $DEST:/data_bags/
rsync -avz --exclude='file_store/archive/pool' /file_store/ $DEST:/file_store/
rsync -avz --del /hipchat/ $DEST:/hipchat/
rsync -avz --del /hipchat-scm/ $DEST:/hipchat-scm/
rsync -avz --del --exclude='home/admin/.ssh' /home/ $DEST:/home/
rsync -avz --del /ops/ $DEST:/ops/
rsync -avz --del /opt/ $DEST:/opt/
rsync -avz --del /var/lib/mysql/ $DEST:/var/lib/mysql/
rsync -avz --del /var/lib/redis/ $DEST:/var/lib/redis/
rsync -avz --del /var/lib/cloud/ $DEST:/var/lib/cloud/

Важно не затереть .ssh/authorized_keys, чтобы не пришлось иметь мучений с восстановлением доступа к инстансу!

Чтобы начать копировать файлы с источника на приемник нужно сперва настроить доступ по ключам и ssh-сервер. Конфиг по умолчанию имеет whitelist и запрещает авторизацию пользователю root, поэтому пришлось временно внести следующие изменения:

editor /etc/ssh/sshd_config
...
PermitRootLogin without-password
...
# Whitelist to HipChat admin
DenyUsers ubuntu hipchat
AllowUsers root admin nessus

и сдеать рестарт ssh:

/etc/init.d/ssh restart

После того как копирование будет завершено и запустится хипчат эти изменения автоматически откатятся.

Когда все успешно скопируется, можно пробовать запускать все сервисы обратно на приемнике (источник лучше не трогать, пока вы не удостоверитесь что всё хорошо), но лучше сделать reboot, вернее мне пришлось его сделать чтобы всё заработало.

# ON DEST
/etc/init.d/memcached start
/etc/init.d/redisserver start
/etc/init.d/mysql start
/etc/init.d/cron start
/etc/init.d/monit start
/etc/init.d/nginx start
/etc/init.d/php5-fpm start
/etc/init.d/hipchat start
/etc/init.d/integrations-0 start
/etc/init.d/tetra-proxy start
/etc/init.d/tetra-proxy-0 start
/etc/init.d/tetra-app-0 start
/etc/init.d/barb-0 start
/etc/init.d/coral-0 start
/etc/init.d/crowd start
/etc/init.d/cumulus start
/etc/init.d/curler start
/etc/init.d/elasticsearch start
/etc/init.d/gearman-job-server start

Еще важное замечание — хипчат завязан на днс-записи и записи в файле hosts, причем последний поправить не получится (он перезаписывается при старте), чтобы «всё взлетело» сервер должен резолвить сам себя по hostname который прописан в днс и который вы указывали при первичной настройке (типа hipchat.example.com).

cat /etc/hosts
127.0.0.1       localhost localhost.localdom

# Network nodes
192.168.0.10   hipchat.example.com # Можно было бы указать так, но не выйдет chef все перезапишет при запуске сервера

# Services
192.168.0.10   graphite.hipchat.com  
192.168.0.10   mysql.hipchat.com             
192.168.0.10   redis-master.hipchat.com       
192.168.0.10   redis-slave.hipchat.com       

# IPv6
::1             ip6-localhost ip6-loopback
fe00::0         ip6-localnet
ff00::0         ip6-mcastprefix
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters
ff02::3         ip6-allhosts

Чтобы проверить работоспособность приемника придется поменять днс-запись для вашего хипчат сервера. Либо в случае с AWS, можно использовать внутренний днс-сервер разместив private-зону c вашим доменом в Route 53 и указав в ней private-ip инстанса.
И только после этого сделать service hipchat restart (или лучше reboot, чтобы быть уверенным что при рестарте системы все будет ок), и всё заработает.

Я намеренно старался не вмешиваться в ту логику которая существует в работе сервера, потому как все мои изменения исчезли бы при следующем обновлении и возможно могли бы привести к потере работоспобности сервиса.

В итоге мой эксперимент удался, сегодня с утра парни даже не заметили что произошло, все без проблем продолжили пользоваться командным чатом.

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

Делайте бекапы и проверяйте их.

Всем долгого аптайма и хорошего настроения.