Когда SSL/TLS прекращается до NGINX
|
Вам требуется выполнять перенаправление в HTTPS, однако у вас ис- тек срок SSL/TLS на уровне перед NGINX.
Решение
Чтобы выяснить, требуется ли вам выполнить перенаправление, вос- пользуйтесь стандартным заголовком X-Forwarded-Proto:
server {
listen 80 default_server;
listen [::]:80 default_server; server_name _;
|
}
}
Данная конфигурация во многом схожа с перенаправлением HTTPS. Тем не менее в данной конфигурации мы выполняем перенаправле- ние, только когда значение заголовка X-Forwarded-Proto эквивалентно HTTP.
Обсуждение
Достаточно распространен случай, когда у вас может завершиться срок действия SSL/TLS на некоем уровне перед NGINX. Одной из при- чин может быть то, что вы делаете нечто подобное сбережению затрат на вычисления. Тем не менее вам требуется быть уверенным, что все запросы являются HTTPS, но при этом сам уровень с прекращенным SSL/TLS не имеет возможности перенаправления. Он способен, однако, устанавливать заголовки посредника. Эта конфигурация работает с та- кими уровнями, как Amazon Web Services Elastic Load Balancer, который выполняет разгрузку SSL/TLS без дополнительных затрат. Это удобный трюк для обеспечения защиты вашего HTTP-трафика.
7.11. Строгая безопасность доставки HTTP
Задача
|
|
|
|
Решение
Воспользуйтесь расширением HSTS (HTTP Strict Transport Security),
устанавливая заголовок Strict-Transport-Security:
add_header Strict-Transport-Security max-age=31536000;
Данная конфигурация устанавливает значение заголовка Strict- Transport-Security на максимальный возраст в один год. Он будет инст- руктировать соответствующий браузер всегда осуществлять некое внут- реннее перенаправление при попытке выполнения к данному домену запросов HTTP, чтобы все запросы выполнялись поверх HTTPS.
Обсуждение
|
См. также:
https://tools . ietf . org/html/rfc6797https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet
7.12. Удовлетворение любого числа методов безопасности
Задача
Вам требуется предоставить множество способов передачи безопас- ности закрытой площадке.
Решение
|
|
|
|
location / {
satisfy any;
allow 192.168.1.0/24; deny all;
|
}
Данная конфигурация сообщает NGINX, что запрашивающий location/ пользователь должен удовлетворять одному из установленных мето- дов безопасности: либо эти запросы должны происходить с блока CIDR 192.168.1.0/24, либо быть способными поддерживать некие имя пользо- вателя и пароль, которые могут быть найдены в обозначенном файле conf/htpasswd. Данная директива satisfy имеет всего два варианта: any или all.
Обсуждение
Описанная директива satisfy является великолепным способом пред- ложения множества способов аутентификации для вашего веб-при- ложения. Определяя any для директивы satisfy, данный пользователь обязан соответствовать одной из предоставленных защит. Определяя в директиве satisfy значение all, запрашивающий пользователь дол- жен соответствовать всем выставленным требованиям безопасности. Данная директива может применяться совместно с http_access_module, описанном в рецепте 7.1, http_auth_basic_module, детализированном в рецепте 6.1, http_auth_request_module, описанном в рецепте 6.2 и пред- ставленном в рецепте 6.3 http_auth_jwt_module. Обсуждаемая директива satisfy поможет вам достичь этого для местоположений и серверов, ко- торые требуют глубоких правил защиты.
|
|
|
|
7.13. Динамичное ослабление DDoS
Задача
Вам необходимо динамичное ослабление DDoS (Distributed Denial of Service).
Решение
Для создания поддерживающего кластер ограничения скорости запросов и автоматического черного списка воспользуйтесь NGINX Plus:
limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync; # Cluster-aware rate limit
limit_req_status 429;
keyval_zone zone=sinbin:1M timeout=600 sync;
# Cluster-aware "sin bin" with # 10-minute TTL
|
# Populate $in_sinbin with
# matched client IP addresses
server {
listen 80; location / {
if ($in_sinbin) {
set $limit_rate 50; # Restrict bandwidth of bad clients
}
limit_req zone=per_ip;
# Apply the rate limit here error_page 429 = @send_to_sinbin;
# Excessive clients are moved to # this location
proxy_pass http://my_backend;
}
location @send_to_sinbin {
rewrite ^ /api/3/http/keyvals/sinbin break;
7.13. Динамичное ослабление DDoS v 101
# Set the URI of the # "sin bin" key-val
proxy_method POST;
proxy_set_body '{"$remote_addr":"1"}'; proxy_pass http://127.0.0.1:80;
}
|
|
|
|
# directives to control access to the API
}
}
Обсуждение
|
|
| |
HTTP/2
8.0. Введение
|
8.1. Базовая настройка
Задача
Вы желаете воспользоваться преимуществами HTTP/2.
Решение
Включите HTTP/2 в своем сервере NGINX:
server {
listen 443 ssl http2 default_server;
ssl_certificate server.crt; ssl_certificate_key server.key;
...
Обсуждение
8.2. gRPC v 103
|
См. также:
|
lnpcgagjijhmgnchggcjblin
https://addons.mozilla.org/en-US/ fi refox/addon/http2-indicator/
8.2. gRPC
Задача
Вам требуется прекратить, проинспектировать, маршрутизировать или осуществить балансировку нагрузки вызовов метода gRPC.
Решение
Для посредничества (прокси) подключений gRPC воспользуйтесь
NGINX.
server {
listen 80 http2;
location / {
grpc_pass grpc://backend.local:50051;
}
104 v Глава 8. HTTP/2
|
Чтобы воспользоваться шифрованием TLS между клиентом и NGINX
и прерывать такое шифрование перед передачей вызова серверу при- ложений, включите SSL и HTTP/2, как вы это делали в первом разделе:
server {
listen 443 ssl http2 default_server;
ssl_certificate server.crt; ssl_certificate_key server.key; location / {
grpc_pass grpc://backend.local:50051;
}
|
Данная конфигурация прекращает TLS в NGINX и передает соответ- ствующее взаимодействие gPRC в имеющееся приложение поверх не- зашифрованного HTTP/2.
Для настройки NGINX на шифрование всего взаимодействия gRPC со своим сервером приложения предоставьте повсеместное шифрование трафика, просто изменив имеющуюся директиву grpc_pass, определив grpcs:// перед уже имеющейся информацией о сервере (обратите вни- мание на добавление символа s, обозначающего безопасное взаимо- действие):
grpc_pass grpcs://backend.local:50051;
Вы также можете применять NGINX для маршрутизации вызовов к различным серверным службам на основе значения URI gRPC, которые включают пакеты, службы и методы. Для этого воспользуйтесь дирек- тивой location.
location /mypackage.service1 {
grpc_pass grpc://backend.local:50051;
}
location /mypackage.service2 {
8.2. gRPC v 105
grpc_pass grpc://backend.local:50052;
}
location / {
root /usr/share/nginx/html; index index.html index.htm;
|
|
Вызовы балансировки нагрузки также похожи на трафик HTTP без
gRPC:
upstream grpcservers {
server backend1.local:50051; server backend2.local:50051;
}
server {
listen 443 ssl http2 default_server;
ssl_certificate server.crt; ssl_certificate_key server.key; location / {
grpc_pass grpc://grpcservers;
}
}
Обсуждение
NGINX обладает возможностью получать, выступать посредником, выполнять балансировку нагрузки, осуществлять маршрутизацию и прекращать шифрование для вызовов gRPC. Имеющийся модуль gRPC позволяет NGINX устанавливать, изменять или сбрасывать заголов- ки вызова gRPC, выставлять тайм-ауты для запросов и устанавливать
106 v Глава 8. HTTP/2
|
8.3. Сервер активной доставки HTTP/2
Задача
Вам требуется активно доставлять своему клиенту содержимое упреж- дающим образом.
Решение
Воспользуйтесь функциональностью NGINX активной доставки HTTP/2.
server {
listen 443 ssl http2 default_server;
|
location = /demo.html { http2_push /style.css; http2_push /image1.jpg;
}
}
Обсуждение
Для применения активной доставки сервера HTTP/2 ваш сервер обя- зан быть настроенным для HTTP/2, как это было нами сделано в ре- цепте 7.1. Здесь вы можете указать NGINX на необходимость упреждаю- щей активной доставки определенных файлов при помощи директивы http2_push. Эта директива получает один параметр, значение полного пути URI того файла, который активно доставляется вашему клиенту.
NGINX также способно автоматически активно доставлять клиентам
ресурсы, если выступает посредником (прокси) в приложениях, содер- жащих некий заголовок отклика HTTP с названием Link. Такой заголо- вок имеет возможность указывать NGINX на упреждающую загрузку предписанных ресурсов. Чтобы включить данную функциональность, добавьте в настройки NGINX http2_push_preload on;.
Глава 9
Управление сложными потоками медиа
9.0. Введение
|
9.1. Обслуживание MP4 и FLV
Задача
Вам требуется отправлять поток цифровых данных, изначально пред- ставленных в формате MPEG-4 (MP4) или Flash Video (FLV).
Решение
Обозначьте блок местоположения HTTP как .mp4 или .flv. NGINX бу- дет управлять потоком медиа, применяя прогрессивные выгрузки или псевдопотоки HTTP с поддержкой поисков:
|
http {
server {
...
location /videos/ { mp4;
}
location ~ \.flv$ { flv;
}
}
}
Блок местоположения данного примера сообщает, что файлы в ката- логе videos представлены в формате с типом MP4 и могут направляться потоком с поддержкой прогрессивной выгрузки. Второй блок местопо- ложения указывает NGINX, что все файлы, завершающиеся на .flv, пред- ставлены в формате FLV и могут направляться потоком с поддержкой псевдопотоков HTTP.
|
Потоковые видео- и аудиофайлы в NGINX являются неким образцом отдельной директивы. Прогрессивная выгрузка делает возможным для клиента инициировать воспроизведение таких медиа до того, как завершится выгрузка всего файла. NGINX поддерживает операции поиска по неким пока не выгруженным порциям этих медиа в обоих форматах.
9.2. Организация потоков с помощью HLS
Задача
Вам требуется поддержка HTTP Live Streaming (HLS) для кодирован- ного H.264/AAC содержимого, упакованного в файлы MP4.
Решение
Воспользуйтесь модулем HLS NGINX Plus с сегментацией в реальном масштабе времени, пакетизацией и мультиплексированием, а также с контролем буферизации фрагментов и др. в качестве аргументов пере- направления HLS:
9.2. Организация потоков с помощью HLS v 109
location /hls/ {
hls; # Use the HLS handler to manage requests
|
# HLS parameters hls_fragment 4s;
hls_buffers 10 10m; hls_mp4_buffer_size 1m; hls_mp4_max_buffer_size 5m;
}
|
Обсуждение
Доступный в NGINX Plus модуль HLS предоставляет свои возможно- сти для мультиплексирования транспортировки файлов с медиа MP4 на лету. Существует множество директив, которые предоставляют вам воз- можностьконтроля над тем, как фрагментируются и буферизуются ваши медиа. Определенный блок местоположения должен быть настроен для обслуживания медиа как некоего потока HLS с соответствующим об- работчиком HLS. Значение фрагментации HLS устанавливается в числе секунд, что указывает NGINX на необходимость фрагментирования по длине времени. Общее число буферируемых данных устанавливается с помощью директивы hls_buffers, определяющей количество буферов и их размер. Данному клиенту разрешается начинать воспроизведение его медиа после осуществления накопления буферизации определен- ного объема, определяемого hls_mp4_buffer_size. Однако может потребо- ваться больший размер буфера, если метаданные для этого видео могут превышать первоначальный размер буфера. Такой объем блокируется сверху значением hls_mp4_max_buffer_size. Эти переменные буферизации позволяют NGINX оптимизировать практику, получаемую конечным пользователем; выбор правильных значений для этих директив требует знания целевой аудитории и ваших медиа. Например, если имеющиеся пачки ваших медиа составляют видеофайлы, а ваша целевая аудитория имеет широкую полосу пропускания, можете выполнить оптимизацию
110 v Глава 9. Управление сложными потоками медиа
|
9.3. Организация потоков с помощью HDS
Задача
Вам требуется поддержка HDS (HTTP Dynamic Streaming) Adobe, кото-
рый уже был фрагментирован и обособлен от своих метаданных.
Решение
Для предложения своим пользователям Adobe Adaptive Streaming
|
location /video/ {
alias /var/www/transformed_video; f4f;
f4f_buffer_size 512k;
}
Данный пример указывает NGINX Plus на необходимость обслужи- вать изначально фрагментированное видео из некоего местоположе- ния на диске своему клиенту при помощи модуля F4F NGINX Plus. Зна- чение размера буфера для его индексного файла (.f4x) устанавливается в 512 Кб.
Обсуждение
Модуль F4F позволяет NGINX обслуживать для конечных пользова- телей изначально фрагментированные медиа. Сама настройка этого проста и состоит в применении обработчика F4F внутри некоего блока местоположения HTTP. Значение директивы f4f_buffer_size настраивает величину размера буфера для файла индексации данного типа медиа.
9.4. Пределы полосы пропускания
Задача
Вам требуется лимитировать полосу пропускания нисходящего ме- диапотока клиентов без воздействия на практику их просмотра.
9.4. Пределы полосы пропускания v 111
|
Примените поддержку побитовой скорости NGINX Plus для файлов медиа MP4:
location /video/ { mp4;
mp4_limit_rate_after 15s; mp4_limit_rate 1.2;
}
Данная настройка позволяет клиентам вашего нисходящего потока выгружать 15 с до применения ограничения битовой скорости. После 15 с данному клиенту разрешается выгружать медиа с соотношением 120 % к установленной скорости обмена данных, что делает возможным этому клиенту всегда выполнять выгрузку быстрее воспроизведения.
Обсуждение
|
Глава 10
| |
Развертывание
В облачных решениях
10.0.
|
Появление поставщиков облачных решений изменило ландшафт хо- стинга веб-приложений. Такой процесс, как подготовка новой маши- ны раньше занимал часы или месяцы; теперь ее можно создать мак- симально быстро, как щелчок мышью или API-вызов. Эти облачные провайдеры сдают в аренду свои виртуальные машины – эта модель носит название инфраструктура как услуга (IaaS) – или управляемые программные решения, такие как базы данных, по модели pay-per-use, что означает, что вы платите только за то, что используете. Это позво- ляет инженерам создавать целые среды для тестирования в любой мо- мент и отключать их, когда они больше не нужны. Облачные провайде- ры также позволяют приложениям масштабироваться по горизонтали в зависимости от потребности в производительности в любой момент. В этой главе рассматриваются базовые развертывания с использовани- ем NGINX и NGINX Plus на нескольких основных платформах облачных провайдеров.
10.1. Автоматическая настройка в AWS
Задача
Вам нужно автоматизировать настройку серверов NGINX в Amazon Web Services, чтобы машины могли автоматически настраивать сами себя.
10.1. Автоматическая настройка в AWS v 113
Решение
|
Обсуждение
Есть три модели мышления при выполнении настройки на AWS.
Настройка при загрузке
|
Полностью настроенные образы машины Amazon
Полностью настройте сервер, затем запишите образ машины Amazon для использования. Этот шаблон запускается очень бы- стро и аккуратно. Тем не менее он менее гибок по отношению окружающей его среде, и поддержание множества образов может быть сложным.
Частично настроенные образы машины Amazon
Это смесь двух миров. Частично настроенный образ – когда требо- вания к программному обеспечению устанавливаются и записы- ваются в образ машины Amazon, а настройка среды выполняется во время загрузки. Этот шаблон является гибким по сравнению с предыдущим шаблоном и быстрым по сравнению с настройкой при загрузке.
Если вы решите частично или полностью настроить свои образы, этот процесс можно автоматизировать. Чтобы собрать конвейер сборки об- разов машины Amazon, предлагается использовать несколько инстру- ментов:
Управление конфигурациями
Инструменты управления конфигурацией определяют состояние сервера в коде, например какую версию NGINX следует запускать
|
и от какого пользователя он должен работать, какой DNS-реша- тель использовать и куда выполнять проксирование. Этот код управления конфигурациями может располагаться в системе управления версиями как программный проект. Популярные ин- струменты управления конфигурациями – Ansible, Chef, Puppet и SaltStack, которые были описаны в главе 5.
Packer от компании HashiCorp
Packer используется для автоматизации управления конфигура- циями практически на любой виртуальной или облачной плат- форме, а также для записи образа машины в случае успешного запуска. В основном Packer создает виртуальную машину на вы- бранной вами платформе, отправляет SSH-пакеты в виртуальную машину, запускает любую заданную вами настройку и записыва- ет образ. Можно использовать Packer для запуска инструмента управления конфигурациями и надежной записи образа машины в соответствии с вашими требованиями.
|
UserData – это строка в кодировке base64, которая скачивается при
первой загрузке и запуске. UserData может быть такой же простой, как и файл окружения, доступ к которому осуществляется другими процес- сами начальной загрузки в вашем образе машины Amazon, или же это может быть скрипт, написанный на любом языке, который существует в образе.
Обычно UserData – это bash-скрипт, который определяет перемен- ные или скачивает переменные для передачи их в управление конфи- гурациями. Управление конфигурациями обеспечивает правильную настройку системы, вырабатывает шаблоны файлов конфигурации на базе переменных среды и выполняет перезагрузку служб. После запуска UserData ваша машина с NGINX должна быть полностью настроена очень надежным образом.
10.2. Маршрутизация в узлы NGINX без ELB v 115
10.2. Маршрутизация в узлы NGINX без ELB
Задача
Вам необходимо маршрутизировать трафик в несколько активных узлов NGINX или создать отработку отказа «активный-пассивный» для достижения высокой доступности без балансировщика нагрузки перед NGINX.
|
Используйте DNS-сервис Amazon Route53 для маршрутизации в не- сколько активных узлов NGINX или настройте проверку работоспособ- ности и отработку отказа между активно-пассивным набором узлов NGINX.
Обсуждение
|
При работе нескольких активных узлов NGINX вам понадобится ис-
пользовать одну из этих функций записи A, чтобы распределить на- грузку по всем узлам. Алгоритм циклического перебора используется, когда для одной записи А указаны несколько IP-адресов. Взвешенное распределение может использоваться для неравномерного распределе- ния нагрузки путем определения весов для каждого IP-адреса сервера в записи A.
Одной из наиболее интересных особенностей Route53 является воз-
можность проверки работоспособности. Вы можете настроить Route53 для мониторинга работоспособности конечной точки, установив TCP- соединение или отправив запрос через HTTP или HTTPS. Проверку работоспособности легко настроить с помощью параметров для IP-ад- реса, имени хоста, порта, пути URI, интервалов, мониторинга и гео- графии. С помощью этих проверок работоспособности Route53 может вывести IP из ротации, если он начинает отказывать. Вы также можете настроить Route53 на аварийное переключение на вторичную запись в случае сбоя, что приведет к настройке «активный–пассивный» с высо- кой доступностью.
|
Route53 имеет геологическую функцию маршрутизации, которая позволит вам направлять своих клиентов к ближайшему к ним узлу NGINX с наименьшей задержкой. При маршрутизации по географии ваш клиент направляется в ближайшее работоспособное физическое местоположение. При запуске нескольких наборов инфраструктуры в конфигурации «активный–активный» вы можете автоматически пере- ключаться на другое геологическое местоположение с помощью прове- рок работоспособности.
При использовании Route53 DNS для маршрутизации трафика в узлы
|
См. также:
https://docs.nginx.com/nginx/deployment-guides/amazon-web-services/route-53-global-server-load-balancing/
10.3. NLB-сэндвич
Задача
Вам необходимо автоматически масштабировать слой NGINX с от- крытым исходным кодом и равномерно и легко распределять нагрузку между серверами приложений.
Решение
Создайте балансировщик сетевой нагрузки (NLB). Во время создания NLB через консоль вам будет предложено организовать новую целевую группу. Если вы не сделаете это через консоль, вам нужно будет создать этот ресурс и подключить его к слушателю на NLB. Вы организовываете группу автоматического масштабирования с конфигурацией запуска, которая обеспечивает экземпляр EC2 с установленным NGINX с откры-
10.4. Развертывание из AWS Marketplace v 117
тым исходным кодом. Группа автоматического масштабирования име- ет конфигурацию для связи с целевой группой, которая автоматически регистрирует любой экземпляр в группе автоматического масштабиро- вания в целевой группе, настроенной при первой загрузке. На целевую группу ссылается слушатель в NLB. Поместите ваши вышестоящие при- ложения за другим балансировщиком сетевой нагрузки и целевой груп- пой, а затем настройте NGINX для проксирования в NLB приложения.
Обсуждение 
|
10.4. Развертывание из AWS Marketplace
Задача
Вам нужно с легкостью запускать NGINX Plus в AWS по лицензии с оплатой по факту потребления.
118 v Глава 10. Развертывание в облачных решениях
 |
Рис. 10.1. Здесь изображен NGINX в виде шаблона NLB-сэндвич с внутренним балансировщиком сетевой нагрузки для использования внутренними приложениями. Пользователь отправляет запрос в приложение-1, которое отправ- ляет запрос в приложение-2 через NGINX, чтобы выполнить запрос пользователя
Решение
Выполните развертывание через AWS Marketplace. Посетите сайт AWS Marketplace (https://aws.amazon.com/marketplace) и введите в поисковую строку «NGINX Plus» (рис. 10.2). Выберите образ машины Amazon на базе выбранного вами дистрибутива Linux; ознакомьтесь с деталями, усло- виями и ценами; затем нажмите на кнопку Continue (Продолжить). На
10.5. Создание образа виртуальной машины NGINX в Azure v 119
следующей странице вы сможете принять условия и развернуть NGINX Plus одним щелчком мыши или принять условия и использовать образ машины Amazon.
Рис. 10.2. Поиск NGINX на сайте AWS Marketplace
Обсуждение
Решение AWS Marketplace для развертывания NGINX Plus обеспечи- вает простоту использования и лицензию с оплатой по факту потребле- ния. Вам не только не нужно ничего устанавливать, но у вас также есть лицензия без лишней нервотрепки, такой как получение заказа на по- купку для годичной лицензии. Это решение позволяет вам опробовать NGINX Plus без каких-либо обязательств. Вы также можете использовать образ машины NGINX Plus Marketplace в качестве емкости переполне- ния. Обычной практикой является приобретение лицензий на ожида- емую рабочую нагрузку и использование образа машины Marketplace в группе автоматического масштабирования в качестве емкости пере- полнения. Эта стратегия гарантирует, что вы платите только за то, что используете.
10.5. Создание образа виртуальной машины
NGINX в Azure
Задача
Вам нужно создать образ виртуальной машины (ВМ) собственного сервера NGINX, настроенного так, как вы считаете нужным, чтобы быст-
120 v Глава 10. Развертывание в облачных решениях
ро создать больше серверов или использовать их в наборах масшта- бирования.
Решение
|
$ sudo waagent -deprovision + user -force
|
виртуальную машину и высвободите ресурсы:
$ azure vm deallocate -g <ResourceGroupName> \
-n <VirtualMachineName>
После этого вы сможете пометить ее как универсальную с помощью команды azure vm generalize:
$ azure vm generalize -g <ResourceGroupName> \
-n <VirtualMachineName>
После того как ваша виртуальная машина станет универсальной, вы можете создать образ. Приведенная ниже команда создаст образ, а так- же сгенерирует шаблон диспетчера ресурсов Azure (ARM), который вы будете использовать для загрузки этого образа:
$ azure vm capture <ResourceGroupName> <VirtualMachineName> \
<ImageNamePrefix> -t <TemplateName>.json
10.5. Создание образа виртуальной машины NGINX в Azure v 121
|
$ azure network nic create <ResourceGroupName> \
<NetworkInterfaceName> \
<Region> \
--subnet-name <SubnetName> \
--subnet-vnet-name <VirtualNetworkName>
Эта команда выводит подробную информацию о недавно созданном сетевом интерфейсе. Первая строка выходных данных будет идентифи- катором сетевого интерфейса, который вам понадобится для исполь- зования шаблона ARM, созданного Azure. Получив идентификатор, вы можете создать развертывание с помощью шаблона ARM:
$ azure group deployment create <ResourceGroupName> \
<DeploymentName> \
-f <TemplateName>.json
|
После ввода необходимых параметров Azure приступит к созданию
новой виртуальной машины из вашего собственного образа.
Обсуждение
Создание пользовательского образа в Azure позволяет делать копии предварительно настроенного сервера NGINX или NGINX Plus по жела- нию. Шаблон ARM позволяет быстро и надежно развертывать этот же сервер снова и снова по мере необходимости. Используя путь к образу виртуальной машины, который можно найти в шаблоне, можно созда-
122 v Глава 10. Развертывание в облачных решениях
вать различные наборы инфраструктуры, такие как наборы масштаби- рования виртуальных машин или другие виртуальные машины с раз- личными конфигурациями.
См. также:
|
age ? toc =%2 Fazure %2 Fvirtual-machines %2 Flinux %2 Ftoc . json
10.6.
|
Задача
Вам необходимо масштабировать узлы NGINX за балансировщиком нагрузки Azure, чтобы добиться высокой доступности и динамического использования ресурсов.
Решение
Создайте балансировщик нагрузки Azure, который является обще- доступным или внутренним. Разверните образ виртуальной машины NGINX, созданный в предыдущем разделе, или образ NGINX Plus из Marketplace, описанный в рецепте 10.7, в набор для масштабирования виртуальных машин Azure (VMSS). После развертывания балансиров- щика нагрузки и VMSS настройте внутренний пул балансировщика на- грузки в VMSS. Установите правила балансировки нагрузки для портов и протоколов, на которые вы хотите принимать трафик, и направьте их во внутренний пул.
Обсуждение
Обычно NGINX масштабируется для достижения высокой доступно- сти или обработки пиковых нагрузок без чрезмерного выделения ре- сурсов. В Azure этого можно достичь с помощью VMSS. Использование балансировщика нагрузки Azure обеспечивает простоту управления для добавления и удаления узлов NGINX в пул ресурсов при масштаби- ровании. С помощью балансировщиков нагрузки Azure можно прове- рить работоспособность своих внутренних пулов и передавать трафик только на исправные узлы. Вы можете запустить внутренние баланси-
10.7. Развертывание через Azure Marketplace v 123
|
10.7. Развертывание через Azure Marketplace
Задача
Вам нужно с легкостью запустить NGINX Plus в Azure с лицензией с оплатой по факту использования.
Решение
Разверните образ виртуальной машины NGINX Plus через Azure Marketplace:
1.
|
2. Из списка выберите образ виртуальной машины NGINX Plus, опу-
бликованный NGINX, Inc.
3. При появлении запроса на выбор модели развертывания выбери- те параметр Resource Manager (Диспетчер ресурсов) и нажмите кнопку Create (Создать).
4. Затем вам будет предложено заполнить форму, указав имя своей виртуальной машины, тип диска, имя пользователя и пароль по умолчанию или открытый ключ SSH, для какой подписки вы хо- тите выставить счет, группу ресурсов, которую вы хотите исполь- зовать, и местоположение.
5. Как только эта форма будет заполнена, можете нажать OK. Ваша форма будет подтверждена.
6. При появлении запроса выберите размер виртуальной машины и нажмите кнопку Select (Выбрать).
7. На следующей панели у вас есть возможность выбрать допол- нительные конфигурации, которые будут использоваться по умолчанию в зависимости от группы ресурсов, выбранной ра- нее. После изменения этих параметров и их принятия нажмите кнопку ОК.
124 v Глава 10. Развертывание в облачных решениях
8.
|
9. После того как вы проверите и загрузите свой шаблон, можно на- жать OK, чтобы перейти к приобретению. На экране вы увидите уведомление о расходах, которые вы понесете в связи с исполь- зованием этой виртуальной машины. Нажмите кнопку Purchase (Купить), и ваш NGINX Plus начнет загружаться.
Обсуждение
|
10.8. Развертывание в Google Compute Engine
Задача
Вам необходимо создать сервер NGINX в Google Compute Engine, что- бы осуществлять балансировку нагрузки или выступать в качестве по- средника (proxy) для остальных своих ресурсов в Google Compute или App Engine.
Решение
Запустите новую виртуальную машину в Google Compute Engine. Вы- берите имя для своей виртуальной машины, зоны, тип машины и за- грузочного диска. Настройте управление идентификацией и доступом, брандмауэр и любые дополнительные конфигурации, которые вам нужны. Создайте виртуальную машину.
После ее создания войдите в систему через SSH или через Google Cloud Shell. Установите NGINX или NGINX Plus с помощью менеджера пакетов для данного типа ОС. Настройте NGINX, как считаете нужным, и перезагрузите.
10.9. Создание образа Google Compute v 125
Кроме того, вы можете установить и настроить NGINX с помощью сценария запуска Google Compute Engine, который является дополни- тельным параметром конфигурации при создании виртуальной маши- ны.
Обсуждение
|
10.9. Создание образа Google Compute
Задача
Вам нужно создать образ Google Compute, чтобы быстро сделать экземпляр виртуальной машины или шаблон экземпляра для группы экземпляров.
Решение
Создайте виртуальную машину, как описано в рецепте 10.8. После установки и настройки NGINX на экземпляре виртуальной машины установите для состояния автоматического удаления загрузочного дис- ка значение false. Чтобы установить состояние автоматического уда- ления диска, отредактируйте виртуальную машину. На странице Edit (Правка) под конфигурацией диска установлен флажок Delete boot disk when instance is deleted (Удалить загрузочный диск при удалении экземпляра). Снимите этот флажок и сохраните конфигурацию вир- туальной машины. Как только состояние автоматического удаления эк- земпляра будет установлено в false, удалите экземпляр. При появлении запроса не устанавливайте флажок, предлагающий удалить загрузоч- ный диск. После выполнения этих задач у вас останется неприкреплен- ный загрузочный диск с установленным NGINX.
После того как ваш экземпляр удален и у вас есть неприкрепленный
загрузочный диск, вы можете создать образ Google Compute. В разделе Image (Образ) консоли Google Compute Engine выберите Create Image (Создать образ). Вам будет предложено указать имя образа, семейство,
|
описание, тип шифрования и источник. Тип источника, который вам нужно использовать, – это диск; и для исходного диска выберите не- прикрепленный загрузочный диск NGINX. Выберите Create (Создать), и Google Compute Cloud создаст образ из вашего диска.
Обсуждение
Можно использовать образы Google Cloud для создания виртуаль- ных машин с загрузочным диском, идентичным только что созданному серверу. Ценность создания образов заключается в том, чтобы гаранти- ровать, что каждый экземпляр этого образа идентичен. При установ- ке пакетов во время загрузки в динамической среде, если только вы не используете блокировку версий с закрытыми репозиториями, вы ри- скуете не проверить версию пакета и обновления до запуска в произ- водственной среде. Используя образы машины, вы можете проверить, что каждый пакет, работающий на этой машине, соответствует вашим требованиям, что повышает надежность предложения услуги.
См. также:
https://cloud.google.com/compute/docs/images/create-delete-deprecate-private-images
10.10. Создание прокси-сервера для Google App Engine
Задача
Вам нужно создать прокси-сервер для Google App Engine, чтобы пере- ключать контексты между приложениями или обслуживать HTTPS в настраиваемом домене.
Решение
Используйте NGINX в Google Compute Cloud. Создайте виртуальную машину в Google Compute Engine или образ виртуальной машины с установленным NGINX и сделайте шаблон экземпляра с этим образом в качестве загрузочного диска. Если вы создали шаблон экземпляра, то нужна и группа экземпляров, которая использует этот шаблон.
Выполните настройку NGINX. Убедитесь, что вы используете прото- кол HTTPS, потому что Google App Engine является общедоступным, и вы должны убедиться, что не отключаете HTTPS на вашем экземпля-
|
ре NGINX и не позволяете информации перемещаться между NGINX и Google App Engine без защиты. Поскольку App Engine предоставляет только одну конечную точку DNS, вы будете использовать директиву proxy_pass вместо блоков upstream в версии NGINX с открытым исходным кодом.
|
Вы можете сохранить файлы конфигурации NGINX в Google Storage,
а затем использовать сценарий запуска для своего экземпляра, чтобы извлечь конфигурацию во время загрузки. Это позволит вам изменить конфигурацию без необходимости записывать новый образ. Тем не ме- нее это увеличит время запуска вашего сервера NGINX.
Обсуждение
Вы хотите запустить NGINX перед Google App Engine, если использу- ете собственный домен, и сделать свое приложение доступным через HTTPS. В настоящее время Google App Engine не позволяет загружать собственные сертификаты SSL. Поэтому, если вы хотите обслуживать свое приложение в домене, отличном от appspot.com, с шифрованием, вам необходимо создать прокси-сервер с помощью NGINX для прослу- шивания в своем пользовательском домене. NGINX будет шифровать связь между собой и вашими клиентами, а также между собой и Google App Engine.
Еще одна причина, по которой вам может потребоваться запустить
NGINX перед Google App Engine, – это размещение большого количества приложений App Engine в одном домене и использование NGINX для переключения контекста на основе URI. Микросервисы – это популяр- ная архитектура, и прокси-сервер, такой как NGINX, обычно выполняет маршрутизацию трафика. Google App Engine упрощает развертывание приложений, и вместе с NGINX у вас есть полноценная платформа дос- тавки приложений.
Глава 11
|
11.0. Введение
|
11.1. Записи DNS SRV
Задача
Вы бы хотели использовать свою имеющуюся реализацию записей DNS SRV в качестве источника для вышестоящих серверов с помощью NGINX Plus.
Решение
11.1. Записи DNS SRV v 129
Определите соответствующую директиву службы со значением http для вышестоящего сервера, чтобы указать NGINX на необходимость применения имеющихся записей SRV в качестве пула балансировки нагрузки:
http {
resolver 10.0.0.2;
upstream backend { zone backends 64k;
server api.example.internal service=http resolve;
}
}
|
Обсуждение
Динамичная инфраструктура становится все более популярной бла- годаря спросу и внедрению инфраструктур на облачной основе. Среды с автоматическим масштабированием масштабируются горизонталь- но, увеличивая или уменьшая общее число серверов в имеющемся пуле для соответствия текущей нагрузке. Горизонтальное масштабирование требует балансировщика нагрузки, который способен добавлять или удалять ресурсы из имеющегося пула. Обладая некоей записью SRV, вы снимаете с себя ответственность за отслеживание текущего списка сер- веров и передаете ее DNS. Такой тип настройки чрезвычайно заманчив для сред с контейнерами, так как у вас могут быть контейнеры с изме- няемыми номерами портов, причем, возможно, даже с одним и тем же IP-адресом. Важно также отметить, что полезная нагрузка записи UDP DNS ограничена примерно 512 байтами.
130 v Глава 11. Контейнеры / Микросервисы
11.2.
|
Задача
Вам требуется быстро подготовить к работе образ NGINX из Docker Hub.
Решение
|
$ docker run --name my-nginx -p 80:80 \
-v /path/to/content:/usr/share/nginx/html:ro -d nginx
Команда docker извлекает образ nginx:latest из Docker Hub, если не обнаруживает его локально. Затем эта команда запускает данный об- раз NGINX в качестве контейнера Docker, отображая localhost:80 в порт 80 самого контейнера NGINX. Она также монтирует имеющийся локаль- ный каталог /path/to/content/ в качестве тома контейнера в /usr/share/ nginx/html/ с доступом только для чтения. Установленная по умолчанию конфигурация NGINX будет обслуживать этот каталог в качестве стати- ческого содержимого. При отображении из вашей локальной машины в контейнер первым идет значение порта или каталога локальной маши- ны, а порт или каталог самого контейнера идут вторыми.
Обсуждение
NGINX сделал официальный образ Docker, доступный через Docker Hub. Этот официальный образ Docker позволяет легко начать работу в Docker с вашей любимой платформой доставки приложений, NGINX. В данном разделе мы имели возможность запустить NGINX в контей- нере при помощи одной единственной команды! Основная ветвь офи- циального образа Docker NGINX, которой мы воспользовались в данном примере, собрана из образа Docker Debian Jessie. Однако вы также мо-
11.3. Создание Docker fi le NGINX v 131
жете выбирать официальные образы, собранные из Alpine Linux. Файл Dockerfile и исходные коды для этих официальных образов доступны в GitHub. Вы можете расширить данный официальный образ, создав собственный файл Dockerfile и определив свой официальный образ в соответствующей команде FROM.
См. также:
|
11.3. Создание Dockerfile NGINX
Задача
Для сборки образа Docker вам требуется создать файл Dockerfile NGINX.
Решение
|
Файл Dockerfile:
FROM centos:7
# Устанавливае м репозитори й epel , чтоб ы получит ь ngin x и установит ь ngin x.
132 v Глава 11. Контейнеры / Микросервисы
RUN yum -y install epel-release && \
yum -y install nginx
# Добавляем локальные файлы конфигурации в образ.
ADD /nginx-conf /etc/nginx
EXPOSE 80 443
|
Получаемая структура каталогов выглядит так:
|
└── nginx-conf
├── conf.d
│ └── default.conf
├── fastcgi.conf
├── fastcgi_params
├── koi-utf
├── koi-win
├── mime.types
├── nginx.conf
├── scgi_params
├── uwsgi_params
└── win-utf
Я решил разместить настройки NGINX целиком внутри данного ката- лога Docker для простоты доступа ко всем его настройкам при помощи всего одной строки в соответствующем файле Dockerfile, чтобы доба- вить все свои настройки NGINX.
Обсуждение
Вы можете найти полезным создание своего собственного файла Dockerfile, когда вам требуется полный контроль над установкой па- кетов и их обновлением. Обычно держат собственный репозиторий образов, с тем чтобы знать, что ваш базовый образ надежен и прове- рен вашей командой, прежде чем запускать его в реальную эксплуа- тацию.
11.4. Сборка образа NGINX Plus v 133
11.4. Сборка образа NGINX Plus
Задача
|
Решение
Для создания образа Docker NGINX Plus воспользуйтесь этим файлом Dockerfile. Вам потребуется выгрузить свои сертификаты репозитория NGINX Plus и держать их в том же каталоге, что и данный Dockerfile с именами nginx-repo.crt и nginx-repo.key соответственно. С их помощью этот Dockerfile сделает всю остальную работу, установив NGINX Plus для вашего использования и связав журналы доступа и ошибок NGINX со сборщиком журналов Docker.
FROM debian:stretch-slim
LABEL maintainer="NGINX <docker-maint@nginx.com>"
# Скачиваем сертификат и ключ с портала клиента
# (https://c s.nginx.com ) и копируе м в контекс т сборк и.
COPY nginx-repo.crt /etc/ssl/nginx/ COPY nginx-repo.key /etc/ssl/nginx/ # Устанавливаем NGINX Plus.
RUN set -x \
&& APT_PKG="Acquire::https::plus-pkgs.nginx.com::" \ && REPO_URL="https://plus-pkgs.nginx.com/debian" \ && apt-get update && apt-get upgrade -y \
&& apt-get install \
--no-install-recommends --no-install-suggests\
-y apt-transport-https ca-certificates gnupg1 \
&& \
NGINX_GPGKEY=573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62;\
found=''; \
for server in \
ha.pool.sks-keyservers.net \ hkp://keyserver.ubuntu.com:80 \ hkp://p80.pool.sks-keyservers.net:80 \
134 v Глава 11. Контейнеры / Микросервисы
pgp.mit.edu \
|
echo "Fetching GPG key $NGINX_GPGKEY from $server"; \
apt-key adv --keyserver "$server" --keyserver-options \
timeout=10 --recv-keys "$NGINX_GPGKEY" \
&& found=yes \
&& break;\ done;\
test -z "$found" && echo >&2 \
"error: failed to fetch GPG key $NGINX_GPGKEY" && exit 1; \
echo "${APT_PKG}Verify-Peer "true";"\
>> /etc/apt/apt.conf.d/90nginx \
&& echo \
"${APT_PKG}Verify-Host "true";">>\
/etc/apt/apt.conf.d/90nginx \
&& echo "${APT_PKG}SslCert \ "/etc/ssl/nginx/nginx-repo.crt";" >> \
/etc/apt/apt.conf.d/90nginx \
&& echo "${APT_PKG}SslKey \ "/etc/ssl/nginx/nginx-repo.key";" >> \
/etc/apt/apt.conf.d/90nginx \
|
"deb ${REPO_URL} stretch nginx-plus" \
> /etc/apt/sources.list.d/nginx-plus.list \
&& apt-get update && apt-get install -y nginx-plus \ && apt-get remove --purge --auto-remove -y gnupg1 \ && rm -rf /var/lib/apt/lists/*
# Перенаправляем журналы запросов сборщику журналов Docker.
RUN ln -sf /dev/stdout /var/log/nginx/access.log \
&& ln -sf /dev/stderr /var/log/nginx/error.log
EXPOSE 80
STOPSIGNAL SIGTERM
CMD ["nginx", "-g", "daemon off;"]
Чтобы собрать этот файл Dockerfile в образ Docker, выполните приве- денную ниже команду в каталоге, который содержит данный Dockerfile, а также ваши сертификат и ключ репозитория NGINX Plus:
$ docker build --no-cache -t nginxplus .
11.5. Использование переменных среды в NGINX v 135
Данная команда docker build использует флаг --no-cache, чтобы гаран- тировать, что вне зависимости от того, когда вы это создадите, из репо- зитория NGINX Plus будут вытянуты для обновления свежие пакеты NGINX Plus. Если для вас будет допустимо применение той же самой версии NGINX Plus, которую мы собирали ранее, вы можете опустить флаг --no-cache. В этом примере наш новый образ Docker снабжается те- гом nginxplus.
|
Создавая для NGINX Plus свой собственный образ Docker, вы получае- те возможность настраивать свой контейнер NGINX Plus так, как счита- ете нужным, и переносить его в любую среду Docker. Это открывает всю мощность и расширенную функциональность NGINX Plus для вашей среды контейнеров. Данный файл Dockerfile не использует свойство ADD для добавления настроек; вам придется добавлять свои настройки вручную.
См. также:
https://www.nginx.com/blog/deploying-nginx-nginx-plus-docker/
11.5.
|
Задача
Вам требуется воспользоваться переменными среды внутри своей конфигурации NGINX чтобы применять один и тот же образ контейне- ра для различных сред.
Решение
Для установки в NGINX переменных из своей среды воспользуйтесь модулем ngx_http_perl_module:
daemon off; env APP_DNS;
include /usr/share/nginx/modules/*.conf;
...
http {
perl_set $upstream_app 'sub { return $ENV{"APP_DNS"}; }'; server {
|
...
location / {
proxy_pass https://$upstream_app;
}
}
}
Чтобы использовать perl_set, нужно, чтобы у вас был установлен ngx_http_perl_module; это можно сделать, загрузив данный модуль дина- мически или статически при сборке из исходного кода. По умолчанию NGINX стирает переменные среды из своего окружения: вам требуется объявлять все переменные, которые вы не желаете удалять, с помощью директивы env. Директива perl_set получает два параметра: имя пере- менной, которую вы бы хотели установить, и строку perl, которая вы- числяет необходимый результат.
Приведенный ниже файл Dockerfile, который динамически загружает
|
FROM centos:7
# Устанавливае м репозитори й epel , чтоб ы получит ь ngin x и установит ь ngin x.
RUN yum -y install epel-release && \
yum -y install nginx nginx-mod-http-perl
# Добавляем локальные файлы конфигурации в образ.
ADD /nginx-conf /etc/nginx
EXPOSE 80 443
CMD ["nginx"]
Обсуждение
Обычной практикой при использовании Docker является примене- ние переменных окружения для изменения того порядка, в котором работают контейнеры. Можно применять переменные среды в своей
11.6. Контроллер Ingress в Kubernetes v 137
конфигурации NGINX, чтобы ваш файл Dockerfile NGINX можно было использовать во многих разнообразных средах.
11.6.
|
Задача
Вы развертываете свое приложение в Kubernetes, и вам требуется контроллер ingress.
Решение
Убедитесь, что у вас имеется доступ к необходимому образу контрол- лера ingress. В случае с NGINX можно использовать образ nginx/nginx- ingress из Docker Hub. В случае с NGINX Plus вам потребуется собрать собственный образ и разместить его в собственном закрытом реестре Docker. Вы можете найти инструкции по сборке и доставке собствен- ного контроллера ingress для NGINX Plus на странице https://github.com/nginxinc/kubernetes-ingress/blob/master/build/README.md.
Зайдите в папку Kubernetes Ingress Controller Deployments (https://
|
Создайте пространство имен и учетную запись службы для своего контроллера ingress; они оба имеют название nginx-ingress.
$ kubectl apply -f common/ns-and-sa.yaml
Создайте ключ безопасности с помощью сертификата TLS и ключа для контроллера ingress:
$ kubectl apply -f common/default-server-secret.yaml
Эти сертификат и ключ самостоятельно подписываются и создаются NGINX Inc. для проверок и примеров. Рекомендуется применять свой собственный, поскольку данный ключ открыт для общего доступа.
В качестве варианта можно создать словарь CofigMap для индиви- дуальной конфигурации NGINX (в данном случае словарь пуст; но вы можете ознакомиться с подробностями пользовательских настроек и аннотацией здесь: https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/customization):
$ kubectl apply -f common/nginx-config.yaml
|
Если в вашем кластере включено управление доступом на основе ро- лей, создайте роль кластера и привяжите ее к соответствующей учетной записи этой службы. Для выполнения данного шага вы должны быть администратором кластера:
$ kubectl apply -f rbac/rbac.yaml
Теперь разверните свой контроллер ingress. В данном репозитории доступны два примера развертывания: Deployment и DaemonSet. Если вы планируете динамически изменять общее число реплик контрол- лера ingress, используйте Deployment. Для развертывания контрол- лера ingress во всех узлах или в подмножестве узлов воспользуйтесь DaemonSet.
Если вы намерены использовать манифесты Deployment NGINX Plus,
вам следует исправить соответствующий файл YAML и определить собственный реестр и образ.
Для Deployment NGINX:
$ kubectl apply -f deployment/nginx-ingress.yaml
Для Deployment NGINX Plus:
$ kubectl apply -f deployment/nginx-plus-ingress.yaml
Для DaemonSet NGINX:
$ kubectl apply -f daemon-set/nginx-ingress.yaml
Для DaemonSet NGINX Plus:
$ kubectl apply -f daemon-set/nginx-plus-ingress.yaml
Убедитесь, что ваш контроллер ingress запущен:
$ kubectl get pods --namespace=nginx-ingress
Если вы создали DaemonSet, порты контроллера ingress 80 и 443 отобра- жены в те же порты узла, в котором запущен этот контроллер. Для до- ступа к данному контроллеру ingress используйте эти порыт и IP-адрес любого из узлов, в которых работает контроллер. Если вы развернули Deployment, продолжите, используя приведенную ниже информацию.
Для методов Deployment имеются два варианта доступа к модулям контроллера ingress. Можно указать Kubernetes случайным образом вы- делять порт узла, который соответствует модулю контроллера ingress.
|
Такая служба имеет тип NodePort. Другой вариант – создание службы с типом LoadBalancer. При создании службы типа LoadBalancer Kubernetes создает балансировщик нагрузки для конкретной облачной платформы, такой как Amazon Web Services, Microsoft Azure и Google Cloud Compute.
Для создания службы типа NodePort используйте приведенную ниже команду:
$ kubectl create -f service/nodeport.yaml
Чтобы настроить открытый для данного модуля порт статически, из- мените соответствующий YAML и добавьте атрибу nodePort: {port} в на- стройки всех подлежащих открытию портов.
Для создания службы типа LoadBalancer для Google Cloud Compute
или Azure воспользуйтесь таким кодом:
$ kubectl create -f service/loadbalancer.yaml
Для создания службы типа LoadBalancer для Amazon Web Services:
$ kubectl create -f service/loadbalancer-aws-elb.yaml
|
proxy-protocol: "True"
real-ip-header: "proxy_protocol" set-real-ip-from: "0.0.0.0/0"
Затем обновите словарь:
$ kubectl apply -f common/nginx-config.yaml
Теперь вы можете выполнять адресацию своего модуля по его Node- Port или делая запросы к балансировщику нагрузки, созданному от его имени.
Обсуждение
На момент написания данных строк Kubernetes является ведущей платформой для оркестрации и управления контейнерами, погранич-
140 v Глава 11. Контейнеры / Микросервисы
|
11.7. Маршрутизатор OpenShift
|
Вам нужно развернуть свое приложение в OpenShift, и вы бы хотели использовать в качестве маршрутизатора NGINX.
Решение
Соберите образ Маршрутизатора и выгрузите его в свой закрытый ре- естр. Вы можете найти необходимые исходные файлы для этого образа здесь: https://github.com/openshift/origin/tree/master/images/router/nginx. Важ- но поместить образ вашего Маршрутизатора в имеющийся закрытый реестр до того, как вы удалите установленный по умолчанию Маршру- тизатор, поскольку это сделает реестр недоступным.
Выполните вход в кластер OpenShift в качестве администратора:
$ oc login -u system:admin
Выберите проект default:
$ oc project default
Выполните резервное копирование настроек установленного по умолчанию Маршрутизатора, в случае если вам потребуется его восста- новить:
$ oc get -o yaml service/router dc/router \ clusterrolebinding/router-router-role \ serviceaccount/router > default-router-backup.yaml
Удалите Маршрутизатор:
$ oc delete -f default-router-backup.yaml
11.7. Маршрутизатор OpenShift v 141
Разверните Маршрутизатор NGINX:
$ oc adm router router --images={image} --type='' \
--selector='node-role.kubernetes.io/infra=true'
В данном примере значение {image} должно указывать на образ Маршрутизатора NGINX в вашем реестре. Параметр selector определя- ет селектор метки для узлов, где будет развернут ваш Маршрутизатор: node-role.kubernetes.io/infra=true. Используйте селектор, который актуа- лен в вашей среде.
Проверьте, что ваши модули работают:
$ oc get pods
|
{string}. По умолчанию страница состояния заглушки NGINX доступна через порт 1936 того узла, где запущен ваш Маршрутизатор (вы можете изменить этот порт с помощью переменной среды STATS_PORT). Для дос- тупа к странице вне данного узла вам потребуется добавить запись в правила IPtables для такого узла:
$ sudo iptables -I OS_FIREWALL_ALLOW -p tcp -s {ip range} \
-m tcp --dport 1936 -j ACCEPT
Перейдите в своем браузере по адресу http://{node-ip}:1936/stub_status,
чтобы получить доступ к странице состояния заглушки.
Обсуждение
Маршрутизатор OpenShift является точкой входа для внешних за- просов, ограничивающей работающие в OpenShift приложения. Рабо- та этого Маршрутизатора состоит в получении входящих запросов и направлении их в соответствующий модуль приложения. Возможно- сти балансировки нагрузки и маршрутизации NGINX делают его вели- колепным выбором для использования в качестве Маршрутизатора OpenShift. Переключение с устанавливаемого по умолчанию Маршру- тизатора OpenShift на Маршрутизатор NGINX активирует все имею- щиеся функции и мощь NGINX в качестве ingress вашего приложения OpenStack.
|
Режимы развертывания высокой доступности
12.0. Введение
|
12.1. Режим высокой доступности NGINX
Задача
Вам необходимо решение для балансировки нагрузки с высокой до- ступностью.
Решение
Воспользуйтесь режимом высокой доступности (HA, highly available) NGINX Plus с поддержкойактивности, установивпакет nginx-ha-keepalived из репозитория NGINX Plus.
12.2. Балансировка нагрузки балансировщиками с помощью DNS v 143
|
Пакет nginx-ha-keepalived основан на поддержке активности и управ- ляет виртуальным IP-адресом, открытым клиенту. На самом сервере NGINX запущен еще один процесс, который предоставляет гарантию работы этого NGINX Plus и самого процесса поддержки активности. Процесс поддержки активности – это процесс, который использует про- токол VRRP (Virtual Router Redundancy Protocol), отправляя небольшие сообщения, часто именуемые сердцебиениями, в резервный сервер. Если этот сервер не получает такое сердцебиение на протяжении трех последовательных периодов, он инициирует отработку отказа, пере- мещая виртуальный IP-адрес к себе и превращаясь в хозяина (master). Имеющиеся возможности отработки отказа пакета nginx-ha-keepalived можно настраивать для указания индивидуальных ситуаций сбоя.
12.2. Балансировка нагрузки балансировщиками с помощью DNS
Задача
Вам необходимо распределить нагрузку между двумя или более сер- верами NGINX.
Решение
Воспользуйтесь DNS, чтобы выполнить распределение нагрузки по круговому циклу (round robin) по серверам NGINX, добавляя несколько IP-адресов в запись A DNS.
Обсуждение
При запуске нескольких балансировщиков нагрузки можно распре- делять нагрузку через DNS. Запись A позволяет перечислять под одним полностью определенным именем домена (FQDN, fully qualified domain name) несколько IP-адресов. DNS будет автоматически прокручивать все IP- адреса каруселью. DNS также предлагает взвешенный цикличес- кий алгоритм со взвешенными записями, которые действуют так же, как и описанный в главе 1 циклический алгоритм в NGINX. Эти методы прекрасно работают. Тем не менее удаление конкретной записи в том случае, когда сервер NGINX испытал сбой, может оказаться ловушкой. Существуют поставщики DNS – Amazon Route53 для одних и Dyn DNS для других, – предлагающие проверку жизнеспособности и отработку
144 v Глава 12. Режимы развертывания высокой доступности
|
12.3. Балансировка нагрузки в EC2
Задача
Вы используете NGINX в AWS, причем ваш режим высокой доступно- сти NGINX Plus не поддерживает IP-адреса Amazon.
Решение
|
Обсуждение
Основанное на поддержке активности (keepaliving) решение с ре- жимом высокой доступности от NGINX Plus не будет работать в AWS, поскольку он не поддерживает плавающие виртуальные IP-адреса, так как IP-адреса EC2 работают совершенно иначе. Это вовсе не означает, что NGINX лишен возможностей режима высокой доступности в AWS; на самом деле совершенно наоборот. Amazon предлагает баланси- ровщик сетевой нагрузки AWS, который будет естественным образом выполнять балансировку нагрузки по множеству физически раздель- ных центров обработки данных, именуемых зонами доступности (AZ, availability zones), предоставит активные проверки жизнеспособности, а также конечную точку DNS CNAME. Распространенным решением для NGINX с режимом высокой доступности в AWS является размещение уровня NGINX позади имеющегося балансировщика сетевой нагрузки.
12.4. Синхронизация конфигурации v 145
|
|
12.4. Синхронизация конфигурации
Задача
Вы запускаете уровень NGINX Plus с режимом высокой доступности, и вам необходима синхронизация конфигураций серверов.
Решение
Воспользуйтесь эксклюзивной функцией синхронизации конфигура- ций NGINX Plus. Для настройки этой функциональности следуйте этим этапам:
Из репозитория пакетов NGINX Plus установите пакет nginx-sync.
Для RHEL или CentOS:
$ sudo yum install nginx-sync
Для Ubuntu или Debian:
$ sudo apt-get install nginx-sync
Предоставьте главной машине SSH-доступ в качестве суперпользова- теля ко всем одноранговым машинам.
Сгенерируйте пару ключей для аутентификации по протоколу SSH
для суперпользователя и получите открытый ключ:
|
$ sudo ssh-keygen -t rsa -b 2048
$ sudo cat /root/.ssh/id_rsa.pub
ssh-rsa AAAAB3Nz4rFgt...vgaD root@node1
Получите IP-адрес главного узла:
$ ip addr
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen \ 1000
|
inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe34:6c35/64 scope link valid_lft forever preferred_lft forever
Команда ip addr выведет дамп информации относительно интерфей- сов машины. Игнорируйте интерфейс петли (loopback), который обыч- но идет первым. Найдите IP-адрес, который следует за inet для само- го первого интерфейса. В данном примере таким IP-адресом является
192.168.1.2.
Распространите открытый ключ для файла authorized_keys пользова- теля root во всех одноранговых узлах и задайте авторизацию только с IP-адреса главной машины:
$ sudo echo 'from="192.168.1.2" ssh-rsa AAAAB3Nz4rFgt...vgaD \ root@node1' >> /root/.ssh/authorized_keys
Добавьте в /etc/ssh/sshd_confg приведенную ниже строку и выполните перезагрузку sshd на всех узлах:
$ sudo echo 'PermitRootLogin without-password' >> \
/etc/ssh/sshd_config
$ sudo service sshd reload
Убедитесь, что пользователь root на главном узле способен подклю- чаться по протоколу SSH ко всем одноранговым узлам без пароля:
|
$ sudo ssh root@node2.example.com
На главной машине создайте файл настроек /etc/nginx-sync.conf со сле-
дующей конфигурацией:
NODES="node2.example.com node3.example.com node4.example.com" CONFPATHS="/etc/nginx/nginx.conf /etc/nginx/conf.d" EXCLUDE="default.conf"
|
/etc/nginx/nginx.conf и /etc/nginx/conf.d в одноранговые узлы с именами
node2.example.com, node3.example.com и node4.example.com. Если процесс син- хронизации обнаруживает файл с именем default.conf, для него не будет выполняться активная доставка в этой одноранговой сети, так как он настроен в качестве EXCLUDE.
Для настройки местоположения бинарных файлов NGINX, RSYNC, SSH, diff, а также расположения lockfile и резервного каталога имеют- ся дополнительные параметры. Существует также параметр, который использует sed для выработки шаблона заданных файлов. Для полу- чения дополнительных сведений относительно расширенных пара- метров посетите https://docs.nginx.com/nginx/admin-guide/high-availability/con fi guration-sharing/.
Проверьте свою конфигурацию:
$ nginx-sync.sh -h # display usage info
$ nginx-sync.sh -c node2.example.com # compare config to node2
$ nginx-sync.sh -C # compare master config to all peers
$ nginx-sync.sh # sync the config & reload NGINX on peers
Обсуждение
Эта имеющаяся только в NGINX Plus функциональность позволяет управлять несколькими серверами NGINX Plus в конфигурации с вы-
148 v Глава 12. Режимы развертывания высокой доступности
|
12.5. Совместное использование состояния с помощью Zone Sync
Задача
|
Решение
Воспользуйтесь параметром sync при настройке зоны общей памяти
NGINX Plus:
stream {
resolver 10.0.0.2 valid=20s;
server {
listen 9000; zone_sync;
zone_sync_server nginx-cluster.example.com:9000 resolve; # ... Security measures
}
}
http {
upstream my_backend { zone my_backend 64k;
12.5. Совместное использование состояния с помощью Zone Sync v 149
server backends.example.com resolve; sticky learn zone=sessions:1m
|
sync;
}
server {
listen 80; location / {
proxy_pass http://my_backend;
}
}
}
Обсуждение
|
Глава 13
|
Активности
13.0. Введение
|
13.1. Активация модуля Stub Status
С открытым исходным кодом
Задача
Вам нужно активировать базовый мониторинг для NGINX.
Решение
В блоке location внутри HTTP-сервера NGINX активируйте модуль
stub_status:
location /stub_status { stub_status;
13.2. Активация инструментальной панели мониторинга NGINX Plus v 151
allow 127.0.0.1; deny all;
# Set IP restrictions as appropriate
}
Проверьте свои настройки, выполнив запрос состояния:
|
server accepts handled requests 1 1 1
Reading: 0 Writing: 1 Waiting: 0
Обсуждение
|
$connections_waiting.
13.2. Активация инструментальной панели мониторинга NGINX Plus
Задача
Вам необходимы подробные метрики относительно протекающего через ваш сервер NGINX Plus трафика.
Решение
Воспользуйтесь инструментальной панелью мониторинга активнос- ти в реальном масштабе времени:
152 v Глава 13. Расширенный мониторинг активности
server { # ...
location /api {
api [write=on];
|
}
location = /dashboard.html { root /usr/share/nginx/html;
}
}
|
Обсуждение
NGINX Plus предоставляет продвинутую инструментальную панель мониторинга состояния. Она предоставляет подробное состояние си- стемы NGINX, например число активных подключений, время работы, информацию о пуле вышестоящих серверов и многое другое. Для бе- глого знакомства с ее консолью посмотрите на рис. 13.1.
Загрузочная страница инструментальной панели состояния дает об- зор всей имеющейся системы. Кликнув по вкладке Server Zones, вы увидите подробную информацию обо всех настроенных в конфигура- ции серверах HTTP с детализацией значений числа откликов от 1XX до 5XX и общее итоговое значение, а также число запросов в секунду и текущую пропускную способность трафика. Вкладка Upstream выводит подробности состояний вышестоящих серверов, а если какие-либо из них пребывают в состоянии отказа, показывает, сколько запросов было обслужено и общее число обслуженных запросов для состояния кода, а также иные статистические данные, например сколько проверок жиз- неспособности были пройдены успешно или завершились провалом. Вкладка TCP/UDP Zones отображает подробности объема трафика, про-
13.3. Сбор метрик с помощью API NGINX Plus v 153
|
См. также:
https://demo . nginx . com/dashboard . html
 |
Рис. 13.1. Инструментальная панель состояния NGINX Plus
13.3. Сбор метрик с помощью API NGINX Plus
Задача
Вам необходим API-доступ для детализации измерений, производи- мых инструментальной панелью состояния NGINX Plus.
Решение
Для сбора метрик воспользуйтесь API RESTful. Вот примеры конвейе- ра, получаемого через json_pp, для более простого прочтения вывода:
$ curl "demo.nginx.com/api/3/" | json_pp [
154 v Глава 13. Расширенный мониторинг активности
|
"slabs",
"http", "stream"
]
Вызов с curl запрашивает самый верхний уровень API, который ото- бражает другие фрагменты API.
Для получения информации о сервере NGINX Plus воспользуйтесь
URI /api/{version}/nginx:
$ curl "demo.nginx.com/api/3/nginx" | json_pp
{
"version" : "1.15.2",
|
"build" : "nginx-plus-r16", "pid" : 77242,
"address" : "206.251.255.64",
"timestamp" : "2018-09-29T23:12:20.525Z",
"load_timestamp" : "2018-09-29T10:00:00.404Z", "generation" : 2
}
Для ограничения информации, возвращаемой API, используйте ар- гументы:
$ curl "demo.nginx.com/api/3/nginx?fields=version,build" \
| json_pp
{
"build" : "nginx-plus-r16",
"version" : "1.15.2"
}
Вы можете запросить статистические данные по соединениям из URI
/api/{version}/connections:
$ curl "demo.nginx.com/api/3/connections" | json_pp
{
13.3. Сбор метрик с помощью API NGINX Plus v 155
|
"idle" : 34,
"dropped" : 0,
"accepted" : 33614951
}
У вас имеется возможность собирать статистику запросов из URI за- просов /api/{version}/http/:
$ curl "demo.nginx.com/api/3/http/requests" | json_pp
{
"total" : 52107833,
"current" : 2
}
|
zones/{httpServerZoneName}:
$ curl "demo.nginx.com/api/3/http/server_zones/hg.nginx.org" \
| json_pp
{
"responses" : {
"1xx" : 0,
"5xx" : 0,
"3xx" : 938,
"4xx" : 341,
"total" : 25245,
"2xx" : 23966
},
"requests" : 25252,
"discarded" : 7,
"received" : 5758103,
"processing" : 0,
"sent" : 359428196
}
Данный API способен предоставлять абсолютно все данные, которые вы видите на инструментальной панели. У него есть глубина, и он сле- дует некому логическому шаблону. Ссылки на ресурсы можно найти в конце данного рецепта.
156 v Глава 13. Расширенный мониторинг активности
Обсуждение
|
См . также : https://nginx.org/en/docs/http/ngx_http_api_module.htmlhttps://demo.nginx.com/swagger-ui/
 |
Глава 14
|
И отслеживания запросов
 |
14.0. Введение
Ведение журналов является основой понимания вашего приложения. Благодаря NGINX вы получаете прекрасный контроль над регистрацией информации, значимой для вас и вашего приложения. NGINX позво- ляет разделять журналы доступа на разные файлы и форматы для раз- ных контекстов и изменять уровень регистрации ошибок, чтобы глубже понять происходящее. Возможность потоковой передачи журналов на централизованный сервер присуща NGINX благодаря возможностям ведения журналов Syslog. В этой главе мы обсудим журналы доступа и ошибок, потоковую передачу по протоколу Syslog и отслеживание запросов от начала до конца с помощью идентификаторов запросов, сгенерированных NGINX.
14.1. Настройка журналов доступа
Задача
Вам необходимо настроить форматы журналов доступа, чтобы доба- вить встроенные переменные в журналы запросов.
158 v Глава 14. Отладка и устранение неполадок с помощью журналов доступа ...
Решение
Настройте формат журнала доступа: 
http {
log_format geoproxy
'[$time_local] $remote_addr ' '$realip_remote_addr $remote_user ' '$request_method $server_protocol ' '$scheme $server_name $uri $status ' '$request_time $body_bytes_sent ' '$geoip_city_country_code3 $geoip_region ' '"$geoip_city" $http_x_forwarded_for ' '$upstream_status $upstream_response_time ' '"$http_referer" "$http_user_agent"';
...
}
|
Эта конфигурация журнала отображает запись, которая выглядит
следующим образом:
[25/Nov/2016:16:20:42 +0000] 10.0.1.16 192.168.0.122 Derek
GET HTTP/1.1 http www.example.com / 200 0.001 370 USA MI
|
"Ann Arbor" - 200 0.001 "-" "curl/7.47.0"
Чтобы взять этот формат журнала, используйте директиву access_log, указав в качестве параметров путь к файлу журнала и имя формата geo- proxy:
server {
access_log /var/log/nginx/access.log geoproxy;
...
}
Директива access_log принимает в качестве параметров путь к файлу журнала и имя формата. Эта директива действительна во многих кон- текстах и в каждом контексте может иметь свой путь к журналу и (или) формату журнала.
|
Модуль журнала в NGINX позволяет настраивать форматы журналов для множества различных сценариев, чтобы выполнять записи в раз- ные файлы журналов по своему усмотрению.
Может оказаться полезным настроить отдельный формат журнала для каждого контекста, где вы используете разные модули и применя- ете встроенные переменные этих модулей, или единый общий формат, предоставляющий всю информацию, которая вам может понадобиться. Также возможно отформатировать журнал в формате JSON или XML. Эти журналы помогут вам понять ваши схемы трафика, использование клиентами, а также кто ваши клиенты и откуда они приходят. Журна- лы доступа также могут помочь вам обнаружить задержки в ответах и проблемы с вышестоящими серверами или определенными URI. Жур- налы доступа могут использоваться для парсинга и воспроизведения шаблонов трафика в тестовых средах для имитации реального взаимо- действия с пользователем. При поиске и устранении неисправностей, отладке или анализе вашего приложения или рынка возможности не- ограничены.
14.3. Отправка журналов в Syslog
Задача
Вам необходимо пересылать свои журналы слушателю Syslog, чтобы объединить их в централизованную службу.
160 v Глава 14. Отладка и устранение неполадок с помощью журналов доступа ...
|
Используйте директивы access_log и error_log для отправки своих жур-
налов слушателю Syslog:
error_log syslog:server=10.0.1.42 debug;
access_log syslog:server=10.0.1.42,tag=nginx,severity=info geoproxy;
|
severity по умолчанию имеет значение info и обозначает серьез-
ность отправляемого сообщения. Флаг nohostname отключает добавле- ние поля имени хоста в заголовок сообщения Syslog и не принимает значения.
Обсуждение
Syslog – это стандартный протокол для отправки сообщений журна- ла и сбора этих журналов на одном сервере или коллекции серверов. Отправка журналов в централизованное расположение помогает при отладке, когда на нескольких хостах запущено несколько экземпляров одной и той же службы. Это называется агрегированием журналов. Агре- гирование журналов позволяет просматривать журналы разом в одном месте без необходимости переходить с сервера на сервер и мысленно объединять файлы журналов по отметке времени. Среди распростра- ненных средств агрегации журналов можно упомянуть ElasticSearch, Logstash и Kibana, также известный как ELK Stack. NGINX упрощает по- токовую передачу этих журналов слушателю Syslog с помощью дирек- тив access_log и error_log.
14.4. Трассировка запросов v 161
14.4. Трассировка запросов
|
Вам необходимо соотнести журналы NGINX с журналами приложе- ний, чтобы иметь полное представление о запросе.
Решение
Используйте идентифицирующую переменную request и передайте ее в свое приложение для регистрации:
|
upstream backend { server 10.0.0.42;
}
server {
listen 80;
add_header X-Request-ID $request_id; # Return to client location / {
proxy_pass http://backend;
proxy_set_header X-Request-ID $request_id; #Pass to app access_log /var/log/nginx/access_trace.log trace;
}
}
В этом примере конфигурации мы установили log_format с именем trace, а в журнале используется переменная $request_id, которая также передается в вышестоящее приложение с помощью директивы proxy_ set_header для добавления идентификатора запроса в заголовок при вы- полнении запроса в восходящем направлении. Идентификатор запроса также передается обратно клиенту с помощью директивы add_header, устанавливающей идентификатор запроса в заголовке ответа.
Обсуждение
Ставшая доступной в NGINX Plus R10 и NGINX версии 1.11.0, пере- менная $request_id предоставляет случайно сгенерированную строку из 32 шестнадцатеричных символов, которые можно использовать для уникальной идентификации запросов. Передав этот идентификатор
162 v Глава 14. Отладка и устранение неполадок с помощью журналов доступа ...
|
 |
Глава 15
| | |||
| | |||
Настройка
Производительности
15.0. Введение
|
15.1. Автоматизация тестов с помощью драйверов нагрузки
Задача
Вам необходимо автоматизировать свои тесты с помощью драйвера нагрузки, чтобы обеспечить согласованность и повторяемость резуль- татов тестирования.
|
Решение
Используйте инструмент нагрузочного тестирования HTTP, такой как Apache JMeter, Locust, Gatling, или любой другой инструмент, на котором стандартизировалась ваша команда. Создайте конфигурацию для своего инструмента нагрузочного тестирования, который запу- скает комплексное тестирование в вашем веб-приложении. Запустите тест для своей службы. Просмотрите показатели, собранные во время прогона, чтобы установить базовый уровень. Медленно увеличивайте эмулированный пользовательский параллелизм, чтобы имитировать типичную реальную эксплуатацию, и определите точки улучшения. На- стройте NGINX и повторяйте этот процесс, пока не добьетесь желаемых результатов.
|
Использование инструмента автоматического тестирования для определения теста дает вам непротиворечивый тест для построения метрик при настройке NGINX. Вы должны быть в состоянии повторить свой тест и измерить прирост производительности или потери для проведения экспериментов. Выполнение теста до внесения каких-либо изменений в конфигурацию NGINX для установления базовой линии дает вам основу для работы, чтобы вы могли оценить, повысило ли из- менение в конфигурации производительность или нет. Измерения всех внесенных изменений помогут вам определить, что улучшает произво- дительность.
15.2. Сохраняем подключения открытыми для клиентов
Задача
Вам необходимо увеличить количество запросов, разрешенных к вы- полнению по одному подключению от клиентов, и количество времени, в течение которого незанятые подключения могут сохраняться.
Решение
Используйте директивы keepalive_requests и keepalive_timeout, чтобы изменить количество запросов, которые можно сделать через одно под- ключение и время, в течение которого незанятые подключения могут оставаться открытыми:
|
http {
keepalive_requests 320; keepalive_timeout 300s;
...
}
По умолчанию директива keepalive_requests имеет значение 100, а ди- ректива keepalive_timeout – 75 секунд.
Обсуждение
|
15.3. Сохраняем подключения открытыми для вышестоящих серверов
Задача
Вам необходимо держать подключения открытыми для вышестоя- щих серверов для повторного использования, чтобы повысить произ- водительность.
Решение
Используйте директиву keepalive в контексте upstream, чтобы подклю- чения были открыты для вышестоящих серверов для повторного ис- пользования:
166 v Глава 15. Настройка производительности
proxy_http_version 1.1; proxy_set_header Connection "";
|
server 10.0.2.56;
keepalive 32;
}
|
Обсуждение
Вы хотите, чтобы соединения оставались открытыми для вышестоя- щих серверов и сэкономили время, необходимое для инициирования подключения, что позволяет рабочему процессу вместо этого перейти непосредственно к выполнению запроса через незанятое подключе- ние. Важно отметить, что количество открытых подключений может превышать количество подключений, указанное в директиве keepalive, поскольку открытые подключения и незанятые подключения – это не одно и то же. Количество подключений keepalive должно быть достаточ- но маленьким, чтобы разрешить другие входящие подключения с вы- шестоящим сервером. Этот маленький трюк с настройкой NGINX может сэкономить циклы и повысить вашу производительность.
15.4. Буферизация ответов
Задача
Вам необходимо выполнить буферизацию ответов между вышестоя- щими серверами и клиентами в памяти, чтобы избежать записи отве- тов во временные файлы.
|
Решение
Настройте параметры прокси-буфера, чтобы позволить NGINX памя- ти буферизовать тела ответов:
server {
proxy_buffering on; proxy_buffer_size 8k; proxy_buffers 8 32k; proxy_busy_buffer_size 64k;
...
}
|
Обсуждение
Прокси-буферы могут значительно улучшить производительность прокси в зависимости от типичного размера тел ответов. Настройка этих параметров может иметь неблагоприятные последствия и должна выполняться путем наблюдения за возвращаемым средним размером тела, а также тщательного и многократного тестирования.
Чрезвычайно большие буферы, установленные, когда они не нужны, мо- гутпоглотитьпамятьвашего NGINX-устройства. Вы можете установитьэти параметры для определенных местоположений, которые, как известно, возвращают большие тела ответа для оптимальной производительности.
15.5. Буферизация журналов доступа
Задача
Вам нужно буферизовать журналы, чтобы уменьшить возможность блоков до рабочего процесса NGINX, когда система находится под на- грузкой.
168 v Глава 15. Настройка производительности
Решение
Установите размер буфера и время сброса ваших журналов доступа:
http {
access_log /var/log/nginx/access.log main buffer=32k flush=1m;
|
Параметр buffer директивы access_log обозначает размер буфера па- мяти, который можно заполнить данными журнала перед записью на диск. Параметр flush директивы access_log устанавливает максимальное время, в течение которого журнал может оставаться в буфере до его записи на диск.
Обсуждение
|
15.6. Настройка ОС
Задача
Вам нужно настроить свою операционную систему так, чтобы она принимала больше подключений для обработки пиковых нагрузок или сайтов с высокой посещаемостью.
Решение
Проверьте настройки ядра для net.core.somaxconn, что является мак- симальным числом подключений, которые ядро может поставить в очередь для обработки NGINX. Если это число выше 512, вам нужно будет задать параметр backlog директивы listen в вашей конфигурации
15.6. Настройка ОС v 169
|
|
Активируйте больше эфемерных портов. Когда NGINX действует как
обратный прокси-сервер или балансировщик нагрузки, каждое восходя- щее соединение открывает временный портдля обратного трафика. В за- висимости от конфигурации вашей системы на сервере может не быть открыто максимальное количество временных портов. Чтобы проверить это, посмотрите настройку ядра net.ipv4.ip_local_port_range. Настрой- ка представляет собой нижнюю и верхнюю границу диапазона портов. Обычно для этого параметра ядра можно установить значение от 1024 до 65535. 1024 – это то место, где останавливаются зарегистрированные TCP-порты, а 65535 – место, где останавливаются динамические или эфе- мерные порты. Имейте в виду, что ваша нижняя граница должна быть выше, чем самый высокий открытый сервисный порт прослушивания.
Обсуждение
Настройка операционной системы – одно из первых мест, куда вы смотрите, когда начинаете настраивать большое количество подключе- ний. Есть много оптимизаций, которые вы можете внести в свое ядро для вашего конкретного случая использования. Однако настройку ядра не следует выполнять по прихоти, и нужно измерять изменения их производительности, чтобы убедиться, что эти изменения помогают. Как указывалось ранее, вы будете знать, когда пора начинать настрой- ку ядра из сообщений, зарегистрированных в журнале ядра, или когда NGINX явно регистрирует сообщение в своем журнале ошибок.
|
Советы по практической эксплуатации и заключение
16.0. Введение
|
16.1. Использование директивы include
Для чистых настроек
Задача
Вам необходимо очистить громоздкие файлы конфигурации, чтобы ваши конфигурации логически группировались в модульные наборы конфигурации.
Решение
Используйте директиву include для ссылки на файлы конфигурации, каталоги или маски:
http {
include config.d/compression.conf; include sites-enabled/*.conf
}
|
Директива include принимает один параметр: либо путь к файлу, либо маску, которая соответствует множеству файлов. Эта директива дейст- вует в любом контексте.
Обсуждение
|
16.2. Отладка конфигураций
Задача
Вы получаете неожиданные результаты от вашего сервера NGINX.
Решение
Выполните отладку конфигурации и запомните эти советы:
• NGINX обрабатывает запросы в поисках наиболее конкретно- го сопоставленного правила. Это делает пошаговое выполнение конфигураций вручную немного сложнее, но это самый эффек- тивный способ для работы NGINX. Подробнее о том, как NGINX
172 v Глава 16. Советы по практической эксплуатации и заключение
обрабатывает запросы, смотрите ссылку на документацию в раз- деле «См. также» на стр. 173;
• можно включить ведение журнала отладки. Для этого вам необхо- димо убедиться, что ваш пакет NGINX настроен с флагом --with- debug. В большинстве распространенных пакетов он есть; но, если вы создали свой собственный или используете минимальный па-
кет, можете, по крайней мере, проверить еще раз. Убедившись, что у вас есть отладка, вы можете установить уровень ведения
журнала директивы error_log на
error.log debug;
error_log /var/log/nginx/
• вы можете активировать отладку для определенных подключе- ний. Директива debug_connection действительна в контексте events и принимает в качестве параметра IP-адрес или диапазон CIDR. Эту директиву можно объявлять более одного раза для добавле- ния нескольких IP-адресов или диапазонов CIDR для отладки. Это может быть полезно для устранения проблемы в реальной эксплуатации без снижения производительности путем отладки всех подключений;
•
|
• можно активировать дампы ядра и получить от них обратную трассировку. Дампы ядра можно привести в действие через опе- рационную систему или файл конфигурации NGINX. Подробнее об этом можно прочитать в руководстве администратора в разде- ле «См. также» на стр. 173;
• Вы можете записывать, что происходит в операторах перезаписи, с помощью включенной директивы rewrite_log: rewrite_log on.
Обсуждение
Платформа NGINX обширна, а ее настройка позволяет вам делать множество удивительных вещей. Тем не менее благодаря способности делать удивительные вещи, также существует возможность навредить самому себе. Выполняя отладку, убедитесь, что вы знаете, как отследить ваш запрос через вашу конфигурацию; и, если у вас есть проблемы, до- бавьте уровень журнала debug, чтобы справиться с ситуацией. Журнал
отладки довольно многословен, но очень полезен, чтобы определить, что NGINX делает с вашим запросом и где в конфигурации вы ошиблись.
См . также : http://nginx.org/en/docs/http/request_processing.html https://docs.nginx.com/nginx/admin-guide/monitoring/debugging/
https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#rewrite_log
16.3. Заключение
В этой книге мы рассказали о высокопроизводительной балансировке нагрузки, безопасности, а также развертывании и обслуживании сер- веров NGINX и NGINX Plus. Мы продемонстрировали некоторые самые мощные функции платформы доставки приложений NGINX. Компания NGINX Inc. продолжает разрабатывать удивительные функции и оста- ется на шаг впереди.
Эта книга продемонстрировала множество коротких рецептов, ко-
|
Сведения об авторе
|
|
| |
Предметный указатель
A
Amazon Web Services 97, 112, 139
Ansible 69, 70, 114
Azure 45, 120, 121, 122, 123, 124, 139
C
Chef 67, 68, 114
D
Docker Hub. 130, 137
G
Google App Engine 126, 127
gRPC 102, 103, 104, 105
H
health_check 34, 35, 37
http_auth_request_module 77, 78, 99
J
JWT 75, 78, 79, 81, 82
K
Kubernetes 128, 137, 138, 139
N
ngx_http_ssl_module 87
ngx_stream_ssl_module 87
P
Packer 114
proxy_cache_bypass 53
proxy_cache_key 52, 53, 56
proxy_cache_path 51, 56
proxy_cache_purge 55
proxy_ssl_certificate 90
proxy_ssl_certificate_key 90
Puppet 65, 66, 114
S
SaltStack 70, 71, 114
secure_link_secret 90, 91, 93
split_clients 39, 40
sticky cookie 28
Б
Балансировка нагрузки 23, 25
Балансировщик сетевой нагрузки 145
Г
Горизонтальное масштабирование 129
М
Медленный запуск 37
Х
Хеширование IP-адреса 28
Ц
Циклический алгоритм 27
Книги издательства «ДМК Пресс» можно заказать в торгово-издательском холдинге
«Планета Альянс» наложенным платежом, выслав открытку или письмо по почтовому адресу: 115487, г . Москва , 2- й Нагатинский пр - д , д . 6 А.
При оформлении заказа следует указать адрес (полностью), по которому должны быть высланы книги; фамилию, имя и отчество получателя. Желательно также указать свой телефон и электронный адрес.
Эти книги вы можете заказать и в интернет-магазине: www.a-planeta.ru.
Оптовые закупки: тел. +7(499) 782-38-89.
Электронный адрес: books@alians-kniga.ru.
Дерек де Йонге
NGINX. Книга рецептов
 |
Продвинутые рецепты высокопроизводительной балансировки нагрузки
Главный редактор Мовчан Д. А.
dmkpress@gmail.com
Перевод с английского Беликов Д. А.
Корректор Чистякова Л. А.
Верстка Паранская Н. В.
Дизайн обложки Мовчан А. Г.
Формат 70×901/16. Печать цифровая.
Усл. печ. л. 12,87. Тираж 200 экз.
Веб-сайт издательства: www.dmkpress.com
Дата добавления: 2021-01-21; просмотров: 131; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!