Déploiement Docker

Drovio Server peut être déployé en conteneur Docker. Nous fournissons pour cela deux images distinctes :

• Tout-en-un : destinée avant tout à l'essai et à la préproduction. Elle contient les fonctionnalités essentielles de Drovio Server. Toutes les dépendances sont embarquées et configurées automatiquement au démarrage du conteneur.
• Production : réservée aux environnements de production. Drovio Server s'appuie sur une base gérée par Docker ou externe, et sur le magasin de sessions interne ou sur un magasin Redis géré par Docker ou externe.

Image Docker	Tout-en-un	Production
Usage	Test et préproduction	Production
Base	Debian 13 (Trixie) slim	Debian 13 (Trixie) slim
Base PostgreSQL	Base PostgreSQL interne	Base PostgreSQL gérée par Docker ou externe, 14 et supérieur
Magasin de sessions	Magasin interne	Magasin interne, ou magasin Redis géré par Docker ou externe
Tourne sous	root	drovio, uid 1000

Composants gérés par Docker ou externes

Le terme géré par Docker désigne un composant de Drovio Server piloté par le plugin docker compose et vivant sur le même réseau Docker. Les composants externes sont au contraire totalement indépendants : vous devez alors fournir leurs informations de connexion par les variables d'environnement correspondantes.

Les deux images sont multi-architectures : linux/amd64 et linux/arm64 sont servies sous le même nom, et Docker retient celle qui correspond à votre machine. Il n'y a aucune option --platform à passer, ni de nom d'image propre à une architecture.

Prérequis

• Docker Engine 20.10 ou supérieur, pour la prise en charge des images multi-architectures.
• Le plugin docker compose 2.20 ou supérieur pour l'image de production, qui utilise les profils et les dépendances facultatives.

Obtenir les images

Les images sont publiées sur notre registre privé. Demandez les identifiants de votre organisation à support@drovio.com : vous recevrez un nom d'utilisateur et un jeton, tous deux propres à vous et révocables.

Image	Référence
Tout-en-un	registry.gitlab.com/drovio/drovio-server-aio
Production	registry.gitlab.com/drovio/drovio-server

docker login registry.gitlab.com -u <username> -p <token>
docker pull registry.gitlab.com/drovio/drovio-server:3.6.9

Quelle étiquette utiliser

Étiquette	Désigne
3.6.9	cette version exacte, et ne bouge jamais
3.6	le dernier correctif de la série 3.6
latest, stable	la dernière version publiée

Figez une version complète en production. Les étiquettes mouvantes rendent service pour un essai, mais elles font qu'un docker compose pull peut amener une nouvelle version mineure sans que vous l'ayez décidé.

Accès réseau sortant

Votre pare-feu doit autoriser registry.gitlab.com ainsi que le domaine de stockage objet d'où les couches d'image sont téléchargées. Un docker login qui réussit suivi d'un docker pull qui s'enlise vient presque toujours de là.

Installation hors ligne

Si vos serveurs n'ont aucun accès sortant, nous livrons également chaque version sous forme d'archive, une par architecture. Demandez-la au support puis chargez-la sur la machine cible :

docker load -i docker-drovio-server-amd64-3.6.9.tar.gz

L'image ainsi chargée porte les mêmes nom et étiquette que celle du registre : la suite de cette page s'applique donc telle quelle.

Gestion des données persistantes

Conformément aux principes de Docker, les données stockées dans un conteneur sont éphémères et ne survivent pas à sa destruction. Il existe toutefois des mécanismes pour les données persistantes, dont les montages liés, qui projettent un fichier ou un dossier du système hôte à l'intérieur du conteneur.

Nos images Docker s'appuient sur des montages liés pour trois types de données persistantes :

Données	Chemin dans le conteneur	Concerne
Fichiers de configuration	/etc/drovio-server	les deux images
Fichiers de journal	/var/log/drovio-server	les deux images
Données de la base	/opt/drovio-server/data	l'image tout-en-un

L'image de production n'embarque aucune base. Elle n'a besoin que des deux premiers. L'emplacement de ses données relève de la base vers laquelle vous la pointez, qu'il s'agisse de celle que docker compose démarre pour vous ou de votre propre serveur.

Le secret JWT vit dans le dossier de configuration

Au premier démarrage, le conteneur écrit dans settings.conf un secret JWT qui lui est propre. Ce secret signe les sessions des utilisateurs. Supprimer ce dossier, c'est perdre le secret : chaque utilisateur devra se reconnecter.

Propriétaire des dossiers, image de production

L'image de production tourne sous l'utilisateur non privilégié drovio, uid et gid 1000. Les deux dossiers dans lesquels elle écrit doivent lui appartenir :

mkdir -p config logs
sudo chown -R 1000:1000 config logs

Sans cela le conteneur refuse de démarrer, en indiquant quel dossier corriger.

Ne faites jamais cela sur le dossier de la base

data/postgresql appartient au conteneur de base de données, qui tourne sous son propre utilisateur. Le confier à l'uid 1000 empêche PostgreSQL de démarrer, sur une erreur de permission portant sur ses propres fichiers.

Montée depuis la 3.6.5 ou antérieure

Les versions précédentes de cette image tournaient sous root. Les dossiers qu'elles ont créés sur votre hôte appartiennent donc à root. Lancez la commande chown ci-dessus sur vos dossiers config et logs existants avant de démarrer la nouvelle image.

Rien n'est écrit en dehors de ces deux chemins et du dossier de travail de Vert.x sous /tmp. Le conteneur peut d'ailleurs tourner avec un système de fichiers racine en lecture seule :

docker run --read-only --tmpfs /tmp ...

Déployer l'image tout-en-un

Créez un dossier drovio-server et placez-vous dedans :

mkdir drovio-server
cd drovio-server

Créez un volume pour la base embarquée, puis lancez le conteneur :

docker volume create drovio-data

docker run --hostname drovio.example.com \
  -p 8090:8090 \
  -v "./config:/etc/drovio-server" \
  -v "./logs:/var/log/drovio-server" \
  -v "drovio-data:/opt/drovio-server/data" \
  --rm -it "registry.gitlab.com/drovio/drovio-server-aio:3.6.9"

Utilisez un volume pour la base, pas un montage lié

PostgreSQL vérifie que son dossier de données appartient à l'utilisateur postgres. Or Docker Desktop, sous macOS comme sous Windows, présente tout ce qui se trouve dans un montage lié comme appartenant à root, quoi que vous fassiez. Le conteneur ne peut pas démarrer ainsi. Un volume nommé n'a pas cette limite, et c'est de toute façon la manière recommandée de conserver des données de base. La configuration et les journaux ne sont pas concernés et peuvent rester en montages liés.

Option	Description
--hostname	Fixe un nom d'hôte précis. Vous devrez ensuite nous le communiquer pour que nous générions vos licences. Conservez toujours le même, les licences y étant liées.
-p <hôte>:<conteneur>	Publie le port du conteneur sur le port de l'hôte. Le port 8090 est utilisé ici, Drovio Server n'activant pas TLS et tout le trafic HTTP passant par ce port par défaut.
-v "<hôte>:<conteneur>"	Montages liés pour les données persistantes décrites plus haut.
--rm	Supprime automatiquement le conteneur à son arrêt.
-it	Alloue un pseudo-terminal relié à l'entrée standard du conteneur.

Le nom d'hôte n'est écrit qu'une fois

À son tout premier démarrage, le serveur inscrit dans sa configuration sa propre URL, construite à partir du nom d'hôte que vous lui donnez. Elle n'est pas recalculée ensuite, et vos licences y sont liées. Un conteneur démarré sans --hostname refuserait de fonctionner.

Renseignez plutôt APP_URL si l'URL par laquelle vos utilisateurs accèdent au serveur diffère du nom d'hôte du conteneur, derrière un proxy inverse par exemple.

Déployer l'image de production

L'image de production se déploie avec le plugin docker compose, l'outil qui sert à définir et à lancer des applications Docker multi-conteneurs.

Récupérer les fichiers de déploiement

Tout ce dont vous avez besoin pour déployer se trouve dans l'image elle-même. Extrayez-le à l'endroit où vous voulez faire tourner le serveur, avec les identifiants qui vous ont servi à la récupérer :

id=$(docker create registry.gitlab.com/drovio/drovio-server:3.6.9)
docker cp "$id:/opt/drovio-server/bundle/." ./drovio-server
docker rm "$id"
cd drovio-server

Vous obtenez trois fichiers, tous accordés à la version que vous venez de récupérer :

Fichier	Ce que c'est
docker-compose.yml	le déploiement, avec ou sans base et magasin de sessions gérés
env.example	les réglages que vous devez renseigner
drovio-server.sql	le schéma de la base, utilisé à sa création et lors des mises à jour

Sa ligne image: désigne déjà la version exacte dont vous l'avez extrait.

Réglages

Copiez env.example en .env et renseignez-le. Deux valeurs sont obligatoires :

DROVIO_HOSTNAME=drovio.example.com
DB_PASSWORD=<generate one>

Générez les mots de passe plutôt que d'en réutiliser un, par exemple avec openssl rand -base64 24. DROVIO_HOSTNAME suit la même règle que --hostname plus haut : il n'est inscrit dans l'URL du serveur qu'au premier démarrage.

Composants gérés par Docker ou externes

Le choix entre une base et un magasin de sessions gérés ici ou fournis par vous se fait au démarrage, par les profils. Le même docker-compose.yml couvre les trois cas :

Commande	Ce que cela lance
docker compose --profile bundled-db up	PostgreSQL géré par docker compose, magasin de sessions interne
docker compose --profile bundled-db --profile redis up	idem, avec un magasin de sessions Redis géré par docker compose
docker compose up	base externe, renseignez DB_HOST et les variables associées dans .env

Avec le profil redis, décommentez également SS_TYPE, SS_REDIS_CONNECTION_STRINGS, SS_REDIS_MASTER_NAME et SS_REDIS_PASSWORD dans votre .env.

• Composants gérés par Docker : pilotés par le plugin docker compose. Tous les conteneurs suivent le même cycle de vie et partagent le même réseau Docker.
• Composants externes : ils ne sont pas déclarés dans le fichier docker-compose. Leurs informations de connexion doivent être transmises par les variables d'environnement prévues à cet effet. Au premier démarrage, le fichier de configuration de Drovio Server n'existe pas et est créé avec des valeurs par défaut. Ces variables servent alors à en remplacer certaines, ce qui permet un premier démarrage réussi.

Vérifier que le serveur répond

Les deux images exposent un point de contrôle de santé et déclarent un HEALTHCHECK Docker qui s'en sert. docker ps affiche le conteneur comme healthy dès que le serveur répond.

curl -f http://drovio.example.com:8090/healthcheck

Variables d'environnement

Variable d'environnement	Champ de configuration
APP_URL	.http.url
SS_TYPE	.http.session_store.type
SS_REDIS_CONNECTION_STRINGS	.http.session_store.redis.connections
SS_REDIS_MASTER_NAME	.http.session_store.redis.master
SS_REDIS_PASSWORD	.http.session_store.redis.password
DB_HOST	.database.host
DB_PORT	.database.port
DB_NAME	.database.database
DB_USER	.database.user
DB_PASSWORD	.database.password
DB_MAIN_POOL_SIZE	.database.pool_options.main.max_size
DB_LICENSING_POOL_SIZE	.database.pool_options.licensing.max_size
DB_MAIN_IDLE_TIMEOUT	.database.pool_options.main.idle_timeout
DB_LICENSING_IDLE_TIMEOUT	.database.pool_options.licensing.idle_timeout
DB_MAIN_CONNECT_TIMEOUT	.database.pool_options.main.connect_timeout
DB_LICENSING_CONNECT_TIMEOUT	.database.pool_options.licensing.connect_timeout
DB_POOL_SIZE (deprecated)	.database.pool_options.main.max_size
DB_NV_POOL_SIZE (deprecated)	.database.pool_options.licensing.max_size
DB_IDLE_TIMEOUT (deprecated)	.database.pool_options.main.idle_timeout

Les variables d'environnement l'emportent toujours

Ces variables écrasent systématiquement les valeurs du fichier de configuration de Drovio Server au démarrage. Si vous modifiez dans les fichiers de configuration une valeur associée à l'une d'elles, vous devez aussi retirer cette variable du fichier docker-compose ou mettre sa valeur à jour avant de redémarrer Drovio Server.

Mettre à jour

Récupérez la version voulue, puis recréez les conteneurs. Votre configuration, vos journaux et votre base vivent dans les montages liés et ne sont pas touchés.

docker compose pull
docker compose --profile bundled-db up -d

Mettre à jour le schéma de la base de données

Une nouvelle version peut ajouter des tables ou des colonnes. Les deux images ne traitent pas ce point de la même façon.

Image	Ce qui applique les évolutions de schéma
Tout-en-un	le conteneur lui-même, à chaque démarrage. Rien à faire.
Production	vous, avant de démarrer la nouvelle image.

L'image de production ne touche jamais à votre schéma. drovio-server.sql n'est exécuté qu'à la création de la base, par le conteneur de base de docker compose à son tout premier démarrage, ou par vous sur votre propre serveur. Il n'est pas rejoué ensuite.

Lors d'une montée de version de l'image de production :

1. Extrayez drovio-server.sql de l'image vers laquelle vous montez, comme pour une première installation. Le script livré dans une image est toujours celui que cette image attend.

   id=$(docker create registry.gitlab.com/drovio/drovio-server:3.6.9)
   docker cp "$id:/opt/drovio-server/bundle/drovio-server.sql" .
   docker rm "$id"
   

2. Appliquez-le à votre base, les conteneurs Drovio Server étant arrêtés.

   psql -h my-database.example.com -U drovio -d drovio -f drovio-server.sql
   

3. Démarrez la nouvelle image.

Le script est écrit pour être rejoué : il crée ce qui manque et laisse le reste en place, si bien que l'appliquer à une base déjà à jour ne change rien.

Sauvegardez d'abord

Faites une sauvegarde de la base avant d'appliquer un script de schéma, quel que soit l'écart de version. C'est la seule étape de cette procédure qui ne se rattrape pas.

Tout-en-un et versions majeures de PostgreSQL

L'image tout-en-un ne met pas à niveau son cluster de base de données sur place. Si une nouvelle version embarque une version majeure de PostgreSQL plus récente, le conteneur s'arrête au démarrage avec un message explicatif. Exportez vos données depuis l'image précédente avec pg_dumpall, puis restaurez-les dans un volume neuf avec la nouvelle.

Migrer depuis l'image production v3.6.5 ou antérieure

Les déploiements production antérieurs à la 3.6.6 ne pouvaient être chargés que depuis une archive, et tournaient en root. Les mettre à jour et les basculer vers le registre ne se fait qu'une fois, mais l'ordre indiqué ci-dessous a son importance.

1. Sauvegardez votre base de données. La dernière étape de cette procédure est la seule qui ne puisse pas être annulée.

2. Changez les droits des deux répertoires dans lesquels le serveur écrit, et uniquement ceux-là. Ils ont été créés par un conteneur tournant en root, et la nouvelle image tourne en uid 1000.

   sudo chown -R 1000:1000 config logs
   

   Pas le dossier entier

   Ne lancez pas cette commande sur l'ensemble de votre répertoire de déploiement. data/postgresql appartient au conteneur de base de données, qui tourne sous son propre utilisateur, et le passer à l'uid 1000 empêche PostgreSQL de démarrer.

3. Pointez vers le registre. Remplacez la ligne image: de votre docker-compose.yml, ou repartez du lot embarqué dans la nouvelle image. Le suffixe d'architecture disparaît : un déploiement arm64 qui référençait drovio/drovio-server-arm64 doit désormais utiliser drovio/drovio-server.

   image: 'registry.gitlab.com/drovio/drovio-server:3.6.9'
   

4. Conservez le mot de passe de votre base. Si vous utilisez le docker-compose.yml embarqué et son fichier .env, DB_PASSWORD doit reprendre le mot de passe que votre base utilise déjà, celui inscrit dans votre fichier compose actuel. Un mot de passe fraîchement généré laisserait le serveur incapable de se connecter.

5. Démarrez la nouvelle image, et vérifiez qu'elle se lance avant d'aller plus loin.

6. Appliquez le script de schéma si vous changez aussi de version, comme décrit plus haut.

Rien d'autre n'est réécrit

L'URL de votre serveur et les licences qui y sont liées sont lues dans la configuration que vous avez déjà. Les règles concernant --hostname ne s'appliquent qu'à un premier démarrage. Un déploiement existant n'est pas concerné.

Tant que vous n'avez pas franchi l'étape 6, le retour arrière consiste à remettre l'ancienne ligne image:, à condition d'avoir conservé l'archive chargée à l'origine.

Migrer depuis une installation Windows ou par paquet Linux

Si vous avez installé Drovio Server sous Windows ou à l'aide du paquet Linux correspondant à votre distribution, et que vous souhaitez basculer vers notre image Docker de production, deux éléments seulement sont à transférer : la base de données et le répertoire de configuration. Rien d'autre n'est à recréer, la migration est simple.

Trois choses à savoir avant de commencer

L'URL de votre serveur doit survivre. Vos licences sont liées à cette URL, donc à ce nom d'hôte.

Votre secret JWT doit survivre lui aussi, faute de quoi les sessions des utilisateurs connectés seraient invalidées.

Les variables de .env sont appliquées à chaque démarrage, pas seulement au premier. C'est ainsi que vous pointez votre configuration existante vers une nouvelle base sans l'éditer à la main.

1. Sauvegardez la base et l'intégralité du répertoire de configuration. La restauration de l'étape 7 est la seule de cette procédure qui soit irréversible.

2. Arrêtez le service.

   LinuxWindows

   systemctl stop drovio-server
   

   sc stop drovio-server
   

3. Exportez la base. L'hôte, le nom et l'utilisateur figurent dans la section database de votre settings.conf.

   pg_dump -h localhost -U drovio -d drovio -Fc -f drovio.dump
   

4. Récupérez les fichiers de déploiement comme pour une première installation, puis copiez env.example vers .env.

5. Apportez votre configuration. Copiez settings.conf et admin.properties dans le répertoire config, à côté de docker-compose.yml, ainsi que tout fichier qu'ils désignent : magasin de clés TLS, magasin SAML, autorité de certification LDAP.

   LinuxWindows

   Les chemins contenus dans settings.conf correspondent déjà à ce qu'attend le conteneur, les deux étant /etc/drovio-server. Rien à réécrire.

   Chaque chemin absolu contenu dans settings.conf est à réécrire, de C:\ProgramData\Drovio\Drovio Server\... vers /etc/drovio-server/.... Selon ce que vous utilisez, cela peut concerner http.keystore, users.auth.saml.keystore, users.auth.saml.sp_metadata_path, users.auth.saml.idp_metadata_path et users.auth.ldap.ca_certificate_path.

6. Confiez les deux répertoires à l'utilisateur du conteneur, c'est-à-dire à l'uid 1000.

   mkdir -p logs
   sudo chown -R 1000:1000 config logs
   

7. Restaurez votre export, puis complétez .env.

   Base gérée par composeVotre propre base

   Démarrez la base seule et laissez-la s'initialiser. Restaurez ensuite votre export. Le conteneur crée un schéma vide à son premier démarrage : la restauration doit donc le remplacer et non s'y ajouter.

   docker compose --profile bundled-db up -d database
   pg_restore -h localhost -U drovio -d drovio --clean --if-exists drovio.dump
   

   Dans .env, donnez à DB_PASSWORD le mot de passe avec lequel la base vient d'être créée.

   Restaurez sur le serveur que vous comptez conserver, puis pointez la configuration vers lui dans .env :

   DB_HOST=my-database.example.com
   DB_NAME=drovio
   DB_USER=drovio
   DB_PASSWORD=<le mot de passe existant>
   

8. Renseignez DROVIO_HOSTNAME dans .env avec le nom par lequel vos utilisateurs joignent déjà le serveur. Compose l'exige, même s'il ne réécrira pas votre URL.

   Laissez APP_URL vide

   Contrairement à DROVIO_HOSTNAME, APP_URL est écrit dans la configuration à chaque démarrage. Lui donner autre chose que l'URL actuelle de votre serveur casserait les licences qui y sont liées.

9. Appliquez le script de schéma si vous changez aussi de version, comme décrit plus haut. Une migration à version égale ne demande rien ici.

10. Démarrez le serveur et vérifiez que vous y accédez :

    docker compose --profile bundled-db up -d
    curl -f http://drovio.example.com:8090/healthcheck
    

Laissez l'ancienne installation en place, arrêtée, jusqu'à ce que vous soyez satisfait. Le retour arrière consiste alors à redémarrer son service, à condition de ne pas avoir laissé le nouveau déploiement écrire dans la même base.