Контроль версий загруженных изображений в файловую систему

Question

После прочтения Хранение изображений в БД - да или нет? Я думаю, что файловая система - подходящее место для хранения изображений. Но я хотел бы знать, как вы справляетесь с резервным копированием / контролем версий загруженных изображений в ваших различных средах (dev / stage / prod) и для балансировки сетевой нагрузки?

Эти проблемы довольно легко решаются при работе с базой данных, например сделать резервную копию из производственной среды и восстановить БД в среде разработки.

Что вы думаете об использовании, например, git для управления версиями загруженных файлов, например?

Производственная среда:

• Изображение загружается в общую папку на веб-сервере.
• Метаданные хранятся в базе данных
• Изображение автоматически добавляется в репозиторий git

Разработчик за работой:

• Проверяет исходный код.
• Запускает скрипт для восстановления базы данных.
• Запускает скрипт для получения последних изображений.

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

Answer 1

Для нас контроль версий не так важен, как распространение. Метаданные добавляются через веб-администратора, а изображения сбрасываются на сервер администратора. Скрипты Rsync выталкивают их в кластер, который обслуживает образы продуктов. Для dev / test мы просто rsync с главного сервера prod обратно на сервер dev.

rsync отлично подходит для балансировки и распределения нагрузки. Если вы используете git для администратора / главного сервера, у вас есть довольно хорошее решение.

Если у вас все в порядке с резервной копией, которая сохраняет историю файлов во время резервного копирования (в отличие от контроля версий при каждой ревизии), то некоторая адаптация этого может помочь: Автоматизированные резервные копии в виде моментальных снимков с rsync .

Answer 2

Это может работать, но я бы сохранял эти изображения в репозитории git, который затем был бы подмодулем репозитория git с исходным кодом.
Таким образом, между кодом и изображениями существует тесная связь, даже если изображения находятся в собственном репо.
Кроме того, он позволяет избежать проблем, связанных с тем, что git gc или git prune менее эффективны при большом количестве бинарных файлов: если изображения находятся в своем собственном репо и с небольшими вариациями для каждого из них, обслуживание этого репо достаточно легкое. Тогда как репозиторий исходного кода может развиваться гораздо более динамично, с обычными командами обслуживания git в игре.