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

Обновлено: 04.07.2024

Я уже писал статью по данной теме, и она формально даже не устарела, если брать все пакеты из официальных репозиториев. Сегодня я настрою производительный веб сервер на свежих версиях nginx, php-fpm, где сам php версии 7.1. Сейчас использовать версию php54, которую предлагает CentOS по-умолчанию, очень странно, поэтому я решил актуализировать статью и все настроить в соответствии с современными реалиями.

Хочешь научиться автоматически разворачивать и поддерживать высоконагруженные проекты? Тогда рекомендую познакомиться с онлайн курсом " Infrastructure as a code." в OTUS. Актуально для системных администраторов и devops инженеров. Подробности по .

Данная статья является частью единого цикла статьей про сервер Centos. Если вы хотите использовать более новую версию системы, то читайте как настроить такой же web сервер на CentOS 8.

Введение

Ранее я рассказывал о настройке nginx и php-fpm. В принципе, статья полностью актуальна, по ней получится настроить веб сервер, если вас устраивают версии предложенных в стандартном репозитории пакетов. Если же хочется версий посвежее, то читайте далее.

Работать будем на сервере под управлением CentOS 7. Если у вас его еще нет, то читайте мои статьи на тему установки и базовой настройки centos. Не забудьте уделить внимание теме настройки iptables. В данной статье я ее не буду касаться, хотя тема важная для web сервера.

В своей тестовой среде я буду использовать следующие сущности.

Подопытным сервером будет выступать виртуальная машина от ihor, характеристики следующие:

Процессор	2 ядра
Память	8 Gb
Диск	150 Gb SSD

Это кастомная настройка параметров. Они не оптимальны по цене, но мне были нужны именно такие.

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

Для установки самой свежей стабильной версии nginx на centos подключим родной репозиторий.

Если по какой-то причине ссылка изменится или устареет, то можно создать файл с конфигурацией репозитория nginx вручную. Для этого рисуем такой конфиг /etc/yum.repos.d/nginx.repo.

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

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

Если страница не открывается, то скорее всего вы не настроили firewall. Свою статью по его настройке я приводил в самом начале.

Настройка nginx

Расскажу, как настроить nginx для работы разных виртуальных хостов. Создадим виртуальный хост и подготовим директории для размещения исходников сайта и панели управления phpmyadmin.

Для phpmyadmin рисуем конфиг попроще.

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

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

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

Основные трудности возникают с тем, что в официальных репозиториях очень старые версии php, но при этом они часто есть в зависимостях к другим пакетам. В итоге, обновившись неаккуратно до 7.1 можно получить проблемы с установкой и обновлением, к примеру, phpmyadmin или zabbix. В комментариях к моим статьям я иногда вижу эти ошибки и по тексту ошибок сразу понимаю, что проблема с зависимостями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка бесплатного ssl сертификата Lets Encrypt

Устанавливаем пакет certbot для получения бесплатного ssl сертификата от let's encrypt.

Запускаем программу для генерации сертификата.

Вам в консоли будут заданы несколько вопросов. Вот мои ответы, необходимые для успешного получения сертификата. Первый раз мы получим сертификаты, используя временный веб сервер самого certbot, так как наш еще не работает. Далее обновлять сертификаты будем в автоматическом режиме с помощью временной директории в корне виртуального хоста.

Для успешного создания бесплатных ssl сертификатов от lets encrypt у вас должны быть корректно настроены DNS записи для доменов, на которые выпускаются сертификаты.

Итак, сертификаты получили. Теперь можно проверить конфигурацию nginx и запустить его. Проверяем конфиг:

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

То генерируете необходимый ключ:

Генерация будет длиться долго (у меня 20 минут длилось на двух ядрах). Снова проверяйте конфигурацию. Если ошибок нет, то перезапустим nginx.

Настройка nginx на этом завершена. Он должен корректно запуститься и работать в рабочем режиме.

Приводим его к следующему виду:

По аналогии делаете с остальными виртуальными хостами, для которых используете бесплатные сертификаты let's encrypt. Осталось дело за малым - настроить автоматический выпуск новых ssl сертификатов, взамен просроченным. Для этого добавляем в /etc/crontab следующую строку:

Все, с сертификатами закончили. Двигаемся дальше в настройке web сервера.

Установка mariadb 10 на CentOS 7

Дошла очередь до установки сервера баз данных для web сервера на CentOS 7 - MariaDB. По аналогии с другим софтом, в официальном репозитории очень старая версия mariadb - 5.5. Я же буду устанавливать последнюю стабильную версию на момент написания статьи - 10.2.

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

В моем случае конфиг получился следующий.

Устанавливаем последнюю версию mariadb на centos.

Убедитесь, что база данных ставится из нужного репозитория.

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

Запускаем скрипт начальной конфигурации mysql и задаем пароль для root. Все остальное можно оставить по-умолчанию.

Сервер баз данных mysql для нашего web сервера готов. Продолжаем настройку. Установим панель управления mysql - phpmyadmin.

Установка phpmyadmin

Кратко расскажу про установку phpmyadmin в контексте данной статьи. Подробно не буду останавливаться на этом, так как статья и так получается очень объемная, а я еще не все рассказал. Вопрос настройки phpmyadmin я очень подробно рассмотрел отдельно. За подробностями можно сходить туда.

Устанавливаем phpmyadmin через yum. Если ранее все сделали правильно, то конфликтов с зависимостями быть не должно.

Выставляем правильные права на директорию с php сессиями. Без этого работать phpmyadmin не будет.

Можно заходить и проверять работу phpmyadmin. Ее установка закончена.

Доступ к сайту по sftp

Настройка сервера почти завершена. Если вы администратор и единственный пользователь, то больше можно ничего не делать. Вы и так сможете загрузить на сервер все что нужно тем или иным способом. Если же вы будете передавать управление сайтами другим людям, им нужен доступ к директории с исходниками сайта. Раньше для этих целей повсеместно использовали ftp. Если вы хотите так сделать, у меня есть статья по настройке ftp сервера vsftpd.

Я же предлагаю использовать sftp по нескольким причинам:

Он безопаснее.
Его быстрее настроить.
Не надо отдельно настраивать firewall.

Статью по настройке sftp доступа я уже тоже писал, все подробности там. Здесь без комментариев выполним необходимые действия.

Создаем пользователя для подключения к сайту. Я обычно использую имя пользователя пересекающееся с названием сайта. Так удобнее управлять.

Открываем конфиг ssh по пути /etc/ssh/sshd_config и комментируем там одну строку, добавляя далее несколько новых.

Перезапускаем службу sshd.

Этого уже достаточно, чтобы вы могли подключиться к сайту, к примеру, с помощью программы winscp. Если что-то пойдет не так и будут какие-то ошибки, то смотреть подробности нужно в логе /var/log/secure. Но тут возникает много нюансов с правами к файлам и директориям. Дальше я расскажу, как их аккуратно и грамотно разрулить, чтобы у нас не было проблем с дальнейшей работой сайтов от разных пользователей.

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

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

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

А теперь сделаем все красиво. Назначаем владельцем содержимого нашего сайта только отдельного пользователя.

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

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

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

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

Ротация логов виртуальных хостов

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

У нас уже будет файл конфигурации logrotate для nginx, который был создан во время установки - /etc/logrotate.d/nginx. Приведем его к следующему виду:

Я предлагаю ротировать файлы логов по достижению ими размера в 1Мб, сжимать после ротации и хранить 10 архивов с логом. Для виртуальных хостов, работающих от отдельного пользователя, новые логи создаются сразу с соответствующими правами, чтобы у пользователя был доступ к ним. Для всех остальных хостов можно использовать самое первое правило, просто добавляя туда новые пути для логов.

Это просто пример конфигурации. Все параметры вы можете поменять по своему усмотрению. Примеров конфигурации logrotate в интернете много.

На этом все. Я рассмотрел все основные моменты, которые необходимы для установки и настройки производительного web сервера на основе nginx и php-fpm последних версий. При этом рассказал о некоторых вещах, которые повышают удобство и гибкость эксплуатации сервера.

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

Тема настройки веб сервера обширна. Рассмотреть все варианты в одной статье невозможно, так как функционал будет разниться, в зависимости от назначения сервера. Тем не менее приведу еще несколько ссылок на материалы, которые имеют отношение к настройке web сервера:

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

Если еще что-то полезное вспомню, добавлю ссылки. Пока вроде все. Жду комментариев и отзывов. Написал все по своему опыту, как я обычно настраиваю веб сервера. Возможно что-то можно сделать более удобно и правильно.

Эта статья будет первой из цикла статей по настройке современного веб сервера. Далее мы будем защищать web сервер и готовить его к максимальным нагрузкам.

Напоминаю, что данная статья является частью единого цикла статьей про сервер Centos.

Nginx – один из самых популярных веб-серверов в мире. Nginx отвечает за размещение и обслуживание объёмных и производительных сайтов с большой нагрузкой. В большинстве случаев Nginx легче Apache и лучше подаётся масштабированию. Кроме того, Nginx можно использовать как веб-сервер и обратный прокси.

Для управления индивидуальными настройками отдельных сайтов Nginx использует блоки server, которые принято называть виртуальными хостами (как в Apache). Виртуальные хосты позволяют размещать несколько сайтов с разными конфигурациями на одном сервере.

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

Данное руководство поможет настроить блоки server для Nginx на виртуальном выделенном сервере CentOS 7.

Требования

Для выполнения руководства понадобится:

Предварительно настроенный сервер CentOS 7.
Не-root пользователь с доступом к sudo (информацию о настройке такого пользователя можно найти здесь).

Также нужно заранее установить веб-сервер Nginx. Можно установить полный стек LEMP согласно этому руководству. Чтобы установить только Nginx, используйте yum. Сначала добавьте Nginxв список исходников системы:

Затем при помощи yum загрузите и установите Nginx:

sudo yum install nginx

После завершения установки подключитесь как не-root пользователь при помощи SSH.

Если же у вас ещё нет доменных имён, вы сможете протестировать настройку при помощи фиктивных данных.

1: Структура каталогов

Для начала нужно создать структуру каталогов для хранения данных для сайтов.

Такие каталоги (каталоги верхнего уровня, в которых Nginx ищет запрашиваемый контент) называются document root. В каталоге /var/www нужно создать отдельные подкаталоги для каждого сайта. а в них – подкаталоги html для хранения файлов сайта.

Для создания каталогов используется команда mkdir, а флаг –p позволяет создать каталог с подкаталогом в нём.

Примечание: Напоминаем, что условные доменные имена нужно заменять своими доменами.

Права доступа

Теперь структура каталогов для сайтов готова, но все эти каталоги принадлежат пользователю root. Нужно передать права на них текущему пользователю, иначе он не сможет изменять данные. Для этого используйте команду chown:

Переменная $USER автоматически задаёт имя текущего пользователя. Теперь текущему пользователю принадлежат подкаталоги public_html, в которых будет храниться контент сайтов.

Также нужно немного изменить привилегии и открыть контент для чтения (иначе страницы не будут обслуживаться):

sudo chmod -R 755 /var/www

Теперь сервер имеет необходимые права доступа и может корректно обслуживать контент в соответствующих каталогах.

2: Создание демо-страниц

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

Для тестирования подойдут и самые простые страницы. Создайте для каждого домена страницу index.html:

Чтобы создать страницу index.html для первого сайта, наберите:

Добавьте в этот файл простой HTML-код:

Сохраните и закройте файл.

Скопируйте этот файл и используйте его в качестве шаблона для страницы второго сайта:

Откройте файл и подкорректируйте код:

Сохраните и закройте файл.

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

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

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

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

sudo mkdir /etc/nginx/sites-available
sudo mkdir /etc/nginx/sites-enabled

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

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

sudo nano /etc/nginx/nginx.conf

include /etc/nginx/sites-enabled/*.conf;
server_names_hash_bucket_size 64;

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

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

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

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

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

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

server listen 80;
server_name localhost;
location / root /usr/share/nginx/html;
index index.html index.htm;
>
error_page 500 502 503 504 /50x.html;
location = /50x.html root /usr/share/nginx/html;
>
>

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

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

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

try_files $uri $uri/ =404;

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

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

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

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

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

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

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

4: Включение блоков server

Теперь блоки server готовы к использованию и их нужно включить. Для этого создайте символьную ссылку для каждого блока в каталог sites-enabled:

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

sudo systemctl restart nginx

5: Настройка локальных хостов (опционально)

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

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

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

В системах Mac или Linux войдите как root-пользователь и откройте файл hosts:

sudo nano /etc/hosts

Пользователи Windows могут обратиться за инструкциями к сайту Microsoft.

На данном этапе понадобится внешний IP-адрес сервера и домен, который вы хотели бы использовать на сайте:

6: Тестирование настройки

Теперь нужно проверить работу блоков server. Для этого посетите домены в браузере:

Аналогичным образом нужно проверить и второй домен.

Если все настроенные сайты отвечают на запросы, значит, настройка виртуальных хостов Nginx прошла успешно.

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

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

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

Одна из основных возможностей веб-сервера - обслуживание нескольких сайтов на одном IP-адресе и в одной программе. Эта функция реализована с помощью виртуальных хостов. В этой статье мы разберём, как выполняется настройка виртуальных хостов в Nginx. Прежде чем читать статью дальше, я рекомендую просмотреть статью настройка Nginx, чтобы понять общий синтаксис конфигурационного файла.

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

Вообще, у Nginx только один конфигурационный файл - это /etc/nginx/nginx.conf. Все остальные файлы из папки /etc/nginx/* подключаются в этот файл с помощью директивы include. Поэтому теоретически все виртуальные хосты или только часть из них могут быть размещены в этом файле. Однако так делать не рекомендуется.

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

1. Синтаксис виртуального хоста

Каждый виртуальный хост представляет из себя такой блок кода:

server
listen ip_адрес:порт;
server_name доменные_имена;
root /путь/к/файлам/сайта/;
index index.php index.html;
.
location / <>
.
>

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

listen - указывает на IP-адрес и порт, на котором программа будет ожидать соединения от этого сайта. Чтобы выбрать любой IP-адрес, можно указать звёздочку, а порт указывать обязательно. Также в этой строке можно добавить параметр default_server, тогда этот виртуальный хост будет использоваться по умолчанию;
server_name - доменные имена, на которые будет отзываться этот хост. При отправке запроса на сервер, браузер указывает, к какому домену он обращается. Nginx анализирует этот параметр и выбирает необходимый виртуальный хост. Чтобы обрабатывать все домены, используйте символ подчеркивания _;
root - путь к файлам сайта, которые будут открываться при запросе к этому виртуальному хосту. У Nginx должен быть доступ на чтение ко всем папкам по этому пути;
index - файлы, которые будут открываться, если адрес файла не указан в URL;
location - это набор правил обработки путей в url. Каждый location может содержит путь URL а внутри него можно настроить открытие другого файла, аутентификацию, запрос к другому серверу и другие подобные вещи. Nginx анализирует все location в конфигурационном файле и выбирает самое подходящее. Из этого правила есть одно исключение. Если несколько location содержат регулярные выражения, то для обработки будет выбран первый подходящий.

2. Виртуальный хост по умолчанию

Теперь разберём создание виртуальных хостов nginx на примере. Давайте создадим виртуальный хост, который будет обрабатывать все необработанные запросы:

sudo vi /etc/nginx/sites-available/000-default.conf

server listen *:80 default_server;
server_name _;
root /usr/share/nginx/html;
index index.html index.htm;
location / <>

Все директивы, которые используются в блоке server, могут использоваться и в блоках location. Но нам не обязательно указывать root и index в каждом location. Если их опустить, то будут наследоваться те, которые были указаны в родительском блоке. Блоки server ведут себя аналогичным образом, поэтому, если мы не укажем другой путь к access.log, то будет использоваться путь, указанный в /etc/nginx/nginx.conf и так далее.

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

sudo ln -s /etc/nginx/sites-available/000-default.conf /etc/nginx/sites-enabled/000-default.conf

Затем убедитесь, что файлы из этого каталога подключены в основном конфигурационном файле:

sudo vi /etc/nginx/nginx.conf

Затем выполните эту команду, чтобы убедится, что вы не допустили ошибок:

Далее перечитайте конфигурацию nginx:

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

2. Виртуальный хост с доменом

sudo vi /etc/nginx/sites-available/example.conf

Если вы работаете на локальной машине и доступа к DNS выбранного домена у вас нет, то надо добавить его IP в файл /etc/hosts:

sudo vi /etc/hosts

3. Отключение виртуального хоста

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

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

Выводы

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

Нет похожих записей

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.

Недавно приняли решение переехать с хостинга на VPS, будем использовать: CentOS 7, Nginx, Apache, PHP, MySQL. Несмотря на большое количество статей на эту тему, многие аспекты не упоминаются, поэтому выкладываем эту статью чтобы услышать мнение знающих и опытных людей. Настраивать сервер как Вы уже поняли будем первый раз, поэтому о актуальности статьи можно будет судить из комментариев. Nginx будет отдавать статику, а динамику Apache (скрипты PHP), чтобы снизить нагрузку на сервер.

Все настройки будем применять на рабочем сервере нашего проекта с конфигурацией сервера: CPU — 2 × 2000 МГц и RAM — 2048 МБ.

Для начала работы находим подходящий VPS с предустановленной CentOS 7, к серверу будем подключаться по SSH через PuTTY.

Вводим название хоста и порт, нажимаем Open:

Далее вводим логин [Enter], потом пароль (обратите внимание, ввод пароля не отображается) [Enter]:

Обновить систему, при этом сохранить устаревшие версии пакетов:

Или обновить все пакеты, старые пакеты будут удалены:

Устанавливаем файловый менеджер с текстовым интерфейсом — Midnight Commander:

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

Создаём файловую структуру и пользователей под сайты.

Создаём каталог (папку) для файлов под все сайты:

Под каждый отдельный сайт выполните такие действия.

Содержимое каждого сайта будет находиться в собственном каталоге, поэтому создаём нового пользователя и отдельный каталог для разграничения прав доступа:
-b папка в которой будет создан каталог пользователя
-m создать каталог
-U создаём группу с таким же именем как у пользователя
-s /bin/false отключаем пользователю shell

Делаем каталоги для данных сайта (файлы сайта, логи и временные файлы):

Изменяем владельца и группу на каталог, включая вложенные папки:

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

Инструкции по установке приведены на официальном сайте Nginx.

Для настройки репозитория yum в CentOS создаём файл /etc/yum.repos.d/nginx.repo:

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

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

Временно останавливаем:

Настраиваем Nginx.

Добавляем в автозагрузку:

user nginx;
worker_processes 2;
pid /var/run/nginx.pid;

events worker_connections 1024;
multi_accept on;
>

charset utf-8;
server_tokens off;

include /etc/nginx/mime.types;
default_type application/octet-stream;

reset_timedout_connection on;
client_header_timeout 15;
client_body_timeout 30;
send_timeout 15;
keepalive_timeout 5;
keepalive_requests 30;
client_max_body_size 8m;

limit_rate_after 30M;
limit_rate 500K;

open_file_cache max=10000 inactive=3m;
open_file_cache_min_uses 2;
open_file_cache_valid 1m;

sendfile on;
tcp_nodelay on;
tcp_nopush on;

Указываем количество рабочих процессов (зависит от количества ядер процессора и количества жёстких дисков, потому что головка диска быстрее перемещаться не сможет):

Внутри блока events, максимальное количество одновременных соединении с сервером (worker_processes × worker_connections):

Внутри блока events, принимать соединения сколько будет возможно:

Записывать ошибки (уровня: warn, error, crit, alert) по указанному пути:

Отключаем запись журнала доступа (жёсткий диск скажет спасибо):

Если MIME-тип файла не удастся определить, то по умолчанию файл будет бинарным:

Читать заголовок запроса клиента не более 15 секунд:

Читать тело запроса клиента не более 30 секунд — интервал устанавливается не на всю передачу тела запроса, а только между двумя последовательными операциями чтения:

Если клиент не принимает ответ более 15 секунд, сбрасываем соединение:

Максимальное количество запросов с открытым соединением от одного клиента:

Чтобы один пользователь не занял весь свободный канал трафика, после 30 Мб наложим ограничение на скорость отдачи данных:

Максимальная скорость с клиентом в рамках одного соединения после наложенных ограничений будет не более 500 Кб/с:

Устанавливаем максимальное количество файлов, информация о которых будет содержаться в кеше и удаляться, если файл не будет запрошен повторно в течении 3 минут:

Если файл будет запрошен более 2 раз, поместить в кэш:

Для каждого сайта создаём виртуальный хост Nginx.

Чтобы Nginx получил доступ к файлам сайта, добавим пользователя nginx в группу name.site:

* \.(css|js|png|gif|jpg|jpeg|ico)$ root /website/name.site/www;
expires 1d;
>

error_page 500 502 503 504 /50x.html;
location = /50x.html root /usr/share/nginx/html;
>
>

Имя сервера, определяет в каком блоке будет выполнен запрос, указывается имя домена:

Обрывать коннект через 300 секунд, если превышен таймаут при чтении ответа с сервера Apache:

Передать список серверов по которым прошёл запрос и добавить свой:

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

* \.(css|js|png|gif|jpg|jpeg|ico)$ root /serves/name.site/www;
expires 1d;
>

Настраиваем Apache.

Посмотрите какой именно модуль Apache у вас установлен. У меня — apache2-mpm-prefork (один процесс с одним потоком будет обрабатывать одно соединение, рекомендуется как безопасный совместно с PHP):

ServerRoot "/etc/httpd"
DocumentRoot "/website"
Include conf.modules.d/*.conf

User apache
Group apache

Listen 127.0.0.1:8080
ServerName 127.0.0.1:8080
ServerAdmin root@localhost

ServerSignature Off
ServerTokens Prod

RLimitMEM 786432000
TimeOut 250

AddDefaultCharset utf-8
DefaultLanguage ru

KeepAlive Off
ContentDigest Off
EnableSendfile off

ErrorLog "logs/error_log"
LogLevel error

<IfModule mime_module>
TypesConfig /etc/mime.types
</IfModule>

<Directory />
DirectoryIndex index.php
AllowOverride none
Require all denied
</Directory>

<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 30
MaxRequestsPerChild 2500
</IfModule>

<Files ".ht*">
Require all denied
</Files>

Указываем IP и порт с которых будем принимать запросы, снаружи этот сервер видно не будет:

Адрес электронной почты который отправляется клиенту в случае ошибок:

Отключаем отправку информации версии системы и сервера Apache:

Отключаем отправку клиенту в заголовке информацию о Apache:

Максимальное время приёма запроса, обработки, отправки контента серверу Nginx:

Отключаем обработку большого количества запросов в одном соединении:

Apache статику отдавать не будет, поэтому отключаем:

<IfModule mime_module>
TypesConfig /etc/mime.types
</IfModule>

Внутри блока Directory, в случае указания пути до каталога, по умолчанию отдавать index.php::

Внутри блока Directory, запретить переопределение информации доступа в .htaccess:

Внутри блока Directory, запретить доступ к файлам сервера:

Внутри блока mpm_prefork_module, после запуска Apache создать 5 процессов:

Внутри блока mpm_prefork_module, минимальное количество неиспользуемых процессов (если все процессы будут заняты, то запустятся новые свободные процессы):

Внутри блока mpm_prefork_module, максимальное количество неиспользуемых (запасных) процессов:

Внутри блока mpm_prefork_module, максимальное количество дочерних процессов которые можно запустить одновременно, остальные встают в очередь (с увеличением дочерних процессов, увеличивается потребление памяти):

Внутри блока mpm_prefork_module, после указанного числа обработанных запросов, процесс перезапускается (необходимо при переполнении — утечки памяти):

Для каждого сайта создаём виртуальный хост Apache.

Добавляем пользователя apache в группу каждого сайта:

Создаём каталог под конфигурационные файлы виртуальных хостов Apache:

<Directory "/website/name.site">
AllowOverride None
Require all granted
</Directory>

ErrorLog /website/name.site/logs/error.log
CustomLog /website/name.site/logs/requests.log combined
</VirtualHost>

Блок VirtualHost, указывается какой порт слушать:

Если путь указан до каталога, по умолчанию открывать:

Проверка Nginx и Apache.

Добавляем Apache в автозагрузку:

Настраиваем PHP.

engine = On
expose_php = Off
short_open_tag = Off
zlib.output_compression = Off
disable_functions = exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source, etc

display_startup_errors = Off
display_errors = Off
log_errors = On
error_log = "/usr/local/zend/var/log/php.log"
ignore_repeated_errors = Off
ignore_repeated_source = Off
html_errors = On

implicit_flush = Off
output_buffering = 4K
realpath_cache_size = 2M
realpath_cache_ttl = 1800
zend.enable_gc = On

max_input_time = 200
max_execution_time = 30
file_uploads = On

memory_limit = 256M
post_max_size = 8M
upload_max_filesize = 2M
max_file_uploads = 4

extension_dir = "/usr/local/zend/lib/php_extensions"
date.timezone = Europe/Moscow
default_mimetype = "text/html"
default_charset = "UTF-8"

variables_order = "CGPS"
register_argc_argv = Off
auto_globals_jit = On
enable_dl = Off

allow_url_fopen = On
allow_url_include = Off

Включаем интерпретатор PHP, по необходимости можно выключить на конкретном сайте:

disable_functions = exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source, etc

Не выводить на экран ошибки возникшии во время старта PHP:

Логируем ошибки, после выключения их вывода на экран:

Не записывать одинаковые ошибки, которые проиcходят в конкретном файле и строке (ignore_repeated_source — нужно выключить):

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

Используем кэш realpath, тем самым уменьшая количество вызовов stat():

Указываем максимальное время в течении которого будут приниматься данные на сервер (POST, GET, HEAD), время измеряется с запуска PHP до момента выполнения скрипта:

Указываем максимальное время выполнения скрипта (значение не больше чем в Apache — Timeout) — вместо set_time_limit:

Максимальный размер памяти, который можно использовать скрипту:

Максимальный размер данных, отправляемых методом POST (должно быть меньше — memory_limit):

Максимальный размер закачиваемого файла (должно быть меньше — post_max_size):

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

Порядок обработки переменных — $_COOKIE, $_GET, $_POST, $_SERVER:

Переменные SERVER и ENV будут создаваться в момент использования, что приводит к увеличению производительности:

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

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

Количество параллельных процессов, обрабатывающих конкурентные запросы к MySQL (количество ядер умноженных на два):

Устанавливаем кодировку по умолчанию для новых таблиц:

Устанавливаем размер буфера индексов таблиц в оперативной памяти (актуально для таблиц MyISAM):

Максимальный размер оперативной памяти, выделяемой для временных таблиц, создаваемых MySQL:

Максимальное количество открытых таблиц, которые будут находиться в кэше:

Буфер данных, который используется для записи информации на диск — InnoDB:

Размер буфера который используется для сортировки (ORDER BY) или группировки GROUP BY) данных в каждом потоке:

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

Влияет на скорость сортировки, для запросов с — ORDER BY:

Размер буфера с использованием JOIN, если не используются индексы в этих запросах:

Размер стека, место для хранения списка задач (открыть или закрыть таблицу, выполнить запрос и т.п.):

Выделяем память для буфера соединения и его результатов, может быть увеличено до max_allowed_packet:

Максимальный размер данных, которые можно передать за один запрос:

Количество соединений, которые могут стоять в очереди:

Не использовать TCP/IP соединения, передавать данные через сокет:

Чтобы рассчитать примерное потребление оперативной памяти на сервере MySQL (насколько я понял) можно воспользоваться следующей формулой (не забывайте, что серверу Apache уже выделено 750 МБ и ещё нужно оставить серверу Nginx):

key_buffer_size + innodb_buffer_pool_size + tmp_table_size + ((sort_buffer_size + read_buffer_size + read_rnd_buffer_size + join_buffer_size + thread_stack) × max_connections) = ?

Немного про безопасность.

Под root заходить нежелательно, поэтому создаём нового пользователя:

Если вы подключаетесь к SSH через 22 порт, то нужно его изменить, открываем sshd_config:

Меняем порт на любой свободный (не забываем через установленный у вас firewall закрыть 22 порт и открыть новый, например 54139):

Разрешим логиниться в терминале только новому пользователю —
newuser:

P.S. Можно использовать Nginx с php-fpm, но есть такое мнение, что при правильно настроенном Apache особой разницы в производительности не наблюдается.

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

Читайте также: