Перейти к содержимому
BXWiki

Облачное хранилище и CDN - вынос файлов, перенос, копии

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

Решение

Когда вынос оправдан

Смотрим, сколько места занимают файлы:

Окно терминала
du -sh /home/bitrix/www/upload/                # каталог загрузок целиком
du -sh /home/bitrix/www/upload/resize_cache/   # уменьшенные копии отдельно
df -h /home                                    # сколько осталось на диске
find /home/bitrix/www/upload -type f | wc -l   # и сколько там файлов

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

Подключение хранилища

Проверяем, что модуль доступен:

use Bitrix\Main\Loader;


if (!Loader::includeModule('clouds')) {
    return; // модуля облачных хранилищ в этой редакции нет
}
// контейнер подключается в админке: адрес сервиса, ключи доступа, имя бакета
// там же задают правила отбора: по ним новые файлы уходят наружу

В коде от подключения остаётся одна проверка. Файл, не подпавший под правила отбора, по-прежнему пишется на диск сервера.

Перенос уже загруженного

Проверяем, где лежит конкретный файл:

$file = CFile::GetFileArray($pictureId);       // описание файла по номеру
if (str_starts_with($file['SRC'], 'http')) {   // внешний адрес вместо пути
    echo 'файл уже в хранилище: ' . $file['SRC'];
}
// в полях элемента лежит номер, поле SRC собирается в момент вывода

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

Раздача и адреса файлов

Смотрим, какой адрес уходит в вёрстку:

Окно терминала
curl -s https://example.ru/catalog/ | grep -o 'src="[^"]*\.jpg"' | head -5
# ждём домен хранилища, а не свой каталог загрузок
curl -sI https://storage.example.com/x.jpg | head -3   # ответ самого хранилища

Пока в исходном коде страницы виден прежний путь, раздачи через сеть доставки нет и ускорения тоже. Встроенное «Ускорение сайта (CDN)» из модуля облачных сервисов - другая технология, и с версии 22.100.0 модуля она отключена.

Что остаётся на диске

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

Окно терминала
du -sh /home/bitrix/www/bitrix/managed_cache/  # кэш ядра, чистится из админки
du -sh /home/bitrix/www/bitrix/backup/         # архивы штатного копирования
du -sh /home/bitrix/www/upload/                # остаток вне правил отбора

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

Резервные копии

Сверяем размер архива с размером сайта:

Окно терминала
ls -lh /home/bitrix/www/bitrix/backup/*.tar.gz | tail -3
du -sh /home/bitrix/www --exclude=upload   # сайт без вынесенных файлов
# архив меньше сайта ровно на объём того, что уехало в хранилище

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

Типичные проблемы

Перенос в облако обрывается каждые 30-40 МБ.

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

Ошибка добавления контейнера: нераспознанный ответ службы.

S3-совместимый сервис отвечает не так, как ожидает модуль: MinIO, например, требует обращения по имени контейнера в домене. Совместимость проверяют на тестовом контейнере с парой файлов, а не сразу на боевом каталоге.

Файл открывается по прямой ссылке, а на странице картинки нет.

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

Сброс кэша подвешивает страницы каталога на минуты.

Уменьшенные копии собираются при первом обращении и сразу уезжают в хранилище по сети. Набор размеров на проекте сокращают, а витрину прогревают заранее, до наплыва посетителей.

В админке пропали превью картинок товара.

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

Частые вопросы

Как настроить экспорт бэкапов сайта в облачное хранилище?

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

«Композитный сайт» и «Ускорение сайта (CDN)» - это одно и то же?

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

Включил CDN, а трафик остался нулевым - почему?

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

Работает ли Битрикс с MinIO как с s3-совместимым хранилищем?

На практике нет: подпись запроса модуль считает по правилам AWS, а MinIO ожидает другую. Остаются сервисы с совместимой подписью либо свой коннектор поверх их API.

Куда попадут новые файлы после подключения хранилища?

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

Смежное

Первоисточник