журнал работы
Функция ngx.log(log level, ...) записывает рабочий журнал OpenResty. Ее использование очень похоже на
функцию печати из стандартной библиотеки Lua. Она может принимать любое количество параметров и записывать любую информацию.
Первый параметр ngx.log — это уровень лога, в лог реально будут записываться только сообщения с уровнем выше «журнала ошибок» в конфигурационном файле (обычно это уровень ошибок), а значение — от высокого к низкому. да:
- ngx .STDERR записывает данные непосредственно в стандартный вывод, самый высокий уровень ведения журнала.
- ngx.EMERG Произошла чрезвычайная ситуация,
- ngx .ALERT Произошла серьезная ошибка, и может потребоваться предупредить систему эксплуатации и обслуживания:
- ngx.CRIT . Произошла критическая ошибка;
- ngx .ERR Распространенные ошибки, несчастные случаи в бизнесе;
- ngx .WARN предупреждающая информация, бизнес нормальный, но вы можете проверить источник предупреждения:
- Уведомление ngx.NOTICE — это просто уведомление, и его обычно можно игнорировать:
- общая информация ngx.INFO;
- ngx .DEBUG Отладочная информация, будет включена только отладочная версия.
совпадение местоположения
Директиву местоположения можно настроить на основе запрошенного URI.
Операция сопоставления выполняется над канонизированным URI, включая декодирование текста, закодированного в форме «%XX», разрешение «.» и «...» в компонентах относительного пути и, возможно, сжатие двух или более смежных косых черт для косой черты.
Местоположение может быть определено строкой префикса или регулярным выражением. Перед регулярными выражениями может стоять модификатор «~*» (для соответствия без учета регистра) или модификатор «~» (для соответствия с учетом регистра). Чтобы найти местоположение, соответствующее заданному запросу, Nginx сначала проверяет местоположение, определенное с помощью строки префикса (prefix-location). Среди них выбирается и запоминается место с самым длинным совпадающим префиксом. Затем регулярные выражения проверяются в порядке их появления в файле конфигурации. Поиск регулярного выражения прекращается после нахождения первого совпадения и используется соответствующая конфигурация. Если совпадение с регулярным выражением отсутствует, используется ранее запомненная конфигурация расположения префикса.
Блоки местоположения могут быть вложенными, за некоторыми исключениями.
Для операционных систем, нечувствительных к регистру, таких как macOS и Cygwin, при сопоставлении со строками префикса регистр игнорируется (0.7.7). Однако сравнения ограничены однобайтовыми локализациями.
Регулярные выражения могут содержать группы захвата (0.7.40), которые можно использовать в других директивах.
Регулярные выражения не проверяются, если место с самым длинным совпадающим префиксом использует модификатор "^~".
Кроме того, точное соответствие URI и местоположения можно определить с помощью модификатора "=". Если найдено точное совпадение, поиск прекращается. Например, если запросы "/" происходят часто, определение "location=/" ускорит обработку этих запросов, так как поиск прекратится после первого сравнения. Такое местоположение, очевидно, не может содержать вложенных местоположений.
Пример:
location ~ " / (\w+) {
content_by_lua_file service/http/$1.lua;
}
Это директива конфигурации местоположения Nginx, где символ ~ означает использование регулярных выражений для сопоставления. Он будет соответствовать строке, начинающейся с косой черты «/», за которой следует одна или несколько букв, цифр или знаков подчеркивания.
Смысл разбора директивы конфигурации следующий:
- Эта конфигурация местоположения вступит в силу, когда запрошенный путь URL-адреса удовлетворяет регулярному выражению "/ (\w+)", которое начинается с косой черты "/", за которой следует одна или несколько букв, цифр и знаков подчеркивания.
- При успешном совпадении Nginx выполнит следующие инструкции: content_by_lua_file service/http/$1.lua;
- Здесь для обработки содержимого запроса используется сценарий Lua.Путь к файлу сценария определяется значением соответствующей группы $1 в запросе, то есть совпавшая строка используется в качестве имени файла, и это вставлен в путь «service/http/» с расширением «.lua».
- Это означает, что конфигурация принимает совпадающую строку в пути запроса в качестве имени файла сценария Lua и выполняет сценарий с помощью команды content_by_lua_file для обработки содержимого запроса.
модуль
В Lua модуль — это способ организации кода, который может инкапсулировать связанные функции, переменные и константы в независимое пространство имен для ссылки и использования в другом месте. Оператор local _M = {} создает локальную переменную с именем _M и назначает ей пустую таблицу. Эта таблица будет использоваться для хранения функций, переменных и констант в модуле.
Определение модуля обычно включается в файл Lua и заканчивается оператором возврата, а определенная таблица используется в качестве возвращаемого значения модуля. Например, простой модуль Lua можно определить следующим образом:
-- my_module.lua
local _M = {
}
function _M.foo()
print("This is foo() function")
end
function _M.bar()
print("This is bar() function")
end
return _M
В приведенном выше примере модуль my_module определяет две функции foo() и bar() и помещает их в таблицу _M. Файл модуля заканчивается на return _M, а таблица _M используется как возвращаемое значение модуля, чтобы другие места могли обращаться к этому модулю через функцию require и получать доступ к функциям в нем.
Использование local _M = {} может эффективно инкапсулировать функции, переменные и константы в модуле в локальную область, избегая загрязнения глобальных переменных и конфликтов имен, а также соответствует идее модульного программирования. В реальном программировании на Lua этот метод очень распространен и используется для определения различных типов модулей Lua, включая модуль ngx_http_lua_module , используемый в OpenResty .
Использование rewrite_by_lua_file в nginx
В Nginx директива rewrite_by_lua_file используется для перезаписи URI с помощью Lua-скриптов на этапе обработки запроса. Его использование заключается в следующем:
rewrite_by_lua_file <lua_file_path>;
Где < lua_file_path > — это путь к указанному файлу сценария Lua, который может быть абсолютным или относительным путем.
Когда запрос достигает Nginx и соответствует блоку местоположения, в котором находится директива rewrite_by_lua_file , Nginx выполнит файл сценария Lua по указанному пути. В сценариях Lua объект запроса и объект ответа можно манипулировать через модуль ngx для реализации пользовательской логики перезаписи URI.
Вот простой пример, показывающий, как использовать директиву rewrite_by_lua_file для перезаписи URI:
location /example {
rewrite_by_lua_file /path/to/lua_script.lua;
}
В приведенном выше примере, когда URI запроса совпадает с /example, Nginx выполнит скрипт Lua в /path/to/lua_script.lua, чтобы перезаписать URI.
В скрипте Lua вы можете получить информацию об объекте запроса через объект ngx.req , такую как URI запроса, метод запроса, заголовок запроса и т. д.; установить новый URI
через метод ngx.req.set_uri , чтобы реализовать перезапись URI.
Например:
-- 获取请求 URI
local uri = ngx.req.uri
-- 对请求 URI 进行处理，例如添加前缀
uri = "/new_prefix" .. uri
-- 设置新的 URI
ngx.req.set_uri(uri)
Следует отметить, что Lua-скрипт, указанный в директиве rewrite_by_lua_file , должен быть доступным для чтения и выполнения, а также должен иметь достаточные разрешения для доступа к требуемым файлам или ресурсам. При написании сценариев Lua вы должны следовать синтаксису Lua и спецификациям программирования, а также обрабатывать возможные ошибки.