Как правильно организовать работу с изображениями при локальной разработке/обслуживании сайтов?

Question

[simon_db]

Допустим есть сайт. Подключается к его обслуживанию разработчик. Он создает локально окружение схожее с продакшен. Если с кодом и базой-данных все примерно ясно, то как быть с изображениями, которые используются на сайте в новостях, блогах, товарах и прочее? Если проект маленький и изображений несколько гигабайт, то еще ладно, можно скопировать. Но как быть если изображений десятки гагабайт, не копировать же их себе локально, только ради того, чтобы корректно отображался сайт у разработчика.

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

На данный момент использую свой класс, который на любой запрос сервера статики отдает одно и тоже изображение, но сохраняет его (генерация превью) как новый файл.

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

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

Answer 1

[Владимир Муковоз]

Можно проксировать изображения с продакшена.

location ~* ^.+\.(svg|svgz|ttf|jpg|jpeg|gif|png|ico|webp)$ {
    try_files $uri @prod;
    access_log off;
    expires 8d;
}
location @prod {
    proxy_pass       http://prod.ru;
}

Поясню для тех кто не вкурил, с такой организацией nginx ищет файл на сайте и если его там нет тогда запрашивает его через проксю с продакшена)
Писал на коленке, данная вещь не тестировалась нигде, так что буду признателен если отпишите как оно)

P.S. естественно этот конфиг подойдёт только для nginx, но я думаю и на апаче изобразить такое же просто. Но я конкретно с апачем редко сталкиваюсь, так что написал на том что мне понятно.

Comments

[simon_db]

Это решение подойдет только в случае, если на дев сервере не нужно как-то модифицировать ранее загруженные изображения.
Например, вы захотите обкатать сам (локально), а после дать клиенту возможность на стейджинг сервере потестировать новый супер код по умной обрезке фото. Мне (разработчику) и клиенту хочется видеть, как это будет выглядеть на реальных товара (утюгах, телевизорах, люстрах, и прочих разнородных товарах).

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

[Владимир Муковоз]

simon_db, вообще-то Вы не правы. Вполне себе подходит) Ведь он сначала проверяет есть ли фотка локально и только если её нет тогда запрашивает с продакшена. Так что ты прекрасно можешь скинуть часть фото для демонстрации к себе. А если обрезка фото делается средствами nginx например то вообще ничего не надо скидывать оно и так будет работать.

[Владимир Муковоз]

simon_db, я решил проблему которую Вы описали в своём вопросе.

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

В моём случае будут тянуться локально новые превью) Вы определитесь что Вам надо). Мой ответ максимально подходит под Ваш вопрос.

[simon_db]

Мне не совсем понятно как это поможет. Компонент, который генерирует превью возьмет из БД относительный путь к изображению и попытается открыть его, чтобы после модифицировать. Т.к его нет локально, то выбросит исключение. Метод не будет запрашивать файл в этом случае по HTTP, он будет искать его локально. Т.е тут nginx тут вообще не при чем. Вот при рендеринге странице в браузере ваш способ сработает, но это же только на чтение.

[simon_db]

В моём случае будут тянуться локально новые превью) Вы определитесь что Вам надо). Мой ответ максимально подходит под Ваш вопрос.

Какие я вижу решения данного вопроса:
1) Если нужно только отображать изображения, которые есть на продакшене, то ваш вариант с прокси подойдет
2) В большинстве других случае подойдет решение от @mrsoul
3) Для сложный случаев, когда нужна вся база и возможность редактировать изображения не загружая их, то написание своего бекэнда хранения фото. При рендеринге страницы в браузере использовать прокси, а при изменении файла, перелавливать исключение о недоступности файла, подгружать его с продакшен и подсовывать на дальнейшую обработку.

[Владимир Муковоз]

simon_db, я имел ввиду что ты можешь работать с изображениями. И те изображения которые ты загрузишь на дев будут отображаться с дев, а те что не загрузишь, ну те будут тянуться с прода. Как-то так. Понятно что те что не загружены ты не отредактируешь в редакторе.

Answer 2

[Дмитрий]

Для себя решил проблему таким образом. На копиях разработчиков нет необходимости в полной базе товаров, поэтому перед созданием копии, удаляется 90% товаров, соответственно, столько же изображений. Оставшегося объёма достаточно для тестирования новых фич по изображениям. Изображения товаров - основная масса изображений. Изображения вёрстки, прочие контентные изображения переносятся на копию полностью. Но в любом случае, если копия не находит у себя запрошенного изображения, она идёт за ним на прод

Comments

[simon_db]

Конечно же можно очистить базу от большинства товаров с фото. Но где гарантия, что завтра не потребуется реализовать или доработать фильтр товаров или механизм кэширования. В данном случае потребуется вся база, иначе замеры производительности будут не объективны.
Да и сама задача по очистке базы требует внимание и потребует его всегда, а если к этому еще и добавить плохую/не самую удачную для этого случая организацию хранения фото, то это потребует еще и решения задачи, как выцепить с сервера фото, только для оставшихся товаров.

[Дмитрий]

На мой взгляд замер производительности на копии всегда будет не объективным (копия - виртуалка), поэтому вся база нам не требуется. У нас фотография к товарам сопровождается записью в в БД, поэтому при удалении товара, знаем какое фото нужно удалить. Процесс создание копии полностью автоматизирован - его делает инстанс в облаке из ночного архива сайта. Процесс удаление лишних данных (товаров, изображений, заказов) занимает около часа.

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

[Станислав Б]

иначе замеры производительности будут не объективны

надо быть честными. замеры производительности на локальной машине разраба в любом случае будут не объективны

[simon_db]

Да, это так, но замерить очевидные проседания в том же фильтре все же будет проще на 50 000 товаров, чем на 5000, особенно если используется EAV и т.п решения.

[simon_db]

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

Да, этот вариант я и описывал в тексте вопроса по организации.
Было интересно узнать еще подходы к этому вопросу.

[simon_db]

Дмитрий,

У нас фотография к товарам сопровождается записью в в БД, поэтому при удалении товара, знаем какое фото нужно удалить. Процесс создание копии полностью автоматизирован - его делает инстанс в облаке из ночного архива сайта. Процесс удаление лишних данных (товаров, изображений, заказов) занимает около часа.

Это интересный вариант, спасибо. Наверное из универсальных, это пока лучшее, что приходит в голову. Правда, требует доп. вложений (облако, написание скрипта, парсинг выхлопа визивиг редактора).

Достаточно часто работаю c Django, там хорошо реализован механизм хранения файлов, который позволяет удобно написать свой бекэнд для хранения файлов. Для дев сервера можно подсовывать свой бекэнд, который будет читать файлы с продакшен по http, а сохранять локально. Я писал свое решение, после нашел репу, работающую по похожему принципу. https://github.com/beniwohli/django-localdevstorage Нужно будет внимательно изучить этот компонент.

[Дмитрий]

Правда, требует доп. вложений (облако, написание скрипта, парсинг выхлопа визивиг редактора).

Да, изначально нашу систему долго делали, но в результате получилось что поддерживать копии в актуальном состоянии проще простого - запустил плейбук ансибла и он всё сделал (поднял инстанс, скачал архивы, обработал, создал новые и загрузил к нам на сервер). В качестве облака - спотовый инстанс в амазоне, так что именно облако по деньгам совсем недорого выходит.

Answer 3

[Станислав]

Для начала, для разных вариантов реализации проекта все-таки могут быть разные решения. Для фронтенд части приложения на том же React вы вообще можете не париться насчет бекенда, он забирается из интернета по http(s).

Если речь идет все-таки о разработке бекенда, или же о разработке спаянного фронтенда с бекендом на чем-то отличным от упомянутого React (и подобные библиотеки/фреймворки и приложения на них пока скорее исключение из правил), то тут опять варианты:

Первый вариант - когда у вас все равно есть некое API с этими крупными данными и оно живет где-то отдельно в сети. Или например вообще используется CDN. Ваше приложение опять же ходит туда просто по http(s), где бы оно ни было.

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

Условия могут выглядеть примерно так: Среда выполнения тестовая? Да => Мы хотим получить часть данных, которые считаем большими? Да => Использовать отдельный экземпляр подключения к БД/другое для получения данных.