Настройка производительного веб-сервера на nginx + php-fpm
Содержание:
- Проксирование
- Настройка корневой системы для сайтов
- Nginx Location Related Error Messages
- Создание первого файла server block (виртуального хоста) конфигурации
- Настройка перенаправлений
- Установка NGINX
- Nginx конфигурационный файл
- Server Blocks
- Настройка Nginx на backend-серверах
- Directives, Blocks, and Contexts
- Параметры конфигурационного файла haproxy.cfg
- Шаг 11 — Обслуживание статических файлов с помощью Nginx (необязательно)
- Контекст main
- Nginx Block Configurations
- Summary of Location Modifiers
Проксирование
Проксирование, в отличие от редиректа, не передает инструкции браузеру перейти на другой url — NGINX сам выполняет http-запрос по другому адресу и возвращает готовый ответ. Эта возможность может применяться для внутреннего распределения серверных ресурсов.
Хоть это и не совсем редирект, рассмотрим примеры его настройки, так как очень часто нужно не перенаправление, а, как раз, обратное проксирование.
1. На другой сервер
Пример внутреннего перенаправления http-запроса на другой веб-сервер:
…
location / {
proxy_pass $scheme://192.168.0.15:8080/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
* в данном случае, принимать запросы от браузера и отвечать на них будет NGINX, а сама обработка будет выполняться на сервере с IP-адресом 192.168.0.15 на порту 8080.
Использование NGINX в качестве http-прокси:
server {
…
server_name site1.ru www.site1.ru;
location / {
proxy_pass http://192.168.1.21/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
server {
…
server_name site2.ru www.site2.ru;
location / {
proxy_pass http://192.168.1.22/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
* в данном примере запросы на site1.ru будут перекинуты на сервер 192.168.1.21, а запросы на site2.ru — 192.168.1.22.
HTTP proxy с авторизацией (если удаленный веб-сервер требует аутентификации):
server {
…
location / {
proxy_pass http://10.10.10.10/page/;
proxy_set_header Authorization «Basic dGVzdDp0ZXN0»;
…
}
}
* где 10.10.10.10/page — страница, на которую будут перекинуты запросы; dGVzdDp0ZXN0 — логин:пароль test:test, закодированные в формате base64.
2. Часть url на другой сервер
Выше мы рассмотрели пример перенаправления запроса по части веб-адреса. По схожему сценарию мы можем делать проксирование:
server {
…
location ~ ^/page1/(.*)$ {
proxy_pass $scheme://10.10.10.10/$1;
}
}
* и так, в данном примере при обращении по адресу site.ru/page1/<что-то еще>, nginx сделает внутренний запрос на сервер 10.10.10.10 по адресу 10.10.10.10/<что-то еще> и вернет готовый ответ.
3. На другой сайт
Мы можем сделать так, что при переходе по одному адресу у нас будет открываться совершенно другой сайт:
server {
…
location / {
proxy_pass https://www.dmosk.ru;
proxy_set_header Host www.dmosk.ru;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
* в данном случае мы при обращении к нашему серверу будем попадать на сайт https://www.dmosk.ru
Обратите внимание, что в proxy_set_header мы передаем хосту его имя — в противном случае, как правило, другой сервер вернет ошибку. Также мы не указываем proxy_redirect, иначе, nginx будет переводить запросы на реальный сайт (отправлять инструкции браузеру перейти на него), а не тот, что мы используем за http-прокси
4. Редиректы при проксировании
Если при проксировании хост возвращает инструкцию браузеру для выполнения редиректа, обозреватель может сменить адрес сайта. Это особенно не удобно, когда проксирование мы выполняем на другой сайт. Чтобы отловить редиректы и заменить их своими значениями, мы должны воспользоваться опцией proxy_redirect. Рассмотрим ее применение для предыдущего примера, когда мы проксировали запрос на сайт www.dmosk.ru:
server {
listen 80;
server_name dmosk.local www.dmosk.local;
location / {
proxy_pass https://www.dmosk.ru;
proxy_set_header Host www.dmosk.ru;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect https://www.dmosk.ru/url1 http://dmosk.local/url2;
proxy_redirect https://www.dmosk.ru/ http://dmosk.local/;
}
}
* в конкретном случае мы проксируем запросы http://dmosk.local на сайт www.dmosk.ru, но если он вернет инструкцию для редиректа https://www.dmosk.ru/url1, в браузере он должен быть заменен на http://dmosk.local/url2. А также любое перенаправление для https://www.dmosk.ru/ будет заменено на http://dmosk.local/.
Настройка корневой системы для сайтов
Сделаем удобную корневую систему сайтов таким образом, что каждый каталог соответствует названию сайта.
И все файлы будут храниться в директории «/var/www/название домена/html».
Создадим каталоги для двух доменов: vseprolinux.ru; siteprimer.ru.
Аргумент «-p» говорит, чтобы директории создавались в любом случаи, если даже их не существует.
Права на html
Передадим права на папку html обычному пользователю, таким образом, чтобы мы могли создавать новые элементы, а пользователи сайта — нет.
Для этого будем использовать переменную окружения «$USER», чтобы не вводить имя своего логина.
Права на каталог www.
Nginx Location Related Error Messages
The following are few of the location related error message that you’ll get when you restart Nginx if something is wrong in the location directive.
If you have multiple location directives with the same prefix match, you’ll get the following “duplicate location” error message:
# service nginx start Starting nginx: nginx: duplicate location "/" in /etc/nginx/conf.d/default.conf:45
If you use the “location” in a wrong context. i.e outside the server, then you’ll get the following error message:
# service nginx restart nginx: "location" directive is not allowed here in /etc/nginx/nginx.conf:34 nginx: configuration file /etc/nginx/nginx.conf test failed
You can only use the location modifiers that is allowed by nginx (for example: =). In the following snippet, we are using $ as location modifier which is not allowed by Nginx.
location $ /ab {
root /var/www/html1;
index index.html index.htm;
}
In this case, you’ll receive the following invalid location modifier error message as shown below.
# service nginx restart nginx: invalid location modifier "$" in /etc/nginx/conf.d/default.conf:17 nginx: configuration file /etc/nginx/nginx.conf test failed
Создание первого файла server block (виртуального хоста) конфигурации
В отличие от apache в nginx виртуальные хосты называются server block.
Из коробки на веб-сервере активирован только один виртуальный хост (server block) — «default» . Находится он «/etc/nginx/sites-available/defaul».
Будем использовать его в качестве шаблона для двух сайтов.
Для начала скопируем дефолтный файл в новый веб-сайт.
Отредактируем default.
Немного о параметрах конфига.
listen — указывает на IP-адрес и порт на который программа или сайт будет слушать. Здесь можно указать default_server — тогда этот server block будет использоваться по умолчанию.
Для примера, установим параметр default_server для первого веб-сайта, однако его можно перенести на любой другой веб-сайт или оставить в default.
server_name — доменные имена, на которые будет отзываться сайт. Добавим название веб-сайта с www и без.
root — полный путь к файлам виртуального хоста.
Укажем корневой каталог первого веб-сайта.
Заменим:
На:
Итоговый файл с конфигурацией выглядит так:
Сохраните файл.
На этом первичная настройка первого веб-сайта закончена. Далее переходим ко второму сайту.
Настройка перенаправлений
Настройки необходимо вносить в файлах конфигураций виртуальных доменов. В Linux на основе RPM (CentOS, Red Hat), как правило, они расположены в директории /etc/nginx/conf.d/. В Linux на основе Deb (Ubuntu, Debian) — в директории /etc/nginx/sites-enabled/. Во FreeBSD все в одном файле — /usr/local/etc/nginx/nginx.conf.
Саму настройку на перенаправление в NGINX можно прописать несколькими способами.
1. Первый:
rewrite ^ https://$host$request_uri? <флаг>;
* $host — имя хоста из запроса, если отсутствует — имя в поле «Host» заголовка, если тоже отсутствует — имя сервера; $request_uri — первоначальный запрос с аргументами (все, что идет после доменного имени).
** где флаги могут быть следующие:
- permanent — перенаправление с кодом 301.
- redirect — перенаправить с кодом 302.
- last — закончить обработку с переходом в новый location.
- break — закончить обработку и остаться в текущем location.
2. Второй:
return <код> https://$host$request_uri;
* где коды могут использоваться любые, но чаще всего — 301, 302, 404.
Есть различные мнения, какой из методов лучше и безопаснее, поэтому каким воспользоваться — решать по ситуации. В данных примерах используются оба варианта.
После внесения изменений, необходимо проверить их корректность:
nginx -t
И для их применения перезапустить веб-сервер:
systemctl restart nginx
service nginx restart
* в первом примере перезапуск выполняется на новых системах Linux. Второй пример — на устаревших или FreeBSD.
Проверяя редиректы в браузере, следует учесть, что настройки могут кэшироваться. Для обновления кэша используйте комбинацию Ctrl + F5. Если и это не помогает, закрывайте вкладку и открывайте новую.
Установка NGINX
Для тюнинга установка из пакетов или портов не подходит. Лучше всего выполнять сборку и установку из исходников.
Скачайте последнюю стабильную версию nginx (актуальную ссылку можно посмотреть по адресу http://nginx.org/ru/download.html):
… и с помощью данной ссылки скачиваем исходник.
а) во FreeBSD:
fetch http://nginx.org/download/nginx-1.16.1.tar.gz
б) в Linux:
wget http://nginx.org/download/nginx-1.16.1.tar.gz
* На момент обновления статьи актуальная версия nginx — 1.16.1.
Распакуйте скачанный архив и сразу удалите его, чтобы не мешался:
tar -xvf nginx-*.tar.gz && \rm nginx-*.tar.gz
И перейдите в распакованную директорию:
cd nginx-*
Сконфигурируйте исходники для установки:
а) для FreeBSD:
Сначала устанавливаем пакеты, необходимые для сборки:
pkg install pcre
Приступаем к конфигурированию:
./configure \
—prefix=/usr/local/etc/nginx \
—with-cc-opt=’-I /usr/local/include’ \
—with-ld-opt=’-L /usr/local/lib’ \
—conf-path=/usr/local/etc/nginx/nginx.conf \
—sbin-path=/usr/local/sbin/nginx \
—pid-path=/var/run/nginx.pid \
—error-log-path=/var/log/nginx-error.log \
—user=www \
—group=www \
—http-client-body-temp-path=/var/tmp/nginx/client_body_temp \
—http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp \
—http-proxy-temp-path=/var/tmp/nginx/proxy_temp \
—http-scgi-temp-path=/var/tmp/nginx/scgi_temp \
—http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp \
—http-log-path=/var/log/nginx-access.log \
—with-http_ssl_module \
—with-file-aio \
—with-pcre \
—with-http_stub_status_module \
—without-http_charset_module \
—without-http_ssi_module \
—without-http_userid_module \
—without-http_autoindex_module \
—without-http_geo_module \
—without-http_map_module \
—without-http_split_clients_module \
—without-http_referer_module \
—without-http_empty_gif_module \
—without-http_browser_module \
—without-http_upstream_hash_module \
—without-http_upstream_ip_hash_module \
—without-http_upstream_least_conn_module \
—without-http_upstream_keepalive_module \
—without-mail_pop3_module \
—without-mail_imap_module \
—without-mail_smtp_module
а) для CentOS:
Сначала устанавливаем пакеты, необходимые для сборки:
yum install gcc pcre-devel openssl-devel make
Приступаем к конфигурированию:
./configure \
—prefix=/etc/nginx \
—sbin-path=/usr/sbin/nginx \
—pid-path=/var/run/nginx.pid \
—error-log-path=/var/log/nginx/error.log \
—lock-path=/var/run/nginx.lock \
—user=nginx \
—group=nginx \
—http-log-path=/var/log/nginx-access.log \
—with-http_ssl_module \
—with-file-aio \
—with-pcre \
—with-http_stub_status_module \
—without-http_charset_module \
—without-http_ssi_module \
—without-http_userid_module \
—without-http_autoindex_module \
—without-http_geo_module \
—without-http_map_module \
—without-http_split_clients_module \
—without-http_referer_module \
—without-http_empty_gif_module \
—without-http_browser_module \
—without-http_upstream_hash_module \
—without-http_upstream_ip_hash_module \
—without-http_upstream_least_conn_module \
—without-http_upstream_keepalive_module \
—without-mail_pop3_module \
—without-mail_imap_module \
—without-mail_smtp_module
* Данный список опций подойдет для большинства серверов, но не помешает узнать о всех возможностях при помощи команды ./configure —help
Теперь запустите сборку дистрибутива из исходника:
make
И установите nginx:
make install
Теперь можно запустить и проверить наш веб-сервер.
а) во FreeBSD необходимо разрешить запуск демона nginx:
echo ‘nginx_enable=»YES»‘ >> /etc/rc.conf
service nginx start
б) в CentOS действий больше.
Создаем учетную запись nginx и в качестве владельца каталога для его настроек:
useradd nginx
chown -R nginx:nginx /etc/nginx
Создаем юнит для systemd:
vi /etc/systemd/system/nginx.service
Description=nginx — high performance web server
Documentation=https://nginx.org/en/docs/
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target
Type=forking
PIDFile=/var/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/conf/nginx.conf
ExecStart=/usr/sbin/nginx -c /etc/nginx/conf/nginx.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID
Restart=on-failure
WantedBy=multi-user.target
Применяем изменения в systemd:
systemctl daemon-reload
Разрешаем автозапуск сервиса и стартуем его:
systemctl enable nginx
systemctl start nginx
Nginx конфигурационный файл
Основной конфигурационный файл имеет следующую структуру:
user www-data; worker_processes 4; pid /run/nginx.pid;
events { worker_connections 768; # multi_accept on; }
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
…
}
Для приведенного файла запускается веб-сервер от имени пользователя www-data. Максимальное количество возможных соединений определяется произведением значений worker_processes и worker_connections — каждый воркер может обрабатывать количество соединений, заданное в соответствующей директиве конфига (в примере значение worker_connections равно 768, и задано 4 воркера).
Стандартное для веб-серверов правило — устанавливать количество воркеров в соответствии с количеством ядер процессора для nginx не критично, также значение worker_processes можно устанавливать в auto, но эта настройка актуальна не для всех версий Nginx.
Следующая директива важна для снятия ограничений количества возможных соединений — она находится в блоке events и по-умолчанию закомментирована, чтобы активировать директиву достаточно снять знак комментария и перезапустить Nginx
multi_accept on;
Директивы, задающиеся в разделе конфигурационного файла http
Метод отправки информации
sendfile on;
Указание на необходимость отправки заголовков вместе с данными, что позволит ускорить процесс обработки запросов
tcp_nodelay on;
tcp_nopush on;
Самым важным для быстродействия является включение сжатия — производится обычно также в разделе http
gzip on;
gzip_disable «msie6»;
gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript application/json application/javascript;
При активных директивах будет использоваться GZIP сжатие, что покажет GooglePageSpeedInsights
Логирование подключается директивами в секции http, но может также задаваться и в файлах виртуальных хостов
access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log;
Полностью конфигурационный файл может выглядеть так:
user www-data;worker_processes 4;pid /run/nginx.pid;
events { worker_connections 768; # multi_accept on;}
http {
sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048;
server_names_hash_bucket_size 64;
include /etc/nginx/mime.types; default_type application/octet-stream;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE ssl_prefer_server_ciphers on;
access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log;
gzip on; gzip_disable «msie6»; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*;
}
После внесения изменений в конфигурационный файл необходимо протестировать конфигурацию
Если ошибок в консоль не вывелось — веб-сервер можно перезапускать
Nginx хорош тем, что универсален. Он легко масштабируется и может проксировать запросы на несколько бэкендов отслеживая их доступность. Nginx применяется для почтовых серверов и является универсальным фронтэндом, что позволяет использовать его в распределенных отказоустойчивых системах.
Server Blocks
The block above contains an directive which tells NGINX where website configuration files are located.
-
If you installed from the official NGINX repository, this line will say as it does in the block above. Each website you host with NGINX should have its own configuration file in , with the name formatted as . Sites which are disabled (not being served by NGINX) should be named .
-
If you installed NGINX from the Debian or Ubuntu repositories, this line will say . The folder contains symlinks to the site configuration files stored in . Sites in can be disabled by removing the symlink to .
-
Depending on your installation source, you’ll find an example configuration file at or .
Regardless of the installation source, server configuration files will contain a block (or blocks) for a website. For example:
- /etc/nginx/conf.d/example.com.conf
-
Listening Ports
The directive tells NGINX the hostname/IP and the TCP port where it should listen for HTTP connections. The argument means this virtual host will answer requests on port 80 that don’t specifically match another virtual host’s listen statement. The second statement listens over IPv6 and behaves similarly.
Name-Based Virtual Hosting
The directive allows multiple domains to be served from a single IP address. The server decides which domain to serve based on the request header it receives.
You typically should create one file per domain or site you want to host on your server. Here are some examples:
-
Process requests for both and :
- /etc/nginx/conf.d/example.com.conf
-
-
The directive can also use wildcards. and both instruct the server to process requests for all subdomains of :
- /etc/nginx/conf.d/example.com.conf
-
-
Process requests for all domain names beginning with :
- /etc/nginx/conf.d/example.com.conf
-
NGINX allows you to specify server names that are not valid domain names. NGINX uses the name from the HTTP header to answer requests, regardless of whether the domain name is valid or not.
Using non-domain hostnames is useful if your server is on a LAN, or if you already know all of the clients that will be making requests of the server. This includes front-end proxy servers with entries configured for the IP address on which NGINX is listening.
Настройка Nginx на backend-серверах
Начнем с установки и настройки Nginx на наших веб-серверах, между которыми будет балансировать нагрузка. Установим репозиторий EPEL и собственно сам nginx с помощью yum:
Я выполнял установку сразу на двух серверах, так как сервера настраиваются один в один (для параллельного выполнения команд на нескольких серверах можно использовать pdsh).
Далее в конфигурационных файлах nginx.conf укажем, что сервера должны обрабатывать запросы только с сервера HaProxy и backend-серверов:
1-ый backend-сервер:
server {
listen IP_текущего_сервера:80 default_server;
allow IP_второго_backend_сервера;
allow IP_haproxy;
deny all;
server_name _;
root /usr/share/nginx/html;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
}
2-ой backend-сервер:
server {
listen IP_текущего_сервера:80 default_server;
allow IP_первого_backend_сервера;
allow IP_haproxy;
deny all;
server_name _;
root /usr/share/nginx/html;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
}
Конфиг nginx стандартный, мы лишь добавили в listen IP сервера и закрыли доступ всем, кроме наших серверов с помощью директив allow и deny.
Для работы веб-сервера, нужно открыть соединения на файерволле через firewalld или iptables:
Выполним тестовую проверку на любом из backend-серверов:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> тут вы должны получить html документ
Сервер отдал стандартный index файл nginx, значит между собой сервера взаимодействуют.
Для удобства проверки, я изменил содержимое index файла на каждом backend-сервере, чтобы в процессе тестирования четко видеть в браузере какой сервер обработал запрос.
Index файл nginx расположен в /usr/share/nginx/html/.
Directives, Blocks, and Contexts
All NGINX configuration files are located in the directory. The primary configuration file is .
Configuration options in NGINX are called directives. Directives are organized into groups known as blocks or contexts. The two terms are synonymous.
Lines preceded by a character are comments and not interpreted by NGINX. Lines containing directives must end with a or NGINX will fail to load the configuration and report an error.
Below is a condensed copy of the file that is included with installations from the NGINX repositories. The file starts with 4 directives: , , , and . These are outside any specific block or context, so they’re said to exist in the context. The and blocks are areas for additional directives, and they also exist in the context.
See the NGINX docs for explanations of these directives and others available in the context.
- /etc/nginx/nginx.conf
-
Параметры конфигурационного файла haproxy.cfg
Рассмотрим основные примеры алгоритмов работы HaProxy:
- roundrobin — алгоритм используемый по умолчанию, отправляет запросы на сервера по очереди. В нашем примере мы использовали именно такой метод;
- leastconn – выбирает сервер с наименьшим количеством активных соединений. Рекомендуется применять на проектах, в которых сессии могут быть задействованы продолжительное время;
- source – выбирает сервер по хешу, построенному на основе IP пользователей. В таком режиме работы один и тот же клиент будет обращаться всегда к одному серверу, если его IP остается неизменным;
Пройдем по некоторым параметрам в конфигурационном файле.
Блок global:
- log — вести лог в /dev/log сохраняя в «объект» local0;
- chroot — настройки безопасности, «запирающие» HAProxy в указанной директории;
- maxconn — максимальное количество конкурирующих соединений на один процесс;
- user — пользователь, от имени которого будет запущена программа;
- group — группа пользователя, от имени которого будет запущена программа;
- daemon — запуск процесса как демона.
Блок default. В данном блоке описываются параметры по умолчанию для всех других секций, которые следуют за ней:
- log — указывает, в какой лог вести записи (global в данном случае означает, что используются параметры, заданные в секции global);
- mode — устанавливает протокол взаимодействия, принимает одно из значений: tcp, http или health;
- retries — количество попыток соединения с сервером в случае отказа;
- option httplog — формат лога, в случае использования HAProxy для проксирования HTTP-запросов;
- option redispatch — разрешает программе разорвать и переназначить сессию в случае отказа сервера;
- contimeout — максимальное время ожидания успешного соединения с сервером.
Также есть большое количество параметров связанных с различными timeout.
Шаг 11 — Обслуживание статических файлов с помощью Nginx (необязательно)
Когда Nginx перенаправляет запросы доменов Apache через прокси-сервер, каждый запрос файла этого домена отправляется в Apache. Nginx обслуживает статические файлы, такие как изображения, JavaScript и таблицы стилей, быстрее Apache. Поэтому мы настроим файл виртуального хоста Nginx для прямого обслуживания статических файлов и перенаправления запросов PHP в Apache.
Откройте в своем редакторе файл :
Вам потребуется добавить два дополнительных блока в каждый блок server, а также изменить существующие разделы . Кроме того, вам нужно будет указать Nginx, где можно найти статические файлы для каждого сайта.
Если вы решили не использовать сертификаты SSL и TLS, измените свой файл, чтобы он выглядел следующим образом:
/etc/nginx/sites-available/apache
Если вы также хотите обеспечить доступность HTTPS, используйте следующую конфигурацию:
/etc/nginx/sites-available/apache
Директива указывает Nginx искать файлы в корне документа document root и выводить их напрямую. Если файл имеет расширение , запрос перенаправляется в Apache. Даже если файл отсутствует в document root, запрос перенаправляется в Apache, чтобы функции приложения (например, постоянные ссылки) работали без проблем.
Предупреждение. Директива очень важна, поскольку она не дает Nginx выводить содержимое файлов конфигурации Apache с важными данными, таких как и .
Сохраните файл и проведите тест конфигурации:
Если тест завершается успешно, перезагрузите Nginx:
Чтобы убедиться, что все работает, вы можете просмотреть файлы журнала Apache в каталоге и посмотреть запросы для файлов сайтов и . Используйте команду для просмотра последних нескольких строк файла и параметр для просмотра изменений файла:
Теперь откройте в браузере и посмотрите на результаты вывода журнала. Вы увидите ответ Apache:
Затем откройте страницы каждого сайта, и вы не увидите записи журнала Apache. Их обслуживает Nginx.
Завершив изучение файла журнала, нажмите чтобы остановить отслеживание.
При такой настройке Apache не сможет ограничивать доступ к статическим файлам. Контроль доступа к статическим файлам должен быть настроен в файле виртуального хоста Nginx, однако это не входит в содержание настоящего обучающего руководства.
Контекст main
Укажем пользователя от имени которого будет работать сервер. При установке сервера был создан пользователь nginx, он и будет основным пользователем.
# Пользователь user nginx;
Определим число worker_processes или другими словами, рабочих процессов. Число процессов должно равняться числу процессорных ядер, хотя для последних версий nginx данный параметр рекомендуют устанавливать в значение auto. Поскольку на моем недорогом VPS/VDS сервере доступно одно ядро, то я устанавливаю значение равное единице.
# Количество рабочих процессов worker_processes 1;
Также зададим приоритет рабочих процессов, это нужно для того, чтобы при сильной нагрузке сервер сразу не упал мог продолжать обрабатывать запросы клиентов. Значения могут варьироваться от -20 до 20, причем чем больше будет отрицательное значение, тем больше будет приоритет процесса.
# Приоритет рабочих процессов worker_priority -5;
Указываем местонахождение pid-файла и лог-файла ошибок. Отмечаться будут только ошибки критического уровня, другими словами фиксация ошибок практически прекращается, в логах будут только события связанные со стартом или перезагрузкой сервера. Чем меньше производится записей в лог-файлы, тем меньше нагрузка на сервер.
# Pid-файл и error_log файл сервера pid /var/run/nginx.pid; error_log /var/log/nginx/error.log crit;
Nginx Block Configurations
Nginx logically divides the configurations meant to serve different content into blocks, which live in a hierarchical structure. Each time a client request is made, Nginx begins a process of determining which configuration blocks should be used to handle the request. This decision process is what we will be discussing in this guide.
The main blocks that we will be discussing are the server block and the location block.
A server block is a subset of Nginx’s configuration that defines a virtual server used to handle requests of a defined type. Administrators often configure multiple server blocks and decide which block should handle which connection based on the requested domain name, port, and IP address.
A location block lives within a server block and is used to define how Nginx should handle requests for different resources and URIs for the parent server. The URI space can be subdivided in whatever way the administrator likes using these blocks. It is an extremely flexible model.
Summary of Location Modifiers
To put things in perspective, the following lists most of the above discussed location examples:
The following = is for exact match. For example: thegeekstuff.com/
location = / {
}
The following without any modifier is for / followed by anything. For example: thegeekstuff.com/contact.html
location / {
}
The following is for /db. For example: thegeekstuff.com/db/index.html
location /db/ {
}
The following is for best prefix match without Reg-Ex. For example: thegeekstuff.com/images/logo.gif
location ^~ /images/ {
}
The following is for regular expression match. For example: thegeekstuff.com/db/mysql.jpg
location ~* .(png|gif|ico|jpg|jpeg)$ {
}
