Informations techniques sur le produit ADOIT 21

Aperçu​

À partir d'ADOIT 21, 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 à ADOIT 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 ADOIT 21, 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'ADOIT, 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.

ADOIT 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 ADOIT 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'ADOIT 21 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 ADOIT 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) ADOIT​

Les composants applicatifs ADOIT 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 ADOIT.

• 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 ADOIT :

• 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 recréer le Pod.

• Chaque déploiement utilise une seule réplique; ADOIT 21 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​

ADOIT utilise une base de données externe PostgreSQL ou Microsoft SQL Server, 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 ADOIT 21 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 ADOIT 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'ADOIT​

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 ADOIT

• 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​

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

Registre et mises à jour​

ADOIT 21 est distribué sous forme de conteneurs. Les artefacts de version suivants sont fournis.

Images de conteneurs​

L'application ADOIT 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 ADOIT et les traitements côté serveur (backend).

Charts Helm​

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

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

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 ADOIT 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'ADOIT. 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 ADOIT restent identiques à celles des versions précédentes d'ADOIT.

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)​

ADOIT 21 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 ADOIT dans son propre environnement SaaS basé sur Kubernetes et utilise Docker ainsi que Docker Compose pour le développement, les tests et la validation en interne. Ces environnements sont donc entièrement validés.

Les plateformes classées comme « compatibles attendues » ne sont pas testées ou validées individuellement, mais elles sont supposées fonctionner correctement dès lors qu'elles sont conformes aux normes Kubernetes et OCI correspondantes.

Système d'exploitation​

ADOIT 21 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'ADOIT 21 sont généralement effectués via Kubernetes et Helm.

Base de données​

ADOIT 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'ADOIT. Les bases de données disponibles dans ADOIT 19 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 :

ADOIT 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 ADOIT 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​

Les prérequis matérielles pour ADOIT 21 en environnement conteneurisé sont globalement comparables à celles des déploiements précédents basés sur Windows-based deployments. Les recommandations de dimensionnement matériel d'ADOIT 19 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 ADOIT.

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'ADOIT 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'ADOIT 21 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’ADOIT. Ils sont stockés dans la base de données d’ADOIT.

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'ADOIT, 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 ADOIT 21, 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 application workers (aworker).

Kubernetes:

aserver:
  env:
    - name: ADOXX_SERVER_DBNAME
      value: adodb
    - name: ADOXX_SERVER_PORTS
      value: 5432,5432

Docker:

aserver:
  image: adoit.image/aserver
  container_name: aserver
  ...
  environment:
    - ADOXX_SERVER_DBNAME=adodb
    - 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:

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

Docker:

webserver:
  image: adoit.image/webserver
  container_name: webserver
  ...
  environment:
    - AXW_PROPERTIES_aservers=AS1:adoit.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'ADOIT 21.

Exemple de configuration Kubernetes​

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

• une instance de serveur applicatif

• plusieurs aworkers

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

aserver:
  env:
  - name: ADOXX_SERVER_DBNAME
    value: adodb
  - 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: adoit21
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: ADOIT <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://adoit21.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:
    - adoit21.company.com
  resources:
    limits:
      memory: 4096Mi
    requests:
      cpu: 100m
      memory: 2048Mi

Exemple de configuration Docker Compose​

Cette configuration Docker Compose déploie ADOIT avec :

• une instance du serveur applicatif

• deux ports de aworkers

• 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>/adoit/aserver:21.0.0
    container_name: aserver
    user: ado
    ports:
      - 54321:54321
      - 54322:54322
    environment:
      - ADOXX_SERVER_PORTS=54321,54322
      - ADOXX_SERVER_DBNAME=adodb
      - ADOXX_SERVER_DBTYPE=PostgreSQL
      - ADOXX_SERVER_DBHOST=postgres.company.com
#      - ADOXX_SERVER_DBPORT=5432
      - 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>/adoit/webserver:21.0.0
    container_name: webserver
    user: ado
    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://adoit21.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=ADOIT <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 ADOIT 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'ADOIT 17.x/18.x vers ADOIT 21​

Un guide de migration qui vous aidera à mettre à niveau ADOIT de la version 17.0 – 17.7 ou 18.0 – 18.2 vers la version 21.0 dans un environnement Kubernetes sera fourni dans le Manuel d'installation d'ADOIT 21.

Le processus de mise à niveau diffère considérablement de celui des versions précédentes d'ADOIT. Le serveur applicatif ainsi que le serveur web sont tous deux déployés sous forme de services conteneurisés. Afin de simplifier le processus de migration, ADOIT 21.0 fournit l'outil de gestion aupgrade_product. Cet outil met à niveau une base de données existante vers la nouvelle version et exécute automatiquement les tâches de migration requises, notamment la mise à niveau du schéma de la base de données, la mise à jour de la bibliothèque d'applications, l'exécution des scripts de migration et la conservation des paramètres des composants.

Le processus de migration comprend les étapes générales suivantes :

1. Arrêter les services ADOIT existants.

2. Sauvegarder les fichiers de configuration spécifiques au déploiement.

3. Mettre à niveau la base de données à l'aide de aupgrade_product.

4. Déployer ADOIT 21.0 dans Kubernetes à l'aide de la configuration sauvegardée.

5. Vérifier le déploiement et supprimer l'ancienne installation.

Migration depuis toutes les autres versions vers ADOIT 21.0​

ADOIT 20.0 est disponible uniquement pour les clients SaaS hébergés sur AWS. Comme toutes les mises à niveau de la version 20.0 vers la version 21.0 sont l'œuvre de l'équipe BOC Cloud Operations, aucun guide de migration n'est fourni pour cette version. Si vous utilisez ADOIT 16.0 ou une version antérieure, veuillez contacter votre consultant ADOIT pour obtenir de l'aide concernant les étapes de mise à niveau requises.

Sécurité​

Droits et autorisations​

Les images de conteneur ADOIT 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 ADOIT suivent une approche sans 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 ADOIT 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 ADOIT.

Exploitation​

Mise à l'échelle​

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

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'ADOIT, l'exécution de deux serveurs d'applicatifs ou plus est prise en charge et recommandée afin de répartir la charge de travail sur plusieurs serveurs.

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 ADOIT, 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, ADOIT 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​

ADOIT 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'ADOIT sous Windows.

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'ADOIT.

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'ADOIT 21.

Suivi​

Suivi des logs​

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

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

ADOIT 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​

ADOIT 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’ADOIT 21.

Licences​

Les licences ADOIT 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 ADOIT.

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'ADOIT.