Exploitation - Généralités

Cette page présente les opérations d’exploitation communes à toutes les stacks de la solution Datachain : scripts de déploiement, démarrage et arrêt, ordre de démarrage, mise à jour, certificats et conventions de logs et de supervision. Les opérations propres à chaque stack sont décrites dans les pages dédiées (voir Exploitation).

Arborescence et scripts de déploiement

Lors d’un déploiement de Datachain Core selon les méthodes de déploiement proposé par Adobis, nous mettons à disposition un ensemble de scripts shell, qui vont permettre de gérer les services déployés, quelle que soit la granularité des stacks déployées.

A NOTER

Les scripts proposés sont des scripts permettant de faciliter le déploiement de la solution. Ils peuvent être librement adaptés par vos soins, ne sont pas soumis à licence.

A l’opposé, ces scripts ne sont pas soumis à garantie.

Dans la suite de ce chapitre, nous utiliserons les chemins standards proposés par Adobis pour le produit.

L’arborescence suivante est déployée sur tous les noeuds du cluster :

.
└── opt
    ├── adobis
    ├── products  // contient les scripts, fichier de configuration des différentes stacks
    │   ├── stack1
    │   └── stack2  // identique en terme d'arborescence globale
    ├── data  // contient les données des différents modules
    │   └── stack1  // répertoire de données de l'application
    │       └── xxx  // répertoire de données d'un service pour l'application
    └── logs  // contient les fichiers de log

Les scripts suivants sont déployés sur le noeud master du cluster :

.
└── opt
    ├── adobis
    └── products  // contient les scripts, fichier de configuration des différentes stacks
        └── stack1
            ├── shared  // scripts et éléments utilisés pas les scripts start, stop,...
            ├── previous_stacks_version  // historisation des certains éléments.
            ├── start.sh  // script de démarrage de la stack
            ├── stop.sh  // script d'arret de la stack
            ├── restart.sh  // script d'arrêt puis redémarrage de la stack
            ├── runStack.sh  // script utilisé par les scripts start, stop, restart
            ├── *.env  // configuration d'un service particulier (exemple : backend.env pour la configuration du backend de Datachain)
            ├── .env.harbor  // clés de la registry Harbor Adobis
            ├── .env.platform  // paramétrage globale (URL racine), utilisées dans les autres fichiers env ou le fichier docker-compose.
            ├── .env.global  // permet de spécifier le nom de la stack, ainsi que les réseaux dont cette stack est 'propriétaire'. Pour ce dernier point, le réseau est créée par le script de démarrage ou de redémarrage lors du lancement de la stack, si celui-ci n'existe pas encore.
            ├── .env.local  // contient potentiellement l'URL de Traefik, utilisées dans le fichier docker-compose.
            └── docker-compose-${stack-name} // Descripteur de déploiement de la stack ${stack-name}

Les fichiers .env.* présentés ci-dessus ne sont pas obligatoires. Ils peuvent être regroupées en un seul, en conservant le nom d’un des fichiers (i.e. tous les paramètres peuvent être regroupés dans un unique fichier '.env.local')

Ci-dessous un tableau avec les variables utilisées habituellement :

Paramètre	description
HARBOR_REGISTRY	Nom du registre ou récupérer les images docker
HARBOR_USER	Nom de l’utilisateur du registre si authentification
HARBOR_KEY	Clé de l’utilisateur du registre si authentification
DOCKER_NETWORKS	Réseau dont est propriétaire la(es) stack(s). Le réseau sera créé automatique si non existant. (D’un point de vue docker swarm, nous créant un réseau overlay encrypté, non attachable.)
STACKS_NAMES	Nom de la / des stack(s) séparé par des espaces. Si STACKS_NAMES=dc, alors le répertoire de déploiement doit contenir un fichier docker-compose-dc.yml. Il doit y avoir autant de fichiers docker-compose-xxx.yml que de stacks.
DOCKER_NETWORKS	Réseau dont est propriétaire la(es) stack(s). Le réseau sera créé automatique si non existant. (D’un point de vue docker swarm, nous créant un réseau overlay encrypté, non attachable.)
ADDITIONALS_COMPOSE_FILE_NAMES	Dans le cas où il y a une seule stack, mais plusieurs fichiers dockers compose, fin de nom de fichier à utiliser pour ajouter les fichiers docker-compose additionnel. Par exemple, la description du service Redis a été externalisée dans un fichier docker-compose-redis.yml, alors il est possible déclarer : ADDITIONALS_COMPOSE_FILE_NAMES=redis Les fichiers dockers-compose-STACK_NAME et docker-compose-redis.yml seront utilisés lors du démarrage de la stack.
*_URL	Externalisation des URLs pour le reverse-proxy traefik, utilisée par le(s) fichier(s) docker-compose-xxx.yml

Paramètre

description

HARBOR_REGISTRY

Nom du registre ou récupérer les images docker

HARBOR_USER

Nom de l’utilisateur du registre si authentification

HARBOR_KEY

Clé de l’utilisateur du registre si authentification

DOCKER_NETWORKS

Réseau dont est propriétaire la(es) stack(s). Le réseau sera créé automatique si non existant. (D’un point de vue docker swarm, nous créant un réseau overlay encrypté, non attachable.)

STACKS_NAMES

Nom de la / des stack(s) séparé par des espaces. Si STACKS_NAMES=dc, alors le répertoire de déploiement doit contenir un fichier docker-compose-dc.yml. Il doit y avoir autant de fichiers docker-compose-xxx.yml que de stacks.

DOCKER_NETWORKS

Réseau dont est propriétaire la(es) stack(s). Le réseau sera créé automatique si non existant. (D’un point de vue docker swarm, nous créant un réseau overlay encrypté, non attachable.)

ADDITIONALS_COMPOSE_FILE_NAMES

Dans le cas où il y a une seule stack, mais plusieurs fichiers dockers compose, fin de nom de fichier à utiliser pour ajouter les fichiers docker-compose additionnel. Par exemple, la description du service Redis a été externalisée dans un fichier docker-compose-redis.yml, alors il est possible déclarer :

ADDITIONALS_COMPOSE_FILE_NAMES=redis

Les fichiers dockers-compose-STACK_NAME et docker-compose-redis.yml seront utilisés lors du démarrage de la stack.

*_URL

Externalisation des URLs pour le reverse-proxy traefik, utilisée par le(s) fichier(s) docker-compose-xxx.yml

Démarrage et arrêt d’une stack

Le démarrage s’effectue en effectuant la commande shell suivante :

bash start.sh

L’arrêt s’effectue en effectuant la commande shell suivante :

bash stop.sh

Le redémarrage s’effectue en effectuant la commande suivante :

bash restart.sh

Changement de version

En cas de changement de version de la stack, ou de premier lancement, il est possible de spécifier la version dans la ligne de commande en utilisant le sélecteur '-v' suivi du numéro de version à déployer.

bash start.sh -v 8.6.0

bash restart.sh -v 8.6.0

Ordre de démarrage des éléments de la solution

Certains services nécessitent que d’autres soient déjà présents pour être opérationnels. Ci-dessous un ordre de démarrage proposé pour les différentes stacks. Selon votre propre architecture et votre propre déploiement, certaines stacks sont peut-être regroupées. De fait, celles présentées ci-dessous le sont avec un découpage standard.

Traefik : en tant que reverse proxy, aucune application ne sera accessible sans de déploiement de cette stack. L’absence de la stack traefik n’entraine pas de dysfonctionnement applicatif. Les autres applications ne sont juste pas accessibles depuis un navigateur.
Keycloak : lorsque la stack keycloak est déployée et non démarré, certains modules de la stack datachain ne peuvent pas démarrer, car utilisant des informations de sécurité issues de cette stack.
Cluster Spark : Dans le cadre du déploiement d’un cluster spark, celui-ci doit être opérationnel avant lancement de la stack Datachain et la stack Datachain devra être redémarrée si le cluster est redémarré. Dans le cas contraire, les contextes Spark de Datachain ne seront pas opérationnels.
Datachain : Dernier module à démarrer.

L’ordre d’arrêt des composants est l’ordre inverse de celui de démarrage.

Les opérations et fichiers propres à chaque stack sont décrits dans les pages Exploitation correspondantes.

Mise à jour d’une version

La mise à jour d’une stack consiste à redéployer ses services avec la nouvelle version des images, avec l’option -v des scripts (voir Changement de version). Pour toutes les stacks :

Consulter les notes techniques de version de chaque version intermédiaire : elles décrivent les changements de configuration, d’images, de ports et les procédures exceptionnelles de migration.
Sauvegarder les données de la stack avant l’arrêt (voir la page d’exploitation de la stack concernée, et Gestion des données pour les bases de données).
Arrêter la stack, puis la redémarrer avec la nouvelle version. Les services de migration (pg_migration pour Datachain, db-migration et airflow-migration pour Dc-Maestro) s’exécutent une fois et s’arrêtent : vérifier dans leurs logs que les migrations se sont bien déroulées avant d’utiliser l’application.
Respecter les indications des notes de version concernant les composants tiers (Keycloak, PostgreSQL) : version à conserver, ou migration conseillée.

Certificats applicatifs

Les images Java de Datachain (Spark, Console, Marketplace) permettent d’ajouter des autorités de confiance ou des certificats serveur, par exemple pour accéder à des connecteurs ou dépôts en HTTPS. Les certificats à ajouter sont déposés dans le volume /java_cert_import du conteneur : ils sont importés dans le keystore Java au démarrage du conteneur.

Extension .cert obligatoire, un seul certificat par fichier, encodage PEM ou DER.
Après le dépôt d’un nouveau certificat, redémarrer le service concerné.
Le format détaillé et le fonctionnement sont décrits dans Certificats applicatifs.

Une alternative manuelle, qui consiste à fournir un keystore complet à la JVM, est présentée dans la FAQ.

Logs

Les images Java de Datachain (backend, Spark, Console, Marketplace) écrivent leurs logs dans des fichiers sous /logs/datachain/<module>, avec rotation quotidienne et par taille, compression et rétention de 30 jours. Monter un volume sur /logs est conseillé pour les conserver. Voir la page de configuration de chaque module.
Les autres images (Web, migration, Keycloak, PostgreSQL, Valkey) écrivent sur la sortie standard du conteneur, consultable avec docker service logs (Swarm) ou docker logs.
Dc-Maestro écrit sur la sortie standard et dans un fichier à rotation (LOG_FILENAME). Airflow écrit les logs d’exécution des tâches sous /opt/airflow/logs.

Supervision

Les modules de Datachain exposent leurs métriques au format Prometheus : en natif (Spring Actuator) pour le backend, Spark, la Console et la Marketplace, via des briques externes pour le serveur web (nginx-prometheus-exporter) et PostgreSQL (postgres-exporter). La mise en place est décrite dans les pages d’exploitation de chaque stack.

Dernière mise à jour le 2 novembre 2026 à 15:16