Compare commits
10 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 181a9770f1 | |||
| 21a64c6f45 | |||
| 8ba27d0e92 | |||
| 61cb52dc50 | |||
| 77dd0c0795 | |||
| 31631d6e87 | |||
| d9ee716c85 | |||
| 12217191ce | |||
| eeea2e8dfd | |||
| 2c4be8ae9b |
4
Makefile
4
Makefile
@ -44,8 +44,8 @@ public/${NAME}.html: public ${CONTENT_LIST}
|
|||||||
|
|
||||||
public/${NAME}.pdf: public ${CONTENT_LIST}
|
public/${NAME}.pdf: public ${CONTENT_LIST}
|
||||||
$Qecho "[PREPA] PDF : contenu"
|
$Qecho "[PREPA] PDF : contenu"
|
||||||
# Cf. https://pandoc.org/chunkedhtml-demo/8.17-images.html for implicit_figures explanations (deactivated here)
|
$Q# Cf. https://pandoc.org/chunkedhtml-demo/8.17-images.html for implicit_figures explanations. Si activé : titre + centrées MAIS les images sont pas au bon endroit dans le texte. Si désactivé : pas de titre, pas centrées, MAIS images au BON ENDROIT.
|
||||||
$Qpandoc -V colorlinks -V fontfamily="${FONT_FAMILY}" -V fontsize="${FONT_SIZE}" -V classoption:twoside --number-sections -V graphics --template="${LATEX_TEMPLATE}" --toc -V toc-title:'${TOC_TITLE}' -V papersize:a4 --from=markdown-implicit_figures+fenced_code_attributes --highlight-style ${HL_THEME} --to=latex -o "public/${NAME}.pdf" ${CONTENT_LIST}
|
$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
|
# END
|
||||||
.PHONY: clean
|
.PHONY: clean
|
||||||
|
|||||||
BIN
Olivier_DOSSMANN-v1.0.pdf
Normal file
BIN
Olivier_DOSSMANN-v1.0.pdf
Normal file
Binary file not shown.
BIN
Olivier_DOSSMANN-v1.1.pdf
Normal file
BIN
Olivier_DOSSMANN-v1.1.pdf
Normal file
Binary file not shown.
BIN
Olivier_DOSSMANN-v1.2.pdf
Normal file
BIN
Olivier_DOSSMANN-v1.2.pdf
Normal file
Binary file not shown.
@ -8,7 +8,7 @@ Document's content is available under **content** directory.
|
|||||||
|
|
||||||
Only `*.md` files would be read ([Markdown format](https://daringfireball.net/projects/markdown/)).
|
Only `*.md` files would be read ([Markdown format](https://daringfireball.net/projects/markdown/)).
|
||||||
|
|
||||||
# Depenencies
|
# Dependencies
|
||||||
|
|
||||||
## ArchLinux
|
## ArchLinux
|
||||||
|
|
||||||
|
|||||||
@ -4,7 +4,7 @@ subtitle: Dossier de projet - API Utilisateurs
|
|||||||
author: Olivier \textsc{Dossmann}
|
author: Olivier \textsc{Dossmann}
|
||||||
mail: <emploi@dossmann.net>
|
mail: <emploi@dossmann.net>
|
||||||
date: 05 mars 2025
|
date: 05 mars 2025
|
||||||
version: 0.2
|
version: 1.2
|
||||||
mentor: Jérémie \textsc{Tarot}
|
mentor: Jérémie \textsc{Tarot}
|
||||||
qrcode: https://odtre.gitlab.io/diapos/
|
qrcode: https://odtre.gitlab.io/diapos/
|
||||||
geometry:
|
geometry:
|
||||||
|
|||||||
@ -1,35 +0,0 @@
|
|||||||
\newpage
|
|
||||||
|
|
||||||
# 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
|
|
||||||
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.
|
|
||||||
|
|
||||||
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
|
|
||||||
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
|
|
||||||
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)
|
|
||||||
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,
|
|
||||||
quelques réalisations effectuées et d'une situation de travail qui mérite
|
|
||||||
d'être relevée.
|
|
||||||
|
|
||||||
Mais avant tout, nous tenons à présenter nos remerciements à quelques personnes.
|
|
||||||
|
|
||||||
@ -1,50 +0,0 @@
|
|||||||
\newpage
|
|
||||||
|
|
||||||
# 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 !
|
|
||||||
|
|
||||||
À 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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
## À 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.
|
|
||||||
|
|
||||||
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 !
|
|
||||||
|
|
||||||
À 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 !
|
|
||||||
|
|
||||||
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 »
|
|
||||||
|
|
||||||
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) :
|
|
||||||
|
|
||||||
* à 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 !
|
|
||||||
|
|
||||||
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.
|
|
||||||
53
content/10_intro.md
Normal file
53
content/10_intro.md
Normal file
@ -0,0 +1,53 @@
|
|||||||
|
\newpage
|
||||||
|
|
||||||
|
# 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
|
||||||
|
outillage plus conséquent pour déployer ces versions. C'est pour cette raison
|
||||||
|
que l'**automatisation**, entre autres, est nécessaire pour soulager les équipes
|
||||||
|
d'opération. Ainsi **le DevOps entre en jeu** : une culture et un
|
||||||
|
ensemble de **bonnes pratiques** pour faciliter l'échange entre les équipes
|
||||||
|
de développement et celles d'opération. Mais également de favoriser un **flux
|
||||||
|
continu** entre ces équipes.
|
||||||
|
|
||||||
|
Au long de mon parcours, que ce soit en tant qu'**Ingénieur en Conception et
|
||||||
|
Développement d'Environnements Distribués** ou **Responsable d'Applications**, j'ai
|
||||||
|
été sensibilisé aux besoins incessants de l'automatisation et de l'amélioration
|
||||||
|
des processus de création logicielle. J'ai participé à la mise en place
|
||||||
|
progressive d'une **chaîne de publication logicielle**, que ce soit dans le monde
|
||||||
|
professionnel ou dans la sphère privée (pour publier mon blog). C'est donc tout
|
||||||
|
naturellement que je me suis tourné vers ce domaine passionnant qu'est le
|
||||||
|
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)
|
||||||
|
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 en expliquant la démarche suivie pour accomplir le projet,
|
||||||
|
quelques réalisations effectuées et d'une situation de travail qui mérite
|
||||||
|
d'être relevée.
|
||||||
|
|
||||||
|
**Conventions typographiques**
|
||||||
|
|
||||||
|
Ce document suit certaines conventions de mise en forme pour faciliter la
|
||||||
|
lecture :
|
||||||
|
|
||||||
|
* Les liens hypertextes apparaissent sous la forme suivante : [Titre du lien](
|
||||||
|
https://perdu.com),
|
||||||
|
* Les références vers d'autres sections sont indiquées comme suit : [référence
|
||||||
|
vers un paragraphe spécifique, exemple avec DataScientest](#datascientest),
|
||||||
|
* Les mots-clés essentiels d'une section sont en **gras**,
|
||||||
|
* Les termes particuliers sont en *italique*,
|
||||||
|
* Les noms de famille apparaissent avec de petites majuscules : Prénom \textsc{Nom},
|
||||||
|
* Les extraits de code sont affichés dans un format distinct :
|
||||||
|
|
||||||
|
```bash {.numberLines}
|
||||||
|
#!/usr/bin/env bash
|
||||||
|
|
||||||
|
echo "Bonjour tout le monde !"
|
||||||
|
```
|
||||||
|
|
||||||
@ -1,43 +0,0 @@
|
|||||||
\newpage
|
|
||||||
|
|
||||||
# Liste de compétences couvertes par le projet
|
|
||||||
|
|
||||||
Le référentiel de compétences du *Titre Professionnel Administrateur Système DevOps* liste 11 compétences réparties en 3 catégories :
|
|
||||||
|
|
||||||
* Automatiser le déploiement d’une infrastructure dans le
|
|
||||||
cloud
|
|
||||||
* Compétence **n°1 : Automatiser la création de serveurs à l’aide de 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**
|
|
||||||
* 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**
|
|
||||||
* Superviser les services déployés
|
|
||||||
* 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**
|
|
||||||
|
|
||||||
En utilisant les critères de performance fournis par chaque fiche de compétence, nous avons pu établir le tableau suivant :
|
|
||||||
|
|
||||||
: Couverture de compétences par le 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°5 | 4/4 | Oui | Gitlab CI
|
|
||||||
Compétence n°6 | 1/3 | Non | 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°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.
|
|
||||||
@ -1,270 +0,0 @@
|
|||||||
\newpage
|
|
||||||
|
|
||||||
# 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.
|
|
||||||
|
|
||||||
Le cahier des charges a été la première réflexion sur le projet.
|
|
||||||
|
|
||||||
### 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.
|
|
||||||
|
|
||||||
Plusieurs formats de formation existent parmi Bootcamp, continu et en alternance. Ce projet est un exercice de fin de formation proposé à tous les élèves de la « cohorte » (équivalent d'une classe).
|
|
||||||
|
|
||||||
Plusieurs élèves se regroupent autour d'un projet auquel ils ont un intérêt commun.
|
|
||||||
|
|
||||||
### L'équipe DevU42 {#devu42}
|
|
||||||
|
|
||||||
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**.
|
|
||||||
|
|
||||||
Ses membres sont, par ordre alphabétique (prénom) :
|
|
||||||
|
|
||||||
* 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.
|
|
||||||
|
|
||||||
### Organisation d'équipe
|
|
||||||
|
|
||||||
Pour s'organiser, l'équipe s'est doté de plusieurs outils et suivi quelques méthodologies.
|
|
||||||
|
|
||||||
#### Rapports hiérarchiques
|
|
||||||
|
|
||||||
L’équipe s'articule autour de membres ayant le même degré de responsabilités et d'objectifs. Leur périmètre et leur champ d'action est similaire qu'il s'agisse de déterminer les tickets à prendre en charge, les axes de travail à rajouter au projet ou bien de nouveaux objectifs.
|
|
||||||
|
|
||||||
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 :
|
|
||||||
|
|
||||||
* 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 !
|
|
||||||
* Un nom de domaine, **devu42.fr**,
|
|
||||||
* Une boîte courriel, <team@devu42.fr> 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.
|
|
||||||
|
|
||||||
### Contraintes initiales
|
|
||||||
|
|
||||||
Deux principales contraintes initiales avaient été imposées dans le cadre de la formation :
|
|
||||||
|
|
||||||
* 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).
|
|
||||||
|
|
||||||
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**.
|
|
||||||
|
|
||||||
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).
|
|
||||||
|
|
||||||
## Le projet
|
|
||||||
|
|
||||||
Le point de départ du projet est un dépôt de version contenant une application à mettre en ligne. Justification du projet, l'application elle-même, ambitions et objectifs sont des points à soulever.
|
|
||||||
|
|
||||||
### Justification du projet
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
On imagine ainsi le cadre suivant :
|
|
||||||
|
|
||||||
> 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 :
|
|
||||||
|
|
||||||
* Reprise d’activité lente, coûteuse et avec pertes d’informations,
|
|
||||||
* Service instable, disponibilité non garantie, vulnérabilité du service,
|
|
||||||
* Capacité limitée pour encaisser des augmentations ponctuelles de la charge et du trafic,
|
|
||||||
* Absence de supervision et faible capacité à prévoir les problèmes,
|
|
||||||
* Manque de contrôle sur la qualité du code ; procédures de développement pouvant être améliorées par l'automatisation,
|
|
||||||
* Perte de temps et erreurs humaines liées aux actions manuelles,
|
|
||||||
* Manque de portabilité de l'application d'un système à l'autre,
|
|
||||||
* Lenteurs d’implémentation de nouvelles fonctionnalité avec interruptions de service.
|
|
||||||
|
|
||||||
Pour bien saisir l'état des lieux de ladite application, regardons de plus près.
|
|
||||||
|
|
||||||
### Application existante
|
|
||||||
|
|
||||||
L’application FastAPI-Træfik est fournie avec les éléments principaux suivants :
|
|
||||||
|
|
||||||
* BackEnd FastAPI (en Python),
|
|
||||||
* FrontEnd (Interface de gestion et d’enregistrement d’utilisateurs. Statique, Utilise React, Vite.js, Chakra UI.),
|
|
||||||
* Base de données postgreSQL,
|
|
||||||
* et Traefik (Proxy inverse).
|
|
||||||
|
|
||||||
Tout ceci est déposé dans un dépôt de version avec de la documentation en fichier Markdown (*.md) bruts.
|
|
||||||
|
|
||||||
De simples fichiers Docker et docker-compose.yml permettent aux développeurs de lancer l'application localement.
|
|
||||||
|
|
||||||
Une procédure existe pour expliquer comment manuellement mettre l'application en production sur une machine serveur dédiée.
|
|
||||||
|
|
||||||
Mais le projet voit plus loin.
|
|
||||||
|
|
||||||
### Ambitions
|
|
||||||
|
|
||||||
En dehors des objectifs à atteindre, le projet vise à :
|
|
||||||
|
|
||||||
* répondre aux problématiques de l’entreprise sur l'application existante par la méthode DevOps,
|
|
||||||
* répondre aux attentes de l’examen en matière de compétences attendues (méthode d'apprentissage par la pratique),
|
|
||||||
* démontrer un savoir-faire technique sur les sujets principaux du DevOps, notamment vis à vis du Cloud en utilisant AWS,
|
|
||||||
* appliquer une méthode de travail qui optimise l’efficacité de la production des livrables.
|
|
||||||
|
|
||||||
C'est de ces ambitions que naîssent plusieurs objectifs spécifiques.
|
|
||||||
|
|
||||||
### Objectifs
|
|
||||||
|
|
||||||
D'après moi, ce projet à plusieurs objectifs :
|
|
||||||
|
|
||||||
* balayer l'ensemble des sujets liés à la culture DevOps et ses méthodes,
|
|
||||||
* porter, puis déployer une application sur le cloud,
|
|
||||||
* préparer une architecture complète pour accueillir une à plusieurs applications,
|
|
||||||
* respecter un budget et des limites de temps,
|
|
||||||
* déployer en continu un projet en passant par une phase de test, de pré-production puis de production,
|
|
||||||
* penser à la gestion de la donnée,
|
|
||||||
* superviser un système déployé en production avec des tableaux de bord efficaces,
|
|
||||||
* rendre un système résilient en prenant en compte les augmentations ET les diminution de charges et par une haute disponibilité,
|
|
||||||
* automatiser la plupart des actions afin de limiter les erreurs humaines,
|
|
||||||
* procéder, de manière automatique, à des vérifications sur la sécurité des éléments produits et déployés,
|
|
||||||
* favoriser une collaboration plus fluide entre les équipes de développements et les équipes d'opérations,
|
|
||||||
* et obtenir des alertes en cas de défaillance d'un ou plusieurs éléments du système.
|
|
||||||
|
|
||||||
Ce sont des objectifs plutôt ambitieux pour un temps aussi court. Un travail d'équipe et une organisation sont totalement nécessaires.
|
|
||||||
|
|
||||||
## Planification
|
|
||||||
|
|
||||||
C'est par le [mentor](#mentor) que nous avons reçu un plan d'action pour les 7 semaines de travail et une liste de livrables attendus. Nous avons adapté ce plan d'action pour nous correspondre.
|
|
||||||
|
|
||||||
### Étapes de travail
|
|
||||||
|
|
||||||
Voici le détail de chaque étape de travail.
|
|
||||||
|
|
||||||
#### Semaine 1 : Cadrage
|
|
||||||
|
|
||||||
Sous le signe de l'encadrement, cette première semaine est dite « douce » :
|
|
||||||
|
|
||||||
* réunion de prise de contact, présentation et cadrage,
|
|
||||||
* introduction de chaque membre du projet,
|
|
||||||
* 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 :
|
|
||||||
|
|
||||||
* 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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
#### 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 :
|
|
||||||
|
|
||||||
* 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).
|
|
||||||
|
|
||||||
L'adoption d'un workflow pour la gestion des branches Git est la bienvenue.
|
|
||||||
|
|
||||||
#### Semaine 4 : Conception 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.
|
|
||||||
|
|
||||||
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 :
|
|
||||||
|
|
||||||
* créer et configurer des ressources de stockage de données,
|
|
||||||
* mise en place de politique d'authentification et d'autorisation,
|
|
||||||
* import des données,
|
|
||||||
* et installer et configurer une solution de sauvegarde et de restauration de données.
|
|
||||||
|
|
||||||
Rien de très particulier à ce niveau là.
|
|
||||||
|
|
||||||
#### Semaine 6 : Observabilité et alertes
|
|
||||||
|
|
||||||
Quant à la semaine 6, nous avons principalement la supervision à gérer :
|
|
||||||
|
|
||||||
* configuration du système de supervision centralisé,
|
|
||||||
* mise en place d'une collecte de surveillance pertinente pour l'application,
|
|
||||||
* choix des métriques à utiliser pour la création de tableaux de bords,
|
|
||||||
* création des tableaux de bords,
|
|
||||||
* définition des niveaux d'alertes pour les métriques choisis,
|
|
||||||
* mise en place des alertes,
|
|
||||||
* et envoi des alertes sur les canaux choisis.
|
|
||||||
|
|
||||||
Ces éléments pourront être complétés et étendus une fois la solution principale de supervision configurée.
|
|
||||||
|
|
||||||
#### Semaine 7 : Présentation de la solution finale
|
|
||||||
|
|
||||||
Cette dernière semaine ciblera la présentation et le lancement officiel de l'application. Il faudra donc :
|
|
||||||
|
|
||||||
* compléter les documentations,
|
|
||||||
* mettre à jour les schémas en fonction d'éventuels changements,
|
|
||||||
* préparer un support visuel de présentation du projet,
|
|
||||||
* veiller à ce que l'application tourne sans accrocs pour la présentation,
|
|
||||||
* et résoudre les derniers problèmes majeurs connus - s'ils existent.
|
|
||||||
|
|
||||||
C'est un plan assez ambitieux quand on considère que les membres de l'équipe proviennent d'horizons et de formations variées.
|
|
||||||
|
|
||||||
### Livrables
|
|
||||||
|
|
||||||
Sont attendus les éléments suivants :
|
|
||||||
|
|
||||||
* un cahier des charges,
|
|
||||||
* une présentation par diapositives pour le lancement de l'application,
|
|
||||||
* une application déployée en production, sans bugs,
|
|
||||||
* un système de supervision de la production,
|
|
||||||
* une gestion des données avec un système de sauvegarde,
|
|
||||||
* un schéma de la couche basse de l'infrastructure utilisée dans le Cloud pour la production,
|
|
||||||
* un accès aux dépôts et scripts permettant l'automatisation du déploiement de l'application et de la génération des différents éléments (images Docker, Chart Helm, registres, etc.),
|
|
||||||
* et un fonctionnement en haute disponibilité de l'application.
|
|
||||||
|
|
||||||
## Conclusion
|
|
||||||
|
|
||||||
Le projet couvre beaucoup de situations et domaines autour de l'automatisation et la mise en production, dans le Cloud, d'une application avec une supervision et une mise à l'échelle de cette dernière.
|
|
||||||
|
|
||||||
En groupe, c'est un projet idéal pour suivre l'« apprentissage par la pratique » proposée par [DataScientest](#datascientest) et couvrir un maximum de compétences demandées pour le Titre Professionnel d'Administrateur Système DevOps.
|
|
||||||
54
content/20_remerciements.md
Normal file
54
content/20_remerciements.md
Normal file
@ -0,0 +1,54 @@
|
|||||||
|
\newpage
|
||||||
|
|
||||||
|
# Remerciements
|
||||||
|
|
||||||
|
À **Madame Agnès \textsc{Schweitzer}** pour ses **conseils**, son aide
|
||||||
|
**précieuse**, sa **présence d'esprit** et son **exceptionnelle
|
||||||
|
intelligence** : MERCI !
|
||||||
|
|
||||||
|
## Via l'organisme de formation DataScientest
|
||||||
|
|
||||||
|
Je remercie **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.
|
||||||
|
|
||||||
|
Une mention toute particulière aux personnes suivantes pour leur **écoute**,
|
||||||
|
leur **professionnalisme** et leur souci de réponses claires :
|
||||||
|
|
||||||
|
* Sarah \textsc{Bouras},
|
||||||
|
* Benjamin \textsc{Fiche},
|
||||||
|
* et Jérémie \textsc{Tarot}.
|
||||||
|
|
||||||
|
Aux **membres de l'équipe DevU42** qui, malgré les **difficultés**, une **vie
|
||||||
|
sociale et familiale** prenante, des **obligations** et des
|
||||||
|
**responsabilités** ont donné ce qu'ils pouvaient :
|
||||||
|
|
||||||
|
* Hrubech \textsc{Hombessa},
|
||||||
|
* Eliel \textsc{Moncada},
|
||||||
|
* et Julien \textsc{Sabiols}.
|
||||||
|
|
||||||
|
J'imagine que derrière chacune de ces personnes il y a également **un ou une
|
||||||
|
partenaire de vie**. Vous méritez de figurer dans ces lignes et d'avoir un
|
||||||
|
grand MERCI !
|
||||||
|
|
||||||
|
Aux **membres de la « cohorte »** que je tiens à remercier. À
|
||||||
|
ceux qui ont participé aux discussions, qui ont voulu échanger, qui ont
|
||||||
|
accepté de répondre à des questions, qui ont partagé des difficultés ou encore
|
||||||
|
des solutions et qui étaient eux-mêmes finalement.
|
||||||
|
|
||||||
|
Une mention aux personnes suivantes :
|
||||||
|
|
||||||
|
* à Maxime \textsc{Boulanghien},
|
||||||
|
* à Michael \textsc{Lachand},
|
||||||
|
* à Philippe \textsc{Risser-Maroix},
|
||||||
|
* et à Dorian \textsc{Roly}.
|
||||||
|
|
||||||
|
## Et d'autres encore !
|
||||||
|
|
||||||
|
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 !
|
||||||
|
|
||||||
|
À Richard \textsc{Dern} et son œil d'aigle pour les nombreuses relectures et
|
||||||
|
fautes d'orthographes découvertes dans ce document.
|
||||||
69
content/30_liste_competences.md
Normal file
69
content/30_liste_competences.md
Normal file
@ -0,0 +1,69 @@
|
|||||||
|
\newpage
|
||||||
|
|
||||||
|
# Liste de compétences couvertes par le projet
|
||||||
|
|
||||||
|
## Introduction
|
||||||
|
|
||||||
|
Le référentiel de compétences du *Titre Professionnel Administrateur Système
|
||||||
|
DevOps* liste 11 compétences réparties en 3 catégories :
|
||||||
|
|
||||||
|
* 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**
|
||||||
|
* 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**
|
||||||
|
* Superviser les services déployés
|
||||||
|
* 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**
|
||||||
|
|
||||||
|
## Couverture
|
||||||
|
|
||||||
|
En utilisant les critères de performance fournis par chaque fiche de
|
||||||
|
compétence, j'ai pu établir le tableau suivant permettant de voir les points à
|
||||||
|
améliorer :
|
||||||
|
|
||||||
|
: 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°5 | 4/4 | Oui | Gitlab CI
|
||||||
|
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 | 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) n'a pu être clairement établie **faute d'interlocuteur autre que le
|
||||||
|
« mentor »**.
|
||||||
|
|
||||||
|
La **compétence n°10** (Exploiter une solution de supervision) est **en lien
|
||||||
|
avec la compétence précédente**, ce qui influe sur la pertinence des moniteurs
|
||||||
|
mis en place dans la solution.
|
||||||
|
|
||||||
|
## Conclusion
|
||||||
|
|
||||||
|
Le projet décrit dans le présent document couvre de manière complète une
|
||||||
|
énorme partie des compétences attendues. Au final 2 type de compétences
|
||||||
|
sont partiellement couvertes : celle concernant la supervision et celle
|
||||||
|
concernant le stockage de données.
|
||||||
File diff suppressed because one or more lines are too long
367
content/40_cahier_des_charges.md
Normal file
367
content/40_cahier_des_charges.md
Normal file
@ -0,0 +1,367 @@
|
|||||||
|
# Cahier des charges
|
||||||
|
|
||||||
|
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*.
|
||||||
|
|
||||||
|
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 pour lequel ils ont un
|
||||||
|
**intérêt commun**.
|
||||||
|
|
||||||
|
### L'équipe DevU42 {#devu42}
|
||||||
|
|
||||||
|
Le **groupe DevU42** s'est formé le **17 octobre 2024**. Il est composé de
|
||||||
|
**quatre étudiants** participant à la formation **Administrateur Système
|
||||||
|
DevOps** de l'organisme de formation [DataScientest](#datascientest).
|
||||||
|
|
||||||
|
Ses membres sont, par ordre alphabétique :
|
||||||
|
|
||||||
|
* **Hrubech \textsc{Hombessa}**,
|
||||||
|
* **Eliel \textsc{Moncada}**,
|
||||||
|
* **Julien \textsc{Sabiols}**,
|
||||||
|
* et Olivier \textsc{Dossmann}.
|
||||||
|
|
||||||
|
Ils interviennent sur le projet en qualité d'**Administrateur Système DevOps**.
|
||||||
|
|
||||||
|
L'équipe a été supervisée et suivie par [**Jérémie \textsc{Tarot}** sous la
|
||||||
|
dénomination de **« Mentor »**]{#mentor}. Et ainsi en sera-t-il
|
||||||
|
dans le présent document.
|
||||||
|
|
||||||
|
### Organisation d'équipe
|
||||||
|
|
||||||
|
Pour s'organiser, l'équipe s'est dotée de plusieurs outils et suivi certaines
|
||||||
|
méthodologies particulières.
|
||||||
|
|
||||||
|
#### Rapports hiérarchiques
|
||||||
|
|
||||||
|
L'équipe s'articule autour de membres ayant le **même degré de
|
||||||
|
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).
|
||||||
|
|
||||||
|
#### Moyens de communication
|
||||||
|
|
||||||
|
La géolocalisation des membres de l'**équipe étant éparse**, plusieurs moyens
|
||||||
|
de communication **en ligne** ont été nécessaires, parmi lesquels :
|
||||||
|
|
||||||
|
* Canaux de **discussions sur [Slack](https://slack.com/intl/fr-fr/)** fournis
|
||||||
|
initialement par [DataScientest](#datascientest) :
|
||||||
|
* 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, **<team@devu42.fr>** 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 :
|
||||||
|
|
||||||
|
* 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).
|
||||||
|
|
||||||
|
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**.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
### Justification du projet
|
||||||
|
|
||||||
|
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 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.
|
||||||
|
|
||||||
|
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**,
|
||||||
|
* Perte de temps et erreurs humaines liées aux actions manuelles,
|
||||||
|
* Manque de **portabilité de l'application** d'un système à l'autre,
|
||||||
|
* Lenteurs d'implémentation de **nouvelles fonctionnalités** avec
|
||||||
|
interruptions de service.
|
||||||
|
|
||||||
|
### Application existante
|
||||||
|
|
||||||
|
Pour bien saisir l'état des lieux de ladite application, regardons de plus
|
||||||
|
près.
|
||||||
|
|
||||||
|
L'**application API Utilisateurs** (nom de code FastAPI-Træfik) est fournie
|
||||||
|
avec les éléments principaux suivants :
|
||||||
|
|
||||||
|
* Backend utilisant le framework **FastAPI** (en Python),
|
||||||
|
* Frontend statique (en **React**, **Vite.js** et **Chakra UI**) :
|
||||||
|
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.
|
||||||
|
|
||||||
|
De simples fichiers **Docker** et **docker-compose.yml** permettent aux
|
||||||
|
développeurs de **lancer l'application localement**.
|
||||||
|
|
||||||
|
**Une procédure manuelle existe** pour expliquer comment mettre l'application
|
||||||
|
en production sur une machine serveur dédiée.
|
||||||
|
|
||||||
|
### Ambitions
|
||||||
|
|
||||||
|
Le projet **va plus loin** ; en dehors des objectifs à atteindre, il vise
|
||||||
|
à :
|
||||||
|
|
||||||
|
* répondre aux problématiques de l'entreprise sur l'application existante par
|
||||||
|
**la méthode DevOps**,
|
||||||
|
* 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.
|
||||||
|
|
||||||
|
### Objectifs
|
||||||
|
|
||||||
|
C'est de ces **ambitions** que naîssent plusieurs objectifs spécifiques :
|
||||||
|
|
||||||
|
* balayer l'ensemble des **sujets liés à la culture DevOps et ses méthodes**,
|
||||||
|
* porter, puis **déployer** une application **sur le cloud**,
|
||||||
|
* 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 des données**,
|
||||||
|
* **superviser** un système déployé en production avec des tableaux de bord
|
||||||
|
efficaces,
|
||||||
|
* rendre un système **résilient** en prenant en compte les augmentations ET
|
||||||
|
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éveloppement et les équipes d'opération,
|
||||||
|
* et obtenir des **alertes** en cas de défaillance d'un ou plusieurs éléments
|
||||||
|
du système.
|
||||||
|
|
||||||
|
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 {#plan}
|
||||||
|
|
||||||
|
Après quelques échanges avec le [mentor](#mentor) nous avons établi le plan
|
||||||
|
d'action pour les 7 semaines de travail à venir ainsi qu'une liste de
|
||||||
|
livrables attendus.
|
||||||
|
|
||||||
|
### Étapes de travail
|
||||||
|
|
||||||
|
Le plan s'articule en étapes bien définies.
|
||||||
|
|
||||||
|
#### Semaine 1 : Cadrage
|
||||||
|
|
||||||
|
Sous le signe de l'**encadrement**, cette première semaine est dite
|
||||||
|
« douce » :
|
||||||
|
|
||||||
|
* **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**.
|
||||||
|
|
||||||
|
Il faut ce temps pour découvrir de quoi il retourne.
|
||||||
|
|
||||||
|
#### Semaine 2 : Planification
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Ce qui amène à **compléter le cahier des charges**.
|
||||||
|
|
||||||
|
Nous prévoyons aussi :
|
||||||
|
|
||||||
|
* une **configuration de Gitlab**, des principaux dépôts, des branches, etc.,
|
||||||
|
* de s'organiser en équipe : définir des **méthodologies** à suivre.
|
||||||
|
|
||||||
|
#### Semaine 3 : Automatisation de la chaine d'intégration et de livraison
|
||||||
|
|
||||||
|
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 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 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** :
|
||||||
|
|
||||||
|
* **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.
|
||||||
|
|
||||||
|
#### Semaine 5 : Gestion des données
|
||||||
|
|
||||||
|
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/configurer une solution de **sauvegarde** et de **restauration
|
||||||
|
de données**.
|
||||||
|
|
||||||
|
C'est un sujet bien à part. D'où la possibilité de **faire cette étape en
|
||||||
|
parallèle** d'une autre.
|
||||||
|
|
||||||
|
#### Semaine 6 : Observabilité et alertes {#semaine6}
|
||||||
|
|
||||||
|
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 choisies,
|
||||||
|
* mise en place des **alertes**,
|
||||||
|
* et envoi des alertes sur **les canaux choisis**.
|
||||||
|
|
||||||
|
Ces éléments pourront être complétés et étendus une fois la solution
|
||||||
|
principale de supervision configurée.
|
||||||
|
|
||||||
|
#### Semaine 7 : Présentation de la solution finale
|
||||||
|
|
||||||
|
Cette dernière semaine ciblera la **présentation et** le **lancement officiel
|
||||||
|
de l'application**. Il faudra donc :
|
||||||
|
|
||||||
|
* compléter les **documentations**,
|
||||||
|
* **mettre à jour les schémas** en fonction d'éventuels changements,
|
||||||
|
* préparer un **support visuel de présentation du projet**,
|
||||||
|
* veiller à ce que l'**application tourne sans accrocs** pour la présentation,
|
||||||
|
* et résoudre les derniers problèmes majeurs connus - s'ils existent.
|
||||||
|
|
||||||
|
C'est un **plan ambitieux** quand on considère que **les membres de l'équipe
|
||||||
|
proviennent d'horizons et de formations variés**.
|
||||||
|
|
||||||
|
### Livrables {#livrables}
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
## 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 tout en gérant une **base de données**, le **stockage** et la
|
||||||
|
**sauvegarde**.
|
||||||
|
|
||||||
|
En groupe, c'est un projet idéal pour suivre l'« **apprentissage par la
|
||||||
|
pratique** » proposé par [DataScientest](#datascientest) et couvrir un
|
||||||
|
maximum de compétences demandées pour le *Titre Professionnel d'Administrateur
|
||||||
|
Système* DevOps.
|
||||||
|
|
||||||
|
Cela demande de suivre [le plan](#plan) à la lettre dans les **limites de
|
||||||
|
temps et de budget** définies : c'est un projet ambitieux.
|
||||||
@ -1,217 +0,0 @@
|
|||||||
\newpage
|
|
||||||
|
|
||||||
# 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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
## Méthodologie
|
|
||||||
|
|
||||||
### Agile
|
|
||||||
|
|
||||||
Le choix d'une méthodologie agile « basique » s'est offerte à nous, notamment par :
|
|
||||||
|
|
||||||
* des **comptes-rendus journaliers rapides de 10mn** en respectant les points suivants :
|
|
||||||
* ce que j'ai fais hier,
|
|
||||||
* ai-je rencontré un/des problème(s) qui vaille(nt) d'être cité(s),
|
|
||||||
* ce que 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).
|
|
||||||
|
|
||||||
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 :
|
|
||||||
|
|
||||||
* É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)
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
#### 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).
|
|
||||||
|
|
||||||
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 :
|
|
||||||
|
|
||||||
```
|
|
||||||
1.0.0
|
|
||||||
2.1.4
|
|
||||||
0.6.3-alpha
|
|
||||||
0.6.3-alpha.1
|
|
||||||
1.5.2-rc.2
|
|
||||||
```
|
|
||||||
|
|
||||||
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/).
|
|
||||||
|
|
||||||
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 :
|
|
||||||
|
|
||||||
* 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.
|
|
||||||
|
|
||||||
{width=50%}\
|
|
||||||
|
|
||||||
#### 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).
|
|
||||||
|
|
||||||
Cela se résume à peu près à cela :
|
|
||||||
|
|
||||||
```
|
|
||||||
<type>[étendue optionnelle]: <description>
|
|
||||||
|
|
||||||
[corps optionnel]
|
|
||||||
|
|
||||||
[pied optionnel]
|
|
||||||
```
|
|
||||||
|
|
||||||
Qui donne par exemple :
|
|
||||||
|
|
||||||
```markdown {.numberLines}
|
|
||||||
feat(backend): include postgreSQL BDD + backend
|
|
||||||
|
|
||||||
* change EC2 instances to t3.large
|
|
||||||
* change min_size nodes to 2
|
|
||||||
* use backend version 0.0.1
|
|
||||||
* use annotations to have api.r53.devu42.fr as domain for backend
|
|
||||||
* use annotations to use Let's Encrypt with cert-manager
|
|
||||||
* update EBS CSI driver to v1.37.0-eksbuild.1
|
|
||||||
* declare a StorageClass EBS in gp3 for postgreSQL
|
|
||||||
* use this EBS StorageClass in our backend chart for postgreSQL
|
|
||||||
* set database size to 1Gi
|
|
||||||
|
|
||||||
ref projet#18
|
|
||||||
```
|
|
||||||
|
|
||||||
## Outils
|
|
||||||
|
|
||||||
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**.
|
|
||||||
|
|
||||||
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 :
|
|
||||||
|
|
||||||
* 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.
|
|
||||||
|
|
||||||
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 :
|
|
||||||
|
|
||||||
* 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,
|
|
||||||
* 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,
|
|
||||||
* etc.
|
|
||||||
|
|
||||||
De nombreuses fonctionnalités supplémentaires existent dans Gitlab. Cela en fait donc un outil de choix pour notre projet.
|
|
||||||
|
|
||||||
#### 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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
{width=100%}\
|
|
||||||
|
|
||||||
#### 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.
|
|
||||||
|
|
||||||
{width=50%}\
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
## 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é.
|
|
||||||
|
|
||||||
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/).
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
Pour reprendre le schéma de l'article :
|
|
||||||
|
|
||||||
{width=100%}\
|
|
||||||
|
|
||||||
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).
|
|
||||||
|
|
||||||
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 :
|
|
||||||
|
|
||||||
* 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,
|
|
||||||
* 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.
|
|
||||||
|
|
||||||
À 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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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é.
|
|
||||||
File diff suppressed because one or more lines are too long
381
content/50_specifications_techniques.md
Normal file
381
content/50_specifications_techniques.md
Normal file
File diff suppressed because one or more lines are too long
309
content/60_demarche.md
Normal file
309
content/60_demarche.md
Normal file
@ -0,0 +1,309 @@
|
|||||||
|
# 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**.
|
||||||
|
|
||||||
|
En pareille situation, c'est tout un **écosystème DevOps** qu'il faut mettre
|
||||||
|
en place. Nous allons donc avant tout parler des **méthodologies utilisées**
|
||||||
|
pour ce faire, puis des **outils utilisés** et enfin aborder le sujet de
|
||||||
|
**collaborations** avec d'autres équipes.
|
||||||
|
|
||||||
|
## Méthodologie
|
||||||
|
|
||||||
|
### Agile
|
||||||
|
|
||||||
|
Le choix d'une **méthodologie agile** « basique » s'est offerte à nous,
|
||||||
|
notamment par :
|
||||||
|
|
||||||
|
* des **comptes-rendus journaliers rapides de 10mn** en respectant les points
|
||||||
|
suivants :
|
||||||
|
* ce que j'ai fait hier,
|
||||||
|
* ai-je rencontré un/des problème(s) qui vaut(valent) d'être cité(s),
|
||||||
|
* ce que je compte faire aujourd'hui,
|
||||||
|
* la **création de jalons** avec un ensemble de tâches sur une période d'une
|
||||||
|
semaine,
|
||||||
|
* 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).
|
||||||
|
|
||||||
|
### 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 :
|
||||||
|
|
||||||
|
* É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).
|
||||||
|
|
||||||
|
### Choix de standards et normes
|
||||||
|
|
||||||
|
Les jalons n'étaient pas suffisants, d'autres éléments ont dû être pris en
|
||||||
|
compte ; des standards/normes ont été choisies pour **rassembler plutôt
|
||||||
|
que diviser le groupe** : c'est là que SemVer, Git OneFlow et
|
||||||
|
Conventional commit entrent en jeu.
|
||||||
|
|
||||||
|
#### SemVer
|
||||||
|
|
||||||
|
[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**.
|
||||||
|
|
||||||
|
Nous ne détaillerons pas l'ensemble du standard, mais voici **quelques
|
||||||
|
exemples de versions** :
|
||||||
|
|
||||||
|
```
|
||||||
|
1.0.0
|
||||||
|
2.1.4
|
||||||
|
0.6.3-alpha
|
||||||
|
0.6.3-alpha.1
|
||||||
|
1.5.2-rc.2
|
||||||
|
```
|
||||||
|
|
||||||
|
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/).
|
||||||
|
|
||||||
|
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 :
|
||||||
|
|
||||||
|
* 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.
|
||||||
|
|
||||||
|
{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)**.
|
||||||
|
|
||||||
|
Cela se résume à peu près à cela :
|
||||||
|
|
||||||
|
```
|
||||||
|
<type>[étendue optionnelle]: <description>
|
||||||
|
|
||||||
|
[corps optionnel]
|
||||||
|
|
||||||
|
[pied optionnel]
|
||||||
|
```
|
||||||
|
|
||||||
|
Qui donne **par exemple** :
|
||||||
|
|
||||||
|
```markdown {.numberLines}
|
||||||
|
feat(backend): include postgreSQL BDD + backend
|
||||||
|
|
||||||
|
* change EC2 instances to t3.large
|
||||||
|
* change min_size nodes to 2
|
||||||
|
* use backend version 0.0.1
|
||||||
|
* use annotations to have api.r53.devu42.fr as domain for backend
|
||||||
|
* use annotations to use Let's Encrypt with cert-manager
|
||||||
|
* update EBS CSI driver to v1.37.0-eksbuild.1
|
||||||
|
* declare a StorageClass EBS in gp3 for postgreSQL
|
||||||
|
* use this EBS StorageClass in our backend chart for postgreSQL
|
||||||
|
* set database size to 1Gi
|
||||||
|
|
||||||
|
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é
|
||||||
|
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**.
|
||||||
|
|
||||||
|
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 :
|
||||||
|
|
||||||
|
* 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 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 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 é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.
|
||||||
|
|
||||||
|
\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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
{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.
|
||||||
|
|
||||||
|
{height=70%}
|
||||||
|
|
||||||
|
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 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é.
|
||||||
|
|
||||||
|
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 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 :
|
||||||
|
|
||||||
|
{width=100%}
|
||||||
|
|
||||||
|
Après moultes discussions, **nous sommes tombés d'accord** sur quelques
|
||||||
|
points, notamment :
|
||||||
|
|
||||||
|
* **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).
|
||||||
|
|
||||||
|
**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, 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 la somme de contrôle) avant
|
||||||
|
utilisation dans d'autres dépôts.
|
||||||
|
|
||||||
|
Maxime et moi avons également relevé que lorsqu'on parle de promotions dans
|
||||||
|
l'infrastructure on peut imaginer 2 types de promotions :
|
||||||
|
|
||||||
|
* la promotion de versions concernant les logiciels/modules/charts utilisés,
|
||||||
|
* et la promotion de configurations pour différentes infrastructures.
|
||||||
|
|
||||||
|
C'est un autre sujet très intéressant que nous ne détaillerons pas ici.
|
||||||
|
|
||||||
|
## 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 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.
|
||||||
|
|
||||||
|
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é.
|
||||||
File diff suppressed because one or more lines are too long
385
content/70_realisations.md
Normal file
385
content/70_realisations.md
Normal file
@ -0,0 +1,385 @@
|
|||||||
|
\newpage
|
||||||
|
|
||||||
|
# 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é.
|
||||||
|
|
||||||
|
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 :
|
||||||
|
|
||||||
|
* 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.
|
||||||
|
|
||||||
|
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**),
|
||||||
|
* 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.
|
||||||
|
|
||||||
|
\newpage
|
||||||
|
|
||||||
|
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 :
|
||||||
|
|
||||||
|
{height=40%}
|
||||||
|
|
||||||
|
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 ?
|
||||||
|
|
||||||
|
Après plusieurs heures de réflexions, de dessins en tous genres et du recul,
|
||||||
|
j'ai constaté que :
|
||||||
|
|
||||||
|
* 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é.
|
||||||
|
|
||||||
|
\newpage
|
||||||
|
|
||||||
|
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 :
|
||||||
|
|
||||||
|
{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.
|
||||||
|
|
||||||
|
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 représentant la pipeline de
|
||||||
|
chaque dépôt :
|
||||||
|
|
||||||
|
```{=latex}
|
||||||
|
\begin{sidewaysfigure}
|
||||||
|
\includegraphics{./media/schema_3_pipelines.png}
|
||||||
|
\caption{Schéma des 3 pipelines}
|
||||||
|
\end{sidewaysfigure}
|
||||||
|
```
|
||||||
|
|
||||||
|
\newpage
|
||||||
|
|
||||||
|
Ce qui donne le savant mélange suivant :
|
||||||
|
|
||||||
|
{height=73%}
|
||||||
|
|
||||||
|
\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:
|
||||||
|
stage: inform-next
|
||||||
|
variables:
|
||||||
|
BACKEND_CHARTFILE_PATH: charts/backend/Chart.yaml
|
||||||
|
FRONTEND_CHARTFILE_PATH: charts/frontend/Chart.yaml
|
||||||
|
script:
|
||||||
|
- |
|
||||||
|
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:${ACCESS_TOKEN}@${CHARTS_REPOSITORY}
|
||||||
|
cd charts
|
||||||
|
# Update files
|
||||||
|
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 back/front image version"
|
||||||
|
git tag $COMMIT_TAG
|
||||||
|
git push origin main --tags
|
||||||
|
fi
|
||||||
|
needs: [push-backend,push-frontend]
|
||||||
|
```
|
||||||
|
|
||||||
|
**Le code a dû être modifié (raccourcissement des lignes) pour les fins de
|
||||||
|
rédaction du présent document**.
|
||||||
|
|
||||||
|
Les **ligne 27 à 29** posent un tag sur le dépôt **charts** en mettant
|
||||||
|
simplement à jour les versions utilisées du backend et du frontend dans les
|
||||||
|
charts Helm sur le registre Gitlab.
|
||||||
|
|
||||||
|
### Résultats
|
||||||
|
|
||||||
|
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 :
|
||||||
|
|
||||||
|
* 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 **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**.
|
||||||
|
|
||||||
|
### 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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
## 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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
### 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 :
|
||||||
|
|
||||||
|
* 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**.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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 :
|
||||||
|
|
||||||
|
* **init**,
|
||||||
|
* **plan**,
|
||||||
|
* **apply**,
|
||||||
|
* **destroy**,
|
||||||
|
* **fmt**,
|
||||||
|
* et **graph**.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
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 :
|
||||||
|
|
||||||
|
```bash {.numberLines}
|
||||||
|
#!/usr/bin/env bash
|
||||||
|
#
|
||||||
|
# init.sh
|
||||||
|
#
|
||||||
|
# Initialize for a Developer
|
||||||
|
|
||||||
|
ENV_FILE="${PWD}/.env"
|
||||||
|
BACKEND_HTTP_FILE="${PWD}/backend.hcl"
|
||||||
|
|
||||||
|
# Need variables in this file
|
||||||
|
source "${ENV_FILE}" \
|
||||||
|
|| echo "Fichier ${ENV_FILE} manquant." \
|
||||||
|
|| exit 1
|
||||||
|
|
||||||
|
echo "[INFO] 'USERNAME': ${TF_HTTP_USERNAME}"
|
||||||
|
|
||||||
|
if ! [[ -f "${BACKEND_HTTP_FILE}" ]]; then
|
||||||
|
echo "[ERR] ${BACKEND_HTTP_FILE} manquant!"
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
terraform init \
|
||||||
|
-reconfigure \
|
||||||
|
-backend-config=${BACKEND_HTTP_FILE} $@
|
||||||
|
```
|
||||||
|
|
||||||
|
\newpage
|
||||||
|
|
||||||
|
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
|
||||||
|
export TF_HTTP_USERNAME="PseudoGitlab"
|
||||||
|
export TF_STATE_NAME="dev"
|
||||||
|
# Cf.https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html
|
||||||
|
export TF_HTTP_PASSWORD="monPersonnalAccessTokenGitlab"
|
||||||
|
# Backend HTTP
|
||||||
|
export TF_HTTP_ADDRESS="<myurl>/state/${TF_STATE_NAME}"
|
||||||
|
export TF_HTTP_LOCK_ADDRESS="<myurl>/state/${TF_STATE_NAME}/lock"
|
||||||
|
export TF_HTTP_UNLOCK_ADDRESS="<myurl>/state/${TF_STATE_NAME}/lock"
|
||||||
|
# Accès AWS
|
||||||
|
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
|
||||||
|
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**.
|
||||||
|
|
||||||
|
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 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**.
|
||||||
|
|
||||||
|
### 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.
|
||||||
|
|
||||||
|
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**.
|
||||||
|
|
||||||
|
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é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.
|
||||||
|
|
||||||
|
Ces expériences ont aussi permi d'acquérir de nouvelles compétences
|
||||||
|
primordiales dans le domaine du DevOps. La prise de recul sur ces éléments
|
||||||
|
met en évidence des failles dans le schéma de pensée. Il y a donc des points
|
||||||
|
à améliorer et une évolution possible dans les tâches présentées.
|
||||||
|
|
||||||
|
Je pense aussi que de nouvelles expériences seraient enrichissantes pour
|
||||||
|
comparaison avec celles présentées ici afin d'estimer les pour et les contre
|
||||||
|
de différentes solutions. Cela permettrait de s'adapter aux situations avec
|
||||||
|
des outils adéquats.
|
||||||
@ -1,11 +0,0 @@
|
|||||||
\newpage
|
|
||||||
|
|
||||||
# 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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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 !
|
|
||||||
195
content/80_situation_de_travail.md
Normal file
195
content/80_situation_de_travail.md
Normal file
@ -0,0 +1,195 @@
|
|||||||
|
\newpage
|
||||||
|
|
||||||
|
# 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** ».
|
||||||
|
|
||||||
|
Pour saisir **la méthodologie choisie**, je pense qu'il est nécessaire de
|
||||||
|
décrire une situation complète. Nous allons poser le contexte, faire l'état
|
||||||
|
des lieux puis suivre la démarche pour atteindre l'objectif.
|
||||||
|
|
||||||
|
## Contexte et état des lieux
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Où les installer ? Comment ? **De quelles ressources
|
||||||
|
disposons-nous ?**
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
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**.
|
||||||
|
|
||||||
|
Après en avoir discuté en groupe, je me suis attelé à la tâche. Régulièrement.
|
||||||
|
|
||||||
|
## Démarche
|
||||||
|
|
||||||
|
### 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**.
|
||||||
|
|
||||||
|
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**.
|
||||||
|
|
||||||
|
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,
|
||||||
|
* recherche de **livres existants** sur le sujet,
|
||||||
|
* passage à la **médiathèque**,
|
||||||
|
* 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 **sur Internet** avec une **grande
|
||||||
|
lecture initiale** de [**Stéphane \textsc{Robert}** (Devenez expert DevOps et
|
||||||
|
maîtrisez ses outils)](https://blog.stephane-robert.info/){#stephane-robert}
|
||||||
|
(j'ai repris le titre du site tel quel).
|
||||||
|
|
||||||
|
{height=35%}
|
||||||
|
|
||||||
|
\newpage
|
||||||
|
|
||||||
|
### Point de départ
|
||||||
|
|
||||||
|
Grâce à la lecture de quantité d'articles sur le blog de [Stéphane
|
||||||
|
\textsc{Robert}](#stephane-robert), notamment la [série d'article sur
|
||||||
|
« Mon nouveau Homelab DevOps »](
|
||||||
|
https://blog.stephane-robert.info/docs/homelab/introduction/) (Cf.
|
||||||
|
https://blog.stephane-robert.info/docs/homelab/introduction/) et la
|
||||||
|
**Roadmap de son parcours de formation DevSecOps** (Cf.
|
||||||
|
https://blog.stephane-robert.info/docs/#la-roadmap), j'ai pu établir des
|
||||||
|
**objectifs à court terme** et des étapes de sujets à aborder comme :
|
||||||
|
|
||||||
|
* le **sujet de la virtualisation**,
|
||||||
|
* **le GitOps avec** un outil tel que **FluxCD**.
|
||||||
|
|
||||||
|
{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** :
|
||||||
|
|
||||||
|
* Le **wiki d'ArchLinux** et sa catégorie
|
||||||
|
« **Virtualization** » : \
|
||||||
|
https://wiki.archlinux.org/title/Category:Virtualization,
|
||||||
|
* Le blog précédemment cité de [**Stéphane
|
||||||
|
\textsc{Robert}**](#stephane-robert).
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
**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/.
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
{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/.
|
||||||
|
|
||||||
|
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 ».
|
||||||
|
|
||||||
|
Comme auparavant, ceci a donné lieu à **la rédaction d'un article sur notre
|
||||||
|
outil de retranscription**, Cf. https://odtre.gitlab.io/doc/fluxcd/.
|
||||||
|
|
||||||
|
{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** restent **dans les articles des
|
||||||
|
blogueurs** et autres joyeux rédacteurs en tous genres.
|
||||||
|
|
||||||
|
Le blog de [Stéphane \textsc{Robert}](#stephane-robert) est un bon point de
|
||||||
|
départ qui ne dispense absolument pas de recherches supplémentaires. Des
|
||||||
|
outils tels que QEMU/KVM/libvirt pour la virtualisation sont de bonnes idées
|
||||||
|
pour tester les outils de DevOps dans un environnement isolé. Tout comme
|
||||||
|
FluxCD qui permet d'automatiser, à l'intérieur d'un environnement Kubernetes,
|
||||||
|
la recherche de nouvelles versions de ses applications.
|
||||||
|
|
||||||
|
La méthodologie ayant été fructueuse, elle sera dans mes priorités pour les
|
||||||
|
années à venir. Il faudra cependant être attentif au temps passé à la
|
||||||
|
publication de ses recherches qui, bien qu'il soit un investissement sur long
|
||||||
|
terme, consomme un temps certain à la rédaction et la mise en page.
|
||||||
33
content/90_conclusion.md
Normal file
33
content/90_conclusion.md
Normal file
@ -0,0 +1,33 @@
|
|||||||
|
# Conclusion
|
||||||
|
|
||||||
|
Ma **passion anticipée pour l'automatisation** et l'**amélioration des
|
||||||
|
processus** de **création logiciel** m'ont amené à ce moment 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éfiques à la prise d'expérience**, mais pas que.
|
||||||
|
|
||||||
|
En effet, **il est question de nouvelles compétences**, que le projet, à
|
||||||
|
travers la rédaction d'un cahier des charges, de spécifications
|
||||||
|
fonctionnelles, d'une approche (démarche) suivie, de plusieurs réalisations et
|
||||||
|
de situations diverses, a permis d'**acquérir tout au long de ces derniers
|
||||||
|
mois**.
|
||||||
|
|
||||||
|
La découverte de nombreux outils comme Kubernetes, Terraform, FluxCD, Datadog,
|
||||||
|
externaldns, cert-manager, QEMU/KVM, libvirt, etc. a été riche et variée. Il
|
||||||
|
est possible **d'approfondir plus encore** sur ces derniers et de les essayer
|
||||||
|
dans **d'autres environnements de cloud** comme *Microsoft Azure* ou *Google
|
||||||
|
Cloud Platform*.
|
||||||
|
|
||||||
|
Ainsi **je ressors riche de nouvelles expériences**, de **nouveaux outils**,
|
||||||
|
de **nouvelles méthodes** et de **nouveaux collaborateurs** dans un monde sans
|
||||||
|
cesse grandissant qu'est **le monde du DevOps**. C'est aussi et surtout une
|
||||||
|
culture qui amène à de **bonnes pratiques**, une **amélioration constante** et
|
||||||
|
la découverte infinie de projets en tous genres.
|
||||||
|
|
||||||
|
Ce projet, bien qu'ambitieux au départ, semble désormais une approche basique
|
||||||
|
à reprendre lors de futurs projets. Il faudra alors améliorer la gestion
|
||||||
|
d'équipe, une planification plus réactive et la prise en compte de plus de
|
||||||
|
facteurs comme l'apprentissage de nouvelles technologies, les retards et le
|
||||||
|
temps accordé à chaque étape. D'autres outils, plus adaptés, pourront
|
||||||
|
également mieux se greffer à de nouveaux projets pour en faciliter la
|
||||||
|
finalisation.
|
||||||
BIN
media/screenshot_fluxcd-doc.png
Normal file
BIN
media/screenshot_fluxcd-doc.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 198 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 183 KiB |
BIN
media/screenshot_odtre_doc_shadow.png
Normal file
BIN
media/screenshot_odtre_doc_shadow.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 98 KiB |
@ -173,6 +173,7 @@ $if(colorlinks)$
|
|||||||
\usepackage{xcolor}
|
\usepackage{xcolor}
|
||||||
$endif$
|
$endif$
|
||||||
\usepackage{hyperref}
|
\usepackage{hyperref}
|
||||||
|
\usepackage{rotating}
|
||||||
\hypersetup{
|
\hypersetup{
|
||||||
$if(title-meta)$
|
$if(title-meta)$
|
||||||
pdftitle={$title-meta$},
|
pdftitle={$title-meta$},
|
||||||
|
|||||||
Reference in New Issue
Block a user