В настоящее время я занимаюсь миграцией нашего сервера с существующей развёртки на базе Bitnami (довольно старой версии) на официально поддерживаемую установку в AWS с использованием последней версии Discourse. Эта новая установка использует внешний экземпляр Elasticache и RDS, а также будет применять S3 для резервных копий и загрузок.
У меня два вопроса:
Старый сервер Discourse работает на очень старой версии. Запустятся ли все необходимые команды обновления при выполнении резервного копирования и восстановления на новом сервере Discourse?
Если я скопирую файл резервной копии в новый контейнер Docker с Discourse на новом сервере и инициирую восстановление через командную строку, будут ли перезаписаны новые значения бакета, которые я указал в конфигурации, в процессе восстановления, или будут использованы мои новые значения? Я предполагаю, что моя новая база данных будет заполнена данными из резервной копии, а после выхода из контейнера и запуска команды ./launcher rebuild app будут применены мои новые значения S3.
Если мои предположения верны, то перед выполнением восстановления я должен скопировать содержимое старых бакетов S3 в новые?
Есть ли какие-либо подводные камни при выполнении такого типа миграции с помощью резервной копии?
Возможно, я что-то упускаю, но зачем вы создаёте новые бакеты? Создание нового бакета для резервных копий с соответствующими правилами жизненного цикла выглядит приемлемым, однако если ваш текущий экземпляр Discourse использует бакет для загрузки файлов S3, у вас возникнут проблемы.
Я не на 100% уверен, что миграция с Bitnami пройдет без сбоев, поэтому мы не хотим затрагивать существующие данные на случай, если нам придется отменить миграцию.
Мы изменили схему именования бакетов, поэтому решили, что проще будет создать два совершенно новых бакета для этой задачи.
Меня больше всего беспокоит пункт 1, поэтому я просто проявляю особую осторожность.
Какие проблемы вы видите с новым бакетом для загрузки? Старый сервер Discourse будет переведен в режим только для чтения. План таков: после запуска и проверки нового сервера мы остановим старый сервер, изменим DNS на указание нового сервера, затем очистим кэш CDN (CloudFront) и только после этого откроем доступ для публики.
Я упустил, что вы собираетесь перенести данные из старых бакетов. Посмотрел в AWS — всё выглядит просто. Если бы это было на мне, я бы не стал менять бакеты до переезда на AWS или на новый сервер где-либо ещё.
Официально поддерживаемой? Не уверен в этом.
Настоятельно рекомендую обновить Discourse перед переездом на новый сервер.
На старом экземпляре, если этого ещё не сделано, рекомендую перенести конфигурацию S3 в app.yml перед переездом.
Меня очень интересует, почему такая установка считается выгодным предложением.
Судя по многочисленным сообщениям о неподдерживаемых установках, это больше проблем, чем пользы, если только люди не делают это для обучения или экспериментов.
Такая конфигурация может считаться неподдерживаемой с точки зрения Discourse, но с позиции корпоративной IT-организации RDS и ElastiCache могут быть стандартными решениями, тогда как стандартная установка Discourse будет выглядеть исключением.
Как уже отметил @RGJ, наша корпоративная инфраструктура использует внешние сервисы для таких задач, как кэширование, базы данных и т. д., поэтому мы применяем Elasticache и RDS. Это позволяет нам обеспечить полное резервное копирование и избыточность для этих сервисов, а также усилить контроль безопасности. С точки зрения Discourse это официальная и поддерживаемая установка — мы просто используем другой набор шаблонов: discourse_docker/samples/web_only.yml at main · discourse/discourse_docker · GitHub (возможно, слово «стандартная» было немного вводящим в заблуждение, приношу извинения).
Похоже, что сначала нам следует обновить имена бакетов для существующей установки, а затем выполнить миграцию на новый сервер. Обновление существующей установки до последней версии не вариант — ранее у нас возникали проблемы с обновлением через Bitnami, поэтому мы перешли к официальному методу установки.
Могу ли я спросить, какие проблемы могут возникнуть, если мы выполним восстановление с использованием существующих бакетов, а затем обновим файл app.yml, чтобы он ссылался на новые бакеты? Разве все переменные окружения DISCOURSE_ не имеют приоритета над любыми настройками в базе данных (если это применимо)? Или есть что-то ещё, что может вызвать проблемы?
Потому что, если вы сделаете это до миграции и что-то пойдёт не так, у вас возникнет проблема на старой инстансе Bitnami, а не на свежеустановленном стандартном. Кроме того, помимо старой версии, даже упоминание слова Bitnami значительно снизит шансы на получение поддержки здесь, на meta.
Ещё один вопрос, если можно: когда я запускаю восстановление из командной строки внутри контейнера Discourse, используется ли существующий файл конфигурации /var/www/discourse/config/discourse.conf для сведений о подключении к базе данных, подключении к Redis и т. д., или этот файл перезаписывается данными из файла резервной копии?
discourse.conf генерируется из app.yml и не включается в файл резервной копии.
Обычно параметры, указанные в discourse.conf, имеют приоритет над настройками сайта.
Таким образом, если у вас есть параметр setting_foo в базе данных, вы можете переопределить его, указав DISCOURSE_SETTING_FOO в файле app.yml. Это приведёт к генерации параметра setting_foo в файле discourse.conf.
Подключение контейнера Discourse к внешнему серверу PostgreSQL и Redis с использованием нашего образа контейнера и наших инструментов является поддерживаемым способом установки.
RDS[1] — это PostgreSQL, а ElastiCache — это Redis, это допустимо.
Это должно сработать, мы делаем так для клиентов, переходящих на наше хостинг-решение.
Мой предпочтительный вариант — сохранить процесс максимально простым. Поэтому, если вы сможете создать полную резервную копию (включая загрузки) на старом сервере и восстановить её на новом, это позволит вам полностью протестировать новую настройку без какого-либо воздействия на старую.
Я сделаю резервное копирование и восстановление без изменения названий бакетов, как также предложил @RGJ. Как я уже говорил, моя забота заключалась в том, чтобы никак не затронуть существующие данные на сервере, но если я сначала сделаю резервную копию существующих бакетов и убедлюсь, что существующий сервер находится в режиме только для чтения во время миграции, я думаю, что целостность загруженных данных в бакетах будет хорошо защищена.
