diff --git a/Makefile b/Makefile index 92a4b5b..ad572a4 100644 --- a/Makefile +++ b/Makefile @@ -44,8 +44,8 @@ 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 (deactivated here) - $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} + # 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 .PHONY: clean diff --git a/content/05_intro.md b/content/05_intro.md index c18f1d1..464465e 100644 --- a/content/05_intro.md +++ b/content/05_intro.md @@ -2,32 +2,32 @@ # Introduction {#introduction} -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 +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 -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 -continu entre ces équipes. +que l'**automatisation**, entre autre, 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 +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 +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 -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 +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 -DevOps. Et ce à travers la formation DevOps en BootCamp au sein de l'organisme +DevOps. Et ce à travers la **formation DevOps en BootCamp** au sein de l'organisme de formation DataScientest. Le présent document présentera principalement le projet étudié lors de cette formation. Nous commencerons par faire la corrélation entre les compétences -attendues pour le Titre Professionnel Administrateur Système DevOps et le(s) +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 suivi pour accomplir le projet, +Nous continuerons par expliquer 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. diff --git a/content/08_remerciements.md b/content/08_remerciements.md index bcad953..d0e1e02 100644 --- a/content/08_remerciements.md +++ b/content/08_remerciements.md @@ -2,49 +2,104 @@ # 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écense l'humilité n'a qu'à bien se tenir ! +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écense l'**humilité** n'a qu'à bien se +tenir ! -À Madame \textsc{Schweitzer} pour ses **conseils**, son aide **précieuse**, sa **présence d'esprit** et son **exceptionnelle intelligence** : MERCI ! +À **Madame \textsc{Schweitzer}** pour ses **conseils**, son aide +**précieuse**, sa **présence d'esprit** et son **exceptionnelle +intelligence** : MERCI ! ## À l'organisme de formation DataScientest -Nous avons parfois besoin d'un coup de pouce pour rejoindre les rails d'une 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. +Nous avons parfois besoin d'un coup de pouce pour rejoindre les rails d'une +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 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. -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. +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. +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. -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, les examens et les machines virtuelles fournies. +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, +les examens et les machines virtuelles fournies. ## À l'équipe DevU42 -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. +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. -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 faits. Et rien que pour cela je remercie l'équipe d'y être parvenu. +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 +faits. Et rien que pour cela je remercie l'équipe d'y être parvenu. -À Eliel \textsc{Moncada} pour ses trouvailles Web et sa patience sur les schémas visuels qui prennent un temps considérable ! +À 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. +À 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 ! +À 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 ! -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. +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. -## Au 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. +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. -Une mention particulière aux personnes suivantes (ordre alphabétique - prénom) : +Une mention particulière aux personnes suivantes (ordre alphabétique - +prénom) : -* à 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 ! +* à 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 ! ## Et les autres -D'autres personnes n'ayant aucun lien avec cette formation ont pourtant 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 ! +D'autres personnes n'ayant aucun lien avec cette formation ont pourtant +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'aurais 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 omi le nom/prénom. +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. diff --git a/content/10_liste_competences.md b/content/10_liste_competences.md index 08b7ac5..e22fac7 100644 --- a/content/10_liste_competences.md +++ b/content/10_liste_competences.md @@ -2,42 +2,57 @@ # 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 : +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 scripts** +* 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 cloud** + * 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 application avec une plateforme** + * 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 services** + * Compétence **n°9 : Définir et mettre en place des statistiques de + services** * Compétence **n°10 : Exploiter une solution de supervision** - * Compétence **n°11 : Échanger sur des réseaux professionnels éventuellement en anglais** + * Compétence **n°11 : Échanger sur des réseaux professionnels + éventuellement en anglais** -En utilisant les critères de performance fournis par chaque fiche de compétence, nous avons pu établir le tableau suivant : +En utilisant les critères de performance fournis par chaque fiche de +compétence, j'ai pu établir le tableau suivant : -: Couverture de compétences par le projet +: Couverture de compétences du projet 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 | Non | postgresql-ha, Velero +Compétence n°6 | **1**/3 | Partiellement | postgresql-ha, Velero Compétence n°7 | 4/4 | Oui | Docker -Compétence n°8 | 3/4 | Oui | Gitlab CI, Terraform, staging/prod -Compétence n°9 | 0/3 | Non | Aucun interlocuteur -Compétence n°10 | 1/3 | Non | Datadog +Compétence n°8 | **3**/4 | Oui | Gitlab CI, Terraform, staging/prod +Compétence n°9 | **0**/3 | Non | Aucun interlocuteur +Compétence n°10 | **1**/3 | Partiellement | Datadog Compétence n°11 | 3/3 | Oui | Tout au long du projet -La couverture de la compétence n°6 (Gérer le stockage de données) manque de 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 ». \ -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. +La couverture de la **compétence n°6** (Gérer le stockage de données) manque de +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 »**. + +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. diff --git a/content/20_cahier_des_charges.md b/content/20_cahier_des_charges.md index 3381723..7514a7f 100644 --- a/content/20_cahier_des_charges.md +++ b/content/20_cahier_des_charges.md @@ -2,36 +2,49 @@ # Cahier des charges -Premier élément du projet sur lequel travailler : le cahier des charges. - -## Contexte - -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. +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. +## Contexte + +Commençons par le contexte du projet avec l'ensemble des intervenants et des +contraintes attenantes. + ### Dans le cadre d'une formation -[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. +**[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). +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. +Plusieurs élèves se regroupent autour d'un projet auquel 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**. +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). Ses membres sont, par ordre alphabétique (prénom) : -* Eliel MONCADA -* Hrubech HOMBESSA -* Julien SABIOLS +* **Eliel MONCADA** +* **Hrubech HOMBESSA** +* **Julien SABIOLS** * Olivier DOSSMANN 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 Tarot** sous la +dénomination de **« Mentor »**]{#mentor}. Et ainsi en sera-t-il dans le +présent document. ### Organisation d'équipe @@ -39,232 +52,315 @@ Pour s'organiser, l'équipe s'est doté de plusieurs outils et suivi quelques m #### 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. +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). +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). #### Moyens de communication -La géolocalisation des membres de l'équipe étant éparse, plusieurs moyens de communication en ligne ont été nécessaires, parmi : +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 d'équipe - devu42 : pour les discussions techniques, les choix déccisifs et de la bonne humeur ! +* 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 d'équipe - **devu42** : pour les **discussions techniques**, + les choix décisifs et de la bonne humeur ! * Un nom de domaine, **devu42.fr**, -* Une boîte courriel, partagée pour la gestion des services, -* [**Gitlab**, DevU42](https://gitlab.com/devu42/), un outil intégré avec gestion d'équipe, gestion de projet, gestion de tickets, gestion de tableau de bord (kanban), gestion de dépôts, gestion de paquets, etc. -* Un [wiki, DevU42](https://gitlab.com/devu42/projet/-/wikis/home) (fourni par Gitlab) permettant de rassembler les connaissances de l'équipe en un seul endroit, -* [**Framapad**](https://framapad.org/abc/fr/), un éditeur de texte collaboratif pour les divers travaux de rédaction. +* Une boîte courriel, **** partagée pour la **gestion des +services**, +* [**Groupe DevU42 sur Gitlab**](https://gitlab.com/devu42/), un outil intégré +avec gestion d'équipe, gestion de projet, gestion de tickets, gestion de +tableau de bord (kanban), gestion de dépôts, gestion de paquets, etc. +* Un [**wiki**, DevU42 sur +Gitlab](https://gitlab.com/devu42/projet/-/wikis/home) (fourni par Gitlab) +permettant de rassembler les **connaissances de l'équipe** en un seul endroit, +* [**Framapad**](https://framapad.org/abc/fr/), un éditeur de **texte +collaboratif** pour les divers travaux de rédaction. ### Contraintes initiales -Deux principales contraintes initiales avaient été imposées dans le cadre de la formation : +Deux principales contraintes initiales avaient été imposées dans le cadre de +la formation : -* le budget, -* le temps. +* le **budget**, +* le **temps**. #### Budget -Le budget alloué au projet est de **150€ mensuel** pour couvrir l'intégralité des frais issus de l'utilisation de services Amazon (AWS). +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 Amazon qu'ils nous partagent. +C'est une limite configurée par [Datascientest](#datascientest) sur l'espace +Amazon qu'ils nous partagent. #### Temps -Le temps alloué pour réaliser ce projet avant un premier lancement officiel est fixé à **7 semaines**. +Le temps alloué pour réaliser ce projet avant un premier lancement officiel +est fixé à **7 semaines**. -Après livraison, l’amélioration du projet en continu se fera sur **6 semaines supplémentaires** durant lesquelles un dossier professionnel et un support de présentation est demandé à chacun des [membres de l'équipe](#devu42). +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 +professionnel, un dossier de projet (ci-présent) et un support de présentation +est demandé à chacun des [membres de l'équipe DevU42](#devu42). ## 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. +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 -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. +L'école de formation [DataScientest](#datascientest) s'évertue à proposer une +**situation proche de la réalité** afin que l'équipe nouvellement formée +puisse **apprendre par la pratique**. -On imagine ainsi le cadre suivant : +On imagine facilement le cadre : -> 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. +> 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, on imagine de l'entreprise une façon de fonctionner ayant de nombreux problèmes : +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, -* 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, +* **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. +* Manque de **portabilité de l'application** d'un système à l'autre, +* 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 près. +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 : +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 postgreSQL, -* et Traefik (Proxy inverse). +* 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 +backend, +* 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. +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. +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. +**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. +Mais **le projet voit plus loin**. ### Ambitions 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. +* 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** (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. +C'est de ces **ambitions** que naîssent plusieurs objectifs spécifiques. ### Objectifs 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. +* 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. +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 -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. +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. ### Étapes de travail -Voici le détail de chaque étape de travail. +Commençons par le détail de chaque étape. Pour les 7 semaines à venir. #### 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, +* **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. +* **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**. Il faut ce temps pour découvrir de quoi il retourne. #### Semaine 2 : Planification -Vient ensuite une phase d'organisation avec : +Vient ensuite une **phase d'organisation** avec : * 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. +* **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. -Ce qui amène à compléter le cahier des charges. +Ce qui amène à **compléter le cahier des charges**. Nous prévoyons aussi : -* une configuration de Gitlab, des principaux dépôts Gitlab, des branches, etc., -* de s'organiser en équipe : définir des méthodologies à suivre. +* 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 -Une fois les outils principaux mis en place, il s'agit d'automatiser certaines choses : +Une fois les outils principaux mis en place, il s'agit d'**automatiser** +plusieurs parties : -* 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). +* 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 d'images**, +* 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 sur +des registres d'images**, +* et **automatisation de la création de l'infrastructure** (même si elle n'est +pas encore clairement définie). -L'adoption d'un workflow pour la gestion des branches Git est la bienvenue. +L'**adoption d'un workflow Git** pour la gestion des branches est la bienvenue. #### Semaine 4 : Conception de l’infrastructure -Vient ensuite la création de la couche basse de l'infrastructure : +Vient ensuite la création de la **couche basse de l'infrastructure** : -* 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. +* **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**. -Une semaine n'est pas suffisante pour traiter tous les sujets. En revanche cela permet de les aborder et d'échanger sur ces derniers. +Une semaine n'est pas suffisante pour traiter tous les sujets. En revanche +cela permet de les aborder et d'échanger sur ces derniers. #### Semaine 5 : Gestion des données -La semaine 5 passe par : +Possiblement en parallèle du [sujet de la semaine 6 sur l'Observabilité et des +alertes](#semaine6), la gestion des données est importante et 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. +* 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/configurer une solution de **sauvegarde** et de **restauration +de données**. -Rien de très particulier à ce niveau là. +C'est un sujet bien à part. D'où la possibilité de la **faire en parallèle** +d'un autre. -#### Semaine 6 : Observabilité et alertes +#### Semaine 6 : Observabilité et alertes {#semaine6} -Quant à la semaine 6, nous avons principalement la supervision à gérer : +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. +* 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. +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 : +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, +* 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. +C'est un **plan ambitieux** quand on considère que **les membres de l'équipe +proviennent d'horizons et de formations variées**. -### Livrables +### Livrables {#livrables} -Sont attendus les éléments suivants : +Sont attendus les **livrables** 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. +* 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. +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. +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 26f1cff..5593881 100644 --- a/content/30_specifications_techniques.md +++ b/content/30_specifications_techniques.md @@ -3,26 +3,32 @@ # Spécifications techniques Après avoir décrit, via un cahier des charges, les différents besoins du -projet, les livrables attendus, il est temps de décrire une solution choisie. -Nous aborderons avant tout l'étude de l'existant puis enchaînerons sur le -détail de l'infrastructure choisie pour terminer sur divers sujets intégrés -et quelques outils utilisés. +projet, les livrables attendus, il est temps de décrire une solution. Nous +aborderons avant tout l'étude de l'existant puis enchaînerons sur le détail de +l'infrastructure choisie pour terminer sur divers sujets intégrés et quelques +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. +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 de l'application -L'équipe de développement a fait le choix du **monorepo** pour contenir l'ensemble des éléments de l'application. L'application est composée de : +L'équipe de développement a fait le choix du **monorepo** pour contenir +l'ensemble des éléments de l'application. L'application est composée de : -* une base de données PostgreSQL, -* un backend écrit en Python et construit sur FastAPI, -* un frontend écrit en TypeScript et construit avec ReactJS. +* une **base de données** PostgreSQL, +* un **backend** écrit en Python et construit sur **FastAPI**, +* un **frontend** écrit en TypeScript et construit avec **ReactJS**. + +\newpage L'ensemble se comprend mieux à l'aide du schéma suivant : -![Schéma des composants de l'application](./media/schema_composants_application.png){height=55%} +![Schéma des composants de +l'application](./media/schema_composants_application.png){height=55%} ### Outils fournis aux développeurs @@ -33,104 +39,167 @@ Via le dépôt, les développeurs ont accès à : * un fichier **backend/README.md** pour les développeurs du Backend, * un fichier **frontend/README.md** pour les développeurs du Frontend, * plusieurs fichiers **Docker Compose** afin de déployer localement : - * une **base de données (BDD) PostgreSQL** avec un **jeu de données préchargé**, - * une interface Web, via l'outil adminer, à la BDD, - * le backend (FastAPI), - * le frontend (ReactJS), -* une documentation **deployment.md** pour déployer le projet à l'aide de **Docker Compose**, -* un fichier **docker-compose.traefik.yml** afin de déployer une instance locale du **proxy Traefik** configuré pour utiliser Docker + * une **base de données (BDD) PostgreSQL** avec un **jeu de données + préchargé**, + * un accès à la BDD via une interface Web, via l'outil nommé **adminer**, + * le **backend** (FastAPI), + * le **frontend** (ReactJS), +* une documentation **deployment.md** pour déployer le projet à l'aide de +**Docker Compose**, +* et un fichier **docker-compose.traefik.yml** afin de déployer une instance +locale du **proxy Traefik** configuré pour utiliser Docker. -Ces éléments sont un bon point de départ pour l'équipe de DevOps qui prendra connaissance des particularités de cette application. +Ces éléments sont un **bon point de départ pour l'équipe de DevOps** qui +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 plusieurs domaines et environnements. +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 +plusieurs domaines et environnements. -La partie Backend s'appuie sur une base de données de type PostgreSQL. Elle est donc **dépendante de la BDD**. +La **partie backend** s'appuie sur une base de données de type PostgreSQL. Elle +est donc **dépendante de la BDD**. -La partie proxy utilise actuellement **Traefik comme outil**. Ce qui n'est pas une obligation d'usage pour déploiement en production. +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**. +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**. ## Infrastructure -Afin d'accueillir l'application dans le Cloud, l'infrastructure de base va poser les fondations de l'environnement complet nécessaire à un usage quotidien. +Afin d'accueillir l'application dans le Cloud, l'infrastructure de base va +poser les fondations de l'environnement complet nécessaire à un usage +quotidien. ### Couche basse -La couche basse pourrait définir le minimum nécessaire avant d'installer quoique ce soit pour exploiter l'application. En ce sens, on utilise des éléments de base d'Amazon Web Services (AWS) pour fabriquer notre infrastructure : +La couche basse pourrait se définir comme le minimum nécessaire avant +d'installer quoique ce soit pour exploiter l'application. En ce sens, on +utilise des éléments de base d'Amazon Web Services (AWS) pour fabriquer notre +infrastructure : * un espace privé, Virtual Private Cloud (**VPC**), * sur plusieurs **régions**, * avec plusieurs zones de disponibilités (**Availability Zone**), -* contenant chacune, d'un point de vue réseau informatique, des réseaux publics (**public subnet**) et des réseaux privés (**private subnet**), -* en utilisant une passerelle entre le VPC et Internet, appelée **Internet Gateway** (IGW), -* en utilisant des passerelles **NAT** (Network Access Translation) entre les réseaux privés et les réseaux publics pour un accès à l'IGW, -* avec des groupes de sécurité (**Security groups**) pour définir les règles d'entrée/sortie, -* et des équilibreurs de charge de type réseau (**Network Load Balancer**) afin de gérer les accès aux services de manière équilibrée. +* contenant chacune, d'un point de vue réseau informatique, des réseaux +publics (**public subnet**) et des réseaux privés (**private subnet**), +* en utilisant une passerelle entre le VPC et Internet, appelée **Internet +Gateway** (IGW), +* en utilisant des passerelles **NAT** (Network Access Translation) entre les +réseaux privés et les réseaux publics pour un accès à l'IGW, +* avec des groupes de sécurité (**Security groups**) pour définir les règles +d'entrée/sortie, +* et des équilibreurs de charge de type réseau (**Network Load Balancer**) +afin de gérer les accès aux services de manière équilibrée. + +\newpage 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%} +![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. +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 conteneurisées, d'automatiser le déploiement et de gérer la mise à l'échelle (**auto-scaling**). +**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**). -Sur l'infrastructure présentée dans le paragraphe précédent il va falloir ajouter quelques éléments comme : +Sur l'infrastructure présentée dans le paragraphe précédent il va falloir +ajouter quelques éléments comme : -* un cluster Kubernetes appelé EKS (**Elastic Kubernetes Service**) géré par Amazon, -* avec l'usage d'une mise à l'échelle (**autoscaling**) des serveurs virtuels EC2 (Elastic Container) d'Amazon, -* un équilibreur de charge de type réseau entre l'extérieur du cluster et le cluster (**AWS Elastic LoadBalancer** ou ELB) ; présent d'ailleurs dans le schéma de la couche basse de l'infrastructure dans le paragraphe précédent, -* un équilibreur de charge de type réseau (couche 4 du modèle OSI - Open Systems Interconnection) qui fait le lien entre les services et l'extérieur du cluster : **NGINX Ingress Controller** ; il va notamment échanger avec l'AWS Elastic LoadBalancer précédent, -* l'utilisation d'un agent **externaldns** qui va mettre à jour les routes DNS (Domain Name System) de **Route53** pour les sous-domaines utilisés (~16€/mois pour 3 routes), -* et avec l'usage de **cert-manager** pour faire la demande de certificats SSL (Secure Sockets Layer) via le service - gratuit - de **Let's Encrypt** pour nos sous-domaines. +* un cluster Kubernetes appelé EKS (**Elastic Kubernetes Service**) géré par +Amazon, +* avec l'usage d'une mise à l'échelle (**autoscaling**) des **serveurs +virtuels EC2**(Elastic Container) d'Amazon, +* un équilibreur de charge de type réseau entre l'extérieur du cluster et le +cluster (**AWS Elastic LoadBalancer** ou ELB) ; présent d'ailleurs dans le +schéma de la couche basse de l'infrastructure dans le paragraphe précédent, +* un équilibreur de charge de type réseau (couche 4 du modèle OSI - Open +Systems Interconnection) qui fait le lien entre les services et l'extérieur du +cluster : **NGINX Ingress Controller** ; il va notamment échanger avec +l'AWS Elastic LoadBalancer précédent, +* l'utilisation d'un agent **externaldns** qui va mettre à jour les routes DNS +(Domain Name System) de **Route53** pour les sous-domaines utilisés (~16€/mois +pour 3 routes), +* et avec l'usage de **cert-manager** pour faire la demande de certificats SSL +(Secure Sockets Layer) via le service - gratuit - de **Let's Encrypt** pour +nos sous-domaines. -Le contenu du cluster EKS, une fois implémenté, pourrait ressembler à ceci : +Le contenu du cluster EKS, une fois implémenté, pourrait ressembler à +ceci : -![Schéma des applications et services contenu(e)s dans le cluster EKS](./media/schema_contenu_eks.png){width=100%} +![Schéma des applications et services contenu(e)s dans le cluster +EKS](./media/schema_contenu_eks.png){width=100%} -Dans le cluster pourra donc tourner, en plus des agents précédemment cités, les applications suivantes : +**Pourra tourner dans le cluster**, en plus des agents précédemment cités, +**les applications suivantes** : -* le serveur de BDD postgreSQL, -* le backend de l'application (FastAPI), -* et le frontend de l'application (en fichiers statiques). +* le serveur de BDD **postgreSQL**, +* 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 automatiser au maximum les étapes entre la publication d'une nouvelle version de l'application et sa livraison. Puis son déploiement en production via une intervention humaine. +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 +de l'application et sa livraison. Puis son déploiement en production via une +intervention humaine. ### Environnements Nous parlons de production depuis un moment. À quoi cela correspond ? -Afin de mener à bien le travail de DevOps, nous avons défini les différents environnements par lesquels nous allons passer pour toute notre chaîne de production logicielle. Ainsi nous avons 4 environnements : +Afin de mener à bien le travail de DevOps, nous avons défini les différents +environnements par lesquels nous allons passer pour toute notre chaîne de +production logicielle. Ainsi **nous avons 4 environnements** : -* l'environnement de **développement** : c'est l'environnement disponible 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), -* et l'environnement de production : c'est l'infrastructure finale ; celle qui est disponible aux usagers. +* l'environnement de **développement** : c'est l'environnement disponible +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), +* et l'environnement de **production** : c'est l'**infrastructure +finale** ; celle qui est disponible aux utilisateurs finaux (les usagers). -[//]: # Cf. https://mermaid.live/view#pako:eNptkkFugzAQRa9izRoiAiUkLLrKtlKldtXShYUHYtXY1Nhp05AD5Ry5WAcCUSuVFR6_-X4e-QilEQg5VMp8ljtuHXveFprRJ3D_WvG84mGLtjM6FLKupa7Z9nLeozJtiw1q93alP_gE18gte8Zu3ugcH7qmXSU7F5Y7LN_Zo72cw9Ya4UsnjZ7woTCxpTJeEPaLuJmxMLxnvcCGa4FUYJXvCOnJY_a5Io5MOsa9Mw138sNj189Kf_yu9J4rKfhwGKNkj0phPyrNR8-xl_NwCTam94PQP2FSj3GX8wRAAA3ahktB8z4ODQW4HQ2xgJx-BVbcK1dAoU-EDspPB11C7qzHAKzx9Q5oLqqjlW9JE7eS15Y3M9Jy_WJMc4NoDfkRviCPo2SxSdZplEXrKMrWyziAA5Wz5SJJ0ihebrJ4la7i9BTA9xgRLVZJnCXZJrlL19S6CgCFdMY-XN_L-GxOP_j4v68 +\newpage -![Schéma des environnements utilisés](./media/schema_workflow_environnement.png){height=50%}\ +Le schéma des différents environnements est plus compréhensible : + +![Schéma des environnements +utilisés](./media/schema_workflow_environnement.png){height=50%} + +[commentaire1]: # Cf. https://mermaid.live/view#pako:eNptkkFugzAQRa9izRoiAiUkLLrKtlKldtXShYUHYtXY1Nhp05AD5Ry5WAcCUSuVFR6_-X4e-QilEQg5VMp8ljtuHXveFprRJ3D_WvG84mGLtjM6FLKupa7Z9nLeozJtiw1q93alP_gE18gte8Zu3ugcH7qmXSU7F5Y7LN_Zo72cw9Ya4UsnjZ7woTCxpTJeEPaLuJmxMLxnvcCGa4FUYJXvCOnJY_a5Io5MOsa9Mw138sNj189Kf_yu9J4rKfhwGKNkj0phPyrNR8-xl_NwCTam94PQP2FSj3GX8wRAAA3ahktB8z4ODQW4HQ2xgJx-BVbcK1dAoU-EDspPB11C7qzHAKzx9Q5oLqqjlW9JE7eS15Y3M9Jy_WJMc4NoDfkRviCPo2SxSdZplEXrKMrWyziAA5Wz5SJJ0ihebrJ4la7i9BTA9xgRLVZJnCXZJrlL19S6CgCFdMY-XN_L-GxOP_j4v68 ### Livraison continue et déploiement -Il est visé une CI/cd, c'est à dire une Intégration Continue (Continuous Integration) et une livraison continue (continuous delivery). **L'automatisation est donc essentielle.** +Il est visé une **CI/cd**, c'est à dire une **Intégration Continue** +(Continuous Integration) et une **livraison continue** (continuous delivery). +**L'automatisation est donc essentielle**. -Le déploiement en production passera par une validation manuelle. +**Le déploiement en production passera par une validation manuelle**. Doivent être automatisés : -* les tests du backend, -* les tests du frontend, -* l'étude de sécurité sur les dépendances des composants de l'application, -* la génération d'une image Docker pour le frontend et le backend, -* la publication de cette image sur un dépôt d'images, -* le déploiement d'un environnement de pré-production (appelé *staging*, dont nous parlerons dans le chapitre [Démarche suivie](#demarche)), -* le déploiement, une fois la validation manuelle sur l'environnement de pré-production faite, d'un environnement de production, -* et la mise en place initiale de l'infrastructure (appelée boostrap). +* les **tests du backend et du frontend**, +* l'étude de **sécurité sur les dépendances des composants** de l'application, +* la **génération** d'une **image Docker** pour le **frontend** et le +**backend**, +* la **publication** de cette image sur un **dépôt d'images**, +* le **déploiement d'un environnement de pré-production** (appelé *staging*, +dont nous parlerons dans le chapitre [Démarche suivie](#demarche)), +* le **déploiement**, une fois la validation manuelle sur l'environnement de +pré-production faite, **d'un environnement de production**, +* et la **mise en place initiale** de l'infrastructure (appelée **boostrap**). Nous retrouverons ces éléments dans les chapitres suivants. @@ -138,99 +207,142 @@ Nous retrouverons ces éléments dans les chapitres suivants. Plusieurs sujets tournent autour des services mis en place : -* les données : définit les éléments enregistrés à l'usage quotidien de l'application, -* la supervision : définit tous les éléments permettant de mesurer les différents services et d'alerter si les métriques dépassent des seuils définis, -* la sécurité : définit tout ce qui peut être mis en œuvre pour palier rapidement à des problèmes de sécurité de l'application, de l'infrastructure et des outils utilisés. +* les **données** : définit les éléments enregistrés à l'usage quotidien +de l'application, +* la **supervision** : définit tous les éléments permettant de mesurer +les différents services et d'alerter si les métriques dépassent des seuils +définis, +* la **sécurité** : définit tout ce qui peut être mis en œuvre pour +palier rapidement à des problèmes de sécurité de l'application, de +l'infrastructure et des outils utilisés. ### Données -Le sujet des données ne couvre pas uniquement les données brutes enregistrées par l'application, mais aussi la manière de les stocker, de les sauver via un plan de sauvegarde et de les restaurer si besoin. +Le sujet des données ne couvre pas uniquement les données brutes enregistrées +par l'application, mais aussi la manière de les stocker, de les sauver via un +plan de sauvegarde et de les restaurer si besoin. #### Où sont les données ? -Les données de ce projet sont multiples. En voici une liste non-exhaustive : +Les données de ce projet sont multiples. En voici une liste +non-exhaustive : * les dépôts contenant le **code applicatif** (backend + frontend), * les dépôts contenant la **description de l'infrastructure**, -* les données brutes de l'application, stockées dans la **base de données postgreSQL**, +* 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, * et les **fichiers de journalisation** des services en production. -Regardons pour chacun des points où se situe le stockage. +Regardons pour chacun des points de cette liste où se situe le stockage. #### Stockage En reprenant les éléments précédent, nous avons : -* 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. +* 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. Cela devrait être suffisant pour stocker les diverses données disponibles. +\newpage + #### Base de données postgreSQL -Pour le choix d'un service de base de données, nous avons fini par opter pour postgresql-ha (pour postgreSQL High Availability) qui s'appuie sur 2 bases de données répliquées avec un service **pgpool** par lequel on accède pour chaque requête faite à la base de données. +Pour le choix d'un service de base de données, nous avons fini par opter pour +**postgresql-ha** (pour postgreSQL High Availability) qui s'appuie sur **2 +bases de données répliquées** avec un service **pgpool** par lequel on accède +pour chaque requête faite à la base de données. -![Schéma du fonctionnement de postgreSQL-HA](./media/postgresql-ha.png){width=50%}\ +![Schéma du fonctionnement de +postgreSQL-HA](./media/postgresql-ha.png){height=50%} #### Sauvegardes -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. +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. -En revanche la production, même en étant un service en haute disponibilité doit fournir une sauvegarde au moins 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é. Son outil en ligne de commande permet de gérer les sauvegardes mais aussi les restaurations. +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é. +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 »). +Comme énoncé précédemment, les sauvegardes du cluster seront mises **sur un +stockage AWS S3** (dit « bucket S3 »). + +\newpage Le fonctionnement de Velero dans ce projet est visible sur le schéma suivant. -[//]: # Cf. https://mermaid.live/view#pako:eNptVE1v00AQ_SvWSr0lkWOTOPEBKU2CFLWUgkuRkKVqY08dK7Y37EegRLlxqiqBygFuvSH4B1zopT-I_gTWazteK1g-2G9m35t5s7sbFJAQkIsMxjGHSYwjitP22vKzgwNjMn02O5mdzV6ceH5myEcwoIZrvOZxEjOZL2iBryEBSi6CJJbRx7ub63MFGOPjWZGwHLALvMqjR2IONAMOzBidllFYMhmZHpUqzFYsX38cimAJ3PDshsqKhE0VCRQJIY3XqsDHu9v76aHXHnuz9kSBdRlrkhQZf85JIlJgZQ1zpuBvn_7-_izXFih-z0qt0RvPqPQSEcVZuYwHeTXTs_GkrGGuFnz5fkoYjyh4L4-LgHL01fR4pPmpddRuP60av7lmWKwhwjSEnSN5fM8ACnJsgoI2HS1PjmNvPHm4HkbOEZA0FVn8TkBzVE3B_VjeueaBRvzf3monQ0hxFoIhX5bhFVsQXvijjbBiK4YVPfysesxplPq8oqs46jHurMQ0WEi6_dpDbU9oihXp7T1kFKKY8UpWTrVREuMkWD788stdoA6P2sabAtAEa6B2rOlPjel1afu1BmT7Wva8-N76GWqhFGiK41CeZVWDj_gCUvCRKz9DuMQi4T7ys61MxYIT7yoLkMupgBaiREQL5F7ihMk_sQrrq6BKWeHsLSHpLkn-I3eDPiDXMu3O0B70TMccmKYz6FotdCVhp9ux7Z5pdYeO1e_1rd62hT4qCrPTty3Hdob2k95ALu23EIQxJ_R5cRepK2n7D1LIfM8 +[commentaire2]: # Cf. https://mermaid.live/view#pako:eNptVE1v00AQ_SvWSr0lkWOTOPEBKU2CFLWUgkuRkKVqY08dK7Y37EegRLlxqiqBygFuvSH4B1zopT-I_gTWazteK1g-2G9m35t5s7sbFJAQkIsMxjGHSYwjitP22vKzgwNjMn02O5mdzV6ceH5myEcwoIZrvOZxEjOZL2iBryEBSi6CJJbRx7ub63MFGOPjWZGwHLALvMqjR2IONAMOzBidllFYMhmZHpUqzFYsX38cimAJ3PDshsqKhE0VCRQJIY3XqsDHu9v76aHXHnuz9kSBdRlrkhQZf85JIlJgZQ1zpuBvn_7-_izXFih-z0qt0RvPqPQSEcVZuYwHeTXTs_GkrGGuFnz5fkoYjyh4L4-LgHL01fR4pPmpddRuP60av7lmWKwhwjSEnSN5fM8ACnJsgoI2HS1PjmNvPHm4HkbOEZA0FVn8TkBzVE3B_VjeueaBRvzf3monQ0hxFoIhX5bhFVsQXvijjbBiK4YVPfysesxplPq8oqs46jHurMQ0WEi6_dpDbU9oihXp7T1kFKKY8UpWTrVREuMkWD788stdoA6P2sabAtAEa6B2rOlPjel1afu1BmT7Wva8-N76GWqhFGiK41CeZVWDj_gCUvCRKz9DuMQi4T7ys61MxYIT7yoLkMupgBaiREQL5F7ihMk_sQrrq6BKWeHsLSHpLkn-I3eDPiDXMu3O0B70TMccmKYz6FotdCVhp9ux7Z5pdYeO1e_1rd62hT4qCrPTty3Hdob2k95ALu23EIQxJ_R5cRepK2n7D1LIfM8 -![Schéma du système de sauvegarde](./media/schema_velero.png){height=50%}\ +![Schéma du système de sauvegarde](./media/schema_velero.png){height=70%} + +\newpage ### Supervision -Le choix se porte sur Datadog pour sa souplesse et sa capacité à proposer des services supplémentaires de manière progressive. +Le choix se porte sur **Datadog** pour sa **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 montrer le schéma suivant. +Le fonctionnement semble simple : installation d'agents Datadog dans le +système Kubernetes pour receuillir de nombreuses informations. Comme peut le +montrer le schéma suivant. -[//]: # Cf. https://mermaid.live/view#pako:eNp1VEtu2zAQvQrBImgLKIYs-RctCji2ChhxHMNKUaDQhhZHjiCZNCiqbRL4DgV6gB6g-266C9D79Agl9ZeTaiPyzZsZzvcRB5wCdnAqiYR5RHaC7M8_Wz7z2dkZmrvvF6vF7eJm5fkMqY8SSSjfIQf9_fHtF5oX10IGcarw6Z48cIbcq1Ij4EwKnijJ6s_3jKKnn2hWQuuEMEBPvwviFy5iEG3exwLRhNJ7QLSHHTBZuUY0Q0GSpRJEyWEvcpg2WjDibAsJSMW6Kk5VaOndlhNBlWBenQvRnrNIcv22a32CTLxJ35YiEunYZjwTIoKkANOEBLFCPf03EMig1ySDRAxEP9dhEpgyhuhrcjgkUQ_1T2jWyzSroJFDpENdL5AH4rNOgCrZ7GZ5s6lyn5A0nUOINkBRGCWJ8yoMaUgHRqoKEIMjgJ4wL5MMSioZBCFsK-pWCU6464jFtVkYQFhxD0rQ4uZ123Rc5WW67JrM41nnqnkkG3c5bbVeVbbz83e5dlPuHAlI0yMlpQso603aNBB3ql-ptTu6Nt4Gq2bQgrL606W7uXW95_KqEUoCetYFnZe2yl7jxRhOVx5aumi2_ODdupuyyfTE5kP3WAANWM1cS1AG3gXqpOnveGqlHMgTI52s1YYY6QJNiP_ByxY-dn6F32rHtBzT7jy20lzrYwPvQaiCULXNclUfyzvYg48ddaQQkiyRPvbZUVFJJrl3zwLsSJGBgQXPdnfYCUmSqlt2oM02rCgHwj5xvq9J6o6dR_wVO5Zp9y7sydAcmxPTHE_6loHvFTzu92x7aFr9i7E1Go6s4dHAD7kJszeyrbE9vrAHw4lSHRkYqA7nutjG-VI-_gOoBrf7 -Choix de Datadog au détriment de Prometheus, faute de temps +[commentaire3]: # Cf. https://mermaid.live/view#pako:eNp1VEtu2zAQvQrBImgLKIYs-RctCji2ChhxHMNKUaDQhhZHjiCZNCiqbRL4DgV6gB6g-266C9D79Agl9ZeTaiPyzZsZzvcRB5wCdnAqiYR5RHaC7M8_Wz7z2dkZmrvvF6vF7eJm5fkMqY8SSSjfIQf9_fHtF5oX10IGcarw6Z48cIbcq1Ij4EwKnijJ6s_3jKKnn2hWQuuEMEBPvwviFy5iEG3exwLRhNJ7QLSHHTBZuUY0Q0GSpRJEyWEvcpg2WjDibAsJSMW6Kk5VaOndlhNBlWBenQvRnrNIcv22a32CTLxJ35YiEunYZjwTIoKkANOEBLFCPf03EMig1ySDRAxEP9dhEpgyhuhrcjgkUQ_1T2jWyzSroJFDpENdL5AH4rNOgCrZ7GZ5s6lyn5A0nUOINkBRGCWJ8yoMaUgHRqoKEIMjgJ4wL5MMSioZBCFsK-pWCU6464jFtVkYQFhxD0rQ4uZ123Rc5WW67JrM41nnqnkkG3c5bbVeVbbz83e5dlPuHAlI0yMlpQso603aNBB3ql-ptTu6Nt4Gq2bQgrL606W7uXW95_KqEUoCetYFnZe2yl7jxRhOVx5aumi2_ODdupuyyfTE5kP3WAANWM1cS1AG3gXqpOnveGqlHMgTI52s1YYY6QJNiP_ByxY-dn6F32rHtBzT7jy20lzrYwPvQaiCULXNclUfyzvYg48ddaQQkiyRPvbZUVFJJrl3zwLsSJGBgQXPdnfYCUmSqlt2oM02rCgHwj5xvq9J6o6dR_wVO5Zp9y7sydAcmxPTHE_6loHvFTzu92x7aFr9i7E1Go6s4dHAD7kJszeyrbE9vrAHw4lSHRkYqA7nutjG-VI-_gOoBrf7 -![Schéma des agents Datadog dans notre système Kubernetes](./media/schema_datadog.png){height=50%}\ +![Schéma des agents Datadog dans notre système +Kubernetes](./media/schema_datadog.png){height=70%} #### Surveillance (monitoring) -Pour le monitoring, on veillera à suivre des indicateurs simples comme l'utilisation CPU et la mémoire vive des instances AWS EC2 (Elastic Compute Cloud) utilisées. +Pour le monitoring, on veillera à suivre 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. +* le **nombre de pods utilisés** par l'instance EC2, +* et la **disponibilité du service** de l'application API-Utilisateurs. -Cependant ces moniteurs peuvent s'agrémenter d'alertes. +Cependant ces moniteurs doivent s'agrémenter d'**alertes**. #### Alertes -On veillera à utiliser **un canal Slack** (*#alertes*) pour avertir les DevOps d'une quelconque alerte levée. Datadog permet cela facilement comme énoncé dans l'introduction de ce chapitre sur la Supervision. +On va utiliser **un canal Slack** (*#alertes*) **pour avertir les DevOps** +d'une quelconque **alerte levée**. Datadog permet cela facilement comme énoncé +dans l'introduction de ce chapitre sur la Supervision. -Suite aux alertes, les DevOps peuvent opérer et notifier de la prise en charge d'un problème via le chatbot Gitlab intégré à ce canal Slack. Nous utilisons donc le [**Gitlab ChatOps**](https://docs.gitlab.com/ci/chatops/). +Suite aux alertes, les **DevOps peuvent opérer et notifier** de la prise en +charge d'un problème **via le chatbot Gitlab intégré** à ce canal Slack. Nous +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'API-Utilisateurs. +En suivant toutes ces indications, nous devrions avoir une base stable et +saine pour constuire une supervision correcte de l'application +API-Utilisateurs. ### Sécurité -Au niveau de la sécurité, vaste sujet, nous partirons de peu d'éléments : +Au niveau de la sécurité, **vaste sujet**, nous partirons de peu +d'éléments : -* lancement de tests sur le code applicatif, -* lancement de tests SAST (Static application security testing), sur Terraform notamment, -* et utilisation d'un coffre fort numérique pour les mots de passes et clés d'accès en tous genres. +* lancement de **tests** sur le **code applicatif**, +* lancement de **tests SAST** (Static application security testing), sur 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 dans les spécifications techniques. +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. diff --git a/content/40_demarche.md b/content/40_demarche.md index dc9b8f2..864f565 100644 --- a/content/40_demarche.md +++ b/content/40_demarche.md @@ -3,54 +3,69 @@ # Démarche suivie {#demarche} La réalisation de ce projet va plus loin que la simple mise en place d'une -application dans le Cloud. C'est une nouvelle équipe, dans un nouvel -environnement avec une application inconnue et des savoirs à acquérir. +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és pour -ce faire, puis des outils utilisés et enfin aborder le sujet de -collaborations avec d'autres équipes. +en place. Nous allons donc avant tout parler de **méthodologie utilisées** +pour ce faire, puis des **outils utilisés** et enfin aborder le sujet de +**collaborations** avec d'autres équipes. ## Méthodologie ### Agile -Le choix d'une méthodologie agile « basique » s'est offerte à nous, notamment par : +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 : +* 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 je compte faire aujourd'hui, -* la **création de jalons** avec un ensemble de tâches sur une période d'une semaine, -* des échanges réguliers en **pair-programming** sur des sujets difficiles **via [la plateforme Slack](slack.com)**, -* et l'utilisation d'un **tableau façon Kanban** (méthode de gestion de production en flux tendus). +* la **création de jalons** avec un ensemble de tâches sur une période d'une +semaine, +* des échanges réguliers en **pair-programming** sur des sujets difficiles +**via [la plateforme Slack](slack.com)**, +* 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. +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 dérive de l'objectif attendu. Voici les jalons qui ont été utilisés : +Les **jalons** (milestones en anglais) permettent de savoir si le projet +dérive de l'objectif attendu. Voici les jalons qui ont été utilisés : -* Étape 1 : préparation - outils (config. gitlab, projets, wiki, etc.), **cahier des charges** -* Étape 2 (avec 3) : **CI/CD** sur le projet principal -* Étape 3 (avec 2) : **Infrastructure** (Terraform) -* Étape 4 (avec 5) : Données (**postgreSQL**) -* Étape 5 (avec 4) : **Observabilité** -* Étape 6 : **extras** (s'il y a du temps restant) +* Étape 1 : **préparation** - outils (configuration de gitlab, des projets, du +wiki, etc.), **cahier des charges**, +* Étape 2 (avec 3) : **CI/CD** sur le projet principal, +* Étape 3 (avec 2) : **Infrastructure** (Terraform), +* Étape 4 (avec 5) : Données (**postgreSQL**), +* É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. +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 diviser le groupe : SemVer, Git OneFlow et Conventional commit. +Plusieurs standards/normes ont été choisies pour **rassembler plutôt que +diviser le groupe** : SemVer, Git OneFlow et Conventional commit. #### SemVer -[SemVer](https://semver.org/) ou **Semantic Versioning** est un standard visant à codifier la manière d'écrire le numéro de version d'une application et leur hiérarchisation (c'est à dire la façon dont on incrémente un numéro de version). +[SemVer](https://semver.org/) ou **Semantic Versioning** est un standard +visant à codifier la manière d'écrire le numéro de version d'une application +et leur hiérarchisation (c'est à dire la façon dont on incrémente un numéro de +version). -Respecter SemVer, c'est permettre d'utiliser des outils conçus pour cela mais aussi et surtout **faciliter la gestion des dépendances**. +Respecter SemVer, c'est permettre d'utiliser des outils conçus pour cela mais +aussi et surtout **faciliter la gestion des dépendances**. -Nous ne détaillerons pas l'ensemble du standard, mais voici quelques exemples de versions : +Nous ne détaillerons pas l'ensemble du standard, mais voici **quelques +exemples de versions** : ``` 1.0.0 @@ -60,24 +75,38 @@ Nous ne détaillerons pas l'ensemble du standard, mais voici quelques exemples d 1.5.2-rc.2 ``` -Cela fonctionne donc sous la forme `Majeur`.`Mineur`.`Correctif`. +Cela fonctionne donc sous la forme **Majeur**.*Mineur*.`Correctif`. #### Git OneFlow -[Git OneFlow](https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow) est un workflow Git conçu par Adam Ruka en alternative à [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/). +[**Git OneFlow**]( +https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow) est +un workflow Git conçu par Adam Ruka en alternative à [GitFlow]( +https://nvie.com/posts/a-successful-git-branching-model/). -Il se base principalement sur un objectif simple : avoir un arbre Git dont la **branche principale** est **la plus linéaire possible**. C'est à dire avec le moins d'embranchements possibles. +Il se base principalement sur un objectif simple : avoir un arbre Git +dont la **branche principale** est **la plus linéaire possible**. C'est à dire +avec le moins d'embranchements possibles. -En somme on va favoriser le **rebase** sur les branches dédiées à une nouvelle fonctionnalité AVANT de fusionner sur la branche principale. Cela aura l'avantage : +En somme on va favoriser le **rebase** sur les branches dédiées à une nouvelle +fonctionnalité **avant de fusionner sur la branche principale**. Cela aura +l'avantage : -* de réduire le travail de la personne qui fusionne la branche de fonctionnalités, -* et de favoriser la résolution des conflits de fusion aux développeurs responsables de la branche de fonctionnalités. +* de réduire le travail de la personne qui fusionne la branche de +fonctionnalités, +* et de favoriser la résolution des conflits de fusion aux développeurs +responsables de la branche de fonctionnalités. -![Avant/après la fusion d'une branche en utilisant Git OneFlow](./media/feature-branch-rebase-final.png){width=50%}\ +![Avant/après la fusion d'une branche en utilisant Git +OneFlow](./media/feature-branch-rebase-final.png){width=50%} + +\newpage #### Conventional commit -Dans le cadre de la rédaction de message de commit pour chaque changement effectué sur un dépôt, nous avons choisi de suivre la spécification [Commits Conventionnels](https://www.conventionalcommits.org/fr/v1.0.0/#r%C3%A9sum%C3%A9). +Dans le cadre de la **rédaction de message de commit** pour chaque changement +effectué sur un dépôt, nous avons choisi de suivre la **spécification [Commits +Conventionnels](https://www.conventionalcommits.org/fr/v1.0.0/#r%C3%A9sum%C3%A9)**. Cela se résume à peu près à cela : @@ -89,7 +118,7 @@ Cela se résume à peu près à cela : [pied optionnel] ``` -Qui donne par exemple : +Qui donne **par exemple** : ```markdown {.numberLines} feat(backend): include postgreSQL BDD + backend @@ -107,111 +136,180 @@ feat(backend): include postgreSQL BDD + backend ref projet#18 ``` +On notera aussi l'**usage des références Gitlab** en fin de message de commit +pour **faire un lien entre le commit et un ticket spécifique**, en l'occurence +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 des outils afférents. +Au delà d'une à plusieurs méthodologies/normes/standards, nous avons utilisés +des outils afférents. ### Nom de domaine -Afin d'avoir une **boîte courriel commune** (team@devu42.fr) et des **noms de domaine** qui pointent sur le résultat de nos travaux, nous avons opté pour la location d'un nom de domaine : **devu42.fr**. +Afin d'avoir une **boîte courriel commune** (team@devu42.fr) et des **noms de +domaine** qui pointent sur le résultat de nos travaux, nous avons opté pour la +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 ». +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 ». -Nous avons ainsi pu avoir des noms de domaines spécifiques pour : +Nous avons ainsi pu avoir des **noms de domaines spécifiques** pour : -* le backend (API) dans l'environnement de pré-production, -* le backend (API) dans l'environnement de production, -* le frontend dans l'environnement de pré-production, -* et le frontend dans l'environnement de production. +* le backend (API) dans l'environnement de pré-production, +**api.staging**.devu42.fr, +* le backend (API) dans l'environnement de production, **api.r53**.devu42.fr, +* le frontend dans l'environnement de pré-production, +**www.staging**.devu42.fr, +* et le frontend dans l'environnement de production, **www.r53**.devu42.fr. C'était donc un bon départ. ### Plateforme DevOps -Notre outils principal a été la **plateforme Gitlab**. C'est une plateforme complète de DevOps qui couvre bon nombre de besoins DevOps parmi : +Notre outil principal a été la **plateforme Gitlab**. C'est une plateforme +complète de DevOps qui couvre bon nombre de besoins DevOps parmi : -* des dépôts de code source (dépôts Git), -* un système d'intégration continu (GitlabCI), -* une gestion des rôles utilisateurs pour une granularité de gestion de permissions tout en finesse, -* des dépôts pour : - * les Chart Helm, - * les images Docker, - * les modules Terraform, - * les états Terraform, - * les librairies Python, PHP, JS, +* des dépôts de code source (**dépôts Git**), +* un système d'**intégration continue** (**GitlabCI**), +* une gestion des **rôles utilisateurs** pour une granularité de **gestion de +permissions** tout en finesse, +* des dépôts/**registres** pour : + * les **Chart Helm**, + * les **images Docker**, + * les **modules Terraform**, + * les **états Terraform**, + * les bibliothèques Python, PHP, JS, * etc., -* un système de gestion de tickets pour le retour régulier (feedback) des utilisateurs, -* l'usage de jalons, kanban et métriques des équipes pour une gestion efficace d'une à plusieurs équipe dans un projet, -* la gestion des versions (release), -* l'intégration avec Kubernetes pour un suivi depuis Gitlab de nos clusters Kubernetes, +* un **système de gestion de tickets** pour le retour régulier (feedback) des +utilisateurs, +* l'usage de **jalons**, **kanban** et **métriques des équipes** pour une +gestion efficace d'**une à plusieurs équipes** dans un projet, +* la gestion des versions (**releases**), +* l'**intégration avec Kubernetes** pour un suivi depuis Gitlab de nos +clusters Kubernetes, * etc. -De nombreuses fonctionnalités supplémentaires existent dans Gitlab. Cela en fait donc un outil de choix pour notre projet. +De nombreuses fonctionnalités supplémentaires existent dans Gitlab. Cela en +fait donc un outil de choix pour notre projet. + +\newpage #### Base de connaissance -Une des premières choses qui a été faite sur cette plateforme a été la **mise en place d'une base de connaissances** sous la forme d'un Wiki. +Une des premières choses qui a été faite sur cette plateforme a été la **mise +en place d'une base de connaissances** sous la forme d'un Wiki. Pour plusieurs raisons : -* partager nos découvertes sur les outils (liens web, procédures d'installation, etc.), -* détailler nos diverses installations, -* partager nos travaux, -* rédaction de contenu concernant les réunions, des outils, etc. +* **partager nos découvertes** sur les outils (liens web, procédures +d'installation, etc.), +* détailler nos diverses **installations**, +* **partager nos travaux**, +* rédaction de contenu concernant les **réunions**, des **outils**, etc. -![Impression écran de la page d'accueil du Wiki](./media/screenshot_wiki_projet.png){width=100%}\ +![Impression écran de la page d'accueil du +Wiki](./media/screenshot_wiki_projet.png){width=100%} + +\newpage #### Workflow des tickets -Autre exemple de configuration de la plateforme Gitlab afin de suivre notre organisation : la création d'un workflow de l'état d'un ticket, que vous trouverez ci-après. +Autre exemple de configuration de la plateforme Gitlab afin de suivre notre +organisation : la **création d'un workflow de l'état d'un ticket**, que +vous trouverez ci-après. -![Schéma du workflow de l'état des tickets](./media/schema_workflow_ticket.png){width=50%}\ +![Schéma du workflow de l'état des +tickets](./media/schema_workflow_ticket.png){height=70%} -Il permet à chaque membre de l'équipe de prendre connaissance des habitudes en matière de gestion de ticket. +Il permet à chaque membre de l'équipe de prendre connaissance des habitudes en +matière de gestion de ticket. -Il est utile si jamais nous changerions de plateforme DevOps : il suffirait d'appliquer à nouveau le même workflow. +Il est utile si jamais nous changions de plateforme DevOps : il suffirait +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é. +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é. -Nous avons échangé sur le sujet de la promotion des versions entre environnements. Maxime, de la Team Matrix, et moi avons principalement discuté autour de l'article suivant : [How to model your GitOps environments and promote releases between them](https://codefresh.io/blog/how-to-model-your-gitops-environments-and-promote-releases-between-them/). +Nous avons échangé sur le **sujet de la promotion des versions entre +environnements**. Maxime, de la Team Matrix, et moi avons principalement +discuté autour de l'article suivant : [How to model your GitOps +environments and promote releases between them]( +https://codefresh.io/blog/how-to-model-your-gitops-environments-and-promote-releases-between-them/) +( +https://codefresh.io/blog/how-to-model-your-gitops-environments-and-promote-releases-between-them/ +). -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 ajoute également de faire la promotion des versions entre ces différents environnements/dossiers. Avec une procédure « humaine » pour limiter de trop nombreuses promotions. +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. Pour reprendre le schéma de l'article : -![Schéma extrait de l'article sur la promotion des versions](./media/article_schema_promotion.png){width=100%}\ +![Schéma extrait de l'article sur la promotion des +versions](./media/article_schema_promotion.png){width=100%} -Après moultes discussions, nous sommes tombés d'accord sur quelques points, parmi : +Après moultes discussions, **nous sommes tombés d'accord** sur quelques +points, parmi : -* ne PAS utiliser une branche par environnement, -* essayer au maximum d'avoir des dépôts indépendants (favoriser la modularité), -* faire de la promotion logicielle par la CI plutôt que manuellement, -* et utiliser les particularités des outils que nous avons (Terragrunt dans le cas de Maxime). +* **ne pas utiliser une branche par environnement**, +* essayer au maximum d'**avoir des dépôts indépendants** (favoriser la +modularité), +* favoriser la **promotion logicielle par la CI** plutôt que manuellement, +* et **utiliser les particularités des outils que nous avons** (Terragrunt +dans le cas de Maxime). -Notre réflexion a evolué suite à ces échanges. Et nous avons opté initialement pour utiliser un dossier par environnement dans un dépôt unique nommé **infra**. Puis nous avons adapté notre intégration continue pour copier les valeurs communes de l'environnement de pré-production (staging) vers l'environnement de production (prod). +Notre réflexion a **evolué suite à ces échanges**. Et nous avons opté +initialement pour utiliser **un dossier par environnement dans un dépôt +unique** nommé **infra**. Puis nous avons adapté notre intégration continue +pour copier les valeurs communes de l'environnement de pré-production +(staging) vers l'environnement de production (prod). -Mon idéal serait : +**Mon idéal** serait : -* avoir des dépôts indépendants pour chaque application avec des tests 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 »), -* avoir la même chose pour chaque module Terraform que nous avons fabriqué (par exemple notre module « networking »), -* puis utiliser, dans un dépôt **infra** par exemple, nos modules situés sur des registres avec une version donnée, +* avoir des **dépôts indépendants pour chaque application** avec des **tests +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 »), +* avoir la **même chose pour chaque module Terraform** que nous avons fabriqué +(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 : - * soit de la promotion des versions par une intégration continue entre dépôts (pré-production vers production par exemple) OU entre dossiers représentant un environnement, - * soit de la promotion des versions par une validation manuelle entre la pré-production et la production, -* ajouter des tests de sécurité des images (comme le contrôle de somme) avant utilisation dans d'autres dépôts. + * soit de la promotion des versions par une intégration continue entre + dépôts (pré-production vers production par exemple) OU entre dossiers + représentant un environnement, + * soit de la promotion des versions par une validation manuelle entre la + pré-production et la production, +* 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 : +À 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 : * la promotion des versions des logiciels/modules/charts utilisés, -* et la promotion des configurations de ces derniers au sein de nos infrastructures. +* et la promotion des configurations de ces derniers au sein de nos +infrastructures. C'est un autre sujet très intéressant que nous ne détaillerons pas ici. ## Conclusion -La démarche entreprise a été structurée autour de méthodologies et d'outils et nous a permis de faire avancer le projet. L'apport des discussions autour de la promotion logiciel avec une autre équipe a eu un impact conséquent sur nos choix concernant l'automatisation et le déploiement continu sur l'environnement de pré-production. Nous en parlerons d'ailleurs dans le prochain chapitre un peu plus en détail. +La **démarche entreprise** a été structurée autour de **méthodologies** et +d'**outils** et nous a permis de faire avancer le projet. L'apport des +**discussions autour de la promotion logicielle** avec une autre équipe a eu +un impact conséquent sur nos choix concernant l'automatisation et le +déploiement continu sur l'environnement de pré-production. Nous en parlerons +d'ailleurs dans le prochain chapitre un peu plus en détail. -Cependant la gestion d'équipe lors de ce projet a fait défaut et nous aurions pu nous organiser bien mieux qu'il n'a été. +A contrario, la **gestion d'équipe** lors de ce projet **a fait défaut** et +nous aurions pu nous organiser bien mieux qu'il n'a été. diff --git a/content/50_realisations.md b/content/50_realisations.md index 6b3ef3f..1625607 100644 --- a/content/50_realisations.md +++ b/content/50_realisations.md @@ -2,66 +2,103 @@ # Mes réalisations -Ce projet m'a amené à participer sur de nombreux sujets. En voici deux qui, je l'espère, illustreront bien ce que j'ai rencontré. +Ce projet m'a amené à participer sur de nombreux sujets. En voici deux qui, je +l'espère, illustreront bien ce que j'ai rencontré. -Je parlerais de livraison continue (CI/cd) et d'états Terraform. +Je parlerais de **livraison continue** (CI/cd) et d'**états Terraform**. ## Réalisation 1 : Livraison continue ### Contexte -Durant le court laps de temps accordé au projet, nous arrivions à la fin, nous étions en manque de ressources humaines : +Durant le court laps de temps accordé au projet, nous arrivions à la fin, nous +étions en manque de ressources humaines : -* le travail de l'équipe n'était pas toujours qualitatif, -* parfois cela ne répondait pas au besoin énoncé, -* d'autres fois une ressource prenait plus de temps que prévu sur sa tâche. +* le travail de l'équipe n'était **pas toujours qualitatif**, +* parfois cela **ne répondait pas au besoin énoncé**, +* d'autres fois **une ressource prenait plus de temps que prévu** sur sa tâche. -Il en résulta peu de moyens pour répondre à tous les besoins du projet. Cela raccourcissait le temps des tâches restantes. +Il en résulta **peu de moyens pour répondre à tous les besoins** du projet. +Cela raccourcissait le temps des tâches restantes. -En pareille situation il a fallu faire avec l'existant afin de créér une chaîne de publication logicielle. J'ai pris en charge cette tâche. +En pareille situation il a fallu **faire avec l'existant** afin de créér une +chaîne de publication logicielle. J'ai pris en charge cette tâche. ### Analyse À ce moment du projet nous n'avions que peu d'éléments : * un dépôt applicatif (nommé **upstream**), -* un dépôt contenant les charts Helm qui utilisent les images publiées du dépôt applicatif (nommé **charts**), +* un dépôt contenant les charts Helm qui utilisent les images publiées du +dépôt applicatif (nommé **charts**), * et un dépôt contenant l'infrastructure de production (nommé **infra**). -Chaque dépôt peut utiliser l'intégration continue de Gitlab, appelée Gitlab CI et utilisant des pipelines. +Chaque dépôt peut utiliser l'intégration continue de Gitlab, appelée Gitlab CI +et utilisant des pipelines. -On souhaite créer une chaîne d'intégration continue (CI, Continuous Integration) pour passer d'un dépôt à l'autre suivant une chaîne, comme le montre le schéma suivant : +\newpage -![Schéma de la chaîne des dépôts](./media/schema_chaine_depots.png){height=50%}\ +On souhaite **créer une chaîne d'intégration continue** (CI, Continuous +Integration) pour passer d'un dépôt à l'autre suivant **une chaîne**, comme le +montre le schéma suivant : -Cela fait penser au chapitre précédent où nous parlions du [sujet de la promotion logicielle](#collab). Suivant quelle(s) règle(s) pouvons-nous passer d'un dépôt à l'autre, d'une version à l'autre ou (in)valider le fonctionnement ? +![Schéma de la chaîne des dépôts](./media/schema_chaine_depots.png){height=40%} -Après plusieurs heures de réflexions, de dessins en tous genres et de recul, j'ai constaté que : +Cela fait penser au chapitre précédent où nous parlions du [sujet de la +promotion logicielle](#collab). Suivant **quelle(s) règle(s)** pouvons-nous +**passer d'un dépôt à l'autre**, d'une version à l'autre ou (in)valider le +fonctionnement ? -* quoiqu'il arrive la pipeline va lancer des tests sur le code, -* et dans la situation où on pose une étiquette (appelé tag sur un dépôt Git), c'est qu'on souhaite valider - indirectement - le travail effectué. +Après plusieurs heures de réflexions, de dessins en tous genres et du recul, +j'ai constaté que : -Ainsi dans la situation où une étiquette apparaît, la pipeline diffère légèrement. Il y a donc globalement 2 règles à suivre, représentées par le schéma suivant : +* quoiqu'il arrive la **pipeline va lancer des tests** sur le code, +* et dans la **situation où l'on pose une étiquette** (appelé **tag** sur un +dépôt Git), c'est qu'on souhaite valider - indirectement - le travail effectué. -![Schéma des 2 règles principales pour la CI d'un dépôt](./media/schema_regles_ci.png){height=50%}\ +\newpage -Comme le résultat positif des tests engendre la compilation puis la publication d'une image sur un registre, une idée apparaît donc : informer les autres dépôts que l'image est disponible ! +Ainsi dans la situation où une étiquette apparaît, la pipeline diffère +légèrement. Il y a donc globalement **2 règles à suivre**, représentées par le +schéma suivant : + +![Schéma des 2 règles principales pour la CI d'un dépôt](./media/schema_regles_ci.png){height=50%} + +Comme le résultat positif des tests engendre la compilation puis la +publication d'une image sur un registre, une idée apparaît donc : +**informer les autres dépôts que l'image est disponible** ! ### Solution -Suivant l'idée précédente qui consiste à informer les autres dépôts de la publication récente d'une version, il a fallu trouver une solution. +Suivant l'idée précédente qui consiste à informer les autres dépôts de la +publication récente d'une version, il a fallu trouver une solution. -Nous sommes sur Gitlab, avons des dépôts Git, et des pipelines qui se lancent quand un commit est effectué. Dans la situation où une étiquette est posée, pourquoi ne pas utiliser Git lui-même sur le dépôt suivant ? Ainsi, sans outils supplémentaires, nous pouvons lier les dépôts entre eux. +Nous sommes sur Gitlab, avons des dépôts Git, et des pipelines qui se lancent +quand un commit est effectué. Dans la situation où une étiquette est posée, +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 suivant représentant la pipeline de chaque dépôt : +```{=latex} +\begin{sidewaysfigure} -![Schéma des 3 pipelines](./media/schema_3_pipelines.png){width=100%}\ +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} +``` + +\newpage Ce qui donne le savant mélange suivant : -![Schéma de toutes les pipelines imbriquées](./media/schema_toutes_pipelines.png){height=100%}\ +![Schéma de toutes les pipelines imbriquées](./media/schema_toutes_pipelines.png){height=73%} -Exemple de code permettant d'informer le dépôt **charts** qu'une nouvelle étiquette a été posée sur le dépôt **upstream** une fois le backend et le frontend publiés sur le registre Docker de Gitlab : +\newpage + +Ainsi nous avons, par exemple, le code suivant permettant d'informer le dépôt **charts** qu'une nouvelle étiquette a été posée sur le dépôt **upstream** une fois le backend et le frontend publiés sur le registre Docker de Gitlab : ```bash {.numberLines} inform-charts: @@ -71,120 +108,177 @@ inform-charts: FRONTEND_CHARTFILE_PATH: charts/frontend/Chart.yaml script: - | - if ! [ -z "$CI_COMMIT_TAG" ]; then + if ! [ -z "$COMMIT_TAG" ]; then # Configure git user git config --global user.email "git@dossmann.net" git config --global user.name "CI Pipeline" # Get CHARTS repository - git clone https://blankoworld:${CHARTS_ACCESS_TOKEN}@${CHARTS_REPOSITORY} + git clone https://blankoworld:${ACCESS_TOKEN}@${CHARTS_REPOSITORY} cd charts # Update files - sed -i "s/^version: \".*\"/version: \"${CI_COMMIT_TAG}\"/" "${BACKEND_CHARTFILE_PATH}" - sed -i "s/^appVersion: \".*\"/appVersion: \"${CI_COMMIT_TAG}-backend\"/" "${BACKEND_CHARTFILE_PATH}" - sed -i "s/^version: \".*\"/version: \"${CI_COMMIT_TAG}\"/" "${FRONTEND_CHARTFILE_PATH}" - sed -i "s/^appVersion: \".*\"/appVersion: \"${CI_COMMIT_TAG}-frontend\"/" "${FRONTEND_CHARTFILE_PATH}" + sed -i "s/^version: \".*\"/version: \"${COMMIT_TAG}\"/" \ + "${BACKEND_CHARTFILE_PATH}" + sed -i "s/^appVersion: \".*\"/appVersion:\"${COMMIT_TAG}-back\"/" \ + "${BACKEND_CHARTFILE_PATH}" + sed -i "s/^version: \".*\"/version: \"${COMMIT_TAG}\"/" + "${FRONTEND_CHARTFILE_PATH}" + sed -i "s/^appVersion: \".*\"/appVersion:\"${COMMIT_TAG}-front\"/" \ + "${FRONTEND_CHARTFILE_PATH}" # Add them to git staged area git add "${BACKEND_CHARTFILE_PATH}" "${FRONTEND_CHARTFILE_PATH}" # Commit and push result (to launch CHARTS CI for new code) - git commit -m "chore(release): Update backend/frontend image version" - git tag $CI_COMMIT_TAG + git commit -m "chore(release): Update back/front image version" + git tag $COMMIT_TAG git push origin main --tags fi needs: [push-backend,push-frontend] ``` -La ligne 23 à 25 posent un tag sur le dépôt **charts** en mettant simplement à jour les versions utilisées pour les charts Helm. +**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 +simplement à jour les versions utilisées du backend et du frontend dans les +charts Helm sur le registre Gitlab. ### Résultats -Après plusieurs points de détails, nous avons pu automatiser correctement la chaîne de production logicielle de la phase de développement jusqu'à la production en passant par une validation manuelle après déploiement en environnement de pré-production via l'intégration continue de Gitlab (Gitlab CI). +Après plusieurs points de détails corrigés, nous avons pu **automatiser +correctement la chaîne de production logicielle** de la **phase de +développement** jusqu'à **la production** en passant **par une validation +manuelle** après déploiement en environnement de pré-production **via +l'intégration continue de Gitlab** (Gitlab CI). -Ceci nous a permis de facilement travailler sur 2 environnements distincts : +Ceci nous a permis de facilement **travailler sur 2 environnements** +distincts : -* l'environnement de pré-production, -* et l'environnement de production. +* l'environnement de **pré-production**, +* et l'environnement de **production**. ### Limites Cette technique, bien qu'efficace, a ses limites : -* pour fonctionner sans développer plus, il a fallu utiliser le même numéro de version sur tous les dépôts : on ne fait que passer le tag courant au dépôt suivant. Que faire si les numéros de version dérivent ?, -* plus on ajoute de dépôts dans la chaîne, plus il y aura de code à faire et plus il y aura de complexiter à chaîner les dépôts. +* pour fonctionner sans développer plus, il a fallu **utiliser le même numéro +de version sur tous les dépôts** : on ne fait que passer le tag courant +au dépôt suivant. **Que faire si les numéros de version dérivent ?**, +* plus on ajoute de dépôts dans la chaîne, plus il y aura de code à faire et +plus il y aura de **complexité à chaîner les dépôts**. -Trouver une solution temporaire et efficace est - potentiellement - facile. Mais avoir une solution pérenne demande de l'expérience et plus de temps. +Trouver une solution temporaire et efficace est - potentiellement - facile. +Mais avoir **une solution pérenne demande de l'expérience et plus de temps**. ### Amélioration(s) possibles(s) -Cette expérience a été enrichissante. Bien que ce système ait répondu à nos besoins du moment, je pense qu'il serait envisageable de procéder autrement. +Cette expérience a été enrichissante. Bien que ce système ait répondu à nos +besoins du moment, je pense qu'il serait envisageable de procéder autrement. -Dans un premier temps, **utiliser des dépôts indépendants** avec leur propre pipeline qui **teste** puis **publie** sur des **dépôts utilisables** par d'autres projets. Puis chaque dépôt pourrait avoir un script de montée de version pour définir les contraintes spécifiques au projet, au dernier numéro de version, etc. +Dans un premier temps, **utiliser des dépôts indépendants** avec leur propre +pipeline qui **teste** puis **publie** sur des **dépôts utilisables** par +d'autres projets. Puis **chaque dépôt pourrait avoir un script de montée de +version** pour définir les contraintes spécifiques au projet, au dernier +numéro de version, etc. -Ainsi un dépôt d'infrastructure, par exemple, pourrait utiliser des versions spécifiques de chacun de ses dépôts indépendants. Et ce serait à lui d'aller regarder quelle est la dernière version d'un module ou d'une application. Et d'agir en conséquence : lancer une batterie de tests puis intégrer la nouvelle version disponible. +Ainsi un dépôt d'infrastructure, par exemple, pourrait utiliser des versions +spécifiques de chacun de ses dépôts indépendants. Et ce serait à lui d'aller +regarder quelle est la dernière version d'un module ou d'une application. Et +d'agir en conséquence : lancer une batterie de tests puis intégrer la +nouvelle version disponible. -Ceci éviterait d'ajouter une quantité astronomique de code Gitlab dans le dépôt initial (celui de l'application par exemple). Et cela laisse la responsabilité à ceux qui ont besoin du dépôt initial plutôt qu'à la/les personne(s) qui s'occupent du dépôt initial. +Ceci éviterait d'ajouter une quantité astronomique de code Gitlab dans le +dépôt initial (celui de l'application par exemple). Et cela **laisse la +responsabilité aux personnes suivantes** (qui utilisent le dépôt initial) plutôt +qu'aux personnes qui s'occupent du code dans le dépôt initial. + +\newpage ## Réalisation 2 : États Terraform ### Contexte -Pendant la création du dépôt **infra** contenant - entre autre - l'infrastructure de notre environnement de production, nous avons subis quelques pertes des états Terraform posés sur le registre Gitlab. +Pendant la création du dépôt **infra** contenant - entre autre - +l'infrastructure de notre environnement de production, **nous avons subis +quelques pertes des états Terraform** posés sur le registre Gitlab. -Non seulement les états Terraform étaient continuellement cassés par les collaborateurs, mais l'ignorance de ces derniers sur le fonctionnement de Terraform nous a mis une belle épine dans le pied. +Non seulement **les états Terraform étaient continuellement cassés** par les +collaborateurs, mais l'ignorance de ces derniers sur le fonctionnement de +Terraform nous a mis **une belle épine dans le pied**. -Il a fallu agir. Sur mon temps libre - au grand dam de ma famille - j'ai décidé d'y regarder de plus près. +Il a fallu agir. Sur mon temps libre - au grand dam de ma famille - j'ai +décidé d'y regarder de plus près. ### Analyse -Comme nous avons plusieurs environnements, l'état Terraform va décrire chaque fois un environnement. Nous aurons besoin au minimum des états Terraform suivants : +Comme nous avons plusieurs environnements, l'état Terraform va décrire chaque +fois un environnement. Nous aurons besoin au minimum des états Terraform +suivants : * un état **gitlab-ci** pour les pipelines de test, * un état **staging** pour l'environnement de pré-production, * un état **prod** pour l'environnement de production, -* et éventuellement un état Terraform par développeur. +* et éventuellement **un état Terraform par développeur**. -C'est ce dernier point que je cherchais à résoudre : **faciliter le travail du développeur** sur Terraform **pour éviter toute bévue**. +C'est ce dernier point que je cherchais à résoudre : **faciliter le +travail du développeur** sur Terraform **pour éviter toute bévue**. Nous constatons également : -* le manque de documentation par le développeur pour savoir comment procéder pour travailler sur Terraform, -* que trop d'erreurs manuelles sont effectués lors de l'utilisation des commandes Terraform. +* le **manque de documentation** par le développeur pour savoir comment +procéder pour travailler sur Terraform, +* que **trop d'erreurs manuelles** sont effectués lors de l'utilisation des +commandes Terraform. -C'est ce qui nécessite une simplification et/ou un changement. +C'est ce qui **nécessite une simplification** et/ou un changement. ### Solution -Dans le Logiciel Libre, dans la plupart des dépôts, nous retrouvons un fichier **Makefile** qui décrit les différentes étapes de compilation d'une application, de son installation ou de la création d'une image. +Dans le Logiciel Libre, dans la plupart des dépôts, nous retrouvons un fichier +**Makefile** qui décrit les différentes étapes de compilation d'une +application, de son installation ou de la création d'une image. -Pourquoi ne pas partir sur cette solution habituelle et l'adapter à notre cas ? +Pourquoi ne pas partir sur cette solution habituelle et l'adapter à notre +cas ? -Ainsi l'idée serait de reprendre les commandes habituelles de Terraform, à savoir : +Ainsi l'idée serait de **reprendre les commandes habituelles de Terraform**, à +savoir : -* init, -* plan, -* apply, -* destroy, -* fmt, -* et graph. +* **init**, +* **plan**, +* **apply**, +* **destroy**, +* **fmt**, +* et **graph**. -J'ai imaginé mettre à disposition les mots-clés suivants avec le fichier **Makefile** : +J'ai imaginé mettre à disposition les mots-clés suivants avec le fichier +**Makefile** : -* make init - pour initialiser l'état Terraform, -* make plan - pour vérifier les changements attendus entre l'état Terraform local et l'environnement distant, -* make apply - pour appliquer les changements, -* make destroy - pour supprimer l'ensemble des ressources distantes, -* make format - pour formater le contenu des fichiers *.tf trouvés, -* make graph - pour générer une image vectorielle des dépendances entre ressources du projet, -* et make clean - pour nettoyer les fichiers Terraform non nécessaires. +* **make init** - pour **initialiser l'état Terraform**, +* **make plan** - pour **vérifier les changements attendus** entre l'état Terraform local et l'environnement distant, +* **make apply** - pour **appliquer les changements**, +* **make destroy** - pour **supprimer l'ensemble des ressources distantes**, +* **make format** - pour **formater le contenu des fichiers \*.tf** trouvés, +* **make graph** - pour **générer une image vectorielle des dépendances entre +ressources** du projet, +* et **make clean** - pour **nettoyer les fichiers Terraform** non nécessaires. -Ces commandes ne résolvent pas le problème en tant que tel. C'est ce qui est derrière qui va résoudre le souci : des scripts qui vérifient que tout soit OK avant d'appliquer les commandes. +**Ces commandes ne résolvent pas le problème en tant que tel**. C'est ce qui +est derrière qui va résoudre le souci : **des scripts qui vérifient que +tout soit OK** avant d'appliquer les commandes. -Ainsi l'utilisation d'un fichier **.env**, non disponible dans le dépôt de code, permet de charger les informations utiles au choix d'un état Terraform et de l'environnement distant à atteindre pour travailler. +Ainsi l'**utilisation d'un fichier .env**, non disponible dans le dépôt de +code, permet de charger les informations utiles au choix d'un état Terraform +et de l'environnement distant à atteindre pour travailler. -La solution réside dans le fait que des scripts soient lancés sous chacune des commandes make et qu'ils vérifient l'existence et le contenu du fichier **.env**. +La solution réside dans le fait que des scripts soient lancés sous chacune des +commandes make et qu'ils vérifient l'existence et le contenu du fichier +**.env**. S'ajoute à cela une **documentation dans le fichier README.md**. -Exemple de script avec **make init** pour bien comprendre de quoi il est question : +\newpage + +Exemple de script avec **make init** pour bien comprendre de quoi il est +question : ```bash {.numberLines} #!/usr/bin/env bash @@ -213,7 +307,8 @@ terraform init \ -backend-config=${BACKEND_HTTP_FILE} $@ ``` -Et le contenu du fichier **env.example**, partagé aux développeurs comme d'un template pour fabriquer le fichier **.env** : +Et le contenu du fichier **env.example**, partagé aux développeurs comme d'un +template pour fabriquer le fichier **.env** : ```bash # TOKEN DOIT avoir permissions read/write @@ -230,35 +325,57 @@ export AWS_ACCESS_KEY_ID="AWS-access-key-id" export AWS_SECRET_ACCESS_KEY="secret-AWS-access-key" ``` -Pour faciliter la création de nouveaux dépôts utilisant Terraform, j'ai choisi de mettre en place un [dépôt dit **template** sur Gitlab](https://gitlab.com/devu42/templates/terraform). +Pour faciliter la création de nouveaux dépôts utilisant Terraform, j'ai choisi +d'inclure ce travail dans un [dépôt dit **template** sur +Gitlab](https://gitlab.com/devu42/templates/terraform). ### Résultats -À l'usage le travail sur Terraform s'est amélioré. En procédant ainsi, toute erreur se produisant sur Terraform n'affectait pas les autres collaborateurs. Chacun avait son état Terraform. +**À l'usage le travail sur Terraform s'est amélioré**. En procédant ainsi, +toute erreur se produisant sur Terraform n'affectait pas les autres +collaborateurs. **Chacun avait son état Terraform**. -La documentation a permis aux développeurs de comprendre facilement quoi changer pour travailler. Et ils se sont sentis moins perdus. +La **documentation a permis** aux développeurs **de comprendre facilement** +quoi changer pour travailler. Et ils se sont sentis moins perdus. ### Limites Toutefois, procéder ainsi a quelques limites : -* toute modification sur les éléments du Makefile, les scripts, la documentation, etc. doit être fait sur CHAQUE dépôt. Ainsi plus on a de dépôt, plus on consomme de temps à mettre à jour (avec des oublis possibles), -* si le template évolue, les dépôts ayant utilisé le template n'ont plus les mises à jour. On pourrait imaginer faire un **git rebase**, mais cela casserait l'historique des dépôts ou bien demanderait d'effectuer du travail sur une branche Git à part. +* **toute modification** sur les éléments du Makefile, les scripts, la +documentation, etc. **doit être faite sur CHAQUE dépôt**. Ainsi plus on a de +dépôt, plus on consomme de temps à mettre à jour (avec des oublis possibles), +* **si le template évolue**, les dépôts ayant utilisé le template **n'ont plus +les mises à jour**. On pourrait imaginer faire un **git rebase, mais cela +casserait l'historique des dépôts** ou bien demanderait d'effectuer du travail +sur une branche Git à part. -C'est très limitant. +**C'est très limitant**. ### Amélioration(s) possibles(s) -Cette solution a fait ses preuves. Elle a été utile au moment où nous en avions grandement besoin. Elle permet de prendre de l'expérience à ce sujet. +**Cette solution** a fait ses preuves. Elle **a été utile au moment où nous en +avions grandement besoin**. Elle permet de prendre de l'expérience à ce sujet. Nous pourrions imaginer améliorer cela avec : -* une forme de dépendance du fichier Makefile et des scripts avec le dépôt **template** utilisé (par exemple via une commande de mise à jour fournie), -* avoir une possibilité de choisir entre la commande Terraform et OpenTofu par l'utilisation d'une variable d'environnement, -* et permettre l'ajout d'arguments aux commandes **make apply**, voire ajouter une commande **make apply-autoapprove**. +* **une forme de dépendance du fichier Makefile** et des scripts avec le dépôt +**template** utilisé (par exemple via une commande de mise à jour fournie), +* avoir une possibilité de **choisir entre la commande Terraform et OpenTofu** +par l'utilisation d'une variable d'environnement, +* et **permettre l'ajout d'arguments** aux commandes **make apply**, voire +ajouter une commande **make apply-autoapprove**. -Il est aussi possible qu'il existe une commande de type **wrapper** (qui utilise Terraform et ses options) pour en faciliter l'usage, tel que **kubectx** pour Kubernetes. +Il est aussi possible qu'il existe une commande de type **wrapper** (qui +utilise Terraform et ses options) pour en faciliter l'usage, tel que +**kubectx** pour Kubernetes. ## Conclusion -Deux expérience 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. Ces sujets amènent également à prendre des initiatives et tester localement des outils choisis. 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 processus de travail dans son ensemble. +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étail 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 db0c51a..0a44e00 100644 --- a/content/60_situation_de_travail.md +++ b/content/60_situation_de_travail.md @@ -2,27 +2,42 @@ # 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 ». +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** ». -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 des lieux puis suivre le cheminement parcouru pour atteindre l'objectif. +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 +des lieux puis suivre le cheminement parcouru pour atteindre l'objectif. ## Contexte -Du projet émane un besoin d'avoir du temps de calcul pour les pipelines. +Du projet émane un besoin d'**avoir du temps de calcul pour les pipelines**. -Il est nécessaire de réfléchir et trouver une solution viable pour l'environnement de test. L'objectif est donc de préparer un environnement de test pour l'ensemble des éléments du projet. Nous utilisons Gitlab, ce sont donc des Gitlab Runner que nous visons. +Il est nécessaire de réfléchir et trouver une solution viable pour +l'environnement de test. L'**objectif** est donc de **préparer un +environnement de test** pour l'ensemble des éléments du projet. **Nous +utilisons Gitlab**, ce sont donc des Gitlab Runner que nous visons. -Où les installer ? Comment ? De quelles ressources disposons-nous ? +Où les installer ? Comment ? **De quelles ressources +disposons-nous ?** ## État des lieux -Nous utilisons Gitlab qui propose, dans sa version gratuite, un limite de temps de calcul. Une fois le seuil atteint : il faut trouver une solution alternative aux machines de Gitlab. Payantes. +**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**. -Autre environnement disponible : AWS. Mais avec un budget limité qui mangerait dans le budget alloué à nos 2 environnements : la production et la pré-production. +Autre **environnement disponible : AWS**. Mais avec un **budget limité** +qui mangerait dans le budget alloué à nos 2 environnements : la +production et la pré-production. -Il n'y a pas le choix : il faut envisager autre chose. Avec les ressources à disposition du groupe, autrement dit : avec le matériel de chacun. +Il n'y a pas le choix : **il faut envisager autre chose**. Avec les +ressources à disposition du groupe, autrement dit : **avec le matériel de +chacun**. -L'idée ? Utiliser une machine disponible, y installer un serveur et un environnement Kubernetes pour déployer des Gitlab Runner. +L'idée ? **Utiliser une machine disponible**, y **installer un serveur** +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. @@ -30,80 +45,136 @@ Après en avoir discuté en groupe, je me suis attelé à la tâche. Régulière ### Retranscription préalable -Étant donné que j'allais passer du temps à faire des recherches, il fallait un lieu où synthétiser les résultats. J'ai opté pour l'utilisation d'un site **gitlab.io** généré automatiquement par les pipelines de Gitlab en utilisant comme moteur statique un outil nommé **Hugo**. Le résultat est disponible sur [odtre.gitlab.io](https://odtre.gitlab.io/) afin qu'il puisse être consulté par mes collaborateurs. +Étant donné que j'allais passer du temps à faire des recherches, il fallait +**un lieu où synthétiser les résultats**. J'ai opté pour l'**utilisation d'un +site** *.gitlab.io* **généré automatiquement par les pipelines de Gitlab** en +utilisant comme **moteur statique** un outil nommé **Hugo**. Le résultat est +**disponible sur [odtre.gitlab.io](https://odtre.gitlab.io/)** afin qu'il +puisse **être consulté par mes collaborateurs**. -Ce site va contenir principalement 2 choses : +Ce site va contenir principalement **2 sections** : -* posts : les réflexions sur différents sujets/thèmes de l'environnement de test, -* doc : de la documentation sur l'installation effectuée des outils en place. +* **posts** : les **réflexions sur différents sujets/thèmes** de +l'environnement de test, +* **doc** : de la **documentation sur l'installation** effectuée **des +outils en place**. -Maintenant qu'un système de retranscription est en place, la recherche commence ! +Maintenant qu'un **système de retranscription** est en place, **la recherche +commence !** ### Méthode de renseignement Je procède souvent de la même manière : -* contact avec des **personnes de mon entourage déjà dans le métier** et pouvant m'indiquer des pistes à suivre, +* contact avec des **personnes de mon entourage déjà dans le métier** et +pouvant m'indiquer des pistes à suivre, * recherche de **livres existants** sur le sujet, * passage à la **médiathèque**, -* recherches sur **Internet d'articles** sur le sujet (support textuel uniquement). +* recherches sur **Internet d'articles** sur le sujet (support textuel +uniquement). 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 \textsc{O'Reilly}, -* recherche, infructueuse, à la médiathèque : le rayon informatique est maigre, -* recherche sur le domaine du DevOps 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). +* **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 +\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). -![Première de couverture du livre O'Reilly, Kubernetes - Guide pratique](./media/livre-oreilly.jpg){height=35%}\ +![Première de couverture du livre O'Reilly, Kubernetes - Guide +pratique](./media/livre-oreilly.jpg){height=35%} + +\newpage ### 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 **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 : +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 +**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 : -* le sujet de la virtualisation, -* le GitOps avec un outil tel que FluxCD. +* le **sujet de la virtualisation**, +* **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%}\ +![Apparence de la page d'accueil du blog de Stéphane +Robert](./media/screenshot_stephane-robert.png){width=100%} ### Recherches #### Sujet de la virtualisation -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 : +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 » : https://wiki.archlinux.org/title/Category:Virtualization, -* Le blog précédemment cité de [Stéphane Robert](#stephane-robert). +* 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). -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 appliqué : +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 +appliqué : -* La page Wiki d'ArchLinux sur QEMU, Cf. https://wiki.archlinux.org/title/QEMU, -* La page Wiki d'ArchLinux sur libvirt, Cf. https://wiki.archlinux.org/title/Libvirt, -* et un message de forum (forums.debian.net) concernant les bonnes pratiques sur l'usage de virt-manager, Cf. https://forums.debian.net/viewtopic.php?t=158967. +* La **page Wiki d'ArchLinux sur QEMU**, Cf. +https://wiki.archlinux.org/title/QEMU, +* La **page Wiki d'ArchLinux sur libvirt**, Cf. +https://wiki.archlinux.org/title/Libvirt, +* et un **message de forum** (forums.debian.net) concernant **les bonnes +pratiques sur l'usage de virt-manager**, Cf. +https://forums.debian.net/viewtopic.php?t=158967. -**J'ai ainsi rédigé 2 articles sur le sujet de la virtualisation**, disponibles sur odtre.gitlab.io (outil de retranscription) : +**J'ai ainsi rédigé 2 articles sur le sujet de la virtualisation**, +disponibles sur odtre.gitlab.io (outil de retranscription) : -* réflexion sur le sujet de la virtualisation, Cf. https://odtre.gitlab.io/post/002-virtualisation/, -* et exemple de virtualisation avec QEMU/KVM/Libvirt sous Linux, Cf. https://odtre.gitlab.io/doc/virtualisation/. +* **réflexion sur le sujet de la virtualisation**, Cf. +https://odtre.gitlab.io/post/002-virtualisation/, +* et **exemple de virtualisation avec QEMU/KVM/Libvirt sous Linux**, Cf. +https://odtre.gitlab.io/doc/virtualisation/. -La virtualisation permet, dans notre situation, de tester un ou plusieurs systèmes d'exploitation avant de les adopter et les déployer sur notre infrastructure. +**La virtualisation permet**, dans notre situation, de **tester un ou +plusieurs systèmes d'exploitation** avant de les adopter et les déployer sur +notre infrastructure. -![odtre.gitlab.io](./media/screenshot_odtre_doc.png){width=100%}\ +![Section « Documentation » du site statique odtre.gitlab.io généré sur +Gitlab](./media/screenshot_odtre_doc.png){width=100%} + +\newpage #### Sujet sur FluxCD -Concernant des outils spécifiques tels que FluxCD, **je favorise avant tout la documentation du site officiel**. Cf. https://fluxcd.io/flux/. +Concernant des outils spécifiques tels que FluxCD, **je favorise avant tout la +documentation du site officiel**. Cf. https://fluxcd.io/flux/. -C'est ainsi que plusieurs éléments de documentation m'ont été nécessaires pour déployer et utiliser FluxCD : +C'est ainsi que plusieurs éléments de **documentation** m'**ont été +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 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 ». +* la **page d'installation officielle**, Cf. +https://fluxcd.io/flux/installation/, +* 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 +«  tout seul ». -Comme auparavant, ceci a donné lieu à **la rédaction d'un article sur notre outil de retranscription**, Cf. https://odtre.gitlab.io/doc/fluxcd/. +Comme auparavant, ceci a donné lieu à **la rédaction d'un article sur notre +outil de retranscription**, Cf. https://odtre.gitlab.io/doc/fluxcd/. -![Documentation de FluxCD sur le site officiel](./media/screenshot_fluxcd_doc.png){width=100%}\ +![Documentation de FluxCD sur le site +officiel](./media/screenshot_fluxcd-doc.png){width=100%} ## Conclusion -Que les recherches soient fructueuses ou non, le projet a avancé. Les recherches ne donnent pas tous les savoirs, parfois il faut tester aussi. 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 restant dans les articles des blogueurs et autres joyeux rédacteurs en tous genres. +Que les recherches soient fructueuses ou non, le projet a avancé. Les +recherches ne donnent pas tous les savoirs, **parfois il faut tester aussi**. +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. diff --git a/content/80_conclusion.md b/content/80_conclusion.md index e270063..bfc57b5 100644 --- a/content/80_conclusion.md +++ b/content/80_conclusion.md @@ -2,10 +2,22 @@ # 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ù 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. +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. -En effet il est question de nouvelles compétences que le projet, à travers la rédaction d'un cahier des charges, de spécifications fonctionnelles, d'une approche (démarche) suivie, de plusieurs réalisations et de situations diverses qu'ont permis d'acquérir tout au long de ces derniers mois. +En effet, **il est question de nouvelles compétences**, que le projet, à +travers la rédaction d'un cahier des charges, de spécifications +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**. -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. +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**. -Bien que ne sachant ce que l'avenir me réserve, j'espère qu'il continuera sur la voie du DevOps et de l'enrichissement par de nouvelles connaissances et perspéctives professionnelles d'avenir ! +Bien que ne sachant ce que l'avenir me réserve, j'espère qu'il continuera sur +la voie du DevOps et de l'enrichissement par de nouvelles connaissances et +perspéctives professionnelles d'avenir ! diff --git a/media/screenshot_fluxcd-doc.png b/media/screenshot_fluxcd-doc.png new file mode 100644 index 0000000..659be07 Binary files /dev/null and b/media/screenshot_fluxcd-doc.png differ diff --git a/media/screenshot_fluxcd_doc.png b/media/screenshot_fluxcd_doc.png deleted file mode 100644 index 7242de7..0000000 Binary files a/media/screenshot_fluxcd_doc.png and /dev/null differ diff --git a/templates/default.latex b/templates/default.latex index 96ef855..d7c750f 100644 --- a/templates/default.latex +++ b/templates/default.latex @@ -173,6 +173,7 @@ $if(colorlinks)$ \usepackage{xcolor} $endif$ \usepackage{hyperref} +\usepackage{rotating} \hypersetup{ $if(title-meta)$ pdftitle={$title-meta$},