4.1 Plan

Voici le plan de déploiement imaginé au 13/06/2023 (aucun environnement cible n’existe encore à cette date).

4.1.1 - Les composants applicatifs et leurs contraintes

Les services du socle sont des fonctionnalités que peuvent proposer les fournisseurs de Cloud. Ils ne seront donc pas tous installés en production. Mais, ceux développés permettent de démarrer, sur le poste local ou sur un serveur OnPremise, un SI complet.

Sont définies 3 catégories de composants :

  • catégorie 3 : le composant est vital et doit être redondé pour assurer le fonctionnement du système.
  • catégorie 2 : le composant n’est pas assez vital pour que tout le SI soit indisponible s’il est absent. Mais son indisponibilité réduit les fonctionnalités proposées aux usagers.
  • catégorie 1 : le composant peut être indisponible sans gêne particulière pour les fonctionnalités proposées aux usagers mais son absence réduit les fonctionnalités du SI.
  • catégorie * : certains composants à la criticité faible peuvent nécessiter plusieurs instances pour tenir la charge induite par les usagers.

Sont aussi définies

  • des couches réseaux
    • exposée
    • interne
    • profonde
  • et des colonnes séparant les instances des applicatifs dans des zones réseaux verticales (DNS dédié obligatoire)
    • exécution
    • administration

Voici les contraintes et la catégorisation de tous les services :

  • services-cloud
    • service-admin : [catégorie 1] [interne] [administration] Le service d’administration n’a pas besoin d’être redondée. S’il est absente, le SI continue son travail. Seules les équipes réalisant des analyses ou souhaitant modifier une configuration sont gênées. Elles résolveront le problème en cours et pourront de nouveau travailler une fois l’application de nouveau disponible.
    • service-config : [catégorie 1] [interne] [administration] Sans mise à disposition des configurations, de nouvelles instances de micro-services ne peuvent pas démarrer et leur configuration ne peut pas être rechargée (action depuis le service d’administration).
    • service-elastic : [catégorie 1] [profonde] [administration] Sans base de données Elasticsearch, les lignes de log ne peuvent pas être centralisées. Mais les fichiers de log sur cheque serveur ne sont pas perdus pour autant. Donc, dès que Elasticsearch est de nouveau disponible, les FileBeat lui enverront les logs. Mais, par principe, un sreveur ElasticSearch est obligatoirement installé sur plusieurs serveurs différents (plusieurs noeuds) pour assurer l’intégrité des données (copie de shard).
    • service-gateway : [catégorie 3] [exposée] [exécution] La Gateway est le point d’entrée de toute requête HTTP vers une API du socle. Elle est hautement nécessaire et donc redondée.
    • service-ldap : [catégorie 1] [profonde] [administration] Le LDAP permet l’authentification du service d’administration et de l’application d’administration. Il n’est pas plus critique que ces deux applications.
    • service-nosql : [catégorie 3] [profonde] [exécution] Sans les configurations (publiques et internes), aucune démarche n’est disponible aux usagers. Cette base de données est donc primordiale.
    • service-redis : [catégorie 1] [profonde] [exécution] Ce composant apporte de la sécuritée (anti-DDOS) pour la Gateway. Il n’apporte rien aux usagers. Il participe à protéger le SI.
    • service-registry : [catégorie 3] [profonde] [exécution] Sans registre, les différents services et micro-services ne peuvent pas communiquer entre eux. Il est indispensable et à redonder.
  • micro-services :
    • socle-adminpsl : [catégorie 1] [interne] [administration] L’application d’administration n’a pas besoin d’être redondée. Si elle est absente, le SI continue son travail. Seules les équipes réalisant des analyses ou souhaitant modifier une configuration sont gênés. Ils résolveront le problème en cours et pourront de nouveau travailler une fois l’application disponible.
    • socle-dbbrouillon : [catégorie 2] [interne] [exécution] Sans sauvegarde ou chargement de brouillon, les usagers peuvent toujours renseigner et soumettre des télé-dossiers.
    • socle-dbconfiguration : [catégorie 3] [interne] [exécution] Sans les configurations (publiques et internes), aucune démarche n’est disponible aux usagers.
    • socle-dbdocument : [catégorie 3] [interne] [exécution] Sans upload de pièce jointe et stockage de documents générés, aucune soumission n’est possible. Cet applicatif est donc indispensable et doit être rendondé.
    • socle-dbnotification : [catégorie 3] [interne] [exécution] Ce composant participe à la soumission d’un télé-dossier. Il est donc indispensable.
    • socle-referentiel : [catégorie 2*] [interne] [exécution] Ce composant donne accès à un référentiel. Si une démarche n’utilise aucun de ces référentiels, elle peut être parcourue et des télé-dossiers peuvent être soumis.
    • socle-referentielexterne : [catégorie 2*] [interne] [exécution] Ce composant donne accès à un référentiel. Si une démarche n’utilise aucun de ces référentiels, elle peut être parcourue et des télé-dossiers peuvent être soumis.
    • socle-securite : [catégorie 3] [interne] [exécution] Ce composant permet toutes les authentifications (OIDC, anonyme et par mot de passe). Sans lui, aucune API ne peut être appelée.
    • socle-soumission : [catégorie 3] [interne] [exécution] Ce composant porte la soumission d’un télé-dossier. Il est donc indispensable.
    • socle-transfert : [catégorie 1*] [interne] [administration] Si ce composant est indisponible, les télé-dossiers soumis s’accumuleront. Mais, à son redémarrage, les traitements seront réalisés au fur et à mesure sans perte de données.
  • autres :
    • les applications WEB des démarches :[catégorie 3] [exposée] [exécution] Les applications des démarches sont la partie visible du système
    • les applications WEB d’administration :[catégorie 1] [interne] [administration] Les applications d’administration ne sont pas nécessaires au bon fonctionnement. Elles sont utiles pour la gestion/configuration/administration uniquement.

4.1.2 - Plan de déploiement

En reprenant les besoins décrits au chapitre précédent et les intégrant dans un tableau représenant les zones et colonnes réseau :

Colonne ADMIN Colonne EXECUTION
Zone exposée
  • service-gateway x3
  • applications WEB des démarches x3
Zone interne
  • service-admin x1
  • service-config x1
  • socle-adminpsl x1
  • socle-transfert x2
  • applications WEB d'administration x1
  • socle-dbbrouillon x3
  • socle-dbconfiguration x1
  • socle-dbdocument x3
  • socle-dbnotification x3
  • socle-referentiel x2
  • socle-referentielexterne x2
  • socle-securite x3
  • socle-soumission x3
Zone profonde
  • service-elastic x3
  • service-ldap x1
  • service-nosql x3
  • service-redis x1
  • service-registry x3

A partir de ces besoin et sans disposer des résultats d’un tir de performance, il parait logique et suffisant de créer un nombre limiter de machines identiques entre elles (pour simplifier les déploiements) sur le modèle suivant :

Colonne ADMIN Colonne EXECUTION
Zone exposée 3 machines
Zone interne 2 machines 3 machines
Zone profonde 3 machines 3 machines

4.1.3 - Besoins vis-à-vis de l’hébergeur/exploitant

Le SI semble donc nécessiter 14 machines Unix répondant aux critères suivants

  • [toutes] est installé un OS unix récent (distribution au choix de l’hébergeur/exploitant) et maintenu à jour par l’expoitant
  • [toutes] sont ouverts les flux vers toutes les zones inférieures (la gateway a besoin de l’accès au registre)
  • [zone exposée et interne] Internet est accessible en passant par un même dispositif réseau (pour assurer une unique IP publique du SI facilitant ainsi la configuration des filtres par IP des partenaires)
  • [profonde] la capacité de disque est importante et taillée en fonction des tirs de performance réalisés (par défaut 300Go)
  • [toutes] aucun logiciel précis n’est à préinstaller sur les machines (Ansible sera utilisé pour installer tous les éléments nécessaires et réaliser les montées de version sauf indication contraire de l’hébergeur/exploitant)

En plus de ces caractéristiques, la sécurité périphérique du SI est à la charge de l’hébergeur/exploitant. Ceci comprend (liste non exhaustive)

  • un filtrage de sécurité basé sur les signatures standards d’attaque
  • la sécurisation des accès SSH d’administration/exploitation
  • … (à compléter)

Les machines sont donc identifiées avec un code XXX_YYY_Z avec

  • XXX la colonne réseau,
  • YYY la couche réseau
  • Z l’indice de la machine.

On obtient ainsi la liste des machines suivantes :

  • EXE_EXP_1, EXE_EXP_2, EXE_EXP_3
  • EXE_INT_1, EXE_INT_2, EXE_INT_3
  • EXE_PRO_1, EXE_PRO_2, EXE_PRO_3
  • ADM_INT_1, ADM_INT_2
  • ADM_PRO_1, ADM_PRO_2, ADM_PRO_3

4.1.4 - Installation avec Ansible

La création des machines n’est pas dans le périmètre actuel de ce projet. Elles sont identifiées telles que le définit le chapitre précédent.

La répartition du déploiement des applicatifs sur les machines est lisible dans le fichier d’inventaire

Les scripts doivent être construits pour installer l’ensemble des éléments nécessaires au bon fonctionnement d’un applicatif sur un serveur. Ainsi, chaque installation d’un applicatif passe, par exemple, par l’installation de Java (si Java est déjà installé, Ansible ne fera rien). Avec ce principe, les scripts ne sont pas à refaire si le plan de déploiement change et il est même envisageable d’installer rapidement une machine supplémentaire avec seulement un unique applicatif alors que ce dernier est systématiquement installé avec d’autres sur les autres machines de l’environnement.

Les scripts/configurations Ansible du projet ias permettent :

  • pour toutes les machines
    • de paramétrer un groupe et un utilisateur UNIX (www:www)
  • pour les micro-services
    • d’installer la bonne version de Java (identique sur toutes les machines - cf version dans la page A faire).
    • de télécharger le binaire applicatif à installer
    • de déposer le binaire dans le répertoire ${repertoirePsl}${nomApplicatif}
    • de déposer la configuration nécessaire dans ce même répertoire
    • de déposer les scripts de démarrage et d’arrêt dans ce même répertoire
    • d’installer FileBeat dans le répertoire ${repertoireFileBeat}
    • de déposer la configuration propre à FileBeat dans le répertoire ${repertoireFileBeat}conf.d
  • pour les services :
    • full custom pour la plus part

4.1.5 - Commandes à connaître

Après exécuter un playbook depuis la machine locale vers la machine WSL :

  • démarrer WLS depuis le menu démarrer de Windows en recherchant ubuntu
  • démarrer WSL, depuis une commande DOS, avec la commande wsl -d UbuntuAnsible
  • sur la machine UbuntuAnsible, exécuter la commande ansible-playbook ansible/05_statuer.yml -i ansible/inventory/local
  • si les actions à réaliser par Ansible nécessite un droit SUDO, exécuter la commande ansible-playbook ansible/01_preparer.yml -i ansible/inventory/local -K --extra-vars "ansible_user=ubuntu" et saisir le mot de passe “ubuntu”

Pour n’exécuter un playbook que pour un groupe de machines précis (service/couche/colonne), exécuter ansible-playbook ansible/05_statuer.yml -i ansible/inventory/local --limit machines_service_registry