From 31631d6e87b9d9d82ea67c2807c1c289847b309d Mon Sep 17 00:00:00 2001 From: Olivier DOSSMANN Date: Tue, 25 Feb 2025 16:17:03 +0100 Subject: [PATCH] fix(content): syntax, language, etc. after comments --- Makefile | 2 +- content/05_intro.md | 32 +++++++-- content/08_remerciements.md | 84 ++++++---------------- content/10_liste_competences.md | 24 +++---- content/20_cahier_des_charges.md | 94 ++++++++++++------------- content/30_specifications_techniques.md | 44 ++++++------ content/40_demarche.md | 38 +++++----- content/50_realisations.md | 11 ++- content/60_situation_de_travail.md | 31 ++++---- content/80_conclusion.md | 2 +- 10 files changed, 173 insertions(+), 189 deletions(-) diff --git a/Makefile b/Makefile index ad572a4..98d39bd 100644 --- a/Makefile +++ b/Makefile @@ -44,7 +44,7 @@ public/${NAME}.html: public ${CONTENT_LIST} public/${NAME}.pdf: public ${CONTENT_LIST} $Qecho "[PREPA] PDF : contenu" - # Cf. https://pandoc.org/chunkedhtml-demo/8.17-images.html for implicit_figures explanations. Si activé : titre + centrées MAIS les images sont pas au bon endroit dans le texte. Si désactivé : pas de titre, pas centrées, MAIS images au BON ENDROIT. + $Q# Cf. https://pandoc.org/chunkedhtml-demo/8.17-images.html for implicit_figures explanations. Si activé : titre + centrées MAIS les images sont pas au bon endroit dans le texte. Si désactivé : pas de titre, pas centrées, MAIS images au BON ENDROIT. $Qpandoc -V colorlinks -V fontfamily="${FONT_FAMILY}" -V fontsize="${FONT_SIZE}" -V classoption:twoside --number-sections -V graphics --template="${LATEX_TEMPLATE}" --toc -V toc-title:'${TOC_TITLE}' -V papersize:a4 --from=markdown+implicit_figures+fenced_code_attributes --highlight-style ${HL_THEME} --to=latex -o "public/${NAME}.pdf" ${CONTENT_LIST} # END diff --git a/content/05_intro.md b/content/05_intro.md index 464465e..3555576 100644 --- a/content/05_intro.md +++ b/content/05_intro.md @@ -6,16 +6,16 @@ La **méthodologie Agile** étant de plus en plus adoptée, les **équipes de développement** publient de nouvelles versions de leur application avec une fréquence bien plus élevée. Les **équipes d'opération** ont désormais besoin d'un outillage plus conséquent pour déployer ces versions. C'est pour cette raison -que l'**automatisation**, entre autre, est nécessaire pour soulager les équipes +que l'**automatisation**, entre autres, est nécessaire pour soulager les équipes d'opération. Ainsi **le DevOps entre en jeu** : une culture et un ensemble de **bonnes pratiques** pour faciliter l'échange entre les équipes -de développement et celles d'opérations. Mais également de favoriser un **flux +de développement et celles d'opération. Mais également de favoriser un **flux continu** entre ces équipes. Au long de mon parcours, que ce soit en tant qu'**Ingénieur en Conception et -Développement d’Environnements Distribués** ou **Responsable d'Applications**, j'ai -été sensibilisé aux besoin incessants de l'automatisation et de l'amélioration - des processus de création logiciel. J'ai participé à la mise en place +Développement d'Environnements Distribués** ou **Responsable d'Applications**, j'ai +été sensibilisé aux besoins incessants de l'automatisation et de l'amélioration + des processus de création logicielle. J'ai participé à la mise en place progressive d'une **chaîne de publication logicielle**, que ce soit dans le monde professionnel ou dans la sphère privée (pour publier mon blog). C'est donc tout naturellement que je me suis tourné vers ce domaine passionnant qu'est le @@ -27,9 +27,29 @@ formation. Nous commencerons par faire la corrélation entre les compétences attendues pour le *Titre Professionnel Administrateur Système DevOps* et le(s) projet(s) présenté(s) dans ce dossier. Après quoi nous continuerons avec le cahier des charges et les spécifications techniques de ce(s) dernier(s). \ -Nous continuerons par expliquer la démarche suivie pour accomplir le projet, +Nous continuerons en expliquant la démarche suivie pour accomplir le projet, quelques réalisations effectuées et d'une situation de travail qui mérite d'être relevée. Mais avant tout, nous tenons à présenter nos remerciements à quelques personnes. +## Conventions typographiques + +Ce document suit certaines conventions de mise en forme pour faciliter la +lecture : + +* Les liens hypertextes apparaissent sous la forme suivante : [Titre du lien]( +https://perdu.com), +* Les références vers d'autres sections sont indiquées comme suit : [référence +vers un paragraphe spécifique, exemple avec DataScientest](#datascientest), +* Les mots-clés essentiels d'une section sont en **gras**, +* Les termes particuliers sont en *italique*, +* Les noms de famille apparaissent avec de petites majuscules : Prénom \textsc{Nom}, +* Les extraits de code sont affichés dans un format distinct : + +```bash {.numberLines} +#!/usr/bin/env bash + +echo "Bonjour tout le monde !" +``` + diff --git a/content/08_remerciements.md b/content/08_remerciements.md index ac6d122..7da41bb 100644 --- a/content/08_remerciements.md +++ b/content/08_remerciements.md @@ -2,14 +2,7 @@ # Remerciements -Avant toute chose il y a une personne sans qui cette aventure n'aurait pas été -possible : **Agnès \textsc{Schweitzer}**. Elle a été l'**immense -soutien** derrière les petites mains qui écrivent ces lignes. Présente quand -les choses n'allaient pas, quand la voie semblait sans issue et que l'iceberg -s'approchait du bateau ! En sa présence l'**humilité** n'a qu'à bien se -tenir ! - -À **Madame \textsc{Schweitzer}** pour ses **conseils**, son aide +À **Madame Agnès \textsc{Schweitzer}** pour ses **conseils**, son aide **précieuse**, sa **présence d'esprit** et son **exceptionnelle intelligence** : MERCI ! @@ -20,23 +13,12 @@ autre ligne. C'est ce que permet l'organisme de formation **DataScientest** au travers de ses nombreux parcours proposés aux personnes qui, comme moi, souhaitent **changer de métier**. -Je remercie Sarah \textsc{Bouras} d'avoir été mon premier contact avec cet -organisme. Elle a été **à l'écoute**, soucieuse de répondre **avec précision -et parcimonie** à toutes mes questions et de me rassurer sur les sujets qui -m'inquiétaient. +Je remercie particulièrement les personnes suivantes pour leur **écoute**, +leur **professionnalisme** et leur souci de réponses claires : -C'est ensuite Benjamin \textsc{Fiche}, **chef de cohorte**, qui a pris le pas -en répondant **consciencieusement** à toutes mes questions ; même les plus -triviales/simplettes/absurdes. Il a toujours fait preuve d'**un -professionnalisme hors pair** et je me devais de le souligner. - -Nous avons également Jérémie \textsc{Tarot}, notre **passionnant - et -passionné** - Mentor qui détient une **connaissance infinie** des outils -et des pratiques du monde du DevOps. Son savoir nous a donné de **multiples -pistes** quand nous étions bloqués. Ses conseils ont été spécifiquement utiles -lorsque les ressources venaient à manquer dans le projet, que ce soit en terme -de ressources humaines ou de ressources temporelles. Il a **cru en nous** ; et -ceci représente une aide précieuse. +* Sarah \textsc{Bouras}, +* Benjamin \textsc{Fiche}, +* et Jérémie \textsc{Tarot}. Je remercie également **l'ensemble de l'équipe DataScientest** pour leur patience et leur savoir-vivre au regard de mes nombreux retours sur les cours, @@ -46,52 +28,31 @@ les examens et les machines virtuelles fournies. Chaque membre de l'équipe a ses **difficultés**, une **vie sociale et familiale** prenante, des **obligations** et des **responsabilités** à côté de -la formation. +la formation. Et pourtant ils ont donné ce qu'ils pouvaient. -Pris à part, nous avons **chacun nos particularités**. Ensemble ces problèmes -étaient amoindris. Nous aurions pu faire mieux et plus loin. Mais nous avons -fait. Et rien que pour cela je remercie l'équipe d'y être parvenu. +Merci à : -À Eliel \textsc{Moncada} pour ses **trouvailles** Web et sa **patience** sur -les schémas visuels qui prennent un temps considérable ! - -À Hrubech \textsc{Hombessa} pour sa **qualité d'échange** sur des **sujets -pointus** et la **pertinence** de ses questions. - -À Julien \textsc{Sabiols} pour sa **détermination**, son **travail acharné**, -son **intelligence** et son énorme **humilité**. Il a su être un partenaire -de pair-programming **brillant** avec un **esprit affûté**. C'est rare. Et -très appréciable ! +* Hrubech \textsc{Hombessa}, +* Eliel \textsc{Moncada}, +* et Julien \textsc{Sabiols}. J'imagine que derrière chaque personne il y a également **un ou une partenaire -de vie** qui a facilité l'organisation et la disponibilité autour de la -formation. Pour ces personnes **cachées dans l'ombre** : MERCI ! -Vous méritez de figurer dans ces lignes. +de vie**. Vous méritez de figurer dans ces lignes et d'avoir un grand +MERCI ! -## Aux membres de la « cohorte » +## Aux membres de la « cohorte » Je tiens à remercier également **l'ensemble des membres de la cohorte**. À ceux qui ont participé aux discussions, à ceux qui ont bien voulu échanger, à ceux qui ont accepté de répondre à des questions, à ceux qui ont partagé -des difficultés ou encore des solutions, à ceux qui étaient eux-même. +des difficultés ou encore des solutions, à ceux qui étaient eux-mêmes. -Une mention particulière aux personnes suivantes (ordre alphabétique - -prénom) : +Une mention particulière aux personnes suivantes : -* à Dorian \textsc{Roly} pour nos **échanges intéressants** sur de multiples -technologies et sur les archétypes des personnes dans l'informatique, -* à Maxime \textsc{Boulanghien} pour sa **sérénité**, son **implication** et -son efficacité sur des sujets dûments travaillés ; notamment la promotion -logicielle au sein d'une automatisation complète de déploiement d'une -infrastructure, -* à Michael \textsc{Lachand} pour nos discussions sur **l'importance de -l'individu** au sein du domaine professionnel plutôt que des chiffres et des -compétences seules ; mais aussi des difficultés apportés par notre Société -moderne à ce sujet, -* et enfin à Philippe \textsc{Risser-Maroix} avec qui j'ai pu discuter de -**notions informatiques poussées** et de Logiciel Libre sans me sentir seul à -ce sujet ; sa sensibilité au sujet de la **sécurité informatique** est un -point fort ! +* à Maxime \textsc{Boulanghien}, +* à Michael \textsc{Lachand}, +* à Philippe \textsc{Risser-Maroix}, +* et à Dorian \textsc{Roly}. ## Et les autres @@ -100,6 +61,5 @@ participé à leur façon. Je tiens à remercier notamment Grégoire \textsc{Stein}, en sa qualité de **DevSecOps**, pour ses **précieux conseils** tout au long de cette aventure ! -Si d'aventures j'avais oublié des personnes, je m'en excuse. Il y a pourtant -ici toute la place nécessaire, voilà pourquoi j'ai reservé ce paragraphe à -toutes celles et ceux dont j'aurais omis le nom/prénom. +À Richard \textsc{Dern} et son œil d'aigle pour les nombreuses relectures et +fautes d'orthographes découvertes dans ce document. diff --git a/content/10_liste_competences.md b/content/10_liste_competences.md index e22fac7..f0cc8cb 100644 --- a/content/10_liste_competences.md +++ b/content/10_liste_competences.md @@ -1,22 +1,20 @@ -\newpage - # Liste de compétences couvertes par le projet Le référentiel de compétences du *Titre Professionnel Administrateur Système DevOps* liste 11 compétences réparties en 3 catégories : -* Automatiser le déploiement d’une infrastructure dans le cloud - * Compétence **n°1 : Automatiser la création de serveurs à l’aide de +* Automatiser le déploiement d'une infrastructure dans le cloud + * Compétence **n°1 : Automatiser la création de serveurs à l'aide de scripts** * Compétence **n°2 : Automatiser le déploiement d'une infrastructure** - * Compétence **n°3 : Sécuriser l’infrastructure** - * Compétence **n°4 : Mettre l’infrastructure en production dans le + * Compétence **n°3 : Sécuriser l'infrastructure** + * Compétence **n°4 : Mettre l'infrastructure en production dans le cloud** * Déployer en continu une application * Compétence **n°5 : Préparer un environnement de test** * Compétence **n°6 : Gérer le stockage des données** * Compétence **n°7 : Gérer des containers** - * Compétence **n°8 : Automatiser la mise en production d’une + * Compétence **n°8 : Automatiser la mise en production d'une application avec une plateforme** * Superviser les services déployés * Compétence **n°9 : Définir et mettre en place des statistiques de @@ -26,7 +24,8 @@ DevOps* liste 11 compétences réparties en 3 catégories : éventuellement en anglais** En utilisant les critères de performance fournis par chaque fiche de -compétence, j'ai pu établir le tableau suivant : +compétence, j'ai pu établir le tableau suivant permettant de voir les points à +améliorer : : Couverture de compétences du projet @@ -35,7 +34,7 @@ Compétence | Nbre critères perf. | Couverte ? | Note Compétence n°1 | 3/3 | Oui | EC2 / Terraform Compétence n°2 | 3/3 | Oui | Terraform Compétence n°3 | 2/2 | Oui | Staging, Vaultwarden, Let's Encrypt -Compétence n°4 | **2**/3 | Oui | Terraform → « prod » +Compétence n°4 | **2**/3 | Oui | Terraform → « prod » Compétence n°5 | 4/4 | Oui | Gitlab CI Compétence n°6 | **1**/3 | Partiellement | postgresql-ha, Velero Compétence n°7 | 4/4 | Oui | Docker @@ -49,10 +48,9 @@ tests concernant le système de sauvegarde qui a été développé mais pas déployé, **faute de tests et de temps**. La **compétence n°9** (Définir et mettre en place des statistiques de -services) ne semble pas pertinente dans un projet où nous n'avons eu **aucun -autre interlocuteur que le « mentor »**. +services) n'a pu être clairement établie **faute d'interlocuteur autre que le +« mentor »**. 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. Ce qui, à mon sens, ne résoud pas totalement -cette compétence. +mis en place dans la solution. diff --git a/content/20_cahier_des_charges.md b/content/20_cahier_des_charges.md index 7514a7f..b9d91b4 100644 --- a/content/20_cahier_des_charges.md +++ b/content/20_cahier_des_charges.md @@ -1,5 +1,3 @@ -\newpage - # Cahier des charges Dans le cadre d'une **formation, dans l'école DataScientest**, il a été @@ -16,57 +14,58 @@ contraintes attenantes. ### Dans le cadre d'une formation -**[Datascientest]{#datascientest}** est une **école de formation** créée en +**[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*. 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). +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**. +Plusieurs élèves se regroupent autour d'un projet pour lequel ils ont un +**intérêt commun**. ### L'équipe DevU42 {#devu42} Le **groupe DevU42** s'est formé le **17 octobre 2024**. Il est composé de **quatre étudiants** participant à la formation **Administrateur Système -DevOps** de l’organisme de formation [DataScientest](#datascientest). +DevOps** de l'organisme de formation [DataScientest](#datascientest). -Ses membres sont, par ordre alphabétique (prénom) : +Ses membres sont, par ordre alphabétique : -* **Eliel MONCADA** -* **Hrubech HOMBESSA** -* **Julien SABIOLS** -* Olivier DOSSMANN +* **Hrubech \textsc{Hombessa}**, +* **Eliel \textsc{Moncada}**, +* **Julien \textsc{Sabiols}**, +* et Olivier \textsc{Dossmann}. -Ils interviennent sur le projet en qualité d’**Administrateur Système DevOps**. +Ils interviennent sur le projet en qualité d'**Administrateur Système DevOps**. -L'équipe a été supervisée et suivie par [**Jérémie Tarot** sous la -dénomination de **« Mentor »**]{#mentor}. Et ainsi en sera-t-il dans le -présent document. +L'équipe a été supervisée et suivie par [**Jérémie \textsc{Tarot}** sous la +dénomination de **« Mentor »**]{#mentor}. Et ainsi en sera-t-il +dans le présent document. ### Organisation d'équipe -Pour s'organiser, l'équipe s'est doté de plusieurs outils et suivi quelques méthodologies. +Pour s'organiser, l'équipe s'est dotée de plusieurs outils et suivi certaines +méthodologies particulières. #### Rapports hiérarchiques -L’équipe s'articule autour de membres ayant le **même degré de +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. En cas de désaccord sur un sujet, une décision est prise à la majorité -votante, avec pour ultime recours l’avis du [Mentor](#mentor). +votante, avec pour ultime recours l'avis du [Mentor](#mentor). #### Moyens de communication La géolocalisation des membres de l'**équipe étant éparse**, plusieurs moyens -de communication **en ligne** ont été nécessaires, parmi : +de communication **en ligne** ont été nécessaires, parmi lesquels : * Canaux de **discussions sur [Slack](https://slack.com/intl/fr-fr/)** fournis -initialement par [Datascientest](#datascientest) : +initialement par [DataScientest](#datascientest) : * canal du projet - **sep24_bootcamp_devops** : favorise l'échange entre [DevU42](#devu42) et le [Mentor](#mentor), * canal d'équipe - **devu42** : pour les **discussions techniques**, @@ -96,7 +95,7 @@ la formation : Le budget alloué au projet est de **150€ mensuel** pour couvrir l'intégralité des frais issus de l'utilisation de **services Amazon** (AWS). -C'est une limite configurée par [Datascientest](#datascientest) sur l'espace +C'est une limite configurée par [DataScientest](#datascientest) sur l'espace Amazon qu'ils nous partagent. #### Temps @@ -108,7 +107,7 @@ Au terme des 7 semaines, un support visuel de présentation du projet pour son lancement est attendu (Cf. [Section du présent chapitre sur les Livrables](#livrables)). -Après livraison, l’amélioration du projet est possible, bien qu'un dossier +Après livraison, l'amélioration du projet est possible, bien qu'un dossier professionnel, un dossier de projet (ci-présent) et un support de présentation est demandé à chacun des [membres de l'équipe DevU42](#devu42). @@ -126,14 +125,14 @@ puisse **apprendre par la pratique**. On imagine facilement le cadre : -> Une entreprise ayant une application de gestion d’utilisateur souhaite +> 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. De la même manière, l'entreprise pourrait rencontrer de nombreux **problèmes** : -* **Reprise d’activité** lente, coûteuse et avec pertes d’informations, +* **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 @@ -143,7 +142,7 @@ service, 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és** avec +* Lenteurs d'implémentation de **nouvelles fonctionnalités** avec interruptions de service. Pour bien saisir l'état des lieux de ladite application, regardons de plus @@ -156,7 +155,7 @@ suivants : * Backend utilisant le framework **FastAPI** (en Python), * Frontend statique (en **React**, **Vite.js** et **Chakra UI**) : -Interface de gestion et d'enregistrement d’utilisateurs utilisant l'API du +Interface de gestion et d'enregistrement d'utilisateurs utilisant l'API du backend, * Base de données **postgreSQL**, * et **Traefik** (Proxy inverse). @@ -176,20 +175,20 @@ Mais **le projet voit plus loin**. En dehors des objectifs à atteindre, le projet vise à : -* répondre aux problématiques de l’entreprise sur l'application existante par +* 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 +* 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** (Amazon Web Services), -* appliquer une méthode de travail qui optimise l’efficacité de la production +* 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 -D'après moi, ce projet à plusieurs objectifs : +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**, @@ -198,7 +197,7 @@ 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**, +* penser à la **gestion des données**, * **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 @@ -208,7 +207,7 @@ 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, +développement et les équipes d'opération, * et obtenir des **alertes** en cas de défaillance d'un ou plusieurs éléments du système. @@ -218,17 +217,18 @@ primordiaux. ## Planification -C'est par le [mentor](#mentor) que nous avons reçu le plan d'action pour les 7 -semaines de travail à venir et une liste de livrables attendus. Nous avons -adapté ce plan d'action pour nous correspondre. +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 +livrables attendus. ### Étapes de travail -Commençons par le détail de chaque étape. Pour les 7 semaines à venir. +Le plan s'articule en étapes bien définies. #### Semaine 1 : Cadrage -Sous le signe de l'**encadrement**, cette première semaine est dite « douce » : +Sous le signe de l'**encadrement**, cette première semaine est dite +« douce » : * **réunion** de prise de contact, présentation et cadrage, * introduction de chaque membre du projet, @@ -257,7 +257,7 @@ Nous prévoyons aussi : * une **configuration de Gitlab**, des principaux dépôts, des branches, etc., * de s'organiser en équipe : définir des **méthodologies** à suivre. -#### Semaine 3 : Automatisation de la chaine d’intégration et de livraison +#### Semaine 3 : Automatisation de la chaine d'intégration et de livraison Une fois les outils principaux mis en place, il s'agit d'**automatiser** plusieurs parties : @@ -276,7 +276,7 @@ pas encore clairement définie). L'**adoption d'un workflow Git** pour la gestion des branches est la bienvenue. -#### Semaine 4 : Conception de l’infrastructure +#### Semaine 4 : Conception de l'infrastructure Vient ensuite la création de la **couche basse de l'infrastructure** : @@ -303,8 +303,8 @@ alertes](#semaine6), la gestion des données est importante et passe par : * et installer/configurer une solution de **sauvegarde** et de **restauration de données**. -C'est un sujet bien à part. D'où la possibilité de la **faire en parallèle** -d'un autre. +C'est un sujet bien à part. D'où la possibilité de **faire cette étape en +parallèle** d'une autre. #### Semaine 6 : Observabilité et alertes {#semaine6} @@ -316,7 +316,7 @@ gérer : 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, +* **définition des niveaux d'alertes** pour les métriques choisies, * mise en place des **alertes**, * et envoi des alertes sur **les canaux choisis**. @@ -335,7 +335,7 @@ de l'application**. Il faudra donc : * et résoudre les derniers problèmes majeurs connus - s'ils existent. C'est un **plan ambitieux** quand on considère que **les membres de l'équipe -proviennent d'horizons et de formations variées**. +proviennent d'horizons et de formations variés**. ### Livrables {#livrables} @@ -360,7 +360,7 @@ Le projet **couvre beaucoup de situations** et **domaines** autour de 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é par [DataScientest](#datascientest) et couvrir un maximum -de compétences demandées pour le *Titre Professionnel d'Administrateur +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. diff --git a/content/30_specifications_techniques.md b/content/30_specifications_techniques.md index 5593881..dfac720 100644 --- a/content/30_specifications_techniques.md +++ b/content/30_specifications_techniques.md @@ -11,8 +11,8 @@ outils utilisés. ## Étude de l'application Le dépôt Git contenant l'application **existait déjà**. Une étude des -composants fournis par le projet a donc été nécessaire. Ce qui a été fournis -aux développeurs également. Ce qui a permis d'en mesurer les implications. +composants fournis a donc été nécessaire, ce qui a permis d'en mesurer les +implications. ### Composants de l'application @@ -54,11 +54,12 @@ prendra connaissance des particularités de cette application. ### Points d'attentions -La **partie Frontend** permet de générer des fichiers dits « statiques », du -**serverless** est envisageable. L'application, bien que faisant des appels à -une API, fonctionne de manière **autonome**. Ce qui, a priori, facilite la -préparation pour un déploiement. Cependant **un nom de domaine est inscrit en -dur dans le fichier Dockerfile**, ce qui peut compliquer un déploiement sur +La **partie Frontend** permet de générer des fichiers dits +« statiques », du **serverless** est envisageable. L'application, +bien que faisant des appels à une API, fonctionne de manière **autonome**. Ce +qui, a priori, facilite la préparation pour un déploiement. Cependant les +développeurs de l'application utilisent **un nom de domaine inscrit en dur +dans le fichier Dockerfile**, ce qui peut compliquer un déploiement sur plusieurs domaines et environnements. La **partie backend** s'appuie sur une base de données de type PostgreSQL. Elle @@ -165,9 +166,10 @@ sur **chaque machine des développeurs** à l'aide des outils fournis (Dockerfile, docker-compose du projet applicatif), * l'environnement de **test** : il est composé de l'**ensemble des Runner Gitlab** utilisés à l'intérieur de la chaîne d'intégration continue, -* l'environnement de **pré-production** (appelé « **staging** ») : c'est -l'infrastructure présentée ci-avant, appliquée dans AWS avec une configuration -dite *plus légère* (moins de machines virtuelles EC2 par exemple), +* l'environnement de **pré-production** (appelé « **staging** » +) : c'est l'infrastructure présentée ci-avant, appliquée dans AWS avec +une configuration dite *plus légère* (moins de machines virtuelles EC2 par +exemple), * et l'environnement de **production** : c'est l'**infrastructure finale** ; celle qui est disponible aux utilisateurs finaux (les usagers). @@ -232,21 +234,23 @@ non-exhaustive : * les données brutes de l'application, stockées dans la **base de données postgreSQL**, * les **données sensibles** (mots de passe, clés d'accès), -* les **copies de sauvegardes** des données elle-même, +* les **copies de sauvegardes** des données elles-mêmes, * et les **fichiers de journalisation** des services en production. Regardons pour chacun des points de cette liste où se situe le stockage. #### Stockage -En reprenant les éléments précédent, nous avons : +Les éléments précédents donnent lieu au tableau suivant : -* des **dépôts Gitlab** pour notre code applicatif ET les dépôts de -l'infrastructure, gérés par Gitlab, -* un **stockage AWS EBS** (Elastic Block Store) pour la base de données -postgreSQL, -* et un **stockage AWS S3** (Simple Storage Service) pour les copies de -sauvegardes. +: Données présentes et leur lieu de stockage + +Données | Stockage +-----|----- +Code applicatif | **dépôt Gitlab** +Code de l'infrastructure | **dépôt Gitlab** +Base de données postgreSQL | **stockage AWS EBS** (Elastic Block Store) +Sauvegardes | **stockage AWS S3** (Simple Storage Service) Cela devrait être suffisant pour stocker les diverses données disponibles. @@ -267,7 +271,7 @@ postgreSQL-HA](./media/postgresql-ha.png){height=50%} Les dépôts de version utilisés étant sur Gitlab, [service qui se targue d'être entre 99% et 100% disponible]( https://handbook.gitlab.com/handbook/engineering/monitoring/#historical-service-availability) -, une **sauvegarde dite « préventive » mensuelle** suffit. +, une **sauvegarde dite « préventive » mensuelle** suffit. En revanche **la production**, même en **étant un service en haute disponibilité**, doit fournir au moins **une sauvegarde 1 fois par jour**. @@ -277,7 +281,7 @@ Son outil en ligne de commande permet de gérer les sauvegardes mais aussi 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 »). +stockage AWS S3** (dit « bucket S3 »). \newpage diff --git a/content/40_demarche.md b/content/40_demarche.md index 864f565..77c9fe0 100644 --- a/content/40_demarche.md +++ b/content/40_demarche.md @@ -7,7 +7,7 @@ application dans le Cloud. C'est une **nouvelle équipe**, dans un **nouvel environnement** avec une application inconnue et **des savoirs à acquérir**. En pareille situation, c'est tout un **écosystème DevOps** qu'il faut mettre -en place. Nous allons donc avant tout parler de **méthodologie utilisées** +en place. Nous allons donc avant tout parler des **méthodologies utilisées** pour ce faire, puis des **outils utilisés** et enfin aborder le sujet de **collaborations** avec d'autres équipes. @@ -15,13 +15,13 @@ pour ce faire, puis des **outils utilisés** et enfin aborder le sujet de ### Agile -Le choix d'une **méthodologie agile** « basique » s'est offerte à nous, +Le choix d'une **méthodologie agile** « basique » s'est offerte à nous, notamment par : * des **comptes-rendus journaliers rapides de 10mn** en respectant les points suivants : - * ce que j'ai fais hier, - * ai-je rencontré un/des problème(s) qui vaille(nt) d'être cité(s), + * ce que j'ai fait hier, + * ai-je rencontré un/des problème(s) qui vaut(valent) d'être cité(s), * ce que je compte faire aujourd'hui, * la **création de jalons** avec un ensemble de tâches sur une période d'une semaine, @@ -142,7 +142,7 @@ l'exemple montre une référence vers le ticket #18 du dépôt nommé *projet*. ## Outils -Au delà d'une à plusieurs méthodologies/normes/standards, nous avons utilisés +Au delà d'une à plusieurs méthodologies/normes/standards, nous avons utilisé des outils afférents. ### Nom de domaine @@ -153,8 +153,8 @@ location d'un nom de domaine : **devu42.fr**. Ce domaine fait référence à notre cursus de DevOps dans un centre de formation nommé **DevU**niversity. Le **nombre 42** est un chiffre connu lié aux -ouvrages de Douglas Adams dans sa trilogie en 5 volumes de « H2G2, Guide du -Voyageur Galactique ». +ouvrages de Douglas Adams dans sa trilogie en 5 volumes de « H2G2, Guide +du Voyageur Galactique ». Nous avons ainsi pu avoir des **noms de domaines spécifiques** pour : @@ -233,8 +233,8 @@ d'appliquer à nouveau le même workflow. ## Cas d'une collaboration inter-équipe {#collab} Dans le cadre de nos diverses **réflexions** nous avons eu un contact **avec -l'équipe** qui se nomme **« Team Matrix »** dont le sujet était le déploiement -de serveurs Matrix en haute disponibilité. +l'équipe** qui se nomme **« Team Matrix »** dont le sujet était le +déploiement de serveurs Matrix en haute disponibilité. Nous avons échangé sur le **sujet de la promotion des versions entre environnements**. Maxime, de la Team Matrix, et moi avons principalement @@ -248,8 +248,9 @@ https://codefresh.io/blog/how-to-model-your-gitops-environments-and-promote-rele L'idée de l'article, en quelques mots, est de **favoriser l'utilisation d'un dossier par environnement** plutôt qu'utiliser une branche Git pour chaque environnement. Il conseille également de faire la promotion des versions entre -ces différents environnements/dossiers. Avec un protocole à suivre par les « -humains » pour limiter de trop nombreuses promotions logicielles en même temps. +ces différents environnements/dossiers. Avec un protocole à suivre par les +« humains » pour limiter de trop nombreuses promotions logicielles +en même temps. Pour reprendre le schéma de l'article : @@ -257,7 +258,7 @@ Pour reprendre le schéma de l'article : versions](./media/article_schema_promotion.png){width=100%} Après moultes discussions, **nous sommes tombés d'accord** sur quelques -points, parmi : +points, notamment : * **ne pas utiliser une branche par environnement**, * essayer au maximum d'**avoir des dépôts indépendants** (favoriser la @@ -279,9 +280,9 @@ de sécurité**, des **tests du code**, vérification de la **couverture de code** et **tests sur la compilation** - éventuelle - de l'outil et/ou des **images Docker** puis **publication sur un registre**, * avoir une gestion de chacun de ces dépôts d'**un système de versionnement** -(les fameuses « releases »), +(les fameuses « releases »), * avoir la **même chose pour chaque module Terraform** que nous avons fabriqué -(par exemple notre module « networking »), +(par exemple notre module « networking »), * puis utiliser, dans un dépôt **infra** par exemple, seulement les versions de nos modules (situés indépendamment sur des registres), * de là on peut imaginer : @@ -293,12 +294,11 @@ de nos modules (situés indépendamment sur des registres), * ajouter des **tests de sécurité des images** (comme la somme de contrôle) avant utilisation dans d'autres dépôts. -À noter que Maxime et moi étions également arrivés sur le fait qu'il y a déjà -2 types de promotions dans tout cela : +Maxime et moi avons également relevé que lorsqu'on parle de promotions dans +l'infrastructure on peut imaginer 2 types de promotions : -* la promotion des versions des logiciels/modules/charts utilisés, -* et la promotion des configurations de ces derniers au sein de nos -infrastructures. +* la promotion de versions concernant les logiciels/modules/charts utilisés, +* et la promotion de configurations pour différentes infrastructures. C'est un autre sujet très intéressant que nous ne détaillerons pas ici. diff --git a/content/50_realisations.md b/content/50_realisations.md index 1625607..fc1b24e 100644 --- a/content/50_realisations.md +++ b/content/50_realisations.md @@ -79,12 +79,11 @@ pourquoi ne pas **utiliser Git lui-même à l'aide d'un commit sur le dépôt suivant** ? Ainsi, sans outils supplémentaires, nous pouvons lier les dépôts entre eux. +En suivant cette logique, nous obtenons le schéma représentant la pipeline de +chaque dépôt : + ```{=latex} \begin{sidewaysfigure} - -En suivant cette logique, nous obtenons le schéma représentant la pipeline de -chaque dépôt~: - \includegraphics{./media/schema_3_pipelines.png} \caption{Schéma des 3 pipelines} \end{sidewaysfigure} @@ -137,7 +136,7 @@ inform-charts: **Le code a dû être modifié (raccourcissement des lignes) pour les fins de rédaction du présent document**. -La **ligne 27 à 29** posent un tag sur le dépôt **charts** en mettant +Les **ligne 27 à 29** posent un tag sur le dépôt **charts** en mettant simplement à jour les versions utilisées du backend et du frontend dans les charts Helm sur le registre Gitlab. @@ -377,5 +376,5 @@ 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étail le +ayant amené à faire une recherche. Nous pourrons ainsi voir plus en détails le processus de travail suivi afin d'aboutir à ce résultat. diff --git a/content/60_situation_de_travail.md b/content/60_situation_de_travail.md index 0a44e00..b2649f6 100644 --- a/content/60_situation_de_travail.md +++ b/content/60_situation_de_travail.md @@ -3,8 +3,8 @@ # 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 -recherche effectuée par le candidat durant le projet** ». +je cite, « **une description d'une situation de travail ayant nécessité 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 décrire une situation complète. Nous allons poser le contexte, faire l'état @@ -77,14 +77,14 @@ Et c'est ce que j'ai fait : * **demande à un ami DevSecOps** si je pouvais l'interpeller de temps en temps sur l'un ou l'autre sujet, -* achat du **livre « Kubernetes - Guide pratique »** aux éditions +* achat du **livre « Kubernetes - Guide pratique »** aux éditions \textsc{O'Reilly}, * recherche, infructueuse, **à la médiathèque** : le rayon informatique est maigre, * recherche sur le domaine du DevOps **sur Internet** avec une **grande -lecture initiale** de [**Stéphane Robert** (Devenez expert DevOps et maîtrisez -ses outils)](https://blog.stephane-robert.info/){#stephane-robert} (j'ai -repris le titre du site tel quel). +lecture initiale** de [**Stéphane \textsc{Robert}** (Devenez expert DevOps et +maîtrisez ses outils)](https://blog.stephane-robert.info/){#stephane-robert} +(j'ai repris le titre du site tel quel). ![Première de couverture du livre O'Reilly, Kubernetes - Guide pratique](./media/livre-oreilly.jpg){height=35%} @@ -94,9 +94,10 @@ pratique](./media/livre-oreilly.jpg){height=35%} ### Point de départ Grâce à la lecture de quantité d'articles sur le blog de [Stéphane -Robert](#stephane-robert), notamment la [série d'article sur « Mon nouveau -Homelab DevOps](https://blog.stephane-robert.info/docs/homelab/introduction/) -(Cf. https://blog.stephane-robert.info/docs/homelab/introduction/) et la +\textsc{Robert}](#stephane-robert), notamment la [série d'article sur +« Mon nouveau Homelab DevOps »]( +https://blog.stephane-robert.info/docs/homelab/introduction/) (Cf. +https://blog.stephane-robert.info/docs/homelab/introduction/) et la **Roadmap de son parcours de formation DevSecOps** (Cf. https://blog.stephane-robert.info/docs/#la-roadmap), j'ai pu établir des **objectifs à court terme** et des étapes de sujets à aborder comme : @@ -105,7 +106,7 @@ https://blog.stephane-robert.info/docs/#la-roadmap), j'ai pu établir des * **le GitOps avec** un outil tel que **FluxCD**. ![Apparence de la page d'accueil du blog de Stéphane -Robert](./media/screenshot_stephane-robert.png){width=100%} +\textsc{Robert}](./media/screenshot_stephane-robert.png){width=100%} ### Recherches @@ -115,9 +116,11 @@ Je pars souvent de **sites de référence ou de sites que j'ai déjà utilisé** plusieurs fois dans le passé. Le sujet de la virtualisation a donc donné lieu à **quelques recherches sur des sites déjà connus** : -* Le **wiki d'ArchLinux** et sa catégorie « **Virtualization** » : +* 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 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 @@ -143,7 +146,7 @@ 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 généré sur Gitlab](./media/screenshot_odtre_doc.png){width=100%} \newpage @@ -158,7 +161,7 @@ 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 **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 diff --git a/content/80_conclusion.md b/content/80_conclusion.md index bfc57b5..e78aaae 100644 --- a/content/80_conclusion.md +++ b/content/80_conclusion.md @@ -6,7 +6,7 @@ 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ù j'écris ces lignes pour **embrasser le métier d'Administrateur Système DevOps**. La formation, puis **le projet de fin de formation** ont été -**bénéfique à la prise d'expérience**, mais pas que. +**bénéfiques à la prise d'expérience**, mais pas que. En effet, **il est question de nouvelles compétences**, que le projet, à travers la rédaction d'un cahier des charges, de spécifications