I am currently in the process of migrating our server from an existing Bitnami based deployment (quite an old version) to the officially supported install in AWS using the latest Discourse release. This new install has an external Elasticache and RDS instance and also will use S3 for backups and uploads.
I have 2 questions:
The old Discourse server is on a pretty old version - by doing the backup/restore in the new Discourse server will that just run all the relevant upgrade commands?
If I copy the backup file into the new Discourse docker container on the new server and initiate the restore on the command line, will the new bucket values I set in my config be overwritten as part of the restore or will my new values be used? I assume my new DB is populated from the backup and then when I exist the container and run ./launcher rebuild app my new S3 values will be used.
If my assumptions are correct, then before I perform the restore I assume I should copy the contents of the old S3 buckets to the new ones?
Are there any other gotchas for doing this type of migration with a backup?
Maybe I am missing something but, why are you establishing new buckets? A new backup bucket with appropriate lifecycle rules seems ok to do but if your existing Discourse instance is using S3 upload bucket you will have some problems.
I am not 100% sure the migration from Bitnami will work without a hitch so we don’t want to impact any existing data incase we need to abort the migration
We changed our bucket naming so thought it easier to have 2 brand new buckets for this
Point 1 is the one that worries me so just being extra careful.
What issues do you envisage with the new uploads bucket? The old Discourse server will be put into read only mode. The plan is once the new server is up and validated we will stop our old server, change the DNS to the new server and then purge the cache in the CDN (Cloudfront) and then open it up to the public.
I missed that you were going to copy over the data from the old buckets. Took a look at AWS, looks to be straight forward. If it were me I would not muck with changing buckets before moving to AWS or a new server elsewhere.
Officially supported?? Not so sure about that.
Strongly suggest you get Discourse updated before the move to a new server.
On the old instance, suggest you move the S3 config to the app.yml if not there already before moving.
I am very curious about how doing this type of install is a value added proposition.
From the numerous posts around unsupported installs it seems more trouble than benefit unless folks are doing them for learning/experimentation.
Такая конфигурация может считаться неподдерживаемой с точки зрения 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_ не имеют приоритета над любыми настройками в базе данных (если это применимо)? Или есть что-то ещё, что может вызвать проблемы?
Since if you do it prior to the migration and things go south, you’ll have the issue on the older Bitnami instance instead of your freshly installed standard instance. And, besides the old version, even the mention of the word Bitnami will make you get far, far less support here on 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. Как я уже говорил, моя забота заключалась в том, чтобы никак не затронуть существующие данные на сервере, но если я сначала сделаю резервную копию существующих бакетов и убедлюсь, что существующий сервер находится в режиме только для чтения во время миграции, я думаю, что целостность загруженных данных в бакетах будет хорошо защищена.
