Подскажите web-сервер для простого ресайза изображений «на лету»

nginx + https://www.php.net/manual/en/book.image.php ?

Вот как раз ищется решение чтобы НЕ заниматься подобной ерундой.

PHP-шные биндинги к Си-шной libgd - гемор тот еще - мало того что придется изучать libgd - так еще придется изучать особенности биндингов. Врагу не пожелаю ковыряться во всем этом.

Если уж хочется руками делать - ГОРАЗДО проще написать конкретные конвертеры на Светом Шеле, используя утилиты ImageMagic - это довольно мощная штука, и труЪ unix-way. И потом уже из PHP через exec() вызывать эти скрипты.

Или вообще конвертеры на C написать, с использованием тех же нативных С-библиотек. Но тут уже квалификация в С нужна. (А она в любом случае нужна, потому что этот мир написан на C :))

Плюс такого подхода - не придется выкидывать знания на помойку при переходе на другие ЯП. (Я про знания особенностей биндинга к языку.)

Но я даже этого не хочу - я хочу ПРОСТОЙ веб-сервер, которому в конфиг скармливаются команды OC (конвертеры), с помощью которых он сам все на лету сконвертит, положит в кеш и раздаст. Конвертеры напишу как пайпы ImageMagick`а - оно удобное в CLI.

Это не задача веб-сервера делать что-то с присылаемыми ему картинками. Это задача бекэнда. Не умеешь бекэнд – пиши в job.

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

http://nginx.org/en/docs/http/ngx_http_image_filter_module.html

А бэкэнд это разве не веб-сервер? С каких пор? :))

Ага, идея правильная, спасибо. Видимо для чистого ресайза простого - этого достаточно. Оно даже у себя кешировать умеет (без этого легко положить прод ддосом :))

Может быть есть еще варианты, не привязанные к GD и с функционалом для выполнения произвольной команды? Например watermark или еще что…

Я чото п. Почему ресайзом должен заниматься веб-сервер?

Бекэнд это приложение, которое спрятано за веб-сервером. Веб-сервер это фронтэнд.

Веб-сервер - это то что принимает HTTP-запрос и выдает HTTP-ответ.

https://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%B1-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80

Ваш «бэкэнд» принимает HTTP-запрос и выдает HTTP-ответ, нет?

Идешь и пишешь https://github.com/intaro/nginx-image-filter-watermark

А почему нет, в чем проблема?

Ну так, ни в чем. Можно и тестировщиц попросить посуду помыть, девочки же. По сути ты хочешь заменить вызов баш-скрипта отправкой запроса веб-серверу, который и вызовет тот самый скрипт, разница только в скорости работы.

Ага, тоже годно. Как понимаю это про тот же модуль, про который выше было.

Веб-сервер - это то что принимает HTTP-запрос и выдает HTTP-ответ.

Верно.

Ваш «бэкэнд» принимает HTTP-запрос и выдает HTTP-ответ, нет?

Нет, бэкэнд принимает запрос от веб-сервера по какому-то внутреннему протоколу (например, fastcgi, хотя бывает и http).

Веб-сервер (фронтэнд) - это тот, кто принимает соединения непосредственно из интернета. Приложение (бэкэнд) - тот, кто реализует полезную логику работы сайта, обычно это отдельная программа, которая ничего не знает про детали реализации http/https/httpv2 итд - занимается только полезной нагрузкой.

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

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

Повторяю, этот сервер на лету сконвертит картинку И ПОЛОЖИТ ее сконвертированную копию в ФС (или еще как-нибудь у себя закеширует).

Ну и где здесь «разница в скорости работы»?

И да, не совсем «заменить вызов баш-скрипта отправкой запроса веб-серверу», потому что запрос пойдет непосредственно от клиенского браузера на URL, по которому отдается картинка (неважно, из кеша или в первый раз «на лету» конвертируется).

Подашь ему миллион картинок - узнаешь разницу и в скорости, и в занимаемой памяти. Кстати, веб-сервер можно написать на 1С, если тебе не принципиально.

Нет, бэкэнд принимает запрос от веб-сервера по какому-то внутреннему протоколу (например, fastcgi, хотя бывает и http).

может да а может нет.

обычно это отдельная программа, которая ничего не знает про детали реализации http/https/httpv2

На go например «бэкэнд» это бинарник, который целиком реализует функционал веб-сервера (включая и протокол http, и http2), можно его непосредственно наружу выставлять, если в https оборачивать не нужно. Можно при желании и https внутри реализовать.

Речь о том, что в итоге бэкэнд РЕАЛИЗУЕТ функционал веб-сервера - где-то непосредственно, где-то с «приставкой».

Я про утверждения типа «веб сервер не должен делать то-то, это должен делать бэкэнд» - почему - непонятно.

Да какая разница кто будет ресайзить этот миллион картинок - веб-сервер который «бэкэнд», или веб-сервер который специальный для ресайза? Они же один и тот же баш-скрипт будут вызывать - в чем ПРИНЦИПИАЛЬНАЯ разница-то?

в питоне есть pillow и что-то еще из этой серии. оберни это каким-нибудь фласком если прям вот в вебе хочется и вуаля.

В том, что ВЕБ-СЕРВЕР НЕ НУЖЕН. Добавь тег к посту, кстати.

Веб-сервер (фронтэнд) - это тот, кто принимает соединения непосредственно из интернета.

Зачем давать свои спорные формулировки, когда можно сказать, что фронтенд это 6 уровень модели OSI и тогда станет понятно, что из одного только веб-сервера фронтенд не получится.

Ну так топик как раз про решение для того чтобы не использовать pillow и другие ЯП-специфичные биндинги к си-шным либам. А про то чтобы написать произвольные конвертеры с CLI-интерфейсом НА ЧЕМ УГОДНО, и скормить их специальному веб-серверу, который их вызовет через exec.

Что угодно - это шел, Си, или вообще тот же Python+pillow.

И да, так просто

оберни это каким-нибудь фласком если прям вот в вебе хочется и вуаля.

не получится!

Под капотом придется реализовать следующее:

1. Прочитать сложный конфиг с древовидной структурой - какие запросы соответствуют каким исходным файлам и каким конвертациям.
2. Запустить пул воркеров конвертации.
3. Принять запрос, проверить его на правильный формат.
4. Проверить запрос на соответствие конфигу (п. 1).
5. Проверить, существует ли файл в ФС
6. Если да - отдать. При этом выставить все HTTP-хедеры ПРАВИЛЬНО (типа Content-Type, Content-Length, etc…)
7. Если нет - поставить задачу в очередь, подписаться на событие ее выполнения.
8. Воркер, отвечающий за выполнение конвертации - должен взять задачу, выполнить, положить файл куда надо в ФС, и уведомить очередь о том что задача выполнена (и прикрепить к ней ошибку, если была).
9. Очередь уведомит всех сабскрайберов, что задача выполнена.
10. Теперь сконвертированный файл есть в ФС. Каждый сабскрайбер (держащий до сих пор соединение с клиентом) должен его отдать, выполнив все как в п. 6. Или выдать ошибку, которая прилетела вместе с уведомлением о выполнении задачи.

Если выкинуть пункты 2, 7, 8 и 9 - то есть тупо «получили запрос - файла нет - конвертируем», то в нагруженном проде получим много одновременных параллельных (дорогих!) операций по конвертации одного и того же, а потом ситуацию с записью одного и того же в один и тот же файл.

И это я набросал упрощенный сценарий, при котором у нас исходный файл находится в локальной ФС. А еще есть вариант что его надо откуда-то получить, например по HTTP. В этом случае наступает тотальный ад - воркер конвертации должен поставить задачу ЕЩЕ В ОДНУ ОЧЕРЕДЬ (очередь для получения оригиналов) и подписаться на выполнение этой задачи. И только по ее выполнении уже начать свою конвертацию. Получается две разных очереди, два типа задач, два пула воркеров. Если опять упростить - опять получим много параллельных запросов одного и того же.

PS: если бы сразу знал, что так много надо будет писать - не писал бы :)) По ходу написания вылезали все новые и новые пункты :-\

написать произвольные конвертеры с CLI-интерфейсом НА ЧЕМ УГОДНО, и скормить их специальному веб-серверу, который их вызовет через exec.

Звучит как простой советский cgi-bin. В apache элементарно, в nginx чуть посложнее вроде.

Шизофазии тред.

наступает тотальный ад

Да ладно, ничего особо сложного, за выходные можно это всё напейсать, ну может за пару. Если деньги есть - го в job.

ага, элементарно - скриптик вызвать. А потом - вот то что с 10-ю пунктами и ниже два абзаца :)

изучать libgd

Держите толстого тролля!

Первая строчка в гугле https://imgproxy.net/

А что не так - типа либа слишком простая чтобы ее изучать? Или биндинги все потроха скрывают, достаточно их изучить?

По обоим пунктам не согласен, там есть где позалипать ))

Речь про то что все эти штуки с картинками в итоге используют ЯП-специфичные биндинги к сишным либам. Я например серверный софт на 5 языках программирования в разное время писал, сейчас вот уже не хочу в спецификациях этих биндингов красноглазить. Тем более они еще и к разным либам. Либо Си, либо шелл+ImageMagick CLI toolkit.

Правильно, только оно в ИХ облаке через платную подписку.

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

И вообще - конвертер должен быть ПРОИЗВОЛЬНОЙ CLI-программой.

Если не хочется программировать

Значит надо заплатить тому, кто запрограммирувает

я наверное не совсем точно сформулировал топик, уточнил.

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

Значит надо заплатить тому

я как раз и есть «тот» :))

Ты удосужься научиться читать, там конкретно даже для твой шизы поддержка есть))

CDN чудненько это делают )

Тот же BunnyCDN у нас тут ребятишки настроили на получение width/height - я прям в восторге был.

эмммммм..... правда не знаю как именно они это делали, может там какой-то Питон свой крутится.

Я 20 лет назад на php3 с gd галерею за 4 часа запилил с ресайзом и подгонкой по высоте иконок. Зная php только в общих чертах. Ну и к IM/GM биндинги в php тоже отличные. Лишние fork() для команд IM на веб сервере не нужны.

Простые вещи делаются просто - да. Но бывают и посложнее.

Форки - не проблема, они дешевые. А время программистов - дорогое.

На среднем веб-сервисе 99% нагрузки - это чтение и 1% - запись (грубо, но идея понятна).

https://github.com/h2non/imaginary

https://docs.squidex.io/id-01-getting-started/installation/configuration/deploying-the-image-resizer-service

что-то вроде этого?

на dockerhub есть куча готовых микросервисов конвертеров/ресайзеров/сжимальщиков/etc. тебе просто нужно найти подходящий.

вот еще например https://github.com/imgproxy/imgproxy

этот микросервис запускается в докере, и есть бесплатная self-host версия.

не получится

получится. почему нет?

написать произвольные конвертеры

придется реализовать следующее

ну так и напиши и реализуй. а то такое впечатление, что ты хочешь выс**ться и не надуться.

Под капотом придется реализовать следующее:

На питоне я бы взял или cherokee или flask как веб-сервер + celery или dramatiq для запуска конвертации и получения изображений.

А бэкэнд это разве не веб-сервер? С каких пор? :))

Нет, бекэнд может работать по разным протоколам: cgi, fastcgi, wsgi. И даже http. Обычно это прослойка между фронтэндом и бекэндом.

На питоне я бы взял или cherokee или flask как веб-сервер + celery или dramatiq для запуска конвертации и получения изображений.

Хороший план!

я бы еще повесил это все на RabbitMQ и с монолита отправлял джобы в очередь на конвертацию изображений. Это будет очень хорошо скейлится, т.к можно будет сразу развернуть кучу подов в кубере, обрабатывать по принципу «кто первый джобу взял того и тапки», и скейлить в зависимости от заполненности кьюхи.

Кстати вот и проект на выходные. Спасибо ТС-у за идею!

на javax.ImageIO делается запросто включая прозрачное масштабируемое кеширование