Redash в Docker Compose: готовый файл

MAATRIX

Аналитик написал SQL-запрос, получил цифры — и вот они уже потерялись в личном чате, а через неделю кто-то в третий раз пересчитывает то же самое вручную. Redash решает эту проблему: подключаете источники данных, сохраняете запросы, собираете из них дашборды и раздаёте команде ссылки вместо скриншотов. Ниже — рабочий docker-compose.yml, который поднимает Redash со всеми зависимостями за один docker compose up, и то, что обычно упускают при первом запуске: инициализация БД, воркеры для тяжёлых запросов и бэкап.

Что такое Redash и зачем он на своём сервере

Redash — open-source BI-инструмент: пишете SQL (или используете конструктор запросов для NoSQL-источников), получаете таблицу или график, из графиков собираете дашборд. Поддерживает десятки источников — PostgreSQL, MySQL, ClickHouse, MongoDB, Google Sheets, Elasticsearch, Redis и другие через плагины-коннекторы.

Почему self-hosted, а не облачный сервис аналитики: данные не покидают вашу инфраструктуру, нет лимитов на число пользователей или запросов, и не нужно платить за место каждого аналитика отдельно. Минус очевиден — обновления, бэкапы и мониторинг ложатся на вас. Для команды из 3-15 человек, которым нужны регулярные отчёты и общие дашборды, это разумный компромен по сравнению с Metabase (проще в освоении, но менее гибкий SQL-редактор) или Superset (мощнее, но заметно тяжелее в администрировании).

Архитектурно Redash — связка из пяти контейнеров: веб-сервер (Flask), два типа воркеров (для запланированных и разовых запросов), Redis как очередь задач и PostgreSQL как хранилище метаданных — дашбордов, запросов, пользователей. Данные, которые вы анализируете, лежат в других базах, к которым Redash просто подключается.

Готовый docker-compose.yml

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

mkdir -p /opt/redash && cd /opt/redash

# docker-compose.yml
x-redash-service: &redash-service
  image: redash/redash:10.1.0.b50633
  restart: unless-stopped
  env_file: .env
  depends_on:
    - postgres
    - redis

services:
  server:
    <<: *redash-service
    container_name: redash_server
    command: server
    ports:
      - "127.0.0.1:5000:5000"

  scheduler:
    <<: *redash-service
    container_name: redash_scheduler
    command: scheduler

  scheduled_worker:
    <<: *redash-service
    container_name: redash_scheduled_worker
    command: worker
    environment:
      QUEUES: "scheduled_queries,schemas"
      WORKERS_COUNT: 1

  adhoc_worker:
    <<: *redash-service
    container_name: redash_adhoc_worker
    command: worker
    environment:
      QUEUES: "queries"
      WORKERS_COUNT: 2

  redis:
    image: redis:7-alpine
    container_name: redash_redis
    restart: unless-stopped
    volumes:
      - redash_redis:/data

  postgres:
    image: postgres:15-alpine
    container_name: redash_postgres
    restart: unless-stopped
    env_file: .env
    environment:
      POSTGRES_DB: redash
    volumes:
      - redash_postgres:/var/lib/postgresql/data

volumes:
  redash_postgres:
  redash_redis:

Версия образа 10.1.0.b50633 — известная стабильная сборка; на Docker Hub (hub.docker.com/r/redash/redash/tags) проверьте, не появилось ли более свежего тега, и подставьте его вместо этого. Redash как upstream-проект последние годы обновляется небыстро, это не мешает ему стабильно работать в проде.

Порт сервера привязан к 127.0.0.1:5000, то есть снаружи недоступен напрямую — доступ будет только через reverse proxy с HTTPS (раздел ниже). Для быстрого теста без прокси временно замените на "5000:5000".

.env и первый запуск: инициализация базы

Создайте .env рядом с docker-compose.yml:

# .env
PYTHONUNBUFFERED=0
REDASH_LOG_LEVEL=INFO
REDASH_REDIS_URL=redis://redis:6379/0
POSTGRES_PASSWORD=замените_на_свой_надёжный_пароль
REDASH_DATABASE_URL=postgresql://postgres:замените_на_свой_надёжный_пароль@postgres/redash
REDASH_COOKIE_SECRET=сгенерируйте_случайную_строку
REDASH_SECRET_KEY=сгенерируйте_вторую_случайную_строку
REDASH_MAIL_DEFAULT_SENDER=redash@yourdomain.com

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

openssl rand -hex 32   # для REDASH_COOKIE_SECRET
openssl rand -hex 32   # для REDASH_SECRET_KEY

POSTGRES_PASSWORD должен совпадать с паролем в REDASH_DATABASE_URL — разошедшиеся пароли в этих двух местах чаще всего и мешают серверу стартовать после первого деплоя.

Дальше — поднимаем зависимости, инициализируем схему БД и только потом стартуем весь стек:

docker compose up -d postgres redis
sleep 5
docker compose run --rm server create_db
docker compose up -d

Команда create_db создаёт таблицы Redash внутри базы redash — без неё сервер упадёт с ошибкой отсутствующих таблиц при первом обращении. Проверьте, что все контейнеры живы:

docker compose ps
docker compose logs -f server

Первый вход — http://127.0.0.1:5000 (или ваш домен через прокси) откроет форму создания администратора: имя организации, email, пароль. Это единственный раз, когда учётка создаётся без приглашения — дальше новых пользователей добавляет уже администратор из интерфейса.

Подключение источников данных

В интерфейсе: Settings → Data Sources → New Data Source. Для PostgreSQL подключение выглядит так:

Важный момент безопасности: заводите для Redash отдельного read-only пользователя в каждой подключаемой базе, не используйте суперпользователя. В PostgreSQL это делается так:

CREATE USER redash_reader WITH PASSWORD 'надёжный_пароль';
GRANT CONNECT ON DATABASE analytics TO redash_reader;
GRANT USAGE ON SCHEMA public TO redash_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO redash_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO redash_reader;

Последняя строка важна — без неё новые таблицы, созданные после выдачи прав, останутся недоступны Redash, и придётся повторять GRANT вручную после каждой миграции.

Для ClickHouse источник называется в списке "ClickHouse" и требует HTTP-порт (обычно 8123); если ещё выбираете, что ставить под аналитику, у нас есть разбор ClickHouse или PostgreSQL для аналитики. Если база лежит на другом сервере, а не в этом же docker-compose, убедитесь, что firewall пропускает трафик именно с IP сервера Redash, а не открывает порт всему миру.

Дашборды и шаринг с командой

Запрос сохраняется через Save, из результата строится визуализация (таблица, линейный график, столбцы, pie, counter-виджет для одного числа) кнопкой New Visualization. Дашборд — это набор виджетов с разных запросов на одной странице, с фильтрами, общими для нескольких графиков сразу (Dashboard filters), и настраиваемым интервалом автообновления.

Права доступа устроены на уровне групп: в Settings → Groups создаёте группу (например, "Маркетинг"), добавляете туда пользователей и конкретные дашборды/источники данных, к которым у группы есть доступ. Это удобнее, чем раздавать права поштучно каждому — при найме нового аналитика достаточно добавить его в нужную группу.

Публичный шаринг дашборда наружу (без логина в Redash) включается кнопкой Share Dashboard → Publish, но с этим стоит быть аккуратным: публичная ссылка отдаёт данные всем, у кого она есть, без проверки прав. Для внешних отчётов клиентам лучше заводить отдельного read-only пользователя, а не публиковать дашборд полностью открытым.

Запланированные обновления запроса (например, раз в час) настраиваются полем Refresh Schedule в самом запросе — эти задачи разбирает scheduled_worker из очереди scheduled_queries, а ручные запуски из интерфейса — adhoc_worker из очереди queries. Если дашборды тяжёлые и обновляются часто, увеличьте WORKERS_COUNT у scheduled_worker — но помните, что каждый воркер держит своё соединение к каждой подключённой базе, и на стороне БД может не хватить max_connections.

Резервное копирование и обновление

Вся ценность Redash — в базе PostgreSQL внутри контейнера redash_postgres: там и запросы, и дашборды, и пользователи, и учётные данные источников (пароли к вашим базам). Бэкап — обязателен.

docker compose exec -T postgres pg_dump -U postgres redash | gzip > redash_backup_$(date +%F).sql.gz

Восстановление из бэкапа на новом сервере:

gunzip -c redash_backup_2026-08-20.sql.gz | docker compose exec -T postgres psql -U postgres redash

Вынесите команду бэкапа в cron с ротацией:

# crontab -e
0 3 * * * cd /opt/redash && docker compose exec -T postgres pg_dump -U postgres redash | gzip > /opt/redash-backups/redash_$(date +\%F).sql.gz && find /opt/redash-backups -mtime +14 -delete

Если храните бэкапы не только локально, а с дедупликацией и на удалённом хранилище, пригодится BorgBackup в Docker Compose.

Обновление: смените тег образа в docker-compose.yml на новый, затем:

docker compose pull
docker compose down
docker compose up -d postgres redis
docker compose run --rm server manage db upgrade
docker compose up -d

Команда manage db upgrade применяет миграции схемы к новой версии — без неё после обновления образа сервер может не подняться из-за расхождения версии кода и структуры базы. Перед обновлением обязательно снимите свежий бэкап — миграции иногда меняют схему необратимо.

Reverse proxy, HTTPS и базовая безопасность

Порт 5000 в готовом compose-файле закрыт на localhost намеренно — Redash по умолчанию не шифрует трафик и не рассчитан на прямой выход в интернет. Поставьте перед ним reverse proxy с TLS, например Traefik или nginx.

Минимальный пример с nginx (если у вас уже настроен сертификат через certbot):

server {
    listen 443 ssl http2;
    server_name redash.yourdomain.com;

    ssl_certificate     /etc/letsencrypt/live/redash.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/redash.yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:5000;
        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;
    }
}

Если предпочитаете автоматический выпуск сертификатов без ручной возни с certbot, у нас есть разбор Traefik как reverse proxy для докера — конфигурация под связку с уже работающими контейнерами.

Дополнительно: порты 5432 (Postgres Redash) и 6379 (Redis) в готовом compose-файле и так не публикуются наружу — доступны только внутри docker-сети между контейнерами compose-проекта, не переопределяйте это без необходимости.

Двухфакторная аутентификация для пользователей включается в профиле (Settings → Account → Enable Two-Factor Authentication) — стоит обязательно включить для админской учётки на проде, раз в этой БД лежат учётные данные ко всем подключённым источникам.

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