Storage Server и WordPress: что работает, а что нет

Каталог wp-content/uploads это та часть WordPress, которая растёт без тормозов. Изображения, файлы PDF, видео, и к каждому изображению ещё несколько размеров, которые WordPress создаёт сам. Через пару лет там лежат десятки гигабайт, а место на веб-сервере самое дорогое, какое вообще можно купить.

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

Три случая в обзоре

Последний пункт это тот, на котором спотыкаются чаще всего. Поэтому сначала неудобная правда.

Почему для медиатеки нет плагина

Известные плагины для выноса в WordPress говорят все на одном языке: S3. Они соединяются с Amazon S3 или совместимой службой, загружают файл туда, удаляют локальную копию и подменяют адрес в записи публичным адресом этой службы.

Именно это на Storage Server не переносится, и по двум причинам:

• Хранилище говорит на SMB, SFTP и WebDAV, но не на S3.
• Публичного адреса на каждый файл не существует. Каждое обращение требует входа, значит не может быть и ссылки, которую браузер посетителя откроет напрямую.

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

Путь, который работает: монтировать вместо выноса

На своём сервере с правами root всё переворачивают. Вместо того чтобы учить WordPress говорить с чужим хранилищем, хранилище приводят на то место, куда WordPress пишет и так:

apt install -y cifs-utils
mkdir -p /mnt/storage
printf 'username=u123456-sub1\npassword=ВАШ_ПАРОЛЬ\n' > /etc/samba/storage.cred
chmod 600 /etc/samba/storage.cred

Запись в /etc/fstab:

//u123456.storage.kernelhost.net/backup /mnt/storage cifs credentials=/etc/samba/storage.cred,uid=www-data,gid=www-data,file_mode=0660,dir_mode=0770,seal,_netdev,nofail 0 0

Дальше переносим существующие файлы и заменяем каталог:

mount -a
mkdir -p /mnt/storage/uploads
rsync -a /var/www/example.com/wp-content/uploads/ /mnt/storage/uploads/
mv /var/www/example.com/wp-content/uploads /var/www/example.com/wp-content/uploads.alt
ln -s /mnt/storage/uploads /var/www/example.com/wp-content/uploads

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

Ловушка на этом пути: миниатюры

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

Два решения, оба хорошие:

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

Резервные копии: самая быстрая польза

Если вы сделаете только одну вещь, то эту. Резервная копия на том же сервере это не резервная копия: если диск удалят или сайт зашифруют, она уйдёт вместе с ним. На отдельном хранилище она выживет.

Бесплатный плагин WPvivid умеет в базовой версии копировать на хранилище по SFTP, с расписанием и правилом хранения. Полное руководство к этому есть в статье Резервные копии WordPress на Storage Server.

На своём сервере получается ещё лучше, а именно с rsync или BorgBackup прямо из расписания. Тогда вы передаёте только изменения, а BorgBackup вдобавок дедуплицирует.

Выдача больших загрузок

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

<?php
// в functions.php или как отдельный плагин
add_action('template_redirect', function () {
    if (!isset($_GET['kh_download'])) {
        return;
    }
    if (!is_user_logged_in()) {
        wp_die('Пожалуйста, войдите', '', ['response' => 403]);
    }

    $pfad = '/mnt/storage/downloads/' . basename($_GET['kh_download']);
    if (!is_readable($pfad)) {
        wp_die('Файл не найден', '', ['response' => 404]);
    }

    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename="' . basename($pfad) . '"');
    header('Content-Length: ' . filesize($pfad));
    readfile($pfad);
    exit;
});

Пример исходит из смонтированного хранилища. Без монтирования вы заменяете readfile() вызовом по SFTP или WebDAV, как это описано в статье Storage Server для вашего сайта.

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

Что остаётся на shared-хостинге

На shared-хостинге WebDAV по HTTPS самый надёжный путь, потому что порт 443 практически никогда не закрыт. SFTP тоже работает, но у нас он идёт на порту 23, и не каждый провайдер пропускает исходящие соединения на такие порты. Это стоит коротко проверить до заказа.

По суб-аккаунту на каждую задачу

Каждый Storage Server допускает до 100 суб-аккаунтов, каждый со своим начальным каталогом, своим паролем и своим набором разрешённых протоколов. Для WordPress это значит минимум два:

• Один аккаунт для сайта, которому виден только /uploads.
• Один аккаунт для резервных копий, которому виден только /backup.

Если сайт однажды захватят, злоумышленник найдёт в wp-config.php данные доступа первого аккаунта. Резервные копии останутся нетронутыми, потому что этот аккаунт их просто не знает. С единственным основным аккаунтом в этом месте пропало бы всё.

Когда нескольким пользователям нужно своё место

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

Какой тариф подходит

Для одного сайта на WordPress с резервными копиями Storage-1 как правило хватает надолго. Кто выносит медиатеки нескольких сайтов или работает с видео, быстро приходит к Storage-2 или Storage-3. Все тарифы стоят в Германии, идут без платы за установку, рассчитываются по модели PrePaid и не имеют минимального срока. Переход в следующий по размеру тариф возможен в любое время, без того чтобы трогать данные.