Руководство для начинающих
В этом руководстве даётся начальное введение в nginx и описываются некоторые простые задачи, которые могут быть решены с его помощью. Предполагается, что nginx уже установлен на компьютере читателя. Если нет, см. Установка nginx. В этом руководстве описывается, как запустить и остановить nginx и перезагрузить его конфигурацию, объясняется, как устроен конфигурационный файл, и описывается, как настроить nginx для раздачи статического содержимого, как настроить прокси-сервер на nginx, и как связать nginx с приложением FastCGI.
У nginx есть один главный и несколько рабочих процессов. Основная задача главного процесса — чтение и проверка конфигурации и управление рабочими процессами. Рабочие процессы выполняют фактическую обработку запросов. nginx использует модель, основанную на событиях, и зависящие от операционной системы механизмы для эффективного распределения запросов между рабочими процессами. Количество рабочих процессов задаётся в конфигурационном файле и может быть фиксированным для данной конфигурации или автоматически устанавливаться равным числу доступных процессорных ядер (см. worker_processes).
Как работают nginx и его модули, определяется в конфигурационном файле. По умолчанию, конфигурационный файл называется nginx.conf и расположен в каталоге /usr/local/nginx/conf , /etc/nginx или /usr/local/etc/nginx .
Запуск, остановка, перезагрузка конфигурации
Чтобы запустить nginx, нужно выполнить исполняемый файл. Когда nginx запущен, им можно управлять, вызывая исполняемый файл с параметром -s . Используйте следующий синтаксис:
Где сигнал может быть одним из нижеследующих:
- stop — быстрое завершение
- quit — плавное завершение
- reload — перезагрузка конфигурационного файла
- reopen — переоткрытие лог-файлов
Например, чтобы остановить процессы nginx с ожиданием окончания обслуживания текущих запросов рабочими процессами, можно выполнить следующую команду:
Команда должна быть выполнена под тем же пользователем, под которым был запущен nginx.
Изменения, сделанные в конфигурационном файле, не будут применены, пока команда перезагрузить конфигурацию не будет вручную отправлена nginx’у или он не будет перезапущен. Для перезагрузки конфигурации выполните:
Получив сигнал, главный процесс проверяет правильность синтаксиса нового конфигурационного файла и пытается применить конфигурацию, содержащуюся в нём. Если это ему удаётся, главный процесс запускает новые рабочие процессы и отправляет сообщения старым рабочим процессам с требованием завершиться. В противном случае, главный процесс откатывает изменения и продолжает работать со старой конфигурацией. Старые рабочие процессы, получив команду завершиться, прекращают принимать новые запросы и продолжают обслуживать текущие запросы до тех пор, пока все такие запросы не будут обслужены. После этого старые рабочие процессы завершаются.
Посылать сигналы процессам nginx можно также средствами Unix, такими как утилита kill . В этом случае сигнал отправляется напрямую процессу с данным ID. ID главного процесса nginx записывается по умолчанию в файл nginx.pid в каталоге /usr/local/nginx/logs или /var/run . Например, если ID главного процесса равен 1628, для отправки сигнала QUIT, который приведёт к плавному завершению nginx, нужно выполнить:
Для просмотра списка всех запущенных процессов nginx может быть использована утилита ps , например, следующим образом:
Дополнительную информацию об отправке сигналов процессам nginx можно найти в Управление nginx.
Структура конфигурационного файла
nginx состоит из модулей, которые настраиваются директивами, указанными в конфигурационном файле. Директивы делятся на простые и блочные. Простая директива состоит из имени и параметров, разделённых пробелами, и оканчивается точкой с запятой ( ; ). Блочная директива устроена так же, как и простая директива, но вместо точки с запятой после имени и параметров следует набор дополнительных инструкций, помещённых внутри фигурных скобок ( < и >). Если у блочной директивы внутри фигурных скобок можно задавать другие директивы, то она называется контекстом (примеры: events, http, server и location).
Директивы, помещённые в конфигурационном файле вне любого контекста, считаются находящимися в контексте main. Директивы events и http располагаются в контексте main , server — в http , а location — в server .
Часть строки после символа # считается комментарием.
Раздача статического содержимого
Одна из важных задач конфигурации nginx — раздача файлов, таких как изображения или статические HTML-страницы. Рассмотрим пример, в котором в зависимости от запроса файлы будут раздаваться из разных локальных каталогов: /data/www , который содержит HTML-файлы, и /data/images , содержащий файлы с изображениями. Для этого потребуется отредактировать конфигурационный файл и настроить блок server внутри блока http с двумя блоками location.
Во-первых, создайте каталог /data/www и положите в него файл index.html с любым текстовым содержанием, а также создайте каталог /data/images и положите в него несколько файлов с изображениями.
Далее, откройте конфигурационный файл. Конфигурационный файл по умолчанию уже включает в себя несколько примеров блока server , большей частью закомментированных. Для нашей текущей задачи лучше закомментировать все такие блоки и добавить новый блок server :
В общем случае конфигурационный файл может содержать несколько блоков server , различаемых по портам, на которых они слушают, и по имени сервера. Определив, какой server будет обрабатывать запрос, nginx сравнивает URI, указанный в заголовке запроса, с параметрами директив location , определённых внутри блока server .
В блок server добавьте блок location следующего вида:
Этот блок location задаёт “ / ” в качестве префикса, который сравнивается с URI из запроса. Для подходящих запросов добавлением URI к пути, указанному в директиве root, то есть, в данном случае, к /data/www , получается путь к запрашиваемому файлу в локальной файловой системе. Если есть совпадение с несколькими блоками location , nginx выбирает блок с самым длинным префиксом. В блоке location выше указан самый короткий префикс, длины один, и поэтому этот блок будет использован, только если не будет совпадения ни с одним из остальных блоков location .
Далее, добавьте второй блок location :
Он будет давать совпадение с запросами, начинающимися с /images/ ( location / для них тоже подходит, но указанный там префикс короче).
Итоговая конфигурация блока server должна выглядеть следующим образом:
Это уже работающая конфигурация сервера, слушающего на стандартном порту 80 и доступного на локальном компьютере по адресу http://localhost/ . В ответ на запросы, URI которых начинаются с /images/ , сервер будет отправлять файлы из каталога /data/images . Например, на запрос http://localhost/images/example.png nginx отправит в ответ файл /data/images/example.png . Если же этот файл не существует, nginx отправит ответ, указывающий на ошибку 404. Запросы, URI которых не начинаются на /images/ , будут отображены на каталог /data/www . Например, в результате запроса http://localhost/some/example.html в ответ будет отправлен файл /data/www/some/example.html .
Чтобы применить новую конфигурацию, запустите nginx, если он ещё не запущен, или отправьте сигнал reload главному процессу nginx, выполнив:
В случае если что-то работает не как ожидалось, можно попытаться выяснить причину с помощью файлов access.log и error.log из каталога /usr/local/nginx/logs или /var/log/nginx .
Настройка простого прокси-сервера
Одним из частых применений nginx является использование его в качестве прокси-сервера, то есть сервера, который принимает запросы, перенаправляет их на проксируемые сервера, получает ответы от них и отправляет их клиенту.
Мы настроим базовый прокси-сервер, который будет обслуживать запросы изображений из локального каталога и отправлять все остальные запросы на проксируемый сервер. В этом примере оба сервера будут работать в рамках одного экземпляра nginx.
Во-первых, создайте проксируемый сервер, добавив ещё один блок server в конфигурационный файл nginx со следующим содержимым:
Это будет простой сервер, слушающий на порту 8080 (ранее директива listen не указывалась, потому что использовался стандартный порт 80) и отображающий все запросы на каталог /data/up1 в локальной файловой системе. Создайте этот каталог и положите в него файл index.html . Обратите внимание, что директива root помещена в контекст server . Такая директива root будет использована, когда директива location , выбранная для выполнения запроса, не содержит собственной директивы root .
Далее, используйте конфигурацию сервера из предыдущего раздела и видоизмените её, превратив в конфигурацию прокси-сервера. В первый блок location добавьте директиву proxy_pass, указав протокол, имя и порт проксируемого сервера в качестве параметра (в нашем случае это http://localhost:8080 ):
Мы изменим второй блок location , который на данный момент отображает запросы с префиксом /images/ на файлы из каталога /data/images так, чтобы он подходил для запросов изображений с типичными расширениями файлов. Изменённый блок location выглядит следующим образом:
Параметром является регулярное выражение, дающее совпадение со всеми URI, оканчивающимися на .gif , .jpg или .png . Регулярному выражению должен предшествовать символ
. Соответствующие запросы будут отображены на каталог /data/images .
Когда nginx выбирает блок location , который будет обслуживать запрос, то вначале он проверяет директивы location, задающие префиксы, запоминая location с самым длинным подходящим префиксом, а затем проверяет регулярные выражения. Если есть совпадение с регулярным выражением, nginx выбирает соответствующий location , в противном случае берётся запомненный ранее location .
Итоговая конфигурация прокси-сервера выглядит следующим образом:
Этот сервер будет фильтровать запросы, оканчивающиеся на .gif , .jpg или .png , и отображать их на каталог /data/images (добавлением URI к параметру директивы root ) и перенаправлять все остальные запросы на проксируемый сервер, сконфигурированный выше.
Чтобы применить новую конфигурацию, отправьте сигнал reload nginx’у, как описывалось в предыдущих разделах.
Существует множество других директив для дальнейшей настройки прокси-соединения.
Настройка проксирования FastCGI
nginx можно использовать для перенаправления запросов на FastCGI-серверы. На них могут исполняться приложения, созданные с использованием разнообразных фреймворков и языков программирования, например, PHP.
Базовая конфигурация nginx для работы с проксируемым FastCGI-сервером включает в себя использование директивы fastcgi_pass вместо директивы proxy_pass , и директив fastcgi_param для настройки параметров, передаваемых FastCGI-серверу. Представьте, что FastCGI-сервер доступен по адресу localhost:9000 . Взяв за основу конфигурацию прокси-сервера из предыдущего раздела, замените директиву proxy_pass на директиву fastcgi_pass и измените параметр на localhost:9000 . В PHP параметр SCRIPT_FILENAME используется для определения имени скрипта, а в параметре QUERY_STRING передаются параметры запроса. Получится следующая конфигурация:
Таким образом будет настроен сервер, который будет перенаправлять все запросы, кроме запросов статических изображений, на проксируемый сервер, работающий по адресу localhost:9000 , по протоколу FastCGI.
Источник
Сборка nginx из исходных файлов
Сборка настраивается командой configure . Она определяет особенности системы и, в частности, методы, которые nginx может использовать для обработки соединений. В конце концов она создаёт Makefile .
Команда configure поддерживает следующие параметры:
—help печатает справочное сообщение.
—prefix= путь задаёт каталог, в котором будут находиться файлы сервера. Этот же каталог будет использоваться для всех относительных путей, задаваемых configure (кроме путей к исходным текстам библиотек) и в конфигурационном файле nginx.conf . По умолчанию — каталог /usr/local/nginx . —sbin-path= путь задаёт имя исполняемого файла nginx. Это имя используется только на стадии установки. По умолчанию файл называется префикс /sbin/nginx . —modules-path= путь задаёт каталог, в который будут устанавливаться динамические модули. По умолчанию используется каталог префикс /modules . —conf-path= путь задаёт имя конфигурационного файла nginx.conf . При желании nginx можно всегда запустить с другим конфигурационным файлом, указав его в параметре командной строки . По умолчанию файл называется префикс /conf/nginx.conf . —error-log-path= путь задаёт имя основного файла ошибок, предупреждений и диагностики. После установки имя файла можно всегда поменять в конфигурационном файле nginx.conf с помощью директивы error_log. По умолчанию имя файла — префикс /logs/error.log . —pid-path= путь задаёт имя файла nginx.pid , в котором будет храниться номер главного процесса. После установки имя файла можно всегда поменять в конфигурационном файле nginx.conf с помощью директивы pid. По умолчанию имя файла — префикс /logs/nginx.pid . —lock-path= путь задаёт префикс имён файлов блокировок. После установки значение можно всегда поменять в конфигурационном файле nginx.conf с помощью директивы lock_file. По умолчанию используется значение префикс /logs/nginx.lock .
—user= имя задаёт имя непривилегированного пользователя, с правами которого будут выполняться рабочие процессы. После установки это имя можно всегда поменять в конфигурационном файле nginx.conf с помощью директивы user. По умолчанию имя пользователя nobody. —group= имя задаёт имя группы, с правами которой будут выполняться рабочие процессы. После установки это имя можно всегда поменять в конфигурационном файле nginx.conf с помощью директивы user. По умолчанию группа совпадает с именем непривилегированного пользователя.
—build= имя задаёт необязательное имя сборки nginx. —builddir= путь задаёт каталог для сборки.
—with-select_module
—without-select_module разрешает или запрещает сборку модуля для работы сервера с помощью метода select() . Этот модуль собирается автоматически, если на платформе не обнаружено более подходящего метода — kqueue, epoll или /dev/poll. —with-poll_module
—without-poll_module разрешает или запрещает сборку модуля для работы сервера с помощью метода poll() . Этот модуль собирается автоматически, если на платформе не обнаружено более подходящего метода — kqueue, epoll или /dev/poll. —with-threads разрешает использование пулов потоков. —with-file-aio разрешает использование файлового асинхронного ввода-вывода (AIO) во FreeBSD и Linux.
—with-http_ssl_module разрешает сборку модуля для работы HTTP-сервера по протоколу HTTPS. По умолчанию модуль не собирается. Для сборки и работы этого модуля нужна библиотека OpenSSL. —with-http_v2_module разрешает сборку модуля для работы HTTP-сервера по протоколу HTTP/2. По умолчанию модуль не собирается. —with-http_realip_module разрешает сборку модуля ngx_http_realip_module, позволяющего менять адрес клиента на переданный в указанном поле заголовка. По умолчанию модуль не собирается. —with-http_addition_module разрешает сборку модуля ngx_http_addition_module, позволяющего добавлять текст до и после ответа. По умолчанию модуль не собирается. —with-http_xslt_module
—with-http_xslt_module=dynamic разрешает сборку модуля ngx_http_xslt_module, позволяющего преобразовывать XML-ответ с помощью XSLT-шаблонов. По умолчанию модуль не собирается. Для сборки и работы этого модуля нужны библиотеки libxml2 и libxslt. —with-http_image_filter_module
—with-http_image_filter_module=dynamic разрешает сборку модуля ngx_http_image_filter_module, позволяющего преобразовывать изображения в форматах JPEG, GIF, PNG и WebP. По умолчанию модуль не собирается. —with-http_geoip_module
—with-http_geoip_module=dynamic разрешает сборку модуля ngx_http_geoip_module, создающего переменные, значения которых зависят от IP-адреса клиента, используя готовые базы данных MaxMind. По умолчанию модуль не собирается. —with-http_sub_module разрешает сборку модуля ngx_http_sub_module, позволяющего изменять в ответе одну заданную строку на другую. По умолчанию модуль не собирается. —with-http_dav_module разрешает сборку модуля ngx_http_dav_module, предназначенного для автоматизации задач управления файлами на сервере по протоколу WebDAV. По умолчанию модуль не собирается. —with-http_flv_module разрешает сборку модуля ngx_http_flv_module, обеспечивающего серверную поддержку псевдо-стриминга для файлов Flash Video (FLV). По умолчанию модуль не собирается. —with-http_mp4_module разрешает сборку модуля ngx_http_mp4_module, обеспечивающего серверную поддержку псевдо-стриминга для файлов в формате MP4. По умолчанию модуль не собирается. —with-http_gunzip_module разрешает сборку модуля ngx_http_gunzip_module, позволяющего распаковывать ответы с “ Content-Encoding: gzip ” для тех клиентов, которые не поддерживают метод сжатия “gzip”. По умолчанию модуль не собирается. —with-http_gzip_static_module разрешает сборку модуля ngx_http_gzip_static_module, позволяющего отдавать вместо обычного файла предварительно сжатый файл с таким же именем и с расширением “ .gz ”. По умолчанию модуль не собирается. —with-http_auth_request_module разрешает сборку модуля ngx_http_auth_request_module, предоставляющего возможность авторизации клиента, основанной на результате подзапроса. По умолчанию модуль не собирается. —with-http_random_index_module разрешает сборку модуля ngx_http_random_index_module, обслуживающего запросы, оканчивающиеся слэшом (‘ / ’), и выдающего случайный файл в качестве индексного файла каталога. По умолчанию модуль не собирается. —with-http_secure_link_module разрешает сборку модуля ngx_http_secure_link_module. По умолчанию модуль не собирается. —with-http_degradation_module разрешает сборку модуля ngx_http_degradation_module . По умолчанию модуль не собирается. —with-http_slice_module разрешает сборку модуля ngx_http_slice_module, позволяющего разбить запрос на подзапросы, каждый из которых возвращает определённый диапазон ответа. Модуль обеспечивает более эффективное кэширование больших ответов. По умолчанию модуль не собирается. —with-http_stub_status_module разрешает сборку модуля ngx_http_stub_status_module, предоставляющего доступ к базовой информации о состоянии сервера. По умолчанию модуль не собирается.
—without-http_charset_module запрещает сборку модуля ngx_http_charset_module, позволяющего добавлять указанную кодировку в поле “Content-Type” заголовка ответа и перекодировать данные из одной кодировки в другую. —without-http_gzip_module запрещает сборку модуля сжатия ответов HTTP-сервера. Для сборки и работы этого модуля нужна библиотека zlib. —without-http_ssi_module запрещает сборку модуля ngx_http_ssi_module, обрабатывающего команды SSI (Server Side Includes) в проходящих через него ответах. —without-http_userid_module запрещает сборку модуля ngx_http_userid_module, выдающего куки для идентификации клиентов. —without-http_access_module запрещает сборку модуля ngx_http_access_module, позволяющего ограничить доступ для определённых адресов клиентов. —without-http_auth_basic_module запрещает сборку модуля ngx_http_auth_basic_module, позволяющего ограничить доступ к ресурсам с проверкой имени и пароля пользователя по протоколу “HTTP Basic Authentication”. —without-http_mirror_module запрещает сборку модуля ngx_http_mirror_module, позволяющего зеркалировать исходный запрос при помощи создания фоновых зеркалирующих подзапросов. —without-http_autoindex_module запрещает сборку модуля ngx_http_autoindex_module, обслуживающего запросы, оканчивающиеся слэшом (‘ / ’), и выдающего листинг каталога, когда модуль ngx_http_index_module не нашёл индексный файл. —without-http_geo_module запрещает сборку модуля ngx_http_geo_module, позволяющего создавать переменные, значения которых зависят от IP-адреса клиента. —without-http_map_module запрещает сборку модуля ngx_http_map_module, позволяющего создавать переменные, значения которых зависят от значений других переменных. —without-http_split_clients_module запрещает сборку модуля ngx_http_split_clients_module, позволяющего создавать переменные для A/B тестирования. —without-http_referer_module запрещает сборку модуля ngx_http_referer_module, позволяющего блокировать доступ к сайту для запросов с неверными значениями поля “Referer” в заголовке. —without-http_rewrite_module запрещает сборку модуля HTTP-сервера, позволяющего делать перенаправления и менять URI запросов. Для сборки и работы этого модуля нужна библиотека PCRE. —without-http_proxy_module запрещает сборку проксирующего модуля HTTP-сервера. —without-http_fastcgi_module запрещает сборку модуля ngx_http_fastcgi_module, позволяющего передавать запросы FastCGI-серверу. —without-http_uwsgi_module запрещает сборку модуля ngx_http_uwsgi_module, позволяющего передавать запросы uwsgi-серверу. —without-http_scgi_module запрещает сборку модуля ngx_http_scgi_module, позволяющего передавать запросы SCGI-серверу. —without-http_grpc_module запрещает сборку модуля ngx_http_grpc_module, позволяющего передавать запросы gRPC-серверу. —without-http_memcached_module запрещает сборку модуля ngx_http_memcached_module, позволяющего получать ответы из сервера memcached. —without-http_limit_conn_module запрещает сборку модуля ngx_http_limit_conn_module, позволяющего ограничить число соединений по заданному ключу, в частности, число соединений с одного IP-адреса. —without-http_limit_req_module запрещает сборку модуля ngx_http_limit_req_module, позволяющего ограничить скорость обработки запросов по заданному ключу или, как частный случай, скорость обработки запросов, поступающих с одного IP-адреса. —without-http_empty_gif_module запрещает сборку модуля, выдающего однопиксельный прозрачный GIF. —without-http_browser_module запрещает сборку модуля ngx_http_browser_module, создающего переменные, значения которых зависят от значения поля “User-Agent” в заголовке запроса. —without-http_upstream_hash_module запрещает сборку модуля, реализующего метод балансировки нагрузки hash. —without-http_upstream_ip_hash_module запрещает сборку модуля, реализующего метод балансировки нагрузки ip_hash. —without-http_upstream_least_conn_module запрещает сборку модуля, реализующего метод балансировки нагрузки least_conn. —without-http_upstream_random_module запрещает сборку модуля, реализующего метод балансировки нагрузки random. —without-http_upstream_keepalive_module запрещает сборку модуля, реализующего кэширование соединений к вышестоящим серверам. —without-http_upstream_zone_module запрещает сборку модуля, позволяющего сохранять рабочее состояние группы вышестоящих серверов в разделяемой памяти.
—with-http_perl_module
—with-http_perl_module=dynamic разрешает сборку модуля, добавляющего встроенный Perl. По умолчанию модуль не собирается. —with-perl_modules_path= путь задаёт каталог, в котором будут находиться файлы модулей Perl. —with-perl= путь задаёт имя исполняемого файла Perl.
—http-log-path= путь задаёт имя основного файла регистрации запросов HTTP-сервера. После установки имя файла можно всегда поменять в конфигурационном файле nginx.conf с помощью директивы access_log. По умолчанию имя файла — префикс /logs/access.log . —http-client-body-temp-path= путь задаёт каталог для хранения временных файлов с телами запросов клиентов. После установки имя файла можно всегда поменять в конфигурационном файле nginx.conf с помощью директивы client_body_temp_path. По умолчанию используется каталог префикс /client_body_temp . —http-proxy-temp-path= путь задаёт каталог для хранения временных файлов с данными, полученными от проксируемых серверов. После установки имя файла можно всегда поменять в конфигурационном файле nginx.conf с помощью директивы proxy_temp_path. По умолчанию используется каталог префикс /proxy_temp . —http-fastcgi-temp-path= путь задаёт каталог для хранения временных файлов с данными, полученными от FastCGI-серверов. После установки имя файла можно всегда поменять в конфигурационном файле nginx.conf с помощью директивы fastcgi_temp_path. По умолчанию используется каталог префикс /fastcgi_temp . —http-uwsgi-temp-path= путь задаёт каталог для хранения временных файлов с данными, полученными от uwsgi-серверов. После установки имя файла можно всегда поменять в конфигурационном файле nginx.conf с помощью директивы uwsgi_temp_path. По умолчанию используется каталог префикс /uwsgi_temp . —http-scgi-temp-path= путь задаёт каталог для хранения временных файлов с данными, полученными от SCGI-серверов. После установки имя файла можно всегда поменять в конфигурационном файле nginx.conf с помощью директивы scgi_temp_path. По умолчанию используется каталог префикс /scgi_temp .
—without-http запрещает HTTP-сервер. —without-http-cache запрещает HTTP-кэш.
—with-mail
—with-mail=dynamic разрешает POP3/IMAP4/SMTP почтовый прокси-сервер. —with-mail_ssl_module разрешает сборку модуля для работы почтового прокси-сервера по протоколу SSL/TLS. По умолчанию модуль не собирается. Для сборки и работы этого модуля нужна библиотека OpenSSL. —without-mail_pop3_module запрещает протокол POP3 в почтовом прокси-сервере. —without-mail_imap_module запрещает протокол IMAP в почтовом прокси-сервере. —without-mail_smtp_module запрещает протокол SMTP в почтовом прокси-сервере.
—with-stream
—with-stream=dynamic разрешает сборку модуля stream для TCP/UDP-проксирования и балансировки. По умолчанию модуль не собирается. —with-stream_ssl_module разрешает сборку модуля для работы модуля stream по протоколу SSL/TLS. По умолчанию модуль не собирается. Для сборки и работы этого модуля нужна библиотека OpenSSL. —with-stream_realip_module разрешает сборку модуля ngx_stream_realip_module, позволяющего менять адрес клиента на переданный в заголовке протокола PROXY. По умолчанию модуль не собирается. —with-stream_geoip_module
—with-stream_geoip_module=dynamic разрешает сборку модуля ngx_stream_geoip_module, создающего переменные, значения которых зависят от IP-адреса клиента, используя готовые базы данных MaxMind. По умолчанию модуль не собирается. —with-stream_ssl_preread_module разрешает сборку модуля ngx_stream_ssl_preread_module, позволяющего извлекать информацию из сообщения ClientHello без терминирования SSL/TLS. По умолчанию модуль не собирается. —without-stream_limit_conn_module запрещает сборку модуля ngx_stream_limit_conn_module, позволяющего ограничить число соединений по заданному ключу, в частности, число соединений с одного IP-адреса. —without-stream_access_module запрещает сборку модуля ngx_stream_access_module, позволяющего ограничить доступ для определённых адресов клиентов. —without-stream_geo_module запрещает сборку модуля ngx_stream_geo_module, позволяющего создавать переменные, значения которых зависят от IP-адреса клиента. —without-stream_map_module запрещает сборку модуля ngx_stream_map_module, позволяющего создавать переменные, значения которых зависят от значений других переменных. —without-stream_split_clients_module запрещает сборку модуля ngx_stream_split_clients_module, позволяющего создавать переменные для A/B тестирования. —without-stream_return_module запрещает сборку модуля ngx_stream_return_module, позволяющего отправить заданное значение клиенту и после этого закрыть соединение. —without-stream_set_module запрещает сборку модуля ngx_stream_set_module, позволяющего устанавливать значение переменной. —without-stream_upstream_hash_module запрещает сборку модуля, реализующего метод балансировки нагрузки hash. —without-stream_upstream_least_conn_module запрещает сборку модуля, реализующего метод балансировки нагрузки least_conn. —without-stream_upstream_random_module запрещает сборку модуля, реализующего метод балансировки нагрузки random. —without-stream_upstream_zone_module запрещает сборку модуля, позволяющего сохранять рабочее состояние группы вышестоящих серверов в разделяемой памяти.
—with-google_perftools_module разрешает сборку модуля ngx_google_perftools_module, обеспечивающего поддержку профилирования рабочих процессов nginx при помощи Google Performance Tools. Модуль предназначен для разработчиков nginx и не собирается по умолчанию. —with-cpp_test_module разрешает сборку модуля ngx_cpp_test_module .
—add-module= путь разрешает сборку внешнего модуля. —add-dynamic-module= путь разрешает сборку внешнего динамического модуля.
—with-compat включает режим совместимости с динамическими модулями.
—with-cc= путь задаёт компилятор, который будет использоваться при сборке. —with-cpp= путь задаёт препроцессор, который будет использоваться при сборке. —with-cc-opt= параметры задаёт дополнительные параметры, которые будут добавлены к переменной CFLAGS. При использовании системной библиотеки PCRE во FreeBSD, нужно указать —with-cc-opt=»-I /usr/local/include» . Если нужно увеличить число файлов, с которыми может работать select() , то это тоже можно задать здесь же: —with-cc-opt=»-D FD_SETSIZE=2048″ . —with-ld-opt= параметры задаёт дополнительные параметры, которые будут использованы при линковке. При использовании системной библиотеки PCRE во FreeBSD, нужно указать —with-ld-opt=»-L /usr/local/lib» . —with-cpu-opt= cpu разрешает сборку для одного из следующих процессоров: pentium , pentiumpro , pentium3 , pentium4 , athlon , opteron , sparc32 , sparc64 , ppc64 .
—without-pcre запрещает использование библиотеки PCRE. —with-pcre разрешает использование библиотеки PCRE. —with-pcre= путь задаёт путь к исходным текстам библиотеки PCRE. Дистрибутив библиотеки (версию 4.4 — 8.43) нужно взять на сайте PCRE и распаковать. Всё остальное сделают ./configure nginx’а и make . Библиотека нужна для использования регулярных выражений в директиве location и для модуля ngx_http_rewrite_module. —with-pcre-opt= параметры задаёт дополнительные параметры сборки PCRE. —with-pcre-jit собирает библиотеку PCRE с поддержкой JIT-компиляции (1.1.12, директива pcre_jit).
—with-zlib= путь задаёт путь к исходным текстам библиотеки zlib. Дистрибутив библиотеки (версию 1.1.3 — 1.2.11) нужно взять на сайте zlib и распаковать. Всё остальное сделают ./configure nginx’а и make . Библиотека нужна для модуля ngx_http_gzip_module. —with-zlib-opt= параметры задаёт дополнительные параметры сборки zlib. —with-zlib-asm= cpu разрешает использование при сборке библиотеки zlib ассемблерных вставок, оптимизированных для одного из следующих процессоров: pentium , pentiumpro .
—with-libatomic разрешает сборку с библиотекой libatomic_ops. —with-libatomic= путь задаёт путь к исходным текстам библиотеки libatomic_ops.
—with-openssl= путь задаёт путь к исходным текстам библиотеки OpenSSL. —with-openssl-opt= параметры задаёт дополнительные параметры сборки OpenSSL.
Пример использования параметров (всё это нужно набрать в одной строке):
После конфигурации nginx компилируется и устанавливается с помощью make .
Источник
