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.6

Quelle étiquette utiliser¶

Étiquette	Désigne
`3.6.6`	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.6.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.

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.6"

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.6)
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

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 :

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.6)
docker cp "$id:/opt/drovio-server/bundle/drovio-server.sql" .
docker rm "$id"
```

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

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.