Можно ли использовать снимки при обновлении ОС хоста?

Поддержка Самостоятельное хостинг
1

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

Я всё ещё на версии 18 (с неё и начал; никогда не обновлял ОС Linux, только применял обновления безопасности), поэтому скоро перейду на 22. Всё, что я здесь прочитал, говорит о том, что миграция на новую установку гораздо разумнее, чем обновление существующей, так как могут возникнуть множество случайных проблем, которые могут проявиться, а могут и нет. Но риск не оправдан: если они всё же возникнут, это будет просто бессмысленной головной болью.

Я прочитал это руководство: Move your Discourse Instance to a Different Server, но оно касается переноса с какого-то сервера на DigitalOcean (или наоборот), из-за чего снимок (Snapshot) здесь не применим. В то же время я планирую перенести данные с существующего Droplet в DigitalOcean на новый (на что я видел множество ссылок, подтверждающих, что это работает отлично и является идеальным вариантом для обновления).

Так вот, мой вопрос по переносу DO → DO: могу ли я просто остановить свой Droplet, создать снимок, запустить новый Droplet на обновлённой версии Ubuntu, загрузить снимок и готово (только скорректировать DNS-запись домена и т.д.)? По сути, обойти «полную переустановку Discourse», описанную в руководстве. Как я понимаю, снимки должны быть точной копией 1:1 установки на Droplet, тогда как резервная копия (backup) относится конкретно к настройкам Discourse и требует полной установки для её использования. Правильно ли я понимаю? Есть ли какие-то недостатки у этого метода, кроме более длительного простоя?

tl;dr: могу ли я просто сделать снимок, создать новый обновлённый Droplet, загрузить снимок и закончить?

2

Снимок DO включает версию ОС. Восстановление из снимка приведет к откату операционной системы.

Ваши практические варианты: перенести резервную копию или использовать rsync для папки /var/discourse и выполнить ручную переустановку Docker.

3

Надеюсь, я не совсем ошибаюсь, но восстановление снимка из версии 18 на 22 откатит вас обратно к версии 18, поскольку снимок является точной копией всего дроплета.

Для меня создание совершенно нового дроплета всегда последний вариант, потому что мне нужно установить всё, что требуется Ubuntu (или любой другой ОС), включая почтовую систему и так далее.

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

4

Установка Discourse занимает около 30 минут, верно?

Просто сделайте резервную копию вашего сайта и файла app.yml, создайте новый droplet на новой версии ОС, переназначьте IP-адрес на новый droplet (чтобы домен указывал на правильное новое место), установите Discourse (вы можете выйти из мастера, обновить app.yml, а затем пересобрать) и импортируйте резервную копию.

Весь этот процесс должен занять менее часа.

Этот процесс никогда не затрагивает ваш существующий droplet, так что если что-то пойдет не так, откатиться очень просто?

5

Если переходить с одной LTS-версии ОС на следующую, я ожидаю, что процесс будет довольно гладким. Так что, конечно, я сделаю резервную копию — разумеется, сохраню её для безопасности — и затем попробую обновить ОС. Если это не сработает, я смогу установить свежую версию ОС.

Однако при таком подходе время простоя форума будет больше.

Я немного неохотно готов мигрировать на новый экземпляр, в основном потому, что мне нужно будет обновить DNS и дождаться распространения изменений. Хотя я вижу, что в сообщении выше сказано, что я могу перенести свой IP-адрес, что очень удобно и снимает мои опасения.

Фактически, я полностью меняю свой ответ: если я смогу перенести свой IP-адрес на новый экземпляр, это было бы предпочтительнее. Возможно, не все провайдеры это позволяют. Для некоторых провайдеров можно потерять бесплатный IP и начать платить за него, так как он перемещается, даже если сам адрес не меняется.

6

Супер простое решение этой проблемы — установить очень низкий TTL (или переключить серверы имен на тот, который это поддерживает). Таким образом, записи истекают быстрее, чем требуется на восстановление.

7

Вы можете использовать статический IP-адрес (я не помню, как их сейчас называют в DigitalOcean). В настройках сети вы можете получить новый IP-адрес, а затем сопоставить его со старым дроплетом. Затем вы меняете DNS и ждёте его распространения. Когда вы будете готовы перейти на новый сервер, вы просто переключите IP-адрес, чтобы он указывал на новый сервер. Это происходит мгновенно, и если что-то пойдёт не так, вы можете просто переключиться обратно.

8

Это имеет смысл, я даже не думал о переносе операционной системы.

Создание нового дроплета тоже было бы моим последним выбором, так как я никогда раньше не переносил дроплеты (это мой первый), и никогда не обновлял ОС. Однако все руководства, которые я здесь вижу, почти без исключения рекомендуют именно такой подход, а не обновление текущего дроплета. Поэтому я решил, что раз оба варианта сопряжены с рисками, а я не пробовал ни один из них, лучше последовать мнению большинства.

Моя логика также такова: если обновление каким-то образом полностью провалится, у вас будет простой из-за попытки обновления, плюс время простоя, пока вы будете вынуждены пытаться это исправить (или сдаться и создать новый дроплет). В случае же с созданием нового дроплета он может не заработать, но ваш оригинальный останется работающим и нетронутым. Я не знаю, почему обновление может провалиться, но поиск в метаданных показывает, что очень многие люди сообщают о неудачах или прямо говорят, что никогда не рекомендуют такой способ (хотя официальные руководства здесь и DigitalOcean его рекомендуют).

Полагаю, попробую это сделать в эти выходные.

Зарезервированные IP-адреса (ранее, как выяснилось, назывались плавающими IP-адресами).

9

Просто чтобы я был абсолютно уверен, следуя руководству discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

После шага 5. Установка Discourse, мне можно выйти из мастера на этом этапе, не выполняя настройку, заменить app.yml на свой, а затем выполнить

./launcher rebuild app

и всё должно быть в порядке? (Затем зайти в Админку и убедиться, что всё обновлено/восстановить резервную копию)?

10

Правильно: если вы создадите пустой файл app.yml (например, с помощью команды touch app.yml в директории containers) и аккуратно вставите в него содержимое из вашего другого сервера, запуск ./discourse-setup не потребуется.

Одной из проблем, с которой я столкнулся на этой неделе, была настройка электронной почты: убедитесь, что ваш почтовый сервис не требует точного IP-адреса, с которого вы обращаетесь. Если это так, обязательно обновите эту конфигурацию у вашего провайдера услуг.

11

Однако это самое безопасное решение. Если что-то пойдёт не так, ваш старый сайт продолжит работать. Риск равен нулю.

На эту тему есть отдельная тема. Вы можете скопировать свой файл yml и данные Let’s Encrypt, а также проверить работоспособность, изменив локальные DNS-настройки так, чтобы они указывали на новый сервер.

Кроме того, если у вас есть резервные копии на S3, вы сможете спать спокойно, зная, что в случае серьёзных проблем вы сможете запустить новый сервер и восстановить резервную копию примерно за 30 минут.

12

Моё единственное реальное беспокойство касалось не столько самого переноса, сколько процесса полной настройки и возможной ошибки в каких-то параметрах — будь то настройка почтового сервиса, Let’s Encrypt или что-то ещё, — и осознания этого лишь позже, когда всё развалится. Но это, очевидно, не проблема, если система просто прочитает мой старый app.yml, так что всё в порядке.

Не совсем понимаю, что это значит, но мне кажется, что у меня такого нет… У меня Mailgun, я проверил все записи там и в DNS на Godaddy — ничего не привязано к какому-либо конкретному IP-адресу.

Ладно, звучит достаточно просто, попробую на этой неделе. Возможно, одновременно с этим обновлюсь до более мощного Droplet.

13

Вы правы!

Я не могу найти тему, в существовании которой я уверен. Кратко: настройте резервное копирование на S3 в параметрах вашей среды, выполните rsync для /var/discourse или, возможно, только для директорий ssl, letsencrypt и containers, а затем пересоберите систему.