Розгортання Apache Superset на VPS: Docker, PostgreSQL, Redis, SSL і підключення баз даних

Що ми налаштовуємо і навіщо

Apache Superset — open-source BI-платформа для роботи з даними. Через веб-інтерфейс вона дає змогу підключати PostgreSQL, MySQL, ClickHouse, Microsoft SQL Server, Trino, BigQuery, Snowflake, DuckDB і десятки інших джерел через SQLAlchemy-драйвери. Користувач створює набори даних, SQL-запити, графіки, таблиці, KPI-картки та інтерактивні дашборди.

У цьому посібнику буде розгорнуто production-стек Apache Superset на Ubuntu Server 24.04 LTS. Superset запускається у Docker Compose, метадані зберігаються в PostgreSQL 16, Redis 7 використовується для черг і кешування, а Caddy приймає HTTPS-трафік на портах 80 і 443. Веб-контейнер Superset не публікується безпосередньо в інтернет: назовні доступний лише reverse proxy.

Архітектура підходить для невеликої команди, стартапу, внутрішньої аналітики SaaS-продукту, агентства або відділу до кількох десятків активних користувачів. Вона також зручна для персонального аналітичного середовища: наприклад, коли дані застосунку зберігаються в PostgreSQL, події збираються в ClickHouse, а звіти потрібно надавати менеджерам без прямого доступу до баз.

Що вийде після налаштування

Після виконання кроків у вас буде URL вигляду https://superset.example.com, захищений чинним сертифікатом TLS. Адміністратор зможе створювати користувачів, призначати їм ролі Gamma, Alpha або кастомні ролі, реєструвати зовнішні бази даних і будувати дашборди. Результати тривалих запитів зможуть виконуватися через Celery, не блокуючи веб-процес.

PostgreSQL у цій схемі не є базою для бізнес-даних. Він зберігає саме службовий стан Superset. Якщо видалити його volume без резервної копії, зникнуть облікові записи, підключення до даних, SQL-запити, дашборди, теги та налаштування. Тому PostgreSQL потрібно регулярно резервувати окремо від образів Docker.

Self-hosted Superset і managed BI

Cloud-managed сервіси BI запускаються швидше: зазвичай достатньо підключити сховище даних і запросити співробітників. Натомість організація передає провайдеру метадані, SQL-запити, структуру таблиць, іноді результати аналітики та дані користувачів. Крім того, вартість часто залежить від кількості редакторів або переглядів.

Self-hosted Apache Superset на VPS потребує самостійного адміністрування, оновлень і резервного копіювання. Натомість ви контролюєте мережеву топологію, версії, логи, ролі, домен і місце зберігання даних. Це особливо корисно, якщо база доступна лише у внутрішній мережі, діють вимоги щодо локалізації даних або аналітика має працювати без залежності від зовнішнього SaaS.

Superset зазвичай не копіює дані в PostgreSQL метаданих. Він підключається до вихідної БД і виконує SQL-запити від імені окремого технічного користувача. Однак SQL Lab і кеш можуть зберігати результати протягом обмеженого часу, тому права та строк зберігання кешу потрібно планувати заздалегідь.

Яка VPS-конфігурація потрібна для цього завдання

Навантаження Superset залежить не лише від кількості користувачів. Істотнішими є кількість одночасних SQL-запитів, обсяг результатів, складність графіків, використання звітів за розкладом і розташування аналітичної бази. Сам Superset не повинен виконувати важку агрегацію замість ClickHouse, PostgreSQL або warehouse: обчислення потрібно переносити у вихідну БД, вітрини або materialized views.

Для першого production-розгортання практичний мінімум — 4 vCPU, 8 ГБ RAM, 100 ГБ NVMe та канал від 100 Мбіт/с. На такому сервері нормально працюють Superset, PostgreSQL, Redis, Caddy і один або два Celery worker-процеси. Залишайте щонайменше 20–30% вільного диска для PostgreSQL WAL, Docker-шарів, логів і бекапів перед вивантаженням у зовнішнє сховище.

Наприклад, можна взяти VPS із зазначеними характеристиками, встановити Ubuntu 24.04 LTS і призначити статичний публічний IPv4. Під час вибору перевірте, що провайдер не блокує вхідні порти 80 і 443: вони потрібні Caddy для HTTP-перевірки домену та HTTPS.

Коли потрібен dedicated, а не VPS

Виділений сервер має сенс, якщо Superset обслуговує велику кількість одночасних користувачів, на тому ж хості запускаються важкі ClickHouse або PostgreSQL-аналітика, потрібні 32–128 ГБ RAM, передбачувані IOPS або сувора ізоляція ресурсів. Dedicated також є кращим вибором за вимог комплаєнсу, коли не можна розміщувати виробничі дані на віртуалізованій інфраструктурі.

Якщо ж Superset підключається до окремого managed PostgreSQL, ClickHouse Cloud, BigQuery або віддаленого warehouse, власний сервер Superset зазвичай не потребує потужного CPU. У цьому разі найчастіше достатньо VPS із 4–8 vCPU та 8–16 ГБ RAM. Збільшувати ресурси слід після спостереження за RAM, чергою Celery, часом відповіді та навантаженням вихідної бази.

Вибір локації

Локація впливає на затримку між Superset і джерелами даних. Якщо PostgreSQL або ClickHouse розміщені в європейському дата-центрі, розміщуйте VPS Superset у тому самому регіоні або хоча б у тій самій країні. Затримка 2–10 мс майже не впливає на звичайні запити, але 80–150 мс помітно сповільнює інтерактивні фільтри та дашборди з десятками віджетів.

Якщо Superset доступний співробітникам з однієї країни, обирайте найближчу локацію. Якщо доступ обмежений корпоративною VPN, корисніше розмістити сервер поруч із private network або VPN-шлюзом. Не відкривайте PostgreSQL-джерело в інтернет заради підключення Superset: краще використовувати приватну мережу, WireGuard-тунель, SSH-tunnel або дозвіл конкретної IP-адреси VPS.

Підготовка сервера

Інструкція розрахована на чисту Ubuntu Server 24.04 LTS з доступом через SSH під користувачем root. Перед початком створіть DNS-запис типу A: superset.example.com має вказувати на публічний IPv4 сервера. Caddy не зможе випустити сертифікат, доки DNS не пошириться, а порти 80/443 не будуть доступні ззовні.

Створення адміністратора та оновлення ОС

Не запускайте Docker-стек постійно від root. Створіть окремого користувача, додайте його до груп sudo і docker, а потім використовуйте його для подальших дій.

apt update && apt upgrade -y
apt install -y sudo curl wget ca-certificates gnupg lsb-release \
  ufw fail2ban unattended-upgrades jq nano git
adduser deploy
usermod -aG sudo deploy

Команда встановлює оновлення безпеки, базові утиліти, firewall і fail2ban, а потім створює користувача deploy. Пароль користувача знадобиться лише як резервний варіант: основним способом доступу мають бути SSH-ключі.

Налаштування SSH-ключа

На локальному комп’ютері створіть ключ, якщо його ще немає. Для нового ключа використовуйте Ed25519 і задайте passphrase. Потім скопіюйте публічну частину на сервер.

ssh-keygen -t ed25519 -a 100 -C "[email protected]"
ssh-copy-id deploy@SERVER_IP
ssh deploy@SERVER_IP

Перевірте, що вхід користувачем deploy працює в окремому терміналі. Лише після цієї перевірки вимикайте вхід root і парольну автентифікацію. Не закривайте поточну root-сесію, доки не підтвердите доступ за ключем.

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

Створіть файл із таким вмістом.

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
AllowUsers deploy

Перевірте конфігурацію та перезапустіть SSH-службу.

sudo sshd -t && sudo systemctl restart ssh

Firewall і fail2ban

Зовнішньому інтернету потрібні лише SSH, HTTP і HTTPS. Не відкривайте порт Superset 8088, Redis 6379 і PostgreSQL 5432: між контейнерами вони працюють у внутрішній Docker-мережі.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

В ідеалі обмежте SSH конкретним офісним IP або VPN-підмережею. Якщо IP динамічний, залиште OpenSSH відкритим, але використовуйте лише ключі та fail2ban.

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
sudo systemctl enable --now unattended-upgrades

Fail2ban блокує IP після повторюваних невдалих спроб входу. Автоматичні оновлення Ubuntu встановлюють security-патчі, але Docker-образи Superset, PostgreSQL і Redis однаково потрібно оновлювати вручну за контрольованим розкладом.

Перевірка ресурсів перед встановленням

free -h
df -h /
nproc
curl -4 ifconfig.me

Переконайтеся, що доступно щонайменше 7 ГБ оперативної пам’яті для рекомендованого сценарію, на диску є щонайменше 70 ГБ вільного місця, а команда curl повертає очікуваний публічний IP. Якщо RAM рівно 4 ГБ, створіть swap 2–4 ГБ: він не замінює пам’ять, але може запобігти аварійному завершенню процесу під час короткочасного піку.

Встановлення ПЗ — покроково

Нижче використовуються Docker Engine і Docker Compose Plugin з офіційного репозиторію Docker. На 2026 рік орієнтуйтеся на актуальну стабільну гілку Docker Engine 27/28 і Compose v2; точні версії можна побачити після встановлення. Для Superset у прикладі закріплено образ apache/superset:5.0.0. Перед production-оновленням перевірте сторінку релізів Apache Superset і changelog вибраного тега.

Встановлення Docker Engine

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

Команди додають офіційний GPG-ключ Docker до системного сховища ключів APT.

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update

Цей блок додає офіційний репозиторій Docker для Ubuntu 24.04.

sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker deploy
newgrp docker
docker version
docker compose version

Після додавання до групи docker увійдіть повторно через SSH або виконайте newgrp docker. Членство в цій групі фактично надає root-повноваження на хості, тому додавайте до неї лише довірених адміністраторів.

Створення структури проєкту

Розмістимо конфігурацію в /opt/superset. Каталог міститиме Compose-файл, змінні середовища, конфігурацію застосунку, Caddyfile і скрипти обслуговування. Docker volumes керуватимуться Docker окремо.

sudo mkdir -p /opt/superset/{config,caddy,data,backups,scripts}
sudo chown -R deploy:deploy /opt/superset
cd /opt/superset
umask 077
openssl rand -base64 48
openssl rand -hex 24

Останні дві команди генерують секрети. Перший довгий випадковий ключ збережіть як SUPERSET_SECRET_KEY, другий використовуйте як пароль PostgreSQL. Не вставляйте ці значення в Git, тікети, скриншоти або спільний чат.

Створення файлу змінних

cd /opt/superset
nano .env
chmod 600 .env

Файл .env буде прочитаний Docker Compose, але не повинен бути доступним іншим користувачам системи.

SUPERSET_TAG=5.0.0
SUPERSET_SECRET_KEY=PASTE_A_LONG_RANDOM_BASE64_SECRET_HERE
POSTGRES_DB=superset
POSTGRES_USER=superset
POSTGRES_PASSWORD=PASTE_A_LONG_RANDOM_PASSWORD_HERE
POSTGRES_HOST=db
POSTGRES_PORT=5432
REDIS_HOST=redis
REDIS_PORT=6379
SUPERSET_DOMAIN=superset.example.com
[email protected]
TZ=Europe/Moscow

Замініть домен, email, часовий пояс і обидва секрети. Ключ Superset не можна змінювати після запуску без спеціальної процедури ротації: зашифровані значення, наприклад паролі підключень до БД, перестануть розшифровуватися.

Збирання кастомного образу з драйверами

Базовий образ Superset не зобов’язаний містити всі драйвери потрібних джерел. Для PostgreSQL, MySQL і ClickHouse створимо невеликий похідний образ. Якщо драйвер не потрібен, його можна видалити з файлу.

nano Dockerfile
nano requirements-local.txt

ARG SUPERSET_TAG=5.0.0
FROM apache/superset:${SUPERSET_TAG}

USER root
COPY requirements-local.txt /tmp/requirements-local.txt
RUN pip install --no-cache-dir -r /tmp/requirements-local.txt
USER superset

psycopg2-binary==2.9.10
pymysql==1.1.1
clickhouse-connect==0.8.15
trino==0.333.0
duckdb-engine==0.13.4

Тут додано драйвери для найпоширеніших джерел. Не встановлюйте пакети без потреби: кожен драйвер розширює поверхню оновлень. Для Microsoft SQL Server може знадобитися окремий драйвер pymssql або pyodbc і системні бібліотеки.

Створення конфігурації Superset

nano config/superset_config.py

У наступному розділі буде наведено повний вміст цього файлу. Після його створення створіть Compose-опис.

nano compose.yaml

Compose-файл запускає шість сервісів: PostgreSQL, Redis, Superset web, Celery worker, Celery beat і Caddy. Команда docker compose up -d --build збере локальний образ і створить внутрішню мережу.

docker compose config
docker compose build
docker compose up -d
docker compose ps

Команда docker compose config спочатку перевіряє синтаксис і підстановку змінних. Не переходьте до ініціалізації, доки всі контейнери не отримають стан running або не стане зрозуміла причина помилки через логи.

docker compose logs --tail=100 db
docker compose logs --tail=100 superset
docker compose logs --tail=100 worker

Перегляд логів одразу після першого запуску допомагає виявити неправильний пароль PostgreSQL, зайнятий порт, помилку Python-драйвера або нестачу пам’яті до налаштування домену та HTTPS.

Конфігурація Superset, PostgreSQL, Redis і SSL

Конфігурація застосунку Superset

Файл config/superset_config.py передається в контейнер як /app/pythonpath/superset_config.py. Він задає URI метаданих, Redis-кеш, Celery, проксі-заголовки та обмеження завантаження. Секрети беруться лише з environment variables.

import os
from cachelib.redis import RedisCache

SECRET_KEY = os.environ["SUPERSET_SECRET_KEY"]

SQLALCHEMY_DATABASE_URI = (
    f"postgresql+psycopg2://{os.environ['POSTGRES_USER']}:"
    f"{os.environ['POSTGRES_PASSWORD']}@"
    f"{os.environ['POSTGRES_HOST']}:"
    f"{os.environ['POSTGRES_PORT']}/{os.environ['POSTGRES_DB']}"
)

REDIS_HOST = os.environ.get("REDIS_HOST", "redis")
REDIS_PORT = int(os.environ.get("REDIS_PORT", "6379"))
REDIS_URL = f"redis://{REDIS_HOST}:{REDIS_PORT}/0"

CACHE_CONFIG = {
    "CACHE_TYPE": "RedisCache",
    "CACHE_DEFAULT_TIMEOUT": 300,
    "CACHE_KEY_PREFIX": "superset_cache_",
    "CACHE_REDIS_HOST": REDIS_HOST,
    "CACHE_REDIS_PORT": REDIS_PORT,
    "CACHE_REDIS_DB": 1,
}
DATA_CACHE_CONFIG = CACHE_CONFIG

class CeleryConfig:
    broker_url = REDIS_URL
    result_backend = "redis://redis:6379/2"
    imports = (
        "superset.sql_lab",
        "superset.tasks",
        "superset.tasks.thumbnails",
        "superset.tasks.reports",
    )
    worker_prefetch_multiplier = 1
    task_acks_late = True
    beat_schedule = {}

CELERY_CONFIG = CeleryConfig

FEATURE_FLAGS = {
    "ALERT_REPORTS": True,
    "THUMBNAILS": True,
    "DASHBOARD_RBAC": True,
}

ENABLE_PROXY_FIX = True
WTF_CSRF_ENABLED = True
WTF_CSRF_EXEMPT_LIST = []
SESSION_COOKIE_SECURE = True
SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_SAMESITE = "Lax"
PREFERRED_URL_SCHEME = "https"

SUPERSET_WEBSERVER_TIMEOUT = 120
SQLLAB_TIMEOUT = 300
ROW_LIMIT = 100000
VIZ_ROW_LIMIT = 100000
UPLOAD_FOLDER = "/app/superset_home/uploads"
MAX_CONTENT_LENGTH = 50  1024  1024

TALISMAN_ENABLED = False

Параметр ENABLE_PROXY_FIX необхідний, щоб Superset правильно визначав HTTPS за Caddy і не генерував небезпечні посилання. Значення TALISMAN_ENABLED = False спрощує початковий запуск: під час подальшого посилення CSP налаштуйте заголовки свідомо, оскільки сувора Content Security Policy може блокувати візуалізації та плагіни.

Compose-файл

Збережіть наступний файл як /opt/superset/compose.yaml. Порти PostgreSQL, Redis і Superset не опубліковані на хості. Єдиний опублікований сервіс — Caddy.

services:
  db:
    image: postgres:16.8
    container_name: superset-db
    restart: unless-stopped
    env_file: .env
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      TZ: ${TZ}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB"]
      interval: 10s
      timeout: 5s
      retries: 10
    networks:
      - superset_internal

  redis:
    image: redis:7.4-alpine
    container_name: superset-redis
    restart: unless-stopped
    command: ["redis-server", "--appendonly", "yes", "--save", "60", "1000"]
    volumes:
      - redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 10
    networks:
      - superset_internal

  superset:
    build:
      context: .
      args:
        SUPERSET_TAG: ${SUPERSET_TAG}
    image: local/superset:${SUPERSET_TAG}
    container_name: superset-web
    restart: unless-stopped
    env_file: .env
    environment:
      SUPERSET_CONFIG_PATH: /app/pythonpath/superset_config.py
      PYTHONPATH: /app/pythonpath
      TZ: ${TZ}
    command: ["/usr/bin/run-server.sh"]
    volumes:
      - ./config/superset_config.py:/app/pythonpath/superset_config.py:ro
      - superset_home:/app/superset_home
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    expose:
      - "8088"
    networks:
      - superset_internal

  worker:
    image: local/superset:${SUPERSET_TAG}
    container_name: superset-worker
    restart: unless-stopped
    env_file: .env
    environment:
      SUPERSET_CONFIG_PATH: /app/pythonpath/superset_config.py
      PYTHONPATH: /app/pythonpath
      TZ: ${TZ}
    command: ["celery", "--app=superset.tasks.celery_app:app", "worker", "-O", "fair", "-l", "INFO", "-c", "2"]
    volumes:
      - ./config/superset_config.py:/app/pythonpath/superset_config.py:ro
      - superset_home:/app/superset_home
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    networks:
      - superset_internal

  beat:
    image: local/superset:${SUPERSET_TAG}
    container_name: superset-beat
    restart: unless-stopped
    env_file: .env
    environment:
      SUPERSET_CONFIG_PATH: /app/pythonpath/superset_config.py
      PYTHONPATH: /app/pythonpath
      TZ: ${TZ}
    command: ["celery", "--app=superset.tasks.celery_app:app", "beat", "-l", "INFO"]
    volumes:
      - ./config/superset_config.py:/app/pythonpath/superset_config.py:ro
      - superset_home:/app/superset_home
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    networks:
      - superset_internal

  caddy:
    image: caddy:2.8-alpine
    container_name: superset-caddy
    restart: unless-stopped
    env_file: .env
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - superset
    networks:
      - superset_internal

networks:
  superset_internal:
    name: superset_internal

volumes:
  postgres_data:
  redis_data:
  superset_home:
  caddy_data:
  caddy_config:

Redis persistence увімкнено через AOF. Для кешу це не критично, але допомагає зберегти частину стану черг після короткого перезапуску. Джерелом істини залишається PostgreSQL. Для контейнера worker задано конкурентність -c 2; на сервері з 8 ГБ RAM не збільшуйте її без спостереження за пам’яттю.

Caddy і автоматичний TLS

Створіть файл /opt/superset/caddy/Caddyfile. Caddy отримає сертифікат Let’s Encrypt автоматично, якщо DNS уже вказує на сервер і порти 80/443 вільні.

nano /opt/superset/caddy/Caddyfile

{
    email {$LETSENCRYPT_EMAIL}
    auto_https on
}

{$SUPERSET_DOMAIN} {
    encode zstd gzip

    reverse_proxy superset:8088 {
        header_up Host {host}
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "SAMEORIGIN"
        Referrer-Policy "strict-origin-when-cross-origin"
        -Server
    }

    log {
        output stdout
        format console
    }
}

Після збереження файлів зберіть і запустіть стек. Перший запуск потребує окремої ініціалізації схеми та створення адміністратора.

cd /opt/superset
docker compose up -d --build
docker compose exec superset superset db upgrade
docker compose exec superset superset fab create-admin \
  --username admin \
  --firstname Superset \
  --lastname Admin \
  --email [email protected] \
  --password 'CHANGE_THIS_PASSWORD_NOW'
docker compose exec superset superset init
docker compose restart superset worker beat caddy

Команда superset db upgrade застосовує міграції metadata database. create-admin створює локального адміністратора, а superset init створює ролі та базові дозволи. Одразу після входу змініть тимчасовий пароль на унікальний пароль із менеджера паролів.

Перевірка працездатності

docker compose ps
docker compose exec db pg_isready -U superset -d superset
docker compose exec redis redis-cli ping
curl -I http://127.0.0.1
curl -I https://superset.example.com
docker compose logs --tail=100 caddy

Очікувана відповідь Redis — PONG. Запит до HTTPS має повернути HTTP/2 200 або HTTP/2 302 на сторінку входу. Якщо Caddy повертає помилку сертифіката, спочатку перевірте DNS, firewall і логи docker compose logs caddy.

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

Створюйте в кожній аналітичній БД окремого технічного користувача лише для читання. Не використовуйте root, postgres, sa або власника схеми. Для Superset зазвичай достатньо прав CONNECT, USAGE на потрібні схеми та SELECT на таблиці або views.

Приклад для PostgreSQL-джерела. Виконайте його на сервері бази даних, замінивши назву БД, схему та пароль.

CREATE ROLE superset_reader LOGIN PASSWORD 'LONG_UNIQUE_PASSWORD';
GRANT CONNECT ON DATABASE appdb TO superset_reader;
GRANT USAGE ON SCHEMA analytics TO superset_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO superset_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA analytics
GRANT SELECT ON TABLES TO superset_reader;

В інтерфейсі Superset відкрийте Settings → Database Connections → + Database. Для PostgreSQL URI матиме такий вигляд:

postgresql+psycopg2://superset_reader:[email protected]:5432/appdb

Якщо пароль містить символи @, :, / або #, URL-кодуйте його. Наприклад, @ перетворюється на %40. У налаштуваннях підключення увімкніть Expose in SQL Lab, якщо користувачам потрібен SQL Lab, і вимкніть Allow DML, якщо редагування даних не потрібне.

Для ClickHouse з драйвером clickhouse-connect використовуйте URI такого вигляду:

clickhousedb://superset_reader:[email protected]:8123/analytics

Під час підключення через публічну мережу вмикайте TLS на стороні джерела, використовуйте private networking або WireGuard. Не зберігайте production-паролі в описах дашбордів, SQL-коментарях і змінних, які можуть потрапити до експорту.

Бекапи та обслуговування

Мінімальний бекап Superset має включати PostgreSQL metadata database, файл .env, compose.yaml, config/superset_config.py, Caddyfile та за потреби Docker volume superset_home. Найважливішим є дамп PostgreSQL: у ньому містяться всі об'єкти інтерфейсу та зашифровані дані підключень.

Не вважайте Docker volume резервною копією. Volume розташований на тому самому диску, що й сервер, і не захистить від видалення VPS, помилки адміністратора, збою файлової системи або ransomware. Дотримуйтеся правила 3-2-1: щонайменше три копії, на двох типах носіїв, одна копія поза основним сервером.

Скрипт резервного копіювання PostgreSQL

Нижче скрипт створює стиснений дамп, копіює конфігурацію, а потім може передати архів до S3-сумісного сховища через restic. Restic шифрує дані на клієнті; пароль репозиторію зберігайте окремо в менеджері секретів.

sudo apt install -y restic
mkdir -p /opt/superset/backups
nano /opt/superset/scripts/backup.sh
chmod 700 /opt/superset/scripts/backup.sh

#!/usr/bin/env bash
set -euo pipefail

BASE_DIR="/opt/superset"
DATE="$(date +%F_%H-%M-%S)"
BACKUP_DIR="${BASE_DIR}/backups/${DATE}"

mkdir -p "${BACKUP_DIR}"

cd "${BASE_DIR}"

docker compose exec -T db pg_dump \
  -U "${POSTGRES_USER}" \
  -d "${POSTGRES_DB}" \
  --format=custom \
  --no-owner \
  --no-privileges \
  > "${BACKUP_DIR}/superset_metadata.dump"

tar -czf "${BACKUP_DIR}/config.tar.gz" \
  .env compose.yaml Dockerfile requirements-local.txt \
  config/superset_config.py caddy/Caddyfile

docker run --rm \
  -v superset_superset_home:/source:ro \
  -v "${BACKUP_DIR}:/backup" \
  alpine:3.20 \
  tar -czf /backup/superset_home.tar.gz -C /source .

find "${BASE_DIR}/backups" -mindepth 1 -maxdepth 1 -type d -mtime +3 -exec rm -rf {} \;

export RESTIC_REPOSITORY="s3:s3.amazonaws.com/YOUR_BUCKET/superset"
export RESTIC_PASSWORD_FILE="/root/.config/restic/superset-password"
export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY"

restic backup "${BACKUP_DIR}"
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Перед використанням замініть S3 endpoint, bucket та облікові дані. Не записуйте AWS_SECRET_ACCESS_KEY безпосередньо в скрипт: краще розмістіть змінні у доступному root файлі /root/.config/restic/superset-env з правами 600 та підключайте його через source.

Розклад cron і перевірка відновлення

sudo crontab -e

30 2   * /opt/superset/scripts/backup.sh >> /var/log/superset-backup.log 2>&1

Бекап запускатиметься щодня о 02:30. Не обмежуйтеся повідомленням про успішне виконання: раз на квартал запускайте тестовий контейнер PostgreSQL і відновлюйте дамп. Лише успішне відновлення підтверджує, що резервна копія справді придатна.

docker compose exec -T db pg_restore \
  -U superset \
  -d superset \
  --clean --if-exists \
  < /path/to/superset_metadata.dump

Команду відновлення не можна запускати на робочому production без вікна обслуговування: вона видалить і заново створить об'єкти metadata database. Перевіряйте відновлення в окремому тестовому стеку або тимчасовій базі.

Оновлення Superset і контейнерів

Для одного VPS використовуйте maintenance window. Rolling update без простою потребує щонайменше двох екземплярів Superset за балансувальником, сумісності міграцій та окремої стратегії Celery. Для невеликої інсталяції безпечніше повідомити про коротке вікно обслуговування, зробити бекап, оновити один компонент і виконати smoke-test.

cd /opt/superset
./scripts/backup.sh
docker compose pull
docker compose build --pull
docker compose up -d
docker compose exec superset superset db upgrade
docker compose exec superset superset init
docker compose logs --tail=100 superset
docker compose ps

Не використовуйте тег latest для Superset у production: він може принести несумісну зміну без явного рішення адміністратора. Змінюйте SUPERSET_TAG у .env на конкретну протестовану версію, вивчайте release notes та спочатку повторюйте оновлення у staging-середовищі.

Спостереження за станом

Щонайменше раз на тиждень перевіряйте вільний простір на диску, перезапуски контейнерів, розмір PostgreSQL та логи помилок. Диск, заповнений логами або PostgreSQL WAL, може призвести до повної зупинки бази даних.

cd /opt/superset
docker compose ps
docker stats --no-stream
docker system df
df -h
docker compose exec db psql -U superset -d superset -c \
  "SELECT pg_size_pretty(pg_database_size('superset'));"
docker compose logs --since=24h superset | grep -iE "error|exception|traceback"

Не запускайте бездумно docker system prune -a на production-сервері: команда видаляє невикористовувані образи та може ускладнити швидкий відкат. Використовуйте контрольоване очищення після підтвердження, що старі образи справді не потрібні.

Troubleshooting та FAQ

Чому Caddy не випускає TLS-сертифікат і в логах є ACME error?

Спочатку переконайтеся, що A-запис домену вказує на IP VPS: dig +short superset.example.com має повернути адресу сервера. Потім перевірте, що UFW дозволяє 80 і 443, а інший вебсервер не займає ці порти: sudo ss -ltnp | grep -E ':80|:443'. Також вимкніть проксіювання DNS через CDN на час першого випуску сертифіката або налаштуйте DNS challenge. Перегляньте точну причину командою docker compose logs caddy.

Superset показує 500 Internal Server Error після запуску. Що перевірити?

Почніть із логів: docker compose logs --tail=200 superset. Часті причини — неправильний POSTGRES_PASSWORD, незастосовані міграції, відсутність SUPERSET_SECRET_KEY або синтаксична помилка в superset_config.py. Перевірте доступність бази через docker compose exec db pg_isready -U superset -d superset, потім повторіть docker compose exec superset superset db upgrade і docker compose exec superset superset init. Не змінюйте SECRET_KEY на вже робочій інсталяції.

Чому контейнер worker постійно перезапускається?

Перегляньте логи worker і Redis: docker compose logs --tail=200 worker redis. Зазвичай проблема спричинена неправильним Redis URL, відсутністю Python-модуля, помилкою в конфігурації Celery або нестачею пам'яті. Перевірте docker stats --no-stream і системний журнал dmesg -T | grep -i oom. Якщо ядро завершило процес через OOM killer, зменште worker concurrency до -c 1, додайте RAM або винесіть worker на окремий сервер.

Підключення до PostgreSQL-джерела не працює, хоча URI виглядає правильно. Як діагностувати?

Перевірте мережеву доступність із контейнера Superset, а не з локального комп'ютера: docker compose exec superset python -c "import socket; print(socket.gethostbyname('db-host'))". Переконайтеся, що firewall джерела дозволяє IP VPS або приватну підмережу, а в pg_hba.conf є відповідне правило. Потім перевірте користувача безпосередньо через psql. Для зовнішнього PostgreSQL потрібен окремий read-only користувач і дозвіл CONNECT, USAGE та SELECT.

Чому дашборд працює повільно, хоча VPS майже не завантажений?

Superset часто очікує відповідь від зовнішньої БД, тому низьке навантаження VPS не означає нормальну продуктивність. Відкрийте SQL Lab, скопіюйте згенерований запит і виконайте EXPLAIN ANALYZE на стороні джерела. Додайте індекси, створіть агреговану вітрину, materialized view або таблицю з попереднім обчисленням. Зменште кількість графіків на одній сторінці, налаштуйте cache timeout і не виводьте сотні тисяч рядків у таблицях браузера.

Яка VPS-конфігурація мінімально підійде?

Для тесту достатньо 2 vCPU, 4 ГБ RAM і 40–60 ГБ NVMe, але це компроміс: під час запуску PostgreSQL, Redis, Superset і Celery пам'ять швидко закінчується. Для реальної невеликої команди використовуйте щонайменше 4 vCPU, 8 ГБ RAM і 80–120 ГБ NVMe. Якщо джерела даних зовнішні й запити помірні, цього достатньо для 5–30 активних користувачів. За регулярних звітів і кількох worker плануйте 16 ГБ RAM.

Що вибрати — VPS чи dedicated для цього завдання?

VPS підходить майже для всіх невеликих і середніх інсталяцій Superset, особливо коли аналітичні дані розташовані в окремій базі, warehouse або managed-сервісі. Dedicated потрібен за високих вимог до CPU, RAM, IOPS та ізоляції: наприклад, якщо на одному хості працюють Superset, ClickHouse і PostgreSQL з великими наборами даних. Не переносьте важку аналітичну БД на dedicated лише тому, що Superset став повільним: спочатку профілюйте реальні SQL-запити.

Чи можна відкрити Superset напряму на порту 8088?

Технічно можна, але для production це погана практика. Прямий доступ позбавляє вас автоматичного TLS, централізованих HTTP-заголовків, нормальної обробки сертифікатів і зручного обмеження трафіку на reverse proxy. У Compose-файлі порт 8088 навмисно не публікується. Залиште доступ лише всередині Docker-мережі та спрямовуйте зовнішній трафік через Caddy. Якщо потрібен тимчасовий локальний тест, використовуйте SSH port forwarding замість відкриття порту всьому інтернету.

Висновки та наступні кроки

Тепер Apache Superset працює на VPS в ізольованому Docker-стеку з PostgreSQL, Redis, Celery та HTTPS через Caddy. Метадані відокремлені від аналітичних джерел, доступ захищений TLS, а резервне копіювання PostgreSQL можна виконувати автоматично.

1. Створіть read-only технічних користувачів для кожної підключеної БД та обмежте їм доступ лише до потрібних схем і views.
2. Налаштуйте ролі Superset, вимкніть зайві дозволи SQL Lab і протестуйте доступ звичайного користувача, а не лише адміністратора.
3. У разі зростання навантаження винесіть PostgreSQL metadata database до managed PostgreSQL, додайте окремі Celery worker і налаштуйте моніторинг через Prometheus, Grafana або зовнішній uptime-check.

Перед великим оновленням версії обов'язково перевіряйте міграції та відновлення бекапу на тестовому сервері. Для стабільної аналітики важливіші контрольовані зміни та права доступу до даних, ніж максимальна кількість встановлених компонентів.