Не лучше ли использовать опцию :local/:disk в производственной среде при использовании ActiveStorage? Из-за этого я не смогу сделать резервную копию файлов?

Я работаю над проектом, используя Rails в качестве внутреннего API-сервера. Загрузка файлов клиентов будет одной из самых важных частей этого приложения (это что-то вроде системы CRM/ERP). Однако мой клиент предпочитает хранить все данные и файлы на своем собственном сервере из-за проблем с безопасностью и конфиденциальностью своих клиентов.

Однако, пока я читаю документы ActiveStorage, похоже, что опция :disk используется только для среды test и development. Я понимаю, что использование облачного хранилища, такого как s3, выиграет от масштабируемости и резервного копирования, которые очень безопасны и гибки для веб-разработки, но, в конце концов, вы знаете, это требование клиента.

1) Поэтому хотелось бы знать, не лучше ли использовать :disk в любой производственной среде? Какие минусы я могу упустить?

Также не будет ли мне тяжело делать бекап для файлов, как я увидел в пути /storage, файлы все сохранены не в те имена исходных файлов.

У меня есть предположение, что могу ли я просто сделать резервную копию всех сайтов, просто выполнив pg_dump и клонировать весь каталог сайта, включая файл /storage (они будут gitignore, поэтому мне нужно сделать их резервную копию самостоятельно и сделать git clone git тянуть вещи во время восстановления или перехода на сервер). Будет ли этот рабочий процесс работать безупречно?

2) Каким должен быть фактический процесс резервного копирования и восстановления, если я использую параметр :disk в ActiveStorage?

Спасибо за вашу помощь, и я ценю любую вашу помощь!


ruby-on-rails cloud-storage rails-activestorage
person Joe Leung    schedule 15.07.2019    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Диск и локальный действительно не рекомендуются для производства.

Если вы потеряете содержимое таблицы или некоторые файлы в хранилище, возможно, вы не сможете восстановить свои данные.

Растущий каталог storage/ затруднит перемещение вашего приложения в другое место, поскольку вам придется копировать весь контент вместе с кодом.

Это также затруднит горизонтальное масштабирование, поскольку каталог storage/ должен присутствовать во всех экземплярах ваших приложений и всегда синхронизироваться. Вы можете решить эту проблему, настроив общий ресурс NFS где-нибудь и смонтировав его в хранилище /, но это может привести к некоторым проблемам с надежностью — например, ошибка тайм-аута или прав доступа при записи файла будет генерировать запись таблицы ActiveStorage, но без связанного файла => много досадных ошибок.

Я считаю, что также может быть довольно сложно делать инкрементные резервные копии, вам придется сбросить таблицу и заархивировать ее вместе со всеми хранилищами/файлами, если что-то изменится во время резервного копирования или восстановления данных, вы испытаете все виды ошибок.

Это не совсем невозможно обойти, просто практически невозможно.

Вы можете проверить Minio или подобное приложение. Это дает вам поддержку ActiveStorage без каких-либо затрат на S3 и проблем с конфиденциальностью данных. Просто поместите его на экземпляр докера где-нибудь в вашей сети, настройте постоянство и резервное копирование/RAID, и все готово.

person Nick M    schedule 15.07.2019
comment
Также могут спросить, если я хочу перенести все файлы с Minio на настоящий Amazon S3, возможно ли это? Есть ли удобный способ сохранить ассоциацию ActiveStorage и выполнить перенос? - person Joe Leung; 16.07.2019
comment
Теоретически это должно быть таким же простым, как копирование каталога в корзину и обновление вашего yml. Однако у меня есть предчувствие, что это не может быть так просто, всегда должно быть что-то, что не работает с этими проектами с открытым исходным кодом, поэтому вам может потребоваться настроить скрипт для перебора ресурсов, загрузить их на S3 и обновить записи таблицы active_storage_. Это не невозможно, просто немного хлопотно. AS был разработан с очень конкретной целью (Basecamp), поэтому он может не обслуживать точно все варианты использования и не быть простым в управлении, несмотря на всю связанную с этим шумиху. - person Nick M; 16.07.2019
comment
Помимо того, что на файлы не обязательно ссылаются только по их имени файла (и дополнительный шаг перенаправления на загруженные изображения вместо того, чтобы просто обслуживать их), недостатки использования disk — это то, с чем приходится иметь дело большинству традиционных (мало зависимых) веб-приложений, ИМХО. Люди имеют эти проблемы с тех пор. Кроме того, я не вижу, где наличие файлов во внешнем хранилище делает процесс резервного копирования/восстановления менее сложным. И, конечно же, вы можете восстановить, но для этого вам, скорее всего, придется написать несколько сценариев — простой копии может быть недостаточно. - person Felix; 07.04.2020