chore(content): work on intro/conclusion

content/30_liste_competences.md

@@ -1,5 +1,7 @@
 # Liste de compétences couvertes par le projet
 
+## Introduction
+
 Le référentiel de compétences du *Titre Professionnel Administrateur Système 
 DevOps* liste 11 compétences réparties en 3 catégories : 
 
@@ -23,6 +25,8 @@ DevOps* liste 11 compétences réparties en 3 catégories :
   * Compétence **n°11 : Échanger sur des réseaux professionnels 
   éventuellement en anglais**
 
+## Couverture
+
 En utilisant les critères de performance fournis par chaque fiche de 
 compétence, j'ai pu établir le tableau suivant permettant de voir les points à 
 améliorer : 
@@ -54,3 +58,10 @@ services) n'a pu être clairement établie **faute d'interlocuteur autre que le
 La **compétence n°10** (Exploiter une solution de supervision) est **en lien 
 avec la compétence précédente**, ce qui influe sur la pertinence des moniteurs 
 mis en place dans la solution.
+
+## Conclusion
+
+Le projet décrit dans le présent document couvre de manière complète une 
+énorme partie des compétences attendues. Au final 2 type de compétences 
+sont partiellement couvertes : celle concernant la supervision et celle 
+concernant le stockage de données.

content/40_cahier_des_charges.md

@@ -145,13 +145,13 @@ développement pouvant être améliorées par l'**automatisation**,
 * Lenteurs d'implémentation de **nouvelles fonctionnalités** avec 
 interruptions de service.
 
+### Application existante
+
 Pour bien saisir l'état des lieux de ladite application, regardons de plus 
 près.
 
-### Application existante
+L'**application API Utilisateurs** (nom de code FastAPI-Træfik) est fournie 
-
+avec les éléments principaux suivants : 
-L'**application FastAPI-Træfik** est fournie avec les éléments principaux 
-suivants : 
 
 * Backend utilisant le framework **FastAPI** (en Python),
 * Frontend statique (en **React**, **Vite.js** et **Chakra UI**) : 
@@ -169,11 +169,10 @@ développeurs de **lancer l'application localement**.
 **Une procédure manuelle existe** pour expliquer comment mettre l'application 
 en production sur une machine serveur dédiée.
 
-Mais **le projet voit plus loin**.
-
 ### Ambitions
 
-En dehors des objectifs à atteindre, le projet vise à : 
+Le projet **va plus loin** ; en dehors des objectifs à atteindre, il vise 
+à : 
 
 * répondre aux problématiques de l'entreprise sur l'application existante par 
 **la méthode DevOps**,
@@ -184,11 +183,9 @@ notamment vis à vis du Cloud **en utilisant AWS** (Amazon Web Services),
 * 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
 
-Ce projet à plusieurs objectifs : 
+C'est de ces **ambitions** que naîssent plusieurs objectifs spécifiques : 
 
 * balayer l'ensemble des **sujets liés à la culture DevOps et ses méthodes**,
 * porter, puis **déployer** une application **sur le cloud**,
@@ -215,7 +212,7 @@ Ce sont des **objectifs plutôt ambitieux pour un temps aussi court**. Un
 travail d'équipe et une organisation de cette dernière sont totalement 
 primordiaux.
 
-## Planification
+## Planification {#plan}
 
 Après quelques échanges avec le [mentor](#mentor) nous avons établi le plan 
 d'action pour les 7 semaines de travail à venir ainsi qu'une liste de 
@@ -358,9 +355,13 @@ déploiement de l'application et de la génération des différents éléments
 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.
+dernière tout en gérant une **base de données**, le **stockage** et la 
+**sauvegarde**.
 
 En groupe, c'est un projet idéal pour suivre l'« **apprentissage par la 
 pratique** » proposé par [DataScientest](#datascientest) et couvrir un 
 maximum de compétences demandées pour le *Titre Professionnel d'Administrateur 
 Système* DevOps.
+
+Cela demande de suivre [le plan](#plan) à la lettre dans les **limites de 
+temps et de budget** définies : c'est un projet ambitieux.

content/50_specifications_techniques.md

@@ -69,7 +69,8 @@ La **partie proxy** utilise actuellement **Traefik comme outil**. Ce qui n'est
 pas une obligation d'usage pour un déploiement en production.
 
 Ces trois parties ont une influence sur le choix de l'infrastructure à mettre 
-en place. Il reste cependant une **marge de manœuvre sur la partie proxy**.
+en place. Il reste cependant une **marge de manœuvre sur la partie proxy**. En 
+effet il n'est pas obligatoire d'utiliser Træfik en production.
 
 ## Infrastructure
 
@@ -105,12 +106,13 @@ Le schéma de la couche basse de l'infrastructure ressemble donc à :
 ![Schéma de la couche basse de 
 l'infrastructure](./media/schema_couche_basse.png){width=100%}
 
-C'est sur cette base qu'il est possible d'intégrer un environnement capable de 
-déployer, automatiser et gérer des applications conteneurisées.
-
 ### Environnement Kubernetes
 
-**Kubernetes** est un système capable de faire tourner des **applications 
+C'est sur la couche basse qu'il est possible d'ajouter un environnement 
+permettant d'intégrer, déployer, automatiser et gérer des applications 
+conteneurisées. Pour cela nous choisissons **Kubernetes**.
+
+Kubernetes est un système capable de faire tourner des **applications 
 conteneurisées**, d'**automatiser le déploiement** et de gérer la mise à 
 l'échelle (**auto-scaling**).
 
@@ -148,10 +150,10 @@ EKS](./media/schema_contenu_eks.png){width=100%}
 * le **backend** de l'application (FastAPI),
 * et le **frontend** de l'application (en fichiers statiques).
 
-Afin de permettre une livraison régulière de l'application, il va falloir 
+Afin de permettre une **livraison régulière** de l'application, il va falloir 
-automatiser au maximum les étapes entre la publication d'une nouvelle version 
+**automatiser au maximum** les étapes entre la publication d'une nouvelle 
-de l'application et sa livraison. Puis son déploiement en production via une 
+version de l'application et son déploiement en production en passant par la 
-intervention humaine.
+livraison en environnement de pré-production par une intervention humaine.
 
 ### Environnements
 
@@ -276,9 +278,9 @@ https://handbook.gitlab.com/handbook/engineering/monitoring/#historical-service-
 En revanche **la production**, même en **étant un service en haute 
 disponibilité**, doit fournir au moins **une sauvegarde 1 fois par jour**. 
 L'outil de sauvegarde choisi est **Velero**. Compatible avec l'environnement 
-Kubernetes et permettant aussi de sauver l'état du cluster à un moment donné. 
+Kubernetes et permettant aussi de **sauver l'état du cluster** à un instant 
-Son outil en ligne de commande permet de gérer les sauvegardes mais aussi les 
+*T*. Son outil en ligne de commande permet de gérer les sauvegardes mais aussi 
-restaurations de ces dernières.
+les restaurations de ces dernières.
 
 Comme énoncé précédemment, les sauvegardes du cluster seront mises **sur un 
 stockage AWS S3** (dit « bucket S3 »).
@@ -295,8 +297,9 @@ Le fonctionnement de Velero dans ce projet est visible sur le schéma suivant.
 
 ### Supervision
 
-Le choix se porte sur **Datadog** pour sa **souplesse** et sa capacité à 
+Le choix de l'outil de supervision se porte sur **Datadog** pour sa 
-proposer des **services supplémentaires de manière progressive**.
+**souplesse** et sa capacité à proposer des **services supplémentaires de 
+manière progressive**.
 
 Le fonctionnement semble simple : installation d'agents Datadog dans le 
 système Kubernetes pour receuillir de nombreuses informations. Comme peut le 
@@ -307,18 +310,29 @@ montrer le schéma suivant.
 ![Schéma des agents Datadog dans notre système 
 Kubernetes](./media/schema_datadog.png){height=70%}
 
+Une fois installé, l'agent Datadog recueille et envoie les informations sur 
+les serveurs officiels de l'entreprise Datadog qui en gère le stockage et 
+l'accès.
+
 #### Surveillance (monitoring)
 
-Pour le monitoring, on veillera à suivre des **indicateurs simples** comme 
+L'utilisation de Datadog donne accès à de nombreux moniteurs pré-configurés.
-l'**utilisation CPU** et la **mémoire vive** des instances AWS EC2 (Elastic 
+
-Compute Cloud) utilisées.
+On veillera à utiliser des **indicateurs simples** comme l'**utilisation CPU** 
+et la **mémoire vive** des instances AWS EC2 (Elastic Compute Cloud) utilisées.
 
 Il y a également : 
 
 * le **nombre de pods utilisés** par l'instance EC2,
-* et la **disponibilité du service** de l'application API-Utilisateurs.
+* et la **disponibilité du service** de l'application *API Utilisateurs*.
 
-Cependant ces moniteurs doivent s'agrémenter d'**alertes**.
+Cependant ces moniteurs sont insuffisants. On pourrait ajouter : 
+
+* le temps de réponse de l'API,
+* le nombre de requêtes par seconde sur l'API,
+* même chose pour le nombre de requêtes sur la base de données,
+* le nombre d'erreurs 500 retournées par le frontend et le backend,
+* etc.
 
 #### Alertes
 
@@ -332,21 +346,36 @@ utilisons donc le [**Gitlab ChatOps**](https://docs.gitlab.com/ci/chatops/).
 
 En suivant toutes ces indications, nous devrions avoir une base stable et 
 saine pour constuire une supervision correcte de l'application 
-API-Utilisateurs.
+*API Utilisateurs*.
 
 ### Sécurité
 
-Au niveau de la sécurité, **vaste sujet**, nous partirons de peu 
+Au niveau de la sécurité, **vaste sujet**, nous partirons de ces 
-d'éléments : 
+éléments : 
 
 * lancement de **tests** sur le **code applicatif**,
-* lancement de **tests SAST** (Static application security testing), sur Terraform notamment,
+* lancement de **tests SAST** (Static application security testing), sur 
-* et utilisation d'un **coffre fort numérique** pour les mots de passes et clés d'accès en tous genres.
+Terraform notamment,
+* et utilisation d'un **coffre fort numérique** pour les mots de passes et 
+clés d'accès en tous genres.
 
 Le coffre-fort choisi est **Vaultwarden**.
 
-Il y a beaucoup à faire pour **améliorer la sécurité**. Ceci est un **processus continu** à faire tout au long du **suivi et la maintenance du projet**.
+Il y a beaucoup à faire pour **améliorer la sécurité**. Ceci est un 
+**processus continu** à faire tout au long du **suivi et la maintenance du 
+projet**.
 
 ## Conclusion
 
-Les spécifications techniques étant établies, nous allons pouvoir nous concentrer sur la démarche suivie pour mettre en place le projet. C'est à dire comment nous allons atteindre les objectifs du cahier des charges à l'aide des solutions choisies ici-même.
+Les spécifications techniques décrivent bien l'application, composée de 3 
+éléments (backend, frontend et base de données) qui s'intégreront bien dans 
+l'environnement Kubernetes installé sur l'infrastructure posée dans le cloud 
+AWS.
+
+On retient ainsi un déploiement automatique dans le Cloud d'une infrastructure 
+prête à accueillir à la fois l'application et d'autres services tierces comme 
+la supervision avec Datadog et les sauvegardes à l'aide de Velero.
+
+La sécurité aura cette spécificité de devoir être régulièrement vérifiée, 
+maintenue et améliorée au fil du temps. C'est donc un processus continu dont 
+la réussite dépend beaucoup de la discipline et la régularité.

content/60_demarche.md

@@ -30,9 +30,6 @@ semaine,
 * et l'utilisation d'un **tableau façon Kanban** (méthode de gestion de 
 production en flux tendus).
 
-C'est ainsi que les **jalons** ont parsemés la durée du projet en **objectifs à 
-atteindre**.
-
 ### Jalons
 
 Les **jalons** (milestones en anglais) permettent de savoir si le projet 
@@ -46,13 +43,12 @@ wiki, etc.), **cahier des charges**,
 * Étape 5 (avec 4) : **Supervision** (observabilité, alertes),
 * Étape 6 : **extras** (s'il reste du temps).
 
-Les jalons n'étaient pas suffisants, d'autres éléments ont dû être pris en 
-compte.
-
 ### Choix de standards et normes
 
-Plusieurs standards/normes ont été choisies pour **rassembler plutôt que 
+Les jalons n'étaient pas suffisants, d'autres éléments ont dû être pris en 
-diviser le groupe** : SemVer, Git OneFlow et Conventional commit.
+compte ; des standards/normes ont été choisies pour **rassembler plutôt 
+que diviser le groupe** : c'est là que SemVer, Git OneFlow et 
+Conventional commit entrent en jeu.
 
 #### SemVer
 

content/70_realisations.md

@@ -375,6 +375,13 @@ Deux expériences variées et différentes qui s'imbriquent pourtant dans le
 processus de production logicielle et de livraison continue. Il y a beaucoup 
 de choses à dire sur chacun des sujets, tellement ils sont passionnants. Ils 
 amènent également à prendre des initiatives et tester localement des outils. 
-Nous parlerons d'ailleurs dans le prochain chapitre d'une situation de travail 
+
-ayant amené à faire une recherche. Nous pourrons ainsi voir plus en détails le 
+Ces expériences ont aussi permi d'acquérir de nouvelles compétences 
-processus de travail suivi afin d'aboutir à ce résultat.
+primordiales dans le domaine du DevOps. La prise de recul sur ces éléments 
+met en évidence des failles dans le schéma de pensée. Il y a donc des points 
+à améliorer et une évolution possible dans les tâches présentées.
+
+Je pense aussi que de nouvelles expériences seraient enrichissantes pour 
+comparaison avec celles présentées ici afin d'estimer les pour et les contre 
+de différentes solutions. Cela permettrait de s'adapter aux situations avec 
+des outils adéquats.

content/80_situation_de_travail.md

@@ -3,14 +3,14 @@
 # Situation de travail
 
 L'exercice demandé dans ce chapitre est particulier pour moi. Il est demandé, 
-je cite, « **une description d'une situation de travail ayant nécessité une 
+je cite, « **une description d'une situation de travail ayant nécessité 
-recherche effectuée par le candidat durant le projet** ».
+une recherche effectuée par le candidat durant le projet** ».
 
-Pour bien saisir **ma façon de travailler**, je pense qu'il est nécessaire de 
+Pour saisir **la méthodologie choisie**, je pense qu'il est nécessaire de 
 décrire une situation complète. Nous allons poser le contexte, faire l'état 
-des lieux puis suivre le cheminement parcouru pour atteindre l'objectif.
+des lieux puis suivre la démarche pour atteindre l'objectif.
 
-## Contexte
+## Contexte et état des lieux
 
 Du projet émane un besoin d'**avoir du temps de calcul pour les pipelines**.
 
@@ -22,8 +22,6 @@ utilisons Gitlab**, ce sont donc des Gitlab Runner que nous visons.
 Où les installer ? Comment ? **De quelles ressources 
 disposons-nous ?**
 
-## État des lieux
-
 **Nous utilisons Gitlab** qui propose, dans sa version gratuite, une **limite 
 de temps de calcul**. Une fois le seuil atteint : il faut trouver une 
 solution alternative aux **machines de Gitlab, payantes**.
@@ -41,7 +39,7 @@ et un **environnement Kubernetes** pour **déployer des Gitlab Runner**.
 
 Après en avoir discuté en groupe, je me suis attelé à la tâche. Régulièrement.
 
-## Cheminement
+## Démarche
 
 ### Retranscription préalable
 
@@ -119,8 +117,8 @@ plusieurs fois dans le passé. Le sujet de la virtualisation a donc donné lieu
 * Le **wiki d'ArchLinux** et sa catégorie 
 « **Virtualization** » : \
 https://wiki.archlinux.org/title/Category:Virtualization,
-* Le blog précédemment cité de [**Stéphane \textsc{Robert}**](#stephane-robert)
+* Le blog précédemment cité de [**Stéphane 
-.
+\textsc{Robert}**](#stephane-robert).
 
 Je me suis concentré sur l'outil conseillé par **mon contact DevSecOps** qui 
 utilise QEMU/KVM/Libvirt pour l'émulation d'une machine complète. J'ai lu et 
@@ -146,8 +144,8 @@ https://odtre.gitlab.io/doc/virtualisation/.
 plusieurs systèmes d'exploitation** avant de les adopter et les déployer sur 
 notre infrastructure.
 
-![Section « Documentation » du site statique odtre.gitlab.io généré sur 
+![Section « Documentation » du site statique odtre.gitlab.io 
-Gitlab](./media/screenshot_odtre_doc.png){width=100%}
+généré sur Gitlab](./media/screenshot_odtre_doc.png){width=100%}
 
 \newpage
 
@@ -161,8 +159,9 @@ nécessaires** pour déployer et utiliser **FluxCD** :
 
 * la **page d'installation officielle**, Cf. 
 https://fluxcd.io/flux/installation/,
-* les différents « **bootstrap** » possibles en fonction d'un **fournisseur de 
+* les différents « **bootstrap** » possibles en fonction d'un 
-dépôt Git** choisi, Cf. https://fluxcd.io/flux/installation/bootstrap/,
+**fournisseur de dépôt Git** choisi, Cf. 
+https://fluxcd.io/flux/installation/bootstrap/,
 * et des **explications sur le contrôleur de sources**, \
 Cf. https://fluxcd.io/flux/installation/bootstrap/ pour se mettre à jour 
 «  tout seul ».
@@ -181,3 +180,15 @@ Bien que pour la plupart des outils, une fois choisis, la documentation
 officielle de ces outils semble suffire pour leur installation et leur 
 utilisation. Les **bonnes pratiques** restent **dans les articles des 
 blogueurs** et autres joyeux rédacteurs en tous genres.
+
+Le blog de [Stéphane \textsc{Robert}](#stephane-robert) est un bon point de 
+départ qui ne dispense absolument pas de recherches supplémentaires. Des 
+outils tels que QEMU/KVM/libvirt pour la virtualisation sont de bonnes idées 
+pour tester les outils de DevOps dans un environnement isolé. Tout comme 
+FluxCD qui permet d'automatiser, à l'intérieur d'un environnement Kubernetes, 
+la recherche de nouvelles versions de ses applications.
+
+La méthodologie ayant été fructueuse, elle sera dans mes priorités pour les 
+années à venir. Il faudra cependant être attentif au temps passé à la 
+publication de ses recherches qui, bien qu'il soit un investissement sur long 
+terme, consomme un temps certain à la rédaction et la mise en page.

content/90_conclusion.md

@@ -3,9 +3,9 @@
 # Conclusion
 
 Ma **passion anticipée pour l'automatisation** et l'**amélioration des 
-processus** de **création logiciel** m'ont amené à ce moment, aujourd'hui, où 
+processus** de **création logiciel** m'ont amené à ce moment où j'écris ces 
-j'écris ces lignes pour **embrasser le métier d'Administrateur Système 
+lignes pour **embrasser le métier d'Administrateur Système DevOps**. La 
-DevOps**. La formation, puis **le projet de fin de formation** ont été 
+formation, puis **le projet de fin de formation** ont été 
 **bénéfiques à la prise d'expérience**, mais pas que.
 
 En effet, **il est question de nouvelles compétences**, que le projet, à 
@@ -14,10 +14,22 @@ fonctionnelles, d'une approche (démarche) suivie, de plusieurs réalisations et
 de situations diverses, a permis d'**acquérir tout au long de ces derniers 
 mois**.
 
+La découverte de nombreux outils comme Kubernetes, Terraform, FluxCD, Datadog, 
+externaldns, cert-manager, QEMU/KVM, libvirt, etc. a été riche et variée. Il 
+est possible **d'approfondir plus encore** sur ces derniers et de les essayer 
+dans **d'autres environnements de cloud** comme *Microsoft Azure* ou *Google 
+Cloud Platform*.
+
 Ainsi **je ressors riche de nouvelles expériences**, de **nouveaux outils**, 
 de **nouvelles méthodes** et de **nouveaux collaborateurs** dans un monde sans 
-cesse grandissant qu'est **le monde du DevOps**.
+cesse grandissant qu'est **le monde du DevOps**. C'est aussi et surtout une 
+culture qui amène à de **bonnes pratiques**, une **amélioration constante** et 
+la découverte infinie de projets en tous genres.
 
-Bien que ne sachant ce que l'avenir me réserve, j'espère qu'il continuera sur 
+Ce projet, bien qu'ambitieux au départ, semble désormais une approche basique 
-la voie du DevOps et de l'enrichissement par de nouvelles connaissances et 
+à reprendre lors de futurs projets. Il faudra alors améliorer la gestion 
-perspéctives professionnelles d'avenir !
+d'équipe, une planification plus réactive et la prise en compte de plus de 
+facteurs comme l'apprentissage de nouvelles technologies, les retards et le 
+temps accordé à chaque étape. D'autres outils, plus adaptés, pourront 
+également mieux se greffer à de nouveaux projets pour en faciliter la 
+finalisation.