S3 CDN URL с именем бакета? - MinIO

,

Я запускаю экземпляр MinIO с несколькими серверами за прокси-сервером Nginx.
При интеграции с MinIO у меня возникли трудности, и сегодня я обнаружил, что для отображения загруженных изображений параметр «S3 CDN URL» нужно указывать не как «cdn.example.com», а как «cdn.example.com/bucket_name».

Возможно, это связано с моей собственной настройкой MinIO, поэтому позвольте предоставить немного больше информации.
У меня есть два сервера, на которых запущен MinIO для одного и того же контента. Оба сервера сопоставлены с внутренними IP-адресами, например 192.168.1.1 и 192.168.1.2. Порт для доступа к API — 9000, порт для доступа к консоли — 9001. (Хотя я использую разные IP-адреса и порты, это сделано для иллюстрации.)

Сначала у меня возникли проблемы с параметром «S3 endpoint».

При указании «https://cdn.example.com» в качестве конечной точки я постоянно получал ошибки. Я также пробовал использовать доступ к консоли, например «s3.example.com» — URL-адрес, который я использую для распределения трафика на уровне прокси-сервера Nginx для консоли. Ни один из вариантов не сработал.

Сегодня я изменил конечную точку на «http://192.168.1.1:9000», как это делаю с NextCloud. (У меня были похожие проблемы с NextCloud). Наконец, я увидел, что файлы загружаются в S3. Однако изображения на Discourse по-прежнему не отображались. Когда я проверил URL-адрес пустого изображения, он выглядел так: «cdn.example.com/original/1x/…». Иными словами, отсутствовало имя корзины S3, которое я добавил в настройки.

Поэтому я изменил «S3 CDN URL» на «https://cdn.example.com/my_bucket_name». Теперь я наконец вижу изображения как при редактировании тем на Discourse, так и на живом сайте.

Поскольку всё работает, я собирался отложить это и вернуться к другим своим сайтам, но затем обнаружил, что «S3 Backup Bucket» должен иметь другое имя корзины, чем основная корзина для загрузки. Если я включу опцию «Использовать CDN URL для всех файлов, загружаемых в S3, а не только для изображений», что произойдет с резервной копией S3? Будет ли файл резервной копии загружен по адресу «https://cdn.example.com/backup_bucket»?

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

На данный момент, если я не неправильно настроил MinIO и/или Discourse, логично предположить, что «S3 CDN URL» должен включать имя основной корзины для загрузки и имя корзины для резервного копирования. Тогда я смогу вернуться с «https://cdn.example.com/my_bucket_name» на «https://cdn.example.com».

Кроме того, я предпочитаю не использовать внутренний IP-адрес в качестве «S3 endpoint». Я задал тот же вопрос в сообществе NextCloud. Как работает модуль S3 в Discourse? Просто интересно, почему мне приходится указывать полный внутренний IP-адрес с портом вместо FQDN, который я назначил на уровне прокси-сервера. FQDN определенно помогает перенаправлять трафик в случае сбоя одного из серверов MinIO. При текущих настройках, если основной сервер бэкенда выйдет из строя, чтение может работать (благодаря CDN), но операции записи — нет.

Возможно, или, скорее всего, это связано с моей ошибочной конфигурацией и/или несовместимостью с MinIO/AWS SDK. Пока я воспользуюсь временным решением.

Похоже, вы используете бакеты в стиле пути (minio.example.com/bucketname), что не работает. Необходимо настроить MINIO_DOMAIN, что неявно включит бакеты в стиле виртуального хоста (bucketname.minio.example.com).

См. Core Settings | MinIO AIStor Documentation

Спасибо за быстрый ответ.

Тогда просто интересно, почему URL изображения не был в формате ‘bucketname.cdn.example.com’?
Было ли это связано с тем, что я добавил URL CDN, который работает примерно как URL CloudFront? В моём случае, без URL CDN, я опасался, что путь к файлу изображения может выглядеть так: http://bucket_name.192.168.1.1:9000/original/1x/…

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