Запуск Glarus BI в Docker¶

Glarus BI предоставляет официальный образ Docker через репозиторий компании Glarus Digital, который можно использовать для развёртывания в любой системе, на которой работает Docker.

Если вы пытаетесь обновить версию Glarus BI в Docker, ознакомьтесь с инструкцией по обновлению.

Быстрый старт¶

Используйте это краткое руководство для локального запуска версии Glarus BI. Инструкцию по запуску Glarus BI для промышленной эксплуатации см. ниже.

Предполагается, что у вас установлен и запущен Docker. Получите последний образ Docker. Запросите адрес репозитория и другие данные в техподдержке. Ниже показан синтетический пример:

docker pull repo/image:latest

Затем запустите контейнер Glarus BI:

docker run -d -p 3000:3000 --name glarusBI repo/glarus-bi

Это запустит сервер Glarus BI на порту 3000 по умолчанию.

Опционально: чтобы просмотреть журнал запуска по мере инициализации Glarus BI, запустите:

docker logs -f glarusBI

После завершения запуска вы можете получить доступ к вашему Glarus BI Open Source по адресу http://localhost:3000.

Чтобы запустить Glarus BI на другом порту, скажем, на 12345 выполните следующее:

docker run -d -p 12345:3000 --name glarusBI repo/glarus-bi

Установка для промышленной эксплуатации¶

Glarus BI поставляется со встроенной базой данных H2, которая использует файловую систему для хранения собственных данных приложения. Это означает, что если вы удалите контейнер, вы потеряете данные приложения Glarus BI (ваши запросы, дашборды, коллекции и т.д.).

Если вы хотите запустить Glarus BI в среде промышленной эксплуатации, вам необходимо хранить данные приложения в базе данных уровня промышленной эксплуатации.

После того как вы подготовили СУБД, например Postgres, для Glarus BI, чтобы использовать её для хранения данных своего приложения, всё что вам нужно сделать, это предоставить Glarus BI информацию о подключении и учётные данные, чтобы Glarus BI могла подключиться к ней.

Запуск Docker для промышленной эксплуатации¶

Допустим, вы создали базу данных Postgres следующим образом:

createdb glarusappdb

Нет необходимости вручную добавлять какие-либо таблицы; Glarus BI сама создаст их при запуске. И давайте предположим, что база данных доступна через my-database-host:5432 с именем пользователя name и паролем password.

Вот пример команды Docker, которая запускает Glarus BI с использованием этой базы данных:

docker run -d -p 3000:3000 \
  -e "MB_DB_TYPE=postgres" \
  -e "MB_DB_DBNAME=glarusappdb" \
  -e "MB_DB_PORT=5432" \
  -e "MB_DB_USER=name" \
  -e "MB_DB_PASS=password" \
  -e "MB_DB_HOST=my-database-host" \
   --name glarusBI repo/glarus-bi

Имейте в виду, что Glarus BI будет подключаться изнутри вашего контейнера Docker, поэтому убедитесь, что:

вы используете полное имя хоста;
вы установили правильную запись в файл /etc/hosts вашего контейнера.

Мультиузловая конфигурация¶

Для горизонтального масштабирования запустите несколько экземпляров одной версии Glarus BI с общей базой данных приложения PostgreSQL. На всех узлах должны совпадать параметры MB_DB_*, включая способ задания подключения, и ключ MB_ENCRYPTION_SECRET_KEY. Из параметров базы данных приложения вычисляется код запроса лицензии; различающиеся настройки подключения могут изменить этот код, даже если ведут в одну базу. Для входа пользователей нужна действующая лицензия, соответствующая конфигурации установки. Храните общий ключ шифрования и пароль подключения в защищённой конфигурации установки.

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

Перед узлами администратор настраивает внешний балансировщик, например nginx или HAProxy. Алгоритмы round-robin и least-conn распределяют HTTP-запросы; Glarus BI не выбирает сервер по загрузке CPU или RAM. Настройте активную проверку GET /api/health с ожидаемым HTTP-статусом 200. В отличие от простой проверки процесса она учитывает завершение инициализации и доступность базы данных приложения. Пример Docker healthcheck ниже проверяет контейнер; исключение узла из маршрутизации отдельно настраивается в балансировщике.

Пример backend для HAProxy с активными проверками. Имена query1 и query2 должны разрешаться в адреса узлов:

backend glarus_bi
    mode http
    balance roundrobin
    option httpchk GET /api/health
    http-check expect status 200
    server query1 query1:3000 check inter 5s fall 2 rise 2
    server query2 query2:3000 check inter 5s fall 2 rise 2

Для least-conn замените balance roundrobin на balance leastconn. Таймауты, TLS, внешний адрес и передачу заголовков прокси настройте для своей установки. Балансировщик не входит в поставку Glarus BI. Активные проверки на выбранной реализации nginx требуют соответствующих средств настройки; наличие одного upstream не заменяет проверку /api/health.

Фоновые задания по расписанию — синхронизацию и сканирование, обновление кэша моделей, ETL по cron и запуск рассылок — координирует кластерный Quartz с JDBC JobStore в общей базе приложения и isClustered=true. Quartz координирует захват триггеров между работающими планировщиками; узел для следующего запуска может быть другим. Это не гарантия одного запуска ETL на каждую временную отметку cron: возможны близкие повторные запуски. Операции с внешними побочными эффектами проектируйте с учётом повторов; однократность при сбое или повторной обработке не гарантируется. Часы узлов должны быть синхронизированы.

Не смешивайте версии приложения в одном кластере: порядок описан в разделе Обновление Glarus BI в кластере. Схему с отдельным планировщиком см. в разделе Выделенный узел фоновых задач.

Выделенный узел фоновых задач¶

Администратор может отделить выполнение триггеров Quartz от пользовательского HTTP-трафика: запустить N узлов пользовательских запросов с MB_DISABLE_SCHEDULER=true за балансировщиком и один узел с MB_DISABLE_SCHEDULER=false либо без этой переменной вне пользовательского балансировщика. Все узлы используют одну версию приложения, общую PostgreSQL, одинаковые параметры подключения и общий ключ шифрования.

Пользовательский балансировщик → query1 … queryN
query1 … queryN: MB_DISABLE_SCHEDULER=true
background: MB_DISABLE_SCHEDULER=false
background: вне пользовательского балансировщика
Все узлы → общая PostgreSQL приложения

Узел background выполняет запуски по расписанию: синхронизацию и сканирование, кэширование моделей, ETL и рассылки. Для тяжёлых витрин можно выбрать отдельное подключение ClickHouse при настройке соответствующих моделей или ETL. Это выбор хранилища и вычислительного подключения; он не перенаправляет произвольные запросы на отдельный узел Glarus BI.

Переменная задаётся при запуске; смена роли требует перезапуска узла. Она запрещает запуск Quartz, но не создание самого планировщика: при старте приложения он инициализируется в режиме standby и регистрирует задания. Создание, изменение и удаление расписаний ETL через такой узел обращается к общему JDBC JobStore; обязательный перезапуск фонового узла после изменения расписания не требуется.

Это разделение касается выполнения триггеров Quartz. Ручной запуск ETL, пользовательские SQL-запросы и другие асинхронные операции не получают отдельный маршрут автоматически. Тегов для назначения типов заданий узлам и динамической маршрутизации фоновых задач по таким тегам нет.

Один узел background остаётся единственной точкой выполнения расписаний: если он недоступен, узлы с отключённым Quartz не начнут выполнять его задания. Для доступности планировщика можно выделить несколько узлов с включённым Quartz, использующих общую PostgreSQL. Действие переменной описано в разделе MB_DISABLE_SCHEDULER.

Active-Active и отказ узла¶

В режиме Active-Active узлы Glarus BI работают с общей базой PostgreSQL приложения. Балансировщик трафика настраивает администратор; его проверка работоспособности должна обращаться к GET /api/health и исключать отказавший узел. Балансировщик не входит в поставку Glarus BI. После исключения узла новые запросы направляются на доступные узлы.

Сессии входа хранятся в общей базе приложения. Если пользователь остаётся на том же внешнем адресе и срок действия сессии не истёк, при переключении на другой узел повторный вход не требуется. Значения фильтров, переданные в URL дашборда, применяются при его открытии. Последние выбранные значения фильтров по умолчанию сохраняются для пользователя и дашборда в общей базе приложения и восстанавливаются при следующей загрузке.

Запрос, который выполнялся на отказавшем узле, может оборваться; проверьте его результат и при необходимости запустите снова. Несохранённые изменения вопроса или дашборда при отказе узла не сохраняются автоматически.

Узлы с включённым Quartz продолжают выполнять фоновые задания по общему хранилищу заданий в PostgreSQL приложения. Если узел отказал во время задания, продолжение с того же места и автоматический повтор не гарантируются: результат зависит от задания и его расписания. Узел с MB_DISABLE_SCHEDULER=true не заменяет отказавший планировщик.

Перед использованием конфигурации проверьте работу балансировщика, смену узла, сохранение сессии и следующие срабатывания расписаний. При обновлении следуйте разделу Обновление Glarus BI в кластере.

Миграция на базу данных уровня промышленной эксплуатации¶

Если вы уже использовали Glarus BI с базой данных приложения по умолчанию (H2), а теперь хотите использовать базу данных для промышленной эксплуатации приложения, не потеряв свои данные (запросы, дашборды и т.д.), см. Миграция с H2 на базу данных уровня промышленной эксплуатации.

Пример YAML-файла для Docker Compose¶

Вот пример файла docker-compose.yml для запуска Glarus BI с базой данных PostgreSQL glarusappdb:

Примечание

Это пример файла. Он не предназначен для запуска Glarus BI в промышленной эксплуатации. См. руководство: Как запускать Metabase в рабочей среде (англ.).

services:
  glarusbi:
    image: repo/glarus-bi:latest
    container_name: glarusbi
    hostname: glarusbi
    volumes:
      - /dev/urandom:/dev/random:ro
    ports:
      - 3000:3000
    environment:
      MB_DB_TYPE: postgres
      MB_DB_DBNAME: glarusappdb
      MB_DB_PORT: 5432
      MB_DB_USER: glarus
      MB_DB_PASS: mysecretpassword
      MB_DB_HOST: postgres
    networks:
      - glarusnet1
    healthcheck:
      test: curl --fail -I http://localhost:3000/api/health || exit 1
      interval: 15s
      timeout: 5s
      retries: 5
  postgres:
    image: postgres:latest
    container_name: postgres
    hostname: postgres
    environment:
      POSTGRES_USER: glarus
      POSTGRES_DB: glarusappdb
      POSTGRES_PASSWORD: mysecretpassword
    networks:
      - glarusnet1
networks:
  glarusnet1:
    driver: bridge

Дополнительная настройка Docker¶

Запуск Glarus BI в Docker
Быстрый старт
Установка для промышленной эксплуатации
- Запуск Docker для промышленной эксплуатации
Миграция на базу данных уровня промышленной эксплуатации
Пример YAML-файла для Docker Compose
Дополнительная настройка Docker
Поиск неисправностей
Продолжение установки

Конфигурирование Jetty сервера Glarus BI¶

Вы можете использовать любые пользовательские настройки из Настройка веб-сервера Jetty Glarus BI, установив переменные среды в команде запуска Docker.

Переменные среды, специфичные для Docker¶

В дополнение к стандартным пользовательским настройкам существуют две специфичные для Docker переменные среды MUID и MGID, которые используются для установки идентификаторов пользователя и группы, используемых Glarus BI при работе в Docker-контейнере. Эти параметры позволяют сопоставлять права доступа к файлам, когда, например, файлы базы данных приложения совместно используются хостом и контейнером.

При следующем запуске вы будете использовать файл базы данных, принадлежащий вашей учётной записи и хранящийся в вашем домашнем каталоге:

docker run -d -v ~/my-glarus-db:/metabase.db --name glarusBI -e MB_DB_FILE=/metabase.db -e MUID=$UID -e MGID=$GID -p 3000:3000 repo/glarus-bi

Установка часового пояса в Java¶

Лучше всего установить часовой пояс в Java таким образом, чтобы он соответствовал часовому поясу, в котором должны работать все ваши отчёты. Это можно сделать, просто указав переменную среды JAVA_TIMEZONE, которая используется сценарием запуска Glarus BI. Например:

docker run -d -p 3000:3000 -e "JAVA_TIMEZONE=Europe/Moscow" --name glarusBI repo/glarus-bi

Копирование базы данных приложения¶

Расположение базы данных приложения по умолчанию в контейнере — /metabase.db/metabase.db.mv.db. Вы можете скопировать этот каталог из контейнера, используя следующую команду (заменив CONTAINER_ID фактическим идентификатором или названием контейнера, например glarusBI):

docker cp CONTAINER_ID:/metabase.db ./

Содержимое БД останется в каталоге metabase.db.

Монтирование тома хранилища файлов¶

Чтобы сохранить ваши данные вне контейнера и сделать их доступными для использования между запусками контейнера, мы можем смонтировать локальный путь к файлу внутри нашего контейнера.

docker run -d -p 3000:3000 \
  -v ~/glarus-data:/metabase-data \
  -e "MB_DB_FILE=/metabase-data/metabase.db" \
  --name glarusBI repo/glarus-bi

Когда вы запускаете свой контейнер, Glarus BI будет использовать файл базы данных (MB_DB_FILE) в ~/glarus-data/metabase.db вместо его расположения по умолчанию. При этом мы смонтируем эту папку из нашей локальной файловой системы в контейнер.

Получить конфигурацию, если контейнер остановлен¶

Если вы ранее запустили и настроили свою Glarus BI с помощью локальной базы данных, а затем остановили контейнер, ваши данные останутся там, если только вы не удалили контейнер с помощью команды docker rm. Чтобы восстановить предыдущую конфигурацию:

1. Идентифицируйте остановленный контейнер с помощью команды `docker ps -a`:¶

docker ps -a | grep glarusbi
    ca072cd44a49        repo/glarus-bi        "/app/run_metabase.sh"   About an hour ago   Up About an hour          0.0.0.0:3000->3000/tcp   glarusBI
    02e4dff057d2        262aa3d0f714             "/app/run_metabase.sh"   23 hours ago        Exited (0) 23 hours ago                            pedantic_hypatia
    0d2170d4aa4a        262aa3d0f714             "/app/run_metabase.sh"   23 hours ago        Exited (0) 23 hours ago                            stoic_lumiere

Как только вы определите остановленный контейнер с вашей конфигурацией, сохраните идентификатор контейнера из крайнего левого столбца для следующего шага.

2. Используйте `docker commit`, чтобы создать новый пользовательский образ Docker из остановленного контейнера, содержащего вашу конфигурацию¶

docker commit ca072cd44a49 mycompany/glarusbi-custom
sha256:9ff56186de4dd0b9bb2a37c977c3a4c9358647cde60a16f11f4c05bded1fe77a

3. Запустите новый образ с помощью `docker run`, чтобы снова начать работу¶

docker run -d -p 3000:3000 --name glarusBI mycompany/glarusbi-custom
430bb02a37bb2471176e54ca323d0940c4e0ee210c3ab04262cb6576fe4ded6d

После этого запуска Glarus BI запустится с предыдущей конфигурацией. Если вы не получили то, что ожидали, попробуйте другой остановленный контейнер и повторите эти шаги.

Добавление внешних зависимостей или плагинов¶

Чтобы добавить файлы JAR для внешних зависимостей, (например, драйверы JDBC Oracle или Vertica или сторонние драйверы Glarus BI), сделайте следующее:

создайте каталог plugins в вашей хост-системе и
привяжите этот каталог, чтобы он был доступен для Glarus BI по пути /plugins (используя либо --mount, либо -v/--volume).

Например, если у вас есть каталог /path/to/plugins в вашей хост-системе, вы можете сделать его содержимое доступным для Glarus BI, используя параметр --mount следующим образом:

docker run -d -p 3000:3000 \
  --mount type=bind,source=/path/to/plugins,destination=/plugins \
  --name glarusBI repo/glarus-bi

Обратите внимание, что Glarus BI будет использовать этот каталог для извлечения плагинов, связанных с дистрибутивом Glarus BI по умолчанию (например, драйверов для различных баз данных, таких как SQLite), поэтому он должен быть доступен для чтения и записи для Docker.

Использование Docker Secrets для сокрытия конфиденциальных параметров¶

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

Вот пример файла docker-compose.yml для запуска контейнера Glarus BI с секретами для подключения к базе данных PostgreSQL.

В дополнение к этому примеру файла yml вам нужно создать два файла:

db_user.txt
db_password.txt

Эти файлы должны находиться в том же каталоге, что и docker-compose.yml. Поместите db_user в файл db_user.txt и db_password в файл db_password.txt.

Обратите внимание на постфикс _FILE в переменных окружения, где заданы конфиденциальные параметры: