Руководство по настройке блога WordPress на nginx.
Данное руководство рассчитано на вебмастеров, стремящихся решить проблему недостаточной производительности сайтов, построенных на платформе WordPress. В нем описана пошаговая настройка сервера с ограниченными ресурсами (1 ядро, 512 RAM на примере минимального тарифа Flops.ru) для использования в связке LEMP (Linux + nginx + MySQL + PHP). Для комфортного использования материала вы должны иметь общие представления о работе сайтов и серверов на базе Linux.
Данное руководство рассчитано на вебмастеров, стремящихся решить проблему недостаточной производительности сайтов, построенных на платформе WordPress. В нем описана пошаговая настройка сервера с ограниченными ресурсами (1 ядро, 512 RAM на примере минимального тарифа Flops.ru) для использования в связке LEMP (Linux + nginx + MySQL + PHP). Для комфортного использования материала вы должны иметь общие представления о работе сайтов и серверов на базе Linux.
Эволюция требований к хостингу при увеличении масштабов проекта.
Наиболее популярным решением для веб серверов по прежнему остается связка LAMP (Linux, Apache, MySQL, PHP). Подобный вариант легок в настройке, хорошо документирован, часто используется для небольших проектов. Но за простоту использования приходится платить чрезмерным потреблением ресурсов и высокими рисками даунтайма при увеличении нагрузки (возросшее число посетителей, большое количество материалов, тяжелые плагины).
В результате веб мастерам приходится либо увеличивать финансирование на оплату услуг хостинга путем увеличения производительности аппаратной составляющей, либо искать менее ресурсоемкие решения.
Следующим витком эволюции в погоне за производительность стает полный отказ от Apache, использование FPM, полное кэширование страниц сайта.
Это руководство подробно рассказывает о настройке WordPress, выдерживающей нагрузки в несколько сотен конкурентных запросов в секунду в условиях крайне ограниченных серверных ресурсов. Руководство описывает все шаги установки, включая первичную настройку сервера, обеспечивающую защиту от стандартных угроз, установку и настройку LEMP, настройку WordPress. Выполнение всех пунктов гарантирует получение работоспособного сервера.
ВАЖНО: В руководстве не описана процедура резервного копирования, так как Flops.ru обеспечивает создание резервных копий и снэпшотов, а использование сторонних мест хранения сугубо индивидуально.
ВАЖНО: Набор предустановленных пакетов у разных хостинг-провайдеров может варьироваться. Руководство подразумевает наличие схожих с Flops.ru пакетов.
ЗАМЕЧАНИЕ: В интернете гуляет множество статей по использованию в подобной связке Varnish, но nginx отдает статику не хуже, а конфигурация, представленная ниже, преимущественно будет работать именно со статикой, так что не вижу смыла усложнять проект еще одной прослойкой, тем более сильно отягчающей жизнь проектам, использующим SSL. Для формирования статической выдачи будет использоваться плагин WP Super Cache.
Требования к серверу.
В руководстве приводятся примеры конфигурации для сервера VPS с одним ядром, 512Mb Ram, SSD. Тестовые сервера были развернуты у хостинг-провайдера Flops.ru, но вы можете воспользоваться любыми другими. Так как приведенные ниже настройки рассчитаны на максимальное использование кэшированных на дисках объектов, наиболее важным параметром будет производительность дисковой подсистемы.
Для установки сервера был выбран дистрибутив Debian 7 x86, так как в микроинстялляциях он обеспечивает более экономное использование памяти по сравнению с x64 версиями.
Подготовка серверного окружения.
После установки сервера установим с ним соединение по ssh.
Сразу после установки не назначены локали по умолчанию. Укажем основной локалью en_US.UTF-8.
Для того, чтобы изменения вступили в силу, необходимо завершить сеанс SSH и начать его заново.
Обновим ПО сервера.
Установим и настроим sudo.
Добавим нового пользователя, под которым будем получать доступ по SSH.
Теперь перелогинимся под новым пользователем и убедимся, что все хорошо. Если проблем не возникло ограничим доступ root пользователю к SSH.
После внесения изменений перезагрузим OpenSSH.
Ограничим возможности потенциальных злоумышленников к подбору паролей SSH. Воспользуемся утилитой fail2ban. Также позже мы настроим fail2ban для блокирования возможности подбора пароля к WordPress.
Для нашей задачи дополнительные настройки fail2ban не требуются. Теперь при шестикратном неправильном вводе пароля ssh, пользователь будет блокироваться с помощью iptables на 600 секунд.
Настроим синхронизацию времени.
Настроим exim4 для отправки писем с сайта.
General type of mail configuration: Выберем верхний пункт internet site; mail is sent and received directly using SMTP.
System mail name: Укажем полное имя сервера, например admins.su.
IP-addresses to listen on for incoming SMTP connections: 127.0.0.1
Other destinations for which mail is accepted: Оставим пустым.
Domains to relay mail for: Оставим пустым.
Machines to relay mail for: Оставим пустым.
Keep number of DNS-queries minimal (Dial-on-Demand)? No
Delivery method for local mail: Любое значение.
Split configuration into small files? Yes
Резюме выполненных действий:
Установка LEMP.
Мы будем использовать установку из пакетов для простого управления обновлениями. Для того, чтобы получить более свежий nginx (стандартно ставится nginx 1.2.1), мы подключим родной репозиторий nginx.
Скачаем и установим PGP ключ сервера nginx.
Источник
WordPress.org
Categories
Nginx
Topics
While the LAMP stack (Linux + Apache + MySQL + PHP) is very popular for powering WordPress, it is also possible to use Nginx. WordPress supports Nginx, and some large WordPress sites, such as WordPress.com, are powered by Nginx.
When talking about Nginx, it is important to know that there are multiple ways to implement Nginx. It can be setup as a reverse-proxy in front of Apache, which is a very powerful setup that allows you to use all of the features and power of Apache, while benefiting from the speed of Nginx. Most websites that report using Nginx as the server (based on stats gathered from HTTP response headers), are actually Apache running with Nginx as the reverse proxy. (The HTTP response headers showing “Nginx” are being reported by the reverse-proxy, not the server itself.)
This guide is referring to a standalone Nginx setup, where it is used as the primary server instead of Apache. It should be noted that Nginx is not a completely interchangeable substitute for Apache. There are a few key differences affecting WordPress implementation that you need to be aware of before you proceed:
This guide is not going to cover how to install and configure Nginx, so this assumes that you have already installed Nginx and have a basic understanding of how to work with and debug it.
Generic and Multi-Site Support # Generic and Multi-Site Support
To make WordPress work with Nginx you have to configure the backend php-cgi. The options available are ‘fastcgi’ or ‘php-fpm’. Here, php-fpm is being used because it is included with PHP 5.3+, so installing it is straight forward.
The Nginx configuration has been broken up into five distinct files and is heavily commented to make each option easier to understand. The author also made a best-effort attempting to follow “best practices” for nginx configurations.
Main (generic) startup file # Main (generic) startup file
This is equivalent to /etc/nginx/nginx.conf (or /etc/nginx/conf/nginx.conf if you’re using Arch Linux).
This is a bit different from standard nginx.conf files. This configuration follows the Ubuntu/Debian method of declaring enabled sites for maximum flexibility – using ‘sites-available’ to store a config and then symlink to the config file from ‘sites-enabled’.
Per Site configuration # Per Site configuration
Splitting sections of the configuration into multiple files allows the same logic to be reused over and over. A ‘global’ subdirectory is used to add extra rules for general purpose use (either /etc/nginx/conf/global/ or /etc/nginx/global/ depending on how your nginx install is set up).
Global restrictions file # Global restrictions file
General WordPress rules # General WordPress rules
For single site installations, here is the ‘global/wordpress.conf’ file:
WordPress Multisite Subdirectory rules # WordPress Multisite Subdirectory rules
For multisite subdirectory installations, here is the ‘global/wordpress.conf’ file:
NGINX provides 2 special directive: X-Accel-Redirect and map. Using these 2 directives, one can eliminate performance hit for static-file serving on WordPress multisite network.
WordPress Multisite subdomains rules # WordPress Multisite subdomains rules
HTTPS in Nginx # HTTPS in Nginx
Enabling HTTPS in Nginx is relatively simple.
WP Super Cache Rules # WP Super Cache Rules
Experimental modifications:
If you are using HTTPS, the latest development version of WP Super Cache may use a different directory structure to differentiate between HTTP and HTTPS. try_files line may look like below:
W3 Total Cache Rules # W3 Total Cache Rules
W3 Total Cache uses different directory structure for disk-based cache storage depending on WordPress configuration.
Cache validation checks will remain common as shown below:
FOR Normal WordPress (without Multisite)
Use following:
FOR Multisite with subdirectories
Use the following:
FOR Multisite with Subdomains/Domain-mapping
Use following:
Notes
Nginx fastcgi_cache # Nginx fastcgi_cache
Nginx can perform caching on its own end to reduce load on your server. When you want to use Nginx’s built-in fastcgi_cache, you better compile nginx with fastcgi_cache_purge module. It will help nginx purge cache for a page when it gets edited. On the WordPress side, you need to install a plugin like Nginx Helper to utilize fastcgi_cache_purge feature.
Config will look like below:
Define a Nginx cache zone in http <…>block, outside server <…>block
For WordPress site config, in server <..>block add a cache check block as follow
Then make changes to PHP handling block
Just add this to the following php block. Note the line fastcgi_cache_valid 200 60m; which tells nginx only to cache 200 responses(normal pages), which means that redirects are not cached. This is important for multilanguage sites where, if not implemented, nginx would cache the main url in one language instead of redirecting users to their respective content according to their language.
Such that it becomes something like this
Finally add a location for conditional purge
If you get an ‘unknown directive “fastcgi_cache_purge”‘ error check that your Nginx installation has fastcgi_cache_purge module.
Better Performance for Static Files in Multisite # Better Performance for Static Files in Multisite
By default, on a Multisite setup, a static file request brings php into picture i.e. ms-files.php file. You can get much better performance using Nginx Map <..>directive.
In Nginx config for your site, above server <..>block, add a section as follows:
It is just a list of site-names and blog-ids. You can use Nginx helper to get such a list of site-name/blog-id pairs. This plugin will also generate a map.conf file which you can directly include in the map<> section like this:
After creating a map <..>section, you just need to make one more change in your Nginx config so requests for /files/ will be first processed using nginx map <..>:
Notes # Notes
Notes # Notes
A couple of final but important notes: This whole setup assumes that the root of the site is the blog and that all files that will be referenced reside on the host. If you put the blog in a subdirectory such as /blog, then the rules will have to be modified. Perhaps someone can take these rules and make it possible to, for instance, use a:
directive in the main ‘server’ block and have it automagically apply to the generic WP rules.
Источник
Автоматизируем установку WordPress с NGINX Unit и Ubuntu
Есть множество материалов по установке WordPress, поиск в Google по ключевым словам «WordPress install» выдаст порядка полумиллиона результатов. Но тем не менее фактически среди них весьма мало годных руководств, по которым можно установить и настроить WordPress и нижележащую операционную систему так, чтобы они были способны к поддержке в течение длительного периода времени. Возможно, правильные настройки сильно зависят от конкретных потребностей, или же это связано с тем, что подробное объяснение делает статью тяжелой для чтения.
В этой статье мы постараемся собрать лучшее из двух подходов, предоставляя скрипт на bash для автоматической установки WordPress на Ubuntu, а также пройдемся по нему, поясняя, что делает каждый его кусочек, а также на какие компромиссы мы пошли при его разработке. Если вы опытный пользователь — можете пропустить текст статьи и просто взять скрипт для модификации и использования в ваших окружениях. На выходе скрипта получается настраиваемая установка WordPress с поддержкой Lets Encrypt, работающая на NGINX Unit и пригодная для промышленного применения.
Разработанная архитектура для развертывания WordPress с использованием NGINX Unit описана в более старой статье, сейчас мы также дополнительно настроим вещи, которые там не были охвачены (как и во многих других руководствах):
В статье будет описана установка на одном сервере, на котором будут размещены одновременно сервер обработки статики, сервер обработки PHP, база данных. Установка с поддержкой множества виртуальных хостов и сервисов — потенциальная тема на будущее. Хотите, чтобы мы написали о чем-то, чего нет в этих статьях — пишите в комментариях.
Требования
Обзор архитектуры
Архитектура такая же, как было описано ранее, трехуровневое web-приложение. Оно состоит из скриптов PHP, исполняемых на обработчике PHP, и статических файлов, обрабатываемых веб-сервером.
Общие принципы
Установка переменных окружения
Установите следующие переменные окружения, прежде чем запускать скрипт:
Установка производных переменных окружения
Скрипт в строках 55-61 выставляет следующие переменные окружения, либо в некоторое жестко заданное значение, либо с применением значения, полученного из переменных, установленных в предыдущем разделе:
Назначение hostname WordPress серверу
Скрипт устанавливает hostname серверу, чтобы значение соответствовало доменному имени сайта. Это не обязательно, но так удобнее отправлять исходящую почту через SMTP при настройке единственного сервера, как это настраивается скриптом.
Добавление hostname в /etc/hosts
Дополнение WP‑Cron используется для запуска периодических задач, требует, чтобы WordPress мог получить доступ к самому себе через HTTP. Чтобы убедиться, что WP-Cron работает корректно на всех окружениях, скрипт добавляет строчку в файл /etc/hosts, так что WordPress может получить доступ к самому себе через интерфейс loopback:
Установка инструментов, требуемых для последующих шагов
Оставшаяся часть скрипта нуждается в некоторых программах и подразумевает, что репозитории актуальны. Мы обновляем список репозиториев, после чего устанавливаем нужные инструменты:
Добавление репозиториев NGINX Unit и NGINX
Скрипт устанавливает NGINX Unit и NGINX с открытым исходным кодом из официальных репозиториев NGINX, чтобы удостовериться, что используются версии с последними обновлениями безопасности и исправлениями ошибок.
Реальная установка NGINX Unit и NGINX происходит в следующем разделе. Мы предварительно добавляем репозитории, чтобы не обновлять метаданные несколько раз, что делает установку быстрее.
Установка NGINX, NGINX Unit, PHP MariaDB, Certbot (Let’s Encrypt) и их зависимостей
Как только все репозитории добавлены, обновляем метаданные и устанавливаем приложения. Пакеты, устанавливаемые скриптом, также включают расширения PHP, рекомендуемые при запуске WordPress.org
Настройка PHP для использования с NGINX Unit и WordPress
Скрипт создает файл настроек в каталоге conf.d. Тут задается максимальный размер загружаемых файлов для PHP, включается вывод ошибок PHP в STDERR, так что они будут записаны в журнал NGINX Unit, а также перезапускается NGINX Unit.
Задание настроек базы данных MariaDB для WordPress
Мы выбрали MariaDB вместо MySQL, поскольку у нее больше активность сообщества, кроме того, она, возможно, предоставляет более высокую производительность по умолчанию (вероятно, тут все проще: чтобы поставить MySQL, надо добавить еще один репозиторий, прим. переводчика).
Скрипт создает новую базу данных и создает учетные данные для доступа WordPress через интерфейс loopback:
Установка программы WordPress CLI
На этом шаге скрипт устанавливает программу WP-CLI. С его помощью можно установить и управлять настройками WordPress без необходимости ручной правки файлов, обновления базы или входа в панель управления. Также с его помощью можно установить темы и дополнения и выполнить обновление WordPress.
Установка и настройка WordPress
Настройка NGINX Unit
Скрипт настраивает NGINX Unit для запуска PHP и обработки путей WordPress, изолируя пространство имен процессов PHP и оптимизируя настройки производительности. Тут есть три функции, на которые стоит обратить внимание:
Также это значение подразумевает, что всегда есть как минимум два запущенных процесса PHP, что важно, поскольку WordPress делает много асинхронных запросов к самому себе, а без дополнительных процессов запуск, к примеру, WP-Cron, сломается. Вы, возможно, захотите увеличить или уменьшить эти ограничения, основываясь на ваших локальных настройках, потому что созданные настройки здесь — консервативные. На большинстве производственных систем настройки находятся между 10 и 100.
Настройка NGINX
Настройка основных параметров NGINX
Настройка сжатия NGINX
Сжатие содержимого на лету перед отправкой его клиентам — отличный способ улучшения производительности сайта, но только если сжатие настроено правильно. Этот раздел скрипта основан на настройках отсюда.
Настройка NGINX для WordPress
Далее скрипт создает файл настройки для WordPress default.conf в каталоге conf.d. Здесь настраивается:
Настройка Certbot для сертификатов от Let’s Encrypt и их автоматическое продление
Certbot — бесплатный инструмент от Electronic Frontier Foundation (EFF), с помощью которого можно получать и автоматически обновлять сертификаты TLS от Let’s Encrypt. Скрипт выполняет следующие действия, приводящие к настройке Certbot для обработки сертификатов от Let’s Encrypt в NGINX:
Дополнительная настройка вашего сайта
Мы выше рассказали о том, как наш скрипт настраивает NGINX и NGINX Unit для обслуживания готового к промышленной работе сайта с включенным TLS\SSL. Вы можете также, в зависимости от ваших нужд, добавить в будущем:
Для еще более лучшей производительности сайта мы рекомендуем обновиться до NGINX Plus, наш коммерческий продукт корпоративного уровня, основанный на NGINX c открытым исходным кодом. Его подписчики получат динамически загружаемый модуль Brotli, а также (за дополнительную оплату) NGINX ModSecurity WAF. Мы также предлагаем NGINX App Protect, модуль WAF для NGINX Plus, основанный на технологии, ведущей в отрасли безопасности, от F5.
Источник