Configuration

Datachain Core est mis à disposition sous forme de conteneur docker, permettant des déploiements simples mono-serveur, jusqu’à des architectures multi-serveurs hautement disponibles.

Cette section présente les images de la solution DataChain ©, ainsi que les informations associées pour chaque image (notamment en terme d’accès disque).

Les applications sont paramétrables via les fichiers *.env de docker ou des variables d’environnement. Cette section présente l’essentiel du paramétrage pour les différents modules de la solution.

A propos des variables d’environnements

Les nouvelles images (console et marketplace actuellement) n’ont pas de variables d’environnements définies pour les variables sensibles.

TOUTE valeur d’une variable de configuration peut être insérée dans un docker secret (par exemple pour les mots de passe) en utilisant le nom de variable d’origine et en lui appliquant les règles suivantes :

  • Tous les caractères alphanumériques sont en MAJUSCULE

  • Remplacement des _ (tiret bas) par 2 tirets bas

  • Remplacement des - (tiret) par 3 tirets bas

  • Remplacement des . (point) par 1 tiret bas

  • Ajout de _FILE à la fin du nom de variable

Exemple :

com.adb.dc.data-source.env_value=monsecret est transformé en :

  • Un fichier secret qui contient la valeur "monsecret" par exemple dans /var/run/secret/env_value_file

  • Une variable d’environnement COM_ADB_DC_DATA___SOURCE_ENV__VALUE_FILE=/var/run/secret/env_value_file

Certificats applicatifs

Certaines images exposent un volume /java_cert_import, dans lequel déposer les certificats qui seront utilisés par Datachain, par exemple pour des connecteurs en HTTPS.

Les certificats sont au format PEM, et doivent avoir comme extension ".cert", ex "adobis-rootca.cert".

  • L’extension .cert est obligatoire : seuls les fichiers portant cette extension sont importés, quel que soit leur contenu.

  • Le contenu peut être encodé en PEM (texte, encodé en Base64, délimité par -----BEGIN CERTIFICATE----- / -----END CERTIFICATE-----) ou en DER (binaire, les octets bruts de la structure ASN.1) : les deux sont acceptés, l’outil keytool utilisé pour la mise à jour détectant automatiquement l’encodage.

  • Le fichier doit contenir un seul certificat. Les keystores complets (PKCS12, JKS) ou les fichiers contenant plusieurs certificats ne sont pas supportés.

Exécution sans privilèges (OpenShift)

Les images applicatives de Datachain Core, Console, Marketplace et Dc-Maestro s’exécutent sans privilèges root, et sont conçues pour fonctionner sur OpenShift avec la politique de sécurité par défaut (SCC restricted) :

  • L’application s’exécute avec un utilisateur non privilégié (dc, maestro ou nginx) dont le groupe principal est le groupe root (gid 0). Les fichiers de l’image sont accessibles en écriture à ce groupe. Les images Java de Datachain (backend, spark, console, marketplace) démarrent en root pour leur superviseur de processus, puis lancent l’application avec dc ; avec un uid imposé, elles s’exécutent entièrement avec celui-ci.

  • OpenShift impose un uid aléatoire au démarrage du conteneur. Cet uid appartient toujours au groupe root (gid 0) : l’application garde donc l’accès à ses fichiers et à ses volumes.

  • Les ports d’écoute sont supérieurs à 1024 : 8080 pour l’application web Datachain (monitoring sur 9080), pour l’API Maestro et pour l’interface Maestro.

  • Les volumes (répertoires de l’hôte, volumes persistants) doivent être accessibles en écriture au groupe root (gid 0), ou à l’uid de l’image si celui-ci est conservé (38330 pour dc et maestro, 101 pour nginx).

L’utilisateur de chaque image est indiqué dans le tableau « Description de l’image » de chaque module.

Dans cette section

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