Как настроить серверные блоки nginx на centos 7

Введение

Немного расскажу своими словами о том, как работает модуль ngx_http_proxy_module. Именно он реализует весь функционал, о котором пойдет речь. Допустим, у вас в локальной или виртуальной сети есть какие-то сервисы, не имеющие прямого доступа из интернета. А вы хотите таковой иметь. Можно пробрасывать нужные порты на шлюзе, можно что-то еще придумывать. А можно сделать проще всего — настроить единую точку входа на все свои сервисы в виде nginx сервера и с него проксировать различные запросы к нужным серверам.

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

Ранее я рассказывал о настройке чат серверов — matrix и mattermost. В этих статьях я как раз рассказывал о том, как проксировать запросы в чат с помощью nginx. Прошелся по теме вскользь, не останавливаясь подробно. Суть в том, что вы настраиваете на любом виртуальном сервере эти чаты, помещаете их в закрытые периметры сети без лишних доступов и просто проксируете запросы на эти сервера. Они идут через nginx, который у вас смотрит во внешний интернет и принимает все входящие соединения.
Допустим, у вас есть большой сервер с множеством контейнеров, например докера. На нем работает множество различных сервисов. Вы устанавливаете еще один контейнер с чистым nginx, на нем настраиваете проксирование запросов на эти контейнеры. Сами контейнеры мапите только к локальному интерфейсу сервера. Таким образом, они будут полностью закрыты извне, и при этом вы можете гибко управлять доступом.
Еще один популярный пример. Допустим, у вас есть сервер с гипервизором proxmox или любым другим. Вы настраиваете на одной из виртуальных машин шлюз, создаете локальную сеть только из виртуальных машин без доступа в нее извне. Делаете в этой локальной сети для всех виртуальных машин шлюз по-умолчанию в виде вашей виртуальной машины со шлюзом. На виртуальных серверах в локальной сети размещаете различные сервисы и не заморачиваетесь с настройками фаервола на них. Вся их сеть все равно не доступна из интернета. А доступ к сервисам проксируете с помощью nginx, установленным на шлюз или на отдельной виртуальной машине с проброшенными на нее портами.
Мой личный пример. У меня дома есть сервер synology. Я хочу организовать к нему простой доступ по https из браузера по доменному имени. Нет ничего проще. Настраиваю на сервере nginx получение бесплатного сертификата , настраиваю проксирование запросов на мой домашний ip, там на шлюзе делаю проброс внутрь локалки на synology сервер. При этом я могу фаерволом ограничить доступ к серверу только одним ip, на котором работает nginx. В итоге на самом synology вообще ничего не надо делать. Он и знать не знает, что к нему заходят по https, по стандартному порту 443.
Допустим, у вас большой проект, разбитый на составные части, которые живут на разных серверах. К примеру, на отдельном сервере живет форум, по пути /forum от основного домена. Вы просто берете и настраиваете проксирование всех запросов по адресу /forum на отдельный сервер. Точно так же можно без проблем все картинки перенести на другой сервер и проксировать к ним запросы. То есть вы можете создать любой location и переадресовывать запросы к нему на другие сервера.

Надеюсь в общем и целом понятно, о чем идет речь. Вариантов использования много. Я привел самые распространенные, которые пришли в голову и которые использую сам. Из плюсов, которые считаю наиболее полезными именно из своих кейсов, отмечу 2:

Без проблем можете настроить https доступ к сервисам, при этом совершенно не трогая эти сервисы. Вы получаете и используете сертификаты на nginx сервере, используете https соединение с ним, а сам nginx уже передает информацию на сервера со службами, которые могут работать по обычному http и знать не знают о https.
Вы очень легко можете менять адреса, куда проксируете запросы. Допустим у вас есть сайт, его запросы проксируются на отдельный сервер. Вы подготовили обновление или переезд сайта. Отладили все на новом сервере. Теперь вам достаточно на сервере nginx изменить адрес старого сервера на новый, куда будут перенаправляться запросы. И все. Если что-то пойдет не так, можете оперативно вернуть все обратно.

С теорией закончил. Перейдем теперь к примерам настройки. В своих примерах я буду использовать следующие обозначения:

blog.zeroxzed.ru	доменное имя тестового сайта
nginx_srv	имя внешнего сервера с установленным nginx
blog_srv	локальный сервер с сайтом, куда проксируем соединения
94.142.141.246	внешний ip nginx_srv
192.168.13.31	ip адрес blog_srv
77.37.224.139	ip адрес клиента, с которого я буду заходить на сайт

Установка php-fpm 7.1

Установка и настройка 7-й версии php на centos не очень простая задача. Ранее я уже рассказывал как обновить php до 7-й версии, но в итоге откатился назад. Прошло прилично времени и откатываться уже не будем, так как большинство проблем исправлены.

Вторая проблема в том, что надо определить, какой репозиторий использовать для установки php7. Их существует очень много. К примеру, мой хороший знакомый в своей статье по настройке web сервера использует репозиторий Webtatic. В принципе, чтобы просто поставить php 7-й версии это нормальный вариант. Но если вы после этого захотите установить phpmyadmin через yum уже ничего не получится. Будет ошибка зависимостей, которые нужно будет как-то руками разбирать.

То же самое будет и с другими пакетами. К примеру, zabbix без плясок с бубнами скорее всего не встанет. В сторонних репозиториях есть еще одна проблема. Иногда они закрываются. И это станет для вас большой проблемой на боевом сервере. Так что к выбору репозитория нужно подходить очень аккуратно и внимательно. Я до сих пор иногда встречаю настроенные сервера centos 5 с очень популярным в прошлом репозиторием centos.alt.ru, который закрылся. Сейчас это уже не так актуально, так как таких серверов осталось мало, но некоторое время назад мне это доставляло серьезные неудобства.

Для установки свежей версии php я буду использовать репозиторий Remi. Это известный и популярный репозиторий, который ведет сотрудник RedHat. И хотя надежность репозитория, который ведет один человек не так высока, но ничего лучше и надежнее remi лично я не нашел для своих целей. Если вы можете что-то посоветовать на этот счет — комментарии в вашем распоряжении. Буду благодарен за дельный совет.

Подключаем remi репозиторий для centos 7.

# rpm -Uhv http://rpms.remirepo.net/enterprise/remi-release-7.rpm

Я получил ошибку:

Retrieving http://rpms.remirepo.net/enterprise/remi-release-7.rpm
warning: /var/tmp/rpm-tmp.nwcDV1: Header V4 DSA/SHA1 Signature, key ID 00f97f56: NOKEY
error: Failed dependencies: 
       epel-release = 7 is needed by remi-release-7.3-2.el7.remi.noarch

Тут все понятно, нужен репозиторий epel. Те, кто готовили сервер по моей статье по базовой настройке сервера его уже подключили, а те кто не делали этого, подключают сейчас:

# yum install epel-release

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

# yum repolist

У меня такая картинка получилась.

Активируем репу remi-php71, для этого выполняем команду:

# yum-config-manager --enable remi-php71

Если получаете ошибку:

bash: yum-config-manager: command not found

то установите пакет yum-utils.

# yum install yum-utils

Теперь устанавливаем php7.1.

# yum install php71

Установим php-fpm и наиболее популярные модули, которые могут пригодится в процессе эксплуатации веб сервера.

# yum install php-fpm php-cli php-mysql php-gd php-ldap php-odbc php-pdo php-pecl-memcache php-opcache php-pear php-xml php-xmlrpc php-mbstring php-snmp php-soap php-zip

Запускаем php-fpm и добавляем в автозагрузку.

# systemctl start php-fpm
# systemctl enable php-fpm

Проверяем, запустился ли он.

# netstat -tulpn | grep php-fpm
tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 9084/php-fpm: maste

Все в порядке, повис на порту 9000. Запустим его через unix сокет. Для этого открываем конфиг /etc/php-fpm.d/www.conf и комментируем строку:

;listen = 127.0.0.1:9000

Вместо нее добавляем несколько других:

listen = /var/run/php-fpm/php-fpm.sock
listen.mode = 0660
listen.owner = nginx
listen.group = nginx

Заодно измените пользователя, от которого будет работать php-fpm. Вместо apache укажите nginx.

user = nginx
group = nginx

Перезапускаем php-fpm.

# systemctl restart php-fpm

Проверяем, стартовал ли указанный сокет.

# ll /var/run/php-fpm/php-fpm.sock 
srw-rw----. 1 nginx nginx 0 Oct 26 18:08 /var/run/php-fpm/php-fpm.sock

На текущий момент с настройкой php-fpm закончили, двигаемся дальше.

Для того, чтобы проверить работу нашего веб сервера, нужно установить ssl сертификаты. Без них nginx с текущим конфигом не запустится. Исправляем это.

Is NGINX or Apache right for you?

If you are…

Using the server to host a single website with high traffic
Comfortable with advanced configuration and tweaking, and have the skillset to do so
Wanting to work with newer web development frameworks
Wanting to use an alternative to CGI/FastCGI, such as WSGI
Are OK with less add-ons, components, or modules
Are OK with a more complex configuration

… then NGINX might be a good fit for you.

If you are …

Using traditional MySQL/PHP applications, such as WordPress or Drupal
Planning to host many websites with different configurations per site through an .htaccess
Are more comfortable with a platform that is very well known and documented
Want access to a variety of different modules, add-ons, and components
Want your web server to work right out of the box

… then you probably want to stick with Apache.

Here’s a good rule of thumb: If you want to run ONE site at lightning speed on an advanced configuration, NGINX is probably the server for you. If you want to run MANY sites with easy configuration and flexibility, Apache is still your bread and butter.

At the end of the day, both NGINX and Apache are a good fit for most sites. Apache is included with all major Linux distributions and requires much less configuration. However, most benchmarks have clocked NGINX at serving websites faster. You can also see some configurations that run both — it’s all up to you as the admin.

At the end of the day, the choice of the web server platform is entirely dependent on what you’re doing with the server.

3: Создание блоков Server

Итак, теперь файловая структура и страницы, обслуживающие контент, готовы к работе. Приступайте к созданию блоков server для Nginx.

Блоки server, или виртуальные хосты, помогают веб-серверу Nginx обслуживать несколько сайтов с разным контентом.

Для начала создайте каталог для хранения файлов хостов (sites-available), а также каталог, предоставляющий Nginx список хостов, которые нужно обслуживать (sites-enabled).

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

После этого нужно сообщить , что доступные блоки server хранятся в каталоге sites-enabled. Для этого нужно отредактировать главный конфигурационный файл Nginx, добавив в него строку, сообщающую о других конфигурационных файлах:

Добавьте эти строки в конец блока http {}:

Первая строка указывает, что виртуальные хосты находятся в каталоге sites-enabled, а вторая строка увеличивает объем памяти, выделенный для обработки доменов.

Создание виртуального хоста

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

Откройте новый файл и подкорректируйте настройки:

Примечание: Согласно требованиям все файлы виртуальных хостов Nginx должны иметь расширение .conf

Содержимое файла выглядит так (комментарии опущены для удобства):

Сначала нужно изменить директиву server_name, которая сообщает Nginx, какие запросы нужно направлять на этот виртуальный хост. В этой строке нужно указать домен (например, example.com) и псевдонимы сайта (например, www.example.com); тогда домен с префиксом www и без него будет отображать один и тот же контент.

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

После этого нужно указать каталог document root; для этого существует директива root.

Также нужно добавить команду try_files и указать, что в случае если искомый файл или каталог не найден, сервер должен вернуть ошибку 404.

После внесения всех изменений файл виртуального хоста будет иметь такой вид:

Базовая конфигурация хоста завершена. Сохраните и закройте файл.

Создание виртуального хоста для второго сайта

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

Откройте новый файл:

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

Откорректировав данные, сохраните и закройте файл.

Установка phpmyadmin на CentOS 7

Для удобства управления базами веб сайтов я всегда использую phpmyadmin. Установим ее:

# yum install -y phpmyadmin

Копируем файлы панели в наш виртуальный домен, созданный ранее:

# cp -R /usr/share/phpMyAdmin/* /web/sites/pma.site1.ru/www
# chown -R nginx:nginx /web/sites/pma.site1.ru/www

Заходим по адресу http://pma.site1.ru/ и проверяем, все ли в порядке.

У меня при первом запуске в браузере открылся просто белый лист. Начал разбираться в чем дело. В логе ошибок nginx этого виртуального хоста увидел ошибку:

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

# cd /var/lib/php/
# mkdir session
# chown nginx:nginx session/

После этого загрузилась панель phpmyadmin:

Более подробную информацию об установке и настройке phpmyadmin смотрите в отдельной статье.

На этом все, настройка nginx + php-fpm на CentOS7 закончена.

Онлайн курсы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курсы по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте .

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

Знания, ориентированные на практику;
Реальные ситуации и задачи;
Лучшее из международных программ.

Настройка proxy_pass в nginx

Рассмотрим самый простой пример. Буду использовать свой технический домен zeroxzed.ru в этом и последующих примерах. Допустим, у нас есть сайт blog.zeroxzed.ru. В DNS создана A запись, указывающая на ip адрес сервера, где установлен nginx — nginx_srv. Мы будем проксировать все запросы с этого сервера на другой сервер в локальной сети blog_srv, где реально размещается сайт. Рисуем конфиг для секции server.

Заходим по адресу http://blog.zeroxzed.ru. Мы должны попасть на blog_srv, где тоже должен работать какой-то веб сервер. В моем случае это будет тоже nginx. У вас должно открыться содержимое, аналогичное тому, что вы увидите, набрав http://192.168.13.31 в локальной сети. Если что-то не работает, то проверьте сначала, что по адресу директивы proxy_pass у вас все корректно работает.

Посмотрим логи на обоих сервера. На nginx_srv вижу свой запрос:

Проверяем blog_srv:

Как мы видим, запрос сначала пришел на nginx_srv, был переправлен на blog_srv, куда он пришел уже с адресом отправителя 94.142.141.246. Это адрес nginx_srv. Реальный же ip адрес клиента мы видим только в самом конце лога. Это неудобно, так как директива php REMOTE_ADDR не будет возвращать настоящий ip адрес клиента. А он очень часто бывает нужен. Мы это дальше исправим, а пока создадим в корне сайта на chat_srv тестовую страничку для проверки ip адреса клиента следующего содержания:

Назовем ее myip.php. Перейдем по адресу http://blog.zeroxzed.ru/myip.php и проверим, как сервер определит наш адрес. Никак не определит Он покажет адрес nginx_srv. Исправляем это и учим nginx передавать реальный ip адрес клиента на сервер.

Step One — Create the Directory Structure

First, we need to make a directory structure that will hold the site data to serve to visitors.

Our document root (the top-level directory that Nginx looks at to find content to serve) will be set to individual directories in the directory. We will create a directory here for each of the server blocks that we plan on making.

Within each of these directories, we will create an directory that will hold our actual files. This gives us some flexibility in our hosting.

We can make these directories using the command (with a flag that allows us to create a folder with a nested folder inside of it):

Remember that the portions in red represent the domain names that we want to serve from our VPS.

Grant Permissions

We now have the directory structure for our files, but they are owned by our user. If we want our regular user to be able to modify files in our web directories, we can change the ownership with :

The variable will take the value of the user you are currently logged in as when you submit the command. By doing this, our regular user now owns the subdirectories where we will be storing our content.

We should also modify our permissions a little bit to ensure that read access is permitted to the general web directory, and all of the files and folders inside, so that pages can be served correctly:

Your web server should now have the permissions it needs to serve content, and your user should be able to create content within the appropriate folders.

Шаг 6 — Настройка блоков сервера (опция)

Если вы хотите разместить несколько сайтов на одном и том же веб-сервере Nginx, вам придется создать блоки сервера. Блоки сервера Nginx работают аналогичным с виртуальными хостами Apache образом, позволяя одному серверу реагировать на запросы к нескольким доменным именам и предоставлять разное содержимое для каждого домена. В CentOS 8 серверные блоки определяются в файлах , расположенных в .

Мы создадим серверный блок для домена с именем your_domain. Чтобы узнать больше о настройке доменного имени с помощью DigitalOcean, пройдите наше обучающее руководство Введение в DigitalOcean DNS.

Создайте директорию для your_domain следующим образом, используя флаг для создания необходимых родительских каталогов:

Затем необходимо назначить права владения для директории с помощью переменной среды которая будет использоваться для текущего системного пользователя:

Затем мы создадим образец страницы для тестирования конфигурации блока сервера. Предоставляемый с CentOS 8 по умолчанию текстовый редактор — . очень мощный текстовый редактор, но освоить работу с ним неопытным пользователям достаточно сложно. Вы можете установить более удобный для пользователя редактор, например, , для облегчения редактирования файлов конфигурации на сервере CentOS 8:

Теперь вы можете использовать для создания файла

В этом файле добавьте следующий код HTML:

/var/www/your_domain/html/index.html

Сохраните файл и закройте его после завершения. Если вы ”“”.

Чтобы Nginx обслуживал это содержимое, нам нужно создать серверный блок с правильными директивами, которые указывают на наш настраиваемый корневой каталог. Мы создадим новый серверный блок в :

Вставьте следующий блок конфигурации:

/etc/nginx/conf.d/your_domain.conf

Сохраните и закройте файл после внесения изменений в его содержимое.

Чтобы убедиться, что в файлах Nginx нет синтаксических ошибок, запустите следующую команду:

Если проблем нет, вы увидите на экране следующие результаты:

После тестирования конфигурации перезапустите Nginx для активации изменений:

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

Следующая команда позволит использовать ваш настраиваемый корневой каталог документов в качестве содержимого HTTP:

Теперь вы можете проверить настройку вашего пользовательского домена, перейдя на , где вы увидите примерно следующее:

Эта страница отображает код HTML, который мы задали в корневой директории документов, созданной для серверного блока. Если вы увидите эту страницу, это означает, что ваш сервер Nginx настроен корректно для обслуживания вашего домена.

Установка nginx

Установка nginx в СentOS

Из-под привилегированного пользователя мы отдаем команду

yum install nginx

После установки вводим команду для запуска

/etc/init.d/nginx start

Можно включить дополнительный сервис в автозагрузку

chkconfig nginx on

Установка nginx в Ubuntu

Из-под привилегированного пользователя мы отдаем команду

apt-get install nginx

Включаем сервис, когда он установится в систему

/etc/init.d/nginx start

Устанавливаем из портов

cd /usr/ports/www/nginx
make install clean

Установка nginx в Windows

Необходимо скачать zip-архив
Находим место его сохранения (например, корень диска С)
Разархивируем этот файл

unzip nginx.zip

Переходим внутрь каталога

cd nginx

Запускаем сервер

start nginx

Если nginx не запустился, нужно смотреть причины в error_log. Если же error_log не создался, то об этом сообщается в Event Log. В настоящее время данное ПО не работает в Windows как сервис.

Настройка PHP-FPM Nginx CentOS

Если вам нужен Nginx, то скорее всего, вам нужно также настроить его для работы с интерпретатором PHP. Дальше будет разобрана настройка php-fpm Nginx CentOS 7. Прочитать более подробно про установку PHP 7 в CentOS можно в отдельной статье, а в этой статье мы будем работать с версией, доступной в официальных репозиториях. Для Nginx нам необходимо установить пакет php-fpm:

Затем запустите службу php-fpm командой:

Откройте конфигурационный файл php-fpm, который находится по адресу /etc/php-fpm.d/www.conf и посмотрите, на каком порту ожидает соединений запущенная служба. По умолчанию это 9000:

Далее нам осталось только связать Nginx с новой службой. Для этого в секцию server добавьте такой код:

Здесь очень важно значение этого параметра:

Оно должно соответствовать тому, которое мы видели в файле /etc/php-fpm.d/www.conf. Это адрес и порт на котором ожидает подключения служба php-fpm. Всё остальное можно оставить как есть и модифицировать при необходимости. Затем перезагрузите Nginx:

Опция reload позволяет перечитать конфигурацию без перезагрузки веб-сервера. Осталось создать тестовый файл с таким содержимым:

Затем откройте адрес сервера на который был установлен Nginx плюс phpinfo.php в браузере:

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

Обратите внимание, что секция location для php — это регулярное выражение и если у вас будут более общие регулярные выражения, то эта секция должна находиться перед ними, потому что Nginx не будет проверять все регулярные выражения и искать самое подходящее, а выберет первое, которое совпадёт

Apache (httpd)

Несмотря на то, что мы установили и настроили PHP-FPM, Apache нам понадобится, как минимум, по двум причинам. Во-первых, многие сайты используют файл .htaccess, который читает только Apache. Во-вторых, последний включает большое число модулей, которые может использовать портал.

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

И так, устанавливаем httpd:

yum install httpd

Заходим в настройки:

vi /etc/httpd/conf/httpd.conf

И редактируем следующее:

Listen 8080

* наш веб-сервер будет слушать на порту 8080, так как на 80 уже работает NGINX.

<IfModule dir_module>
DirectoryIndex index.php index.html
</IfModule>

* если не указан конкретный скрипт, сначала веб-сервер пытается найти и запустить index.php, затем index.html

Добавляем:

<Directory /var/www/*/www>
AllowOverride All
Options Indexes ExecCGI FollowSymLinks
Require all granted
</Directory>

* где Directory — разрешенные каталоги для запуска из apache; Options — разрешенные опции; Require — с каких IP-адресов можно открывать сайты, определенные в данном каталоге. Итого, мы разрешаем все каталоги в /var/www, но только если следующий каталог будет www; разрешаем опции Indexes (возвращает список файлов, если нет индексного файла, например, index.php), ExecCGI (разрешены сценарии CGI), FollowSymLinks (включены символические ссылки в этом каталоге); доступ для данных каталого разрешен со всех адресов (all granted).

Проверяем синтаксис конфигурационного файла httpd:

apachectl configtest

Разрешаем автозапуск и запускаем службу:

systemctl enable httpd —now

Создаем php-файл со следующим содержимым:

vi /var/www/html/index.php

<?php phpinfo(); ?>

Открываем браузер и вводим в адресную строку IP-адрес нашего сервера и добавляем :8080. Мы должны увидеть привычную страницу:

NGINX + Apache

Ранее нами была настроена связка nginx + php-fpm. Теперь проверяем совместную работу первого с apache.

Открываем конфигурационный файл nginx:

vi /etc/nginx/conf.d/default.conf

* если при настройке nginx мы редактировали файл /etc/nginx/nginx.conf, то необходимо открыть его.

Находим наш настроенный location для php-fpm:

…
location ~ \.php$ {
fastcgi_pass unix:/run/php-fpm/www.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
…

и меняем на:

…
location ~ \.php$ {
       proxy_pass http://127.0.0.1:8080;
       proxy_redirect off;
       proxy_set_header Host $host;
  proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   }
…

Проверяем и перезапускаем nginx:

nginx -t

systemctl restart nginx

Пробуем открыть в браузере IP-адрес нашего сервера — должна открыться та же страница, что при проверке Apache (с добавлением 8080):

Apache Real IP

Так как все запросы на httpd приходят от NGINX, они воспринимаются как от IP-адреса 127.0.0.1. На практике, это может привести к проблемам, так как некоторым сайтам необходимы реальные адреса посетителей.

Для решения проблемы будем использовать модуль mod_rpaf. Устанавливаем набор разработчика для apache:

yum install httpd-devel gcc unzip

Переходим в каталог /usr/local/src:

cd /usr/local/src

Скачиваем модуль:

wget https://github.com/gnif/mod_rpaf/archive/stable.zip

Распаковываем его:

unzip stable.zip

Переходим в распакованный каталог:

cd mod_rpaf-stable/

Собираем модуль и устанавливаем его:

make

make install

* при возникновении ошибки ./apxs.sh: line 15: -c: command not found, необходимо поставить which командой yum install which.

Создаем конфигурационный файл со следующим содержимым:

vi /etc/httpd/conf.d/mod_rpaf.conf

LoadModule              rpaf_module modules/mod_rpaf.so
RPAF_Enable             On
RPAF_ProxyIPs           127.0.0.1
RPAF_SetHostName        On
RPAF_SetHTTPS           On
RPAF_SetPort            On
RPAF_ForbidIfNotProxy   Off

Перезапускаем httpd:

systemctl restart httpd

Для проверки настройки открываем на редактирование созданный index-файл для httpd:

vi /var/www/html/index.php

И редактируем содержимое на:

<?php echo $_SERVER ?>

Открываем браузер и вводим в адресную строку IP-адрес нашего сервера. Мы должны увидеть внешний адрес компьютера, с которого обращаемся к серверу.

Способы применения nginx

На отдельному порту/IP

Если ресурс насыщен изображениями или файлами для скачивания nginx можно настроить на отдельном порту или же IP и раздавать через него статичный контент. Чтобы это реализовать, нужно поменять некоторые ссылки на сайте. При большом количестве запросов к статичным файлам целесообразно создать отдельный сервер и установить на нем nginx.

Акселерированное проксирование

При акселерированном проксировании все посетительские запросы поступают к nginx. Запросы на получение статичных файлов (например, картинки, простого HTML, JavaScript или CSS-файла) Nginx обрабатывает самостоятельно. В случае обращения пользователя к тому или иному скрипту он переадресует запрос в ведомство Apache. Код сайта при этом остается неизменным.

Управление потоками (модулями)

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

1. Вывести список доступных модулей:

dnf module list

* обозначения:

— значения по умолчанию.
— включенные модули.
— отключены.
— установленные.

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

Мы также можем посмотреть отдельные по состоянию группы модулей:

dnf module list —enabled

* включенные.

dnf module list —disabled

* отключенные.

dnf module list —installed

* установленные.

2. Вывести список возможных модулей для конкретного пакета:

dnf module list nodejs

* в данном примере для nodejs.

3. Разрешить или запретить конкретный модуль:

dnf module enable nodejs:12

dnf module disable nodejs:14

* первая команда разрешит модуль nodejs версии 12, вторая, соответственно, запрещает использование модуля nodejs версии 14.

4. Переключение модуля.

Если мы хотим изменить активный модуль, необходимо сначала отключить текущий командой dnf module reset, например:

dnf module reset php:7.3

* если попробовать включить модуль без отключения активного мы увидим ошибку:Error: It is not possible to switch enabled streams of a module.
It is recommended to remove all installed content from the module, and reset the module using ‘dnf module reset <module_name>’ command. After you reset the module, you can install the other stream.

После включаем новый поток:

dnf module enable php:7.4

Заблокировать установку и обновление пакетов

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

1. Во время обновления (разово)

Данный метод можно использовать при обновлении пакетов. Мы с помощью ключа -x просто указываем через запятую те, которые не должны быть обновлены, например:

yum -x postgresql*,asterisk update

* данной командой мы обновим все пакеты, кроме asterisk и тех, название которых начинается на postgresql.

2. Постоянный запрет в yum.conf

Аналогично, можно запретить как установку, так и обновление в конфигурационном файле yum.conf. Открываем его командой:

vi /etc/yum.conf

Добавляем:

exclude=postgresql* asterisk

* в данном примере мы также запретим установку и обновление asterisk, а также пакетов, название которых начинается на postgresql.

3. Настройка репозитория

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

vi /etc/yum.repos.d/pgdg-redhat-all.repo

И добавим:

…
exclude=postgresql12*

* в данном примере мы блокируем пакет postgresql12.

Работа с сайтами разных пользователей на одном веб сервере

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

# chown -R hl.zeroxzed.ru:nginx /web/sites/hl.zeroxzed.ru/
# chmod -R 0775 /web/sites/hl.zeroxzed.ru/

Но при такой схеме будут проблемы с движками сайтов, которые автоматом что-то к себе загружают. Какие-то галереи не будут работать. К примеру, wordpress не сможет автоматически загружать плагины, будет просить доступ к ftp. В общем, могут возникнуть некоторые неудобства. Сейчас мы их исправим.

Еще обращаю внимание на один нюанс. Chroot доступ для sftp не будет работать, если владельцем директории, куда чрутимся, будет не root

Только что мы сделали владельцем каталога с сайтом и всего, что внутри него пользователя hl.zeroxzed.ru. Теперь надо вернуть обратно владельцем исходного каталога рута, а все, что внутри него остается как мы и хотим — будет принадлежать hl.zeroxzed.ru.

# chown root:root /web/sites/hl.zeroxzed.ru/
# chmod 0755 /web/sites/hl.zeroxzed.ru/

# chown -R hl.zeroxzed.ru:hl.zeroxzed.ru /web/sites/hl.zeroxzed.ru/

Возвращаем обратно рута владельцем корня chroot.

# chown root:root /web/sites/hl.zeroxzed.ru/
# chmod 0755 /web/sites/hl.zeroxzed.ru/

Обращаю внимание, что сначала мы рекурсивно назначаем права на все содержимое директорий, а потом возвращаем владельца root только на корень. Добавляем пользователя nginx в группу hl.zeroxzed.ru

Добавляем пользователя nginx в группу hl.zeroxzed.ru.

# usermod -aG hl.zeroxzed.ru nginx

Создаем отдельный pool для php-fpm, который будет обслуживать сайт hl.zeroxzed.ru и будет запускаться от этого пользователя. Для этого копируем существующий конфиг /etc/php-fpm.d/www.conf и изменяем в нем несколько строк.

# cd /etc/php-fpm.d && cp www.conf hl.zeroxzed.ru.conf

user = hl.zeroxzed.ru
group = hl.zeroxzed.ru
listen = /var/run/php-fpm/hl.zeroxzed.ru.sock
listen.owner = hl.zeroxzed.ru
listen.group = hl.zeroxzed.ru

Мы поменяли название пула, запустили его от отдельного пользователя и назначили ему отдельный сокет. Теперь идем в настройки этого виртуального хоста в nginx — /etc/nginx/conf.d/hl.zeroxzed.ru.conf и везде меняем старое значение сокета

fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;

на новое

fastcgi_pass unix:/var/run/php-fpm/hl.zeroxzed.ru.sock;

Перезапускаем nginx и php-fpm и проверяем работу сайта от отдельного пользователя.

# systemctl restart nginx
# systemctl restart php-fpm

Я рекомендую подключиться по sftp, закинуть исходники wordpress, установить его и добавить новую тему, чтобы проверить, что все корректно работает. По аналогии проделанные выше действия повторяются для всех остальных сайтов.

Выводы

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

В настоящее время безопасный сертификат является обязательной функцией для всех веб-сайтов. Чтобы защитить свой сайт с помощью бесплатного сертификата Let’s Encrypt SSL, вы можете ознакомиться с нашим руководством о том, как защитить Nginx с помощью Let’s Encrypt в CentOS 7 .

Этот пост является частью серии Install LEMP Stack on CentOS 7. Другие сообщения из этой серии:

Защитите Nginx с помощью Let’s Encrypt на CentOS 7
Установите MariaDB на CentOS 7
Установите PHP 7 на CentOS 7
Как настроить серверные блоки Nginx на CentOS 7