Сегодня WordPress является одной из самых популярных CMS. Задуманная изначально как движок для блогов, сегодня она используется для самых разных типов сайтов, в частности, для новостных порталов и интернет-СМИ. На Wordpress работают корпоративные веб-сайты, образовательные и развлекательные порталы.
Во всех примерах используется Ubuntu 12.04.
Настраиваем СУБД
Выбор СУБД
Как известно, для работы WordPress необходима СУБД MySQL. В последнее время широкое распространение получили альтернативные реализации (форки) этой СУБД, наиболее популярными из которых являются Percona Server и MariaDB. Во многих инструкциях по установке, опубликованных в Интернете, рекомендуется использовать MariaDB.
Мы же рекомендуем использовать Percona Server, так как этот форк по сравнению со стандартным MySQL является более производительным и стабильным. Кроме того, Percona обладает более широкими возможностями для сбора системной статистики.
Чтобы установить Percona на сервер, нужно сначала импортировать ключи:
$ apt-key adv --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
Затем нужно добавить в файл /etc/apt/sources.list следующие репозитории:
deb http://repo.percona.com/apt precise main deb-src http://repo.percona.com/apt precise main
И выполнить команду:
$ sudo apt-get update
После этого можно устанавливать percona-server при помощи стандартного менеджера пакетов:
$ sudo apt-get install percona-server-server percona-server-client
Выбираем движок: MyISAM или InnoDB?
Самыми популярными движками в MySQL-базах являются MyISAM и InnoDB. Если движок выбран неправильно, то возникают проблемы с производительностью и консистентностью.
Рассмотрим особенности этих движков более подробно.
MyISAM показывает хорошие результаты на выборках SELECT, что во многом обусловлено отсутствием поддержки транзакций и внешних ключей. Однако при модификации и добавлении записей вся таблица на время блокируется, что при большой загрузке может стать причиной серьезных задержек.
Несомненными преимуществами этого движка являются также полнотекстовый поиск и компрессия. Формат данных в MyISAM — кроссплатформенный, что позволяет без проблем переносить данные с одного сервера на другой путем простого копирования бинарных файлов (таблиц) баз данных.
InnoDB используется в современных версиях MySQL как движок по умолчанию.
В отличии от MyISAM InnoDB поддерживает транзакции и внешние ключи. В Percona Server используется собственный движок — XtraDB, полностью совместимый с InnoDB. Данные в InnoDB/XtraDB кэшируются. Когда большая часть данных считывается из кэша, производительность InnoDB/XtraDB в разы выше, чем у MyISAM.
Статей, посвященных сравнению MyISAM с InnoDB/XtraDB, а также MySQL c его форками, опубликовано немало (см., в частности, тест производительности здесь). Мы не будем вдаваться в теоретические подробности и ограничимся практическим советом: MyISAM нужно выбирать только в случаях, когда нужен полнотекстовый поиск. Со всеми остальными задачами прекрасно справятся InnoDB/XtraDB. Кстати, в MySQL/Percona Server 5.6+ полнотекстовый поиск для InnoDB уже поддерживается.
Оптимизация конфигурации СУБД
По мере развития сайта количество данных в БД будет расти, и возникнет необходимость изменений настроек базы данных. Чтобы обеспечить оптимальную работу сайта, желательно регулярно проверять, насколько оптимально настроена действующая конфигурация MySQL. Такую проверку проще всего осуществлять с помощью специальных скриптов, самым известным и популярным из которых является mysqltuner.pl. Его можно скачать при помощи следующих команд:
$ wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl $ chmod +x ./mysqltuner.pl $ ./mysqltuner.pl
Этот скрипт собирает статистику MySQL и выдает рекомендации по улучшению существующих настроек.
Настраиваем веб-сервер
Параметры Apache
Настройки apache хранятся в файле /etc/apache2/apache2.conf
В конфигурационном файле Apache имеется такой параметр, как max_clients — максимальное количество процессов, запускаемых для параллельной обработки клиентских запросов. На первый взгляд может показаться, что для этого параметра нужно устанавливать максимальное значение. В реальной практике, однако, все бывает по-другому.
Допустим, один процесс Apache может потребить 20 Мб оперативной памяти. Если для параметра max_clients выставлено значение 200, то при пиковой нагрузке под все процессы потребуется 200×20 Мб = 4Гб памяти — и это только под Apache! В результате нехватки памяти даже самые простые запросы будут выполняться крайне медленно. И программное обеспечение на сервере может перестать работать.
Поэтому слишком большое значение параметра max_clients выставлять не желательно. Если количество запросов превысит установленное значение, то все эти запросы будут поставлены в очередь и обработаны, как только освободятся занятые процессы.
В целях повышения производительности рекомендуется также отключить keepalive-соединения, исправив соответствующую строку в конфигурационном файле:
KeepAlive off
Backend+Frontend = Apache +Nginx
Любой более или менее высоконагруженный веб-проект должен иметь многоуровневую архитектуру (об этом мы уже писали). Для большинства проектов на базе WordPress вполне подойдет двухуровневая архитектура Backend — Frontend. Мы рекомендуем использовать следующую связку: в качестве бэкенда Apache, в качестве фронтенда — Nginx.
Впрочем, возможен и другой вариант — php-fpm в качестве бэкенда, а в качестве фронтенда — все тот же Nginx (см. инструкции по настройке, например, здесь и здесь). Во многих публикациях утверждается, что связка php-fpm+Nginx работает быстрее или потребляет намного меньше памяти. С этими утверждением, однако, вряд ли можно однозначно согласиться.
К тестам, опубликованным в Интернете, нужно относиться со здоровой долей скептицизма: нередко php-fpm+Nginx показывает лучшие результаты лишь потому, что Apache не был настроен должным образом (см., например, отчет о тестировании и его критический разбор; см. также любопытную дискуссию здесь). На основании собственного опыта можем сказать, что для большинства проектов на Wordpress комбинация Apache+Nginx вполне подойдет. Выбор решения должен основываться не только и столько на приросте производительности, сколько на специфке решаемых задач и соображениях технологического удобства. А Apache, на наш взгляд, отличается большей гибкостью конфигурирования. Он может использоваться и как отдельный веб-сервер, и как бэкенд для Nginx, и как фронтенд для php-fpm.
Общая схема работы выглядит так: Nginx принимает запросы от пользователей, которые затем либо передает Apache, либо обрабатывает самостоятельно. Apache будут передаваться запросы, связанные с обработкой динамического контента — например, php-скриптов. Nginx самостоятельно обрабатывает запросы на отдачу статики — например, графики, JS, CSS, текстовых файлов, XML-файлов.
Apache обработав запрос и передав содержимое Nginx, отключается и переходе к обработке других запросов. Благодаря этому работа существенно ускоряется (что немаловажно, например, при медленном интернет-подключении).
Кроме того, раздачу динамических запросов можно ускорить с помощью сервера Memcached (см., например, инструкцию по установке и настройке здесь).
Обеспечиваем безопасность
Для расширения функциональности WordPress используются многочисленные плагины. В этих плагинах постоянно обнаруживаются различные уязвимости, и из-за этого некоторые системные администраторы относятся к ней несколько предвзято. Сайты на базе WordPress действительно часто становятся мишенью для атак, но со временем разработчики совершенствуют плагины, устраняя существующие бреши безопасности. Ниже мы дадим еще несколько советов по настройке WordPress, с помощью которых можно сделать сайт менее уязвимым.
Защититесь от вредоносных программ и уязвимостей в скриптах на сервере, на котором установлен WordPress. Мы рекомендуем использовать сканер ClamAV+Maldet. С инструкцией по установке и настройке AV можно ознакомиться здесь. Для поиска уязвимостей можно также воспользоваться программой WPScan.
Измените префикс таблиц в базе данных. По умолчанию в базе данных WordPress установлен префикс «wp_». Это упрощает использование уязвимостей с MySQL-инъекцией: если известно имя таблицы, в нее гораздо проще вставить вредоносный код, изменить в ней информацию или вообще удалить. В новых версиях WordPress появилась возможность выбора префикса при установке.
Если вы используете раннюю версию WordPress, то изменить префикс можно с помощью специализированных плагинов. Наиболее известным и популярным является Prefix Changer. Следует, однако, учесть, что многие из этих плагинов не всегда работают корректно, поэтому перед их использованием рекомендуется сохранить резервную копию базы данных.
Переместите файл wp-config.php. В файле wp-config.php хранятся важные параметры настройки WordPress, которую желательно защитить от несанкционированного доступа. По умолчанию этот файл сохраняется в корневом каталоге, но его можно переместить на каталог выше. Не обнаружив файла wp-config.php в корневом каталоге, WordPress будет искать его автоматически.
Получите SSL-сертификат и включите SSL-шифрование. Для этого в файл wp-config нужно добавить следующие строки:
/* Enable SSL Encryption */ define(‘FORCE_SSL_LOGIN’, true); define(‘FORCE_SSL_ADMIN’, true);
Удалите информацию о версии WordPress. Если злоумышленник узнает, что вы используете устаревшую версию WordPress, то он может воспользоваться имеющимися уязвимостями и взломать ваш сайт. Поэтому информацию о версии лучше удалить.
Во-первых, нужно удалить файл: ваш_сайт/readme.html, из которого можно без труда узнать, какую версию WordPress вы используете.
Об используемой версии можно также узнать из файла header.php, который находится в папке с темой. Он содержит следующую строку:
<meta name="generator" content="WordPress " />
Можно удалить всю эту строку целиком. Если в файле header.php вашей темы оформления нет такой строки, то, скорее всего она вставляется автоматически WordPress’ом при вызове функции wp_head(). В таком случае удалить информацию о версии из секцииможно, добавив в файл functions.php следующий код:
remove_action(’wp_head’, ’wp_generator’);
function selectel_remove_version() {
return ’’;
}
add_filter(’the_generator’, ’selectel_remove_version’);
Измените ключи безопасности. В упомянутом выше файле wp-config.php есть раздел с ключами безопасности. Выглядит он так:
define(’AUTH_KEY’, ’’); define(’SECURE_AUTH_KEY’, ’’); define(’LOGGED_IN_KEY’, ’’); define(’NONCE_KEY’, ’’);
Ключи используются для хэширования паролей. Очень часто на этот раздел не обращают внимания даже опытные пользователи. Между тем изменить ключи безопасности довольно просто: достаточно зайти на страницу https://api.wordpress.org/secret-key/1.1 и скопировать сгенерированные ключи в файл wp-config.php. Эту процедуру достаточно осуществить всего один раз во время первичной настройки сайта.
Ограничьте доступ к папкам wp-content и wp-includes. Из соображений безопасности рекомендуется закрыть доступ к содержимому папок wp-content и wp-includes. Нужно закрыть доступ к любым файлам, кроме графики, JS и СSS. Для этого нужно в каждой папке создать файл .htaccess и поместить в него такой код:
Order Allow,Deny Deny from all Allow from all
Создайте пустой файл wp-content/plugins/index.html. Благодаря этому станет недоступной информация о том, какие плагины вы используете. В плагинах WordPress могут содержаться уязвимости, и этим могут воспользоваться злоумышленники.
Чтобы сделать листинг недоступным, можно также добавить в файл .htaccess, хранящийся в папке с плагинами, следующую строку:
Options -Indexes
Ограничьте доступ к папке wp-admin.
Чтобы ограничить доступ, нужно в этой папке создать файл .htaccess и поместить в него следующий код:
AuthUserFile /dev/null AuthGroupFile /dev/null AuthName «Access Control» AuthType Basic order deny,allow deny from all # указываем, например. IP-адрес домашнего компьютера allow from # здесь указываем адрес один или несколько IP-адресов, с которых мы будем писать в блог на работе allow from allow from
Ограничивать доступ определенным набором IP-адресов не всегда удобно. Можно настроить доступ к папке wp-admin только по паролю. Для этого нужно создать файл .htauth:
$ htpasswd -c /home/yourdirectory/.htauth
И поместить его на один уровень выше директории /public_html/
Затем нужно создать в папке wp-admin файл .htaccess и поместить в него следующий код:
AuthName «Admins Only» AuthUserFile /home/yourdirectory/.htauth AuthGroupFile /dev/null AuthType basic require user <имя пользователя>
Заключение
Настройка даже такой простой и интуитивно понятной CMS, как WordPress — дело довольно непростое и содержащее большое количество нюансов, на которые не всегда обращают внимание даже опытные пользователи.
Тянуто с Хабра