С помощью существующего протокола единого входа OpenID Connect 7 страница
4.3. Обход кеширования
Задача
Вам нужна возможность обойти кеширование.
Решение
|
proxy_cache_bypass $http_cache_bypass;
Эта конфигурация дает NGINX указание обойти кеширование, если для заголовка HTTP-запроса cache_bypass установлено любое значение, отличное от 0.
Обсуждение
Существует ряд сценариев, которые требуют, чтобы запрос не кеши- ровался. Для этого NGINX предоставляет директиву proxy_cache_bypass, поэтому, когда значение является непустым или ненулевым, запрос будет отправлен на вышестоящий сервер, а не извлечен из кеша. Раз- личные потребности и сценарии обхода кеша будут зависеть от вари- анта использования ваших приложений. Методы обхода кеша могут быть такими же простыми, как использование заголовка запроса или ответа, или такими сложными, как совместная работа нескольких бло- ков map. По многим причинам у вас может возникнуть желание обойти кеширование. Одна из важных причин состоит в устранении неполадок и отладке. Проблемы с воспроизведением могут быть трудными, если
54 v Глава 4. Массивно масштабируемое кеширование контента
|
|
|
|
proxy_cache off;.
4.4. Производительность кеширования
Задача
Вам необходимо повысить производительность путем кеширования на стороне клиента.
Решение
Используйте заголовки управления кешированием на стороне кли- ента:
|
add_header Cache-Control "public";
}
Этот блок location указывает, что клиент может кешировать содержи- мое файлов CSS и JavaScript. Директива expires указывает клиенту, что его кешированный ресурс будет недействительным через год. Директи- ва add_header добавляет к ответу HTTP-заголовок ответа Cache-Control со значением public, что позволяет любому серверу кеширования по пути кешировать ресурс. Если мы указываем значение private, кешировать значение разрешено только клиенту.
Обсуждение
Производительность кеширования зависит от многих факторов, в первую очередь, от скорости диска. В конфигурации NGINX есть мно- го вещей, которые можно сделать для повышения производительно- сти кеширования. Один из вариантов – установить заголовки ответа таким образом, чтобы клиент фактически кешировал ответ и вообще не выполнял запрос к NGINX, просто обслуживая его из собственного кеша.
|
|
|
4.5. 
Продувка v 55
4.5. Продувка
|
Вам необходимо отменить действие кеширования для какого-то объ- екта.
Решение
Используйте функцию продувки NGINX Plus, директиву proxy_cache_ purge и непустую переменную или переменную с нулевым значением:
map $request_method $purge_method { PURGE 1;
default 0;
}
server {
...
location / {
...
proxy_cache_purge $purge_method;
|
}
В этом примере кеш конкретного объекта будет очищен, если он бу- дет запрошен методом PURGE. Ниже приведен пример очистки кеша фай- ла main.js с помощью команды curl:
$ curl -XPURGE localhost/main.js
Обсуждение
Обычный способ обработки статических файлов – поместить хеш файла в имя файла. Это гарантирует, что при развертывании нового кода и содержимого ваша сетьдоставки содержимого распознает его как новый файл, поскольку URI изменился. Однако это не совсем подходит для динамического контента, для которого вы установили ключи кеша, не соответствующие этой модели. Для каждого сценария кеширования у вас должен быть способ очистки кеша. NGINX Plus предоставил про- стой метод очистки кешированных ответов. Директива proxy_cache_purge при передаче ненулевого или непустого значения будет очищать кеши- рованные элементы, соответствующие запросу. Простой способ настро- ить очистку – отобразить метод запроса для PURGE. Однако вы можете
|
|
|
|
использовать это в сочетании с модулем geo_ip или простой аутентифи- кацией, чтобы никто не мог очистить важные элементы кеша. NGINX также позволяет использовать знак *, благодаря чему можно очищать элементы кеша, которые соответствуют общему префиксу URI. Чтобы использовать подстановочные знаки, вам понадобится настроить ди- рективу proxy_cache_path с аргументом purger=on.
Директива slice
Задача
Вам необходимо повысить эффективность кеширования, сегменти- руя файл на фрагменты.
Решение
Используйте директиву slice и ее встраиваемые переменные, чтобы разделить результат кеширования на фрагменты:
proxy_cache_path /tmp/mycache keys_zone=mycache:10m; server {
|
proxy_cache mycache; slice 1m;
proxy_cache_key $host$uri$is_args$args$slice_range; proxy_set_header Range $slice_range; proxy_http_version 1.1;
proxy_cache_valid 200 206 1h;
location / {
proxy_pass http://origin:80;
}
}
Обсуждение
|
|
|
Данная конфигурация определяет зону кеширования и активирует ее для сервера. Затем используется директива slice, чтобы указать NGINX разделить ответ на файловые сегменты размером 1 Мб. Файлы кеша хра- нятся в соответствии с директивой proxy_cache_key. Обратите внимание на использование встраиваемой переменной с именем slice_range. Эта же переменная используется в качестве заголовка при отправке запро-
4.6. Директива slice v 57
|
|
См. также:
https://www.nginx.com/blog/smart-efficient-byte-range-caching-nginx/
Глава 5
 |
| |
Программируемость и автоматизация
5.0. Введение
|
сервер NGINX, используя разные платформы.
5.1. API NGINX Plus v 59
5.1. API NGINX Plus
|
У вас есть динамичная среда, и вам нужно перенастроить NGINX Plus
на лету.
Решение
Сконфигурируйте API NGINX Plus, чтобы разрешить добавление и удаление серверов через API-вызовы:
upstream backend {
zone http_backend 64k;
}
server {
# ...
|
api [write=on];
# Директивы, ограничивающие доступ к API # См. главу 7
}
location = /dashboard.html { root /usr/share/nginx/html;
}
}
В этой конфигурация NGINX Plus создается вышестоящий сервер с зоной общей памяти, активируется API в блоке location /api и предо- ставляется местоположение для панели инструментов NGINX Plus.
Можно использовать API для добавления серверов, когда они под- ключаются к сети:
$ curl -X POST -d '{"server":"172.17.0.3"}' \ 'http://nginx.local/api/3/http/upstreams/backend/servers/'
{
"id":0, "server":"172.17.0.3:80",
"weight":1, "max_conns":0, "max_fails":1,
60 v Глава 5. Программируемость и автоматизация
"fail_timeout":"10s", "slow_start":"0s",
|
}
Используя команду curl в этом примере, мы делаем запрос к NGINX Plus, чтобы добавить новый сервер в конфигурацию backend-upstream. HTTP-метод – это POST, а объект JSON передается в качестве тела. API NGINX Plus – это RESTful; следовательно, в URI запроса есть параметры. Формат URI выглядит так:
|
Можно использовать API NGINX Plus для перечисления серверов в восходящем пуле:
$ curl 'http://nginx.local/api/3/http/upstreams/backend/servers/' [
{
"id":0, "server":"172.17.0.3:80",
"weight":1, "max_conns":0, "max_fails":1, "fail_timeout":"10s", "slow_start":"0s",
"route":"", "backup":false, "down":false
}
]
Используя команду curl в этом примере, мы отправляем запрос в NGINX Plus, чтобы вывести список всех серверов в восходящем пуле с именем backend. В настоящее время у нас есть только один сервер, ко- торый мы добавили в предыдущем вызове. Запрос вернет объект вы- шестоящего сервера, который содержит все настраиваемые параметры для сервера.
Используйте API NGINX Plus для осушения подключений от вышесто-
ящего сервера и подготовки его к постепенному удалению из восходя-
5.1. API NGINX Plus v 61
щего пула. Подробную информацию об осушении подключения можно найти в рецепте 2.8:
|
{
"id":0, "server":"172.17.0.3:80",
|
"route":"", "backup":false, "down":false, "drain":true
}
Здесь мы указываем, что методом запроса является PATCH, передаем тело JSON, предписывая ему выполнить осушение подключения для сервера, и указываем идентификатор сервера, добавляя его в URI. Мы нашли идентификатор сервера, перечислив серверы в восходящем пуле с помощью предыдущей команды curl.
NGINX Plus начнет осушение подключений. Этот процесс может за- нять столько же времени, сколько и сеансы приложения. Чтобы прове- рить, сколько активных соединений обслуживает сервер, который вы начали применять, используйте приведенный ниже вызов и найдите атрибут active подлежащего осушению сервера:
$ curl 'http://nginx.local/api/3/http/upstreams/backend'
{
"zone" : "http_backend", "keepalive" : 0,
"peers" : [
{
"backup" : false, "id" : 0,
"unavail" : 0,
"name" : "172.17.0.3",
62 v Глава 5. Программируемость и автоматизация
"requests" : 0, 
"received" : 0,
"state" : "draining", "server" : "172.17.0.3:80",
"active" : 0,
"weight" : 1,
"fails" : 0,
"sent" : 0,
"responses" : {
"4xx" : 0,
"total" : 0,
"3xx" : 0,
"5xx" : 0,
"2xx" : 0,
"1xx" : 0
},
"health_checks" : { "checks" : 0,
"unhealthy" : 0,
"fails" : 0
},
|
}
],
"zombies" : 0
Дата добавления: 2021-01-21; просмотров: 120; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!