Так уж вышло, что относительно недавно я был вынужден инициировать перенос Cloudron сервера к другому поставщику VDS. Несмотря на осознанный страх потерять все свои данные из облака, это нужно было сделать в кратчайшие сроки, поэтому на подготовку особо не было времени.
Спойлер: всё произошло удачно и на удивление крайне быстро благодаря встроенным инструментам Cloudron. Спешу поделиться своим пошаговым опытом в этом удивительно простом деле.
Шаг 1. Делаем резервную копию сервера
Чтобы перенос Cloudron в принципе имел смысл, необходимо убедиться в наличии свежей резервной копии. Даже если Вы настроили ежедневный автоматический бэкап, рекомендуется запустить ручное копирование, чтобы сохранить все свежие данные в приложениях и базах данных.
Сразу оговорюсь, если Вы используете инструмент резервного копирования Вашего поставщика VDS – забудьте о нём и перейдите на встроенное решение Cloudron. Если же Вы уже пользуетесь им, но копируете Cloudron на локальное хранилище, лучшим способом будет временное изменение способа хранения на любое S3 хранилище или дешёвый Backblaze B2. В данном случае все резервные копии будут доступны Cloudron в момент восстановления без необходимости копировать их на новый сервер через rsync или scp.
Если какое-нибудь приложение использует внешний путь для хранения данных, не забудьте установить данную директорию на новом сервере. Если это не представляется возможным, в качестве альтернативы смените путь на стандартный и только после этого запустите резервное копирование.
Для ручного запуска бэкапа перейдите в раздел “Резервные копии” и нажмите на кнопку “Создать резервную копию”.
Как только процесс будет завершён, загрузите кофигурацию свежей резервной копии из общего списка.
Шаг 2. Изменение DNS-записей
Если Вы, также как и я, используете Wildcard метод для DNS записей, то Вам крупно не повезло. Морально приготовьтесь к тому, что все Ваши сервисы будут недоступны до 24 часов, после чего перейдите к Вашему поставщику DNS и вручную измените записи для всех своих привязанных к Cloudron доменов на IP адрес нового сервера.
Настоятельно рекомендую подождать полного применения изменений и не производить восстановление Cloudron преждевременно, в противном случае сертификаты Let’s Encrypt не будут сгенерированы для приложений, а сам процесс восстановления завершится с ошибкой.
Шаг 3. Установка Cloudron на новый сервер
Чтобы не терять времени, подготовим наш новый сервер. Что для этого необходимо?
Во-первых, установленная Ubuntu Server 20.04. Если Вы ещё не установили систему, можете обратиться к инструкции на сайте.
Во-вторых, установленный Fail2Ban. По большому счёту опционально, но крайне рекомендую установить эту программу для базовой защиты Вашего сервера от брутфорса.
В-третьих, сам Cloudron. Но учтите, что необходимо производить установку той версии Cloudron, что стояла у Вас на старом сервере. В противном случае восстановление завершится с ошибкой. Сделать это можно следующим набором команд (где на место x.y.z ставим нужную версию Cloudron):
wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
./cloudron-setup --version x.y.zШаг 4. Восстановление сервера из резервной копии
Если сервер готов, а DNS записи уже обновились, можно приступать непосредственно к переносу. Заходим в браузере по адресу http://IP-адрес-сервера и нажимаем на Looking to restore.
На новой странице нажимаем на кнопку Upload Backup Config и выбираем ранее загруженную конфигурацию резервной копии (Шаг 1).
Все поля заполнятся автоматически, однако Вам скорее всего понадобится дополнительно ввести пароль от Вашего хранилища резервной копии.
После этого нажимаем на кнопку Restore и ждём полного завершения процесса восстановления.
На этом всё! Убедитесь, что все приложения работают как надо и избавляйтесь от старого сервера.
Итог
С учётом обновления DNS записей перенос Cloudron занял у меня примерно 15-20 часов. К сожалению, в процессе пришлось лишиться нескольких необходимых приложений, но это не было связано напрямую с Cloudron.
Настоящий гайд отчасти также можно использовать для переустановки Cloudron на тот же сервер, если что-то пошло не так. Единственной сложностью в такой ситуации будет определение ID необходимой резервной копии. Но это уже совершенно другая история.
Автор: Владислав Лищенко / HomeHosted.ru