<table_of_contents color="gray"/>
¶ Ansible
Ansible est un outil d'automatisation open-source utilisé pour la gestion de la configuration, le déploiement d'applications et le provisionnement des infrastructures.
Il s'appuie sur des playbooks basés sur YAML et se connecte à des hôtes distants via SSH, sans nécessiter d'agent.
¶ Comment nous l'utilisons
- Nous demandons à nos clients de nous fournir des machines virtuelles Linux répondant à certaines spécifications ;
- Nous utilisons des scripts Ansible pour configurer ces machines (paramètres système, pare-feu, etc.) avec les exigences de k3s ;
- Le script Ansible installe K3s à l'aide d'Ansible Galaxy ;
- Enfin, le script Ansible déploie ArgoCD dans le cluster K3s pour préparer le déploiement des applications.
- Installer Qemu/Kvm pour les Data Cleanroom si nécessaire.
- Installer les dépendances Nvidia/GPU si nécessaire.
¶ Kubernetes
L'installation de la plateforme Arkhn inclut l'installation d'un cluster Kubernetes grâce à nos recettes Ansible, et plus précisément d'une distribution k3s.
Le processus d'installation comprend :
- la définition au sein de l'inventaire Ansible des différentes machines et de leurs rôles (agent ou server) ;
- la génération d'un token secret d'authentification partagé entre les différents noeuds du cluster ;
- la création d'un magasin de données clé-valeur etcd partagé entre les différents noeuds server du cluster (≥ 3) pour assurer une haute disponibilité du cluster Kubernetes.
💡 Le process complet d'authentification entre noeuds est détaillé dans la documentation officielle de k3s ci-après
¶ ArgoCD
ArgoCD est un outil de déploiement continu déclaratif pour Kubernetes, *basé sur *GitOps.
Il fait converger les clusters Kubernetes vers un état défini dans un dépôt Git.
¶ Caractéristiques principales
- Suivi des manifestes Kubernetes stockés dans Git ;
- Prise en charge des ****Helm ****charts ;
- Tableau de bord visuel pour l'état de la synchronisation, les différences et les journaux.
¶ Comment nous l'utilisons
- Les configurations et les applications de la plateforme sont définies dans des dépôts Git ;
- ArgoCD extrait les modifications et les applique au cluster K3s ;
- Git agit comme source unique de vérité : ArgoCD crée de nouvelles ressources et met à jour les ressources existantes pour qu'elles correspondent à l'état souhaité déclaré dans le référentiel Git correspondant.
¶ Dépôts Github
¶ Neogeo
Le dépôt Neogeo utilise Ansible, comme nous l'avons vu plus haut - c'est la première étape pour installer la plateforme Arkhn. Il déploie K3S et ArgoCD sur des VMs Linux fournies par notre client.
¶ Helm-charts
Le dépôt Helm-charts est le coeur de la plateforme Arkhn, contenant tous les Helm charts nécessaires au déploiement de la plateforme. Lorsque ce dépôt est mis à jour, ArgoCD, qui est déjà installé par Neogeo, nous permet de déployer les changements facilement via une interface utilisateur.
Le dépôt est divisé en plusieurs charts pour chaque fonctionnalité de la plateforme, que nous détaillons dans https://www.notion.so/225403a7adf380cf92c4d40382383f1e.
Il contient également tout le code de construction des images de conteneurs, exécuté par des workflow d'intégration continue GitHub.
¶ deployment-template / deployment-<hôpital>
En plus du dépôt générique helm-charts, nous déployons la plateforme avec des dépôts spécifiques à l'environnement de chaque client.
Objectif
Chaque dépôt contient une configuration spécifique pour un environnement donné, comme par exemple :
- Configurations personnalisées Ansible (Neogeo) ;
- Configurations personnalisées ArgoCD pour la plateforme ou arkhn-assistant ;
- Pipelines de données personnalisés, connecteurs, etc. (DBT, Dagster, Codex...)
Ces référentiels nous permettent de gérer les différences entre les clients sans dupliquer la logique de base de la plateforme.
¶ Codex
¶ Codex est un projet DBT.
Les hôpitaux fonctionnent généralement avec plusieurs bases de données logicielles, chacune avec sa propre base de données et sa propre structure. Ces bases de données utilisent souvent des schémas, des noms de colonnes et des formats différents.
Pour unifier ces données hétérogènes, nous avons créé le projet Codex. Codex regroupe les scripts DBT qui récupèrent les données au format propriétaire des bases des progiciels, puis les intègre dans des tables standards.
Codex agit comme notre base de connaissances interne, intégrant la logique de transformation, les clients DBT et les mappings pour les logiciels hospitaliers que nous avons déjà rencontrés.
Vous trouverez ci-dessous l'architecture générale du pipeline Codex. Il s'agit d'un pipeline ELT.
L'étape pivot contient des tables proches de la norme OMOP.
La dernière étape de ce pipeline fait référence à des bases de données qui sont utilisées dans différents projets ou applications. Par exemple, OMOP et FHIR sont des formats standards interopérables.
¶ Admin
Arkhn Admin est un outil conçu pour les Data Engineers, Data Managers, et autres (DSI, DRCI, etc.) pour gérer l'EDS** ****( ***Entrepôt de données de santé *) et administrer les applications associées. Comme son nom l'indique, il permet simplement aux utilisateurs d'administrer le produit et ses données. Il peut également gérer la création, la configuration et la suppression des Data Cleanrooms, que nous aborderons plus tard.
Contrairement à beaucoup de nos autres produits, Admin a son propre dépôt Git car il s'agit d'une application développée intégralement par Arkhn avec le framework Django. Par conséquent, elle nécessite non seulement un Helm chart, mais aussi un dépôt Git contenant le code source. A partir de ce code source, nous construisons une image Docker qui peut être récupérée lors du déploiement du Helm chart correspondant.
Le dépôt Git Admin ne se limite pas à l'interface Admin d'Arkhn. Il comprend également l'application Explore, qui permet aux clients de tirer avantage des données à l'aide de graphiques, de statistiques, de filtres, etc.
Pour résumer, Lle dépôt Admin contient :
- le frontend Arkhn Admin : React ;
- le frontend Arkhn Explore : React ;
- le backend : Python Django.
¶ Dagster
Dagster est un framework open-source utilisé pour orchestrer (définir, planifier et surveiller) les pipelines de données.
Il permet aux équipes de structurer les flux de données en Python et d'exécuter chaque étape de manière fiable et traçable.
Ce qu'il y a dans le dépôt :
- Docker : Dagster est construit comme une image docker, destinée à être déployée via le dépôt Helm-charts ;
- orchestration : pipelines Dagster, assets DBT issus de Codex, extraction de données non structurées (PDF, SMB) et ingestion dans MinIO.