Перейти к основному содержимому

Использование Docker Compose



предупреждение

docker compose рассчитан на запуск контейнеров на одном хосте и не обеспечивает высокую доступность. Поэтому мы не поддерживаем и не рекомендуем docker compose для продакшена. Для одно-хостовых окружений рекомендуем minikube вместе с инструкцией по установке на k8s.

Как сказано в быстром старте, быстрее всего попробовать Liteset локально через Docker Compose на Linux или Mac OSX. Liteset не имеет официальной поддержки Windows. Это также самый простой способ быстро поднять полноценное окружение для разработки.

Поддерживается 4 основных режима docker compose:

  1. docker-compose.yml: интерактивная разработка — локальная папка с фронтенд/бэкенд-кодом монтируется в контейнеры, изменения отражаются в приложении в реальном времени.
  2. docker-compose-light.yml: облегчённая конфигурация с минимальным набором сервисов (БД, приложение Liteset, фронтенд-dev-сервер). Использует in-memory кэш вместо Redis и подходит для запуска нескольких инстансов одновременно.
  3. docker-compose-non-dev.yml: собирает более «иммутабельный» образ из локальной ветки и поднимает все сервисы. Состояние локальной ветки на момент up отражается, но изменения после этого — уже нет.
  4. docker-compose-image-tag.yml: скачивает готовый образ с docker-hub (например, релиз 6.0.0) и поднимает его. Локальная ветка ни на что не влияет — мы просто берём предсобранный образ. Чтобы docker compose корректно работал с поднимаемым Postgres, используйте теги с суффиксом -dev, например export TAG=6.0.0-dev или export TAG=5.0.0-dev (по умолчанию latest-dev). dev-сборки включают psycopg2-binary, нужный для подключения к Postgres из docker compose.

Подробнее по каждому подходу — после установки общих требований.

Требования

Документация предполагает, что у вас установлены Docker и git. docker-compose устаревает, поэтому мы используем docker compose.

1. Клонирование репозитория Liteset

Клонируйте репозиторий Liteset (либо upstream Apache Superset, если хотите ванильный Superset):

git clone --depth=1 https://github.com/happykust/liteset.git

После выполнения команды появится папка liteset.

2. Запуск Liteset через Docker Compose

Предполагается, что вы знакомы с механикой docker compose. Здесь мы будем использовать docker compose up, хотя в некоторых случаях вам может понадобиться docker compose pull (форс-проверка обновлений), docker compose build (форс-сборка) или docker compose build --pull (сборка на свежих базовых образах). В большинстве случаев up достаточно.

Вариант №1 — интерактивное окружение для разработки

# --build гарантирует, что все слои свежие
docker compose up --build
подсказка

В dev-режиме контейнер superset-node должен закончить сборку ассетов, прежде чем UI будет корректно отображаться. Если нужно просто попробовать Liteset без правки кода — используйте production-вариант или конкретную версию ниже.

подсказка

По умолчанию мы монтируем локальную папку superset-frontend и запускаем npm install и npm run dev (webpack компилирует/бандлит фронтенд). На машинах с менее чем 16 ГБ RAM это может быть медленно. Установите BUILD_SUPERSET_FRONTEND_IN_DOCKER=false и выполняйте npm i && npm run dev локально в терминале — будет НАМНОГО быстрее.

подсказка

Иногда состояние npm выходит из синхронизации. npm run prune из папки superset-frontend/ уничтожит node_modules/ пакетов и поможет начать с чистого листа. В контексте docker compose установка export NPM_RUN_PRUNE=true перед docker compose up запустит prune изнутри контейнера. Стартап замедлится, но многие npm-проблемы исчезнут.

Вариант №2 — облегчённая dev-сборка с несколькими инстансами

Лёгкое окружение, потребляет меньше ресурсов и поддерживает запуск нескольких инстансов:

# Один лёгкий инстанс (порт по умолчанию 9001)
docker compose -f docker-compose-light.yml up

# Несколько инстансов на разных портах
NODE_PORT=9001 docker compose -p superset-1 -f docker-compose-light.yml up
NODE_PORT=9002 docker compose -p superset-2 -f docker-compose-light.yml up
NODE_PORT=9003 docker compose -p superset-3 -f docker-compose-light.yml up

Конфигурация включает:

  • PostgreSQL (только во внутренней сети).
  • Сервер приложения Liteset.
  • Frontend dev-сервер с hot reload через webpack.
  • In-memory кэш (без Redis).
  • Изолированные тома и сети для каждого инстанса.

Доступ к каждому — http://localhost:{NODE_PORT} (например, http://localhost:9001).

Вариант №3 — сборка иммутабельных образов из локальной ветки

docker compose -f docker-compose-non-dev.yml up

Вариант №4 — поднять официальный релиз

# Версия, которую хотим запустить
export TAG=6.0.0
# Получаем тег (мы клонировали shallow, поэтому fetch отдельно)
git fetch --depth=1 origin tag $TAG
# Можно подтянуть все теги, если есть трафик:
# git fetch --tags
# Чекаут на тег
git checkout $TAG
# Запуск docker compose
docker compose -f docker-compose-image-tag.yml up

В переменной TAG можно ссылаться на разные релизы, github SHA и master. Подробнее о доступных тегах — в документации по Docker-образам.

примечание

Для вариантов #2 и #3 рекомендуется чекаутиться на релизный тег (git checkout 6.0.0) для предсказуемого результата. Это гарантирует, что docker-compose.*.yml и монтируемые скрипты docker/ синхронизированы с поднимаемым образом.

Подсказки и конфигурация docker compose

предупреждение

Всё содержимое инстанса Liteset — графики, дашборды, пользователи и т. п. — хранится в БД метаданных. В продакшене эту базу нужно бэкапить. Установка через docker compose по умолчанию хранит данные в томе Docker для PostgreSQL — этот том не бэкапится.

Повторим: УСТАНОВКА ЧЕРЕЗ DOCKER COMPOSE НЕ ГОТОВА К ПРОДАКШЕНУ ИЗ КОРОБКИ.

Вы увидите поток логов от поднимающихся контейнеров. Когда поток замедлится, у вас локально работает Liteset! Чтобы избежать стены логов в будущем, добавляйте -d к команде docker compose up.

Дальнейшая настройка

Эта секция — для тех, кто хочет настроить, как Liteset работает в Docker Compose. Иначе можно перейти к следующей секции.

Дополнительные python-пакеты и оверрайды конфигурации можно подключить, как описано в docker/README.md.

docker/.env задаёт значения по умолчанию для всех образов в docker compose, а docker/.env-local позволяет переопределить их. docker/.env-local указан в .gitignore — чтобы случайно не закоммитить чувствительную конфигурацию.

Важная переменная — SUPERSET_LOAD_EXAMPLES. Она определяет, заполнит ли контейнер superset_init БД примерами и графиками. Примеры удобны для обучения и тестирования, но не нужны опытным пользователям и в продакшене. Загрузка может занять несколько минут и сжечь CPU, поэтому на слабых машинах её стоит отключить.

Для более продвинутых динамических конфигураций, обычно живущих в superset_config.py в PYTHONPATH, можно создать файл docker/pythonpath_dev/superset_config_docker.py (он игнорируется git'ом, что предотвращает случайный коммит). Механика — в docker/pythonpath_dev/superset_config.py, где есть строка from superset_config_docker import *.

примечание

Подключение к другим БД из Liteset проще всего сделать модификацией docker-compose-non-dev.yml: добавьте свою БД как сервис, от которого зависят другие (через x-superset-depends-on). Некоторые пробуют ставить network_mode: host, но это, как правило, ломает установку — конфигурация требует DNS-разрешения имён сервисов через docker compose.

3. Вход в Liteset

Локальный инстанс также включает Postgres-сервер для хранения данных и приходит с примерными датасетами. Откройте Liteset в браузере по адресу http://localhost:8088. Многие браузеры по умолчанию пробуют https — убедитесь, что используется http.

Логин по умолчанию:

username: admin
password: admin

4. Подключение Liteset к локальной БД

Когда Liteset запускается в Docker, он работает в своём контейнере — как если бы он работал на отдельной машине. Поэтому подключение к локальной БД с хостом localhost не сработает: localhost указывает на сам контейнер, а не на ваш хост. К счастью, Docker даёт способ обращаться к ресурсам хоста изнутри контейнера, чем мы и воспользуемся.

Ниже — инструкция для подключения к PostgreSQL (запущенному на вашем хосте) из Liteset (запущенного в контейнере). Для других СУБД настройка может отличаться, но суть та же:

  1. (Пользователи Mac могут пропустить) Настройте локальный PostgreSQL так, чтобы он принимал входящие соединения извне. По умолчанию Postgres принимает только с localhost, а внутри Docker localhost — это другая сущность. Нужно править postgresql.conf и pg_hba.conf (инструкции под вашу ОС / версию Postgres легко найти в сети). Для Docker достаточно whitelist'ить IP 172.0.0.0/8, а не *. Внимание: делать это в продакшен-БД может быть катастрофой — вы открываете её в публичный интернет.
  2. Вместо localhost пробуйте host.docker.internal (Mac, Ubuntu) или 172.18.0.1 (Linux). На Mac Docker Desktop создаёт DNS-запись host.docker.internal, ведущую на корректный адрес хоста; на Linux по умолчанию её нет. Если эти варианты не сработали — выясните точный IP через ifconfig/ip addr show, посмотрев интерфейс docker0. Если интерфейса нет, попробуйте docker network inspect bridge и найдите запись "Gateway".

4. Собирать или не собирать

При docker compose up Docker сам соберёт нужное (если кэш-слои не хватает). Запуск docker compose build перед docker compose up (или эквивалент docker compose up --build) гарантирует, что образы соответствуют коду в репозитории. Это касается основного docker-compose.yml; для альтернативных файлов (выше) — не применимо.