Меню Рубрики

Установка php nginx wordpress

Предложение от 8host.com

Установка WordPress+Nginx на Ubuntu 14.04

Вступление

WordPress — самая популярная CMS (система управления контентом), позволяющая без труда запустить сайт или блог и управлять его контентом при помощи простого и понятного интерфейса.

В данном руководстве речь пойдет об установке WordPress на сервер Ubuntu 14.04. В качестве веб-сервера будет использован Nginx — мощный и эффективный веб-сервер, широко распространенный благодаря своей производительности.

Предварительные требования

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

Во-первых, понадобится пользователь (не root) с привилегиями sudo. Чтобы создать такого пользователя, выполните шаги 1-4 руководства «Начальная настройка сервера Ubuntu 14.04«.

Кроме того, на сервер должен быть установлен и настроен LEMP stack (система Linux, веб-сервер Nginx, база данных MySQL и PHP). Чтобы получить информацию об установке необходимых компонентов, следуйте руководству «Установка LEMP stack на Ubuntu 14.04«.

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

1: Создание базы данных MySQL и пользователя WordPress

Первое, что нужно сделать для запуска WordPress — подготовить базу данных.

На данный момент на сервере установлена база данных MySQL, но базы данных для информации WordPress пока еще нет. Кроме того, необходимо создать учетную запись, которую WordPress сможет использовать для получения доступа к БД.

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

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

Теперь нужно создать отдельную базу данных, использовать которую будет исключительно WordPress. Название БД не имеет значения, но, вероятно, ее имя должно иметь отношение к проекту, чтоб ее можно было легко распознать. В этом руководстве БД называется wordpress:

CREATE DATABASE wordpress;

Обратите внимание на символ точки с запятой (;) в конце предложения MySQL. Каждое выражение MySQL должно заканчиваться таким символом, потому при возникновении проблем проверьте его наличие в каждой строке.

Теперь БД создана и можно приступить к созданию учетной записи. Затем нужно будет передать управление базой данных этому новому пользователю, чтобы приложение WP могло с ней взаимодействовать. Такой подход (создание индивидуальной базы данных и пользователя для каждого приложения) помогает держать все хранящиеся на MySQL данные отдельно, что очень важно для управления безопасностью и данными.

Для удобства в данном руководстве именем пользователя будет wordpressuser, его паролем — password. Конечно, создавая такого пользователя, стоит выбрать более сложные имя и пароль:

CREATE USER wordpressuser@localhost IDENTIFIED BY ‘password’;

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

GRANT ALL PRIVILEGES ON wordpress.* TO wordpressuser@localhost;

Теперь нужно сбросить привилегии на диск, чтобы текущий экземпляр MySQL узнал об изменениях:

Это вернет командную строку.

2: Загрузка WordPress на сервер

Следующее, что нужно сделать — это загрузить WordPress на сервер, что можно сделать с помощью сайта проекта.

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

Файлы приложения были загружены в виде сжатой, заархивированной структуры каталогов, которая хранится в файле под названием latest.tar.gz. Чтобы извлечь содержимое, наберите:

Это действие создаст каталог под названием wordpress, который содержит все файлы.

Теперь нужно загрузить некоторые дополнительные компоненты, которые могут понадобиться для работы WordPress. Их можно получить прямо из репозиториев программного обеспечения Ubuntu с помощью apt:

sudo apt-get update
sudo apt-get install php5-gd libssh2-php

Данные два пакета позволяют работать с изображениями и удалять/обновлять плагины и компоненты по SSH соответственно.

3: Настройка WordPress

Теперь установленный WordPress нуждается в настройке.

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

Внутри данного каталога находится образец конфигурационного файла под названием wp-config-sample.php. Большинство конфигураций этого файла подходят, поэтому их можно скопировать и использовать в качестве основы конфигурационного файла:

cp wp-config-sample.php wp-config.php

Откройте новый файл и внесите в него изменения:

В целом, файл отвечает требованиям проекта; ему не хватает только информации касательно подключения к созданной базе данных. Параметры, которые нужно установить — DB_NAME, DB_USER и DB_PASSWORD.

Читайте также:  Установка грпш по документам

Данные параметры можно найти и установить в этом файле, тогда сведения о БД и пользовательские данные будут использоваться. Файл выглядит примерно следующим образом:

. . .
// ** MySQL settings — You can get this info from your web host ** //
/** The name of the database for WordPress */
define(‘DB_NAME’, ‘wordpress’);
/** MySQL database username */
define(‘DB_USER’, ‘wordpressuser’);
/** MySQL database password */
define(‘DB_PASSWORD’, ‘password’);
. . .

Внеся все изменения, сохраните и закройте файл.

4: Создание копии файлов

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

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

root документа nginx на Ubuntu 14.04 по умолчанию находится в /usr/share/nginx/html/.

Тем не менее, данный root нужно перенести в /var/www/html/, чтобы избежать изменения расположения каталога, которым управляет пакет Nginx, но об этом чуть позже.

Чтобы создать новый root-каталог документа, наберите:

Теперь скопируйте в него файлы:

Это рекурсивно скопирует содержимое каталога

/wordpress в root документа.

Теперь перейдите в root документа и внесите некоторые изменения в привилегии:

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

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

nginx работает под www-data. Для пользовательской части введите имя учетной записи пользователя. В данном примере используется учетная запись под названием demo:

Эта строка передаст файлам необходимые привилегии.

На данном этапе нужно создать новый каталог для пользовательских закачек:

Новый пока что не принадлежит группе www-data. Исправьте это:

sudo chown -R :www-data wp-content/uploads

5: Настройка Nginx

Итак, теперь файлы и каталоги отредактированы. На данном этапе нужно изменить конфигурации nginx, чтобы веб-сервер работал должным образом.

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

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/wordpress

Откройте новый файл и внесите некоторые изменения:

sudo nano /etc/nginx/sites-available/wordpress

server <
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /var/www/html;
index index.php index.php index.html index.htm;
server_name your_domain.com;
location / <
# try_files $uri $uri/ =404;
try_files $uri $uri/ /index.php?q=$uri&$args;
>
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
location = /50x.html <
root /usr/share/nginx/html;
>
location

\.php$ <
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
>
>

Вот краткий список изменений, которые необходимо внести:

  • изменить значение директивы root и указать на /var/www/html.
  • изменить параметр index, чтобы файл index.phpраньше остальных был найден .
  • изменить значение директивы server_name, указав домен или IP сервера.
  • отредактировать try_files в разделе location/, чтобы иметь возможность отправлять запросы PHP.

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

Чтобы активировать новый файл, нужно связать его с каталогом sites-enabled. Это делается так:

sudo ln -s /etc/nginx/sites-available/wordpress/ /etc/nginx/sites-enabled/

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

sudo rm /etc/nginx/sites-enabled/default

Теперь перезапустите веб-сервер и PHP:

sudo service nginx restart
sudo service php5-fpm restart

6: Завершение инсталляции с помощью веб-интерфейса

Для завершения инсталляции WordPress используйте веб-браузер.

Направьте его на домен или IP сервера:

Если браузер возвращает старую страницу по умолчанию nginx, нужно обновить страницу без кэша.

Появится приветственная страница WordPress. Выберите параметры (имя сайта, имя пользователя, пароль, и email), а затем нажмите кнопку Install WordPress.

Войдите с помощью созданной только что учетной записи.

Будет открыта инструментальная панель WordPress, с помощью которой можно редактировать настройки и публиковать контент.

Итоги

Теперь ​​WordPress установлен и использует веб-сервер Nginx на Ubuntu 14.04. WordPress — довольно гибкая платформа, которую можно использовать для настройки сайта. Поэкспериментируйте с некоторыми плагинами, темами и т.д., чтобы выбрать наиболее подходящие.

Читайте также:  Установка жесткого диска с другого ноутбука

источник

Очень шустрый блог на WordPress при помощи связки nginx + PHP-FPM + MariaDB + Varnish

CPU: 1 x 2GHz
HDD: 10Gb
RAM: 512Mb
OS: Debian 8 x64

Схема работы системы выглядит следующим образом:

Описание работы схемы

Для посетителей сайта происходит перенаправление на HTTPS, где nginx работает в качестве прокси для Varnish, при этом на выходе nginx помимо реализации HTTPS-соединения происходит gzip-сжатие данных, передаваемых пользователю. Следующим элементом в данной системе является HTTP-акселератор Varnish, ожидающий соединения на 6081 порту. Получая запрос от клиента он выполняет поиск запрашиваемого URL в кэше, и в случае его обнаружения мгновенно отдаёт его фронтенду. Таким образом, при наличии запрашиваемого файла в кэше скорость запроса к страницам сокращается до скорости запроса к статическим данным. Если же запрашиваемого файла в кэше не обнаруживается, Varnish передаёт запрос бэкенду. Так же в Varnish реализована оптимизация клиентской стороны — здесь статическим данным устанавливаются заголовки Cache-Control и Expires, указывающие браузеру на необходимость кэширования этих данных на стороне клиента. Таким образом сокращается время загрузки сайта и уменьшается нагрузка на сервер.

В роли бэкенда выступает опять же nginx, ожидающий соединений на 127.0.0.1:81. Интерпретация PHP реализована с помощью FPM. Версия PHP — 5.6 с включенным по умолчанию акселератором OPcache. В качестве СУБД — MariaDB 10, являющаяся одной из лучших по производительности и кушающих в меру оперативную память СУБД среди форков MySQL. В качестве движка таблиц — MyISAM, так как запись производится редко, в основном чтение, для которого данный движок больше оптимизирован. За счёт отключения движка InnoDB реализуется экономия оперативной памяти. Наконец, в качестве CMS функционирует WordPress с установленным плагином Varnish HTTP Purge, отправляющий PURGE-запросы на адреса страниц, на которых были произведены изменения, что приводит к очистке кэша Varnish для данных страниц. Таким образом, пользователь получает всегда актуальную версию сайта. Далее я детально расскажу об установке и настройке данных компонентов, а так же о проблемах, с которыми я столкнулся.

Установка и настройка nginx

Содержимое основного конфига /etc/nginx/nginx.conf:

Создадим файл настроек бэкенда /etc/nginx/conf.d/backend.conf:

На тему детального описания настройки HTTPS в nginx рекомендую к прочтению данную статью: habrahabr.ru/post/252821
Создаём файл настроек фронтэнда /etc/nginx/conf.d/frontend.conf:

Теперь при попытке зайти на сайт увидим ошибку 502. Это нормально, так как Varnish пока не запущен.

Установка и настройка Varnish

Файл параметров запуска располагается здесь — /etc/default/varnish. В DAEMON_OPTS задаём следующие параметры:

-a — задаёт порт, на котором Varnish будет принимать соединения, в нашем случае от фронтенда — nginx;
-T — здесь крутится админка, подробнее в описании к флагу -S;
-f — файл с конфигурацией VCL — специальном языке, предназначенном для определения правил обработки запросов и кэширования в Varnish;
-S — Varnish имеет панель администрирования. Для входа необходимо выполнить команду varnishadm, при этом пользователь должен иметь права на чтение файла /etc/varnish/secret для прохождения аутентификации;
-s указание места хранения кэша и его размер, в данном случае 128Mб в оперативной памяти.

Как вы уже, наверное, поняли, самое интересное нас ждёт в файле с правилами обработки запросов. Во время старта процесса Varnish’а данный файл компилируется. В VCL используется несколько подразделов-функций, в которых описываются эти правила. Кратко расскажу о них, полное описание рекомендую прочитать на официальном сайте.

sub vcl_recv — данная функция используется когда приходит запрос от клиента;
sub vcl_pass — выполняется, когда запрос клиента необходимо передать напрямую бэкенду, не кэшировать и не искать соответствия в кэше;
sub vcl_hash — определяет правила кэширования, можно использовать несколько хранилищ для одного и того же документа, в зависимости от разных условий, например, поддержки сжатия клиентом, или каких-либо других особенностей клиента. В нашем случае не будет использоваться, так как клиент у нас для Varnish’а один — nginx на фронтенде;
sub vcl_backend_response — данная функция используется когда приходит запрос от бэкенда (nginx);
sub vcl_deliver — используется непосредственно перед отправкой данных клиенту, например, для добавления/изменения заголовков.

Схема работы компонентов VCL может быть представлена следующим образом:

Если обращение к бэкенду происходит при этом из функции vcl_miss ответ бэкенда отправляется и в кэш. Сам язык очень похож на C. Приступим к настройке. Открываем файл /etc/varnish/default.vcl и начинаем кодить:

Читайте также:  Установка кулеров на вдув или выдув

После чего выполняем команду:

Перейдя теперь в браузере на наш сайт, мы увидим index.php, который нужно предварительно создать.

Проблема Varnish и Debian 8

А что если вы захотите изменить порт, на котором Varnish будет принимать входящие соединения или изменить объём кэша. Судя по официальной документации нужно изменить файл с параметрами запуска Varnish, располагающийся по пути: /etc/default/varnish и перезапустить сервис. Но нет! Ничего не изменится, и если мы зайдём в top и нажмем на клавишу ‘c’, то увидим, что сервис запущен с прежними настройками. А всё дело в том, что в новой версии Debian используется systemd вместо init.d в качестве системы инициализации, и поэтому нужно зайти в файл /lib/systemd/system/varnish.service и прописать там в директиве ExecStart те же параметры запуска:

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

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

Установка и настройка PHP-FPM

Устанавливаем FPM и библиотеку PHP для работы с СУБД:

Заходим в файл конфигурации /etc/php5/fpm/pool.d/www.conf и меняем директиву:

В этом же файле задаём настройки воркеров:

Меняем несколько директив в /etc/php5/fpm/php.ini

post_max_size задаём чуть больше, чем upload_max_filesize, так как помимо файла в запросе идут другие данные.
Здесь же директивой allow_url_fopen запрещаем выполнять скрипты, расположенные удаленно (убирая возможность эксплуатации уязвимости удалённого инклуда).

И говорим FPM перечитать конфиг:

Теперь создайте файлик, выводящий phpinfo() и обратитесь к нему в браузере, всё должно работать. Не забывайте, что он уже закэшировался в Varnish и если вы будете изменять конфигурацию PHP, то она не будет обновляться в вашем браузере. Можете написать правило на пропуск данного файла в Varnish, либо же на время тестов проксировать не Varnish, а напрямую бэкенд на 81 порту.

Установка и настройка MariaDB

Эту СУБД я выбрал по причине её лучшей производительности и способности выдерживать большие нагрузки, при этом затрачивая меньшее количество оперативной памяти по сравнению с MySQL, а так же её полной совместимостью с WordPress. Установка очень проста, будет запрошен пароль для пользователя root.

В качестве движка для таблиц я использую MyISAM, по причине того, что запись в таблицу выполняется редко, а на чтении MyISAM показывает лучшие характеристики. Я полностью отключил поддержку InnoDB для освобождения оперативной памяти. Настройки хранятся в файле /etc/mysql/my.cnf. Опишу только те директивы, которые я изменил:

После сохранения изменений перезапускаем сервис:

Настройка WordPress — плагин «Varnish HTTP Purge»

Устанавливаем в панели администрирования WP плагин «Varnish HTTP Purge». Теперь при обновлении данных на измененные страницы будет отправлен PURGE-запрос, очищающий кэш в Varnish, и для посетителей данные всегда будут обновлёнными.

Дополнительная оптимизация

Для оптимизации клиентской стороны с помощью Varnish мы указываем браузеру на необходимость хранения статических данных в локальном кэше клиента. Но если вы жаждете ещё большей оптимизации, перейдите на страничку developers.google.com/speed/pagespeed/insights и введите URL вашего сайта или даже конкретной страницы. Вам предоставится список рекомендаций, а так же предложат архив со сжатыми версиями ваших css и js стилей. Замените их на своём сайте и получите ещё большую скорость загрузки за счёт уменьшенного объема передаваемых данных, так же уменьшится нагрузка на сервер и место, занимаемое данными файлами в кэше.

Как поступить с документами, запрашиваемыми со сторонних серверов, например, шрифтами или библиотекой jquery? Можно перенести их к себе, и тут за счёт установки соединения только с одним сервером возрастёт скорость загрузки страниц, однако, в то же время, возрастёт список обращений и общая нагрузка. Какой вариант выбрать — решайте сами, в зависимости от загруженности вашего сервера и вашей лени.

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

После

Полноценные стресс-тесты проведу чуть позже.

источник

Добавить комментарий

Adblock
detector