Меню Рубрики

Установка lua для nginx

Nginx + Lua + Redis. Эффективно обрабатываем сессию и отдаем данные


Предположим, у вас есть данные, которые вы хотите кэшировать и отдавать, не используя тяжелые языки, как php, при этом проверяя, что пользователь аутентифицирован и имеет право на доступ к данным. Сегодня я расскажу, как, используя связку nginx lua redis, выполнить эту задачу, снять нагрузку с сервера и увеличить скорость отдачи информации сервером в десятки раз.

Для начала необходимо собрать nginx с модулем nginx_lua_module.

Установим компилятор lua (версии 2.0 или 2.1)

Для сборки nginx с nginx devel kit необходим http_rewrite_module, а тот с свою очередь требует библиотеку pcre. Поэтому установим ее

Сконфигурируем и установим nginx

Скачаем библиотеку lua для работы с redis lua redis lib и скопируем ее в папку библиотек lua командой

Подключим библиотеку lua redis в конфигурацию nginx

Все. Теперь можно писать скрипы на lua, которые будут исполнятся nginx

Чтобы быстро и эффективно отдавать кэшированные данные, мы положим самые часто используемые из них в redis сразу при прогреве кэша, а менее используемые будем класть по запросу. Отдавать данные будем с помощью lua на стороне nginx. В этой связке не будет участвовать php, что в разы ускорит выдачу данных и будет занимать намного меньше памяти у сервера.

Для этого напишем Lua скрипт

Подключим этот файл в nginx.conf и перезагрузим nginx

Теперь при запросе /search-by-string?string=smth lua подключится к redis и попробует найти данные по ключу search:smth. Если данных не окажется, то запрос обработает php. Но если данные уже закэшированы и лежат в redis, то они будут сразу же отданы пользователю.

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

В таком случае можно хранить сессию в redis и перед тем, как отдавать контент, проверять роль пользователя по данным сессии.

Т.к. я работаю с фрэймворком Symfony2, то для него был написан небольшой бандл nginx-session-handler, с помощью которого можно хранить сессию в redis именно так, как нам удобно.

В redis данные будут хранится в качестве хэш значения:
phpsession — префикс ключа для сессии
php-session — сама сессия php
user-role — роль пользователя.

Теперь нужно написать lua скрипт для обработки этих данных:

Мы достаем id сессии пользователя из cookie, пытаемся получить роль пользователя по его id сессии из redis по запросу HGET phpsession:id user-role. Если у пользователя истекло время жизни сессии, он не аутенитифицированн или у него не роль ROLE_ADMIN, то сервер вернет код 403.

Дописываем этот скрипт обработки сессии перед нашим скриптом получения данных и теперь данные могут получить только аутентифицированные пользователи с ролью ROLE_ADMIN.

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

Для начала немного перепишем наш скрипт обработки сессии.

Теперь необходимо собрать session.o файл из session.lua с помощью компилятора luaJit и собрать nginx c этим файлом.

Соберем session.o файл, выполнив команду компилятора lua

Добавим в конфигурацию для сборки nginx строку

и соберем nginx(как собрать nginx описано выше)

После этого можно подключать файл в любой lua скрипт и вызывать функцию handle() для обработки сессии пользователя

В конце небольшой тест для сравнения.

Тесты, которые с помощью php или lua достают данные из redis

Concurrency Level: 100
Time taken for tests: 3.869 seconds
Complete requests: 100
Failed requests: 0
Requests per second: 25.85 [#/sec] (mean)
Time per request: 3868.776 [ms] (mean)
Time per request: 38.688 [ms] (mean, across all concurrent requests)
Transfer rate: 6.66 [Kbytes/sec] received

Connection Times (ms)
min mean[±sd] median max
Connect: 1 3 1.1 3 5
Processing: 155 2116 1053.7 2191 3863
Waiting: 155 2116 1053.7 2191 3863
Total: 160 2119 1052.6 2194 3864

Percentage of the requests served within a certain time (ms)
50% 2194
66% 2697
75% 3015
80% 3159
90% 3504
95% 3684
98% 3861
99% 3864
100% 3864 (longest request)

Concurrency Level: 100
Time taken for tests: 0.022 seconds
Complete requests: 100
Failed requests: 0
Requests per second: 4549.59 [#/sec] (mean)
Time per request: 21.980 [ms] (mean)
Time per request: 0.220 [ms] (mean, across all concurrent requests)
Transfer rate: 688.66 [Kbytes/sec] received

Connection Times (ms)
min mean[±sd] median max
Connect: 2 4 0.9 4 6
Processing: 3 13 1.6 13 14
Waiting: 3 13 1.6 13 14
Total: 9 17 1.3 18 18

Percentage of the requests served within a certain time (ms)
50% 18
66% 18
75% 18
80% 18
90% 18
95% 18
98% 18
99% 18
100% 18 (longest request)

Разница «количества запросов в секунду» в 175 раз.

Такой же тест с другими парметрами

Concurrency Level: 100
Time taken for tests: 343.082 seconds
Complete requests: 10000
Failed requests: 0
Requests per second: 29.15 [#/sec] (mean)
Time per request: 3430.821 [ms] (mean)
Time per request: 34.308 [ms] (mean, across all concurrent requests)
Transfer rate: 7.51 [Kbytes/sec] received

Connection Times (ms)
min mean[±sd] median max
Connect: 0 0 0.3 0 4
Processing: 167 3414 197.5 3408 4054
Waiting: 167 3413 197.5 3408 4054
Total: 171 3414 197.3 3408 4055

Percentage of the requests served within a certain time (ms)
50% 3408
66% 3438
75% 3458
80% 3474
90% 3533
95% 3633
98% 3714
99% 3866
100% 4055 (longest request)

Concurrency Level: 100
Time taken for tests: 0.899 seconds
Complete requests: 10000
Failed requests: 0
Requests per second: 11118.29 [#/sec] (mean)
Time per request: 8.994 [ms] (mean)
Time per request: 0.090 [ms] (mean, across all concurrent requests)
Transfer rate: 1682.94 [Kbytes/sec] received

Connection Times (ms)
min mean[±sd] median max
Connect: 0 0 0.4 0 5
Processing: 1 9 3.4 7 19
Waiting: 1 9 3.5 7 18
Total: 2 9 3.4 7 21

Percentage of the requests served within a certain time (ms)
50% 7
66% 13
75% 13
80% 13
90% 13
95% 13
98% 13
99% 15
100% 21 (longest request)

Разница «количества запросов в секунду» в 381 раз.

Читайте также:  Установка акустики kia rio

Надеюсь, моя статья была полезна. Если у вас есть пожелания, замечания или вы, знаете как сделать лучше — пишите.

источник

Использование Lua в Nginx

Openresty, большой набор модулей для Nginx’a, открывает много возможностей для разработки прямо на популярном Web сервере. Одним из главных достоинств этого пакета является расширение для поддержки языка Lua в Nginx.

Установка

В Debian системах все, что нужно, есть в пакете:

Hello world

# Выведем известную строку прямо с помощью Nginx’a

И по адресу http://сайт/hello увидим:

Вывод HTML

Чтобы вывести HTML достаточно заменить тип контента и указать сам контент:

# Выводим HTML из Nginx Lua

Организация кода

Для удобства стоит использовать внешние Lua файлы:

# загрузка Lua кода из внешних файлов

Во время разработки удобно использовать lua_code_cache , т.к. код файла можно будет менять без перезапуска Nginx’a.

Несколько обработчиков

Глобальные переменные

Для настроек и статистики удобно использовать глобальные переменные (они будут иметь одинаковые значения для всех запросов):

# Используем глобальную переменную для подсчета количества запросов

Работа с данными

Nginx поддерживает работу с разными базами данных, в т.ч. Mysql и Redis.

Пример простого скрипта для подсчета количества запросов в Redis’e:

# Увеличиваем счетчик test с помощью Redis

Самое главное

Openresty позволяет использовать Nginx не просто как Web сервер, а как полноценную платформу. С помощью Lua можно реализовать большой набор функционала, в т.ч. и работу с данными.

Основы оптимизации работы Web сервера

Настройка Nginx для отдачи статических файлов

Использование Nginx, как кэширующего сервера

Кэширование динамических страниц с помощью SSI

Распространенные ошибки конфигурации Nginx, подводные камни и лучшие практики

Как настроить Nginx на максимальную эффективность

Как собирать статистику Nginx при помощи встроенного модуля и Zabbix

Методы улучшения производительности TLS/SSL

Правильное использование ngx.req.get_body_data() для чтения тела запроса

Примеры применения Javascript в Nginx’e

Кэширование динамических сайтов с помощью ESI

Как использовать Varnish для кэширования HTTP запросов

Настраиваем Apache на максимальную производительность

4 шага и 9 инструментов для анализа нагрузки на сервер

Как настроить веб-сервер Nginx для работы с Magento

Эффективный механизм записи данных из Nginx’a прямо в Clickhouse минуя промежуточные узлы

Главные возможности нового протокола HTTP/2

Где находится nginx.conf и пример настроек

Работа приложения с несколькими бэкендами при помощи Nginx

Причины возникновения ошибки Ошибка 502 bad gateway в Nginx и методы исправления

Причины и методы исправления ошибки Gateway Timeout, Nginx

Ошибка 400 Bad Request возникает, когда клиент отправляет на Nginx неверный запрос. Это случается когда размер заголовков запроса больше допустимого предела.

Как пофиксить ошибку «110: connection timed out» while reading response header from upstream

источник

Nginx на стероидах — расширяем функционал с помощью LUA

Для обеспечения работы всех наших внешних продуктов мы используем популярный nginx. Это быстро и это надежно. Проблем с ним почти нет. Наши продукты также постоянно развиваются, появляются новые сервисы, добавляется новый функционал, расширяется старый. Аудитория и нагрузка только растет. Сейчас мы хотим рассказать о том, как мы ускорили разработку, неплохо увеличили производительность и упростили добавление в наши сервисы этого нового функционала, при этом сохранив доступность и отказоустойчивость затронутых приложений. Речь пойдет о концепции “nginx as web application”.
А именно, о сторонних модулях (в основном LUA), позволяющих делать совершенно магические вещи быстро и надежно.

Проблемы и решение

Основная задумка довольно простая. Возьмем следующие факторы:
— сложность логики приложения,
— количество компонентов приложения,
— размер аудитории.
С определенного момента становится довольно сложно поддерживать приложение отзывчивым и быстрым, иногда даже и работоспособным. Продукт становится многокомпонентным, географически распределенным. И им пользуются все больше людей. При этом существуют требования бизнеса по отзывчивости и отказоустойчивости, которые надо в первую очередь соблюдать.
Путей решения этой проблемы несколько. Можно все вообще сломать и переделать на другие технологии. Безусловно, этот вариант работает, но нам он не очень понравился и мы решили переделывать постепенно. За основу была взята сборка openresty (nginx+LUA). Почему LUA. Без помощи cgi, fastcgi и других cgi прямо в конфигурационном файле nginx можно заскриптовать мощный, красивый и быстрый функционал. Все работает асинхронно. Причем не только с клиентами, но и с бекендами. При этом не вмешиваясь в event loop вебсервера, без callbacks, полностью используя имеющийся функционал nginx.

На данный момент доступны следующие бекенды:
— Redis
— Memcache
— MySQL
— PostgreSQL
В дополнении можно подключить еще модули для использования, например RabbitMQ и ZeroMQ.
Это работает довольно быстро. Во всяком случае быстрее, чем php-fpm ))

Логичный вопрос, а почему бы все вообще не переписать на C? Писать на LUA сильно проще и быстрее. И мы сразу избавлены от проблем, связанных с асинхронностью и nginx event loop.

Примеры. Идеи

Мы, как обычно, не будем приводить полный код, только основные части. Эти все штуки раньше были сделаны на php.

1. Эту часть придумал и сделал наш коллега AotD. Есть хранилище картинок. Их надо показывать пользователям, причем желательно производить при этом некоторые операции, например, resize. Картинки мы храним в ceph, это аналог Amazon S3. Для обработки картинок используется ImageMagick. На ресайзере есть каталог с кэшем, туда складываются обработанные картинки.
Парсим запрос пользователя, определяем картинку, нужное ему разрешение и идем в ceph, затем на лету обрабатываем и показываем.
serve_image.lua

Подключаем биндинг imagic.lua. Должен быть доступен LuaJIT.

2. Firewall для API. Валидация запроса, идентификация клиента, контроль rps и шлагбаум для тех, кто нам не нужен.
Firewall.lua

3. Дополнительные сервисы, например межкомпонентное взаимодействие по протоколу AMQP. Пример здесь.

4. Как я уже писал. Модуль самодиагностики приложения с возможностью “умного” управления маршрутами прохождения запроса через бекенды. Еще в разработке.

5. Адаптеры для интерфейсов API. В некоторых случаях необходимо подправить, дополнить или расширить имеющиеся методы. Чтобы все не переписывать, LUA поможет. Например, json xml conversion на лету.

Бенчмарков как таковых не будет. Продукты слишком сложны и рпс после бенча сильно зависит от многих факторов. Однако, для наших продуктов, мы добились 20-кратного увеличения производительности для затронутого функционала, а в некоторых случаях все стало быстрее до

Читайте также:  Установка pid в кофеварку
Плюсы и минусы

Ощутимые плюсы. Все, что раньше было 5 мегабайтами кода на php, превращается в 100кб файл на lua.
— скорость разработки,
— скорость работы приложения,
— надежность,
— асинхронная работа с клиентами и бекендами, не ломающая при этом event loop nginx,
— LUA sugar feel good! Корутины, shared dictionary для всех форков nginx, сабреквесты, куча биндингов.

Неощутимые минусы.
— делать надо все аккуратно и помнить про асинхронность и event loop nginx.
— фронтенд работает настолько быстро, что это может не понравиться бекенду. Между ними прямая связь, без прослоек. Я, например, уверен, что 10000 запросов в секунду LUA на фронтенде прожует легко. Но, если при этом оно захочет пойти в базу, тут могут возникнуть проблемы.
— довольно непросто отладить, если что-то пойдет не так.

Кстати, пока пишется эта статья, прямо в этот момент наш программист рассказывает про все это в подробностях на highload.

С удовольствием ответим на вопросы в комментариях.

Напоследок, здесь можно найти небольшую подборку информации по теме.

источник

Nginx + Lua, гибкая балансировка нагрузки с сохранением сессии

При балансировке нагрузки важный вопрос — сохранение сессии клиента. Особенно, если за балансировщиком стоит какой-то интерактивный backend. И тем более, если захотелось сделать A/B тестирование и гибко регулировать порции клиентов к различному содержанию. «Nginx plus» предлагает такие возможности, но что делать, если хочется дёшево и быстро?

На помощь приходит возможность расширить функционал Nginx с помощью Lua.

Алгоритм прост. При первом запросе клиента, выставляем ему cookie, а при последующих в зависимости от значения, отправляем к конкретному бэкенду. Сами же куки распределяем подходящим алгоритмом с анализом нужных параметров.

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

Необходимые компоненты сборки:

Устанавливаем пакеты для сборки deb-пакета:

Последняя команда скачивает исходные коды nginx-а, из настроенного репозитория. Мы используем nginx: пакеты для Linux.

Скачиваем и распаковываем текущие версии исходных кодов модулей: ngx_devel_kit и lua-nginx-module

Первый модуль необходим для сборки желанного второго.

Правим файл правил сборки deb-пакета по адресу nginx-1.10.3/debian/rules , добавив в список параметров секции config.status.nginx: config.env.nginx :

Собираем и устанавливаем получившийся пакет:

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

Кроме этого, нам потребуется ещё две lua-библиотеки из проекта OpenResty, предоставляющих Nginx API for Lua: lua-resty-core и lua-resty-lrucache. Они из себя представляют набор *.lua файлов, устанавливаемых (по умолчанию) по пути /usr/local/lib/lua/ .

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

В нашем случае требовалось реализовать только варианты контента, потому и балансировщик и бэкенд будут на одном сервере и upstream будет указывать на локальные адреса с портами 800x.
Но гибкость реализации позволяют построить любые желаемые конфигурации. Итак по порядку.

В блоке http <> инициализируем lua.

в блоках *_lua_block уже идёт lua-код со своим синтаксисом и функциями.

Основной сервер, который принимает на себя внешние запросы.

Блок upstream, который используя lua заменяет встроенную логику nginx.

Ну и простой демонстрационный бэкенд, на который в итоге придут клиенты.

При запуске nginx-a с этой конфигурацией в логи свалится предупреждение:

Которое можно убрать собрав и установив требуемую версию. Но и на 2.0 (libluajit-5.1-2) работает.
Теперь, используя браузер с инструментами разработчика, можем проверять работу сервера и выставляемые куки.

Таким образом мы получили необходимую для тестирования и статистики гибкость. И необходимое для правильной работы бэкенда сохранение сессии клиента. Ну и просто интересный опыт.

PS Подобные задачи можно решить и другими методами, например используя haproxy, который позволяет балансировать с учётом сессий. Или для разделения клиентов использовать ngx_http_split_clients_module и с помощью map сопоставлять одни значения в зависимости от других.
Но приведённый вариант распределения клиентов и выбора бэкенда позволяет гибче настраивать систему. И при необходимости, добавлять разнообразную логику в работу. При этом не перестраивая текущую систему.

источник

Lapis: сайт на Lua в конфигах Nginx

Tl;dr Lapis(Lua) = RoR(Ruby) = Django(Python)

Вступление


Lua — мощный и быстрый скриптовый язык, который очень легко встраивается в C. Разработан в PUC-Rio (Бразилия).


LuaJIT — это самая быстрая реализация Lua (JIT-компилятор), настоящее произведение искусства. По некоторым оценкам, имеет шестикратное преимущество перед стандартным интерпретатором Lua и во многих тестах побивает V8. Разработчик Mike Pall (Германия).

А ещё LuaJIT может привязать функции и структуры C на стороне Lua (без написания привязок на C):


Nginx — один из самых эффективных веб-серверов, разработанный Игорем Сысоевым. Многие крупные сайты используют Nginx. Начиная с версии 0.8 появилась возможность напрямую встраивать язык Lua. Lua исполняется в самом процессе Nginx, а не выносится в отдельный процесс, как это происходит в случае с другими языками. Код на Lua в контексте Nginx выполняется в неблокирующем режиме, включая запросы к БД и внешние HTTP-запросы, порожденные веб-приложением (например, запрос к API другого сайта).


OpenResty — это сборка Nginx с множеством сторонних модулей, в том числе для неблокирующего доступа к популярным БД. Последние версии используют LuaJIT для исполнения Lua. Разработчик Yichun Zhang (США, место работы: CloudFlare, основной разработчик lua-nginx-module).


Sailor MoonScript — это скриптовый язык, который транслируется в Lua. Добавляет синтаксический сахар, упрощает написание некоторых вещей, например списковых выражений; реализует классы с наследованием. Можно сказать, что MoonScript для Lua — это CoffeeScript для JavaScript. Разработчик Leaf Corcoran (США).


Lapis — это веб-фрейморк для написания веб-приложений на Lua и MoonScript, который живёт внутри OpenResty. Разработчик Leaf Corcoran (США).

Какое же преимущество дает Lua в Nginx?

Tl;dr Все возможности языка высокого уровня и эффективное использование ресурсов при больших нагрузках

Для ответа вернёмся в далёкое прошлое, когда все сайты обслуживались веб-сервером Apache.

Задержки вносят красные узлы и ребра графа. Желтым закрашены компоненты, расположенные на одной машине.

Аpache выделял отдельный поток операционной системы, который читал запрос, выполнял обработку и отправлял результат пользователю. (Современный Apache можно научить так не делать.) Получается, сколько активных запросов, столько и потоков ОС, а они стоят дорого. Бóльшая часть времени жизни потока при такой схеме расходуется не на обработку запроса, а на передачу данных по сети, лимитированную скоростью интернета у пользователя.

Читайте также:  Установки для фототерапии новорожденного


Как с этим бороться? Надо поручить операционной системе следить за передачей данных, чтобы нашему веб-серверу работать только тогда, когда сеть выполнила очередную задачу. Такой подход называется неблокирующим вводом-выводом и реализуется в большинстве современных ОС. Веб-сервер Nginx использует эту возможность, за счёт чего может обслуживать десятки тысяч одновременных запросов, используя всего один поток ОС.


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

Обычное решение: уже в самом веб-приложении наплодить потоков, от которых мы так успешно избавились в веб-сервере. Эффективное решение: сделать так, чтобы веб-приложение и база данных общались неблокирующим способом. Веб-приложение направляет запрос в базу данных и сразу же переходит к следующему запросу от пользователя. База данных считает, возвращает результат, а веб-приложение, когда освободится, возвращается к обработке запроса от пользователя, породившего данный запрос к базе данных. Такой подход используется, например, в node.js:

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

Замечательно! Теперь посмотрим, как происходит программирование внешних HTTP-запросов в node.js:

Допустим, мы хотим скачать файл по URL и что-то с ним сделать. Результат приходится обрабатывать в лямбда-функции. Неудобно? Это неизбежная плата за асинхронность? К счастью, это не так; посмотрим аналогичный код в Lapis:

Код для Lapis писать удобно, как будто он синхронный, но за кулисами он исполняется полностью асинхронно. Это возможно благодаря активному использованию сопрограмм (coroutines, green threads, а в терминологии Lua просто threads). Весь код, обрабатывающий запрос от пользователя, исполняется в отдельной сопрограмме, а сопрограммы могут останавливаться и продолжаться в определенных местах. В нашем примере такое место было внутри вызова функции http.simple.

Почему же сопрограммы эффективнее потоков ОС? Не перетащили ли мы все накладные расходы в приложение? На самом деле, ключевым отличием сопрограмм от потоков ОС является свобода программиста, в каком именно месте сопрограмма засыпает и просыпается. (В случае потоков ОС решение принимает ОС.) Начали запрос к БД — усыпили сопрограмму, породившую запрос. Пришёл ответ от БД — будим сопрограмму и продолжаем её исполнение. Выполняем одновременно много дел и всё в одном потоке ОС!

Примечание. Похожий механизм вот-вот появится в node.js.

Примечание. Советую прочитать замечательную статью про сопрограммы в контексте C++. В конце статьи получился асинхронный код, записываемый как синхронный, и всё благодаря сопрограммам. Жалко, что в C++ сопрограммы являются скорее хаком, чем общепринятым приёмом.

Помимо этого, Lapis исполняется непосредственно в Nginx, что исключает накладные расходы на передачу информации между Nginx и веб-приложением. Конечно, node.js можно использовать как основной веб-сервер, без Nginx, но тогда пропадает возможность использовать разные возможности Nginx.

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

Эффективность Lapis подтверждается в 10-гигабитном бенчмарке. Lapis занимает лидирующие места на уровне языков C++ и Java.

Lapis

1 апреля 2014 года на Хабре была опубликована первоапрельская статья «LUA в nginx: лапшакод в стиле inline php». В статье рассматривался шуточный код, реализующий PHP-подобные шаблоны на Lua. В комментариях к той же статье упомянули о Lapis. Других упоминаний о Lapis на Хабре я не нашел, поэтому решил написать сам.

Писать Hello World скучно. Давайте вместо этого напишем простенький веб-прокси на Lapis.

Установка OpenResty

Установите perl 5.6.1+, libreadline, libpcre и libssl и убедитесь, что доступна команда ldconfig (её родительская папка может отсутствовать в PATH).

Установка Lapis

Сначала надо установить LuaRocks (есть в основных дистрибутивах).

Создаем веб-приложение

Если бы мы не передали опцию —lua, то был бы создан костяк на языке MoonScript.

Теперь реализуем в app.lua логику нашего приложения: на главной странице сайта отображается форма для ввода URL. Форма отправляется на /geturl, где происходит загрузка страницы по указанному URL и передача содержимого в браузер пользователя.

Главная страница просто выдает HTML-код с формой. Двойные квадратные скобки — ещё одно обозначения для строк в Lua. Страница /geturl получает POST-запрос от формы, достает из него URL, вписанный пользователем в форму, скачивает содержимое по этому URL при помощи функции http.simple (поток ОС при этом не блокируется, см. выше) и показывает результат пользователю.

Для работы http.simple нужно изменить nginx.conf:

Этот код создает в Nginx location /proxy, через который Lua совершает внешние запросы. В главный location нужно добавить set $_url «»; Подробнее об этом написано в документации.

Нажимаем на кнопку «Get». Сайт ip4.me показывает IP-адрес сервера, на котором запущен Lapis.

Если в URL отсутствует path, то в качестве path используется /proxy. Видимо, это баг Lapis’а, по которому уже составлен отчёт.

Заключение

В Lapis, Lua и Nginx есть ещё много интересного, например, асинхронная работа с БД Postgres, классы-обертки для объектов БД, генерация HTML, мощный язык шаблонов etlua, кеширование переменных между разными процессами-рабочими Nginx, защита от CSRF, два инструмента для тестирования и интерактивная Lua-консоль прямо в браузере. Если статья найдёт читателя, я продолжу рассказ о Lapis в других статьях.

Без сомнения, Lapis давно перерос уровень первоапрельской шутки и стремительно набирает позиции в сообществе веб-разработчиков. Желаю приятного изучения этих перспективных технологий!

источник

Добавить комментарий

Adblock
detector