Informations techniques sur le produit ADONIS 19

Aperçu​

À partir d'ADONIS 19, le produit est fourni aux clients On-Premise sous une forme entièrement conteneurisée. Cette évolution marque une avancée importante en matière d'évolutivité, ainsi qu’en termes de portabilité et de flexibilité opérationnelle. L’adoption d’un modèle de déploiement moderne basé sur les conteneurs permet à ADONIS d’être installé plus efficacement dans les environnements informatiques actuels et futurs, tout en conservant les fonctionnalités déjà connues des versions précédentes.

Architecture​

Avec ADONIS 19, l'application est distribuée sous la forme d'un ensemble d'images de conteneurs conformes à la norme OCI. Cette approche conserve l'architecture fonctionnelle des versions précédentes d'ADONIS, tout en offrant un mode de déploiement plus flexible et moderne.

Les principaux composants applicatifs sont exécutés dans deux conteneurs séparés :

• conteneur de serveur web

• conteneur de serveur applicatif

Les images correspondantes sont mises à disposition via un registre conforme à la norme OCI.

ADONIS propose deux modes de déploiement :

• un déploiement sur Kubernetes, à l'aide du chart Helm fourni

• un déploiement via Docker Compose, à l'aide de la configuration Compose fournie

Les deux options de déploiement reposent sur les mêmes deux composants applicatifs conteneurisés. Kubernetes offre des capacités d'orchestration avancées avec des types de ressources spécialisés et des fonctionnalités d'intégration, ainsi qu'une architecture de cluster adaptée aux environnements d’entreprise. Docker Compose, quant à lui, propose une configuration plus simple, adaptée aux environnements ne nécessitant pas l’ensemble des fonctionnalités de Kubernetes.

La base de données ADONIS est généralement exploitée en dehors du cluster Kubernetes ou de l'environnement Docker. Les clients continuent de gérer leur serveur de base de données existant de manière indépendante.

Déploiement Kubernetes​

Le schéma suivant illustre le déploiement d'ADONIS 19 dans un environnement Kubernetes. Les composants applicatifs s'exécutent dans un espace de noms (namespace)dédié, tandis que les composants d'infrastructure de support sont généralement fournis dans d'autres espaces de noms.

Prérequis sur Kubernetes​

Le cluster Kubernetes dans lequel ADONIS sera exécuté doit fournir :

• un contrôleur Ingress ou un contrôleur Gateway API pour le routage du trafic des utilisateurs finaux

• une StorageClass pour la mise à disposition de volumes persistants

• Il est fortement recommandé de définir allowVolumeExpansion=true

Il est recommandé que le cluster fournisse également :

• cert-manager pour automatiser la gestion des certificats TLS pour ingress ou HTTPRoute

• ClamAV, exposant un point de terminaison TCP permettant l’analyse antivirus lors du téléchargement/chargement de fichiers

Détails architecturaux​

Espace de noms (Namespace) ADONIS​

Les composants applicatifs ADONIS s'exécutent dans leur propre espace de noms et se composent de :

• HttpRoute / Ingress, qui sert de point d'entrée du trafic externe vers l'espace de noms ADONIS.

• la couche serveur web, où le serveur web est exposé via un service Kubernetes et utilise un volume persistant pour stocker les fichiers logs locaux.

• la couche serveur applicatif, où le serveur applicatif est exécuté sous forme de déploiement distinct avec son propre service et un stockage persistant pour l'index de recherche en texte intégral ainsi que les fichiers logs locaux.

Autres espaces de noms (Namenspace)​

Composants au niveau du cluster qui prennent en charge le déploiement ADONIS :

• Contrôleur Ingress / Contrôleur gateway API pour le routage du trafic externe

• StorageClass utilisée pour le provisionnement de volumes persistants

• cert-manager (optionnel) pour l'automatisation des certificats TLS

• ClamAV (optionnel) pour l'analyse antivirus

Comportement du déploiement​

• Les déploiements du serveur web et du serveur applicatif prennent en charge la mise à l'échelle verticale via les requêtes /limites de mémoire et de CPU.

• À partir de Kubernetes 1.35, ces paramètres peuvent être modifiés au niveau du pod sans interruption de service.

• Chaque déploiement utilise une seule réplique; ADONIS 19 ne prend pas en charge la mise à l'échelle horizontale avec plusieurs répliques.

• Les fichiers logs locaux sont nécessaires pour permettre la génération d'un Support Information Package (SIP) directement depuis l’application, lequel est requis pour le support technique.

Base de données externe​

ADONIS utilise une base de données externe PostgreSQL ou MSSQL, exécutée en dehors du cluster Kubernetes et gérée de manière indépendante.

Déploiement avec Docker Compose​

Le schéma suivant illustre la manière dont ADONIS 19 peut être déployé sur un seul hôte à l'aide d'outils compatibles avec Docker Compose tels que Docker ou Podman.

Dans cette configuration, les conteneurs du serveur web et du serveur applicatif ADONIS s'exécutent sur la même machine. Les données persistantes sont stockées via des volumes Docker, et l'accès externe est généralement fourni via un proxy inverse.

Détails architecturaux​

Pile Docker Compose d'ADONIS​

La pile Compose se compose de :

• proxy inverse (par exemple nginx), qui traite les requêtes HTTP(S) entrantes et les redirige vers le serveur web ADONIS

• conteneur du serveur web

• conteneur du serveur applicatif

• volumes, utilisés pour stocker les fichiers logs locaux et l'index de recherche en texte intégral

Comportement du déploiement​

• Le serveur web et le serveur applicatif s'exécutent tous deux sur un seul hôte.

• Les volumes de conteneur garantissent la persistance des fichiers logs et des données d'index de recherche.

• La mise à l'échelle est limitée à une configuration à nœud unique; le déploiement distribués ou avec plusieurs répliques n'est pas pris en charge.

• Les fichiers logs locaux stockés dans des volumes permettent la génération d'un Support Information Package (SIP) pour le support hotline.

Base de données externe​

ADONIS utilise une base de données externe PostgreSQL ou MSSQL, qui est généralement exploitée en dehors de l'hôte Docker et gérée de manière indépendante.

Registre et mises à jour​

ADONIS 19 est distribué sous forme de conteneurs. Les artefacts de version suivants sont fournis.

Images de conteneurs​

L'application ADONIS est fournie sous la forme d'un ensemble d'images de conteneurs, comprenant notamment :

• une image de serveur web – fournit l'interface utilisateur et traite les requêtes HTTP(S)

• une image du serveur applicatif – exécute la logique de l'application ADONIS et les traitements côté serveur (backend).

Charts Helm​

Pour les déploiements basés sur Kubernetes, ADONIS fournit un chart Helm pour chaque version publiée d'ADONIS. Ce chart Helm définit les ressources Kubernetes ainsi que les paramètres de configuration nécessaires à l’exécution des composants ADONIS dans un environnement conteneurisé.

La livraison comprend un chart « umbrella » qui définit le déploiement complet d'ADONIS.

Ce Chart contient un fichier central values.yaml, qui spécifie notamment :

• les références aux images de conteneur

• les paramètres des ressources

• la configuration des services

• les paramètres spécifiques à l'environnement

Ces valeurs peuvent être personnalisées pour s'adapter à l'environnement cible.

Le chart Helm ne contient que la configuration de déploiement, telle que :

• la définitions des images de conteneurs

• les spécifications des ressources Kubernetes

• les paramètres de configuration

Aucune donnée applicative n’est fournie ou initialisée par le chart Helm.

Les données applicatives sont stockées de manière persistante dans la base de données configurée et ne sont donc pas affectées par le déploiement, la mise à niveau ou le redéploiement du chart Helm. Cela garantit que les déploiements restent sans état au niveau de la couche applicative, tandis que les données persistantes sont gérées de façon indépendante via la base de données et le stockage persistant configuré.

Distribution des artefacts​

Registre de conteneurs​

Toutes les images de conteneurs et tous les Charts Helm sont distribués via un registre officiel géré par BOC et conforme à la norme OCI.

• Les clients reçoivent une invitation par e-mail pour s'inscrire au registre.

• L'accès au registre est sécurisé par une authentification et un contrôle d’accès basé sur les rôles.

• Une fois inscrits, les clients peuvent gérer leurs propres identifiants d'accès (par exemple, clés d'accès ou jetons).

Ces identifiants peuvent être utilisés pour s'authentifier de manière sécurisée et récupérer les artefacts ADONIS nécessaires depuis le registre via :

• des environnements d'exécution de conteneurs (par exemple, Docker, containerd, Podman)

• des environnements Kubernetes

• des pipelines CI/CD ou des outils d'automatisation de déploiement

Environnements isolés​

Les images de conteneurs peuvent être répliquées dans des registres internes afin de prendre en charge les environnements restreints ou isolés.

Voici quelques exemples de solutions de registres internes :

• JFrog Artifactory

• Harbor

• Nexus Repository

Mises à jour​

Les mises à jour des images de conteneurs et des charts Helm suivent le processus standard de publication et de maintenance d'ADONIS. Les nouvelles versions des images sont publiées dans le registre de conteneurs OCI dans le cadre des versions officielles du produit, des mises à jour de maintenance ou des correctifs de sécurité.

Les clients sont informés des nouvelles versions via les canaux de communication habituels (tels que la documentation détaillée des nouveautés et contact avec le gestionaire de compte). Les images mises à jour peuvent ensuite être récupérées depuis le registre et déployées conformément aux procédures internes de déploiement et de mise à jour du client.

Les clients conservent le contrôle total sur le moment où les mises à jour sont appliquées dans leurs environnements.

Prérequis techniques​

Configuration requise pour le Client Web​

Les prérequis logicielles du Client Web ADONIS restent identiques à celles des versions précédentes d'ADONIS.

Navigateurs compatibles​

Il est recommandé d'utiliser les dernières versions des navigateurs pour garantir une fonctionnalité et une sécurité optimales.

Configuration requise pour le Serveur​

Environnement d'exécution de conteneurs (Runtime de conteneurs)​

ADONIS 19 prend en charge les environnements d'exécution de conteneurs conformes à la norme OCI sur architecture AMD64 (x86_64). Les plateformes suivantes sont supportées ou devraient être compatibles :

BOC Group exploite ADONIS dans son propre environnement SaaS basé sur Kubernetes. Les déploiements Kubernetes sont donc entièrement validés.

Système d'exploitation​

ADONIS 19 peut fonctionner sur les distributions Linux modernes prenant en charge Kubernetes ou Docker/containerd, telles que :

• Ubuntu

• Debian

• Red Hat Enterprise Linux (RHEL)

• SUSE Linux Enterprise Server (SLES)

Toute distribution Linux moderne capable d'exécuter le runtime de conteneurs choisi devrait être compatible.

Kubernetes et outils de déploiement​

Les déploiements d'ADONIS 19 sont généralement effectués via Kubernetes et Helm.

Base de données​

ADONIS nécessite une base de données externe pour stocker toutes les données persistantes du référentiel. Les prérequis en matière de base de données restent inchangées par rapport à la version précédente d'ADONIS. Les bases de données disponibles dans ADONIS 17 peuvent servir de référence.

Stockage persistant​

Un stockage persistant est requis pour l'index de recherche en texte intégral ainsi que pour les fichiers logs de l'application. Le stockage est généralement fourni via des volumes persistants (PV) et des revendications de volumes persistants (ou PVC : Persistent Volume Claims) de Kubernetes, configurés via le chart Helm fourni.

Réseau​

Les images de conteneurs sont distribuées via un registre conforme à la norme OCI et accessibles via HTTPS.

Les prérequis réseau typiques comprennent :

ADONIS est généralement exposé via un contrôleur Ingress Kubernetes, un contrôleur Gateway API ou un proxy inverse externe.

Le conteneur du serveur Web ADONIS expose port 8080 et ne termine pas lui même les connexions HTTPS.

Pour un accès chiffré (HTTPS), la terminaison TLS doit donc être assurée par le composant Ingress/Gateway dans Kubernetes ou par un proxy inverse dans les déploiements Docker Compose.

Prérequis matérielles (Hardware)​

Principes généraux​

HLes prérequis matérielles pour ADONIS 19 en environnement conteneurisé sont globalement comparables à celles des déploiements précédents basés sur Windowsows-based deployments. Les recommandations de dimensionnement matériel d'ADONIS 17 peuvent servir de référence.

Ressources typiques des composants​

Les valeurs suivantes indiquent les besoins typiques en CPU et en mémoire pour chaque conteneur ADONIS.

La consommation réelle des ressources dépend de plusieurs facteurs, tels que :

• le nombre d'utilisateurs simultanés

• la taille et la complexité du référentiel

• les activités de modélisation et de reporting

• les modèles de charge de travail de l'application

Exemple de configuration des ressources​

Les valeurs ci-dessous illustrent la manière dont le dimensionnement typique d'ADONIS peut être mis en correspondance avec les paramètres de ressources Kubernetes. Elles sont basées sur les valeurs recommandées ci-dessus et doivent être ajustées en fonction de la charge de travail réelle.

Conteneur du serveur Web​

Conteneur du serveur applicatif​

Configuration du déploiement et installation​

Approche de configuration​

La configuration d'ADONIS 19 suit deux mécanismes complémentaires :

Paramètres et configuration enregistrés dans l'application​

Ces paramètres sont gérés soit individuellement par les utilisateurs, soit de manière centralisée via l'administration d’ADONIS. Ils sont stockés dans la base de données d’ADONIS.

Exemples :

• la configuration de l'authentification

• l'administration des droits

• les paramètres de l'API REST

• les préférences au niveau de l'application

Paramètres et configuration lus depuis l'environnement​

Ces paramètres sont lus par l'application à partir de l'environnement d'exécution.

Dans les versions antérieures d'ADONIS, ces paramètres étaient stockés dans des fichiers .properties ou .conf situés dans les répertoires du serveur applicatif (par exemple, server.conf) ou de l'application web (par exemple, adoxx_web.properties).

Avec ADONIS 19, l'application est distribuée sous forme d'images de conteneurs pour le serveur applicatif et le serveur web. Étant donné que les conteneurs sont éphémères, la configuration basée sur des fichiers n'est plus prise en charge.

À la place, toutes les configurations spécifiques au déploiement sont désormais transmises via des variables d'environnement :

• Kubernetes : les variables sont définies dans le fichier values.yaml et transmises aux conteneurs lors du déploiement du chart Helm.

• Docker: les variables sont définies dans docker-compose.yml et appliquées au démarrage des conteneurs.

Configuration du serveur applicatif​

Les propriétés de configuration du serveur applicatif sont fournies sous forme de variables d'environnement via :

• le fichier Helm values.yaml (déploiements Kubernetes), ou

• le fichier docker-compose.yml (déploiements Docker)

Toutes les variables du serveur applicatif sont préfixées par ADOXX_.

Les exemples suivants montrent comment configurer le nom de la base de données ainsi que les ports des workers de l'application.

Kubernetes:

axx:
  aserver:
    env:
      - name: ADOXX_SERVER_DBNAME
        value: adonis19
      - name: ADOXX_SERVER_PORTS
        value: 5432,5432
  ...

Docker:

...
  aserver:
    image: adonis.image/aserver
    container_name: aserver
    ...
    environment:
      - ADOXX_SERVER_DBNAME=adonisdb
      - ADOXX_SERVER_PORTS=54321,54322
      ...

Configuration du serveur Web​

Les propriétés de configuration du serveur Web sont également fournies sous forme de variables d'environnement via les fichiers values.yaml (Kubernetes) ou docker-compose.yml (Docker).

Les variables du serveur Web sont préfixées par AXW_PROPERTIES_.

Les exemples suivants montrent comment configurer le serveur applicatif utilisé ainsi que les applications workers, et comment augmenter la taille maximale des fichiers logs REST à 300 Mo.

Kubernetes:

axx:
  ...
  webserver:
    env:
      - name: AXW_PROPERTIES_aservers
        value: AS1:adonis.host
      - name: AXW_PROPERTIES_aworkers
        value: AS1:54321,AS1:54322
      - name: AXW_PROPERTIES_axw_logger_appender_rest_maxfilesize
        value: 300MB
...

Docker:

...
  webserver:
    image: adonis.image/webserver
    container_name: webserver
    ...
    environment:
      - AXW_PROPERTIES_aservers=AS1:adonis.host
      - AXW_PROPERTIES_aworkers=AS1:54321,AS1:54322
      - AXW_PROPERTIES_axw_logger_appender_rest_maxfilesize=300MB
      ...

Une documentation détaillée des options de configuration sera fournie dans la documentation officielle d'ADONIS 19.

Exemple de configuration Kubernetes​

L'exemple suivant de fichier values.yaml présente une configuration minimale pour déployer ADONIS avec :

• une instance de serveur applicatif

• plusieurs workers

• les paramètres de connexion à la base de données

• la configuration des logs

• les paramètres d'exécution

Il définit les variables d'environnement pour les composants du serveur applicatif (aserver) du serveur web (webserver) ainsi que les paramètres de ressources et des fonctionnalités optionnelles telles que les points de terminaison de messagerie et de cycle de vie, servant de base pour un déploiement Kubernetes via Helm.

axx:
  aserver:
    env:
    - name: ADOXX_SERVER_DBNAME
      value: adonis19
    - name: ADOXX_SERVER_DBTYPE
      value: PostgreSQL
    - name: ADOXX_SERVER_DBPORT
      value: 5432
    - name: ADOXX_SERVER_DBHOST
      value: postgres.company.com
    - name: ADOXX_SERVER_WEBTIERAUTH_TRUSTED_HOSTS
      value: 127.0.0.*
    - name: ADOXX_LOG_MODE
      value: MIXED
    resources:
      limits:
        memory: 4096Mi
      requests:
        cpu: 500m
        memory: 2048Mi
    workerConf:
      count: 2
  instance:
    name: adonis19
  webserver:
    env:
    - name: AXW_PROPERTIES_mail_enabled
      value: 'true'
    - name: AXW_PROPERTIES_mail_server
      value: smtp.company.com 
    - name: AXW_PROPERTIES_mail_server_port
      value: '25'
    - name: AXW_PROPERTIES_mail_sender
      value: ADONIS <no-reply@company.com>
    - name: AXW_PROPERTIES_mail_reply_to
      value: no-reply@company.com
    - name: JAVA_OPTS
      value: -Xms512m -Xmx2048m
    - name: AXW_PROPERTIES_base_url
      value: https://adonis19.company.com
    - name: AXW_PROPERTIES_lifecycleops_endpoint_enable
      value: 'true'
    - name: AXW_PROPERTIES_axw_logger_console_enabled
      value: 'true'
    - name: AXW_PROPERTIES_axw_logger_root_level
      value: INFO
    httpRoute:
      hostnames:
      - adonis19.company.com
    resources:
      limits:
        memory: 4096Mi
      requests:
        cpu: 100m
        memory: 2048Mi

Exemple de configuration Docker Compose​

Cette configuration Docker Compose déploie ADONIS avec :

• une instance du serveur applicatif

• deux ports de workers

• une connexion à une base de données externe

• journalisation locale basée sur le volume

• un réseau de pont partagé

services:
 aserver:
    image: <boc-registry>/adonis/aserver:19.0.0
    container_name: aserver
    user: root
    ports:
      - 54321:54321
      - 54322:54322
    environment:
      - ADOXX_SERVER_PORTS=40180
      - ADOXX_SERVER_DBNAME=<adbname>
      - ADOXX_SERVER_DBTYPE=<PostgreSQL/SQLServer>
      - ADOXX_SERVER_DBHOST=<hostname/IPaddress>
#      - ADOXX_SERVER_DBPORT=5432 (for PostgreSQL)
      - ADOXX_SERVER_WEBTIERAUTH_TRUSTED_HOSTS=*.*.*.*
      - ADOXX_LOG_MODE=MIXED
      - TZ=Europe/Vienna
    volumes:
      - ./logs/aserver:/aserver/logs
    shm_size: "300mb"
    networks:
      aserver_webserver:

 webserver:
    image: <boc-registry>/adonis/webserver:19.0.0
    container_name: webserver
    user: root
    ports:
      - 8888:8080
    environment:
      - JAVA_OPTS=-Xms512m -Xmx2048m -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000
      - AXW_PROPERTIES_aworkers=AS1:54321,AS1:54322
      - AXW_PROPERTIES_aservers=AS1:aserver
      - AXW_PROPERTIES_axw_logger_console_enabled=true
      - AXW_PROPERTIES_axw_webserver_debug_enabled=false
      - AXW_PROPERTIES_axw_logger_root_level=INFO
      - AXW_PROPERTIES_base_url=https://adonis19.company.com
      - AXW_PROPERTIES_lifecycleops_endpoint_enable=true
      - AXW_PROPERTIES_mail_enabled=true
      - AXW_PROPERTIES_mail_server=smtp.company.com
      - AXW_PROPERTIES_mail_server_port=25
      - AXW_PROPERTIES_mail_sender=ADONIS <no-reply@company.com>
      - AXW_PROPERTIES_mail_reply_to=no-reply@company.com
      - TZ=Europe/Vienna
    volumes:
      - ./logs/webserver:/tomcat/logs
    networks:
      aserver_webserver

networks:
  aserver_webserver:
    driver: bridge
    enable_ipv6: true

Authentification et intégration des identitésn​

L’authentification dans ADONIS est gérée au niveau de l’application web et est indépendante du système d'exploitation sous-jacent. L'application web a toujours pris en charge plusieurs plateformes, notamment Linux, Solaris et Windows.

Authentification LDAP et SAML​

L'authentification LDAP et SAML n'est pas affectée par la migration vers un déploiement conteneurisé basé sur Linux.

La communication avec les systèmes d'identité utilise des protocoles réseau standard (LDAP, HTTP, HTTPS), qui sont indépendants du système d'exploitation.

Les configurations LDAP ou SAML existantes peuvent être réutilisées sans modifications spécifiques au système d'exploitation.

Impact sur la configuration​

L'authentification étant gérée au niveau de l'application web et reposant sur une communication indépendante du système d'exploitation, le passage à un déploiement conteneurisé n'entraîne aucun changement fonctionnel pour les mécanismes d'authentification pris en charge.

Seuls des ajustements spécifiques à l'environnement (par exemple, les noms d'hôte ou les paramètres réseau) peuvent être nécessaires.

Migration d'ADONIS 16.x/17.x vers ADONIS 19​

Ce guide fournit une vue d'ensemble de la migration d'ADONIS 16.x/17.x vers ADONIS 19.

Il met en évidence les principaux concepts, les changements architecturaux clés ainsi que les étapes essentielles de la migration.

Principaux changements conceptuels dans ADONIS 19​

Un changement technique majeur est introduit : le serveur applicatif ADONIS 19 ne fonctionne plus sous Windows ; il s'agit désormais d'un conteneur basé sur Linux et conforme à la norme OCI.

Approche de migration décrite dans ce guide​

La liste suivante résume le processus global de migration décrit dans ce guide (sous « Processus de mise à niveau »):

1. Exportez les configuration,, arrêtez les services ADONIS 16.x/17.x existants et sauvegardez les valeurs de configuration nécessaires.

2. Continuez à utiliser la base de données existante et effectuez une mise à niveau du schéma de la base de données après avoir effectué une sauvegarde.

3. Déployez ADONIS 19 via Kubernetes (Helm) ou Docker Compose, puis configurez toutes les valeurs liées au déploiement sous forme de variables d'environnement, sur la base des valeurs préalablement sauvegardées.

4. Effectuez les tâches post-installation au sein de l'application (mise à jour de la librairie, migration des paramètres, exécution de scripts).

Parmi ces étapes, les étapes 1, 2 et 4 suivent un schéma similaire aux précédents guides de mise à niveau d’ADONIS, tandis que l'étape 3 introduit le nouveau modèle de déploiement basé sur des conteneurs.

Prérequis​

Avant de commencer la migration, assurez-vous que les conditions suivantes sont remplies.

Prérequis relatives au système et à l’environnement :

• Un environnement d'exécution pris en charge doit être disponible (Kubernetes ou Docker Compose).

• Des ressources suffisantes doivent être disponibles pour les deux conteneurs ADONIS 19 (CPU, mémoire, stockage).

• Consultez la section Prérequis techniques pour en savoir plus.

Prérequis relatives à la base de données et aux sauvegardes :

• La base de données ADONIS existante (SQL Server ou PostgreSQL) doit être accessible depuis l'environnement d'exécution.

• Une sauvegarde de la base de données doit être réalisée avant toute modification.

Accès et identifiants :

• Accès administrateur à l’environnement ADONIS 16.x/17.x existant.

• Identifiants de déploiement pour Kubernetes ou Docker Compose.

• Identifiants de base de données disposant de privilèges suffisants pour se connecter à la base de données ADONIS et exécuter le script de mise à niveau du schéma ADONIS 19.

• Identifiants du registre de conteneurs permettant de s’authentifier auprès du registre de conteneurs BOC et, le cas échéant, auprès du registre de conteneurs de votre organisation.

Images de conteneurs et package d'installation :

Depuis le registre de conteneurs BOC :

• Images de conteneurs OCI pour :

  • le serveur applicatif

  • le serveur web

• Manifestes de déploiement :

  • values.yaml (Kubernetes)

  • docker-compose.yml (Docker)

Depuis le package d'installation (téléchargement) :

• Fichier de librairie (si vous utilisez la librairie BPMS ADONIS)

• Script de mise à niveau de la base de données

• Script de migration (si vous effectuez une mise à niveau depuis ADONIS 16.x)

Librairie pour ADONIS 19:

• Vous pouvez démarrer immédiatement si vous utilisez la librairie par défaut (Librairie BPMS ADONIS).

• Contactez votre consultant ADONIS si vous utilisez une librairie différente.

Processus de mise à niveau​

Les sections suivantes décrivent les principales étapes de la migration dans l'ordre dans lequel elles doivent être exécutées. Elles fournissent une vue d’ensemble des actions à réaliser, depuis l'arrêt de l'ancien système jusqu'au déploiement d'ADONIS 19 et à l’exécution des tâches finales au sein de l’application.

Export des paramètres des composants​

Dans un premier temps, les paramètres des composants de votre environnement ADONIS 16.x/17.x existant doivent être exportés :

• Exportez dès maintenant les paramètres des composants afin de pouvoir les réimporter ultérieurement, après la mise à niveau de la librairie.

• Exportez tous les paramètres en une seule fois ou, le cas échéant, sélectionnez uniquement ceux que vous souhaitez.

Arrêt des services​

Une fois les paramètres des composants exportés, l'environnement ADONIS 16.x/17.x existant peut être arrêté :

• Arrêtez le service du serveur applicatif ADONIS sur le système hôte actuel.

• Arrêtez le service Tomcat hébergeant l'application web ADONIS 16.x/17.x existante.

• Si une solution de suivi est en place, désactivez-la temporairement.

Sauvegarde des données spécifiques au déploiement​

Ensuite, sauvegardez les données spécifiques au déploiement de votre environnement ADONIS 16.x/17.x existant. Vous aurez besoin de ces informations ultérieurement lors de la configuration d'ADONIS 19.

• Sauvegardez les fichiers de configuration contenant des valeurs spécifiques à l'environnement (par exemple, nom de la base de données, ports, paramètres d'hôte/IP, paramètres personnalisés), tels que server.conf et adoxx_web.properties.

• Conservez tous les fichiers sauvegardés accessibles afin de pouvoir transférer les valeurs correspondantes dans les variables d'environnement d'ADONIS 19.

Mise à niveau du schéma de la base de données​

Mettez à niveau la base de données ADONIS existante vers le schéma ADONIS 19 :

• Créez une sauvegarde de la base de données dès maintenant si vous ne l'avez pas déjà fait.

• Exécutez le script de mise à niveau de la base de données ADONIS 19 correspondant à votre système (SQL Server ou PostgreSQL).

Préparation de l'environnement d'exécution​

Suivez les étapes correspondant à votre plateforme d'orchestration cible ci-dessous :

Déploiement Kubernetes​

Préparez l'environnement Kubernetes :

• Créez ou sélectionnez un namespace pour ADONIS.

• Assurez-vous que les StorageClasses nécessaires sont disponibles pour les volumes persistants.

• Assurez-vous qu'un contrôleur Ingress ou un contrôleur Gateway API est disponible. Le chart Helm prend en charge à la fois Ingress et HTTPRoute.

Déploiement Docker Compose​

Préparez l'environnement Docker :

• Assurez-vous que le runtime de conteneur est disponible (par exemple, Docker, containerd, Podman)

• Préparez les volumes Docker pour les fichiers logs et l'index de recherche.

• Vérifiez qu’un proxy inverse est disponible pour la terminaison HTTPS.

Préparation de la configuration (values.yaml ou docker-compose.yml)​

Préparez la configuration des variables d'environnement :

• Ajoutez les paramètres de connexion à la base de données.

• Configurez les ports des workers, les hôtes de confiance (trusted hosts) ainsi que les paramètres spécifiques à l'environnement : transférez les valeurs pertinentes depuis vos fichiers de configuration de sauvegarde (tels que server.conf et adoxx_web.properties).

• Pour Kubernetes: renseignez les valeurs dans values.yaml.

• Pour Docker: renseignez les valeurs dans docker-compose.yml.

Déploiement d’ADONIS 19​

Suivez les étapes correspondant à votre plateforme d'orchestration cible ci-dessous :

Kubernetes​

Déployez ADONIS 19 dans votre environnement Kubernetes à l'aide du chart Helm et des images de conteneur OCI fournis :

• Assurez-vous que le fichier values.yaml finalisé est disponible pour le déploiement.

• Exécutez la commande helm install pour déployer le chart dans votre namespace désigné.

• Le chart déploie les conteneurs du serveur applicatif et du serveur web, ainsi que toutes les ressources Kubernetes nécessaires (Services, Ingress, etc.).

Docker Compose​

Déployez ADONIS 19 dans votre environnement Docker à l'aide de la configuration Docker Compose fournie :

• Assurez-vous que le fichier docker-compose.yml finalisé est disponible dans votre répertoire de travail.

• Exécutez la commande docker-compose up -d pour récupérer les images OCI et initialiser les services.

Vérification du déploiement​

Après avoir déployé ADONIS 19, vérifiez que l'environnement fonctionne correctement :

• Assurez-vous que tous les conteneurs (pods Kubernetes ou services Docker) ont démarré avec succès.

• Accédez à l'URL d’ADONIS pour vérifier que l'application est accessible.

• Consultez les fichiers logs via les volumes persistants ou les fichiers logs des conteneurs.

Tâches post-installation​

Une fois ADONIS 19 en cours d'exécution, effectuez les tâches restantes dans l'administration d'ADONIS 19 :

• Mettez à jour la librairie.

• Réimportez les paramètres des composants exportés depuis votre environnement ADONIS 16.x/17.x existant.

• Si vous effectuez une mise à niveau depuis ADONIS 16.x, exécutez le script de migration 17.0 - repo.js pour aligner le contenu du référentiel avec la nouvelle méthode.

Vérifications finales​

Effectuez les vérifications finales pour vous assurer qu'ADONIS 19 est pleinement opérationnel :

• Vérifiez que les utilisateurs peuvent accéder à ADONIS comme prévu.

• Confirmez que le contenu du référentiel est disponible et s'affiche correctement.

• Exécutez des opérations standard (par exemple, modélisation, création de rapports, recherche) dans ADONIS pour valider les fonctionnalités de base.

• Si vous le souhaitez, intégrez le déploiement à votre solution de suivi.

Désinstallation d’ADONIS 16.x/17.x​

ADONIS 19 étant désormais pleinement opérationnel, l'ancien environnement ADONIS 16.x/17.x peut être supprimé :

• Désinstallez le serveur applicatif ADONIS 16.x/17.x via le panneau de configuration.

• Supprimez l'application web ADONIS 16.x/17.x d'Apache Tomcat.

La mise à niveau vers ADONIS 19 est maintenant terminée.

Sécurité​

Droits et autorisations​

Les images de conteneur ADONIS ne nécessitent pas de privilèges root.

Tous les processus à l'intérieur des conteneurs s'exécutent sous un utilisateur non root prédéfini(ADO).

Aucune autorisation supplémentaire au niveau de l'hôte ni aucun privilège Kubernetes élevé ne sont requis.

Principe de l'image minimale​

Les images de conteneurs ADONIS suivent une approchesans distribution (distroless).

Les composants et utilitaires inutiles du système d'exploitation sont supprimés, ce qui réduit la surface d'attaque et applique le principe de minimalisme.

Ressources du cluster​

Le déploiement ADONIS ne nécessite pas de conteneurs privilégiés ni de ressources Kubernetes globales. En particulier :

• aucun mode privilégié

• aucun NodePorts

• aucun opérateur Kubernetes

• aucun droit d'accès à l'échelle du cluster

Cela permet un déploiement dans des clusters d'entreprise restrictifs soumis à des politiques de sécurité strictes.

Namespaces et isolation des ressources​

Toutes les ressources Kubernetes nécessaires peuvent être déployées et exploitées entièrement au sein d'un seul namespace.

Cela permet une isolation au niveau du namespace, un contrôle d'accès basé sur les rôles (RBAC) ainsi que l’intégration avec des cadres de sécurité spécifiques à l'organisation.

Autorisations de stockage​

Le stockage persistant n'est requis que pour des composants spécifiques, tels que l'index de recherche en texte intégral et les fichiers logs d'application.

Les volumes persistants et les revendications de volumes persistants nécessaires sont définis via le chart Helm et ne nécessitent pas d'autorisations de cluster élevées.

L'accès est limité aux conteneurs du serveur applicatif et du serveur web ADONIS.

Exploitation​

Mise à l'échelle​

L’auto-scalabilité horizontale (Horizontal Pod Autoscaling – HPA) n'est pas pris en charge dans ADONIS 19.

La mise à l'échelle s'effectue donc principalement de manière verticale, en ajustant les ressources CPU et mémoire allouées aux conteneurs applicatifs.

Les charts Helm fournis permettent de déployer plusieurs instances du serveur applicatif. Comme pour les versions précédentes d'ADONIS, l'exécution de deux serveurs d'applicatifs ou plus est prise en charge et recommandée pour assurer une haute disponibilité.

L'allocation des ressources doit être dimensionnée en fonction :

• de la charge de travail prévue

• du nombre d'utilisateurs concurrents

• de l’utilisation globale du système

Journalisation et suivi​

Journalisation​

Les conteneurs du serveur web et du serveur applicatif génèrent des logs relatifs aux événements système et aux erreurs.

Afin de permettre la création du Support Information Package (SIP) dans ADONIS, les fichiers logs sont enregistrés sur un stockage persistant. Un volume persistant dédié est requis pour ces fichiers logs.

Le SIP est nécessaire pour le support et le diagnostic.

En plus de la journalisation basée sur des fichiers, ADONIS génère également des fichiers logs via les flux de journalisation standard des conteneurs (stdout/stderr).

Cela permet l'intégration avec des solutions de journalisation externes telles que les collecteurs de fichiers logs centralisés, les plateformes SIEM ou les data lakes.

Stockage et conservation des fichiers logs​

Les fichiers logs sont stockés sur le volume persistant configuré.

Les paramètres de conservation, de rotation et de remplacement peuvent être configurés via les paramètres de journalisation.

La durée de conservation effective dépend :

• de la configuration de la journalisation

• de l'infrastructure du client

• des politiques opérationnelles de l'organisation

Niveaux de logs​

ADONIS utilise les niveaux de logs suivants :

Les niveaux de logs fonctionnent de la même manière que dans les versions précédentes d'ADONIS sous Windows (ADONIS 17 et antérieures).

Configuration des logs​

Le comportement de la journalisation peut être configuré à l'aide de variables d'environnement fournies via :

• values.yaml (Kubernetes)

• docker-compose.yml (Docker)

Les paramètres configurables incluent :

• niveau de log

• taille maximale des fichiers

• historique maximal

• limites de taille totale des fichiers logs

Les détails des paramètres disponibles sont décrits dans la section relative à la configuration.

Protection des données dans les fichiers logs​

Les valeurs sensibles et les données personnelles consignées dans les fichiers logs sont pseudonymisées lorsque cela est possible.

Ce comportement est cohérent avec les versions précédentes d'ADONIS.

Format des fichiers logs​

La structure générale des fichiers logs reste largement cohérente avec les versions précédentes.

Quelques ajustements ont été apportés afin d'améliorer la cohérence entre les différents types de fichiers logs.

Un schéma détaillé sera inclus dans la documentation officielle d'ADONIS 19.

Suivi​

Suivi des logs​

ADONIS ne fournit pas de pile intégrée de fichiers logs.

Les clients sont invités à intégrer les fichiers logs ADONIS dans leur infrastructure d'observabilité ou de suivi existante.

ADONIS prend cela en charge grâce à :

• la sortie des fichiers logs via les mécanismes de journalisation standard des conteneurs (stdout/stderr)

• la compatibilité avec les agents de collecte de fichiers logs courants (par exemple, Fluent Bit)

• le transfert des fichiers logs vers des systèmes tels qu'OpenSearch, Elasticsearch ou des plateformes similaires

Dans les environnements Kubernetes, les fichiers logs des conteneurs sont généralement stockés temporairement sur le nœud puis collectés par un agent de traitement avant d'être transférés vers le système central de fichiers logs de l'organisation.

Les métriques et le suivi opérationnel peuvent être intégrées à des outils existants tels que Prometheus, Grafana ou d'autres plateformes de suivi d'entreprise.

Mécanismes de suivi​

ADONIS fournit des mécanismes intégrés de suivi pour les contrôles de santé au niveau de la plateforme.

Les images de conteneurs fournies incluent des exécutables utilisés pour les probes Kubernetes de réactivité et de disponibilité (liveness et readiness).

Des informations plus détaillées seront fournies dans la documentation officielle d’ADONIS 19.

Licences​

Les licences ADONIS existantes restent valides pour tous les scénarios d'utilisation actuels.

Le modèle de déploiement, qu'il soit basé sur Windows ou sur des conteneurs, n'a aucune incidence sur les conditions de licence applicables.

Support et cycle de vie​

L'introduction du modèle de déploiement conteneurisé ne modifie pas les politiques existantes en matière de support ou de cycle de vie des produits ADONIS.

Toutes les conditions de support, les services de maintenance et les règles de cycle de vie continuent de s'appliquer comme pour les versions précédentes d'ADONIS.