Перенос/создание редиректов для nginx при помощи lua и redis

Posted in Новости on июня 19, 2018 by admin

В процессе работы появилась задача организовать порядка 1500 редиректов для сайта. Конечно, можно просто сгенерировать локейшены и подцепить их инклудом, но подобное решение во-первых является не совсем красивым, а во-вторых довольно медленным, ведь nginx придется проходить для каждого запроса все локейшены. Выбор упал на lua + redis , так как redis является inmemory СУБД ( хоть и nosql ) и довольно быстра.
Итак, мы собрали nginx с модулем lua и готовы творить.
У меня получился вот такой конфиг :

server {
listen 80;
location / {
access_by_lua '
local redis = require "resty.redis"
local red = redis:new()
red:set_timeout(1000)
local ok, err = red:connect("127.0.0.1", 6379)
local key = ngx.var.request_uri
local res, err = red:get(key)
if res ~= ngx.null then
ngx.redirect(res, 301)
end
';
rewrite ^(.*)$ /index.html break;
}
location /value1 { return 505; }
}

Долго мучался с access_by_lua , так как глубоких знаний lua у меня пока нет, а во всех источниках люди пишут content_by_lua. В итоге, прошерстив документацию, я пришел к выводу, что content_by_lua можно использовать только тогда, когда в этом же локейшене нет других рерайтов, proxy_pass и прочего от nginx . В текущем конфиге с content_by_lua я получал безусловный рерайт на /index.html не учитывая мою логику lua. А access_by_lua учитывает подобное поведение, что мне на руку. Дополнительный локейшен /value1 использую для теста конфига. Если в redis есть ключ со значением /value1 , то мы получим редирект и 505 код, если же ключа не существует, то нам просто отдастся стандартная страница openresty ( я использовал docker образ openresty/openresty:alpine для тестирования ).

Итак,

стартуем образ nginx :

docker run --net host -d -v /srv/docker/nginx/:/etc/nginx/conf.d openresty/openresty:alpine

далее стартуем наш редис :

docker run --net host -d redis

вносим в redis наши данные :

redis-cli set /v1234 /value1

Проверяем :
http://localhost/v123 — ( нет такого ключа в редисе ) — получаем индексную страницу
http://localhost/v1234 — ( есть такой ключ со значением /value1 ) — получаем 301 редирект и 505 код. Ура.

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

Tags: , , , ,

moodle slasharguments nginx php-fpm

Posted in Новости on января 31, 2016 by admin

Если moodle установлен в корень сайта ( DOCROOT ) и доступен как, http://site.com/ , то для активации slash arguments нужно в nginx в конфиге сайта в блоке server прописать :

rewrite ^/(.*\.php)(/)(.*)$ /$1?file=/$3 last;

Tags: , ,

nginx и бесплатные сертификаты от let's encrypt

Posted in Новости on января 29, 2016 by admin

1. Ставим само ПО letsencrypt :

cd /usr/src
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto

В процессе установки попросят ввести ящик. Он потребуется для продления сертификата или при утере данных
2. Генерируем сертификаты для работы :

cd /usr/src
service nginx stop
./letsencrypt-auto certonly --standalone
service nginx start

В процессе генерации ключей нас попросят ввести список доменов, если нам нужно разместить более одного домена второго уровня, тогда нужно будет запустить еще раз утилиту, так как для всего списка создается один сертификат. Перед генерацией сертификата нужно останавливать вебсервер.
3. Создаем минимальный конфиг nginx для ssl :

server {
listen my.ip.ad.dre.ss:443 ssl;
server_name example.com www.example.com;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
set $root /var/www/example.com/;
ssl on;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
root $root;
}
}

сертификат fullchain.pem уже включает и сертификат домена и цепочку сертификатов.

Tags: , , , ,

nginx watermark , наложение водных знаков в nginx

Posted in Новости on января 29, 2016 by admin

1. Обновляем систему до упора.

apt-get update
apt-get upgrade
apt-get install dpkg-dev

2. Качаем исходники nginx

cd /usr/src
apt-get source nginx

3. Качаем модуль imagefilter для nginx

wget https://github.com/intaro/nginx-image-filter-watermark/archive/master.zip
unzip master.zip
cp nginx-image-filter-watermark-master/ngx_http_image_filter_module.c nginx-*/src/http/modules/ngx_http_image_filter_module.c

4. Включаем в сборку флаг :

--with-http_image_filter_module

5. Собираем пакет, не забывая сделать вместо «make install» — «checkinstall»
6. Включаем в нужный блок :

location /img/ {
image_filter watermark;
image_filter_watermark "PATH_TO_FILE";
image_filter_watermark_position center-center; or other position
}

Tags: , ,

Начальная оптимизация php5-fpm

Posted in Новости on января 29, 2016 by admin

Итак, имеем сервер 4 ядра , 8Gb RAM . На сервере стоит MySQL , php5-fpm, nginx.
Сначала рассчитываем, сколько мы можем выделить памяти для php5-fpm . Возьмем половину реальной — 4Gb.
Далее, узнаем, сколько памяти в среднем «ест» один процесс php5-fpm , в этом нам поможет конвеер отсюда
root@XXX:/# pidof php5-fpm | xargs pmap -d | grep '^mapped' | awk '{print $4}' | sed 's/K//' | perl -e 'do { $a+=$_; $b++ } for <>;print $a/1024, " mb\n", $a/1024/$b, " mb\n"'
197.484375 mb
24.685546875 mb

Округлим до 30Мб
Вводные : 4 ядра , 4Гб RAM , ~30Мб на процесс.

pm.max_children = Количество памяти под fpm / Память одного процесса
pm.min_spare_servers = Количество ядер * 2
pm.max_spare_servers = Количество ядер * 4
pm.start_servers = ( pm.min_spare_servers + pm.max_spare_servers) / 2

Итого :

pm.max_children = 136
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.start_servers = 12

Tags: , , , ,