diff --git a/content/20_cahier_des_charges.md b/content/20_cahier_des_charges.md index 634fc79..3381723 100644 --- a/content/20_cahier_des_charges.md +++ b/content/20_cahier_des_charges.md @@ -2,17 +2,21 @@ # Cahier des charges -TODO: cahier des charges +Premier élément du projet sur lequel travailler : le cahier des charges. ## Contexte -TODO : présenter Datascientest succinctement (dans un sous titre ?) +Dans le cadre d'une formation, dans l'école DataScientest, il a été demandé à des équipes composées de 3 à 5 personnes de travailler sur un projet défini, cadré et suivant un certain nombre de contraintes dont nous allons parler ici. + +Le cahier des charges a été la première réflexion sur le projet. ### Dans le cadre d'une formation -[Datascientest]{#datascientest} +[Datascientest]{#datascientest} est une école de formation créée en 2017, située sur Paris et proposant plus de 18 formations différentes, dont Administrateur Système DevOps. -TODO: compléter ici ce que Datascientest fait +Plusieurs formats de formation existent parmi Bootcamp, continu et en alternance. Ce projet est un exercice de fin de formation proposé à tous les élèves de la « cohorte » (équivalent d'une classe). + +Plusieurs élèves se regroupent autour d'un projet auquel ils ont un intérêt commun. ### L'équipe DevU42 {#devu42} @@ -31,6 +35,8 @@ L'équipe a été supervisée et suivie par [Jérémie Tarot sous la dénominati ### Organisation d'équipe +Pour s'organiser, l'équipe s'est doté de plusieurs outils et suivi quelques méthodologies. + #### Rapports hiérarchiques L’équipe s'articule autour de membres ayant le même degré de responsabilités et d'objectifs. Leur périmètre et leur champ d'action est similaire qu'il s'agisse de déterminer les tickets à prendre en charge, les axes de travail à rajouter au projet ou bien de nouveaux objectifs. @@ -42,7 +48,7 @@ En cas de désaccord sur un sujet, une décision est prise à la majorité votan La géolocalisation des membres de l'équipe étant éparse, plusieurs moyens de communication en ligne ont été nécessaires, parmi : * Canaux de discussions sur [Slack](https://slack.com/intl/fr-fr/) fournis initialement par [Datascientest](#datascientest) : -* canal du projet - sep24_bootcamp_devops : favorise l'échange entre [DevU42](#devu42) et le [Mentor](#mentor), + * canal du projet - sep24_bootcamp_devops : favorise l'échange entre [DevU42](#devu42) et le [Mentor](#mentor), * canal d'équipe - devu42 : pour les discussions techniques, les choix déccisifs et de la bonne humeur ! * Un nom de domaine, **devu42.fr**, * Une boîte courriel, partagée pour la gestion des services, @@ -71,148 +77,194 @@ Après livraison, l’amélioration du projet en continu se fera sur **6 semaine ## Le projet +Le point de départ du projet est un dépôt de version contenant une application à mettre en ligne. Justification du projet, l'application elle-même, ambitions et objectifs sont des points à soulever. + ### Justification du projet -Le projet s’inscrit dans le cadre suivant : +L'école de formation [DataScientest](#datascientest) s'éverture à proposer une situation proche de la réalité afin que l'équipe nouvellement formée puisse apprendre par la pratique. -Une entreprise a besoin que son application de gestion d’utilisateur soit portée par les pratiques DevOps, pour faire évoluer son service. +On imagine ainsi le cadre suivant : -De nombreux problèmes sont constatés avec la façon de fonctionner actuelle : +> Une entreprise ayant une application de gestion d’utilisateur souhaite déployer et faire évoluer son service en favorisant les bonnes pratiques suivies dans la culture DevOps. -* Reprise d’activité lente, coûteuse et avec des pertes d’informations importantes -* Stabilité et disponibilité du service vulnérable -* Capacité limitée à encaisser les charges soudaines de trafic -* Absence de supervision efficace, et de capacité à prévoir les problèmes -* Manque de contrôle sur la qualité du code, et les procédures de développement -* Grande perte de temps lié aux nombreuses actions manuelles et aux erreurs humaines -* Possibilité d’évolution limité par le manque de portabilité -* Lenteur de l’implémentation de nouvelles fonctionnalité, et interruptions de service +De la même manière, on imagine de l'entreprise une façon de fonctionner ayant de nombreux problèmes : + +* Reprise d’activité lente, coûteuse et avec pertes d’informations, +* Service instable, disponibilité non garantie, vulnérabilité du service, +* Capacité limitée pour encaisser des augmentations ponctuelles de la charge et du trafic, +* Absence de supervision et faible capacité à prévoir les problèmes, +* Manque de contrôle sur la qualité du code ; procédures de développement pouvant être améliorées par l'automatisation, +* Perte de temps et erreurs humaines liées aux actions manuelles, +* Manque de portabilité de l'application d'un système à l'autre, +* Lenteurs d’implémentation de nouvelles fonctionnalité avec interruptions de service. + +Pour bien saisir l'état des lieux de ladite application, regardons de plus près. ### Application existante L’application FastAPI-Træfik est fournie avec les éléments principaux suivants : -* BackEnd FastAPI (en Python) -* FrontEnd (Interface de gestion et d’enregistrement d’utilisateurs. Statique, Utilise React, Vite.js, Chakra UI.) -* Base de données -* Traefik (Proxy inverse) +* BackEnd FastAPI (en Python), +* FrontEnd (Interface de gestion et d’enregistrement d’utilisateurs. Statique, Utilise React, Vite.js, Chakra UI.), +* Base de données postgreSQL, +* et Traefik (Proxy inverse). + +Tout ceci est déposé dans un dépôt de version avec de la documentation en fichier Markdown (*.md) bruts. + +De simples fichiers Docker et docker-compose.yml permettent aux développeurs de lancer l'application localement. + +Une procédure existe pour expliquer comment manuellement mettre l'application en production sur une machine serveur dédiée. + +Mais le projet voit plus loin. ### Ambitions -* Répondre aux problématiques de l’application existante par la méthode DevOps. -* Répondre aux attentes de l’examen en matière de compétences attendues. -* Démontrer un savoir-faire technique sur les sujets principaux du Cloud dont AWS. -* Appliquer une méthode de travail qui optimise l’efficacité de la production des livrables. +En dehors des objectifs à atteindre, le projet vise à : + +* répondre aux problématiques de l’entreprise sur l'application existante par la méthode DevOps, +* répondre aux attentes de l’examen en matière de compétences attendues (méthode d'apprentissage par la pratique), +* démontrer un savoir-faire technique sur les sujets principaux du DevOps, notamment vis à vis du Cloud en utilisant AWS, +* appliquer une méthode de travail qui optimise l’efficacité de la production des livrables. + +C'est de ces ambitions que naîssent plusieurs objectifs spécifiques. ### Objectifs -* Porter l’application sur le cloud, avec une architecture réseau dans le respect du budget. -* Assurer une reprise d’activité en un minimum de temps. -* Déployer automatiquement et en continu avec des fichiers modularisés. -* Sauvegarder les données pour garantir leur conservation en cas de sinistre. -* Etablir une sécurité multi-niveau qui garantisse l’intégrité de l’application et de l’architecture, sans - handicaper les travailleurs dans leur travail au quotidien. -* Rendre le système résilient, en assurant son auto-scalabilité et sa haute disponibilité. -* Automatiser l’essentiel des actions pour limiter les erreurs humaines et gagner du temps. -* Rendre le contrôle du code et des versions, systématique. -* Mettre en place des solutions de supervisions et des tableaux de bord efficaces. -* Mettre en place un système d’alertes pour détecter les problèmes au plus tôt. +D'après moi, ce projet à plusieurs objectifs : + +* balayer l'ensemble des sujets liés à la culture DevOps et ses méthodes, +* porter, puis déployer une application sur le cloud, +* préparer une architecture complète pour accueillir une à plusieurs applications, +* respecter un budget et des limites de temps, +* déployer en continu un projet en passant par une phase de test, de pré-production puis de production, +* penser à la gestion de la donnée, +* superviser un système déployé en production avec des tableaux de bord efficaces, +* rendre un système résilient en prenant en compte les augmentations ET les diminution de charges et par une haute disponibilité, +* automatiser la plupart des actions afin de limiter les erreurs humaines, +* procéder, de manière automatique, à des vérifications sur la sécurité des éléments produits et déployés, +* favoriser une collaboration plus fluide entre les équipes de développements et les équipes d'opérations, +* et obtenir des alertes en cas de défaillance d'un ou plusieurs éléments du système. + +Ce sont des objectifs plutôt ambitieux pour un temps aussi court. Un travail d'équipe et une organisation sont totalement nécessaires. ## Planification +C'est par le [mentor](#mentor) que nous avons reçu un plan d'action pour les 7 semaines de travail et une liste de livrables attendus. Nous avons adapté ce plan d'action pour nous correspondre. + ### Étapes de travail -Semaine 1 : Choix du projet +Voici le détail de chaque étape de travail. -* Constitution des groupes par l’organisme de formation -* Choix du projet par le groupe nouvellement formé -* Découverte de l’application en détail -* organisation de l’équipe -* choix des outils principaux et prise en main de ces derniers +#### Semaine 1 : Cadrage -Semaine 2 : Planification +Sous le signe de l'encadrement, cette première semaine est dite « douce » : -* Etablissement du présent cahier des charges -* Prise en main de l’application -* Conception des schémas -* Choix des différents outils qui seront explorés les semaines suivantes -* Mise en place de l’organisation sur GitLab, et des procédures de travail -* Attribution de tâches par individu -* Exploration de projets similaires -* Décider d’une première approche pour l’automatisation gitlab-ci -* Décider des futurs repo/registry pour les images et les charts. +* réunion de prise de contact, présentation et cadrage, +* introduction de chaque membre du projet, +* découverte de l'application, +* analyse du sujet, +* évaluation du contexte, des objectifs et du périmètre du projet, +* et rédaction du premier jet du présent cahier des charges. -Semaine 3 : Automatisation de la chaine d’intégration et de livraison +Il faut ce temps pour découvrir de quoi il retourne. -* Adoption de la méthode GitOneFlow -* Mise en œuvre des deux environnements séparés Stagging et Prod -* Développement des processus d’automatisation des : - - Tests - - Constructions/Compilations - - Livraison - - Déploiement -* Mise en place de la promotion de version (basé sur Sem Ver) -* Produire un schéma clair résumant nos dépôts et nos pipelines sur Gitlab. +#### Semaine 2 : Planification -Semaine 4 : Conception de l’Infrastructure +Vient ensuite une phase d'organisation avec : -* Définir la couche réseau de l’infrastructure sur AWS en haute disponibilité -* Assurer la sécurité des éléments de la couche réseau -* Prévoir une future solution de stockage -* Adopter une solution de backup -* Définir la distribution de Kubernetes à employer, et la déployer. -* Gestion des secrets -* Générer la redirection vers notre propre nom de domaine -* Objectif : Infrastructure As Code +* définition du contexte, des objectifs et du périmètre du projet, +* organisation des exigences, +* identification des composants d'architecture, +* choix de solutions à implémenter, +* et définition de l'architecture et les spécifications du système cible. -Semaine 5 : Gestion des données +Ce qui amène à compléter le cahier des charges. -* Appliquer la méthode de stockage de données choisie -* Définir les politiques d’authentification, d’autorisation et de contrôle d’accès -* Assurer une journalisation -* Garantir la sauvegarde des données, et leur restauration en cas de sinistre -* Mettre en place la scalabilité de la solution choisie. -* Tester l’accessibilité des données par l’application +Nous prévoyons aussi : -Semaine 6 : Observabilité et Alertes +* une configuration de Gitlab, des principaux dépôts Gitlab, des branches, etc., +* de s'organiser en équipe : définir des méthodologies à suivre. -* Choisir une solution de monitoring -* Définir les données d’analyse du système dans sa globalité, et multi-environnement -* Créer des tableaux de bord pratiques et simples d’interprétation -* Attribuer des alertes à certaines métriques -* Tester des situations anormales pour constater si les alarmes se déclenchent correctement +#### Semaine 3 : Automatisation de la chaine d’intégration et de livraison -Semaine 7 : Préparer la communication +Une fois les outils principaux mis en place, il s'agit d'automatiser certaines choses : -* Mettre à jour les schémas as code (Mermaid et Draw.io) -* Création du support de diapositives as code -* Rédaction de la présentation, et entrainement individuel -* Tests de fonctionnement de l’implémentation d’une nouvelle fonctionnalité -* Mise en commun des compétences et des connaissances en vue de la présentation -* Fabrication d’un logo d’équipe -* Résolution des dernières améliorations +* automatisation des tests pour le backend et le frontend, +* création d'image Docker pour le backend, +* création d'image Docker pour le frontend, +* automatisation des images Docker et de leur publication sur des registres, +* création de chart Helm pour le backend, +* création de chart Helm pour le frontend, +* automatisation de la création des chart Helm et de leur publication, +* et automatisation de la création de l'infrastructure (même si elle n'est pas encore clairement définie). -### Livrables attendus +L'adoption d'un workflow pour la gestion des branches Git est la bienvenue. -Documents informatifs : +#### Semaine 4 : Conception de l’infrastructure -* Cahier des charges -* Support de communication diapositive -* Schéma pour chaque préoccupation majeure -* Dossier de projet +Vient ensuite la création de la couche basse de l'infrastructure : -Gitlab : +* création d'un schéma de la couche basse de l'infrastructure, +* description de cette infrastructure via des modules adaptés et en adoptant l'Infrastructure as Code (IaC), +* premiers choix de solutions pour le stockage, les sauvegardes, la supervision et l'environnement d'accueil de l'application, +* activation des certificats Let's Encrypt, +* liaison avec le nom de domaine, +* et mise à l'échelle automatique. -* Registre d’images docker -* Dépôt pour les charts -* Dépôt de l’application initiale -* Ensemble des fichiers de déploiement de l’architecture et des environnement modularisés -* Pipelines (Gitlab-ci) -* Le dépôt du projet +Une semaine n'est pas suffisante pour traiter tous les sujets. En revanche cela permet de les aborder et d'échanger sur ces derniers. -L’application : +#### Semaine 5 : Gestion des données -* L’accès au backend -* L’accès sécurisé https à notre Frontend -* Le tout via notre propre nom de domaine +La semaine 5 passe par : +* créer et configurer des ressources de stockage de données, +* mise en place de politique d'authentification et d'autorisation, +* import des données, +* et installer et configurer une solution de sauvegarde et de restauration de données. + +Rien de très particulier à ce niveau là. + +#### Semaine 6 : Observabilité et alertes + +Quant à la semaine 6, nous avons principalement la supervision à gérer : + +* configuration du système de supervision centralisé, +* mise en place d'une collecte de surveillance pertinente pour l'application, +* choix des métriques à utiliser pour la création de tableaux de bords, +* création des tableaux de bords, +* définition des niveaux d'alertes pour les métriques choisis, +* mise en place des alertes, +* et envoi des alertes sur les canaux choisis. + +Ces éléments pourront être complétés et étendus une fois la solution principale de supervision configurée. + +#### Semaine 7 : Présentation de la solution finale + +Cette dernière semaine ciblera la présentation et le lancement officiel de l'application. Il faudra donc : + +* compléter les documentations, +* mettre à jour les schémas en fonction d'éventuels changements, +* préparer un support visuel de présentation du projet, +* veiller à ce que l'application tourne sans accrocs pour la présentation, +* et résoudre les derniers problèmes majeurs connus - s'ils existent. + +C'est un plan assez ambitieux quand on considère que les membres de l'équipe proviennent d'horizons et de formations variées. + +### Livrables + +Sont attendus les éléments suivants : + +* un cahier des charges, +* une présentation par diapositives pour le lancement de l'application, +* une application déployée en production, sans bugs, +* un système de supervision de la production, +* une gestion des données avec un système de sauvegarde, +* un schéma de la couche basse de l'infrastructure utilisée dans le Cloud pour la production, +* un accès aux dépôts et scripts permettant l'automatisation du déploiement de l'application et de la génération des différents éléments (images Docker, Chart Helm, registres, etc.), +* et un fonctionnement en haute disponibilité de l'application. + +## Conclusion + +Le projet couvre beaucoup de situations et domaines autour de l'automatisation et la mise en production, dans le Cloud, d'une application avec une supervision et une mise à l'échelle de cette dernière. + +En groupe, c'est un projet idéal pour suivre l'« apprentissage par la pratique » proposée par [DataScientest](#datascientest) et couvrir un maximum de compétences demandées pour le Titre Professionnel d'Administrateur Système DevOps.