Как установить и настроить MinIO на VPS

MAATRIX

Когда файлы приложения — аватарки, бэкапы, видео, артефакты сборки — перестают помещаться в обычную папку на диске, встаёт вопрос: платить AWS S3 в валюте и зависеть от чужой инфраструктуры, или поднять объектное хранилище у себя. MinIO решает именно эту задачу: это S3-совместимый сервер, который вы разворачиваете на своём VPS за 15 минут и получаете тот же API, что у AWS S3, но под полным контролем и без счетов в долларах.

Что такое MinIO и когда он нужен вместо AWS S3

MinIO — открытый (AGPLv3) объектный сервер, который реализует S3 API почти полностью: те же методы PUT/GET/DELETE, presigned URL, версионирование объектов, политики доступа, multipart upload для больших файлов. Для приложения, которое уже умеет работать с S3-совместимым хранилищем (а таких сегодня большинство — от Django с django-storages до Nextcloud и бэкап-утилит вроде restic), переход на MinIO означает просто смену endpoint и ключей, без переписывания кода.

Типичные сценарии, где MinIO оправдан:

• хранилище для бэкапов (дампы БД, снапшоты Docker-volume, архивы конфигов);
• медиатека приложения (загружаемые пользователями файлы, генерируемые отчёты, экспорты);
• промежуточный слой для CI/CD — артефакты сборки, кэш Docker-слоёв;
• S3-совместимый бэкенд для self-hosted сервисов (Nextcloud, Immich, Loki, Thanos и т.д. умеют писать напрямую в S3-хранилище).

Если вам нужен ровно один инструмент «залил файл — получил ссылку», MinIO избыточен: проще смонтировать диск или использовать SFTP. MinIO имеет смысл, когда важны именно API-совместимость с S3, множественные bucket'ы с разными правами доступа, версионирование или интеграция с готовыми S3-клиентами.

Важная оговорка: с 2023 года MinIO урезал часть функциональности консоли управления в open-source версии, а AGPL-лицензия обязывает публиковать код, если вы модифицируете и раздаёте сервис как услугу. Для внутреннего использования на своём VPS это не проблема — ограничения касаются в первую очередь тех, кто перепродаёт MinIO как сервис.

Требования к серверу и подготовка

MinIO не капризен к ресурсам для старта, но диск — главный ограничитель, потому что это хранилище файлов, а не вычислений.

Минимум для тестового/небольшого продакшена:

• 1-2 vCPU, 2 ГБ RAM — MinIO сам по себе лёгкий, память в основном уходит под кэш файловой системы;
• отдельный диск или раздел под данные — не системный /, иначе рост хранилища упрётся в ОС;
• Ubuntu 24.04 или Debian 12 — обе версии поддерживаются официально, ниже примеры для Ubuntu/Debian;
• домен (поддомен), направленный на IP сервера, если планируете доступ по HTTPS извне — например s3.example.com.

Сколько закладывать под диск, зависит от нагрузки: если это бэкапы с ротацией, считайте объём одного бэкапа × количество хранимых копий × 1.3 (запас). Общий подход к расчёту дискового пространства на VPS разобран в статье сколько дискового пространства закладывать с запасом.

Перед установкой обновите систему и создайте отдельного пользователя, от которого будет работать сервис (не root):

apt update && apt upgrade -y
useradd -r -s /sbin/nologin minio-user
mkdir -p /data/minio
chown minio-user:minio-user /data/minio

Установка MinIO через Docker Compose

Самый предсказуемый способ развернуть MinIO — через Docker, особенно если у вас уже есть compose-стек с другими сервисами. Если Docker ещё не установлен, порядок разворачивания production-стека на Compose подробно описан в статье как установить и настроить Docker Compose для продакшена на VPS.

Создайте директорию проекта и docker-compose.yml:

mkdir -p /opt/minio && cd /opt/minio

# /opt/minio/docker-compose.yml
services:
  minio:
    image: minio/minio:latest
    container_name: minio
    restart: unless-stopped
    command: server /data --console-address ":9001"
    environment:
      MINIO_ROOT_USER: admin_minio
      MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD}
    ports:
      - "127.0.0.1:9000:9000"   # S3 API
      - "127.0.0.1:9001:9001"   # веб-консоль
    volumes:
      - /data/minio:/data
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]
      interval: 30s
      timeout: 5s
      retries: 3

Обратите внимание: порты пробрасываются только на 127.0.0.1 — наружу MinIO смотреть не будет, доступ снаружи организуем через реверс-прокси с TLS (ниже). Root-пароль вынесите в .env, а не в сам compose-файл:

echo "MINIO_ROOT_PASSWORD=$(openssl rand -base64 24)" > /opt/minio/.env
chmod 600 /opt/minio/.env

Запуск:

docker compose up -d
docker compose logs -f minio

Если в логах видно API: http://...:9000 и Console: http://...:9001 без ошибок — сервис поднялся. Логин от root-пароля храните отдельно (менеджер паролей, зашифрованный файл) — это единственный ключ, который открывает полный доступ ко всем данным.

Настройка домена и TLS через реверс-прокси

MinIO умеет сам терминировать TLS, если положить сертификаты в ~/.minio/certs, но на практике удобнее вынести TLS на Caddy или nginx, которые уже стоят перед другими сервисами на сервере. Caddy особенно удобен тем, что сам получает и продлевает сертификат Let's Encrypt — подробная установка описана в статье как установить и настроить Caddy с авто-SSL на VPS.

Пример Caddyfile для двух поддоменов — API и консоли:

s3.example.com {
    reverse_proxy 127.0.0.1:9000
}

s3-console.example.com {
    reverse_proxy 127.0.0.1:9001
}

Для nginx (если он уже используется как основной реверс-прокси) конфиг выглядит так — важно увеличить client_max_body_size, иначе большие файлы будут обрываться:

server {
    listen 443 ssl;
    server_name s3.example.com;

    client_max_body_size 0;
    ignore_invalid_headers off;
    proxy_buffering off;

    location / {
        proxy_pass http://127.0.0.1:9000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

После настройки TLS S3 API должен отвечать на https://s3.example.com, а консоль — на https://s3-console.example.com. Консоль стоит закрыть дополнительно (Basic Auth на уровне прокси или ограничение по IP) — это административная панель с полным доступом к данным.

Работа с mc: bucket'ы, пользователи и политики доступа

MinIO Client (mc) — официальная утилита для управления сервером из терминала, аналог aws s3 для AWS. Установка на сервере (или на локальной машине, откуда вы администрируете хранилище):

curl https://dl.min.io/client/mc/release/linux-amd64/mc -o /usr/local/bin/mc
chmod +x /usr/local/bin/mc
mc alias set myminio https://s3.example.com admin_minio 'ВАШ_ROOT_ПАРОЛЬ'

Создание bucket'а и проверка:

mc mb myminio/backups
mc ls myminio

В продакшене не работают под root-пользователем — создайте отдельного сервисного пользователя с ограниченной политикой на конкретный bucket:

mc admin user add myminio backup-service SuperSecretPass123

Политика, разрешающая только чтение/запись в bucket backups:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket", "s3:DeleteObject"],
      "Resource": ["arn:aws:s3:::backups", "arn:aws:s3:::backups/*"]
    }
  ]
}

mc admin policy create myminio backup-rw policy-backups.json
mc admin policy attach myminio backup-rw --user backup-service

Теперь этот пользователь может писать в backups, но не видит другие bucket'ы и не может управлять сервером. Такой подход — один сервисный пользователь на приложение — избавляет от ситуации, когда компрометация одного ключа открывает доступ ко всему хранилищу.

Полезно сразу включить версионирование для bucket'ов с важными данными — это защищает от случайного перезаписывания или удаления файла:

mc version enable myminio/backups

Резервное копирование и мониторинг

MinIO хранит данные на обычной файловой системе (при запуске в single-node режиме — без erasure coding, это важно понимать: если диск умрёт, данные без внешнего бэкапа теряются). Поэтому резервное копирование самого хранилища MinIO не менее важно, чем то, что вы бэкапите через него.

Варианты:

Зеркалирование в другое S3-совместимое хранилище одной командой:

mc alias set remote https://s3.remote-provider.com KEY SECRET
mc mirror --watch myminio/backups remote/backups-mirror

Флаг --watch держит процесс запущенным и синхронизирует изменения непрерывно — удобно для фонового сервиса через systemd или в отдельном контейнере.

Если вы бэкапите MinIO как обычный Docker-volume, общие подходы и частые ошибки (неполные снапшоты при работающем сервисе, забытые точки монтирования) разобраны в статье как установить и настроить бэкап Docker-volume на VPS.

Для мониторинга у MinIO есть встроенный Prometheus-эндпоинт:

mc admin prometheus generate myminio

Команда выведет готовый scrape-конфиг с токеном — добавьте его в Prometheus, чтобы отслеживать использование диска, число запросов и ошибки. Отдельно стоит держать алерт на заполнение диска под данными MinIO — том с объектами растёт незаметно, и стоит мониторить его так же, как обычный дисковый раздел (см. как установить и настроить мониторинг диска на VPS).

Безопасность: ключи, firewall и типичные ошибки

Несколько вещей, которые стоит сделать сразу, а не после инцидента:

• Не открывайте порты 9000/9001 наружу через firewall — весь внешний трафик идёт через реверс-прокси с TLS; сам MinIO слушает только 127.0.0.1.
• Root-ключи не используются приложениями — root-пара только для mc admin, каждый сервис получает свой ограниченный ключ.
• Ротация ключей. Если ключ засветился в логах или репозитории, отзовите его (mc admin user disable) и выпустите новый, не пересоздавая аккаунт целиком.
• HTTPS обязателен, если API доступен за пределами localhost — иначе ключи передаются в открытом виде при каждом запросе.
• Бэкапьте .env и структуру bucket'ов отдельно от самих данных — потеря root-пароля без доступа к серверу означает полную блокировку администрирования.

Частая ошибка новичков — запускать MinIO в distributed-режиме «для надёжности» на одном сервере с несколькими директориями на одном физическом диске. Erasure coding защищает от отказа отдельного диска, а не от отказа сервера целиком, поэтому на одной машине с одним диском это ложное чувство безопасности — реальную отказоустойчивость даёт только зеркалирование на другой сервер.

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