В некоммерческой организации, где я работаю, установлена версия Discourse 2.9.0.beta1. Когда первоначальный администратор ушел, ответственность за поддержку легла на меня. При попытке обновить учётные данные SMTP я обнаружил, что установка не может ни самостоятельно пересобраться, ни безопасно обновиться — ни через веб-интерфейс, ни через командную строку. (Если бы у меня не было горячей резервной копии экземпляра, сделанной до начала работ, это был бы очень плохой момент.) Проблема, похоже, находится довольно глубоко в Ruby, и я могу предоставить логи, если они окажутся полезными.
Я подумал, что версия может быть просто слишком старой для плавного обновления, поэтому попробовал процедуру восстановления: создал новый чистый экземпляр Discourse и загрузил в него самую свежую резервную копию форума, но этот процесс также завершился неудачно без чёткого результата. Казалось, что перед тем как процесс обновления перестал отвечать, возникли ошибки с колонками базы данных.
Какой сейчас лучший способ действий? Форум в данный момент функционирует, но я не могу ни обновить его, ни, судя по всему, использовать резервную копию. Стоит ли продолжать попытки восстановления, удвоить усилия по обновлению и собрать логи для начала работы, или есть третий вариант, который я не вижу?
Вам необходимо перенести сайт на новую виртуальную машину. Вероятно, ваша операционная система устарела и не позволяет обновить Docker до поддерживаемой версии.
Лучше перенести сайт на новую виртуальную машину с более новым и быстрым оборудованием, что также будет дешевле.
Похоже, версионирование Docker не сыграло роли в том, почему сборки Ruby не удалась, но, возможно, это всё же возможно. Загрузки Docker, которые были частью пересборки, не показали никаких особых состояний сбоя. Тем не менее, это выглядит как вариант, который я могу попробовать. Спасибо за ответ!
Ваш перенос немного усложнился тем, что у вас резервные копии на S3 настроены в базе данных, а не в переменных окружения, как описано в Настройка совместимого с S3 провайдера объектного хранилища для загрузок (хотя это относится к загрузкам, поэтому вам не нужно использовать настройку use_s3, достаточно указать бакет и расположение для резервных копий. РЕДАКТИРОВАНИЕ: Затем восстановление не удалось, потому что у вашего EC2 нет прав на запись в бакет.
Наличие балансировщика нагрузки перед вашим сайтом также меняет ситуацию по сравнению с тем, как это устроено у большинства пользователей.
И поскольку ваши учётные данные относятся к EC2, а не хранятся в базе данных или файле YML, восстановление не может завершиться.