Настроить DNS сервера на VDS, VPS сервере можно несколькими способами. Более того, если провайдер не ограничил вас в способах настройки DNS, то вы, как владелец сервера с правами root, можете настроить DNS сервера на VDS/VPS сервере, несколькими способами.

Что такое DNS, кратко

DNS это сервер доменных имен (Domain Name System) . Сервера доменных имен, объединенные в иерархическую структуру поддерживают и позволяют получить информацию, как компьютерам искать друг друга в Интернет. Работает это так: Вы набираете адрес ресурса в вашем браузере, ваш провайдер проверяет его через DNS (сервер доменных имен) введенный домен, чтобы знать, куда отправить сделанный вами запрос.

http://www.domain.com → проверка в системе DNS → DNS по домену ищет IP адрес ресурса domain.ru = IP: XX.XXX.XXX.XX → Вы получаете содержимое сайта.

Поэтому, чтобы ваш сайт нашли в Интернет по вашему домену, его нужно привязать к DNS серверам. На VDS/VPS серверах это можно сделать любым из возможных способах, существующих в Интернет.

Привязываем домен с помощью DNS серверов провайдера

Этот способ привязки домена проходит у любого провайдера. Нужно посмотреть адреса DNS серверов провайдера VDS и вписать их у регистратора имен во вкладке «Управление DNS». Так же можно привязать доменное имя к DNS серверам регистратора имен.

Настроить DNS сервера на VDS/VPS сервере через IP

Ваш имеет свой уникальный IP адрес. Раз IP уникален, то и свои домены к нему можно привязать. Делается это у регистратора имен. Сначала свой домен прикрепляете к серверам регистратора, а потом во вкладке «Управление DNS зоной», создаете три записи: [@], , и [*], типа А.

Создаем свои DNS сервера

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

Mожно настроить DNS сервера на VDS/VPS сервере на свои, вновь созданные, DNS сервера. Для этого нужен любой домен, можно тот домен, на который вы ставите WordPress. Каждый DNS сервер создается на отдельном IP адресе. Один IP адрес у вас есть и он является главным. На главном IP адресе сервера создаем первичный DNS сервер (ns1). Одного DNS сервера будет не достаточно, поэтому для создания вторичного DNS (ns2) нужно приобрести у провайдера еще один IP адрес. Созданные DNS сервера (ns1 и ns2) используются для всех доменов, создаваемых на сервере VDS.

Создать свои DNS сервера лучше до создания и .Чтобы создать свои DNS сервера в , во вкладке «Домены» выделяем нужный домен и открываем «Записи» домена. Делаем две новые записи типа «А», привязывая ns1 и ns2 к конкретным IP адресам.

Далее, в этих же записях, меняем записи типа «NS сервера имен». В поле «Имя» вписываем домен с точкой в конце. «Тип записи» выбираем «NS (сервер имен). В поле «Адрес» вместо DNS серверов провайдера, вписываем свои созданные поддомены ns1 и ns2 DNS серверов.

Созданные DNS сервера можно использовать для всех доменов сервера.

После изменения адресов ns1 и ns2 в типах записи NS (сервер имен), нужно поменять адреса NS серверов у вашего регистратора имен.

Важно! При смене доменных зон у регистратора, домен который используется для создания своих DNS, прописывается с указанием IP адресов сервера. На фото меняются DNS сервера для домена vpc-cоm.ru, который используется на сервере для создания своих DNS серверов. Как видите, нужно указать не только Имя DNS-сервера, но и IP адреса DNS-серверов. Для других доменов IP адреса указывать не нужно.

Привязываем домен, используя сторонние DNS сервера

Если вас беспокоит, что ваши DNS сервера лежат на вашем же сервере VDS, то прикрепите домен к сторонним DNS серверам. Самое простое, прикрепить домен к DNS серверам регистратора. Сложнее, «припарковаться» к специальному сервису Яндекс.

Лучшим, в смысле надежности, вариантом создания и использования DNS серверов для сервера VPS/VDS будет вариант, когда все DNS сервера будут лежать на разном «железе», то есть на двух или четырех разных DNS серверах. Например,

• DNS 1 делаете на своем домене и на главном IP адресе, который вам выделят при покупке сервера;
• DNS 2 вторичный dns делаете на стороннем сервере, чтобы он работал при падении вашего сервера DNS;
• Для большей надежности (скорее лишнее) можно также сделать DNS 3 и DNS 4, опять-таки используя третьи и четвертые сторонние DNS сервера.

Другие стати раздела: Установка WordPress

• Обновить WordPress вручную

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

Постановка задачи

Ситуация самая жизненная. Интернет-магазин, размещенный на шаред-хостинге, после запуска начал получать клиентов, но появились пожелания к функциональности, и разработчики активно занялись доработкой сайта. Выяснилось, что, когда в этом участвует несколько человек, постоянно копировать файлы через FTP для теста, да и еще на рабочий сайт, очень проблемно. Терялся контроль, кто когда что сделал, нужно было беспокоиться о сохранении оригинальных файлов, чтобы было легко откатиться. Владельцу приходилось или согласовывать правки, или копировать все самому. Разработчик не мог сразу посмотреть результат и ждал. Процесс сильно тормозился. В итоге пришли к тому, что нужно использовать возможности Git и создать новый сайт-зеркало, где можно было бы все обкатывать. При такой схеме разработчик мог сразу тестировать код, а в случае одобрения код переносили в master и выкладывали уже на рабочий сайт. Также можно легко отслеживать коммиты.

Вторая проблема: хостинг постоянно падал. Причину в итоге нашли: Entry processes limit - параметр, который определяет количество CGI/PHP-процессов, входящих внутрь виртуального контейнера, и о котором не сильно любят говорить маркетологи хостера. На графиках его тоже не видно, только маленькая графа в таблице. В итоге при небольших нагрузках CPU и RAM (не более 20%) сервер вообще не работал даже при минимальном количестве посетителей. В итоге было принято решение переезжать.

Первоначальные настройки сервера

OC в VDS устанавливается автоматически. Достаточно выбрать версию и вариант с веб-панелью или без и чуть подождать, пока не придет письмо с данными для входа. На хостингах предлагаются и разные веб-панели. Когда этот материал создавался, Vesta не поддерживала Ubuntu 16.04 и необходимости в ней не было, поэтому выбрали чистую систему. Все дальнейшие действия ведутся от имени root. Первым делом проверяем локаль, часовой пояс и время. Вообще, веб-приложения обычно не обращают внимания на некоторые системные настройки, но иногда попадается именно тот случай, поэтому лучше сразу сделать все правильно.

# locale

Если в ответ получаем отличное от ru_RU.UTF - перенастраиваем.

# locale-gen ru_RU ru_RU.UTF-8 ru_RU ru_RU.UTF-8 # localedef -c -i ru_RU -f UTF-8 ru_RU.UTF-8 # dpkg-reconfigure locales # update-locale LANG=ru_RU.UTF-8

Проверяем время:

Если часовой пояс не соответствует - переконфигурируем.

# dpkg-reconfigure tzdata

Обновляем сервер:

# apt update && apt upgrade

Теперь можем ставить сервисы.

Ставим веб-сервер

Несмотря на их разнообразие, выбор установки обычно сводится к трем вариантам: Apache, nginx или nginx как реверс Apache. Apache очень гибок в настройках и использует модули для обработки динамических запросов, поэтому хорошо справляется с динамикой. Nginx хорош в отдаче статики и потребляет меньше ресурсов, но для обработки динамики использует сторонний модуль, что снижает скорость и чуть усложняет настройки. В зависимости от конкретного приложения каждый из них может иметь свои плюсы и минусы и показывать разную скорость. Поэтому окончательный выбор веб-сервера всегда приходится подтверждать практикой, подбирая оптимальный вариант. Проблема nginx - то, что в некоторых специфических движках следует вручную возиться с редиректами, когда на Apache все будет работать буквально из коробки, достаточно просто включить mod_rewrite.

Нагрузочное тестирование можно произвести при помощи ab (Apache Benchmark, входит в apache2-utils) или siege. Причем лучше проверить с localhost и удаленного узла, чтобы видеть, как работает сеть.

# ab -c 10 -n 6000 http://example.org/

Хотя ab - это скорее для себя, чтобы оценить эффективность установок. Человека со стороны обычно интересует только то, что показывает Google PageSpeed , поэтому ориентироваться следует и на него.

В последнем случае сайт на старом хостинге давал 60, после переноса на VDS (с такими же параметрами) он в Apache в установке по умолчанию показывал 72, nginx с голым конфигом - 62, после добавления сжатия - 78. На этом и остановились, выбрали nginx. В репозитории несколько пакетов, для большинства ситуаций достаточно базового core, содержащего все основные модули, для PHP нам понадобится FPM.

# apt nginx install nginx php7.0-fpm

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

# nano /etc/nginx/nginx.conf http { .... open_file_cache max=200000 inactive=60s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; server_tokens off; server_names_hash_bucket_size 64; reset_timedout_connection on; client_body_timeout 10; gzip on; gzip_disable "msie6"; gzip_static on; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js; }

Создаем настройки для домена:

# nano /etc/nginx/sites-available/example.org server { listen 80; server_name example.org default; root /var/www/example.org; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; rewrite_log on; # Полезная настройка для отладки index index.php; try_files $uri $uri/ /index.php?$query_string; location ~ \.php$ { include /etc/nginx/fastcgi_params; # fastcgi_pass 127.0.0.1:9000; fastcgi_pass unix:/run/php/php7.0-fpm.sock; } # Кешируем картинки и txt/XML/JS/CSS. Можно убрать ненужное или что-то добавить location ~* ^.+\.(jpg|jpeg|gif|png|js|css|txt|xml)$ { access_log off; expires 30d; } # Блокируем доступ к каталогу.git (о нем дальше), по аналогии добавляем свои правила location ~ /\.git { deny all; } }

Это общий пример для стандартного движка. Некоторые движки вроде OpenCart или WebAsyst требуют специфических настроек, и даже не всегда работает то, что предлагается в Сети.

Проверяем, работает ли сжатие. Это можно сделать, просмотрев заголовок Content-Encoding в Firebug (он должен показывать gzip), или при помощи специального сервиса .

Включаем сайт:

# ln -s /etc/nginx/sites-available/example.org /etc/nginx/sites-enabled/example.org

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

# service nginx restart

Но работать еще не будет. Нужно настроить PHP. Для FPM все установки находятся в /etc/php/7.0/fpm. Проверяем, что в pool.d/www.conf учетная запись совпадает с используемой nginx и включен сокет.

# nano /etc/php/7.0/fpm/pool.d/www.conf user = www-data group = www-data listen = /run/php/php7.0-fpm.sock

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

Pm = dynamic pm.max_children = 15 pm.start_servers = 6 pm.min_spare_servers = 2 pm.max_spare_servers = 6

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

# cat /var/log/php7.0-fpm.log WARNING: server reached pm.max_children setting (5), consider raising it

Еще важный файл php.ini. Параметров там много, и можно рассказывать долго. Но изначально следует включить сжатие, установить максимальный размер файла на аплоад, подключить mail(), сессии и очень желательно включить акселератор OPcache.

# nano /etc/php/7.0/fpm/php.ini zlib.output_compression = On upload_max_filesize = 2M sendmail_path = sendmail -t -i session.save_path = "/var/lib/php/sessions" opcache.enable=1 opcache.memory_consumption=128 pcache.max_accelerated_files=2000

Обязательно проверяем права доступа на /var/lib/php/sessions, чтобы туда мог писать nginx, иначе сессии не будут образовываться. Перезапускаем.

# service php7.0-fpm restart

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

# tar -zcvf backup.tar.gz /var/www

И на новом месте распаковываем:

# tar -zxvf backup.tar.gz /var/www

Но для сайта нам нужна СУБД.

Ставим MySQL

C MySQL все очень просто. Вводим

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «сайт», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!

Настраивать cs сервер на vds, как и любой другой, следует привычным способом, как это делают все администраторы, работая с физическими серверами – разницы, принципиальной, нет никакой. Единственное, что обязательно советуют сразу после установки проделать, это добавить новоиспеченный сервер в мониторинг. Для этого нужно всего лишь в ISPmanager перейти в «Инструментах» на вкладку «Сервисы», где следует добавить новый сервис с названием «SAMP», именем процесса «samp02xsvr», запускающей командой «cd/hоme/имя пользователя/dаta/servеr/ ; ./sаmp02Xsvr &». Режим работы отмечается как «самостоятельный», а тип сервиса, как – «неизвестный». Также стоит проставить галочки в пунктах «Мониторинг» и «Автозагрузка».

Как настраивается сервер VDS?

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

Начало работы с VDS-сервером

Безусловно, получить собственный vds windows сервер можно исключительно после оформления соответствующих отношений с хостером, выбора тарифа и пакета услуг, а также их оплаты, если начинается сотрудничество не с тестировочного режима. Фактически придется vds сервер купить, скачать для него все необходимые клиенты и системы, после чего нужно его установить и заняться его качественной настройкой. Разумеется, для осуществления всего этого комплекса мероприятий арендатору необходимо иметь в штате соответствующей квалификации администратора и веб мастера, либо же (а существует и такая возможность) заказать услуги у самого хостера или работающей в этой области другой ИТ-компании, которые могут без вашего непосредственного участия произвести такие мероприятия, как установка и настройка vds сервера.

Понятие настройки VDS-серверов

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

• систем управления проектами;
• серверов баз данных;
• приложений, сформированных на основе общепринятых ЯП (perl, php, ruby, python);
• почтового сервера;
• системы контроля версий;
• оповещений о сбоях;
• интерапторов скриптовых языков;
• web-сервера;
• системы резервного копирования.

Исходные данные для настройки

После того, как вам удалось vds сервер купить, от хостера вы получаете IP-адрес своего сервера, логины и пароли администрирования для панели, а также для самого VDS, адрес, по которому панель управления может быть найдена. Пользователи в зависимости от выбранной ОС получают права администратора или root-а, в результате чего полную настройку могут осуществлять переходом по иконке «На сервер».

Настройка vds windows сервер

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

Итак, закажем и настроим свой собственный VPS . Заходим на https://www.hetzner.de/, в верхнем меню выбираем VServer (виртуальный сервер). Давайте выберем средний по цене, но вроде как с неплохими характеристиками: vServer CX30

Обратим внимание на цену: на немецком он предлагается за 14,16€ / Monat (14,16 евро в месяц), а после переключения на русский язык или USA: € 11.90 per month / 11,90€ / месяц.

Что за? Да, немцы своим дороже что ли продают? У них денег, видимо больше. Да ладно, переведём евро на рубли, сейчас Яндекс показывает 63,57 руб./ 1EUR – курс ЦБ РФ на 28/12/2016. Округлим до 65, получается сумма менее 1.000 руб: 11,90€ * 65 руб. = 773.50 руб/месяц.

Я думаю, неплохо, особенно после того как посмотрим на предлагаемую конфигурцию сего чуда:
Benefits: 2 vCores, RAM 4 GB RAM, SSD 100 GB, Connection: 1 Gbit/s NIC, Traffic: 8 TB, Snapshots: 3 . Что в переводе на русский означает 2 ядра (виртуальных), 4 гига оперативки, диск на 100 гигов (SSD), скорость связи 1 Гигабит/секунда, предел трафика – 8 Терабайт. Сразу замечу, что в комментарии указано, что при превышении предела трафика за месяц скорость подключения снизится до 10 Мегабит в секунду, но сервер по прежнему будет доступен. Да, и ещё в комплектацию входит поддержка до 3 снэпшотов, так что при желании можно откатиться.

Заказываем сервер

Ну что, друзья, неплохо за такие деньги или как? ОК, поехали! Вперед, без сомнений, этот сервер будет наш. Нажимаем кнопочку “Order now ” (“Заказать ” – да, сайт Hetzner.de поддерживает русский в том числе, да вообще много языков, но вот насчёт самой тех.поддержки не уверен, думаю, английским обойдёмся если что). А сама админка сервера (https://robot.your-server.de/server) у меня на английском, я честно говоря, доволен и так.

Operating systems without pre-installed control panel

• CentOS 6.8 minimal
• CentOS 7.2 minimal
• Debian 8.6 LAMP
• Debian 8.6 minimal
• openSUSE 42.1 minimal
• Ubuntu 16.04.1 LTS minimal
• Ubuntu 16.10 minimal
• Windows Server 2012 R2 Datacenter Edition (Price (monthly): € 130.25 / Setup (once): € 0.00)
• Windows Server 2012 R2 Standard Edition (Price (monthly): € 21.01 / Setup (once): € 0.00)

Operating systems with pre-installed control panel

• CentOS 7.2 + cPanel
• CentOS 7.2 + Plesk
• Debian 8.6 + Plesk
• Ubuntu 16.04.1 LTS + Plesk
• Windows Server 2012 R2 Datacenter Edition + Plesk (Price (monthly): € 130.25 / Setup (once): € 0.00)
• Windows Server 2012 R2 Standard Edition + Plesk (Price (monthly): € 21.01 / Setup (once): € 0.00)

То есть два списка – без контроль-панели и с ней (cPanel/Plesk).

Ребята, мы выбираем – Ubuntu 16.10 minimal без всяких панелей. Это минимальная система, в ней как я понял, дополнительно будут установлены основные системные утилиты (coreutils) и SSH. Как раз то, что нам нужно. Всё остальное – NGINX/PHP/MYSQL/POSTFIX/DOVECOT/PUREFTPD/SpamAssassin/FAIL2BAN и т.д. и т.п. (по-русски etc. ) мы установим сами, своими собственными ручками, тем более это не так уж и сложно и не так уж и долго, в частности благодаря APT ‘у.

На нашем сервере будет работать 3-4 сайта на NGINX/PHP-FPM , крутится радио и, возможно, экспериментальный сайтик на node.js . Также мы поставим FFMPEG и ImageMagic для беспрепятственной обработки видео/аудио/графики.

Потом, если у Вас нет аккаунта на Hetzner.de, Вам предложат его создать, ничего особенного, доволньо небольшая форма, и опосля предложат ввести данные своей банковской карты. Так как я этому сайту доверяю (кто не знает Hetzner.de ?) я без страха ввожу все нужные данные и… получаю сервер в свои руки.

Рабочая среда в Windows 10

Мне на почту пришло письмо буквально через 5-10 минут, что сервер готов к работе, здесь же мне указали рутовый пароль и ip-адрес нашего сервера. Итак, открываем свой любимый SSH-клиент, например, Putty и поехали!

Да, кстати, в своей Windows 10 я использую связку WinSCP + Putty . То есть захожу на файловую систему сервера под рутом через WinSCP по SFTP протоколу, здесь же могу копировать/удалять/править в виндовом редакторе (мой любимый сейчас AkelPad ) любой файл, а нажав на кнопочку Ctrl+P (Open session in PuTTY ) я моментально, без ввода пароля, попадаю в консоль PuTTY (конечно, всё это надо настроить в WinSCP предварительно, что делается буквально в несколько кликов мышки).

Настройка DNS

Лично я использую бесплатный Hurricane Electric Free DNS Management – https://dns.he.net/
А Hetzner.de предлагает подобную вещь за:

Nameserver Robot Administer DNS entries more information... Price (once): € 15.97 For Dedicated Root Server and vServer customers free of charge

Это 15,97 евро * 65 рублей = 1038,05 рублей. Это разовая оплата. Чем он лучше бесплатного? На бесплатный нельзя полагаться на 100%, хотя мы работаем с Hurricane Electric несколько лет и ни разу не было проблем (в отличие от https://entrydns.net/, который часто глючил, а потом стал просить денег, хоть и не больших).

Но тут нам раздумывать нечего – видите надпись – Free of charge for dedicated root server and vServer customers ? Да, для нашего виртульаного сервера он должен быть бесплатным. Но при заходе на https://robot.your-server.de/ мы нигде не видим ссылку на что-то подобное NS/DNS . Оказывается, его просто надо заказать дополнительно – заходим по ссылкам: Ordering – Domain Administration – Nameserver Robot – Order Product и видим:

Shopping cart Unit price Total price Monthly Setup Monthly Setup 1 x Nameserver Robot € 0.00 € 0.00 € 0.00 € 0.00 Total: € 0.00 € 0.00

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

Но, повторяюсь, я использую Hurricane Electric , поэтому здесь не стал заказывать.

Как настроить начальные и самые необходимые NS записи для сайтов рассказано здесь, на этом блоге (на примере Hurricane Electric Free DNS Management ) – . На Hetzner’е, думаю, настравается всё подобным образом. Настраиваем всё под наш новый ip сервера.

Первые шаги

Итак, смотрим, что уже у нас в действительности есть, держа в уме, что всё же это виртуалка, а не полноценный сервер. Но у нас пока нет десятков тысяч – миллионов клиентов, чтобы держать полноценный сервер или кластер таких серверов.
Все команды я будут выполнять от рута, так как у меня нет паранойи по этому поводу, ты через sudo сможешь накосячить также как и не через sudo . Да ладно, это дело в куса а не принципа.
Нас встречает приглашние вида:
root@Ubuntu-1610-yakkety-64-minimal ~ #

FQDN

Заздадим Fully Qualified Domain Name:
# hostname beotiger
# echo beotiger > /etc/hostname
# vim /etc/hosts
ip-адрес нашего сервера site2.ru

Теперь перелогинимся и получим приглашение root@beotiger ~ #

Итак, версия:

# uname -a
Linux beotiger 4.8.0-32-generic #34-Ubuntu SMP Tue Dec 13 14:30:43 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

# cat /etc/issue
Ubuntu 16.10 \n \l

Сколько памяти свободно:

# free -h
total used free shared buff/cache available
Mem: 3.9G 218M 2.8G 17M 841M 3.4G
Swap: 0B 0B 0B

Дисковое пространство:

# df -h
Filesystem Size Used Avail Use% Mounted on
udev 2.0G 0 2.0G 0% /dev
tmpfs 396M 8.7M 387M 3% /run
/dev/sda1 94G 2.1G 87G 3% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
tmpfs 396M 0 396M 0% /run/user/0

Итак, видим, что наша пока пустая система сжирает 218Мегабайт оперативки и 2.1Гиг нашего диска. Посмотрим, что будет после установки всех нужных нам сервисов! Для удобного просмотра состояние системы и процессов можно установить htop :

# apt install htop

Язык и timezone

Лично я предпочитаю английский в документации, сказывается давняя паранойя о плохом переводе. Поэтому локаль не меняю. А время всё же поменяю на московское, а то в логах буду путаться (я живу по московскому времени):

# apt install tzdata # dpkg-reconfigure tzdata

Выбираем пояс Europe/Moscow , и ребутнемся, вспомним времена Win98 (чтобы все наши уже запущенные службы стали использовать новый часовой пояс в логах и т.п.):

# reboot

Синхронизация времени

Внимание! NTP не нужен, если есть timesyncd и мы не собираемся выступать в роли ntpd сервера. Пакет: systemd: /lib/systemd/systemd-timesyncd
# timedatectl status
Local time: Fri 2016-12-30 12:13:22 MSK
Universal time: Fri 2016-12-30 09:13:22 UTC
RTC time: Fri 2016-12-30 09:13:22
Time zone: Europe/Moscow (MSK, +0300)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no

Строка NTP synchronized: yes говорит о том, что время синхронизируется успешно.

Устанавливаем LEMP-стек: NGINX + PHP 7.0 + MySQL

LAMP: Linux Apache MySQL PHP – минимальная готовая среда веб-разработки. Linux у нас есть, Apache мы поменяем на Nginx. Т.е. LAMP -> LEMP (Linux Nginx MySQL PHP). Итак, ставим, настраивать будем позже:

NGINX

NGINX самая простая и мощная вещь, как раз то, что я люблю больше всего:

# apt install nginx

Всё, у нас есть рабочий сервер. Уже можно зайти на http://ip-нашего-сервера и узреть стандартную дефолтную страницу nginx. Дефолтная папка сайта /var/www/html. Мы её трогатиь не будем, когда поставим PHP/MySQL, займёмся детальной настройкой и связкой NGINX+PHP7 (напомню, будем добавлять несколько сайтов)

Текущая версия nginx:

# nginx -v
nginx version: nginx/1.10.1 (Ubuntu)

Посмотреть текущие модули nginx (где-то видел хак на stackoverflow):

# 2>&1 nginx -V | tr -- - "\n" | grep _module
http_ssl_module
http_stub_status_module
http_realip_module
http_auth_request_module
http_addition_module
http_dav_module
http_geoip_module
http_gunzip_module
http_gzip_static_module
http_image_filter_module
http_v2_module
http_sub_module
http_xslt_module
stream_ssl_module
mail_ssl_module

В стандартном nginx -пакете есть только самые необохдимые модули. Если Вам нужны допонлительные модули, например, MP4, совсем не обязательно перекомпилировать nginx с сорцов.
Добавить модули в nginx можно так (ещё не пробовал):

# apt install nginx-extras

Возможная конфигурация с использованием модуля mp4:

Location /video/ {
mp4;
mp4_buffer_size 1m;
mp4_max_buffer_size 5m;
mp4_limit_rate on;
mp4_limit_rate_after 30s;
}

Смотрим, что содержиться в nginx-extras:

# apt show nginx-extras
Package: nginx-extras
Version: 1.10.1-0ubuntu1.2
Priority: optional
Section: universe/httpd
Source: nginx
Origin: Ubuntu
Maintainer: Ubuntu Developers
Original-Maintainer: Kartik Mistry
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 1,886 kB
Provides: httpd, httpd-cgi, nginx
Depends: nginx-common (= 1.10.1-0ubuntu1.2), perl (>= 5.22.2-3), perlapi-5.22.2, libc6 (>= 2.14), libexpat1 (>= 2.0.1), libgd3 (>= 2.1.0~alpha~), libgeoip1, libluajit-5.1-2, libpam0g (>= 0.99.7.1), libpcre3, libperl5.22 (>= 5.22.2), libssl1.0.0 (>= 1.0.2~beta3), libxml2 (>= 2.7.4), libxslt1.1 (>= 1.1.25), zlib1g (>= 1:1.1.4)
Suggests: nginx-doc (= 1.10.1-0ubuntu1.2)
Conflicts: nginx-core, nginx-full, nginx-light
Breaks: nginx (Много всего, нужно ли оно нам сейчас?! Как подключать/отключать нужные модули при запуске сервера/службы?

PHP 7.0

Конечно, будем стаить семёрку. По заявлению многих, она намного быстрее пятёрки. Не знаю, не проверял, но охотно верю! Заметьте, что пакет PHP7.0, который описывается так:

Php7.0/yakkety,yakkety,yakkety,yakkety 7.0.8-3ubuntu3 all
server-side, HTML-embedded scripting language (metapackage)

Предложит нам поставить apache, я не знаю почему, что в головах творится у этих собирателей пакетов под Юбунту? Сами смотрите:

# apt install php7.0 apache2 apache2-bin apache2-data apache2-utils libapache2-mod-php7.0 libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap liblua5.1-0 php-common php7.0-cli php7.0-common php7.0-json php7.0-opcache php7.0-readline psmisc ssl-cert apache2 apache2-bin apache2-data apache2-utils libapache2-mod-php7.0 libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap liblua5.1-0 php-common php7.0 php7.0-cli php7.0-common php7.0-json php7.0-opcache php7.0-readline psmisc ssl-cert 0 upgraded, 19 newly installed, 0 to remove and 0 not upgraded. Need to get 5,066 kB of archives. After this operation, 20.6 MB of additional disk space will be used. Do you want to continue? n

Nooooooooo, тут нажимаем n, нет, nicht, nope, ни в коем случае. Вы что творите, сборщики пакетов для Убунты?

Пакет php7.0-fpm:

Php7.0-fpm/yakkety,yakkety 7.0.8-3ubuntu3 amd64
server-side, HTML-embedded scripting language (FPM-CGI binary)

# apt install php7.0-fpm Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: php-common php7.0-cli php7.0-common php7.0-json php7.0-opcache php7.0-readline psmisc Suggested packages: php-pear The following NEW packages will be installed: php-common php7.0-cli php7.0-common php7.0-fpm php7.0-json php7.0-opcache php7.0-readline psmisc 0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded. Need to get 3,570 kB of archives. After this operation, 14.3 MB of additional disk space will be used. Do you want to continue? Y Creating config file /etc/php/7.0/cli/php.ini with new version Setting up php7.0-fpm (7.0.8-3ubuntu3) ... Creating config file /etc/php/7.0/fpm/php.ini with new version Created symlink /etc/systemd/system/multi-user.target.wants/php7.0-fpm.service → /lib/systemd/system/php7.0-fpm.service.

ИЗ: https://php-fpm.org/
PHP-FPM (FastCGI Process Manager) альтернатива PHP FastCGI со множеством новых полезных возможностей, подходящих для сайтов любых размеров, особенно для загруженных сайтов. Включают: Адаптивный запуск процессов! Статистика! These features include: Adaptive process spawning (NEW!) Basic statistics (ala Apache"s mod_status) (NEW!)

Итак, мы видим, что установились основные пакеты PHP7.0 - common , cli (для вызова PHP из командной строки), fpm - как раз то, что нам нужно для связи с NGINX, нашим вебсервером, json - полезная штука, мы её применяем практически во всех наших проектах, особенно основанных на AJAX, opcache - кэширование, readline - возможность проводить с PHP сессию типа интерактивного шелла, подробнее см. здесь: http://php.net/manual/en/features.commandline.interactive.php

Доустановим некоторые наиболее важные и нужные PHP-пакеты, часто используемые не только в наших проектах:

# apt install php7.0-curl php7.0-gd php7.0-mbstring php7.0-mcrypt php7.0-mysql php7.0-sqlite3 ... The following additional packages will be installed: libcurl3 libmcrypt4 Suggested packages: libmcrypt-dev mcrypt The following NEW packages will be installed: libcurl3 libmcrypt4 php7.0-curl php7.0-gd php7.0-mbstring php7.0-mcrypt php7.0-mysql php7.0-sqlite3

curl - общение с сетью из PHP ч/з удобный CURL API, gd - рисование графических примитов и текста, mbstring - поддержка мультибайтовых строк, mcrypt - криптование, кому оно сейчас не треба)), mysql и sqlite3 - именно эти БД я использую в своих проектах, вам могут понадобиться другие БД, например pgsql или sybase. Вообще список доступных пакетов PHP 7 можно посмотреть например так:

# apt search php7 Sorting... Done Full Text Search... Done libapache2-mod-php7.0/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 server-side, HTML-embedded scripting language (Apache 2 module) libphp7.0-embed/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 HTML-embedded scripting language (Embedded SAPI library) php-all-dev/yakkety,yakkety,yakkety,yakkety 1:44 all package depending on all supported PHP development packages php-symfony-polyfill-php70/yakkety,yakkety,yakkety,yakkety 1.2.0-1 all Symfony polyfill backporting some PHP 7.0+ features to lower PHP versions php7.0/yakkety-updates,yakkety-updates,yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 all server-side, HTML-embedded scripting language (metapackage) php7.0-bcmath/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 Bcmath module for PHP php7.0-bz2/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 bzip2 module for PHP php7.0-cgi/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 server-side, HTML-embedded scripting language (CGI binary) php7.0-cli/yakkety-updates,yakkety-updates,now 7.0.13-0ubuntu0.16.10.1 amd64 command-line interpreter for the PHP scripting language php7.0-common/yakkety-updates,yakkety-updates,now 7.0.13-0ubuntu0.16.10.1 amd64 documentation, examples and common module for PHP php7.0-curl/yakkety-updates,yakkety-updates,now 7.0.13-0ubuntu0.16.10.1 amd64 CURL module for PHP php7.0-dba/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 DBA module for PHP php7.0-dev/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 Files for PHP7.0 module development php7.0-enchant/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 Enchant module for PHP php7.0-fpm/yakkety-updates,yakkety-updates,now 7.0.13-0ubuntu0.16.10.1 amd64 server-side, HTML-embedded scripting language (FPM-CGI binary) php7.0-gd/yakkety-updates,yakkety-updates,now 7.0.13-0ubuntu0.16.10.1 amd64 GD module for PHP php7.0-gmp/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 GMP module for PHP php7.0-imap/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 IMAP module for PHP php7.0-interbase/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 Interbase module for PHP php7.0-intl/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 Internationalisation module for PHP php7.0-json/yakkety-updates,yakkety-updates,now 7.0.13-0ubuntu0.16.10.1 amd64 JSON module for PHP php7.0-ldap/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 LDAP module for PHP php7.0-mbstring/yakkety-updates,yakkety-updates,now 7.0.13-0ubuntu0.16.10.1 amd64 MBSTRING module for PHP php7.0-mcrypt/yakkety-updates,yakkety-updates,now 7.0.13-0ubuntu0.16.10.1 amd64 libmcrypt module for PHP php7.0-mysql/yakkety-updates,yakkety-updates,now 7.0.13-0ubuntu0.16.10.1 amd64 MySQL module for PHP php7.0-odbc/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 ODBC module for PHP php7.0-opcache/yakkety-updates,yakkety-updates,now 7.0.13-0ubuntu0.16.10.1 amd64 Zend OpCache module for PHP php7.0-pgsql/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 PostgreSQL module for PHP php7.0-phpdbg/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 server-side, HTML-embedded scripting language (PHPDBG binary) php7.0-pspell/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 pspell module for PHP php7.0-readline/yakkety-updates,yakkety-updates,now 7.0.13-0ubuntu0.16.10.1 amd64 readline module for PHP php7.0-recode/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 recode module for PHP php7.0-snmp/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 SNMP module for PHP php7.0-soap/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 SOAP module for PHP php7.0-sqlite3/yakkety-updates,yakkety-updates,now 7.0.13-0ubuntu0.16.10.1 amd64 SQLite3 module for PHP php7.0-sybase/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 Sybase module for PHP php7.0-tidy/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 tidy module for PHP php7.0-xml/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 DOM, SimpleXML, WDDX, XML, and XSL module for PHP php7.0-xmlrpc/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 XMLRPC-EPI module for PHP php7.0-xsl/yakkety-updates,yakkety-updates,yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 all XSL module for PHP (dummy) php7.0-zip/yakkety-updates,yakkety-updates 7.0.13-0ubuntu0.16.10.1 amd64 Zip module for PHP php7cc/yakkety,yakkety 1.1.0-1 amd64 command line tool to detect PHP 7 incompatible code

MySQL

Кто-то ставит MariaDB, возможно, ожидая подвоха от Oracle, но я как-то прикипел к MySQL:

# apt install mysql-server

Building dependency tree

The following additional packages will be installed:




mysql-server-5.7 mysql-server-core-5.7
Suggested packages:
libdata-dump-perl libipc-sharedcache-perl libwww-perl mailx tinyca
The following NEW packages will be installed:
libaio1 libcgi-fast-perl libcgi-pm-perl libencode-locale-perl libevent-core-2.0-5
libfcgi-perl libhtml-parser-perl libhtml-tagset-perl libhtml-template-perl
libhttp-date-perl libhttp-message-perl libio-html-perl liblwp-mediatypes-perl
libtimedate-perl liburi-perl mysql-client-5.7 mysql-client-core-5.7 mysql-common
mysql-server mysql-server-5.7 mysql-server-core-5.7
0 upgraded, 21 newly installed, 0 to remove and 0 not upgraded.
Need to get 20.3 MB of archives.
After this operation, 172 MB of additional disk space will be used.

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

Связываем Nginx с PHP, создаём сайты

Итак, мы установили полный стек LEMP, теперь будем создавать сайты, создадим 3 сайта, остальные добавляем по подобию.

Названия и адреса наших сайтов:
1. site.ru
2. site.org
3. site.com

Для каждого сайта создадим в каталоге /var/www одноименные с именем сайта папки: site.ru site.org site.com. В каждой из этих папок создадим три подпапки:

• tmp - для сессий и загрузок файлов
• log - для логов nginx
• web - для www данных (само содержимое сайта)

cd / var/ www mkdir -p site.ru/ { tmp,web,log} mkdir -p site.org/ { tmp,web,log} mkdir -p site.com/ { tmp,web,log}

Также для каждого сайта будем создавать своего юзера с именам web1, web2, web3 и т.д. (при добавлении 4-го сайта создадим юзера web4, см. ниже). для каждого юзера будем использовать группу www-data.

Итак, добавляем пользователей и устанавливаем права доступа на соотв. папки. Все команды напомню осуществляем под root"ом:

useradd -m -d / var/ www/ site.ru -s $(which bash ) -G www-data web1 useradd -m -d / var/ www/ site.org -s $(which bash ) -G www-data web2 useradd -m -d / var/ www/ site.com -s $(which bash ) -G www-data web3 cd / var/ www chown web1:www-data -R site.ru chown web2:www-data -R site.org chown web3:www-data -R site.com passwd web1 passwd web2 passwd web3

Запомним пароли для пользователей web1, web2 и web3, они пригодятся нам далее для доступа к сайтам через FTP (см. далее по тексту).

PHP конфиг

Создадим конфигурационные файлы PHP-FPM для каждого юзера/сайта. Каждый сайт у нас будет обслуживаться своими PHP-FPM процессами, чтобы распределить нагрузку по всем сайтам. Названия конф файлов web.conf, они находятся в папке /etc/php/7.0/fpm/pool.d, PHP-FPM при запуске подключает всё оттуда. Итак, пример конфигурации для сайта site.ru (юзера web1):

cd / etc/ php/ 7.0 / fpm/ pool.d vim web1.conf

Содержимое web1.conf:

listen = /run/php/php7.0-fpm1.sock
listen.owner = web1
listen.group = www-data
listen.mode = 0660

user = web1
group = www-data

pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 5
pm.max_requests = 0

php_admin_value = /var/www/site.ru/web:/var/www/site.ru/tmp
php_admin_value = /var/www/site.ru/tmp
php_admin_value = /var/www/site.ru/tmp
php_admin_value = "/usr/sbin/sendmail -t -i"

security.limit_extensions = .php .html

Отметьте параметры:

listen = /run/php/php7.0-fpm1.sock - указываем на каком сокете будет слушать процесс PHP-FPM, он нам пригодится для настройки NGINX (см. ниже).

listen.owner = web1
listen.group = www-data - владелец/группа прав доступа к сокету

user = web1
group = www-data - владелец/группа запущенного процесса при подключении к сокету

php_admin_value - указываем, в какие папки будет иметь доступ владелец процесса
php_admin_value - указываем, в какой папке будут храниться сессии
php_admin_value - указываем, в какую папку будут скачиваться файлы (upload)
php_admin_value - команда отправки почты, иcпользуемая функцией PHP mail . Настройкой почты мы займёмся чуть позже.

Для остальных двух сайтов - копируем файл web1.conf и поменяем юзера (web1 -> web2 -> web3), сокет - /run/php/php7.0-fpm1.sock -> /run/php/php7.0-fpm2.sock -> /run/php/php7.0-fpm3.sock и папку site.ru -> site.org -> site.com

cd / etc/ php/ 7.0 / fpm/ pool.d cp web1.conf web2.conf vim web2.conf cp web2.conf web3.conf vim web3.conf

Настраиваем NGINX

Настройки сайтов хранятся в папке /etc/nginx/sites-available - доступные сайты. Чтобы сделать сайт активным и видимым nginx на него делают мягкую ссылку (симлинк) отсюда в папку /etc/nginx/sites-enabled - активные сайты.

Итак, заходим в папку /etc/nginx/sites-available и создаём файл для настроек первого сайта. Имя файла конечно же может быть любым, мы будем делать имена файлов в виде имён сайтов с добавления суффикса.vhost, чтобы показать, что это настройки виртуального хоста. А симлинки будем назвать по имени используемого пользователя, чтобы видеть, каким именно пользователем мы используем данный сайт. Эта информация может пригодится, например, ч/з полгода, если мы давно не будем заглядывать сюда и у нас вылетит из головы, каких пользователей под какие сайты мы задавали - в этом случае будет не обязательно копаться в файлах настроек Nginx и PHP. Итак, приступим:

cd / etc/ nginx/ sites-available/ vim site.ru.vhost ln -s site.ru.vhost / etc/ nginx/ sites-enabled/ web1

Полное содержимое файла site.ru.vhost :

Server { listen *:80; server_name site.ru www.site.ru; root /var/www/site.ru/web; index index.html index.php; error_log /var/www/site.ru/log/error.log; access_log /var/www/site.ru/log/access.log combined; location ~ /\. { deny all; access_log off; log_not_found off; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } location ~* \.(js|css|png|jpg|jpeg|gif|svg)$ { expires max; # log_not_found off; } location ~ \.(php|html)$ { try_files /d58f8ccd9bffa83ebec930554209111f.htm @php; } location @php { try_files $uri =404; include /etc/nginx/fastcgi_params; fastcgi_pass unix:/run/php/php7.0-fpm1.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_intercept_errors on; } }

Бегло пробежимся по настройкам. Итак,

Root /var/www/site.ru/web;

Как мы и говорили вначале, корень сайтов будет лежать в папке web.

Location ~ /\. {
deny all;
access_log off;
log_not_found off;
}

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

Location @php {
try_files $uri =404;
include /etc/nginx/fastcgi_params;
fastcgi_pass unix:/run/php/php7.0-fpm1.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_intercept_errors on;
}

Этот блок связывает NGINX с PHP-FPM ч/з сокет /run/php/php7.0-fpm1.sock - именно этот сокет мы задавали в web1.conf в качестве параметра для listen.

Остальные сайты делаем по образу и подобию site.ru.vhost - копируем, меняем в файле имя сервера и корневой путь к сайту (параметры server_name и root ), не забываем исправить пути в error_log и access_log, и главное - не забудем указать другой сокет в параметре fastcgi_pass - это будет unix:/run/php/php7.0-fpm2.sock для site.org и unix:/run/php/php7.0-fpm3.sock для сайта site.com . После создания файлов в папке sites-available делаем на них симлинки в папку sites-enabled:

cd / etc/ nginx/ sites-available/ cp site.ru.vhost site.org.vhost vim site.org.vhost ln -s site.org.vhost / etc/ nginx/ sites-enabled/ web2 cp site.ru.vhost site.com.vhost vim site.com.vhost ln -s site.com.vhost / etc/ nginx/ sites-enabled/ web3

После создания и каждого изменения конфигурационых файлов следует перезапускать соотв. службу. Мы меняли конфиги для PHP-FPM и NGINX, поэтому выполняем следующие две команды:

service nginx reload service php7.0-fpm reload

Если нет ошибки в запуске служб, заходим на наши сайты и любуемся ими! Для проверки создадим файл 1.php с содержимым:

Закинем его в папку /var/www/site.ru/web .
Теперь при заходе на site.ru/1.php мы должны увидеть экран с текущими настройками PHP, типа такого:

Смотрим текущие параметры, подключенные модули PHP и убедждаемся в том, что всё вроде настроено как надо. Тоже самое повторим для сайтов site.org и site.com .

Ещё добавлю один нюанс - иногда организация нашего сайта требует, чтобы все запросы к сайту шли через один шлюз, обычно это index.php . То есть какой бы путь мы ни указали при обращении к сайту, управление будет передано именно index.php . В nginx есть несколько способ организовать подобное и я приведу способ, который используем мы для одного из наших сайтов.
Итак, вот конфиг NGINX для сайта, к которому все запросы (правда, кроме обращения к папке inc , в которой у нас хранятся публичные ресурсы - картинки, JavaScripts и CSS-файлы), идут напрямую index.php, а там мы уже решаем, что делать с данным запросом:

Server { listen *:80; server_name site.com www.site.com; root /var/www/site.com/web; index index.html index.php; error_log /var/www/site.com/log/error.log; access_log /var/www/site.com/log/access.log combined; location ~ /\. { deny all; access_log off; log_not_found off; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } location ~* \.(js|css|png|jpg|jpeg|gif|svg)$ { expires max; # log_not_found off; } location ~ \.(php|html)$ { try_files /d58f8ccd9bffa83ebec930554209111f.htm @php; } location @php { try_files $uri =404; include /etc/nginx/fastcgi_params; fastcgi_pass unix:/run/php/php7.0-fpm3.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_intercept_errors on; } location /inc/ {} location / { rewrite ^ /index.php last; } }

В этом конфиге самые интересные такие блоки:

Location /inc/ {}
location / {
rewrite ^ /index.php last;
}

Первый блок приказывает nginx обрабатывать путь к папке inc как есть, а второй блок все запросы перенаправляет файлу index.php .

Добавляем 4-ый сайт: site2.ru - web4

cd / var/ www mkdir -p site2.ru{ tmp,web,log} useradd -m -d / var/ www/ site2.ru -s $(which bash ) -G www-data web4 passwd web4 chown web4:www-data -R / var/ www/ site2.ru cp / etc/ php/ 7.0 / fpm/ pool.d/ web3.conf / etc/ php/ 7.0 / fpm/ pool.d/ web4.conf vim / etc/ php/ 7.0 / fpm/ pool.d/ web4.conf cp / etc/ nginx/ sites-available/ site.com.vhost / etc/ nginx/ sites-available/ site2.ru.vhost vim / etc/ nginx/ sites-available/ site2.ru.vhost ln -s / etc/ nginx/ sites-available/ site2.ru.vhost / etc/ nginx/ sites-enabled/ web4 service nginx reload service php7.0-fpm reload

Настройка FTP сервера

Прежде чем приступить к настройкам почты, настроим FTP сервер, чтобы можно было заходить по FTP(FTPS) в папку сайта и обновлять его. Инсталлируем pure-ftpd :

# apt install pure-ftpd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
pure-ftpd-common
The following NEW packages will be installed:
pure-ftpd pure-ftpd-common
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 263 kB of archives.
After this operation, 796 kB of additional disk space will be used.
Do you want to continue? y

Настройка Pure-ftpd осуществляется оригинально - надо в папке /etc/pure-ftpd/conf создать файл с именем параметра и вписать требуемое значение в его содержимое. Странно, но ладно. Итак, давайте создадим исполняемый скрипт, который будет задавать нужные нам настройки и потом запустим его:

vim / root/ pureftpd-conf.sh #!/bin/sh echo "yes" > ChrootEveryone echo "50" > MaxClientsNumber echo "10" > MaxClientsPerIP echo "no" > VerboseLog echo "yes" > DisplayDotFiles echo "no" > ProhibitDotFilesWrite echo "yes" > NoChmod echo "yes" > NoAnonymous echo "yes" > DontResolve echo "15" > MaxIdleTime # 1 - simple or TLS, 2 - TLS only echo "2" > TLS # allow unux users FTPing echo "yes" > UnixAuthentication echo "1000" > MinUID

Кратко описание настроек: мы делаем chroot для всех, чтобы не лазали по всему нашему серверу, отображаем файлы начинающиеся с точки (в Юникс это типа скрытые файлы) и разрешаем их читать/писать, запрещаем анонимный вход, задаём 15 минут макс. возможного простоя, также обязуем всех клиентов использовать TLS (шифрование) - строка echo "2" > TLS . Конечно, рекомендуется всегда где возможно использовать шифрование, чтобы MIM (men in the middle) не могли перехватывать наши файлы. То есть перехватывать они смогут по-любому, но расшифровать - вряд ли. Недостаток шифрования - более медленная скорость передачи файлов, т.к. тратится время на шифровку/дешифровку. Чтобы полностью отключить шифрование, надо в TLS вписать 0, чтобы разрешить обычные и шифрованный трафик - сюда вписать единичку (1).
Также важен последний параметр echo "yes" > UnixAuthentication . Помните юзеров, которые мы создавали в связке PHP - NGINX (web1, web2 web3 и т.д.) Теперь мы можем использовать их также в качестве FTP-юзеров. Используем теже пароли, что мы задавали при их создании.

Для того, чтобы использовать TLS, создадим самоподписной сертификат:

# openssl req -x509 -nodes -days 7300 -newkey rsa:2048 -keyout / etc/ ssl/ private/ pure-ftpd.pem -out / etc/ ssl/ private/ pure-ftpd.pem

После всех манипуляций перезапустим наш демон:

# service pure-ftpd restart

PureFTPD пишет логи в syslog. Смотреть:

# tail -f /var/log/syslog

Всё, теперь мы можем соеднияться по FTP(S) (S - secure), указывая пользователей web1,web2, web3 , при этом они по умолчанию будут попадать в свои домашние папки, которые являются папками их сайтов.

Настройка почты - Postfix + Dovecot

Итак, у нас есть работающию сайты и FTP доступ к ним, чтобы заливать/обновлять/удалять контент на этих сайтах. Также мы можем работать с базами данных MySQL/SQlite .

Для полноценной работы нам осталось настроить почту, чтобы отсылать/получать письма на своих сайтах или в своей системе. Система почты в общем случае состоит из двух компонентов MTA - mail transer agent, агент передачи почты и MDA - mail delivery agent, агент доставки почты. В качестве золотой пары мы будем использовать Postfix + Dovecot , как наиболее популярные на сегодня, и не зря, по-моему скромному мнению. Итак, инсталлируем пакеты, настраиваем конфиги и создаём почтовые домены и ящики. Поехали!

Шаг 1: Инсталлируем пакеты и устанавливаем сертификат

# apt install postfix postfix-mysql dovecot-core dovecot-imapd dovecot-lmtpd dovecot-mysql dovecot-pop3d
В диалоговом окне указываем: Internet Site, site.ru
Создаём ключ/сертификат dovecot.key и dovecot.pem:
# openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/ssl/private/dovecot.key -out /etc/ssl/certs/dovecot.pem
Мои ответы на вопросы в порядке их возникновения: RU Volgograd Volgograd Justbeo CEO beotiger [email protected]

Проверяем доступность наших доменов для почты:
# dig MX site.ru +short @ns1.he.net
10 mail.site.ru.
# host mail.site.ru ns1.he.net

Using domain server:
Name: ns1.he.net
Address: 216.218.130.2#53
Aliases:

mail.site.ru has address 131.21.128.229

Шаг 2: Создаём базу данных MySQL, виртуальные домены, пользователей и альясы

Создадим особую БД для хранения наших виртуальных доменов, пользователей и альясов. Назовём её к примеру vmail . В этой базе создадим виртуальные домены под все наши 3 сайта, а также двух пользователя для двух сайтов:

# mysqladmin -p create vmail
mysql > GRANT SELECT ON vmail.* TO "vmail"@"127.0.0.1" IDENTIFIED BY "password";
mysql > FLUSH PRIVILEGES;
mysql> USE vmail;
mysql> CREATE TABLE `domains` (

`name` VARCHAR(50) NOT NULL,
PRIMARY KEY (`id`)

mysql> CREATE TABLE `users` (
`id` INT NOT NULL AUTO_INCREMENT,
`domain_id` INT NOT NULL,
`password` VARCHAR(106) NOT NULL,
`email` VARCHAR(120) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `email` (`email`),

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

mysql> CREATE TABLE `aliases` (
`id` INT NOT NULL AUTO_INCREMENT,
`domain_id` INT NOT NULL,
`source` varchar(100) NOT NULL,
`destination` varchar(100) NOT NULL,
PRIMARY KEY (`id`),
FOREIGN KEY (domain_id) REFERENCES domains(id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Наши виртуальные домены. id по умолчанию начинается с 1:
mysql> INSERT INTO `domains` (`name`)
VALUES ("site.ru"), ("site.org"), ("site.com");

mysql>
VALUES
("1", ENCRYPT("pass1", CONCAT("$6$", SUBSTRING(SHA(RAND()), -16))), "[email protected]"),
("2", ENCRYPT("pass2", CONCAT("$6$", SUBSTRING(SHA(RAND()), -16))), "[email protected]");

Добавляем ещё одного пользователя для site.com, не забываем про правильный domain_id:
mysql> INSERT INTO `users` (`domain_id`, `password` , `email`)
VALUES ("3", ENCRYPT("pass3", CONCAT("$6$", SUBSTRING(SHA(RAND()), -16))), "[email protected]");

Note: Warning | 1287 | "ENCRYPT" is deprecated and will be removed in a future release. Please use AES_ENCRYPT instead

Добавляем альяс [email protected], который будет ссылаться на [email protected], то есть письмо на [email protected] уйдёт пользователю [email protected]. Важно - следует свериться с ид домена из таблицы domains, чтобы поле domain_id ему соответствовало:
mysql>
VALUES ("1", "[email protected]", "[email protected]");

Аналогично добавляем другие нужные альясы. Чтобы добавить глобальный альяс, который будет пересылать письма, уходящие на любой неопределенный адрес выбранного домена определенному пользователю данного домена:
mysql> INSERT INTO `aliases` (`domain_id`, `source`, `destination`)
VALUES ("1", "@site.ru", "[email protected]");

Завершаем сеанс работы с MySQL:
QUIT;

Шаг 3: Конфигурируем Postfix

Основные настройки Postfix находятся в двух файлах - main.cf и master.cf . В master.cf можно переопределять некоторые настройки для определённых служб (флаг -o - override, переопределить). Начнём с main.cf . Кратко. что мы тут делаем: используем шифрованние TLS, виртуальные домены и пользователей ч/з MySQL базу, Dovecot. переопределяем только указанные ниже настройки, остальные оставляем по умолчанию, как они были в main.cf изначально:

# cp /etc/postfix/main.cf /etc/postfix/main.cf.orig
# vim /etc/postfix/main.cf
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/dovecot.pem
smtpd_tls_key_file=/etc/ssl/private/dovecot.key
smtpd_use_tls=yes
smtpd_tls_auth_only = yes

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination

# mydestination = $myhostname, site.com, localhost.com, localhost
mydestination = localhost, localhost.localdomain
myhostname = site.com
## Tells Postfix to use Dovecot"s LMTP instead of its own LDA to save emails to the local mailboxes.
virtual_transport = lmtp:unix:private/dovecot-lmtp
## Tells Postfix you"re using MySQL to store virtual domains, and gives the paths to the database connections.
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf

Создаём нужные файлы:

# vim /etc/postfix/mysql-virtual-mailbox-domains.cf
user = vmail
password = gR29eZ34
hosts = 127.0.0.1
dbname = vmail
query = SELECT 1 FROM domains WHERE name="%s"

# vim /etc/postfix/mysql-virtual-mailbox-maps.cf
user = vmail
password = gR29eZ34
hosts = 127.0.0.1
dbname = vmail
query = SELECT 1 FROM users WHERE email="%s"

# vim /etc/postfix/mysql-virtual-alias-maps.cf
user = vmail
password = gR29eZ34
hosts = 127.0.0.1
dbname = vmail
query = SELECT destination FROM aliases WHERE source="%s"

Проверка:

service postfix restart postmap -q site.ru mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf postmap -q [email protected] mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf postmap -q [email protected] mysql:/etc/postfix/mysql-virtual-alias-maps.cf

Первые две проверки должны вернуть 1, третья - email для альяса: [email protected]

vim /etc/postfix/master.cf

Submission inet n - - - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject

Проверим все установки Postfix и сделаем рестарт его (релоада недостаточно что ли?):

postconf -n service postfix restart

Шаг 4: Конфижим Dovecot

Создаём копии на всякий случай:

cp /etc/dovecot/dovecot.conf /etc/dovecot/dovecot.conf.orig cp /etc/dovecot/conf.d/10-mail.conf /etc/dovecot/conf.d/10-mail.conf.orig cp /etc/dovecot/conf.d/10-auth.conf /etc/dovecot/conf.d/10-auth.conf.orig cp /etc/dovecot/dovecot-sql.conf.ext /etc/dovecot/dovecot-sql.conf.ext.orig cp /etc/dovecot/conf.d/10-master.conf /etc/dovecot/conf.d/10-master.conf.orig cp /etc/dovecot/conf.d/10-ssl.conf /etc/dovecot/conf.d/10-ssl.conf.orig vim /etc/dovecot/dovecot.conf

...
!include_try /usr/share/dovecot/protocols.d
protocols = imap lmtp pop3

Твитнуть

Предыстория

Лучший способ развиваться - делиться накопленным опытом.

Раньше для запуска сайтов мне было достаточно shared-хостинга. Это разумная экономия, если посещаемость сайтов небольшая. Так продолжалось до 2014 года, когда в руки попал довольно посещаемый ресурс, запущенный на VPS и при этом сильно тормозящий. Шутка ли - страницы могли генерироваться по 10 секунд! На домашней Убунте я не раз ставил стек программ LAMP командой sudo apt-get install lamp-server^ , раскидывая сайты по разным папкам и составляя несложные конфиги, поэтому первым делом перенёс сайт на своё «железо». На домашнем ПК он заработал довольно шустро, поэтому решил, что на сервере нужно просто переустановить софт с нуля. Глубокой ночью, когда посетителей было мало, поставил Ubuntu 12.04.4 (тогда была самой актуальной версией), Apache+PHP+MySQL+phpmyadmin+proftpd и запустил сайт. Увы - генерация страниц как длилась по 5-10 секунд, так и продолжила отнимать драгоценное время.

Стал копать дальше и убедился, что дело было в самописных компонентах CMS (это была Joomla, кстати). Переписывать тормозящий программный код CMS, с которым я не знаком, не лучшее решение, когда работу нужно выполнить в сжатые сроки. Поэтому прикрутил компонентам кэширование и аллилуйя - тормоза исчезли! Страницы стали загружаться за 0,7-0,9 секунд, это более чем пятикратный прирост производительности.

Я дам прямой ответ на вопрос: как же сделать так, чтобы запущенный на дешёвом, медленном сервере сайт работал быстро.

Выбор VPS

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

Выбор ОС для сервера (Ubuntu Server 16.04)

Обычно хостинг даёт возможность выбрать операционную систему для вашего сервера. Большинство предлагаемых - различные дистрибутивы Linux: Debian, Ubuntu, Arch Linux, CentOS, OpenSUSE, Fedora, Gentoo и другие.

На персональном компьютере можете ставить что угодно, но на серверах важна стабильность. На мой взгляд, Ubuntu 16.04 - разумный компромисс между новыми версиями софта и стабильностью. Инструкции для Debian подходят и для Убунты, а значит - начинающим пользователям будет раздолье в плане повышения навыков и поиска ответа на вопросы. Потом при желании можно переключиться на CentOS или вообще FreeBSD, но для начала, чтобы избежать головной боли при настройке, лучше Убунты ничего не придумали.

Моё субъективное мнение о популярных дистрибутивах:

• CentOS (любая версия): новичкам будет тяжело, ибо инструкций не очень много. В репозиториях доступны довольно свежие версии софта.
• Debian (любая версия): оперативной памяти занимает немного, что помогает быстрее работать сайту с высокой посещаемостью за счёт выделения памяти кэшу и PHP с MySQL (после тонкой настройки, конечно), но в репозитории доступны старые, проверенные версии PHP, из-за чего скорость работы сайтов будет не так высока, как могла бы быть. Инструкций много, начинающие пользователи разберутся, но настройка требует времени.
• Ubuntu Server 16.04: серверная версия популярного дистрибутива Linux. Версия 16.04 будет поддерживаться до апреля 2021 г. - это значит, что после настройки вы четыре года сможете просто обновлять софт. Обновления важны, потому что в новых версиях исправляются найденные уязвимости и устраняются ошибки. Версии программ в репозитории Ubuntu 16.04 относительно свежие. Например, на момент написания статьи доступна PHP 7.0, дающая 30% прирост производительности по сравнению с PHP 5.6, идущей по умолчанию в Debian 8.
• Ubuntu Server 16.10, 17.04, 17.10: версия 16.10 уже вышла, но обновления безопасности прекратят приходить в июле 2017 года, придётся обновлять всю систему целиком до 17.04. На момент написания статьи 17.04 готовится к выходу, а 17.10 пока только в планах, их тоже ставить нет смысла: это не LTS-релизы, а значит, они тоже быстро превратятся в тыкву.

У любителей настраивать всё ручками можно знатно пригореть от того, что я предлагаю Ubuntu Server 16.04 в качестве основы для веб-сервера, ведь есть CentOS/FreeBSD/Что-то_ещё_OS. Выбор в мире свободного софта - всегда конфликт и холивары. Моя позиция такова: Ubuntu - хороший старт, начните с неё, а дальше у каждого свой путь.

Как подключиться к VPS

Вам нужно понимать, что такое консоль и какие команды бывают. Дело в том, что каждый хостинг стремится сделать собственную сборку ВПС-ки. Например, устанавливает Apache, MySQL, правит конфиги. Поэтому нужно уметь смотреть логи и понимать, что происходит.

Итак, ОС выбрали, сервер заказали, в админке хостинга появился IP-адрес сервера, имя пользователя и пароль для доступа по SSH. Как подключиться к ВПСке?

Управление сервером осуществляется через терминал (консоль) путём ввода команд. Обычно к консоли подключаются по протоколу SSH с помощью соответствующих программ. Я рекомендую использовать Putty как самую распространённую: ссылка на самую новую версию. Версия с MSI-инсталлятором (первая ссылка в списке) - наиболее полный комплект. Или можете использовать форк (модификацию) Putty под названием KiTTY, где добавлено много полезного по сравнению с оригинальной программой.

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

Инструкция подходит к Ubuntu 16.04 и 16.10. Пожалуйста, не спрашивайте меня об установке софта на CentOS и другие дистрибутивы - это тема отдельной статьи.

Вход на сервер через Putty

Для входа нужна только первая вкладка в стартовом окне Putty:

1 - сюда введите IP-адрес вашего сервера;

2 - порт, по умолчанию 22;

3 - введите любое название;

4 - сохранение настроек под именем из третьего пункта;

5 - в дальнейшем просто запустите двойным щелчком по пункту в этом списке. Для редактирования настроек именно этого пункта есть кнопки Load и Save .

После нажатия Open (или двойного щелчка по сохранённому пункту в списке), если правильно ввели адрес и порт, появится предупреждение:

Это значит, что Putty пока не знает цифровой отпечаток этого сервера и предлагает его запомнить. Смело жмите «Да». В будущем, если вдруг кто-то подменит ваш сервер поддельным, окно появится снова. Это удобно.

Появится консоль с предложением войти:

Нужно сначала ввести выданный хостером логин, нажать Enter, пароль и снова Enter:

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

Чтобы добавить нового пользователя, введите команду:

adduser имяпользователя

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

usermod -a -G sudo имяпользователя

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

Есть ещё один способ авторизации на сервере: по цифровому ключу. Генерируется файл-ключ, благодаря которому сервер узнает, что вы - это вы. Цифровой ключ просто нереально подобрать, поэтому доступ к серверу по протоколу SSH будет предельно надёжен. По умолчанию включать доступ по цифровому ключу любят зарубежные хостеры, у наших встречал пока только у одного. Если у вас простая связка логин/пароль, не переживайте и просто имейте в виду, что есть более защищённый способ, который можно включить в будущем. Как настроить, в Интернете инструкций полно, я не буду останавливаться на этом.

Обновление программ

Нужно запомнить команду обновления, которую вводить придётся часто:

sudo apt update && sudo apt upgrade

Точнее, это две команды, объединённые в одну, чтобы лишний раз не жать Enter:

• apt update обновляет список программ, подгружая из их репозитория Ubuntu 16.04;
• apt upgrade запускает обновление программ сервера, если есть устаревшие;
• sudo означает, что программу apt нужно запустить от имени суперпользователя root.

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

Немного теории: как работает веб-сервер

Веб-сервер - это программа, которая разберёт запрос браузера посетителя и отдаст ему нужные файлы. Для работы полноценного сайта на WordPress одного веб-сервера мало - он может отдавать только статичные (заранее подготовленные) файлы, ещё нужны интерпретатор PHP и сервер баз данных. Любой сайт на WordPress - это набор скриптов на языке программирования PHP, которые запрашивают информацию у сервера баз данных, чтобы сформировать страницы с записями, комментариями пользователя, админкой и прочими полезными интерактивными штуками.

Общий принцип работы таков:

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

2. Затем браузер обращается по IP-адресу к серверу, указывая заодно, какой именно сайт ему нужен.

3. Веб-сервер разбирает запрос, определяя - что отдать посетителю. Два варианта событий:

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

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

Вы можете подумать: «Зачем читать эту азбуку? Раз я купил VPS, то всё знаю!». Вам придётся немного потерпеть, потому что есть нюансы, про которые многие забывают. Даже профессионалы своего дела, судя по вопросам на таком серьёзном сайте, как toster.ru, иногда получают граблями по лбу.

Выбор веб-сервера: Apache против Nginx

По умолчанию на VPS не будет веб-сервера, интерпретатора PHP и сервера баз данных. Их нужно ставить самим.Рассмотрим два самых популярных веб-сервера - Apache и Nginx.

• Apache - самый популярный выбор. Совместим со всеми CMS, в том числе WordPress. К сожалению, скорость работы оставляет желать лучшего. Работающий на Apache сайт при наплыве посетителей начнёт открываться медленно или вовсе выдаст ошибку 500, 502 или другую из серии 5**, если у сервера не хватит ресурсов. Плюс только один: совместимость. На нём работают любые сайты, любые CMS, любой софт, написанный на PHP.
• Nginx - второй по популярности веб-сервер. Используется многими посещаемыми сайтами. Например, Яндексом, Mail.ru и Вконтакте. Сильная сторона nginx - он очень быстро отдаёт посетителю статичные файлы (.htm, .jpg, .png и другие). Благодаря этому и некоторым другим особенностям на аналогичном по производительности сервере Nginx выдерживает большее количество одновременных посетителей, а также позволяет загружать странички быстрее. Никакой магии, конечно, нет - если посетителей много и ресурсов сервера не хватает, 5**-е ошибки посыпятся тоже, но при бо льших нагрузках. О том, почему Nginx быстрее, есть

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

Я предлагаю использовать Nginx, потому что:

1. Nginx быстро отдаёт статичные файлы. Я подчеркиваю - действительно быстро . Если у вас сайт с большим количеством фотографий, переход на Nginx будет заметен невооружённым глазом: изображения на страницах будут появляться быстро, словно вы подключились к более шустрому Интернету.
2. Nginx может кэшировать результат работы PHP-скриптов и отдавать браузеру так же быстро, как статичные файлы. Это те самые грабли, на которые наступают некоторые админы, я в их числе. Nginx может работать в любой мыслимой конфигурации и если вдруг вам захотелось ускорить работу сайта, велик соблазн включить все виды кэширования. Но при длинной цепочке кэширования производительность, наборот, может упасть! Более того, посетителям нужен не замерший во времени сайт - комментарии, форумы, новостные ленты должны обновляться. Обновлять кэш постранично в WordPress довольно накладно. А если сбрасывать всё при каждом новом комментарии или записи в блоге, производительность сайта будет низкой, потому что часть ресурсов будет уходить на постоянное пересоздание кэша. Поэтому дальше я предложу гарантированный способ кэширования, однозначно ускоряющий сайт, всё остальное будете допиливать сами, если появится желание.
3. Nginx отказоустойчив. Так как это ещё и прокси-сервер, то при грамотной настройке, если вдруг «отвалится» PHP-интерпретатор, сайт продолжит работу, отдавая посетителям кэшированные страницы.
4. Nginx контролируем в настройке. Всё сосредоточено в нескольких.conf файлах и вся логика параметров базируется на запросе посетителя. Nginx разбирает запрошенный URL «по кирпичикам» и решает: отдать ли фотографию, перенаправить ли запрос PHP-интерпретатору, взять искомое из кэша или запретить доступ. В итоге ресурсов для отдачи контента отдаётся столько, сколько нужно. Apache работает иначе. Как именно, рассказано в статье, ссылку на которую я привёл в начале главы.

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

Выбор PHP: версии 5.6, 7.0, 7.1 и 7.2

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

На момент написания статьи в Ubuntu 16.04 по умолчанию устанавливается PHP 7.0, хотя уже вышла 7.2. Между 7.0, 7.1 и 7.2 разница в производительности минимальна (от 1 до 10% в разных задачах). Приобретя опыт в настройке PHP, вы сможете установить самую свежую, но на первых порах лучше оставить ту, которая будет в стандартных репозиториях ОС.

Выбор сервера баз данных: MySQL, MariaDB, PostgreSQL и другие

Помимо веб-сервера и интерпретатора PHP, должен быть запущен сервер баз данных. WordPress отлично работает с MySQL и MariaDB, а вот с PostreSQL и другими SQL-как-бы-совместимыми базами данных всё печально. Если у сайта нет десятков тысяч активно комментирующих посетителей, обычный MySQL Server не будет «бутылочным горлышком» - операции чтения из базы данных отлично кэшируются.

Пока лучше остаться на MySQL Server. В перспективе можно перенести базу на MariaDB и таким образом ускорить работу нагруженного сайта, инструкций на эту тему в Интернете полно.

Нужен ли DNS-сервер

Часто забывают, что виртуальный сервер может работать DNS-сервером, если установлен соответствующий софт и в записях домена указан IP-адрес сервера в качестве DNS-ки.

Моё мнение: это серьёзная угроза безопасности, потому что в случае взлома VPS, если будут изменены DNS-записи, исправление последствий может занять целые сутки, даже если вы мгновенно исправите взлом. То есть DNS-сервера во всём мире могут сутки открывать вместо вашего сайта поддельный, из-за чего вы потеряете посетителей и, что важнее, их доверие.

В течении 5-20 минут установятся веб-сервер Nginx, PHP-FPM в качестве интерпретатора PHP, Exim для отправки сообщений на электронную почту, MySQL Server для работы баз данных, Vsftpd для доступа по протоколу FTP, файрвол Iptables и средство автоматического бана Fail2Ban. Версии у программ будут те, которые находятся в репозитории Ubuntu.

В конце установки появится информация о том, по какому адресу доступна Vesta Control Panel, а также пароль нового пользователя admin, совпадающий с тем, что указали ранее в команде установки:

После установки Весты вам нужно выйти из сеанса вашего пользователя командой logout и перезайти под свежесозданным admin . И в будущем сидите только под ним, потому что:
а) все папки и файлы, которые потребуется создать в папке /home/admin/, будут принадлежать пользователю admin, вручную выполнять команду chown не потребуется,
б) меньше риск удалить системные файлы.

После установки VestaCP доустановите модули PHP, необходимые для работы WordPress:
sudo apt install php-curl php-gd php-mbstring php-mcrypt php-xml php-xmlrpc
Ещё один момент: софт после установки далеко не всегда запускается автоматически. Перезапустите сервер командой restart, чтобы MySQL Server, Nginx и прочие стартовали. Можно запустить и вручную, но перезапуск VPS - самый простой способ.

Работа в Vesta Control Panel

Так как для статьи я использую локальный виртуальный сервер, мой адрес для доступа к панели будет https://192.168.110.11:8083. У вас, конечно, другой. При заходе браузер предупредит, что https-соединение не защищено - не обращайте внимания. Затем будет запрос логина/пароля (тот самый admin и ваш пароль), после ввода откроется панель управления:

Для удобства можете нажать справа вверху надпись «admin» и в настройках профиля переключиться на русский язык.

В будущем вам лучше изучить основы Linux, чтобы понять, как сделать сервер «непробиваемым». А пока, чтобы хоть как-то обезопасить сервер, зайдите на вкладку «Фаервол» и заблокируйте порты служб FTP, DNS, POP3, IMAP, DB:

Когда потребуется загрузить файлы по протоколу FTP (адрес сервера - его IP, порт 21, пользователь admin, пароль тот же), можно временно разблокировать строку FTP. Постоянно держать открытыми порты со службами, которыми не пользуетесь, нельзя.

Краткое перечисление страниц панели управления Vesta:

1. Пакеты. Здесь настраиваются шаблоны с ограничениями, назначаемые учётным записям (их может быть несколько). Честно говоря, смысла в них мало, потому что Веста не доросла до панели управления полноценного хостинга.
2. IP. Настройка сетевых карт сервера. Лучше не трогать.
3. Графики. Раздел, где должны рисоваться красивые графики использования памяти, пропускной способности сетевых интерфейсов, нагрузки на базу данных. На практике ни разу не замечал, чтобы они показывали что-то, имеющее отношение к действительности. Возможно, это я один такой везучий.
4. Статистика. Просто полезная статистика, в пояснениях не нуждается.
5. Журнал. Операции, проводимые в панели управления, можно отследить тут.
6. Обновления. Можно узнать версии основных компонентов Весты.
7. Фаервол. Удобная настройка фай рвола iptables. Разработчики - грамотеи.
8. Сервер. Здесь можно остановить или перезапустить важные службы, а также настроить. Честно говоря, не советую настраивать службы через Весту, потому что иногда при сохранении она превращает файлы конфигурации буквально в кашу. Не знаю, с чем это связано, наблюдал на нескольких серверах. Вкладку лучше использовать только для перезапуска служб.
9. USER. Добавление новых пользователей и управление существующих.
10. WEB. Настройка сайтов. Самая важная вкладка, из-за которой Веста и нужна. О ней будет попозже.
11. DNS. Настройка записей домена, если VPS выступает в роли DNS-сервера.
12. MAIL. Настройка почтового сервера. В той конфигурации, что я вам рекомендую, страница бесполезна.
13. DB. Вторая по важности после WEB вкладка, позволяет быстро создать новую базу данных.
14. CRON. Крайне полезная вкладка, позволяющая настроить выполнение команд на сервере через заданные промежутки времени.
15. BACKUP. Здесь можно создать и загрузить бекапы.

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

1) Через Весту нельзя редактировать расширенные настройки. Возможность есть, но работает плохо. Например, на вкладке Сервер можно открыть настройки служб, где в удобных текстовых полях записаны какие-то значения. Если их изменить, не факт, что они сохранятся. А если нажать Дополнительные опции и попытаться отредактировать появившийся файл конфигурации вручную, служба может перестать запускаться, потому что строчки окажутся не там, где должны быть. Например, повторно добавиться в конец файла. А еще может открыться файл конфигурации от другой версии, по каким-то причинам оставшийся на сервере. Лучше самому делать тонкую настройку, редактируя файлы конфигурации через mcedit (как именно, покажу дальше).

2) Разработчики VestaCP имеют своё собственное видение того, какой софт должен ставиться вместе с панелью. Они написали отдельные скрипты для нескольких дистрибутивов Linux, подгружающиеся с их сайта во время установки. По их логике, если в Ubuntu 16.04 по команде apt install php ставится PHP версии 5.6, то так тому и быть. И не важно, что потом вместо 5.6 появится 7.0, а в репозиторий добавится ещё и php7.1, устанавливаемый командой apt install php7.1 - судя по комментариям на официальном форуме, такой ситуации не может быть в принципе.

Ещё веселее с поддержкой Ubuntu 16.10 - из-за ошибки в скрипте установки половина софта просто-напросто не устанавливается. На момент написания этой инструкции упоминание ошибки висит на официальном форуме Весты месяц, одна-единственная строчка с ошибкой до сих пор не исправлена. Чтобы не быть голословным, покажу часть скрипта установки софта для Убунты по адресу http://vestacp.com/pub/vst-install-ubuntu.sh:

Если следовать логике скрипта установки, то все дистрибутивы Убунты делятся на Ubuntu 16.04 и остальные. Вот только Ubuntu 16.10 - не остальные. В её репозиториях нет ни apache2.2-common, ни php5-fpm и другого устаревшего софта. Без редактирования скриптов установки работающий с VestaCP веб-сервер на Ubuntu 16.10 не получить.

3) Удобный инструмент управления базами данных phpMyAdmin, который ставит скрипт установки Весты, может просто не работать.

4) Способов «выстрелить в ногу» в Весте выше крыши. Например, ни в коем случае нельзя удалять шаблон default на странице Пакеты , в противном случае вы познаете боль и страдания.

5) Почему-то в скриптах установки панели нет корректной проверки на существование имеющегося софта. Поэтому, если на сервере изначально был установлен какой-то софт, например Apache, а вы ставите Весту без включения этого софта (только Nginx), возможны сбои. Например, просто ничего не заработает. Я не знаю, что тут посоветовать, кроме как удалить весь перечисленный в команде установки панели софт (nginx, phpfpm, apache, vsftpd, proftpd, exim, dovecot и так далее) и только потом ставить панель.

Несмотря на недостатки, среди бесплатных панелей управления лучше Vesta Control Panel ничего нет. Разве что , но у неё нет веб-интерфейса, нужно вводить команды с клавиатуры. Альтернативы Webmin, Froxlor, ajenti недостаточно автоматизируют управление сервером и сложнее в настройке, а у платного ISP Manager тоже хватает проблем.

Установка дополнительного софта

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

Устанавливается командой
sudo apt install memcached php-memcache
После этого рекомендую перезапустить сервер.

2. Littleutils. Нужен для работы плагина CW Optimizer, который сжимает фотографии, загружаемые на сайт. Оптимизация изображений - один из и привлечения посетителей (никто не любит медленную загрузку страниц). Лучше начать оптимизировать фотографии уже сегодня.

Сохраните настройки кнопкой OK, затем выйдите из MC кнопкой F10 и запустите коммандер снова, на этот раз командой sudo mc и повторите настройку.

Эта неочевидная опция сильно упростит жизнь во время редактирования файлов конфигурации. Она позволит временно скрывать с экрана текстовый редактор коммандера mcedit, переключаясь на консоль. Например, когда будете редактировать конфигурацию Nginx, вы сможете отредактировать файл, сохранить его кнопкой F2, затем скрыть редактор сочетанием клавиш Ctrl+O и ввести команду в консоли:
Если будет такой результат:

То с файлом всё отлично и можно перезагружать сервер, окончательно применяя новые настройки:
sudo service nginx restart
Если же появится сообщение о проблемах, можно нажать Ctrl+O и сразу поправить нужную строчку, не тратя время на переоткрытие файла.

Во многих инструкциях советуют редактировать файлы с помощью текстовых редакторов vi или nano . Консоль - не всегда удобно, зачем усложнять себе жизнь ещё больше? На мой взгляд, проще и быстрее в MC зайти в нужную папку, выбрать файл и нажать F4, чтобы открыть редактор, который можно скрыть в любой момент.

Как установить WordPress

1. Прежде чем приступить к установке сайта на Вордпресс, создайте отдельную базу данных на вкладке DB, нажав зеленую кнопку «+ «:

Без базы данных сайты на WP не работают. Им нужно где-то хранить настройки и тексты записей. И лучше для каждого сайта создавать отдельную базу данных. Тогда в случае взлома одного сайта до других добраться будет сложнее.

2. На вкладке WEB добавьте сайт кнопкой «+ «:

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

Домен: адрес сайта. Если домен пока не купили, укажите тот, который планируете купить. В файле hosts компьютера (и сервера тоже в папке /etc/hosts) можно связать домен и IP-адрес сервера, чтобы вы уже могли пользоваться сайтом по выбранному адресу.

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

Поддержка DNS: так как VPS не работает как DNS-сервер, нужно снять галку.

Поддержка почты: тоже снять галку, потому что на сервере будет только Exim для отправки писем, VPS в качестве почтового сервера не подходит по той же причине, что и поддержка DNS.

Следующие пункты появятся при нажатии «Дополнительные опции»:

Алисы: дополнительные адреса, с которых перенаправлять на основной домен.

Поддержка SSL: поддержка шифрования. Современные сайты должны поддерживать защищённый протокол https , здесь сомнений быть не может. После включения опции нужно отметить и «Поддержка Lets Encrypt «, чтобы использовать бесплатные сертификаты Let’s Encrypt. После сохранения настроек нужно повторно поставить галку на «Поддержка Lets Encrypt», потому что с первого раза сертификат может не сгенерироваться.

Учтите два момента:

1. Нельзя получить сертификат на домен или поддомен, если в A-записях домена указан IP другого сервера. Это сделано для того, чтобы никто, кроме владельца домена, не смог получить SSL-сертификат. Поэтому до покупки домена и настройки DNS вы сертификат не получите. То есть, чтобы сайт заработал по протоколу https, ваш сайт должен открываться по протоколу http. Только потом можно настроить редирект с http на https.
2. Генерация ключей Let’s Encrypt через Весту работает через раз. Придётся смотреть логи и разбираться, в чём проблема (они в папке /usr/local/vesta/log) или воспользоваться сторонними утилитами.

Статистика сайта: включение встроенной системы статистики. В большинстве случаев лучше не включать, чтобы не нагружать сервер.

Дополнительный ftp: создание аккаунта ftp специально для работы с папкой, где будет находиться сайт. Даёт ощущение ложной безопасности - мол, дадите только пароль от этого сайта и до других файлов никто не доберётся. На самом деле это не так, VestaCP не подходит организации хостинга с полностью изолированными друг от друга сайтами и пользователями.

3. Когда создадите сайт на вкладке WEB, не торопитесь уходить. Вам нужно снова зайти в настройки сайта (кнопка «Редактировать» при наведении мыши на пункт меню. Появятся новые настройки - выбор шаблонов Web и Backend:

Шаблон Web в VestaCP отвечает за набор настроек Nginx, специфичных для каждой из популярных CMS. Шаблон Backend отвечает за настройку связи между веб-сервером и PHP-интерпретатором.

Выберите Шаблон Web - wordpress , а Шаблон Backend - socket (связь через сокеты работает быстрее связи через порты). Если галка с «Поддержка Lets Encrypt» оказалась снята, поставьте снова. Нажмите Сохранить и снова откройте настройки сайта и поставьте Шаблон Web - wordpress2 и снова сохраните настройки.Почему не выбрать сразу шаблон wordpress2? Ну, я говорил, что VestaCP - глючная штука, это одна из проблем - правильный файл конфигурации для WordPress не генерируется корректно с первого раза.

Обновление от 4.04.2017: Сначала сгенерируйте Let’s Encrypt ключи, потом выбирайте шаблон Web wordpress2, Backend - socket. Или, если SSL не нужно, выбирайте шаблоны wordpress2, socket и сохраняйте настройки.

Если посты отдают 404 ошибку при включенных в админке WP постоянных «красивых» ссылках, используйте шаблон Nginx из поста

4. Запустите Putty, зайдите под пользователем admin.

Выполните команды по очереди:
cd /home/admin/tmp/
wget https://ru.wordpress.org/latest-ru_RU.zip
unzip latest-ru_RU.zip -d /home/admin/web/имя_вашего_домена/public_html/
mv /home/admin/web/имя_вашего_домена/public_html/wordpress/* /home/admin/web/имя_вашего_домена/public_html/
rm latest-ru_RU.zip
rm -r /home/admin/web/имя_вашего_домена/public_html/wordpress
sudo service nginx restart
5. Сайт уже должен заработать. Зайдите через браузер по адресу https ://адрес_сайта, откроется страница установки:

Если зайти по обычному протоколу http, придётся в панели управления WordPress заходить в Настройки - Общие и менять значения в полях Адрес WordPress (URL) и Адрес сайта (URL) с обычного http на https, чтобы CMS поняла, что приоритет у защищённого протокола.

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

• Имя базы данных - имя той базы данных, что создали в первом шаге.
• Имя пользователя - имя пользователя к базе данных из первого шага.
• Пароль - думаю, понятно, что это пароль к базе.
• Сервер базы данных - так как база данных на том же сервере, оставляйте «localhost».
• Префикс таблиц - введите что-нибудь случайное.

6. На следующем этапе нужно указать название сайта, имя пользователя-администратора сайта и ваш e-mail:

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

7. Откроется панель управления сайта:

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

Установка и настройка необходимых плагинов WordPress

Все плагины ставятся сразу из админки. Достаточно пройти в раздел Плагины - Добавить новый и ввести имя плагина в поле поиска.

CW Image Optimizer. Плагин, оптимизирующий каждую фотографию, загружаемую на сайт. В настройке не нуждается. Достаточно было установки Littleutils из прошлого шага. Хочу подчеркнуть - все альтернативы этого плагина платные. Есть разве что EWWW Image Optimizer, но он плохо оптимизирует.

DCO Russian Fixes - плагин для транслитерации имён файлов и ссылок и корректировки формата дат. После установки и активации в настройке не нуждается.

SSL Insecure Content Fixer (Фильтр небезопасного содержимого SSL) - делает все ссылки на сайте ведущими на https-версию вместо http. Работа защищенного соединения HTTPS влияет на ранжирование в поиске Гугла, нужно по-максимуму использовать эту возможность. Рекомендую после установки плагина зайти в раздел Настройки - Небезопасный контент SSL и переключить плагин на режим Виджеты , чтобы все ссылки страницы вели на защищённые версии.

iThemes Security - плагин для повышения уровня безопасности. После установки и активации в верхней части панели управления появится кнопка «Получите бесплатно API ключ» - нажмите и получите его. Настройки iThemes Security смотрите ниже в отдельной главе.

Autoptimize - для объединения всех.css и.js файлов темы и плагинов в один, чтобы сократить количество запросов к серверу. Пока протокол HTTP/2 не шибко актуален, для ускорения загрузки страниц можно экономить запросы. Я перепробовал все подобные плагины, Autoptimize - самый корректный, он совместим с большинством тем WordPress. После установки и активации плагина зайдите в его настройки и включите все три вида оптимизации: HTML, CSS и JS.

W3 Total Cache - самый лучший в мире плагин кэширования. С Nginx отлично дружит, после установки и настройки сайт будет летать. Выделил настройку в отдельную главу. Ничего сложного, нужно просто пробежаться по пунктам.

Настройка iThemes Security

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

Основные настройки:

• Тип журнала событий - Только в файле , чтобы база данных не росла в размере.
• Скрыть меню безопасности в админ панели - поставьте галку, чтобы убрать не шибко нужный пункт.

Заблокированные пользователи:

• Включить черный список от сайта HackRepair.com - поставьте галку.

Local Brute Force Protection:

• Автоматически запретить пользователя «admin» - поставьте галку, чтобы каждый бот и умник, пытающийся зайти в вашу панель управления под самым банальным во Вселенной логином, получал автоматический бан.

SSL:

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

Тонкая подстройка системы:

• Нажмите Enable, чтобы включить блок настроек. Затем в настройках поставьте галку на опциях Защита системных файлов, Отключить просмотр каталогов, Отключить PHP в папке Uploads, Disable PHP in Plugins, Disable PHP in Themes. Последние три опции могут поломать работу некачественно написанных шаблонов оформления и плагинов, так что поможет выявить подобные поделия.

Подстройка WordPress:

• Поставьте галки на Remove the Windows Live Writer header, Remove the RSD (Really Simple Discovery) header, Уменьшить спам в комментариях, Отключить сообщение об ошибке при неудачной попытке входа, Отключает архив автора для пользователя, у которого нет записей.
• Если не пользуетесь программой WordPress на Android, поставьте опцию XML-RPC в режим Отключить XML-RPC.
• REST API - в Restricted Access.

Настройка W3 Total Cache

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

I. Кэширование PHP с помощью технологии OPCache. Компиляция скриптов в более быстрый код, ускоряет их выполнение минимум в 2 раза. Выбор веб-сервера на работу OPCache не влияет, это настройка интерпретатора PHP. Как включить, расскажу в отдельной главе ниже.
II. Кэширование средствами CMS. Благодаря плагинам кэширования WordPress типа W3 Total Cache или WP Super Cache результат работы скриптов в виде страничек сайта отдаётся не только веб-серверу, но и сохраняется в виде статичных html-файлов. Самый предсказуемый, управляемый вид кэширования. При первом посещении страничка откроется медленно (как обычно), при последующих - очень быстро, как и все статичные файлы, если используется Nginx. При использовании Apache страницы тоже станут открываться шустрей, но по сравнению с Nginx прирост мал.
III. Кэширование с помощью Varnish или любого другого кэширующего прокси. Nginx и Apache можно настроить так, чтобы вместо обращения к интерпретатору страница подгружалась из промежуточного кэша, если она там есть. Если мне кто-нибудь объяснит, зачем нужен этот велосипед, буду весьма признателен. Ни одного плюса в подобной прослойке не вижу, потому что см. далее:
IV. Кэширование средствами Nginx. Сам веб-сервер тоже может сохранять готовые страницы и отдавать посетителям. Благодаря такой работе сайт будет открываться очень, очень быстро. Особенно если папку с кэшем расположить в оперативной памяти сервера.
К сожалению, в отличии от кэширования с помощью WordPress, Nginx будет отдавать посетителям старые странички до тех пор, пока файлы кэша не будут удалены. Раньше можно было управлять очисткой с помощью плагина WordPress Nginx Helper, но в последних бесплатных версиях веб-сервера разработчики удалили модуль fastcgi_cache_purge. Настроить кэширование в Nginx для корректной работы всё же можно, но это тема отдельной статьи. В большинстве случаев такое кэширование не нужно, достаточно кэширования средствами CMS.
V. Браузерное кэширование. Можно и нужно настроить веб-сервер так, чтобы браузер кэшировал статичные файлы (фотографии, .css и.js файлы) минимум на неделю, чтобы лишний раз не загружать с сервера одно и то же. Включается легко в том же W3 Total Cache, польза неоспорима.
При использовании Apache II и III виды кэширования не смогут быть эффективными, потому что обработкой запросов будет заниматься медленный веб-сервер.

Итак, как же ускорить с помощью W3 Total Cache? Установите этот плагин, зайдите в его настройки на страницу General Settings:

Раздел Page Cache:

• Галку на Enable , настройку Page Cache Method на Memcached.

Раздел Database Cache:

• Галку на Enable , настройку Database Cache Method на Memcached.

Раздел Object Cache:

• Галку на Enable , настройку Object Cache Method на Memcached.

Раздел Miscellaneous:

• Снимите галку с Enable Google Page Speed dashboard widget , этот инструмент может ввести в заблуждение.
• Снимите галку с Anonymously track usage to improve product quality , незачем отсылать информацию о своём сайте.

Страница настроек Page Cache:

• Поставьте галки в разделе General на опциях Cache feeds: site, categories, tags, comments, Cache SSL (https) requests.
• В разделе Advanced , если будете использовать популярный плагин Yoast SEO, измените содержимое поля Never cache the following pages: на
  wp-.*\.php
  index\.php
  (+)?sitemap(_index)?(-)?(*)?\.(xml(\.gz)?|xsl)$

Страница настроек Browser Cache (настройка кэширования в браузере):

• Поставьте галки в разделе General на опциях Set expires header, Set cache control header, Set entity tag (ETag), Don’t set cookies for static files, Apply HTTP Strict Transport Security policy.
• Поставьте галки в разделах CSS & JS, HTML & XML, Media & Other Files на опциях Set expires header, Set cache control header, Set entity tag (eTag), Disable cookies for static files.

Страница Extensions:

• Выключите модули Fragment Cache и New Relic.

Подобных настроек достаточно, чтобы сайт стал открываться быстро. Не забудьте посмотреть следующую главу, чтобы подключить часть настроек Nginx, которые создали плагины iThemes Security и W3 Total Cache.

Настройка Nginx

Осталось совсем чуть-чуть: нужно сделать так, чтобы Nginx подключал настройки, сделанные плагинами iThemes Security и W3 Total Cache. Для редактирования файлов конфигурации Nginx нужны права суперпользователя, поэтому запустите Midnight Commander командой
sudo mc
и зайдите в папку /home/admin/conf/web:

Увидите два файла:

1. nginx.conf - настройка сайтов, доступных по протоколу http.
2. snginx.conf - сайты по протоколу https.

В nginx.conf настройки сайтов будут всегда. В snginx.conf только в том случае, если включали SSL при создании сайта в панели управления VestaCP. В принципе, вы можете редактировать эти файлы, но после этого при попытке добавить новый сайт через Весту конфигурационные файлы превратятся в кашу. Придётся сбросить все правки командой v-rebuild-web-domains admin yes .

Поэтому нужно создать отдельный файл с настройками, который подхватится nginx, и не будет мешать работе панели управления. Для этого в Midnight Commander в папке /home/admin/conf/web нажмите Shift+F4 . Если до этого никогда не редактировали файлы через MC, появится выбор редактора. Выберите mcedit .

Вставьте туда вот такой код:
include /home/admin/web/имя_вашего_домена /public_html/*.conf;
Благодаря этой строчки будет подхватываться файл nginx.conf, который создается плагином W3 Total Cache и другими совместимыми с Nginx.

Если пользуетесь плагином SEO-оптимизации Yoast SEO, добавьте ещё это:

#Yoast SEO Sitemaps location ~ ([^/]*)sitemap(.*).x(m|s)l$ { rewrite ^/sitemap.xml$ /sitemap_index.xml permanent; rewrite ^/(+)?-?sitemap.xsl$ /index.php?xsl=$1 last; rewrite ^/sitemap_index.xml$ /index.php?sitemap=1 last; rewrite ^/([^/]+?)-sitemap(+)?.xml$ /index.php?sitemap=$1&sitemap_n=$2 last; }

Нажмите F2 для сохранения файла, появится окно выбора имени файла. Введите nginx.имя_вашего_домена.conf_custom.

Потом Ctrl+O для скрытия MC и наберите в консоли для проверки конфига:
sudo service nginx configtest
Если всё ОК, перезапустите сервер для применения конфига:
sudo service nginx restart
Теперь ваш сайт защищён и кэширование работает нормально.

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

В Интернете полно инструкций о том, что можно редактировать в файле /etc/php/7.0/fpm/php.ini. Я лишь приведу парочку, которые в любом случае стоит изменить.

Для повышения безопасности:

Session.use_strict_mode = 1

Для включения OPCache, о котором я писал выше:

Opcache.enable=1 opcache.memory_consumption=128 opcache.max_accelerated_files=7963 opcache.max_wasted_percentage=10

Обратите внимание - нужно убрать «;» перед строками. Ещё можете указать параметр opcache.validate_timestamps=0 , если готовы перезагружать сервер после каждого обновления темы, плагинов и самого WordPress. Параметр отключает проверку изменения файлов PHP, придётся очищать вручную кэш OPCache.

После применения настроек перезагрузите Nginx и PHP-FPM командой:
sudo service nginx restart && sudo service php-fpm restart

Что дальше?

Файлы конфигурации, где сосредоточены все настройки, влияющие на производительность сервера:

• Настройки веб-сервера Nginx хранятся в файле /etc/nginx/nginx.conf
• Настройки PHP хранятся в файлах папки /etc/php/7.0/fpm/
• Настройки сервера MySQL в /etc/mysql/my.cnf

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

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

P.S. Ко мне поступило несколько предложений написать инструкцию по установке VestaCP для CentOS. Разница между Убунтой и любым другим дистрибутивом Linux невелика. Вы вполне можете поставить Весту и на Debian, и CentOS, если знаете команды пакетного менеджера. Поэтому отдельной статьи не будет.

P.P.S. Я не оказываю помощь в настройке этой панели управления. Судя по проблемам, возникшим примерно за год использования, данная панель довольно глючная. С ней постоянно возникают какие-то неурядицы, которые новички решить не могут. Я не автор этого продукта, ресурсов и времени быть техподдержкой VestaCP у меня нет.