Ресайз изображений на лету с помощью Nginx и LuaJIT (OpenResty)

Уже довольно давно, вдохновившись статьей Ресайз изображений на лету был настроен ресайз изображений с помощью ngx_http_image_filter_module и все работало как надо. Но появилась одна проблема, когда менеджеру понадобилось получать изображения с точными размерами для заливки на некоторые сервисы, т.к. это были их технические требования. К примеру, если мы имеем оригинал изображения размером 1200x1200, и при ресайзе мы пишем что-то вроде ?resize=600x400, то получим пропорционально уменьшенное изображение по наименьшему краю, размером 400x400. Так же невозможно получить изображение с бОльшим разрешением (upscale). Т.е. ?resize=1500x1500 вернет все тоже изображение 1200x1200


На помощь пришла статья OpenResty: превращаем NGINX в полноценный сервер приложений для понимания как работает Nginx с Lua и сама библиотека для Lua isage/lua-imagick — Lua pure-c bindings to ImageMagick. Почему было выбрано такое решение, а не, скажем, что-нибудь на python — потому что это быстро и удобно. Вам даже не понадобится создавать никаких файлов, все прямо в конфиге Nginx (не обязательно).


Итак, что нам понадобится


Примеры будут приведены на базе Debian.


Установка nginx и nginx-extras


apt-get update
apt-get install nginx-extras

Установка LuaJIT


apt-get -y install lua5.1 luajit-5.1 libluajit-5.1-dev

Установка imagemagick


apt-get -y install imagemagick

и библиотеки magickwand к нему, в моем случае для 6 версии


apt-cache search libmagickwand
apt-get -y install libmagickwand-6.q16-3 libmagickwand-6.q16-dev

Сборка lua-imagick


Клонируем репозиторий (ну или забираем zip и распаковываем)


cd ~
git clone https://github.com/isage/lua-imagick.git
cd lua-imagick
mkdir build
cd build
cmake ..
make
make install

Если все прошло успешно, можно настраивать Nginx.


Приведу пример конфига backend хоста, который, собственно, и занимается ресайзом. Он проксируется фронт сервером так же с Nginx, на котором происходит кэширование на накоторое время (сутки) и пр. вещи.


nginx backend config
# Backend image server
server {
    listen       8082;
    listen [::]:8082;
    set $files_root /var/www/example.lh/frontend/web;
    root $files_root;
    access_log off;
    expires 1d;

    location /files {
        # дефолтные значения ресайза
        set $w 700;
        set $h 700;
        set $q 89;

        #1-89 allowed
        if ($arg_q ~ "^([1-9]|[1-8][0-9])$") {
            set $q $arg_q;
        }

        if ($arg_resize ~ "([\d\-]+)x([\d\+\!\^]+)") {  
            set $w $1;
            set $h $2;
            rewrite  ^(.*)$   /resize/$w/$h/$q$uri     last;
        }

        rewrite  ^(.*)$   /resize/$w/$h/$q$uri     last;
    }

    location ~* ^/resize/([\d]+)/([\d\+\!\^]+)/([\d]+)/files/(.+)$ {
        default_type 'text/plain';

        set $w $1;
        set $h $2;
        set $q $3;
        set $fname $4;

        # Есть возможность вынести весь Lua код в отдельный файл
        # content_by_lua_file /var/www/some.lua;
        # lua_code_cache off; #dev
        content_by_lua '
        local magick = require "imagick"
        local img = magick.open(ngx.var.files_root .. "/files/" .. ngx.var.fname)
        if not img then ngx.exit(ngx.HTTP_NOT_FOUND) end
        img:set_gravity(magick.gravity["CenterGravity"])

        if string.match(ngx.var.h, "%d+%+") then
            local h = string.gsub(ngx.var.h, "(%+)", "")
            resize = ngx.var.w .. "x" .. h
            -- для png с альфа каналом
            img:set_bg_color(img:has_alphachannel() and "none" or img:get_bg_color())
            img:smart_resize(resize)
            img:extent(ngx.var.w, h)
        else
                img:smart_resize(ngx.var.w .. "x" .. ngx.var.h)
        end

        if ngx.var.arg_q then img:set_quality(ngx.var.q) end

        ngx.say(img:blob())
        ';
    }
}

# Upstream
upstream imageserver {
    server localhost:8082;
}

server {
    listen 80;
    server_name examaple.lh;

    # отправляем все jpg и png картинки на imageserver
    location ~* ^/files/.+\.(jpg|png) {
        proxy_buffers 8 2m;
        proxy_buffer_size 10m;
        proxy_busy_buffers_size 10m;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_pass     http://imageserver;  # Backend image server
    }
}

То, что требовалось (расширение изображения по краям) происходит с помощью img:extent() и определяется с помощью параметра resize со знаком + в конце.


Доступны следующие параметры:


  • WxH (Keep aspect-ratio, use higher dimension)
  • WxH^ (Keep aspect-ratio, use lower dimension (crop))
  • WxH! (Ignore aspect-ratio)
  • WxH+ (Keep aspect-ratio, add side borders)

Сводная таблица с результатами ресайза


Параметр uri запроса Размер выходного изображения
?resize=400x200 200x200
?resize=400x200^ 400x400
?resize=400x200! 400x200 (Не пропорционально)
?resize=400x200+ 400x200 (Пропорционально)


Итог


Учитывая всю мощь и простоту такого подхода можно реализовать вещи с довольно сложной логикой, например добавлять watermark'и или реализовать авторизацию с разграниченным доступом. Для того, чтобы узнать возможности API для работы с изображениями, можно обратиться к документации библиотеки isage/lua-imagick

Комментарии 21

    0
    В копилку — возможности капчагенерации (если сделать в той же луа key-value кеш для капч, по куке/id капчи). Разумеется, существует ReCaptcha, но она не везде заходит, плюс как фолбек.
    Ну и рендеринг всякой фигни, типа «картинок счётчиков посещений/активности» или чего-то такого. Архаично, но народу нравится :)
      +2
        0
        В статье показан очень плохой пример решения этой задачи. Дело в том, что nginx — это однопоточный сервер, построенный на идеологии асинхронного взаимодействия с сетью. Вызовы же imagemagick блокируют эвентлуп, обработка всех запросов встаёт в очередь, тайминги времен ответов (всех, а не только тех, что касаются обработки изображений) начинают дико шуметь.

        Т.к. обработка изображений — это очень cpu-intensive задача, но её стоит выносить в многопоточный обработчик.
          0

          Очень даже многопоточный. Поэтому залипнет только тот поток, который будет масштабировать картинку.
          Собственно точно так же он залипает пока жмёт gzip-ом или brotli.
          Если к этой схеме прикрутить кеширование, то вполне себе рабочий вариант.

            0
            Кроме того, нормальным решением будет еще и разнести front/resizer на разные nginx процессы, где front принимает запрос, разбирает его, кеширует ответ, а resizer висит на localhost и только ресайзит картинки.
              0
              Вы правы, в статье об этом упомянуто.
                0
                Я просто конфиг не открывал :-)
                У нас еще и по куке «опознает» ретину, и выдает по запросу 100х100 в реальности 200х200.
                  0

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


                  background: image-set(
                  url('https://example.jpg?resize=400x400') 1x,
                  url('https://example.jpg?resize=800x800') 2x)

                  ну или media

                    0
                    у нас кеш на ресайзере, для него это разные картинки.
                    Примерно такая схема:
                    запрос на фронте
                    //some.host/images/100x100/000F.jpg
                    have retina cookie -> rewrite 100x100->200x200
                    запросы на ресайзере
                    //resizer/images/100x100/000F.jpg — обычный клиент
                    //resizer/images/200x200/000F.jpg — retina клиент
                0
                Кроме того, нормальным решением будет еще и разнести front/resizer на разные nginx процессы, где front принимает запрос, разбирает его, кеширует ответ, а resizer висит на localhost и только ресайзит картинки.

                А какой смысл держать ещё один nginx, который будет заниматься только сжатием картинок? Не вижу преимущества никакого. Тогда уже можно просто сделать FastCGI-шный скрипт, который будет жать картинки и отдавать на front.
                  0
                  Не отдельный, архитектура остается типовой Nginx front + Nginx back. Фронт является балансировщиком, занимается кэшем и т.п. А бэк обслуживает само приложение + еще один upstream куда проксируются запросы ресайза.
                    0
                    У автора он тот же самый, а не другой. Другой всмысле virtual server, но он может быть и на отдельной быстрой, по процессору, тачке. У нас они вообще на хранилках картинок, где процессоры, очевидно, не загружены. И балансер, который и отдает основную статику, сверху.
                  +1
                  nginx многопроцессный, но не многопоточный. Точнее, там есть пул потоков, но он используется для IO операций с диском, content_by_lua* исполняется прямо в основном эвентлупе. В качестве проверки можно пострелять в него хотя бы через ab, чтобы ресайзилась большая картинка, и посмотреть top по потокам любого из процессов-воркеров.
                    0
                    Спасибо за уточнение. Я считал что в thread pool вынесено вообще всё блокирующее.
                0
                Если разные пользователи через web загружают фотки, которые попадают в папку на сервер, например, image_all.

                Подскажите, пожалуйста, как правильно автоматизируют процесс, чтобы, например, в папке image_01 получать эти фотки в конкретном разрешении без потери качества?

                Как это делают на порталах продаж и какие трудности, возможно, неочевидные возникают?
                Понятно, что есть модерация фоток, а на стадии image_all получают ссылку в базе данных.

                Вот в ручном режиме пробовал прогой ImBatch, — понравилось, только ищу автоматизацию.
                  0
                  Тут основная прелесть в том, что вам не нужно нарезать разные размеры предварительно. Это делается на лету параметризованно. Т.е. сохраняете вы при загрузке лишь одно оригинальное изображение и выдаёте любой ресайз динамически по запросу. И можно не хранить его нигде, разве что в кэше.
                  0

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

                    0
                    В нашем случае много, т.к. это универсальное решение не для одного сайта.
                    + время процессора будет затрачено 1 раз в сутки, дальше будет отдаваться из кэша. Да и то, даже первый ресайз происходит очень быстро.
                      0
                      У нас, к примеру, вариантов картинок около 10 штук на каждую. Хранить это совершенно ни к чему.
                      0
                      А что будет если клиент начнет в цикле запрашивать разные экзотические размеры? Как быстро сервер ляжет от нагрузки и/или забъётся кэш?
                        0

                        Смотря чего вам требуется достигнуть.
                        Можно настроить rate limit чтоб не долбили часто ngx_http_limit_req_module
                        Можно нормализовать экзотические размеры, типа 365x365 => 400x400
                        Можно ограничить с помощью ngx_http_secure_link_module
                        Ну или любую логику на lua добавить.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое