В этом и заключается суть описанной выше настройки: очень удобно, когда тестовый сервер указывает на то же хранилище, так как это значительно упрощает синхронизацию между ними.
Однако вы не хотите, чтобы он автоматически создавал резервные копии (или удалял их) — именно поэтому эти функции отключены следующими настройками:
Согласен, что для вашего тестового сайта необходимо отключить CDN. Я сам с этим не работал, но как только вы разберётесь, как это сделать, пожалуйста, обновите или дополните вики в первом сообщении.
Спасибо, Натан. Я видел упоминание о том, что резервные копии S3 упрощают задачу, но резервная копия отличается от ресурсов сайта, поэтому я не был уверен.
Я уже отключил резервное копирование и рассылку писем, так что здесь всё в порядке. Я займусь настройкой сервера тестовой среды так, чтобы он указывал на существующее хранилище, и проверю, что он не использует CDN.
Я планирую создать зеркало моего продакшн-инстанса Discourse, используя метод rsync.
У меня есть несколько других веб-сайтов, интегрированных с Discourse, поэтому было бы идеально, если бы dev/test-версии этих сайтов могли взаимодействовать с dev/test/staging-версией Discourse.
Поэтому я буду запускать его только при необходимости и периодически восстанавливать резервную копию базы данных PROD на STAGING — не ежедневно, а возможно, раз в месяц.
Если я сделаю так, как мне предотвратить сброс некоторых настроек при восстановлении базы данных?
Например, следующие настройки были бы неоценимы:
Есть ли способ восстановить резервную копию базы данных, а затем вручную применить некоторые настройки перед запуском Discourse? Любые другие идеи, предложения или подводные камни?
Если вы храните резервные копии в S3 и настраиваете это через переменные окружения, то вы можете довольно легко развернуть новый сайт, который сможет восстановить эту резервную копию. Просто запустите новую виртуальную машину, клонируйте Discourse, скопируйте файл yml, выполните пересборку и восстановление. Вы можете переопределить настройки в базе данных с помощью переменных окружения, как указано в цитате из вашего сообщения.
Не хватает ли мне какого-то шага? Я почти уверен, что это работало год или около того назад. Но сейчас, хотя данные и заполняются, не добавляются никакие темы или сообщения, кроме Описания категории… что-то изменилось?
В итоге я восстановил старую резервную копию из одного из своих экземпляров Discourse, где ранее использовал этот метод для заполнения. Мне пришлось сделать это, но это сработало.
Есть один шаг, который нужно выполнить, чтобы можно было удалить базу данных. Если вы запустите задачу db:drop через Rake, она подскажет, что именно нужно сделать. Так что, полагаю, вам нужно сначала выполнить sv stop unicorn, затем удалить, создать и применить миграции к базе данных, а уже потом запускать задачу. Или это следующий шаг, который я бы попробовал, но у вас уже есть другое решение…
Я пытаюсь загрузить тестовые данные на свой staging-сервер, но получаю ошибку:
rake aborted!
Database commands are only supported in development environment
Это multisite-настройка, поэтому команды, которые я выполняю, следующие:
./launcher enter web_only
ALLOW_DEV_POPULATE=1 bundle install
RAILS_DB=instance-x ALLOW_DEV_POPULATE=1 rake dev:populate
Раньше я использовал их без проблем, но теперь возникает эта ошибка. Можно ли задать переменную окружения, чтобы разрешить команды базы данных в production-среде?
