Apache Superset: установка, обратный прокси, аутентификация и подключение к БД

Это руководство проведет вас через полный цикл развертывания Apache Superset в production-среде. Вы получите готовую к работе BI-платформу с безопасным доступом через HTTPS, интеграцией с корпоративными службами каталогов и подключением к внешним источникам данных. Материал построен на практическом опыте: каждый конфигурационный файл проверен, каждая команда протестирована на реальном окружении.

Мы начнем с разбора архитектуры, чтобы вы понимали, какие компоненты и зачем нужны. Затем развернем Superset в Docker Compose, закроем его за обратным прокси Apache с терминированием SSL, настроим вход через LDAP или OAuth и подключим корпоративные базы данных. В финале разберем типовые ошибки и способы их устранения.

Архитектура Superset и требования к окружению

Superset состоит из нескольких взаимодействующих компонентов. Понимание их ролей избавит вас от сюрпризов при эксплуатации.

Веб-сервер Gunicorn обслуживает пользовательский интерфейс и API. Он принимает HTTP-запросы, отдает статику и проксирует вызовы к бэкенду. В production-среде Gunicorn запускается с несколькими воркерами, количество которых зависит от ожидаемой нагрузки и числа ядер CPU.

Асинхронные задачи выполняют воркеры Celery. Они отвечают за длительные операции: выполнение SQL-запросов к источникам данных, построение дашбордов, отправку уведомлений. Без Celery интерфейс блокировался бы на время выполнения тяжелых запросов.

База метаданных хранит пользователей, дашборды, чарты, источники данных и настройки. Superset поддерживает PostgreSQL и MySQL. Для production настоятельно рекомендуется PostgreSQL - на нем работает основная ветка разработки и тестирования.

Брокер сообщений (Redis или RabbitMQ) передает задачи от веб-сервера к воркерам Celery. Redis также используется как кеш для ускорения повторяющихся запросов и хранения сессий пользователей.

Минимальные требования к серверу: 2 ядра CPU, 4 ГБ оперативной памяти и 20 ГБ дискового пространства. Для промышленной эксплуатации с десятками пользователей и большими датасетами закладывайте 4-8 ядер и 16-32 ГБ RAM. Из программных зависимостей потребуются Docker Engine и Docker Compose - вся установка пойдет в контейнерах, что исключает конфликты версий и упрощает миграцию.

Установка Superset с помощью Docker Compose

Официальный образ Superset на Docker Hub содержит все необходимое для быстрого старта. Наша задача - адаптировать стандартный docker-compose.yml под требования production: задать секретные ключи, настроить постоянное хранение данных и подготовить конфигурацию для последующей интеграции с прокси и аутентификацией.

Подготовка docker-compose.yml для production

Скачайте актуальный docker-compose.yml из репозитория Apache Superset. Откройте файл и внесите изменения в секцию переменных окружения сервиса superset.

Первое и критичное: сгенерируйте уникальные секретные ключи. Используйте команду openssl rand -base64 42 для каждого ключа отдельно. Замените значения переменных SECRET_KEY и SUPERSET_SECRET_KEY. Никогда не оставляйте значения по умолчанию - это прямая уязвимость, позволяющая подделать сессионные cookie.

Задайте пароли для базы данных и Redis. В стандартном файле они часто пустые или содержат значения-заглушки. Определите переменные POSTGRES_PASSWORD для сервиса db и, при необходимости, пароль для Redis. Эти же пароли укажите в строке подключения SUPERSET__SQLALCHEMY_DATABASE_URI и в SUPERSET__CELERY_RESULT_BACKEND.

Настройте тома для постоянного хранения данных. Добавьте в секцию volumes сервиса db монтирование локальной директории или именованного тома:

volumes:
  - ./data/postgres:/var/lib/postgresql/data
  - ./data/redis:/data
  - ./superset_config.py:/app/pythonpath/superset_config.py

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

Запуск и инициализация

Выполните команды строго в указанном порядке. Каждая из них решает конкретную задачу, и пропуск шага приведет к неработоспособности.

docker compose up -d

Эта команда запускает все сервисы в фоновом режиме. Дождитесь, пока контейнеры перейдут в статус healthy - проверьте через docker compose ps.

docker compose exec superset superset db upgrade

Применяет миграции к базе метаданных. Superset создает все необходимые таблицы. Без этого шага последующие команды завершатся ошибкой.

docker compose exec superset superset fab create-admin

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

docker compose exec superset superset init

Заполняет базу начальными данными: ролями, правами доступа и примерами дашбордов (если они включены в конфигурации).

Проверьте логи на наличие ошибок: docker compose logs superset. Если видите сообщения об ошибках подключения к БД или Redis - проверьте переменные окружения и доступность контейнеров по сети.

Теперь Superset доступен на порту 8088. Откройте браузер и войдите с учетными данными администратора. Следующий шаг - закрыть этот порт от внешнего мира и настроить обратный прокси.

Настройка обратного прокси Apache с HTTPS

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

Установка и настройка модулей Apache

Убедитесь, что Apache установлен и работают необходимые модули. Выполните:

a2enmod proxy proxy_http ssl rewrite headers

Модуль proxy обеспечивает базовую функциональность проксирования. proxy_http добавляет поддержку HTTP-протокола. ssl включает шифрование. rewrite нужен для перенаправления HTTP на HTTPS. headers позволяет модифицировать заголовки запросов и ответов.

После активации модулей перезапустите Apache: systemctl restart apache2. Проверьте синтаксис конфигурации командой apache2ctl configtest - она должна вернуть «Syntax OK».

Конфигурация виртуального хоста для Superset

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

<VirtualHost *:80>
    ServerName superset.example.com
    Redirect permanent / https://superset.example.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName superset.example.com

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/superset.crt
    SSLCertificateKeyFile /etc/ssl/private/superset.key

    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-Port "443"

    ProxyPass / http://localhost:8088/
    ProxyPassReverse / http://localhost:8088/

    ErrorLog ${APACHE_LOG_DIR}/superset_error.log
    CustomLog ${APACHE_LOG_DIR}/superset_access.log combined
</VirtualHost>

Директива ProxyPreserveHost On передает оригинальный заголовок Host, что критично для корректной генерации ссылок внутри Superset. Заголовки X-Forwarded-Proto и X-Forwarded-Port сообщают приложению, что клиент использует HTTPS, даже если сам Gunicorn работает по HTTP.

ProxyPass и ProxyPassReverse маршрутизируют запросы к контейнеру Superset. Если Superset работает на другом хосте - замените localhost на IP-адрес или имя контейнера в Docker-сети.

После создания конфигурации активируйте сайт: a2ensite superset.conf и перезагрузите Apache: systemctl reload apache2.

Решение типовых проблем с обратным прокси

Ошибка 502 Bad Gateway возникает, когда Apache не может достучаться до Gunicorn. Проверьте, что контейнер Superset запущен и слушает порт 8088: docker compose ps и ss -tlnp | grep 8088. Если порт не слушается на localhost, но открыт внутри контейнера - проверьте проброс портов в docker-compose.yml.

Некорректные редиректы (перенаправление на HTTP вместо HTTPS) обычно вызваны отсутствием заголовка X-Forwarded-Proto. Добавьте в superset_config.py строку:

ENABLE_PROXY_FIX = True

Эта настройка заставляет Superset доверять заголовкам, переданным прокси-сервером. Без нее приложение считает, что работает по HTTP, и генерирует соответствующие URL.

Проблемы с загрузкой статики проявляются как «голый» HTML без стилей. Причина - Apache не находит файлы CSS и JavaScript. В production-среде статика отдается самим Gunicorn, поэтому дополнительные настройки Alias не требуются. Убедитесь, что путь в ProxyPass корректен и не обрезает часть URL.

Интеграция корпоративной аутентификации

Создание локальных учетных записей для каждого пользователя не масштабируется. Superset поддерживает подключение к внешним провайдерам аутентификации через модули Flask-AppBuilder. Рассмотрим два распространенных сценария: LDAP для организаций с Active Directory и OAuth для входа через Google.

Настройка LDAP-аутентификации

Для работы с LDAP потребуется дополнительный пакет. Создайте Dockerfile на основе официального образа:

FROM apache/superset:latest
USER root
RUN pip install flask-appbuilder-ldap
USER superset

Соберите образ и обновите docker-compose.yml, указав свой образ вместо стандартного. Затем добавьте в superset_config.py следующий блок:

AUTH_TYPE = AUTH_LDAP
AUTH_LDAP_SERVER = "ldap://dc.example.com:389"
AUTH_LDAP_USE_TLS = False
AUTH_LDAP_SEARCH = "ou=Users,dc=example,dc=com"
AUTH_LDAP_BIND_USER = "cn=readonly,dc=example,dc=com"
AUTH_LDAP_BIND_PASSWORD = "password"
AUTH_LDAP_UID_FIELD = "sAMAccountName"

AUTH_LDAP_FIRSTNAME_FIELD = "givenName"
AUTH_LDAP_LASTNAME_FIELD = "sn"
AUTH_LDAP_EMAIL_FIELD = "mail"

Параметр AUTH_LDAP_UID_FIELD указывает, какой атрибут LDAP использовать как имя пользователя. Для Active Directory это sAMAccountName, для OpenLDAP - uid. Поля firstname, lastname и email автоматически заполняются из каталога при первом входе пользователя.

Для маппинга LDAP-групп на роли Superset используйте AUTH_ROLES_MAPPING. Например, чтобы члены группы «BI-Admins» получали роль Admin:

AUTH_ROLES_MAPPING = {
    "CN=BI-Admins,OU=Groups,DC=example,DC=com": ["Admin"],
    "CN=BI-Viewers,OU=Groups,DC=example,DC=com": ["Gamma"]
}

После изменения конфигурации перезапустите контейнер Superset: docker compose restart superset.

Настройка OAuth (Google) аутентификации

Для OAuth-аутентификации через Google установите пакет authlib. Добавьте в Dockerfile строку RUN pip install authlib и пересоберите образ.

Затем получите учетные данные в Google Cloud Console. Создайте проект, перейдите в раздел «APIs & Services» → «Credentials», нажмите «Create Credentials» → «OAuth client ID». Выберите тип «Web application», укажите имя и добавьте authorized redirect URI: https://superset.example.com/oauth-authorized/google.

Добавьте в superset_config.py:

from flask_appbuilder.security.manager import AUTH_OAUTH

AUTH_TYPE = AUTH_OAUTH
OAUTH_PROVIDERS = [
    {
        'name': 'google',
        'icon': 'fa-google',
        'token_key': 'access_token',
        'remote_app': {
            'client_id': 'YOUR_CLIENT_ID',
            'client_secret': 'YOUR_CLIENT_SECRET',
            'api_base_url': 'https://www.googleapis.com/oauth2/v2/',
            'client_kwargs': {
                'scope': 'email profile'
            },
            'request_token_url': None,
            'access_token_url': 'https://accounts.google.com/o/oauth2/token',
            'authorize_url': 'https://accounts.google.com/o/oauth2/auth',
            'request_token_params': None
        }
    }
]

После перезапуска Superset на странице входа появится кнопка «Sign in with Google». Пользователи смогут входить, используя корпоративные аккаунты Google Workspace.

Подключение к внешним базам данных

Superset не хранит анализируемые данные - он подключается к существующим СУБД и выполняет запросы на лету. Для каждого типа базы данных требуется соответствующий Python-драйвер.

Установка драйверов баз данных в Docker-образ

Официальный образ Superset включает драйверы для SQLite и базовые коннекторы. Для промышленных СУБД их нужно добавить. Расширьте Dockerfile:

FROM apache/superset:latest
USER root
RUN pip install psycopg2-binary mysqlclient pymssql clickhouse-driver
USER superset

psycopg2-binary - драйвер для PostgreSQL. mysqlclient - для MySQL и MariaDB. pymssql - для Microsoft SQL Server. clickhouse-driver - для ClickHouse. Соберите образ и обновите ссылку на него в docker-compose.yml.

Формирование строк подключения (SQLAlchemy URI)

Superset использует SQLAlchemy для взаимодействия с базами данных. Строка подключения имеет формат dialect+driver://user:password@host:port/database.

Примеры для популярных СУБД:

PostgreSQL: postgresql+psycopg2://user:password@host:5432/dbname
MySQL: mysql+mysqlconnector://user:password@host:3306/dbname
MS SQL Server: mssql+pymssql://user:password@host:1433/dbname
ClickHouse: clickhouse+native://user:password@host:9000/dbname

Специальные символы в пароле необходимо экранировать через URL-кодирование. Например, символ @ заменяется на %40, # на %23, пробел на %20. Если пароль содержит сложные символы, используйте функцию urllib.parse.quote_plus() в Python для кодирования всей строки пароля.

Для PostgreSQL с обязательным SSL-соединением добавьте параметр в строку: postgresql+psycopg2://user:password@host:5432/dbname?sslmode=require. Для MySQL с указанием кодировки: mysql+mysqlconnector://user:password@host:3306/dbname?charset=utf8mb4.

Проверка подключения выполняется в веб-интерфейсе: перейдите в Data → Databases → + Database, вставьте SQLAlchemy URI и нажмите «Test Connection». Superset попытается установить соединение и вернет сообщение об успехе или ошибке с деталями.

Базовая безопасность и управление доступом

Защита BI-платформы начинается с трех шагов: смена секретных ключей, настройка ролевой модели и сетевая изоляция. Первый шаг мы выполнили при подготовке docker-compose.yml. Перейдем к остальным.

Настройка ролевой модели (RBAC)

Superset поставляется с четырьмя предопределенными ролями. Admin имеет полный доступ ко всем функциям и данным. Alpha может создавать и редактировать датасеты, чарты и дашборды, но не управляет пользователями и правами. Gamma имеет доступ только к явно разрешенным датасетам и дашбордам. Public - минимальный доступ для неаутентифицированных пользователей.

Для тонкой настройки создайте кастомные роли через веб-интерфейс: List Roles → + (добавить роль). Назначьте права на конкретные датасеты, дашборды и действия. Например, роль «Региональный менеджер» может видеть только дашборды своего региона и не имеет доступа к SQL Lab.

При интеграции с LDAP настройте автоматическое назначение ролей через AUTH_ROLES_MAPPING. При использовании OAuth определите AUTH_ROLES_SYNC_AT_LOGIN = True, чтобы роли обновлялись при каждом входе.

Сетевая изоляция контейнеров

В docker-compose.yml определите отдельные сети для разных групп сервисов. База данных и Redis не должны быть доступны извне:

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true

services:
  superset:
    networks:
      - frontend
      - backend
  db:
    networks:
      - backend
  redis:
    networks:
      - backend

Директива internal: true запрещает контейнерам в сети backend доступ к внешней сети и наоборот. Только сервис superset подключен к обеим сетям и может маршрутизировать запросы. Порты базы данных и Redis не публикуются на хост-машину - они доступны исключительно внутри Docker-окружения.

Диагностика и решение типовых проблем

Ошибки подключения к базе данных - самая частая проблема при добавлении источников. Проверьте три вещи: сетевую доступность хоста из контейнера Superset (docker compose exec superset ping db-host), корректность учетных данных и наличие драйвера. Сообщение «No module named ...» в логах указывает на отсутствующий pip-пакет - добавьте его в Dockerfile и пересоберите образ.

Проблемы с LDAP-аутентификацией проявляются как ошибка «Invalid login» даже при правильных учетных данных. Включите детальное логирование, добавив в superset_config.py:

import logging
logging.getLogger('flask_appbuilder.security.ldap').setLevel(logging.DEBUG)

Логи покажут, на каком этапе происходит сбой: поиск пользователя, бинд или маппинг полей. Частая причина - несовпадение атрибутов: в Active Directory используется sAMAccountName, а в конфигурации указан uid.

Сброс пароля администратора выполняется через CLI, если доступ к веб-интерфейсу потерян:

docker compose exec superset superset fab reset-password --username admin --password newpassword

Ошибки загрузки дашбордов с таймаутами указывают на нехватку ресурсов. Увеличьте таймаут выполнения запросов в superset_config.py: SUPERSET_WEBSERVER_TIMEOUT = 300. Если проблема сохраняется - проверьте лимиты памяти контейнера и при необходимости увеличьте их в docker-compose.yml через директиву mem_limit.

Для углубленного изучения Docker и контейнеризации обратитесь к руководству по Docker для системных администраторов, где разобраны шаблоны docker-compose.yml для production-сервисов. При настройке безопасного доступа к базам данных пригодится гайд по веб-доступу к СУБД с готовыми конфигурациями SSH-туннелей и ролевых моделей. Если вы планируете масштабировать развертывание, изучите production-гайд по Docker с настройкой мониторинга и логирования.

Для размещения Superset и сопутствующих сервисов требуется надежная облачная инфраструктура. Timeweb Cloud предоставляет VDS с гибким масштабированием ресурсов и готовыми шаблонами Docker - вы можете развернуть описанную конфигурацию за считанные минуты.