Разработка Custom плагина визуализации для Apache Superset 3.1.2 (2024)

Ivan Shamaev (Admin)
Posted by Ivan Shamaev (Admin)

Содержание

Введение в разработку кастомных плагинов визуализации Superset

В этой статье будет подробно описано процесс разработки кастомного плагина визуализации данных с использованием библиотеки визуализации Apache Echart для Apache Superset.

Также будут описаны способы деплоя плагина в образ суперсета.

Общая схема разработки и деплоя плагинов визуализации Apache Superset

Ниже приведена упрощенная схема процесса разработки и добавления плагина в образ Apache Superset 3.1.2:

Из чего состоит разработка плагина для суперсет

Для начала необходимо спроектировать внешний вид плагина, то есть понять, что вы хотите в итоге получить. Самый простой способ — это нарисовать макет плагина на листе бумаги с помощью ручки и карандаша. Отложить в сторону и через несколько часов еще взглянуть свежим взглядом, сделать ряд улучшений — вуаля, у вас готов прототип (в зависимости от сложности плагина и вашего опыта может понадобиться несколько итераций по прототипированию). Не стесняйтесь выполнить этот этап за 3-5 подходов. Даже можно с кем-нибудь посоветоваться и поискать примеры в интернете.

Далее необходимо понять какой вид входных данных нужен для визуализации вашего макета. Нужны ли данные только текущего периода, либо нужны данные за предыдущий период. Если необходим предыдущий период, то продумайте каким образом эти данные получить. То есть нужно понять на какой стороне проводить обработку данных — с помощью SQL или сделать пост обработку полученных данных из SQL. Но не налегайте на постобработку данных. Это может привести к большой нагрузке сервера. Допустима постобработка для микрообъемов данных (до нескольких десятков или сотен строк).

Далее необходимо настроить среду разработки. После этого нужно запустить генератор плагина который создаст шаблонный код плагина в новой директории.

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

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

На этом этапе есть два варианта публикации плагина в npm регистры пакетов:

  • Первый вариант — это npmjs.com
  • Второй вариант — это на гитхабе развернуть среду для публикации пакетов
  • Либо, третий вариант — в gitlab

После того как плагин был опубликован, необходимо попробовать установить в дев-среде. После этого перейти уже к деплою через Dockerfile.

Ниже приведена подробная инструкция что и как делать!

Шаг 1. Качаем репозиторий и переключаемся на версию 3.1.2

Качаем репозиторий, меняем настройки и запускаем Superset 3.1.2

# Клонируем проект из github
git clone https://github.com/apache/superset.git
 
# Переходим в директорию
cd superset
 
# Переключаемся на ветку релиза 3.1.2
git checkout 3.1.2
 
# Проверяем статус (что переключились на правильный тег)
git status

# Обязательно меняем версию образа, который нужно использовать при развертывании
# Делается это в файле docker-compose-non-dev.yml
# nano docker-compose-non-dev.yml

# openssl rand -base64 42
SECRET_KEY = 'сюда вставляем сгенерированный хеш'
TALISMAN_ENABLED = False

# Набор фич FEATURE_FLAGS
FEATURE_FLAGS = {
    "ALERT_REPORTS": True,
    "DRILL_BY": True,
    "DRILL_TO_DETAIL": True,
    "HORIZONTAL_FILTER_BAR": True,
    "DASHBOARD_CROSS_FILTERS": True,
    "ENABLE_TEMPLATE_PROCESSING": True,
    "TAGGING_SYSTEM": True,
    "HORIZONTAL_FILTER_BAR": True,
    "ENABLE_EXPLORE_DRAG_AND_DROP": True,
}

# Запускаем установку (запустится скачивание образов с hub.docker.com)
sudo docker-compose -f docker-compose-non-dev.yml up

Проверяем доступность Superset по адресу:

http://localhost:8088/

Шаг 2. Конфигурируем среду разработки

Ищем нужную версию Node.JS и NPM

В репозитории, либо на github идем в superset-frontend и смотрим версию в package.json:

https://github.com/apache/superset/blob/3.1.2/superset-frontend/package.json

"engines": {
  "node": "^16.20.2",
  "npm": "^8.19.4"
},

Так мы с меньшей вероятностью словим баги при развертывании среды разработки. Из мастера тоже можно вести разработку, но не всегда это удавалось. Из определенного тега почти всегда работает идеально, тьфу тьфу тьфу.

Устанавливаем node.js и npm через NVM

Нам нужна версия 16.20.2

Запускаем команду:

nvm list-remote

Находим такую же версию или больше:

Запускаем команду:

nvm install v16.20.2

Результат выполнения команды (у меня уже эта версия была скачена, поэтому произошло просто переключение на нужную версию):

$ nvm install v16.20.2
v16.20.2 is already installed.
Now using node v16.20.2 (npm v8.19.4)

Среда Node.js и npm сконфигурирована!

Шаг 3. Устанавливаем зависимости и запускаем dev-server

Если на этом шаге что-то пойдет не так, то вы всегда можете в текущей директории найти папку node_modules, удалить ее и запустить npm install (далее по тексту команда npm i) команду заново.

Установка генератора Superset Yeoman

Для начала вам понадобится генератор Superset Yeoman. Рекомендуется использовать версию шаблона, поставляемую с используемой вами версией Superset. Yeoman можно установить, выполнив следующие действия.

Далее мы сначала устанавливаем Yeoman, а затем устанавливаем шаблон генератора плагинов Superset из репозитория Superset.

У меня есть директория ~/plugins в которой находится superset.

Нужно находясь в корне plugins выполнить команду команду:

npm i -g yo

Переходим в директорию генератора:

cd /superset/superset-frontend/packages/generator-superset

и запускаем установку модулей node.js в generator-superset:

npm i

Далее запускаем команду:

npm link

Шаг 4. С помощью генератора Yeoman создаем пустой плагин

После этого мы можем приступить к созданию плагина viz.

Возвращаемся в директорию plugins (вне суперсета) :

cd ~/plugins

В нем создаем новый каталог для своего плагина viz с префиксом superset-plugin-chart- (все плагины должны иметь такой префикс, иначе может не сработать что-то):

mkdir superset-plugin-chart-kpi-cards
cd superset-plugin-chart-kpi-cards

и запускаем генератор Yeoman:

yo @superset-ui/superset

Далее заполняем «анкету» нашего yeoman-generator:

Практически все я оставил по умолчанию, кроме Description.

$ yo @superset-ui/superset

     _-----_     ╭──────────────────────────╮
    |       |    │      Welcome to the      │
    |--(o)--|    │    generator-superset    │
   `---------´   │        generator!        │
    ( _´U`_ )    ╰──────────────────────────╯
    /___A___\   /
     |  ~  |     
   __'.___.'__   
 ´   `  |° ´ Y ` 

? Package name: superset-plugin-chart-kpi-cards
? Plugin name: Kpi Cards
? Description: KPI cards in the form of tiles for each dimension element
? What type of chart would you like? Regular chart
   create package.json
   create .gitignore
   create babel.config.js
   create jest.config.js
   create package-lock.json
   create README.md
   create tsconfig.json
   create src/index.ts
   create src/plugin/buildQuery.ts
   create src/plugin/controlPanel.ts
   create src/plugin/index.ts
   create src/plugin/transformProps.ts
   create src/types.ts
   create src/SupersetPluginChartKpiCards.tsx
   create test/index.test.ts
   create test/__mocks__/mockExportString.js
   create test/plugin/buildQuery.test.ts
   create test/plugin/transformProps.test.ts
   create types/external.d.ts
   create src/images/thumbnail.png

Changes to package.json were detected.

После генерации установятся модули и мы должны получить примерно такую картинку:

Далее у нас развилка — мы можем сбилдить плагин и отобразить его в суперсете, либо не билдить, а запустить дев среду (т.е. среду разработки):

Вариант 1

Чтобы сбилдить плагин viz, выполните следующие команды:

npm ci
npm run build

На этом этапе извлекаются зависимости, создается пакет и выполняются предопределенные модульные тесты в test/ подкаталоге.

Вариант 2 (которым мы пойдем)

В качестве альтернативы, чтобы запустить плагин viz в режиме разработки (пересборку при внесении изменений в код), запустите сервер разработки с помощью следующей команды:

npm run dev

У нас скомпилировался плагин, теперь нужно запустить superset dev сервер.

Шаг 5. Проверяем и разрабатываем плагин на dev-server

Устанавливаем плагин

Чтобы добавить пакет в Superset, перейдите в отдельном окне терминала в директорию superset-frontend исходной папки Superset и выполните следующую команду:

npm i -S ~/plugins/superset-plugin-chart-kpi-cards

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

~/plugins/superset-plugin-chart-kpi-cards/README.md

Вносим изменения в MainPreset.js

После этого отредактируйте superset-frontend/src/visualizations/presets/MainPreset.js и внесите следующие изменения:

import { SupersetPluginChartKpiCards } from 'superset-plugin-chart-kpi-cards';

Затем, чуть ниже в этом же файле () нужно добавить следующую строку:

new SupersetPluginChartKpiCards().configure({ key: 'superset-plugin-chart-kpi-cards' }),

Затем в директории superset-frontend запускаем сервер разработки:

npm run dev-server

Проверяем плагин на dev-server Superset

После запуска dev-server заходим по адресу http://localhost:9000/.

Переходим в раздел Charts и нажимаем кнопку добавить чарт. Находим наш чарт:

Выбираю датасет и нажимаю создать новый чарт. Добавляем колонки и меры в чарт, нажимаем кнопку обновить — вуаля, отрисовывается JSON формат наших данных:

Архитектура плагина и его функциональные части

Схема плагина визуализации Суперсета

Полная схема в PDF: Dependency tree of Custom plugin scripts

Структура нашего плагина superset-plugin-chart-kpi-cards

Исходные файлы плагина (без установленных модулей node_modules и esm директории):

superset-plugin-chart-kpi-cards
│
├── src
│     ├── images
│     │     └── thumbnail.png
│     ├── plugin
│     │     ├── buildQuery.ts
│     │     ├── controlPanel.ts
│     │     ├── index.ts
│     │     └── transformProps.ts
│     ├── index.ts
│     ├── SupersetPluginChartKpiCards.tsx
│     └── types.ts
│
├── test
│     ├── index.test.ts
│     ├── __mocks__
│     │     └── mockExportString.js
│     └── plugin
│         ├── buildQuery.test.ts
│         └── transformProps.test.ts
├── types
│     └── external.d.ts
│
├── babel.config.js
├── jest.config.js
├── package.json
├── package-lock.json
├── README.md
└── tsconfig.json

При создании нового типа диаграммы необходимо обновить следующие файлы:

  • src/types.ts: типы, которые использует ваш плагин
  • src/SupersetPluginChartKpiCards.tsx фактический код плагина
  • src/plugin/buildQuery.ts: перехватчик, создающий полезную нагрузку запроса данных диаграммы. Обычно вы можете оставить это без изменений и начать настраивать позже, когда ваш плагин станет более сложным.
  • src/plugin/transformProps.ts: перехватчик, который получает данные от бэкэнда и возвращает окончательные данные, переданные в плагин (в этом примере SupersetPluginChartKpiCards.tsx)

Кроме того, обычно вам потребуется предоставить миниатюру (картинку) и несколько примеров снимков экрана (как выглядит плагин с данными).

Ооочень упрощенная схема компонентов плагина

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

Основная цель упрощенной схемы показать взаимосвязи, что и куда идет.

superset-plugin-chart-kpi-cards/src/plugin/buildQuery.ts

Функция buildQuery используется для создания экземпляра QueryContext, который отправляется в chart data endpoint. Помимо информации о том, какой источник данных использовать, он определяет тип (например, full payload, samples, query) и формат (например, CSV или JSON) результата, а также следует ли принудительно обновлять данные из источника данных, а не использовать кэшированную копию данных, если таковая имеется.

Что еще более важно, QueryContext содержит свойство `queries`, которое представляет собой массив объектов QueryObjects, определяющих отдельные запросы данных, которые необходимо выполнить.

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

superset-plugin-chart-kpi-cards/src/plugin/controlPanel.ts

Панель управления (control panel) разделена на две вкладки:

  • Запрос (Query)
  • Параметры диаграммы (Chart Options)

Элементы управления, определяющие входные данные для запроса данных диаграммы, такие как столбцы и показатели, обычно находятся в разделе «Запрос», а элементы управления, влияющие на внешний вид или функциональность диаграммы, находятся в разделе «Параметры диаграммы» (фактически, это настройки шрифтов, цвета, подписи и т.п.).

Существует несколько предопределенных элементов управления, которые можно использовать.

Некоторые примеры:

  • groupby: столбцы для группировки (эти элементы будут размещены в GROUP BY)
  • series: то же, что и groupby, но можно выбрать только одно измерение
  • metrics: можно указать несколько метрик
  • metric: можно выбрать только одну метрику
  • adhoc_filters: фильтры (переводятся в WHERE или HAVING в зависимости от типа фильтра)
  • row_limit: максимальное количество строк (переведено в оператор LIMIT)

Если на панели управления есть элементы управления «series» и «groupby», и пользователь выбрал «col1» в качестве значения для элемента управления «series», а «col2» и «col3» в качестве значений для элемента управления «groupby», то результирующий запрос будет содержать три столбца groupby. Это связано с тем, что мы считали, что `series` управляет полем запроса `groupby`, и его значение автоматически добавляет поле `groupby` при создании запроса.

Также можно определить собственные элементы управления, импортировав необходимые зависимости и переопределив параметры по умолчанию, которые затем можно поместить в раздел controlSetRows раздела Query вместо предопределенного элемента управления.

Пример:

import { validateNonEmpty } from '@superset-ui/core';
import {
  sharedControls,
  ControlConfig,
  ControlPanelConfig,
} from '@superset-ui/chart-controls';

const myControl: ControlConfig<'SelectControl'> = {
  name: 'secondary_entity',
  config: {
    ...sharedControls.entity,
    type: 'SelectControl',
    label: t('Secondary Entity'),
    mapStateToProps: state => ({
      sharedControls.columnChoices(state.datasource)
      .columns.filter(c => c.groupby)
    })
    validators: [validateNonEmpty],
  },
}

В дополнение к базовому раскрывающемуся элементу управления существует несколько предопределенных типов элементов управления (можно установить через свойство type), которые можно использовать.

Примеры некоторых часто используемых Dropdown разделов:

  • SelectControl: раскрывающийся список для выбора одного или нескольких значений, обычно столбцов.
  • MetricsControl: раскрывающийся список для выбора показателей, активирующий модальное окно для определения деталей показателя.
  • AdhocFilterControl: элемент управления для выбора фильтров.
  • CheckboxControl: флажок для выбора значений true/false.
  • SliderControl: ползунок с минимальными/максимальными значениями.
  • TextControl: управление текстовыми данными (text data).

Чтобы узнать больше о типах входных данных управления, откройте этот файл: superset-frontend/src/explore/comComponents/controls/index.js.

Чтобы убедиться, что все элементы управления заполнены правильно, @superset-ui/core/lib/validator предоставляет следующие валидаторы:

  • validateNonEmpty: должно иметь хотя бы одно значение
  • validateInteger: должно быть целочисленным значением
  • validateNumber: должно быть целым или десятичным значением

Типы входных данных управления см. в разделе superset-frontend/src/explore/components/controls/index.js

superset-plugin-chart-kpi-cards/src/plugin/index.ts

Конструктор используется для передачи соответствующих метаданных и callbacks (обратных вызовов), которые регистрируются в соответствующих реестрах, которые используются во всей библиотеке и приложении. Более подробное описание каждого свойства приведено в соответствующем импортированном файле.

Стоит отметить, что `buildQuery` является необязательным и необходим только для расширенных визуализаций, требующих либо операций постобработки (поворот, скользящие агрегаты, сортировка и т.д.), либо отправки нескольких запросов.

superset-plugin-chart-kpi-cards/src/plugin/transformProps.ts

Функция TransformProps вызывается после получения успешного ответа от chart data endpoint и используется для преобразования входящих данных перед отправкой в визуализацию. Фактически это этап постобработки полученных данных из источника (например, с помощью SQL из базы данных).

Функция TransformProps также весьма полезна для возврата дополнительных/измененных props в ваш компонент визуализации данных. Доступ к formData также можно получить из файла SupersetPluginChartKpiCards.tsx, но предоставление здесь custom props часто бывает удобно для интеграции сторонних библиотек, которые полагаются на определенные props.

Описание свойств в `chartProps`:

  • height, width: высота/ширина элемента DOM, в котором находится диаграмма.
  • formData: полезные данные запроса данных диаграммы, которые были отправлены на серверную часть.
  • queriesData: полезная нагрузка ответа на данные диаграммы, полученная от серверной части. Некоторые свойства queriesData:
    • data: массив с данными, каждая строка с объектом, сопоставляющим столбец/псевдоним с его значением. Пример: [{ col1: 'abc', metric1: 10 }, { col1: 'xyz', metric1: 20 }]
    • rowcount: количество строк в `данных`
    • query: отправленный запрос в базу данных (может пригодиться для отладки)

Обратите внимание: функция TransformProps кэшируется при загрузке приложения. При внесении изменений в функцию TransformProps во время разработки с горячей перезагрузкой изменения не будут видны до перезапуска сервера разработки.

superset-plugin-chart-kpi-cards/src/types.ts

Файл types.ts обычно содержит определения типов, интерфейсы или код, связанный с типами. Он содержит определения типов, константы, псевдонимы типов, аннотации типов и т.д. Конкретное содержимое файла types.ts зависит от требований вашего плагина.

Когда .ts файл импортируется из пакета npm (хранящегося локально в node_modules), он ищет определения типов в src/types.ts.

✅ 🤓 Что и где почитать/посмотреть про разработку плагинов или посмотреть реализованные примеры?

Для начинающих в React и TypeScript (YouTube)

TypeScript за 5 минут для знающих Javascript

Статья про интерфейсы в TypeScript

Что такое React js. Обзор возможностей для начинающих

React и TypeScript — Быстрый Курс

Рекомендации по разработке Custom Plugin Viz Apache Superset

Полезные расширения для браузера при разработке в React

Описание последовательности разработки Visualization Plugin for Apache Superset

todo

Билдим плагин и пушим собранный плагин в npmjs.com

После того, как плагин разработан, проверена его функциональность на dev сервере Superset, его необходимо сбилдить и отправить пакет в npm package registry.

Для того, чтобы сбилдить наш плагин, необходимо запустить следующие команды:

npm ci
npm run build

Если на этапе npm run build у вас возникает ошибки на этапе тестирования (запуск скрипта test/index.test.ts):

пример текста ошибки:

console.warn
      You should call configure(...) before calling other methods

В таком случае можно в package.json удалить строку:

"postbuild": "npm run test",

Без этой строки не будет запускаться этап автотестов для плагина (их нужно написать отдельно). В этой статье я точно не буду описывать тестирование плагинов. Да и к тому же, если вы не планируете плагины контрибьютить в основной код суперсета, то достаточно будет ручных тестов в вашей организации. На начальном этапе написать еще тесты будет непросто.

После того, как отключили npm run test, запускаем еще раз билд. Должны получить следующий успешный результат:

В результате build появляются 2 папки esm и lib:

Вариант 1. Публикация пакета Superset Plugin в npm package registry на сайте npmjs.com

Внутри плагина отправляем команду

npm login

Получим сообщение «Нажмите Enter» для прохождения авторизации через браузер:

после авторизации в окне браузера, в консоле получим сообщение:

Logged in on https://registry.npmjs.org/.

Далее делаем инициализацию:

npm init

Результат:

~/plugins/superset-plugin-chart-kpi-cards$ npm init
This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

See `npm help init` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.json file.

Press ^C at any time to quit.
package name: (superset-plugin-chart-kpi-cards) 
version: (0.1.0) 
git repository: 
keywords: superset
license: (Apache-2.0) 
About to write to /home/username/plugins/superset-plugin-chart-kpi-cards/package.json:

{
  "name": "superset-plugin-chart-kpi-cards",
  "version": "0.1.0",
  "description": "Superset Plugin Chart Kpi Cards",
  "sideEffects": false,
  "main": "lib/index.js",
  "module": "esm/index.js",
  "files": [
    "esm",
    "lib"
  ],
  "private": true,
  "scripts": {
    "build": "npm run build-cjs && npm run build-esm && npm run ts-types",
    "build-cjs": "babel src --extensions \".ts,.tsx,.js,.jsx\" --copy-files --out-dir lib",
    "build-clean": "npm run clean && npm run build",
    "build-esm": "BABEL_OUTPUT=esm babel src --extensions \".ts,.tsx,.js,.jsx\" --copy-files --out-dir esm",
    "dev": "BABEL_OUTPUT=esm babel src --extensions \".ts,.tsx,.js,.jsx\" --watch --copy-files --out-dir esm",
    "prebuild": "rimraf {lib,esm,tsconfig.tsbuildinfo}",
    "ts-types": "tsc --build",
    "test": "jest"
  },
  "author": "My Name",
  "license": "Apache-2.0",
  "publishConfig": {
    "access": "public"
  },
  "peerDependencies": {
    "@airbnb/config-babel": "^2.0.1",
    "@superset-ui/chart-controls": "*",
    "@superset-ui/core": "*",
    "react": "^16.13.1"
  },
  "devDependencies": {
    "@babel/cli": "^7.16.0",
    "@types/jest": "^26.0.4",
    "jest": "^26.6.3",
    "rimraf": "^3.0.2",
    "typescript": "^4.1.2"
  },
  "types": "./lib/index.d.ts",
  "directories": {
    "lib": "lib",
    "test": "test"
  },
  "keywords": [
    "superset"
  ]
}


Is this OK? (yes) yes

При запуске команды

npm publish --access public

выдает ошибку:

npm ERR! This package has been marked as private
npm ERR! Remove the 'private' field from the package.json to publish it.

Поэтому в package.json удаляем строку:

"private": true,

После этого плагин будет опубликован в npmjs в разделе packages:

Если перейти в плагин и нажать на вкладку code, то вы увидите структуру опубликованного плагина:

То есть, исходный код плагина не публикуется, его нужно отдельно хранить в репозитории git (например, github или gitlab).

Если вы скачаете чей-то пакет из npm, то вы не сможете внести изменений в код плагина. Нужен именно не сбилденные исходники плагина, для того, чтобы вносить изменения в код.

Ссылка на мой опубликованный плагин:

https://www.npmjs.com/package/superset-plugin-chart-kpi-cards

Добавляем плагин в официальный образ (image) Apache Superset

Создаем отдельный проект для сборки образа

Например, я у себя создаю проект на гитхабе

superset-build-image

В нем создаю директорию superset_3_1_2, в которую копирую superset-frontend из официального репозитория superset/superset-frontend/ с включенным тегом 3.1.2.

Создаю файл /superset-build-image/Dockerfile_3_1_2.

Создаю директорию requirements, в которую помещу файл requirements-local.txt

Получается такая структура:

Подготовка к сборке образа custom_superset_3_1_2

Добавляем в файл /superset-build-image/superset_3_1_2/superset-frontend/package.json строчки:

"superset-plugin-chart-kpi-cards": "^0.1.0"

В директории /superset-build-image/superset_3_1_2/superset-frontend для обновления файла package-lock.json запускаем команду:

npm install --package-lock-only

Вручную файл package-lock.json обновить не получится, т.к. там не в одно место нужно внести изменения. Пример результата, который получился после обновления:

Меняем файл MainPreset.js

В файл /superset-build-image/superset_3_1_2/superset-frontend/src/visualizations/presets/MainPreset.js нужно внести строчки.

Сначала строку:

import { SupersetPluginChartKpiCards } from 'superset-plugin-chart-kpi-cards';

Затем ниже:

new SupersetPluginChartKpiCards().configure({
  key: 'superset-plugin-chart-kpi-cards',
}),

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

Создаем файл Dockerfile_3_1_2

Код Dockerfile:

######################################################################
# Official Superset image
######################################################################
FROM apachesuperset.docker.scarf.sh/apache/superset:3.1.2 AS superset-official

######################################################################
# Node stage to deal with static asset construction
######################################################################
# if BUILDPLATFORM is null, set it to 'amd64' (or leave as is otherwise).
ARG BUILDPLATFORM=${BUILDPLATFORM:-amd64}
FROM --platform=${BUILDPLATFORM} node:16-bookworm-slim AS superset-node


ARG NPM_BUILD_CMD="build"
ENV BUILD_CMD=${NPM_BUILD_CMD}
ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true

# NPM ci first, as to NOT invalidate previous steps except for when package.json changes
RUN mkdir -p /app/superset-frontend

WORKDIR /app/superset-frontend/

COPY superset_3_1_2/superset-frontend/package*.json ./
RUN npm ci

# Копируем всю директорию superset-frontend для пересборки
COPY ./superset_3_1_2/superset-frontend .

# This seems to be the most expensive step
RUN npm run ${BUILD_CMD} \
    && rm -rf node_modules

######################################################################
# Final image
######################################################################
FROM superset-official AS superset-bi

# Копируем статические ресурсы (assets) из каталога /app/superset/static/assets
# в образ Docker, используемый для запуска веб-приложения Superset
COPY --from=superset-node /app/superset/static/assets /app/superset/static/assets

######################################################################
# Install Drivers for Clickhouse
######################################################################
USER root

COPY ./superset_3_1_2/requirements/requirements-local.txt /app/requirements/

# Cache everything for dev purposes...
RUN cd /app \
    && pip install --no-cache -r requirements/requirements-local.txt

USER superset

Собираем образ Superset с плагином

sudo docker build -f Dockerfile_3_1_2 --force-rm -t custom_superset:3.1.2 .

Иллюстрация запуска сборки:

Весь код примера сборки образа Superset с плагином на GitHub

https://github.com/superset-bi/superset-build-image — Как сбилдить образ суперсета с плагином из npmjs репозитория. Dockerfile для сборки образа для версии 3.1.2 и выше

Tags:
Ivan Shamaev (Admin)
Ivan Shamaev (Admin)
View More Posts
Работаю с Apache Superset с 2021 года. Веду этот блог, чтобы систематизировать свои знания и поделиться ими с другими специалистами. Подписывайтесь на мой телеграм канал @apache_superset_bi
Senior BI Developer
3
0
Оставьте комментарий! Напишите, что думаете по поводу статьи.x