Блог Ваганова Николая

В процессе работы появилась задача организовать порядка 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 код. Ура.

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

https://cuckoosandbox.org/ — удобная и юзабельная штука.

1. Делаем снепшот keyspace

nodetool snapshot

Создастся снапшот по адресу /var/lib/cassandra/data/$keyspace/$table/snapshots/
2. Делаем бекап схемы :

cqlsh -e "DESC KEYSPACE keyspace" > keyspace.cql # где keyspace нужный нам keyspace

3. Бекапим эти данные
4. На новом сервере импортируем схему :

cqlsh -e "source 'keyspace.sql'"

5. Помещаем данные из снапшота в таблицы обычным копированием
6. Перезагружаем кассандру

CORS плагин kong реализует механизм доступа сторонних сайтов к ресурсам kong

1. Активация CORS для API :

curl -X POST http://localhost:8001/apis/myapi/plugins \
--data "name=cors" \
--data "config.origin=tresnet.ru" \
--data "config.methods=GET, POST" \
--data "config.headers=Accept, Accept-Version, Content-Length, Content-MD5, Content-Type, Date, X-Auth-Token" \
--data "config.exposed_headers=X-Auth-Token" \
--data "config.credentials=true" \
--data "config.max_age=3600"


где :
config.origin — домен доступа ( В последних версиях опция была изменена на config.origins для задания списка доменов через запятую ( comma separated ) ( Access-Control-Allow-Origin )
config.methods — список методов доступа ( Access-Control-Allow-Methods )
config.headers — список заголовков запроса ( Access-Control-Allow-Headers )
config.exposed_headers — список ожидаемых заголовков запроса ( Access-Control-Expose-Headers )
config.credentials — заголовок Access-Control-Allow-Credentials ( должен быть выставлен в true )
config.max_age — TTL кеширования запроса в секундах

ACL — это плагин разграничения доступа пользователей к API. Ему необходим для работы один из плагинов авторизации ( BASIC или KEY например ).

1. Создаем ACL для нашего API к которому будут иметь доступ две группы

curl -X POST http://localhost:8001/apis/myapi/plugins --data "name=acl" --data "config.whitelist=group1, group2"


2. Добавляем пользователя ( consumer ) в группу

curl -X POST http://localhost:8001/consumers/user1/acls --data "group=group1"


3. Используем авторизацию как обычно