Ubuntu установка php fpm. О герое дня

Nginx является одним из самых популярных веб-серверов в мире, его используют для хостинга самых больших и нагруженных сайтов в Интернете. Nginx в подавляющем большинстве случаев менее требователен к ресурсам, чем Apache; его можно использовать как в качестве веб-сервера, так и в качестве обратного прокси-сервера (reverse proxy).

В этой статье мы рассмотрим процесс установки Nginx на ваш сервер с Ubuntu 16.04.

Перед установкой

Перед тем, как начать следовать описанным в этой статье шагам, убедитесь, что у вас есть обычный не-рутовый (non-root) пользователь с привилегиями sudo . Узнать, как настроить такого пользователя на вашем сервере, можно из .

После того, как вы создали такого пользователя, зайдите на сервер используя его логин и пароль. Теперь вы готовы следовать шагам, описанным в этой статье.

Шаг 1: Установка веб-сервера Nginx

Nginx доступен в стандартных репозиториях Ubuntu, поэтому его установка достаточно проста.

Поскольку мы собираемся использовать apt в первый раз в ходе этой сессии, начнём с обновления локального списка пакетов. Далее установим сервер:

  • sudo apt-get update
  • sudo apt-get install nginx

В результате выполнения этих команд apt-get установит Nginx и другие необходимые для его работы пакеты на ваш сервер.

Шаг 2: Настройка файрвола

Перед тем, как начать проверять работу Nginx, нам необходимо настроить наш файрвол для разрешения доступа к сервису. При установки Nginx регистрируется в сервисе файрвола ufw . Поэтому настройка доступа осуществляется достаточно просто.

Для вывода настроек доступа для приложений, зарегистрированных в ufw , введём команду:

  • sudo ufw app list

В результате выполнения этой команды будет выведен список профилей приложений:

Available applications: Nginx Full Nginx HTTP Nginx HTTPS OpenSSH

Как видно из этого вывода, для Nginx настроено три профиля:

  • Nginx Full : этот профиль открывает порты 80 (обычный, не шифрованный веб-трафик) и 443 (трафик шифруется с помощью TLS/SSL).
  • Nginx HTTP : этот профиль открывает только порт 80 (обычный, не шифрованный веб-трафик).
  • Nginx HTTPS : этот профиль открывает только порт 443 (трафик шифруется с помощью TLS/SSL).

Рекомендуется настраивать ufw таким образом, чтобы разрешать только тот трафик, который вы хотите разрешить в явном виде. Поскольку мы ещё не настроили SSL для нашего сервера, в этой статье мы разрешим трафик только для порта 80.

Сделать это можно следующей командой:

  • sudo ufw allow "Nginx HTTP"

Вы можете проверить изменения введя команду:

  • sudo ufw status

В результате должен отобразиться вывод следующего вида:

Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx HTTP ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx HTTP (v6) ALLOW Anywhere (v6)

Шаг 3: Проверка работы веб-сервера

После завершения процесса установки Ubuntu 16.04 запустит Nginx автоматически. Таким образом веб-сервер уже должен быть запущен.

Мы можем убедиться в этом выполнив следующую команду:

  • systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2016-04-18 16:14:00 EDT; 4min 2s ago Main PID: 12857 (nginx) CGroup: /system.slice/nginx.service ├─12857 nginx: master process /usr/sbin/nginx -g daemon on; master_process on └─12858 nginx: worker process

Как видно из вывода выше, сервис запущен и работает. Тем не менее, убедимся в его полной работоспособности путём запроса веб-страницы.

Для этого мы можем проверить, отображается ли веб-страница Nginx, доступная по умолчанию при вводе доменного имени или IP адреса сервера.

Если вы не хотите настраивать доменное имя для вашего сервера, вы можете использовать публичный IP адрес вашего сервера. Если вы не знаете публичного IP адреса сервера, вы можете найти этот IP адрес следующей командой:

  • ip addr show eth0 | grep inet | awk "{ print $2; }" | sed "s/\/.*$//"

В результате будет выведено несколько IP адресов. Попробуйте вставить каждый из них в браузер.

Другим способом определить свой IP адрес будет проверка, как ваш сервер виден из Интернета:

  • sudo apt-get install curl
  • curl -4 icanhazip.com

Наберите полученный IP адрес или доменное имя в вашем веб-браузере. Вы должны увидеть страницу Nginx по умолчанию.

Http://доменное_имя_или_IP_адрес

Если вы видите подобную страницу в своём браузере, вы успешно установили Nginx.

Шаг 4: Управление процессом Nginx

Теперь, когда Nginx установлен и мы убедились в его работоспособности, ознакомимся с некоторыми базовыми командам для управления нашим веб-сервером.

Для остановки веб-сервера используйте команду:

  • sudo systemctl stop nginx

Для запуска остановленного веб-сервера наберите:

  • sudo systemctl start nginx

Для перезапуска веб-сервера можно использовать следующую команду:

  • sudo systemctl restart nginx

Если вы вносите изменения в конфигурацию Nginx, часто можно перезапустить его без закрытия соединений. Для этого можно использовать следующую команду:

  • sudo systemctl reload nginx

По умолчанию Nginx настроен на автоматический запуск при запуске сервера. Если такое поведение веб-сервера вам не нужно, вы можете отключить его следующей командой:

  • sudo systemctl disable nginx

Для повторного включения запуска Nginx при старте сервера введите:

  • sudo systemctl enable nginx

Шаг 5: Важные файлы и директории Nginx

Теперь, когда мы знаем основные команды для управления веб-сервером, ознакомимся с основными директориями и файлами.

Контент

  • /var/www/html: веб-контент, который по умолчанию состоит только из тестовой страницы Nginx, которую мы видели ранее, находится в директории /var/www/html . Путь к этой директории можно настроить в файлах конфигурации Nginx.

Конфигурация сервера

  • /etc/nginx: директория конфигурации Nginx. Все файлы конфигурации Nginx находятся в этой директории.
  • /etc/nginx/nginx.conf: основной файл конфигурации Nginx. Этот файл используется для внесения изменений в глобальную конфигурацию Nginx.
  • /etc/nginx/sites-available: директория, в которой хранятся "серверные блоки" для каждого сайта (серверные блоки являются приблизительным аналогом виртуальных хостов в Apache). Nginx не будет использовать конфигурационные файлы в этой директории, если они не имеют соответствующих ссылок в директории sites-enabled (см. ниже). Обычно все настройки серверного блока осуществляются в этой директории, а затем сайт активируется путём создания ссылки в другой директории.
  • /etc/nginx/sites-enabled/ : в этой директории хранятся серверные блоки для активированных сайтов. Обычно это достигается путём создания ссылок на конфигурационные профили сайтов, расположенные в директории sites-available .
  • /etc/nginx/snippets: в этой директории хранятся фрагменты конфигурации, которые можно использовать при конфигурации любых сайтов. Фрагменты конфигурации, которые потенциально могут быть использованы в нескольких файлах конфигурации, являются прекрасными кандидатами для создания этих сниппетов.

Логи сервера

  • /var/log/nginx/access.log: каждый запрос к вашему веб-серверу записывается в этот файл лога, если иное не задано настройками Nginx.
  • /var/log/nginx/error.log: любые ошибки Nginx будут записываться в этот файл.

Заключение

Теперь, когда у вас есть установленный и настроенный веб-сервер, вы можете выбирать, какой контент отдавать пользователям, и какие другие технологии вы можете использовать в дополнение к веб-серверу.

Связка nginx, php-fpm, php-apc позволяет ускорить работу сайта при правильной настройке по сравнению с apache и снизить нагрузку на сервер. Особенно это актуально при настройке работы сайтов с большим количеством посещений. Это сочетание компонентов в последнее время становится все более популярным, но настройка при этом достаточно несложная и делается быстро. Давайте посмотрим пример настройки на Debian’e. Настроим nginx с кэшем + php-fpm + php-apc.

Для начала вспомним, что это за компоненты. Nginx — это быстрый и гибкий веб-сервер, который к тому же позволяет использовать кеширование. Php-fpm — это PHP FastCGI Process Manager, менеджер процессов FastCGI для PHP. FastCGI — это бинарный протокол клиент-серверного взаимодействия, позволяющий обрабатывать запросы многопоточно, в отличие от однопоточного CGI. А php-apc — это Alternative PHP Cache, свободный фреймворк для кеширования байт-кода PHP в памяти, что в разы может ускорить выполнение PHP, при неоднократном использовании кода, естественно. Таким образом, ускорение должно быть в нескольких местах. Первое — кэш nginx’а, второе — более быстрая отдача статики при помощи nginx’а по сравнению с apache, третье — кэширование байт-кода PHP, четвертое — более быстрое исполнение кода php при помощи php-fpm по сравнению со связкой apache + mod_php5.

Установка пакетов

Устанавливаем пакеты:

Apt-get install nginx php5-fpm php-apc php5-mysql

Всё необходимое установится по зависимостям

Настройка nginx

После установки пакетов необходимо задать настройки для nginx. Создаем файл настроек nginx для нашего сайта, назовем его «site»

Touch /etc/nginx/sites-available/site

В файл запишем следующее:

Server { # Слушаем 80 порт по IPv4 listen 0.0.0.0:80; # Название сайта (доменное имя) server_name site; # Индексный файл index index.php; # Корневая директория сайта root /var/www/site; # Запрещаем доступ к файлам.htaccess и.htpasswd location ~ /\.ht { deny all; } # Отдача статики location ~ \.(jpg|jpeg|ico|gif|css){ # Отключаем записи об отдаче статических файлов # Это поможет снизить количество операций записи на диск access_log off; expires max; root /var/www/site; } location ~ \.php { include /etc/nginx/fastcgi_params; fastcgi_pass unix:/var/run/php-fpm-site; fastcgi_index index.php; # Включаем кэш nginx, подключаем зону my-cache proxy_cache my-cache; # Таймауты хранения страниц в кэше в зависимости # от ответа сервера. 200 и 302 - 60 минут, 404 - 1 минута proxy_cache_valid 200 302 60m; proxy_cache_valid 404 1m; # Директория для временного хранения proxy_temp_path /var/cache/nginx/tmp; } }

Ln -s /etc/nginx/sites-available/site /etc/nginx/sites-enabled

В файл /etc/nginx/nginx.conf надо добавить кэш, который мы уже записали для использования. В начало секции http вставляем следующую строчку:

Proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my-cache:8m max_size=128m inactive=600m;

Эта строчка означает следующее: директория для хранения кэша — /var/cache/nginx. levels — уровни кэширования 1:2, это уровни вложенности директорий в директории для хранения кэша. Параметр keys_zone определяет название и объем зоны кэша (зон может быть несколько). Зона размером 1 мегабайт может хранить 8000 ключей. Параметр max_size определяет максимальный объем кэша, когда кэш достигнет этого объема, то старые файлы из кэша будут удаляться, чтобы освободить место. Если данные не будут запрошены из кэша в течение времени, указанного в параметре inactive (в нашем случае 600 минут), то они будут удалены из кэша. Если параметр inactive не указан, по умолчанию время составляет 10 минут.

Настройка php-fpm

Настройки php-fpm находятся в директории /etc/php5/fpm. В этой директории есть поддиректория pool.d, в которой хранятся файлы для работы с сайтами. Нам нужно создать файл для нашего сайта. Назовем его site.conf

Touch /etc/php5/fpm/pool.d/site.conf

В этот файл записываем следующее:

# Сокет-файл для обмена данными с nginx listen = /var/run/php-fpm-site.sock # Максимально доступное в системе количество соединений listen.backlog = -1 # Владелец сокета и группа владения listen.owner = www-data listen.group = www-data # Права, устанавливаемые при создании сокета listen.mode = 660 user = www-data group = www-data # Количество процессов будет контролироваться динамически pm = dynamic pm.max_children = 30 pm.start_servers = 2 pm.min_spare_servers = 2 pm.max_spare_servers = 5 pm.max_requests = 50 env = site env = /usr/local/bin:/usr/bin:/bin env = /tmp env = /tmp env = /tmp

Теперь можно запускать php-fpm командой

Service php5-fpm start

И после этого так же запустить nginx

Service nginx start

Давайте создадим директорию /var/www/site, если она еще не создана:

Mkdir -p /var/www/site

А в этой директории создадим файл /var/www/site/index.php со следующим содержимым:

Теперь в браузере откроем наш сервер по доменному имени. Например, «http://site». Должна открыться страница с информацией о сервере. Там же перечислены все модули, которые используются. В этом списке должен присутствовать модуль apc, и его статус должен быть «Enabled».

Настройка php-apc

Конфигурационный файл apc находится по следующему пути: /etc/php/fpm/conf.d/20-apc.ini

В принципе, с настройками по умолчанию этот модуль уже можно использовать, но если хотите настроить его более тонко, то описание всех параметров можно посмотреть .

В целом конфигурация готова, можно разворачивать сайт и настраивать все эти компоненты более детально, в зависимости от того, как устроен сайт и какая статистика будет накоплена в процессе его работы.

Классической связкой для работы сайтов написанных на php считается apache + mod_php. Так как mod_php по умолчанию требует prefork_mpm, то apache для обработки каждого отдельного соединения создает отдельный процесс, что сильно не экономно с точки зрения расходования оперативной памяти.

Потом появился nginx - легковесный проксирующий веб-сервер и его начали ставить перед apache чтобы он занимался выдачей статики и не беспокоил apache по мелочам. Следующим логичным шагом является выключение из цепочки nginx - apache - php посредника в лице apache, чем мы и займемся.

php-fpm позволяет демонизировать php дабы избежать затрат на запуск процессов (чем страдает CGI) что умеет и FastCGI. Но php-fpm дает также другие полезные возможности:

  • запуск пулов обработчиков от имени заданных пользователей,
  • динамическое управление количеством запущенных обработчиков,
  • возможность перезапуска обработчиков в случае, если с ними что-то не так,
  • ведение лога медленных запросов по аналогии с mysql,
  • страницы статуса и пинга,
  • прочее.

Установка php-fpm в Debian крайне проста:

Aptitude install php5-fpm

После чего можно править два конфигурационных файла, которые достаточно хорошо документированы сами по себе, но большое количество слов может также мешать найти за ними суть. Первый (/etc/php5/fpm/php-fpm.conf) позволяет задать общие настройки:

include - из какой директории инклудить дополнительные конфиги,
pid - путь до файла с идентификатором процесса,
error_log - путь до лога ошибок,
syslog.facility - позволяет указать в какой лог писать,
syslog.ident - каким именем помечать записи в системном логе,
log_level - уровень лога от алерта до дебага,

В принципе указанные выше параметры можно оставить по умолчанию, если не требуется дебаг, к примеру. Дальше более интересные параметры:

emergency_restart_threshold - позволяет задать при каком количестве вылетов процессов с сигналами SIGSEGV или SIGBUS за указанный промежуток времени необходимо мягко перезапустить php-fpm,
emergency_restart_interval - заданный промежуток времени.
process_control_timeout - как долго потомкам ждать от мастера реакции на сигналы,
process.max - максимальное количество процессов для всех пулов,
process.priority - можно указать приоритет мастер-процесса,
daemonize - демонизировать или нет. Может пригодиться для дебага,
rlimit_files - количество доступных для мастер-процесса файловых дескрипторов,
rlimit_core - не осознал,
events.mechanism - в linux однозначно epoll,
systemd_interval - если ваша ос использует systemd, то можно задать периодичность отчетов о состоянии процессов. Будет актуально в Debian 8.

Второй конфиг является базовым для настройки пулов и находится по пути /etc/php5/fpm/pool.d/www.conf. В этом файле можно задать еще больше параметров и все они хорошо документированы в нем. Мы же удалим или переименуем этот файл и создадим свой конфигурационный файл.

Интересно, что в конфиге пула можно использовать имя пула в виде переменной $pool . За счет этого можно создать унифицированный конфигурационный файл и использовать его в качестве основы для новых пулов. Имя пула задается в квадратный скобках и предваряет собой блок параметров. Фактически все пулы можно описать в одном файле, но, кажется, так делать не стоит. Пример конфигурационного файла:


prefix = /var/www/$pool

user = $pool
group = $pool

listen = /var/run/phpfpm-$pool.sock
listen.owner = $pool
listen.group = www-data
listen.mode = 0660

pm = dynamic
pm.max_children = 16
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4

pm.status_path = /fpmstat

request_slowlog_timeout = 3s
slowlog = /var/www/logs/$pool.slow.log

При необходимости:

access.log = /var/www/logs/$pool.access.log

Разберем параметры:

prefix - позволяет задать путь по умолчанию, который может использоваться в параметрах slowlog, listen, chroot, chdir, php_values, php_admin_values.
user и group - задает владельца и группу запускаемых процессов.
listen - указывает на каком сокете слушать. Поддерживаются как UNIX, так и TCP-сокеты. В случае, если веб-сервер и php-обработчики находятся на одном сервере, то лучше использовать UNIX-сокеты, так как это потенциально быстрее, так как нет оверхеда связанного с генерацией пакетов.
listen.owner, listen.group, listen.mode - позволяют задать параметры доступа к сокету. В качестве владельца указано имя совпадающее с именем пула. Необходимо создать соответствующего пользователя и убедиться, что для него нет ssh-доступа, конечно, если у вас не виртуальный хостинг. Группа указана www-data вследствие того, что под ней работает nginx и необходимо предоставить ему доступ к файлу сокета. Закрыть доступ остальным позволяют права 660.
pm - указывает как менеджер процессов будет управлять количеством дочерних процессов. Может быть статическим (постоянное количество процессов), динамическим (количество процессов может варьироваться в заданных пределах) и по требованию (когда нужно процесс запускается и убивается по истечении таймаута).
pm.max_children - максимальное количество дочерних процессов.
pm.start_servers - сколько процессов запускается при запуске php-fpm.
pm.min_spare_servers - минимальное количество ожидающих процессов. Если процессов меньше, чем значение параметра, то новые процессы будут созданы.
pm.max_spare_servers - максимальное количество ожидающих процессов. Если ожидающих процессов больше, чем значение параметра, то лишние процессы будут убиты.
pm.status_path - путь к странице статуса.
request_slowlog_timeout - время по прошествии которого запрос считается медленным.
slowlog - путь до файла лога медленных запросов.
access.log - путь до файла с логом доступа.

Другие интересные параметры:

pm.max_requests - количество обработанных запросов после которых процесс нужно перезапустить. Позволяет бороться с утечками памяти.
process.priority - задает приоритет процессов данного пула.
chroot - позволяет зачрутить процессы в указанную директорию. Однако все пути используемые php будут действовать относительно указанной директории, что требует дополнительной настройки.
security.limit_extensions - позволяет указать список расширений файлов для обработки php-fpm.

Также можно переопределять переменные окружения, к примеру:

и переопределять параметры из php.ini почти как это делается в.htaccess:

php_flag = off

То есть мы можем настраивать множество параметров php индивидуально для каждого пула.

Кстати говоря, для изменения параметров php можно использовать в директории сайта.

Реализация

Материал выше изложен как-то сумбурно. Попробуем посмотреть конкретный простой пример реализации.

Исходим из того, что nginx и php-fpm у вас уже установлены.

Теперь вам необходимо настроить виртуальный хост в nginx так чтобы запросы к статике обрабатывал сам nginx, а запросы к php-скриптам передавал на обработку php-fpm. Пример:

server {
listen 80;
server_name webpanels.spb.ru;

root /var/www/webpanels;
index index.php;

location ~ \.php$ {
try_files $uri =404;

fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

include fastcgi_params;
}

location ~ ^/(fpmstat|ping)$ {
access_log off;
allow 127.0.0.1;
allow 123.123.123.123; #your-ip
deny all;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /fpmstat;
fastcgi_pass unix:/var/run/phpfpm-webpanels.sock;
}

location ~* ^.+.(html|jpg|jpeg|gif|css|png|js|ico|txt)$ {
expires 60d;
}
}

Здесь указано куда перенаправлять запросы. В нашем случае используется unix-сокет. Также указываем индексный файл и путь до файла. Как видно, все довольно просто. Данный пример можно использовать как формулу.

Теперь настроим php-fpm. В Debian общие настройки находятся в файле /etc/php5/fpm/php-fpm.conf:

pid = /var/run/php5-fpm.pid
error_log = /var/log/php5-fpm.log
process.max = 64
process.priority = -5
rlimit_files = 1024
events.mechanism = epoll
include=/etc/php5/fpm/pool.d/*.conf

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

Пример настройки пула был дан выше. Стоит напомнить, что каждый пул запускается от отдельного пользователя, которого можно создать командой вида:

Useradd -m -d /var/www/webpanels -s /usr/sbin/nologin -c "webpanels site" -U webpanels

Кроме того, говорят, что для нормальной работы в файле /etc/php5/fpm/php.ini должен быть установлен следующий параметры:

cgi.fix_pathinfo = 0

Так же из-за отказа от Apache может понадобится сконвертировать правила mod_rewrite в правила понятные для nginx. Сделать это можно, к примеру, с помощью конвертеров доступных по адресам:

На данный момент самую большую популярность набрали два веб-сервера. Это Apache и Ngnix. У каждого из них есть свои плюсы и минусы. Apache был разработан еще в 1995 году и при его разработке учитывались не все возможные потребности пользователей, он потребляет много памяти и ресурсов системы, зато он прост в настройке. Nginx был разработан чуть позже в 2002 году уже учитывая ошибки Apache и ориентируясь на максимальную производительность.

Мы не будем подробно вникать в плюсы и минусы этих обоих веб-серверов. У каждого из них своя область применения. В этой инструкции будет рассмотрена установка Nginx Ubuntu 16.04. Хотя я буду говорить об Ubuntu 16.04, все действия подойдут и для других дистрибутивов. Настройка Nginx везде одинакова, только команда установки отличается.

Первым делом нужно установить сам веб-сервер в систему. Программа есть в официальных репозиториях, но ее версия уже немного устарела, поэтому если хотите самую новую версию, нужно добавить PPA:

sudo apt-add-repository ppa:nginx/stable

Сейчас в официальных репозиториях доступна версия 1.10.0, а в стабильной PPA уже доступна 1.10.1. Если для вас версия не нужна можно обойтись и без PPA. Дальше обновите списки пакетов из репозиториев:

И устанавливаем ngnix:

sudo apt install nginx

После того как установка сервера Nginx будет завершена добавим программу в автозагрузку, чтобы она запускалась автоматически:

sudo systemctl enable nginx

Если вы уже сейчас откроете браузер, то увидите работающий nginx, но нам предстоит его еще настроить.

Настройка Nginx Ubuntu

Настройка Nginx Ubuntu намного сложнее чем Apache. Здесь мы не будем рассматривать все опции и возможности программы, а поговорим только об основном. Есть различные конфигурации, в которых Nginx используется в качестве прокси сервера, а основной сервер Apache, но нас это интересовать не будет. Нам нужна установка Nginx как самостоятельного веб-сервера.

Настройки Nginx сильно отличаются здесь есть только один основной файл конфигурации и файлы для виртуальных хостов. Настройка из каждой директории, как в Apache не поддерживается.

  • /etc/nginx/nginx.conf - главный файл конфигурации
  • /etc/nginx/sites-available/* - файлы конфигурации для виртуальных хостов, проще говоря для каждого сайта.
  • /etc/nginx/sites-enabled/* - файлы конфигурации активированных сайтов.

На самом деле файлы конфигурации для виртуальных хостов читаются только из директории sites-enabled, но здесь содержаться ссылки на sites-available. Такая система была придумана, чтобы дать возможность отключать на время те или иные сайты, не стирая их конфигурацию. Все остальные файлы содержат только объявления переменных и стандартные настройки, которые изменять не нужно. Что же касается nginx.conf, то в него включаются все файлы из sites-enables, а поэтому они могут содержать все точно такие же инструкции. А теперь давайте рассмотрим главный файл конфигурации:

sudo vi /etc/nginx/nginx.conf

Как видите файл разделен на секции. Общая структура такова:

глобальные опции
events {}
http{
server {
location{}
}
server {}
}
mail {}

  • глобальные опции отвечают за работу всей программы.
  • events - эта секция содержит настройки для работы с сетью.
  • http - содержит настройки веб-сервера. Должна содержать секцию servier для тонкой настройки каждого сайта.
  • server - в этой секции содержится настройка каждого размещенного на веб-сервере сайта.
  • location - секция location может находиться только внутри секции server и содержит настройки только для определенного запроса.
  • mail - содержит настройки почтового прокси.

Перед тем как перейти к опциям, нужно сказать еще пару слов о синтаксисе строки в конфигурационном файле. Он выглядит вот так:

параметр значение дополнительное_значение... ;

Строка должна обязательно заканчиваться ";", а все открытые скобки { должны быть закрыты.

Теперь, когда вы немного изучили глобальную структуру, можно переходить к рассмотрению самих параметров. Глобальных опций не так уж много:

  • user - пользователь, от имени которого будет работать программа.
  • worker_processes - устанавливает сколько процессов нужно запускать для параллелизации работы программы, нужно запускать не больше процессов, чем у вас есть ядер. Можно установить параметр auto и тогда программа определит это число сама.
  • pid = файл pid программы.
  • worker_rlimit_nofile - указывает максимальное количество файлов, которые может открыть программа. Рассчитывается как worker_processes * worker_connections* 2.

С глобальными опциями закончили, их было не так много и они не такие интереснее. Куда интереснее в плане оптимизации опции с секции events:

  • worker_connections - количество соединений, которые программа может обрабатывать одновременно на одном процессе. Если умножить worker_process на этот параметр, то мы получим максимальное количество пользователей, которые могут подключиться к серверу одновременно. Рекомендуется устанавливать значение от 1024 до 4048.
  • multi_accept - разрешить принимать много подключений одновременно, установите параметр on или off.
  • use - способ работы с сетевым стеком. По умолчанию используется poll, но для Linux эффективнее использовать epoll.
  • sendfile - использовать метод отправки данных sendfile. Значение on.
  • tcp_nodelay, tcp_nopush - отправлять заголовки и начало файла одним пакетом. Значение on.
  • keepalive_timeout - таймаут ожидания, перед тем как keepalive соединение будет разорвано, по умолчанию 65, но можно уменьшить до 10 секунд.
  • keepalive_requests - максимальное количество keepalive соединений от одного клиента, рекомендовано 100.
  • reset_timedout_connection - разрывать соединения после таймаута. Значение on.
  • open_file_cache - кэшировать информацию об открытых файлах. Строчка настройки выглядит вот так: open_file_cache max=200000 inactive=20s; max - максимальное количество файлов в кэше, время кэширования.
  • open_file_cache_valid - указывает по истечении какого времени нужно удалить информацию из кэша. Например: open_file_cache_valid 30s;
  • open_file_cache_min_uses - кэшировать информацию о файлах, которые были открыты как минимум указанное количество раз.
  • open_file_cache_errors - кэшировать информацию об отсутствующих файлах, значение on.

Основные параметры рассмотрели. Эти настройки помогут вам получить большую производительность от nginx. Секцию server и location мы рассмотрим в настройке виртуальных хостов.

Настройка сжатия Gzip

Сжатие контента необходимо, чтобы уменьшить размер загружаемых браузером данных. Это ускоряет загрузку сайта, но добавляет дополнительную нагрузку на процессор сервера. Чтобы включить сжатие в секции http нужно добавить параметр:

Эту директиву можно использовать также в секции server, тогда она будет работать только для указного виртуального домена. Дальше настраиваем параметры сжатия настраиваются с помощью следующих опций:

  • gzip_min_length - минимальная длина страницы в байтах, при которой нужно использовать сжатие, например, 1000 (1 кб)
  • gzip_proxied - нужно ли сжимать проксированые запросы, any говорит, что нужно сжимать все.
  • gzip_types - типы файлов, которые нужно сжимать, например: text/plain application/xml application/x-javascript text/javascript text/css text/json;
  • gzip_disable "msie6" - в IE 6 сжатие не поддерживается, поэтому отключаем.
  • gzip_comp_level - уровень сжатия, доступны варианты от 1 до 10. 1 - минимальное, 10 - максимальное сжатие.

Настройка виртуальных хостов

Как вы знаете, на сервере может размещаться несколько сайтов. Все запросы приходят на ip сервера, а nginx уже определяет на основе домена какой контент нужно выдать. Для того чтобы nginx знал что к какому домену относится нужно настроить виртуальные хосты. Каждый хост принято размещать в отдельном файле. Настройка хоста находится в секции server, но поскольку все файлы из sites-enabled импортируются в секцию http, то логика структуры конфигурационного файла не нарушается.

Рассмотрим пример настройки:

vi /etc/nginx/sites-enabled/сайт.conf

  • listen 80 - указывает, что нужно ожидать подключения на порту 80, может также содержать опцию default-server , которая означает, что этот домен будет открывается если домен не был задан в запросе.
  • root /var/www/html - директория, в которой находятся файлы сайта.
  • index index.html - страница, которая будет открываться по умолчанию.
  • server_name - доменное имя сайта.
  • access_log - файл для записи лога запросов к серверу, может использоваться как глобально в секции http, так и для определенного типа файлов в location.
  • error_log - лог ошибок веб-сервера, может принимать дополнительный параметр, указывающий подробность лога. warn - максимум, crit - только критические ошибки.

Это все основные настройки виртуального хоста, после них он уже будет работать. Но тут есть еще секция location, которая позволяет настроить поведение сервера для определенных директорий и файлов. Синтаксис location такой:

location адрес {}

В качестве адреса может использоваться как прямой запрос относительно корня сервера, так и регулярные выражения. Для использования регулярных выражений перед ним ставится символ "~". Примеры рассмотрим ниже, а пока рассмотрим возможные директивы:

  • allow - разрешить доступ к местоположению для пользователей, all - всех, также можно указать ip или подсеть.
  • deny - запретить доступ к местоположению, all - для всех.
  • try-files - пытается открыть файлы в определенном порядке, открывает первый обнаруженный файл. Например, такая конструкция: $uri $uri/index.html $uri.html =404; сначала пытается открыть $uri, затем index.html, если не найден $uri.html, и аж потом, если ни одного из предложных файлов не существует, выдает ошибку 404.
  • expires - задает время кэширования браузером отданного элемента, например, 1d - один день, 2h - два часа, 30s - 30 секунд.

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

Не выполнять логирование для favicon:

location = /favicon.ico {
log_not_found off;
access_log off;
}

Запретить доступ к файлам, начинающимся с точки:

location ~ /\. {
deny all;
}

Кэшировать обычные файлы на 90 дней:

location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
access_log off; log_not_found off; expires 90d;

Здравствуй, уважаемый пользователь Хабрахабра. Мое повествование будет о том, как подготовить почву для локальной веб-разработки проектов в операционной системе Ubuntu 16.04.1 LTS.

В данной статье хочется развеять и разъяснить возможные трудности связанные с установкой и настройкой ПО, которое требуется для современной веб-разработки, с которыми возможно сталкиваются начинающие разработчики и не только.

Технологии которые будут использованы в статье: nginx, php-fpm.

Перед началом повествования, хочу отметить, что я проделывал все эти действия на «голой» системе.
Я буду работать с пакетным менеджером aptitude. Так же рекомендую обновить индекс пакетов и сами пакеты перед установкой ПО. В статье мы проделаем эти действия вместе.

Поехали!

Установка пакетного менеджера aptitude , обновление индекса и пакетов

Устанавливаем:

Sudo apt install aptitude
Обновляем индекс.

Sudo aptitude update
Обновляем пакеты (команда обновит все пакеты, для которых есть новые версии, если потребуется удаление пакетов, то оно будет выполнено).

Sudo aptitude full-upgrade

Установка и настройка nginx (версия >= 1.10.0)

Устанавливаем.

Sudo aptitude install nginx
Запускаем.

Sudo service nginx start
Проверяем версию, чтобы убедиться что не установили старую, то есть ниже 1.10.0.

Установку и запуск произвели, теперь пойдем в каталог туда куда установлен наш nginx и посмотрим на его структуру. Каталог nginx находится по такому пути:

Cd /etc/nginx/
Посмотреть содержимое директории можно командой ls, с флагами -la будет удобнее просматривать содержимое каталога (в действительности эту команду с конкретными флагами можно описать детальнее и вернее, но у нас сегодня другая тема).

Ls -la
Наc интересуют в данный момент два каталога, которые вы видите на скриншоте. Это каталоги sites-available и sites-enabled.

Давайте перейдем в каталог sites-available и начнем конфигурировать наш виртуальный хост (сайт).

Cd /etc/nginx/sites-available
Перед началом создания конфигурационного файла, проверим что лежит у нас в данном каталоге. В моей случае каталог не пустой, в нем уже есть конфигурационные файлы, я их затер, чтобы не вводить вас в заблуждение.

Важное отступление

В случае установки nginx «с нуля», именно «с нуля», так как при удалении nginx командой
sudo apt-get remove nginx или sudo apt remove nginx конфигурационные файлы остаются и если вы вдруг будете не понимать, почему nginx не работает и захотите его переустановить (обычно к такому прибегают начинающие пользователи Linux), то и после переустановки он не будет корректно работать, из-за того что в старых конфигурационных файлах (они не удаляются после удаления командой remove) прописаны неверные настройки, их придется удалить, либо настроить верно, только тогда nginx заработает.

Рекомендую удалять командой sudo apt-get purge nginx или sudo apt purge nginx . Если вы используете пакетный менеджер aptitude, то команда sudo aptitude purge nginx удаляет пакет полностью со всеми зависимостями и конфигурационными файлами.


В этом каталоге будет по умолчанию один файл, с названием default. В нем будет конфигурационный файл с примером, с комментариями, его вы можете изучить на досуге, а можете и вовсе удалить (всегда можно обратиться к официальной документации).

Ls -la

Создадим свой конфигурационный файл, который будет соответствовать названию домена нашего локального сайта (или реального, если уже знаете его название). Это удобно, в будущем, когда будет много конфигурационных файлов, то это избавит вас от путаницы в них. У меня этот файл будет называться project.local.

Sudo touch project.local
Посмотрим что получилось.

Теперь откроем его в редакторе, я открою его в nano.

Sudo nano project.local
Видим что он у нас пустой. Теперь перейдем к формированию нашего файла. Нужно привести конфигурацию к такому виду, как написано ниже. Я опишу только жизненно важные директивы этого файла, описывать остальное не буду, так как это не является на данный момент важным, все-таки у нас тема базовой настройки. Этих настроек с «горкой» хватит для разработки проектов локально, не только мелких, но и довольно крупных. В следующих статьях опишу отдельно каждые использованные директивы (именно так называются строки, например server_name) этого файла.

Смотрите комментарии прям в конфигурационном файле.

Server { listen 80; # порт, прослушивающий nginx server_name project.local; # доменное имя, относящиеся к текущему виртуальному хосту root /home/stavanger/code/project.local; # каталог в котором лежит проект, путь к точке входа index index.php; # add_header Access-Control-Allow-Origin *; # serve static files directly location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ { access_log off; expires max; log_not_found off; } location / { # add_header Access-Control-Allow-Origin *; try_files $uri $uri/ /index.php?$query_string; } location ~* \.php$ { try_files $uri = 404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php/php7.0-fpm.sock; # подключаем сокет php-fpm fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~ /\.ht { deny all; } }
Сохраняем файл. Теперь нам надо проверить, нет ли в нем ошибок. Сделать мы это можем командой.

Sudo nginx -t
Если видим такую информацию как на скриншоте, значит у нас все верно, может продолжать настройку. Если вы получаете какие-либо ошибки, стоит перепроверить конфигурационный файл.

Теперь нам надо активировать конфигурационный файл, в каталоге /etc/nginx/sites-enabled/ необходимо создать симлинк (символическая ссылка). Если у вас nginx был установлен «с нуля», то в этом каталоге есть симлинк на файл default, про который рассказывалось выше, его можно удалить, если он вам не требуется. Переходим в нужный каталог.

Cd /etc/nginx/sites-enabled/
Теперь мы в нужном каталоге. Давайте создадим наш симлинк. Для создания используется команда ln с флагом -s, далее мы укажем путь до нашего конфига project.local.

Sudo ln -s /etc/nginx/sites-available/project.local
Посмотрим на наш созданный симлинк.

Чтобы убедиться что мы делаем еще все верно опять запустим команду.

Файл hosts

Этот файл находится по пути /etc/hosts. Наличие в нем записей, позволяет запускать nginx с использованием в качестве домена localhost. В этом файле можно присваивать альтернативные псевдонимы, например для нашего проекта project.local, мы присвоим домен project.local.

Открываем файл в редакторе nano.

Sudo nano /etc/hosts
У вас в этом файле будет и другая информация, просто игнорируйте ее. Вам всего лишь нужно добавить строку как на моем скриншоте.

Установка php-fpm (>=7.0)

sudo aptitude install php-fpm
Проверяем установленную версию, на всякий случай, хотя в Ubuntu 16.04.1 в репозиториях лежит именно 7.0 версия.

Php-fpm7.0 -v

Убеждаемся что все ок. Стартуем php-fpm.

Sudo service php7.0-fpm start
Если будете править конфиги, то не забывайте рестартовать демон. Это делает так. Но нам это не потребуется.

Sudo service php7.0-fpm restart
На этом установка и настройка php-fpm закончена. Правда, это все. Это не магия, путь до сокета php-fpm у нас уже был прописан в конфигурационном файле. Конечно, вам могут понадобиться какие-либо расширения php для разработки личных проектов, но их вы можете поставить по мере того как они будут требоваться.

Теперь пойдем для в каталог с нашим проектом, у меня он лежит по такому пути.

Cd /home/stavanger/code/project.local
Поднимемся на каталог выше и сделаем права 777 (то есть мы будем делать полные права каталогу с нашим проектом project.local). В будущем это избавим нас от лишних проблем.

Cd .. sudo chmod -R 777 project.local
На этом настройка ПО завершена, давайте создадим тестовый файл в нашем рабочем каталоге project.local и убедимся что все работает. Я создам файл index.php с таким содержанием.

Идем в браузер и видим что у нас все прекрасно работает! Интерпретатор php в том числе.

С уважением к читателям, Stavanger.