Мы занимаемся разработкой, тестированием и намеренным поиском уязвимостей в нашем форуме на Discourse, прежде чем перенести всё в продакшн. Я только что мигрировал свой тестовый форум с включённой загрузкой в S3 с одного сервера на другой, и после восстановления все URL-адреса для любых вложений были переписаны на URL форума, а не на S3…
К счастью, это тестовый форум, поэтому нам не так важно сохранение данных, однако я хотел бы:
A. Всё же исправить это.
B. Найти способ смягчить или предотвратить подобное в продакшене.
Пострадали не только посты, но и все изображения, медиафайлы, контент и аватары (что довольно серьёзно)…
Перед восстановлением вы можете настроить S3 на целевом сайте в файле app.yml (не через панель администратора). После подтверждения, что настройка выполнена и соединение с нужным бакетом установлено, можно приступать к восстановлению — медиафайлы должны быть корректно связаны.
Мы фактически сделали именно это, и именно так мы попали в эту ситуацию.
Я скопировал app.yml в точности как был в место назначения, а затем сделал резервную копию из оригинала. Проблема возникла при восстановлении: именно в этот момент URL-адреса были переписаны, несмотря на то, что ничего не изменилось, и загрузка в S3 по-прежнему была включена.
В конце концов мы решили эту проблему с помощью ребейка (мы так считаем, кэширование в Discourse очень агрессивное, поэтому среди множества опробованных решений мы точно не знаем, что именно помогло). Однако остаются без ответа вопросы о том, как проводить миграции с минимальными проблемами или даже восстанавливаться из резервной копии, если это потребуется на продакшене.
Похоже, вы настроили S3 через настройки сайта, а не через переменные окружения, как предлагал Крис. Процесс восстановления должен иметь информацию о S3. Сделать это через настройки сайта невозможно.
Вы также можете создать резервную копию без файлов загрузок через консоль, если хотите: discourse backup --sql_only
Восстановление такой резервной копии не изменит URL-адреса загрузок. Поэтому, если ваш новый сервер имеет доступ к тому же бакету S3, этот способ сработает.
Конфигурация S3 находится в файле app.yml, а не в настройках сайта.
Редактирование:
Я понимаю, что объясняю недостаточно подробно, и не хочу скрывать детали.
Мы используем OVH S3, и он настроен в файле app.yml.
Я сделал резервную копию нашего тестового форума без загрузок, но на тот момент S3 всё ещё был включён.
Затем я восстановил его на новом сайте с тем же самым файлом app.yml, и именно тогда возникла проблема. Чтобы прояснить: сейчас всё исправлено, но я не уверен, было ли это из-за того, что я несколько раз пересоздавал образ, или из-за агрессивного кэширования Discourse. Вот почему мне нужно знать, как правильно это делать, чтобы всё работало с первого раза. Я боюсь, что если когда-нибудь понадобится восстановить резервную копию на производственный экземпляр и мы столкнёмся с этой проблемой, мне нужно будет знать, как быстро её исправить, прежде чем пользователи это заметят.
Как я уже сказал, если вы хотите выполнить восстановление на сервере, использующем тот же бакет S3, убедитесь, что S3 настроен в app.yml, и создайте резервную копию без файлов (discourse backup --sql_only). При восстановлении из резервной копии, не содержащей файлов, URL-адреса загрузок не будут переписаны.
Если вы хотите выполнить восстановление на сервере, использующем другой бакет S3 или вообще не имеющем конфигурации S3, используйте полную резервную копию с файлами. URL-адреса загрузок будут переписаны во время восстановления.
Вы на 100% уверены, что настроили OVH S3 через переменные окружения в app.yml на обоих серверах и использовали резервную копию без файлов (с расширением .sql.gz)?
Когда я сначала восстановил его с загруженными данными, всё сломалось, поэтому мне пришлось полностью очистить и начать заново, сделав резервную копию без загрузок. Именно там возникла проблема. URL-адреса всё ещё были записаны неверно.
Не уверен, как так вышло. Процесс восстановления пропускает весь код, связанный с загрузкой файлов (включая переписывание URL-адресов загруженных файлов), при восстановлении из файла .sql.gz.
Возможно, мы говорим о разных вещах? Я имею в виду столбец url в таблице uploads, который обычно выглядит как //your-s3-bucket/original/..., в то время как для локальной системы это /uploads/original.
Особенность восстановления из файла .sql.gz заключается в том, что URL-адреса при этом не переписываются вообще. Предполагается, что сервер доступен по тому же имени хоста, что и сервер, на котором создавалась резервная копия. Если вы измените имена хостов, вам потребуется переназначить URL-адреса.
Имена хостов не менялись. Просто обновлены A-записи, сделана резервная копия и всё.
Отсутствовали аватары пользователей (это произошло потому, что я не перенёс папку uploads). Изображения S3 для вложений/медиа были переписаны для URL форума. Не для URL бакета.
Так что, хотя я ожидал, что URL для загрузок S3 для вышеуказанного будут записаны как https://some-bucket-name-here.s3.bhs.io.cloud.ovh.net/optimized, на самом деле это было https://forum.somedomainhere.com/uploads/optimized, что, конечно же, не будет работать.
Я могу буквально снова запустить другую виртуальную машину и сделать прямое восстановление, если вы хотите, чтобы я проверил все выполненные мной шаги.
Да, пожалуйста, сделайте это. И посмотрите на вывод после восстановления. При восстановлении .sql.gz не должно быть никаких упоминаний о переназначении URL-адресов.
Я восстановил базу данных, просто восстановив её из файла sql.gz, который хранился в S3. На данный момент из-за этого сломались только некоторые аватары пользователей и несколько сообщений, но, полагаю, это произошло потому, что они не были загружены в S3 в момент создания.
В продакшен-среде, если всё пройдет гладко с момента запуска и все данные будут в S3… если я восстановлюсь из резервной копии, у меня не возникнет той же странной проблемы, что и в исходном посте, верно?
