Notes de version
Cette page présente les informations techniques liées aux différentes versions de Datachain, les informations de migrations ainsi que les procédures exceptionnelles à appliquer lors de certains changements de version. Pour plus d’informations sur les évolutions fonctionnelles de l’application, merci de vous reporter à la page notes de version.
Version 9.1.0
Modifications importantes en terme d’image docker
Décorrélation Keycloak
La décorrélation keycloak, déjà débutée en 9.0.0, poursuit son cours. Elle devrait être définitivement terminée avec les migrations de DcCode et Maestro dans la console, offrant ainsi un environnement fonctionnel plus intégré et un environnement technique permettant d’intégrer la Suite datachain avec un SSO Oauth compatible.
Comme cela est déjà le cas pour la plupart de nos clients utilisant un déploiement swarm, nous conseillons de mettre keycloak dans une stack docker dédiée.
Les prochaines versions de keycloak seront alignées avec la version majeure de keycloak courante et nous continuerons de la maintenir à niveau de notre côté pour assurer la première configuration (notamment la création des différents clients utilisés par Datachain). Pour cette 9.1.0, merci de conserver votre version de keycloak, la dernière version disponible étant donc la 9.0.18.
Mise à jour majeur de postgreSQL
Pour cette nouvelle version de Datachain core, nous avons procédé à une mise à jour de la version de postgreSQL, désormais en 18.3 de postgreSQL. Comme pour keycloack, la version de postgres va désormais être alignée avec la version majeure de postgres, pour une meilleure visibilité de la version utilisée.
La nouvelle version de postgreSQL est la version 18-trixie.
La migration vers cette nouvelle version est conseillée, mais n’est pas indispensable pour la mise à jour de Datachain. Si vous ne souhaitez pas effectuer la migration des données pour le déploiement de cette version, la mise à jour peut-être faite à une date ultérieure. Merci, dans ce cas, de conserver votre version de postgreSQL utilisée, la dernière version avant la 18-trixie étant la version 9.0.18.
La procédure de migration consiste à :
-
Arrêter les stacks/services utilisant la base de données
-
Procéder au dump des bases de données
-
Sauvegarder le répertoire data de la base (pour seconde sauvegarde) ou procéder à creation d’un nouveau volume pour la nouvelle version de la base de donnée
-
Démarrer la nouvelle base de donnée
-
Restaurer les datas de l’ancienne base vers la nouvelle base de donnée.
A noter : Pour les utilisateurs de DC-Maestro, il est possible de procéder aussi à la migration de la base de données vers cette nouvelle base, pour les bases de maestro et airflow, afin de ne conserver qu’une unique version de postgreSQL déployée.
Remplacement du service Redis par un service Valkey
Redis est une solution de cache, gestion de file utilisée à de nombreux endroits dans la suite Datachain. La dernière version utilisée est la version 7. Nous avons choisi d’utiliser désormais la solution Valkey, qui est le même type de solution, supporté par la fondation Linux. Nous conseillons de migrer vers ce nouveau produit pour Datachain core. Nous sommes en cours de validation pour Dc-Maestro, qui utilise un service Redis distinct actuellement. Pour migrer vers cette nouvelle version, rien de plus simple. Éditer le fichier docker-compose associé à Redis et modifier les lignes :
image: redis:7.0-alpine
command: redis-server #... avec potentiellement des paramètres dans votre déploiement
par
image: valkey/valkey:9.0-alpine
command: valkey-server #... avec potentiellement les mêmes paramètres dans votre déploiement
Mise à jour de la version de Traefik
Nous avons procédé à une mise a jour de la version de Traefik, la version utilisée sur la plupart de nos déploiements clients en Swarm (hors K8s) étant en version 2.x. Nous avons validé l’utilisation du déploiement de la version 3.6. Cette version implique des modifications des descripteurs de déploiement des services relié à Traefik, induite par le produit.
Pour migrer vers cette nouvelle version, il est nécéssaire de procéder à des mises à jour du fichier de configuration de traefik : Modifier les lignes
- "--providers.docker=true"
- "--providers.docker.swarmMode=true"
- "--providers.docker.network=traefik_network"
- "--providers.docker.exposedbydefault=false"
- "--providers.docker.endpoint=unix:///var/run/docker.sock"
par
- "--providers.swarm.watch=true"
- "--providers.swarm.exposedbydefault=false"
- "--providers.swarm.network=traefik_network"
- "--providers.swarm.endpoint=unix:///var/run/docker.sock"
Dans tout les fichiers de déploiement de composant utilisant traefik, modifier la ligne suivante ou supprimer la ligne suivante (voir ci-après)
- "traefik.docker.network=traefik_network"
par
- "traefik.swarm.network=traefik_network"
À noter : il est possible de supprimer cette ligne, car dans ce cas, traefik utilise le réseau par défaut via le paramètre de configuration "providers.swarm.network" présent la déclaration du service traefik, pour communiquer avec les autres services.
Version 9.0.3 → 9.0.18
Quelques migrations techniques de base de données sont effectuées lors de l’installation de la release par rapport à la précédente version. Merci de vous assurer du bon passage des patchs suite au déploiement de la nouvelle version en consultant les logs du service de migration.
Versions 9.0.1/9.0.2
Paramétrage du Module console
Ajout de nouveaux paramètres pour la console pour la synchronization LDAP :
-
dc.app.console.provisioning.ldap.first.ldap-type et dc.app.console.provisioning.ldap.second.ldap-type permettant d’indiquer le type d’annuaire :
-
AD : Active directory
-
STANDARD : Autres annuaires LDAP (par défaut)
-
-
dc.app.console.provisioning.ldap.first.count et dc.app.console.provisioning.ldap.second.count permettant d’activer la pagination et de préciser le nombre d’entrées à remonter (pagination ldap). Précisez une valeur autre que la valeur par défaut (-1) pour activer la pagination.
-
dc.app.console.provisioning.ldap.first.referral et dc.app.console.provisioning.ldap.second.referral de valeurs possibles follow, ignore, throw pour le traitement explicite des referral LDAP (notamment en cas d’erreur de synchronisation avec active directory. Voir ici.)
La valeur des paramètres dc.app.console.provisioning.ldap.first.user.relative-dn, dc.app.console.provisioning.ldap.second.user.relative-dn, dc.app.console.provisioning.ldap.first.group.relative-dn, dc.app.console.provisioning.ldap.second.group.relative-dn peut désormais être positionnée avec une valeur vide.
Version 9.0.0
La version V9 de datachain introduit un grand nombre de fonctionnalités ainsi que de nombreuses évolutions techniques.
Module console
Le module console est désormais déployé avec datachain Core. Ce module permet de gérer les utilisateurs/groupes et de leur attribuer les accès aux différents modules Datachain Core et Datachain Marketplace. Il servira à attribuer les roles des utilisateurs de dc-maestro et dc-marketplace dans une version future. De ce fait, pour les plateformes où est déployé maestro, le module keycloak reste déployé, afin de permettre les communications entre les modules maestro, keycloak et datachain-core.
Le module console permet notamment de limiter le couplage fort entre Datachain-Core et le SSO keycloak et devrait permettre une intégration facilitée dans des systèmes d’informations pré-équipés d’un SSO de type Oauth. Pour ce faire, le module console peut être provisionné notamment auprès d’un annuaire LDAP (en général utilisé pour l’intégration des utilisateurs dans le SSO) et éviter ainsi des ressaisies inutiles d’informations utilisateurs.
Étapes de migration
1.Vérification/Création des clients keycloak
Dans le royaume de sécurité dc-realm, valider l’existence des clients dc_core, dc_marketplace, dc_console. Si les clients n’existent pas, créer les en activant "client authentication" et "standard flow" et récupérer les access_token, à reporter dans les configurations suivantes) Les trois étapes de créations sont :




2. Adaptation de l’image Postgres utilisée pour dc-core
Dans le fichier de déploiement de la base de donnée (docker-compose.yml): vérification de l’utilisation de l’image pg_all au lieu de l’image pg. À remplacer au besoin.
3. Vérification de l’existence des bases de données (dc_console et dc_marketplace)
En fonction de l’image docker et de l’historique de déploiement de la solution, il peut être nécessaire de créer les bases de données.
→ Pour vérifier, se connecter en shell à la base de données Datachain :
psql -U postgres
\l
Si les noms des bases dc_console et dc_marketplace n’apparaissent pas, alors les créer.
CREATE DATABASE dc_console WITH OWNER postgres ENCODING='UTF8' TEMPLATE=template0 TABLESPACE pg_default CONNECTION LIMIT -1;
CREATE DATABASE dc_marketplace WITH OWNER postgres ENCODING='UTF8' TEMPLATE=template0 TABLESPACE pg_default CONNECTION LIMIT -1;
Quitter la base.
\q
4. Revues des descripteurs de déploiement de dc-core
4.1 Préparation du déploiement de la console
Un fichier de description des éléments de la plateforme est fourni à la console, afin transférer les informations aux différents modules, pour permettre les communications inter-module. Dans cette version, seuls les modules Console, marketplace et datachain core sont concerné. Les autres modules Datachain seront intégré dans une version ultérieure.
Préparer le fichier de description de la topology en adaptant les URL publiques et internes des éléments à déployer, les codes, label et description. Les codes associés seront à reporter dans la configuration des modules concernés.
En cas d’utilisation de la marketplace :
{
"products": [
{
"code": "DATACHAIN_CONSOLE",
"label": "Datachain Console",
"description": "Console Datachain",
"internalUrl": "http://dc-console:8093",
"publicUrl": "_____URL_PUBLIQUE_A_CONFIGURER______",
"type": "DC_CONSOLE"
},
{
"code": "DC_MP",
"label": "Datachain Marketplace for Efficient Sharing",
"description": "Une belle description de la plateforme datachain core",
"internalUrl": "http://dc-marketplace:8092",
"publicUrl": "_____URL_PUBLIQUE_A_CONFIGURER______",
"type": "DC_MARKETPLACE"
},
{
"code": "DATACHAIN_CORE",
"label": "Datachain Core Platform",
"description": "Datachain Generics Data & Handle Data",
"internalUrl": "http://dc-backend:8089",
"publicUrl": "_____URL_PUBLIQUE_A_CONFIGURER______",
"linkedProducts": [
"DC_MP"
],
"type": "DC_CORE"
}
]
}
En cas de non utilisation de la marketplace :
{
"products": [
{
"code": "DATACHAIN_CONSOLE",
"label": "Datachain Console",
"description": "Console Datachain",
"internalUrl": "http://dc-console:8093",
"publicUrl": "_____URL_PUBLIQUE_A_CONFIGURER______",
"type": "DC_CONSOLE"
},
{
"code": "DATACHAIN_CORE",
"label": "Datachain Core Platform",
"description": "Datachain Generics Data & Handle Data",
"internalUrl": "http://dc-backend:8089",
"publicUrl": "_____URL_PUBLIQUE_A_CONFIGURER______",
"type": "DC_CORE"
}
]
}
4.2 : Ajout de la console dans les descripteurs de déploiement
services:
dc-console:
# URL REGISTRY A ADAPTER et version du produit à adapter
image: ${HARBOR_REGISTRY}/dc/console:${PRODUCT_VERSION}
networks:
traefik_network:
dc_network:
aliases:
- dc-console
volumes:
- type: bind
# Répertoire de log à adapter
source: ${DC_CFG_DC_LOG_DIR_DATACHAIN}
target: /logs
- type: bind
source: ./config
target: /config
env_file: console.env
deploy:
mode: replicated
replicas: 1
labels:
- "traefik.enable=true"
- "traefik.docker.network=traefik_network"
- "traefik.http.routers.dc_console.rule=Host(`___URL_PUBLIQUE_DE_LA_CONSOLE___`) && PathPrefix(`/`)"
# A adapter en fonction de notre déploiement, si secure
#- "traefik.http.routers.dc_console.entrypoints=web"
#- "traefik.http.routers.dc_console.entrypoints=websecure"
#- "traefik.http.routers.dc_console.tls=true"
#- "traefik.http.routers.dc_console.tls.certresolver=resolver1"
- "traefik.http.routers.dc_console.service=dc_console"
- "traefik.http.services.dc_console.loadbalancer.server.port=8093"
- "traefik.http.routers.dc_console1.middlewares=dc_console_comp1@docker"
- "traefik.http.middlewares.dc_console_comp1.compress=true"
networks:
dc_network:
external: true
name: dc_network
traefik_network:
external: true
name: traefik_network
Fichier de configuration de base
# configuration par défaut des logs, qui pourront être modifié en cas de nécessité
logging.level.ROOT=INFO
logging.level.com.adb=INFO
logging.level.org.springframework=INFO
logging.level.org.springframework.security=INFO
logging.level.org.springframework.data.redis=ERROR
#logging.level.org.hibernate.SQL=DEBUG
#logging.level.org.hibernate.orm.jdbc.bind=TRACE
#logging.level.org.apache.http=DEBUG
#logging.level.org.apache.http.wire=DEBUG
dc.app.console.database.main-datasource.password=___A_PRECISER___
dc.app.console.database.main-datasource.url=jdbc:postgresql://dc-pg:5432/dc_console
spring.security.oauth2.resourceserver.jwt.jwk-set-uri=___URL_SSO___/realms/dc-realm/protocol/openid-connect/certs
spring.security.oauth2.client.provider.oidc.issuer-uri=___URL_SSO___/realms/dc-realm
spring.security.oauth2.client.registration.oidc.client-id=dc_console
spring.security.oauth2.client.registration.oidc.client-secret=___MOT_DE_PASSE_PRECEDEMENT_GENERE___
spring.security.oauth2.client.registration.oidc.client-authentication-method=client_secret_post
spring.security.oauth2.client.registration.oidc.authorization-grant-type=authorization_code
spring.security.oauth2.client.registration.oidc.redirect-uri=___URL_SSO___/login/oauth2/code/oidc
spring.security.oauth2.client.registration.oidc.scope=openid, profile, email
management.endpoints.web.exposure.include=health, info, prometheus, loggers
# Décommenter ce paramètre si un proxy modifie les urls et forward l'url d'origine via les headers standard X-Forwarded-XXX
# server.forward-headers-strategy=NATIVE
4.3 Ajout de la marketplace dans les descripteurs de déploiement
services:
dc-marketplace:
# URL REGISTRY A ADAPTER et version du produit à adapter
image: ${HARBOR_REGISTRY}/dc/marketplace:${PRODUCT_VERSION}
networks:
traefik_network:
dc_network:
aliases:
- dc-marketplace
volumes:
- type: bind
# Répertoire de log à adapter
source: ${DC_CFG_DC_LOG_DIR_DATACHAIN}
target: /logs
env_file: marketplace.env
deploy:
mode: replicated
replicas: 1
labels:
- "traefik.enable=true"
- "traefik.docker.network=traefik_network"
- "traefik.http.routers.dc_marketplace.rule=Host(`___URL_PUBLIQUE_DE_LA_MARKETPLACE___`) && PathPrefix(`/`)"
# A adapter en fonction de notre déploiement, si secure
#- "traefik.http.routers.dc_marketplace.entrypoints=web"
#- "traefik.http.routers.dc_marketplace.entrypoints=websecure"
#- "traefik.http.routers.dc_marketplace.tls=true"
#- "traefik.http.routers.dc_marketplace.tls.certresolver=resolver1"
- "traefik.http.routers.dc_marketplace.service=dc_marketplace"
- "traefik.http.services.dc_marketplace.loadbalancer.server.port=8092"
- "traefik.http.routers.dc_marketplace1.middlewares=dc_marketplace_comp1@docker"
- "traefik.http.middlewares.dc_marketplace_comp1.compress=true"
networks:
dc_network:
external: true
name: dc_network
traefik_network:
external: true
name: traefik_network
Fichier de configuration de base
# configuration par défaut des logs, qui pourront être modifié en cas de nécessité
logging.level.ROOT=INFO
logging.level.com.adb=INFO
logging.level.org.springframework=INFO
logging.level.org.springframework.security=INFO
logging.level.org.springframework.data.redis=ERROR
#logging.level.org.hibernate.SQL=DEBUG
#logging.level.org.hibernate.orm.jdbc.bind=TRACE
#logging.level.org.apache.http=DEBUG
#logging.level.org.apache.http.wire=DEBUG
# Configuration des bases de donnée
dc.app.marketplace.database.main-datasource.url=jdbc:postgresql://dc-pg:5432/dc_marketplace
dc.app.marketplace.database.expose-datasource.url=jdbc:postgresql://dc-pg:5432/expose
dc.app.marketplace.database.main-datasource.password=___A_PRECISER___
dc.app.marketplace.database.expose-datasource.password=___A_PRECISER___
# Information d'ccès à la console
dc.app.module.console.url=http://dc-console:8093/
dc.app.module.instance-id=DC_MP
# Racine de l'exposition
dc.app.marketplace.expose.public-url=___A_PRECISER___
# Configuration Sécurité
dc.app.security.auth.oauth.resource-server.enable=true
dc.app.security.auth.oauth.client.enable=true
dc.app.security.auth.oauth.client.enable-oauth-logout=true
spring.security.oauth2.resourceserver.jwt.jwk-set-uri=___URL_SSO___/realms/dc-realm/protocol/openid-connect/certs
spring.security.oauth2.client.provider.oidc.issuer-uri=___URL_SSO___/realms/dc-realm
spring.security.oauth2.client.registration.oidc.client-id=dc_marketplace
spring.security.oauth2.client.registration.oidc.client-secret=___MOT_DE_PASSE_PRECEDEMENT_GENERE___
spring.security.oauth2.client.registration.oidc.client-authentication-method=client_secret_post
spring.security.oauth2.client.registration.oidc.authorization-grant-type=authorization_code
spring.security.oauth2.client.registration.oidc.redirect-uri=___URL_SSO___/login/oauth2/code/oidc
spring.security.oauth2.client.registration.oidc.scope=openid, profile, email
management.endpoints.web.exposure.include=health, info, prometheus, loggers
# Décommenter ce paramètre si un proxy modifie les urls et forward l'url d'origine via les headers standard X-Forwarded-XXX
# server.forward-headers-strategy=NATIVE
4.4 Modification de la configuration dc-core
-
Dans la configuration du front (en général webui.env), suppression de la configuration KEYCLOAK_CONFIG désormais inutile
-
Dans la configuration du backend, ajout de la configuration SSO vers keycloak modifiée et de la configuration console
Fichier de configuration de base
spring.security.oauth2.resourceserver.jwt.jwk-set-uri=${DC_CFG_KC_PUBLIC_URL}/realms/dc-realm/protocol/openid-connect/certs
spring.security.oauth2.client.provider.oidc.issuer-uri=${DC_CFG_KC_PUBLIC_URL}/realms/dc-realm
spring.security.oauth2.client.registration.oidc.client-id=${DC_CFG_DC_CORE_KC_CLIENT_ID}
spring.security.oauth2.client.registration.oidc.client-secret=${DC_CFG_DC_CORE_KC_CLIENT_SECRET}
spring.security.oauth2.client.registration.oidc.client-authentication-method=client_secret_post
spring.security.oauth2.client.registration.oidc.authorization-grant-type=authorization_code
spring.security.oauth2.client.registration.oidc.redirect-uri=${DC_CFG_DC_CORE_PUBLIC_URL}/login/oauth2/code/oidc
spring.security.oauth2.client.registration.oidc.scope=openid, profile, email
dc.app.security.auth.oauth.client.enable-oauth-logout=true
# Configuration Redis
dc.app.notification.urls=${DC_CFG_DC_REDIS_PRIVATE_URL}
# Activation de la console
dc.app.module.instance-id=DATACHAIN_CORE_1
dc.app.module.console.sync.enable=true
dc.app.module.console.url=http://dc-console:8093/
# SI marketplace
dc.app.module.web.functionality.exposition_v2.available=true
# configuration par défaut des logs, qui pourront être modifié en cas de nécessité
logging.level.ROOT=INFO
logging.level.com.adb=INFO
# Décommenter ce paramètre si un proxy modifie les urls et forward l'url d'origine via les headers standard X-Forwarded-XXX
# server.forward-headers-strategy=NATIVE
6. Création du premier utilisateur administrateur de la console (migration depuis une plateforme V8 sans console)
Se connecter en shell à la base de données Datachain
psql -U postgres
\c dc_console
/* Récupération de l'id de la console, à reporter dans _______ID_INSTANCE______ ci dessous */
SELECT id FROM dc_console.dcc_product_instance WHERE type='DC_CONSOLE';
/* Récupération de l'id du premier utilisteur adminstrateur, à reporter dans ______ID_USER______ ci dessous */
SELECT id FROM dc_console_data.local_user WHERE mail='tests+admin@adobis.lan';
UPDATE dc_console.dcc_user_instance_account (id,"version",created_at,updated_at,roles,user_id,instance_id,organization_id) VALUES
(1,0,TIMEZONE('Europe/Paris', NOW()),TIMEZONE('Europe/Paris', NOW()),'DCC_ADMIN;DCC_ORGANIZATION_ADMIN;DCC_MEMBER', _______ID_USER______ ,_______ID_INSTANCE______ ,1) ON CONFLICT DO NOTHING;
INSERT INTO dc_console_data.local_user_roles (id,created_at,updated_at,roles,organization_id, user_id) VALUES
(1,TIMEZONE('Europe/Paris', NOW()),TIMEZONE('Europe/Paris', NOW()),'DCC_ADMIN;DCC_ORGANIZATION_ADMIN;DCC_MEMBER',1,_______ID_USER______) ON CONFLICT DO NOTHING;
7. Migration des roles utilisateurs issues de keycloak dans la console
Se connecter en shell au conteneur de la console et executer la commande suivante
# mettre la valeur --dc.app.console.keycloak.migration.create-members=false
# au lieu de true si le provisionning de la console est externe (ldap) afin de
# ne pas recréer des utilisateurs qui ne seraient plus dans l'annuaire.
java -jar dc-console-*.jar \
--dc.app.console.keycloak.enable-kc-migration=true \
--dc.app.console.keycloak.migration.create-members=true \
--spring.profiles.active=exec,prod \
--dc.app.console.keycloak.url=http://dc_keycloak:8080/auth \
--dc.app.console.keycloak.realm=dc-realm \
--dc.app.console.keycloak.sync-client-id=dc_backend_keycloak \
--dc.app.console.keycloak.sync-client-secret=6bcf085a-44c8-40b1-9c0c-9381c9749a8c \
--dc.app.console.keycloak.resource=dc_backend \
--server.port=13333 --management.server.port=13334 \
--dc.app.console.provisioning.ldap.first.active=false \
--dc.app.security.auth.kerberos.enable=false \
--dc.app.security.auth.oauth.resource-server.enable=false \
--dc.app.security.auth.oauth.client.enable=false \
--dc.app.security.auth.api-key.enable=false \
--logging.level.ROOT=INFO \
--logging.level.org.springframework=ERROR \
--logging.level.org.springframework.security=ERROR \
--logging.level.org.springframework.data.redis=ERROR \
--logging.level.org.hibernate.SQL=ERROR \
--logging.level.org.hibernate.orm.jdbc.bind=ERROR \
--logging.level.com.adb=DEBUG
8. Validation de la bonne exécution de la migration Datachain-Core
Quelques migrations techniques de base de données sont effectuées lors de l’installation de la release par rapport à la précédente version. Merci de vous assurer du bon passage des patchs suite au déploiement de la nouvelle version en consultant les logs du service de migration.
Mise à jour des drivers de base de données
| Type de base donnée | Version | Matrice de compatibilité du driver | Commentaires |
|---|---|---|---|
PostgreSQL |
42.7.7 |
||
SQLServer |
12.6.4 |
||
Oracle |
19.28.0.0 |
https://www.oracle.com/uk/database/technologies/faq-jdbc.html (question : What is the JDBC and RDBMS interoperability matrix or the certification matrix?) |
Avec prise en compte de l’internationalisation (oraI18n) |
Mysql |
9.4.0 |
https://dev.mysql.com/doc/connector-j/en/connector-j-versions.html |
|
Mariadb |
3.5.5 |
https://mariadb.com/docs/connectors/mariadb-connector-j/about-mariadb-connector-j |
Version 8.9.0
Quelques migrations techniques de base de données sont effectuées lors de l’installation de la release par rapport à la précédente version. Merci de vous assurer du bon passage des patchs suite au déploiement de la nouvelle version en consultant les logs du service de migration.
Précisions sur les drivers de base de données :
| Type de base donnée | Version | Matrice de compatibilité du driver | Commentaires |
|---|---|---|---|
PostgreSQL |
42.6.0 |
||
SQLServer |
12.2.0 |
||
Oracle |
19.22.0.0 |
https://www.oracle.com/uk/database/technologies/faq-jdbc.html (question : What is the JDBC and RDBMS interoperability matrix or the certification matrix?) |
Avec prise en compte de l’internationalisation (oraI18n) |
Mysql |
8.1.0 |
https://dev.mysql.com/doc/connector-j/en/connector-j-versions.html |
|
Mariadb |
3.2.0 |
https://mariadb.com/docs/connectors/mariadb-connector-j/about-mariadb-connector-j |
Version 8.8.0
Quelques migrations techniques de base de données sont effectuées lors de l’installation de la release par rapport à la précédente version. Merci de vous assurer du bon passage des patchs suite au déploiement de la nouvelle version en consultant les logs du service de migration.
Version 8.7.1
Quelques migrations techniques de base de données sont effectuées lors de l’installation de la release par rapport à la précédente version. Merci de vous assurer du bon passage des patchs suite au déploiement de la nouvelle version en consultant les logs du service de migration.
Version 8.7.0
Opérations manuelles de mise à jour
Mise à jour console et marketplace
Pour les utilisateurs des versions beta de la console et de l’application marketplace, certaines opérations doivent être effectuées manuellement lors de la migration. La base de données data_view et son schéma sont remplacés par une base/schéma marketplace et certains paramètres ont été renommés pour plus de lisibilité.
La procédure de mise à jour est la suivante :
-
Procéder à l’arrêt des services hors base de données.
-
Procéder à la sauvegarde des bases de données
-
Sur la base data_view/marketplace, effectuer les commandes suivantes :
\c postgres
ALTER DATABASE data_view RENAME TO dc_marketplace;
\c dc_marketplace
ALTER SCHEMA data_view RENAME TO dc_marketplace;
UPDATE dc_marketplace.schema_changes SET checksum='-774607648' WHERE installed_rank=1;
-
Sur la base dc_console, effectuer les commandes suivantes :
\c dc_console
DELETE from dc_console.schema_changes WHERE version='1.1.1';
-
dans le fichier docker-compose de déploiement de l’application marketplace (ex data_view), renommer le nom de l’image data_view en marketplace
-
dans les fichiers d’environnement et/ou docker-compose, renommer tous les paramètres dc.app.view par dc.app.marketplace
-
Si l’URL de la base de données de la marketplace a été surchargé dans la configuration (avec le paramètre dc.app.marketplace.database.main-datasource), adapter l’URL au nouveau nom de la base de donnée. Par exemple :
dc.app.marketplace.database.main-datasource.url=jdbc:postgresql://dc-pg:5432/dc_marketplace?prepareThreshold=0&preparedStatementCacheQueries=0&defaultRowFetchSize=1000
-
Déployer l’application en version 8.7.0
🚀 Notes techniques
De nouveaux services permettant d’interagir avec les connecteurs, les dépôts et les datablocks ont été ajoutés, modifiés ou simplifiés dans l’API DataChain pour une utilisation facilitée :
-
Duplicate project POST /service/projects/{id}/duplicate : service modifié de duplication des projets. Auparavant, le texte de consentement de l’utilisateur était à réécrire en entier et en anglais. Désormais, un booléen suffit.
-
Check a Connector connectivity POST /service/connectors/detailed/check_connection/{connectorId} : nouveau service de vérification générique des informations de connexion d’un connecteur. Le paramètre ctx y est facultatif.
-
Get a connector by ID and return it with its properties GET /service/connectors/detailed/{connectorId} : nouveau service de consultation d’un connecteur et ses propriétés via son seul identifiant. Les services équivalents imposent de fournir aussi son type.
-
View a list of depots GET /service/depots : service modifié qui retourne la liste des dépôts d’un projet et qui inclut désormais dans son retour les types des dépôts.
-
Create Extraction POST /service/depots/detailed/{depotId}/extractions : nouveau service de création générique d’une extraction dans un dépôt en utilisant son seul identifiant (sans avoir à fournir son type).
-
Get depot file preview GET /service/depots/detailed/{depotId}/remote_file/preview : nouveau service permettant de consulter les données d’un dépôt en ne disposant que de son identifiant et sans avoir à fournir.
-
exec DataBlock And Get JobKey By Element Id POST/service/datablock/exec_by_element_id : nouveau service exécutant un DataBlock pour en obtenir plusieurs données et retournant la clé de cette tâche
-
get Detailed Data By JobKey GET /service/datablock/exec/result/detailed : nouveau service utilisant la clé d’une tâche d’exécution d’un DataBlock et qui en affiche le résultat
Version 8.6.0
Un ou plusieurs patchs modifie(nt) la structure de la base de donnée. Merci de vérifier le passage du service de migration.
| Nous avons procédé à un alignement des ports d’écoute des conteneurs, sur les ports associés à la supervision : Le port d’écoute de spark est désormais le 9090. Veillez à mettre à jour ce port dans le health check de Spark dans le fichier docker-compose associé ainsi que la règle Traefik potentiellement associée pour l’ouverture des flux de monitoring actuator ou dans l’outil de monitoring consommant ce service en direct. Rappel : la liste des ports se trouve ici. |
🚀 Notes techniques
Intégration dans la documentation d’informations concernant :
-
L’administration technique de la solution. Cela concerne notamment les procédures de sauvegarde/restauration.
-
Une description avancée des services déployés. Cela inclut notamment les ports ouverts par les services, les volumes qui peuvent/doivent être montés.
Version 8.5.3
Un patch ajoute une fonction postgres supplémentaire. Il n’y a pas de modification en termes de données.
Version 8.5.1
Mise à jour des drivers de base de données :
| Type de base donnée | Version | Commentaires |
|---|---|---|
PostgreSQL |
42.6.0 |
|
SQLServer |
12.2.0 |
|
Oracle |
19.22.0.0 |
Avec prise en compte de l’internationalisation (oraI18n) |
Mysql |
8.1.0 |
|
Mariadb |
3.2.0 |
Version 8.5.0
Quelques migrations techniques de base de données sont effectuées lors de l’installation de la release par rapport à la précédente version. Merci de vous assurer du bon passage des patchs suite au déploiement de la nouvelle version en consultant les logs du service de migration.
Mise à jour des drivers de base de données :
| Type de base donnée | Version | Commentaires |
|---|---|---|
PostgreSQL |
42.6.0 |
|
SQLServer |
12.2.0 |
|
Oracle |
19.19.0.0 |
Avec prise en compte de l’internationalisation (oraI18n) |
Mysql |
8.1.0 |
|
Mariadb |
3.2.0 |
Version 8.4.0
Quelques migrations techniques de base de données sont effectuées lors de l’installation de la release par rapport à la précédente version. Merci de vous assurer du bon passage des patchs suite au déploiement de la nouvelle version en consultant les logs du service de migration.
Ajout de paramètres de configuration SMTP, pour effectuer cette configuration lors du déploiement plutôt que via l’interface.
Version 8.3.0
🚀 Notes techniques
Modèle de base de donnée
Quelques migrations techniques de base de données sont effectuées lors de l’installation de la release par rapport à la précédente version. Merci de vous assurer du bon passage des patchs suite au déploiement de la nouvelle version en consultant les logs du service de migration.
Version 8.2.0
🚀 Notes techniques
Lors d’une nouvelle exposition de données, les données destinées à être remplacées restent disponibles pendant la durée de l’exposition, afin de garantir un maintien de l’accès aux données.
Modèle de base de donnée
De nombreuses migrations techniques de base de données sont effectuées lors de l’installation de la release par rapport à la précédente version. Merci de vous assurer du bon passage des patchs suite au déploiement de la nouvelle version en consultant les logs du service de migration.
| Les patchs mis en oeuvre pour cette migration font aussi des mises à jour de la base de données d’exposition. Merci de vous assurer de la bonne configuration des paramètres du service pg_migration. Plus d’information sur la configuration ici. |
Dernière mise à jour le 28 avril 2026 à 13:45