Apache Superset se révèle être un formidable outil de Business Intelligence: open source, riche en fonctionnalités (multitude de charts, intégration avec plusieurs SGBD, …) et qui n’a rien à envier aux alternatives commerciales les plus connues (Tableau, PowerBI, BusinessObjects et consorts).
Formidable ne veut malheureusement pas dire qu’il est exempt de défauts, notamment sa documentation qui pourra paraître un peu frugale à certains.
C’est justement pour palier à ce manque que je vous propose de voir ensemble comment mettre en place rapidement une instance de Superset taillée pour la production.
Prérequis
- Disposer d’un serveur de production sous linux (peu importe la distribution) avec:
- docker
- git
- caddy (ou autre reverse proxy de votre choix)
- les ports 443 et 80 ouverts au niveau du firewall
- Un nom de domaine (par exemple
bi.myawesomecompany.com) qui pointe vers votre serveur
Installation
Clonage du repo superset
Commencez par faire un git clone du repo directement sur votre serveur de prod (oui ça n’est pas commun):
cd $HOME
git clone https://github.com/apache/superset.git
cd superset
Puis sélectionnez la version souhaitée via son tag.
git checkout tags/3.0.0
Édition des fichiers de configuration
Arrive l’étape de customisation de certains fichiers de configuration. Comme vous êtes sur un tag git, vous ne pourrez pas commiter vos modifications en l’état, vous aurez donc le choix de:
- documenter toutes vos modifications pour les reproduire à l’identique en cas de réinstallation
- ou forker le projet et créer une branche pour commiter vos modifications
A vous de voir.
Le fichier docker/.env-non-dev (comprendre ici: non-dev = prod) permet de définir un ensemble de variables d’environnement qui seront utilisées par les containers dockers que nous démarrerons par la suite.
Ajoutez-y ceci:
# On ne veut pas de données de démonstration en prod
SUPERSET_LOAD_EXAMPLES=no
# Une chaîne de caractère aléatoire pour encoder les cookies de session
SUPERSET_SECRET_KEY=4Sido8BkIjs54Vz2XyVD5GJIvANVIAT399dRESjdmr4vm92n
# Pour prévenir les attaques de type XSS (entre autre)
TALISMAN_ENABLED=yes
# Nombre de workers: plus la valeur est élevée, moins vous aurez d'échecs intermittents de refresh de charts dans vos dashboards (à ajuster selon la puissance de votre serveur).
SERVER_WORKER_AMOUNT=64
Effectuez aussi quelques retouches dans docker/pythonpath_dev/superset_config.py pour activer l’alerting et le moteur de template (nécessaire pour créer des datasets avec filtrage dynamique):
FEATURE_FLAGS = {"ALERT_REPORTS": True, "ENABLE_TEMPLATE_PROCESSING": True}
Désactivez la télémétrie en remplaçant dans le fichier docker-compose-non-dev.yml:
x-superset-image: &superset-image apachesuperset.docker.scarf.sh/apache/superset:${TAG:-latest-dev}
par
x-superset-image: &superset-image apache/superset:${TAG:-latest-dev}
Et passez sur la dernière version stable de postgresql en remplaçant:
image: postgres:14
par
image: postgres:16
Démarrage
Instanciez et démarrez les conteneurs docker:
docker compose -f docker-compose-non-dev.yml up -d
Superset est donc accessible sur votre serveur de prod via http://127.0.0.1:8088.
Reverse proxy
Configurez un reverse proxy pour sécuriser la connexion, exemple avec caddy:
Editer /etc/caddy/Caddyfile
bi.myawesomecompany.com {
reverse_proxy http://127.0.0.1:8088
}
Puis redémarrez caddy.
sudo service caddy restart
Première connexion
Connectez vous à https://bi.myawesomecompany.com avec le nom d’utilisateur / mot de passe: admin / admin
Changez votre mot de passe.
Sauvegarde et restauration
Qui dit prod, dit sauvegarde !
Lors de l’édition du fichier de configuration docker-compose-non-dev.yml, vous aurez sans-doute remarqué qu’on instancie une base de données postgresql.
Pour faire la sauvegarde/restauration de superset il n’y a que cette base à prendre en compte.
La sauvegarde peut donc se faire à chaud via un simple:
docker exec -t superset_db pg_dump superset -U superset | xz > backup.sql.xz
Pour la restauration, on ne démarrera au préalable QUE le conteneur postgresql, évitant ainsi d’avoir une instance superset branchée sur une base de données en cours de restauration:
docker compose down
docker compose -f docker-compose-non-dev.yml up db -d
docker exec -t superset_db dropdb -U superset superset
docker exec -t superset_db createdb -U superset superset
xz -dc backup.sql.xz | docker exec -i superset_db psql -U superset -d superset
docker compose -f docker-compose-non-dev.yml up -d