Ce document décrit succintement comment est déployée la GED, et quels sont les prérequis que le client doit mettre à disposition. Par client il faut entrendre soit son propre département IT, soit son prestataire.
Il est important de bien prendre connaissance des éléments présentés ici et de respecter les prérequis, sans quoi l’installation de la GED devra être différée jusqu’à mise à disposition des éléments demandés.
Certains prérequis dépendent du client. La volumétrie, le nombre d’utilisateurs, le nombre de GED… ont un impact sur les ressources à allouer. Par conséquent le représentant technique du client devra systématiquement prendre contact avec les équipes techniques d’Adhoc-GTI en charge du déploiement de la GED afin de définir ensemble les ressources nécessaires en fonction de ces éléments variables.
La GED est déployée sur un système GNU/Linux, virtualisé, en utilisant Docker pour minimiser le couplage entre la partie logicielle et le système hébergeant la GED. Docker est installé par Adhoc-GTI, aucune compétence côté client n’est requise sur ce point.
La GED stocke ses données :
Les documents sont stockés hors base de données en raison de la volumétrie généralement très importante. Toujours en raison de la volumétrie, il est vivement recommandé de stocker ces données sur des systèmes de fichiers externes à la machine virtuelle. Ce point est détaillé plus loin.
La GED est accessible à travers des webservices et un navigateur. Les documents sont traités par l’intermédiaire de ces derniers, et ne doivent pas être accessibles directement par les utilisateurs.
L’hyperviseur utilisé est au choix du client tant qu’il est compatible avec les prérequis, et maintenu à jour régulièrement.
La GED doit être déployée sur une VM basée sur Ubuntu Server 22.04 LTS (x64).
Le système doit être installé à minima, avec uniquement un accès SSH (OpenSSH) sans aucun autre logiciel ou couche graphique. Le reste sera installé par Adhoc-GTI dans les versions exactes souhaitées (et supportées).
En aucun cas Docker, MariaDB, … ne devront être installés lors de la mise à disposition du système à Adhoc-GTI.
Quelques notes d’installations sont disponibles en fin de document.
En aucun cas le système ne pourra être le clone d’un système déjà existant, même d’une autre GED. Le processus d’installation est suffisamment simple et rapide pour éviter ces pratiques.
Le disque virtuel de la VM doit avoir une taille de 48 Go minimum.
Il est inutile de découper le disque en plusieurs partitions (hormis /boot). La partition montée à la racine (/) devra être basé sur LVM (Logical Volume Manager) et formatée en ext4. L’installation par défaut correspond à ces besoins, ces points sont donnés à titre d’information.
En de rares occasions le volume de données au sein de la VM peut être amené à augmenter au point de nécessiter une extension. L’usage de LVM facilitera grandement cette opération (à la charge du client).
La VM doit disposer à minima de :
Ces métriques sont adaptées à des petites structures et doivent être dimensionnées en fonction des besoins réels du client et après avoir fait l’objet d’un échange technique (avant installation du système).
Indépendemment de ce qui est convenu à l’installation, l’usage et son évolution peuvent amener à revoir ces ressources à la hausse.
Adhoc-GTI doit avoir accès au système via SSH.
Un utilisateur dédié à Adhoc-GTI sera mis à disposition. Cet utilisateur doit être membre du groupe sudo. Il peut être celui créé lors de l’installation de la VM, ou un autre compte créé à postériori et rendu membre du groupe sudo.
Les données liées à MariaDB et elasticsearch sont gérées au sein même de la VM, leurs volumétries dépassent rarement quelques Go à quelques dizaines de Go.
Les documents sont impérativement stockés à part afin de faciliter la gestion de la volumétrie. La solution recommandée est de stocker ces documents en dehors de la VM via des partages SMB (depuis un serveur Windows, ou une baie de disques). Ces partages sont si possible montés par le client, mais Adhoc-GTI peut réaliser cette opération.
L’usage de partages NFS est possible, à chaque intégrale du client (partages et montages).
Les partages devront être accessibles via un compte dédié à cet usage. Les contenus de ces partages doivent être accessibles en lecture/ecriture pour ce compte. Exception faite des comptes d’administration et comptes de services (backup, …) aucun autre compte/groupe d’utilisateur ne doit y avoir accès directement (local) ou indirectement (via partage). Charge au client de mettre en place les droits nécessaires. Ce point est extrêmement important car il réduit considérablement les risques en cas de maladresse ou d’infection par un crypto-malware.
Une dernière solution est de stocker les documents sur des disques virtuels montés sur la VM. Cette solution bien que possible n’est pas recommandée car offrant beaucoup moins de souplesse lors d’opérations de maintenance ou de migration. Si elle devait tout de même être retenu l’usage de LVM serait impératif, et la gestion de l’ensemble à la charge intégrale du client.
Les volumes de stockages destinés aux documents, qu’ils soient des disques locaux ou des points de montages doivent êtres montés sous-répertoire de /mnt/ged, par exemple :
/mnt/ged/xxx (xxx étant pas exemple le nom du courtier/compagnie)./mnt/ged/xxx/production .La VM de la GED doit être accessible en SSH par Adhoc-GTI, de façon simple. Cela peut-être à travers un VPN (compatible Windows/OSX/Linux).
La GED doit être accessible depuis les environnements clients (généralement le logiciel Adhoc) via les protocoles HTTP et HTTPS.
L’usage de HTTPS est possible en interne sous réserve de mise à disposition de certificats par le client. Il appartiendra également au client d’en gérer l’expiration et de fournir à Adhoc-GTI de nouvelles versions à minima 3 semaines avant leurs expirations.
La VM de la GED a besoin de réaliser des accès sortants vers internet pour télécharger les éléments à installer, les mises à jour du système, et des images de containers (docker). Ces accès sont en HTTP/HTTPS, ou SCP (via SSH). Ce qui implique également tout ce qui est nécessaire aux résolutions DNS soit via des serveurs internes, soit des serveurs publics.
Chaque service de GED est accessible uniquement en HTTP/HTTPS, il faudra fournir des noms DNS (accessibles en internes) dont les enregistrement A/AAAA ou CNAME pointent vers la VM. Il est question de noms dédiés aux services de la GED qui doivent être différents du nom DNS du système lui-même. Il faut à minima deux noms DNS :
ged-production.courtier.local)ged-recette.courtier.local)Ces noms DNS n’ont pas besoin d’être publics, il suffit qu’ils soient connus des environnements clients (serveurs RDS ou postes individuels).
Généralement la GED n’a pas à être accessible depuis le WAN, uniquement depuis l’infrastrucure interne du client. Exception faite d’un besoin de couplage avec un extranet. Voir la section dédiée plus loin.
Voici une synthèse des prérequis, qui devront être affinés avec les équipes techniques d’Adhoc-GTI avant l’installation de la VM :
sudo.De manière générale, Adhoc-GTI fournit les logiciels et les prestations d’installation et maintenance associées.
La gestion de l’infrastructure est à la charge intégrale du client.
Il appartient au client de gérer la sauvegarde de la GED à travers :
La durée de rétention recommandée est d’au moins 15 jours.
La GED effectue un dump des bases MariaDB au moins une fois par jour localement, afin de disposer de bases dans un état stable.
L’accès à MariaDB par le client est possible (le port 3306 est exposé), ouvrant la porte à des stratégie complémentaires.
Les données liées à elasticsearch ne font l’objet d’aucun dump ou copie d’aucune sorte. Ce sont de simples indexes destinées à des recherches non courantes, et sont reconstructibles en cas d’incident.
A tout moment du projet, le client peut se rapprocher d’Adhoc-GTI pour faire un point sur ces aspects.
La gestion des volumes disques est un problème d’infrastructure à la charge du client. Par ailleurs une fois en production Adhoc-GTI ne se connecte qu’occasionellement pour des opérations de mises à jour ou des diagnostiques à la demande, et ne peut donc prendre en charge ces aspects.
Il appartient donc au client de surveiller ces volumes pour anticiper toute saturation, et d’étendre les volumes si nécessaire.
Un extranet peut être amené à accéder à la GED. La plus souvent c’est la solution courtier en ligne fournie par Adhoc-GTI, mais cela peut également être une solution tierce propre au client.
Dans ce cas la GED devra être accessible d’internet en HTTPS. Il faudra donc configurer les accès réseaux en conséquence, et éventuellement anticiper ce point en mettant la GED dans une DMZ dès le départ.
La stratégie est de ne permettre l’accès qu’aux extranet via un filtrage par leurs adresses IP publiques. Ceci limite considérablement les risques d’attaques/intrusions, mais a pour conséquence de ne pas permettre l’usage de Let’s Encrypt.
Si l’extranet est la solution courtier en ligne, Adhoc-GTI mets généralement en place ses propres certificats (privés) et gère le nom DNS public. Le client peut cependant prendre en charge ces aspects s’il le souhaite, voir mettre en place un reverse proxy qui lui en propre.
Si l’extranet est une solution tierce, il appartiendra au client de fournir les certificats (qu’Adhoc-GTI pourra installer) et gérer les noms DNS. Là aussi l’usage d’un reverse proxy géré par le client est possible.
Ci-dessous quelques remarques concernant le processus d’installation du système afin qu’il soit conforme aux attentes, et aussi aisé que possible pour ceux qui ne seraient pas familiers avec l’opération.
Les remarques sont mentionnées dans l’ordre correspondant aux opérations. Toutes les opérations ne font pas nécessairement l’object d’une remarque.
/ (à faire sous USER DEVICES).