Compare commits
6 Commits
v1.0
...
8ba27d0e92
| Author | SHA1 | Date | |
|---|---|---|---|
| 8ba27d0e92 | |||
| 61cb52dc50 | |||
| 77dd0c0795 | |||
| 31631d6e87 | |||
| d9ee716c85 | |||
| 12217191ce |
2
Makefile
2
Makefile
@ -44,7 +44,7 @@ public/${NAME}.html: public ${CONTENT_LIST}
|
||||
|
||||
public/${NAME}.pdf: public ${CONTENT_LIST}
|
||||
$Qecho "[PREPA] PDF : contenu"
|
||||
# Cf. https://pandoc.org/chunkedhtml-demo/8.17-images.html for implicit_figures explanations. Si activé : titre + centrées MAIS les images sont pas au bon endroit dans le texte. Si désactivé : pas de titre, pas centrées, MAIS images au BON ENDROIT.
|
||||
$Q# Cf. https://pandoc.org/chunkedhtml-demo/8.17-images.html for implicit_figures explanations. Si activé : titre + centrées MAIS les images sont pas au bon endroit dans le texte. Si désactivé : pas de titre, pas centrées, MAIS images au BON ENDROIT.
|
||||
$Qpandoc -V colorlinks -V fontfamily="${FONT_FAMILY}" -V fontsize="${FONT_SIZE}" -V classoption:twoside --number-sections -V graphics --template="${LATEX_TEMPLATE}" --toc -V toc-title:'${TOC_TITLE}' -V papersize:a4 --from=markdown+implicit_figures+fenced_code_attributes --highlight-style ${HL_THEME} --to=latex -o "public/${NAME}.pdf" ${CONTENT_LIST}
|
||||
|
||||
# END
|
||||
|
||||
BIN
Olivier_DOSSMANN-v1.1.pdf
Normal file
BIN
Olivier_DOSSMANN-v1.1.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/)).
|
||||
|
||||
# Depenencies
|
||||
# Dependencies
|
||||
|
||||
## ArchLinux
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@ subtitle: Dossier de projet - API Utilisateurs
|
||||
author: Olivier \textsc{Dossmann}
|
||||
mail: <emploi@dossmann.net>
|
||||
date: 05 mars 2025
|
||||
version: 1.0
|
||||
version: 1.1
|
||||
mentor: Jérémie \textsc{Tarot}
|
||||
qrcode: https://odtre.gitlab.io/diapos/
|
||||
geometry:
|
||||
|
||||
@ -1,105 +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.
|
||||
|
||||
## Aux membres de la « cohorte »
|
||||
|
||||
Je tiens à remercier également **l'ensemble des membres de la cohorte**. À
|
||||
ceux qui ont participé aux discussions, à ceux qui ont bien voulu échanger,
|
||||
à ceux qui ont accepté de répondre à des questions, à ceux qui ont partagé
|
||||
des difficultés ou encore des solutions, à ceux qui étaient eux-même.
|
||||
|
||||
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'avais oublié des personnes, je m'en excuse. Il y a pourtant
|
||||
ici toute la place nécessaire, voilà pourquoi j'ai reservé ce paragraphe à
|
||||
toutes celles et ceux dont j'aurais omis le nom/prénom.
|
||||
@ -6,16 +6,16 @@ La **méthodologie Agile** étant de plus en plus adoptée, les **équipes de
|
||||
développement** publient de nouvelles versions de leur application avec une
|
||||
fréquence bien plus élevée. Les **équipes d'opération** ont désormais besoin d'un
|
||||
outillage plus conséquent pour déployer ces versions. C'est pour cette raison
|
||||
que l'**automatisation**, entre autre, est nécessaire pour soulager les équipes
|
||||
que l'**automatisation**, entre autres, est nécessaire pour soulager les équipes
|
||||
d'opération. Ainsi **le DevOps entre en jeu** : une culture et un
|
||||
ensemble de **bonnes pratiques** pour faciliter l'échange entre les équipes
|
||||
de développement et celles d'opérations. Mais également de favoriser un **flux
|
||||
de développement et celles d'opération. Mais également de favoriser un **flux
|
||||
continu** entre ces équipes.
|
||||
|
||||
Au long de mon parcours, que ce soit en tant qu'**Ingénieur en Conception et
|
||||
Développement d’Environnements Distribués** ou **Responsable d'Applications**, j'ai
|
||||
été sensibilisé aux besoin incessants de l'automatisation et de l'amélioration
|
||||
des processus de création logiciel. J'ai participé à la mise en place
|
||||
Développement d'Environnements Distribués** ou **Responsable d'Applications**, j'ai
|
||||
été sensibilisé aux besoins incessants de l'automatisation et de l'amélioration
|
||||
des processus de création logicielle. J'ai participé à la mise en place
|
||||
progressive d'une **chaîne de publication logicielle**, que ce soit dans le monde
|
||||
professionnel ou dans la sphère privée (pour publier mon blog). C'est donc tout
|
||||
naturellement que je me suis tourné vers ce domaine passionnant qu'est le
|
||||
@ -27,9 +27,29 @@ formation. Nous commencerons par faire la corrélation entre les compétences
|
||||
attendues pour le *Titre Professionnel Administrateur Système DevOps* et le(s)
|
||||
projet(s) présenté(s) dans ce dossier. Après quoi nous continuerons avec le
|
||||
cahier des charges et les spécifications techniques de ce(s) dernier(s). \
|
||||
Nous continuerons par expliquer la démarche suivie pour accomplir le projet,
|
||||
Nous continuerons en expliquant la démarche suivie pour accomplir le projet,
|
||||
quelques réalisations effectuées et d'une situation de travail qui mérite
|
||||
d'être relevée.
|
||||
|
||||
Mais avant tout, nous tenons à présenter nos remerciements à quelques personnes.
|
||||
|
||||
## Conventions typographiques
|
||||
|
||||
Ce document suit certaines conventions de mise en forme pour faciliter la
|
||||
lecture :
|
||||
|
||||
* Les liens hypertextes apparaissent sous la forme suivante : [Titre du lien](
|
||||
https://perdu.com),
|
||||
* Les références vers d'autres sections sont indiquées comme suit : [référence
|
||||
vers un paragraphe spécifique, exemple avec DataScientest](#datascientest),
|
||||
* Les mots-clés essentiels d'une section sont en **gras**,
|
||||
* Les termes particuliers sont en *italique*,
|
||||
* Les noms de famille apparaissent avec de petites majuscules : Prénom \textsc{Nom},
|
||||
* Les extraits de code sont affichés dans un format distinct :
|
||||
|
||||
```bash {.numberLines}
|
||||
#!/usr/bin/env bash
|
||||
|
||||
echo "Bonjour tout le monde !"
|
||||
```
|
||||
|
||||
65
content/20_remerciements.md
Normal file
65
content/20_remerciements.md
Normal file
@ -0,0 +1,65 @@
|
||||
\newpage
|
||||
|
||||
# Remerciements
|
||||
|
||||
À **Madame Agnès \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 particulièrement les 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}.
|
||||
|
||||
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. Et pourtant ils ont donné ce qu'ils pouvaient.
|
||||
|
||||
Merci à :
|
||||
|
||||
* Hrubech \textsc{Hombessa},
|
||||
* Eliel \textsc{Moncada},
|
||||
* et Julien \textsc{Sabiols}.
|
||||
|
||||
J'imagine que derrière chaque personne il y a également **un ou une partenaire
|
||||
de vie**. Vous méritez de figurer dans ces lignes et d'avoir un grand
|
||||
MERCI !
|
||||
|
||||
## Aux membres de la « cohorte »
|
||||
|
||||
Je tiens à remercier également **l'ensemble des membres de la cohorte**. À
|
||||
ceux qui ont participé aux discussions, à ceux qui ont bien voulu échanger,
|
||||
à ceux qui ont accepté de répondre à des questions, à ceux qui ont partagé
|
||||
des difficultés ou encore des solutions, à ceux qui étaient eux-mêmes.
|
||||
|
||||
Une mention particulière aux personnes suivantes :
|
||||
|
||||
* à Maxime \textsc{Boulanghien},
|
||||
* à Michael \textsc{Lachand},
|
||||
* à Philippe \textsc{Risser-Maroix},
|
||||
* et à Dorian \textsc{Roly}.
|
||||
|
||||
## 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 !
|
||||
|
||||
À Richard \textsc{Dern} et son œil d'aigle pour les nombreuses relectures et
|
||||
fautes d'orthographes découvertes dans ce document.
|
||||
@ -1,22 +1,22 @@
|
||||
\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
|
||||
* Automatiser le déploiement d'une infrastructure dans le cloud
|
||||
* Compétence **n°1 : Automatiser la création de serveurs à l'aide de
|
||||
scripts**
|
||||
* Compétence **n°2 : Automatiser le déploiement d'une infrastructure**
|
||||
* Compétence **n°3 : Sécuriser l’infrastructure**
|
||||
* Compétence **n°4 : Mettre l’infrastructure en production dans le
|
||||
* Compétence **n°3 : Sécuriser l'infrastructure**
|
||||
* Compétence **n°4 : Mettre l'infrastructure en production dans le
|
||||
cloud**
|
||||
* Déployer en continu une application
|
||||
* Compétence **n°5 : Préparer un environnement de test**
|
||||
* Compétence **n°6 : Gérer le stockage des données**
|
||||
* Compétence **n°7 : Gérer des containers**
|
||||
* Compétence **n°8 : Automatiser la mise en production d’une
|
||||
* Compétence **n°8 : Automatiser la mise en production d'une
|
||||
application avec une plateforme**
|
||||
* Superviser les services déployés
|
||||
* Compétence **n°9 : Définir et mettre en place des statistiques de
|
||||
@ -25,8 +25,11 @@ DevOps* liste 11 compétences réparties en 3 catégories :
|
||||
* Compétence **n°11 : Échanger sur des réseaux professionnels
|
||||
éventuellement en anglais**
|
||||
|
||||
## Couverture
|
||||
|
||||
En utilisant les critères de performance fournis par chaque fiche de
|
||||
compétence, j'ai pu établir le tableau suivant :
|
||||
compétence, j'ai pu établir le tableau suivant permettant de voir les points à
|
||||
améliorer :
|
||||
|
||||
: Couverture de compétences du projet
|
||||
|
||||
@ -35,7 +38,7 @@ Compétence | Nbre critères perf. | Couverte ? | Note
|
||||
Compétence n°1 | 3/3 | Oui | EC2 / Terraform
|
||||
Compétence n°2 | 3/3 | Oui | Terraform
|
||||
Compétence n°3 | 2/2 | Oui | Staging, Vaultwarden, Let's Encrypt
|
||||
Compétence n°4 | **2**/3 | Oui | Terraform → « prod »
|
||||
Compétence n°4 | **2**/3 | Oui | Terraform → « prod »
|
||||
Compétence n°5 | 4/4 | Oui | Gitlab CI
|
||||
Compétence n°6 | **1**/3 | Partiellement | postgresql-ha, Velero
|
||||
Compétence n°7 | 4/4 | Oui | Docker
|
||||
@ -49,10 +52,16 @@ tests concernant le système de sauvegarde qui a été développé mais pas
|
||||
déployé, **faute de tests et de temps**.
|
||||
|
||||
La **compétence n°9** (Définir et mettre en place des statistiques de
|
||||
services) ne semble pas pertinente dans un projet où nous n'avons eu **aucun
|
||||
autre interlocuteur que le « mentor »**.
|
||||
services) n'a pu être clairement établie **faute d'interlocuteur autre que le
|
||||
« mentor »**.
|
||||
|
||||
La **compétence n°10** (Exploiter une solution de supervision) est **en lien
|
||||
avec la compétence précédente**, ce qui influe sur la pertinence des moniteurs
|
||||
mis en place dans la solution. Ce qui, à mon sens, ne résoud pas totalement
|
||||
cette compétence.
|
||||
mis en place dans la solution.
|
||||
|
||||
## 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.
|
||||
@ -1,5 +1,3 @@
|
||||
\newpage
|
||||
|
||||
# Cahier des charges
|
||||
|
||||
Dans le cadre d'une **formation, dans l'école DataScientest**, il a été
|
||||
@ -16,57 +14,58 @@ contraintes attenantes.
|
||||
|
||||
### Dans le cadre d'une formation
|
||||
|
||||
**[Datascientest]{#datascientest}** est une **école de formation** créée en
|
||||
**[DataScientest]{#datascientest}** est une **école de formation** créée en
|
||||
2017, située sur Paris et proposant **plus de 18 formations différentes**,
|
||||
dont *Administrateur Système DevOps*.
|
||||
|
||||
Plusieurs formats de formation existent parmi **Bootcamp**, continu et en
|
||||
alternance. **Ce projet est un exercice de fin de formation** proposé à tous
|
||||
les élèves de la « cohorte » (équivalent d'une classe).
|
||||
les élèves de la « cohorte » (équivalent d'une classe).
|
||||
|
||||
Plusieurs élèves se regroupent autour d'un projet auquel ils ont un **intérêt
|
||||
commun**.
|
||||
Plusieurs élèves se regroupent autour d'un projet pour lequel ils ont un
|
||||
**intérêt commun**.
|
||||
|
||||
### L'équipe DevU42 {#devu42}
|
||||
|
||||
Le **groupe DevU42** s'est formé le **17 octobre 2024**. Il est composé de
|
||||
**quatre étudiants** participant à la formation **Administrateur Système
|
||||
DevOps** de l’organisme de formation [DataScientest](#datascientest).
|
||||
DevOps** de l'organisme de formation [DataScientest](#datascientest).
|
||||
|
||||
Ses membres sont, par ordre alphabétique (prénom) :
|
||||
Ses membres sont, par ordre alphabétique :
|
||||
|
||||
* **Eliel MONCADA**
|
||||
* **Hrubech HOMBESSA**
|
||||
* **Julien SABIOLS**
|
||||
* Olivier DOSSMANN
|
||||
* **Hrubech \textsc{Hombessa}**,
|
||||
* **Eliel \textsc{Moncada}**,
|
||||
* **Julien \textsc{Sabiols}**,
|
||||
* et Olivier \textsc{Dossmann}.
|
||||
|
||||
Ils interviennent sur le projet en qualité d’**Administrateur Système DevOps**.
|
||||
Ils interviennent sur le projet en qualité d'**Administrateur Système DevOps**.
|
||||
|
||||
L'équipe a été supervisée et suivie par [**Jérémie Tarot** sous la
|
||||
dénomination de **« Mentor »**]{#mentor}. Et ainsi en sera-t-il dans le
|
||||
présent document.
|
||||
L'équipe a été supervisée et suivie par [**Jérémie \textsc{Tarot}** sous la
|
||||
dénomination de **« Mentor »**]{#mentor}. Et ainsi en sera-t-il
|
||||
dans le présent document.
|
||||
|
||||
### Organisation d'équipe
|
||||
|
||||
Pour s'organiser, l'équipe s'est doté de plusieurs outils et suivi quelques méthodologies.
|
||||
Pour s'organiser, l'équipe s'est dotée de plusieurs outils et suivi certaines
|
||||
méthodologies particulières.
|
||||
|
||||
#### Rapports hiérarchiques
|
||||
|
||||
L’équipe s'articule autour de membres ayant le **même degré de
|
||||
L'équipe s'articule autour de membres ayant le **même degré de
|
||||
responsabilités** et d'objectifs. Leur périmètre et leur champ d'action est
|
||||
similaire qu'il s'agisse de déterminer les tickets à prendre en charge, les
|
||||
axes de travail à rajouter au projet ou bien de nouveaux objectifs.
|
||||
|
||||
En cas de désaccord sur un sujet, une décision est prise à la majorité
|
||||
votante, avec pour ultime recours l’avis du [Mentor](#mentor).
|
||||
votante, avec pour ultime recours l'avis du [Mentor](#mentor).
|
||||
|
||||
#### Moyens de communication
|
||||
|
||||
La géolocalisation des membres de l'**équipe étant éparse**, plusieurs moyens
|
||||
de communication **en ligne** ont été nécessaires, parmi :
|
||||
de communication **en ligne** ont été nécessaires, parmi lesquels :
|
||||
|
||||
* Canaux de **discussions sur [Slack](https://slack.com/intl/fr-fr/)** fournis
|
||||
initialement par [Datascientest](#datascientest) :
|
||||
initialement par [DataScientest](#datascientest) :
|
||||
* canal du projet - **sep24_bootcamp_devops** : favorise l'échange
|
||||
entre [DevU42](#devu42) et le [Mentor](#mentor),
|
||||
* canal d'équipe - **devu42** : pour les **discussions techniques**,
|
||||
@ -96,7 +95,7 @@ la formation :
|
||||
Le budget alloué au projet est de **150€ mensuel** pour couvrir l'intégralité
|
||||
des frais issus de l'utilisation de **services Amazon** (AWS).
|
||||
|
||||
C'est une limite configurée par [Datascientest](#datascientest) sur l'espace
|
||||
C'est une limite configurée par [DataScientest](#datascientest) sur l'espace
|
||||
Amazon qu'ils nous partagent.
|
||||
|
||||
#### Temps
|
||||
@ -108,7 +107,7 @@ Au terme des 7 semaines, un support visuel de présentation du projet pour son
|
||||
lancement est attendu (Cf. [Section du présent chapitre sur les
|
||||
Livrables](#livrables)).
|
||||
|
||||
Après livraison, l’amélioration du projet est possible, bien qu'un dossier
|
||||
Après livraison, l'amélioration du projet est possible, bien qu'un dossier
|
||||
professionnel, un dossier de projet (ci-présent) et un support de présentation
|
||||
est demandé à chacun des [membres de l'équipe DevU42](#devu42).
|
||||
|
||||
@ -126,14 +125,14 @@ puisse **apprendre par la pratique**.
|
||||
|
||||
On imagine facilement le cadre :
|
||||
|
||||
> Une entreprise ayant une application de gestion d’utilisateur souhaite
|
||||
> Une entreprise ayant une application de gestion d'utilisateur souhaite
|
||||
> déployer et faire évoluer son service en favorisant les bonnes pratiques
|
||||
> suivies dans la culture DevOps.
|
||||
|
||||
De la même manière, l'entreprise pourrait rencontrer de nombreux
|
||||
**problèmes** :
|
||||
|
||||
* **Reprise d’activité** lente, coûteuse et avec pertes d’informations,
|
||||
* **Reprise d'activité** lente, coûteuse et avec pertes d'informations,
|
||||
* Service instable, **disponibilité** non garantie, **vulnérabilité** du
|
||||
service,
|
||||
* Capacité limitée pour encaisser des **augmentations** ponctuelles de la
|
||||
@ -143,20 +142,20 @@ service,
|
||||
développement pouvant être améliorées par l'**automatisation**,
|
||||
* Perte de temps et erreurs humaines liées aux actions manuelles,
|
||||
* Manque de **portabilité de l'application** d'un système à l'autre,
|
||||
* Lenteurs d’implémentation de **nouvelles fonctionnalités** avec
|
||||
* Lenteurs d'implémentation de **nouvelles fonctionnalités** avec
|
||||
interruptions de service.
|
||||
|
||||
### Application existante
|
||||
|
||||
Pour bien saisir l'état des lieux de ladite application, regardons de plus
|
||||
près.
|
||||
|
||||
### Application existante
|
||||
|
||||
L'**application FastAPI-Træfik** est fournie avec les éléments principaux
|
||||
suivants :
|
||||
L'**application 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
|
||||
Interface de gestion et d'enregistrement d'utilisateurs utilisant l'API du
|
||||
backend,
|
||||
* Base de données **postgreSQL**,
|
||||
* et **Traefik** (Proxy inverse).
|
||||
@ -170,26 +169,23 @@ développeurs de **lancer l'application localement**.
|
||||
**Une procédure manuelle existe** pour expliquer comment mettre l'application
|
||||
en production sur une machine serveur dédiée.
|
||||
|
||||
Mais **le projet voit plus loin**.
|
||||
|
||||
### Ambitions
|
||||
|
||||
En dehors des objectifs à atteindre, le projet vise à :
|
||||
Le projet **va plus loin** ; en dehors des objectifs à atteindre, il vise
|
||||
à :
|
||||
|
||||
* répondre aux problématiques de l’entreprise sur l'application existante par
|
||||
* répondre aux problématiques de l'entreprise sur l'application existante par
|
||||
**la méthode DevOps**,
|
||||
* répondre aux attentes de l’examen en matière de compétences attendues
|
||||
* répondre aux attentes de l'examen en matière de compétences attendues
|
||||
(méthode d'**apprentissage par la pratique**),
|
||||
* démontrer un **savoir-faire technique** sur les sujets principaux du DevOps,
|
||||
notamment vis à vis du Cloud **en utilisant AWS** (Amazon Web Services),
|
||||
* appliquer une méthode de travail qui optimise l’efficacité de la production
|
||||
* appliquer une méthode de travail qui optimise l'efficacité de la production
|
||||
des livrables.
|
||||
|
||||
C'est de ces **ambitions** que naîssent plusieurs objectifs spécifiques.
|
||||
|
||||
### Objectifs
|
||||
|
||||
D'après moi, ce projet à plusieurs objectifs :
|
||||
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**,
|
||||
@ -198,7 +194,7 @@ applications,
|
||||
* respecter un **budget** et des **limites de temps**,
|
||||
* **déployer en continu** un projet en passant par une phase de test, de
|
||||
pré-production puis de production,
|
||||
* penser à la **gestion de la donnée**,
|
||||
* penser à la **gestion des données**,
|
||||
* **superviser** un système déployé en production avec des tableaux de bord
|
||||
efficaces,
|
||||
* rendre un système **résilient** en prenant en compte les augmentations ET
|
||||
@ -208,7 +204,7 @@ humaines**,
|
||||
* procéder, de manière automatique, à des vérifications sur **la sécurité**
|
||||
des éléments produits et déployés,
|
||||
* favoriser une **collaboration** plus fluide entre les équipes de
|
||||
développements et les équipes d'opérations,
|
||||
développement et les équipes d'opération,
|
||||
* et obtenir des **alertes** en cas de défaillance d'un ou plusieurs éléments
|
||||
du système.
|
||||
|
||||
@ -216,19 +212,20 @@ Ce sont des **objectifs plutôt ambitieux pour un temps aussi court**. Un
|
||||
travail d'équipe et une organisation de cette dernière sont totalement
|
||||
primordiaux.
|
||||
|
||||
## Planification
|
||||
## Planification {#plan}
|
||||
|
||||
C'est par le [mentor](#mentor) que nous avons reçu le plan d'action pour les 7
|
||||
semaines de travail à venir et une liste de livrables attendus. Nous avons
|
||||
adapté ce plan d'action pour nous correspondre.
|
||||
Après quelques échanges avec le [mentor](#mentor) nous avons établi le plan
|
||||
d'action pour les 7 semaines de travail à venir ainsi qu'une liste de
|
||||
livrables attendus.
|
||||
|
||||
### Étapes de travail
|
||||
|
||||
Commençons par le détail de chaque étape. Pour les 7 semaines à venir.
|
||||
Le plan s'articule en étapes bien définies.
|
||||
|
||||
#### Semaine 1 : Cadrage
|
||||
|
||||
Sous le signe de l'**encadrement**, cette première semaine est dite « douce » :
|
||||
Sous le signe de l'**encadrement**, cette première semaine est dite
|
||||
« douce » :
|
||||
|
||||
* **réunion** de prise de contact, présentation et cadrage,
|
||||
* introduction de chaque membre du projet,
|
||||
@ -257,7 +254,7 @@ Nous prévoyons aussi :
|
||||
* une **configuration de Gitlab**, des principaux dépôts, des branches, etc.,
|
||||
* de s'organiser en équipe : définir des **méthodologies** à suivre.
|
||||
|
||||
#### Semaine 3 : Automatisation de la chaine d’intégration et de livraison
|
||||
#### Semaine 3 : Automatisation de la chaine d'intégration et de livraison
|
||||
|
||||
Une fois les outils principaux mis en place, il s'agit d'**automatiser**
|
||||
plusieurs parties :
|
||||
@ -276,7 +273,7 @@ pas encore clairement définie).
|
||||
|
||||
L'**adoption d'un workflow Git** pour la gestion des branches est la bienvenue.
|
||||
|
||||
#### Semaine 4 : Conception de l’infrastructure
|
||||
#### Semaine 4 : Conception de l'infrastructure
|
||||
|
||||
Vient ensuite la création de la **couche basse de l'infrastructure** :
|
||||
|
||||
@ -303,8 +300,8 @@ alertes](#semaine6), la gestion des données est importante et passe par :
|
||||
* et installer/configurer une solution de **sauvegarde** et de **restauration
|
||||
de données**.
|
||||
|
||||
C'est un sujet bien à part. D'où la possibilité de la **faire en parallèle**
|
||||
d'un autre.
|
||||
C'est un sujet bien à part. D'où la possibilité de **faire cette étape en
|
||||
parallèle** d'une autre.
|
||||
|
||||
#### Semaine 6 : Observabilité et alertes {#semaine6}
|
||||
|
||||
@ -316,7 +313,7 @@ gérer :
|
||||
l'application,
|
||||
* **choix des métriques** à utiliser pour la création de tableaux de bords,
|
||||
* création des **tableaux de bords**,
|
||||
* **définition des niveaux d'alertes** pour les métriques choisis,
|
||||
* **définition des niveaux d'alertes** pour les métriques choisies,
|
||||
* mise en place des **alertes**,
|
||||
* et envoi des alertes sur **les canaux choisis**.
|
||||
|
||||
@ -335,7 +332,7 @@ de l'application**. Il faudra donc :
|
||||
* et résoudre les derniers problèmes majeurs connus - s'ils existent.
|
||||
|
||||
C'est un **plan ambitieux** quand on considère que **les membres de l'équipe
|
||||
proviennent d'horizons et de formations variées**.
|
||||
proviennent d'horizons et de formations variés**.
|
||||
|
||||
### Livrables {#livrables}
|
||||
|
||||
@ -358,9 +355,13 @@ déploiement de l'application et de la génération des différents éléments
|
||||
Le projet **couvre beaucoup de situations** et **domaines** autour de
|
||||
**l'automatisation** et la **mise en production**, dans le Cloud, d'une
|
||||
application avec une **supervision** et une **mise à l'échelle** de cette
|
||||
dernière.
|
||||
dernière tout en gérant une **base de données**, le **stockage** et la
|
||||
**sauvegarde**.
|
||||
|
||||
En groupe, c'est un projet idéal pour suivre l'« **apprentissage par la
|
||||
pratique** » proposé par [DataScientest](#datascientest) et couvrir un maximum
|
||||
de compétences demandées pour le *Titre Professionnel d'Administrateur
|
||||
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.
|
||||
@ -11,8 +11,8 @@ outils utilisés.
|
||||
## Étude de l'application
|
||||
|
||||
Le dépôt Git contenant l'application **existait déjà**. Une étude des
|
||||
composants fournis par le projet a donc été nécessaire. Ce qui a été fournis
|
||||
aux développeurs également. Ce qui a permis d'en mesurer les implications.
|
||||
composants fournis a donc été nécessaire, ce qui a permis d'en mesurer les
|
||||
implications.
|
||||
|
||||
### Composants de l'application
|
||||
|
||||
@ -54,11 +54,12 @@ prendra connaissance des particularités de cette application.
|
||||
|
||||
### Points d'attentions
|
||||
|
||||
La **partie Frontend** permet de générer des fichiers dits « statiques », du
|
||||
**serverless** est envisageable. L'application, bien que faisant des appels à
|
||||
une API, fonctionne de manière **autonome**. Ce qui, a priori, facilite la
|
||||
préparation pour un déploiement. Cependant **un nom de domaine est inscrit en
|
||||
dur dans le fichier Dockerfile**, ce qui peut compliquer un déploiement sur
|
||||
La **partie Frontend** permet de générer des fichiers dits
|
||||
« statiques », du **serverless** est envisageable. L'application,
|
||||
bien que faisant des appels à une API, fonctionne de manière **autonome**. Ce
|
||||
qui, a priori, facilite la préparation pour un déploiement. Cependant les
|
||||
développeurs de l'application utilisent **un nom de domaine inscrit en dur
|
||||
dans le fichier Dockerfile**, ce qui peut compliquer un déploiement sur
|
||||
plusieurs domaines et environnements.
|
||||
|
||||
La **partie backend** s'appuie sur une base de données de type PostgreSQL. Elle
|
||||
@ -68,7 +69,8 @@ La **partie proxy** utilise actuellement **Traefik comme outil**. Ce qui n'est
|
||||
pas une obligation d'usage pour un déploiement en production.
|
||||
|
||||
Ces trois parties ont une influence sur le choix de l'infrastructure à mettre
|
||||
en place. Il reste cependant une **marge de manœuvre sur la partie proxy**.
|
||||
en place. Il reste cependant une **marge de manœuvre sur la partie proxy**. En
|
||||
effet il n'est pas obligatoire d'utiliser Træfik en production.
|
||||
|
||||
## Infrastructure
|
||||
|
||||
@ -104,12 +106,13 @@ Le schéma de la couche basse de l'infrastructure ressemble donc à :
|
||||
{width=100%}
|
||||
|
||||
C'est sur cette base qu'il est possible d'intégrer un environnement capable de
|
||||
déployer, automatiser et gérer des applications conteneurisées.
|
||||
|
||||
### Environnement Kubernetes
|
||||
|
||||
**Kubernetes** est un système capable de faire tourner des **applications
|
||||
C'est sur la couche basse qu'il est possible d'ajouter un environnement
|
||||
permettant d'intégrer, déployer, automatiser et gérer des applications
|
||||
conteneurisées. Pour cela nous choisissons **Kubernetes**.
|
||||
|
||||
Kubernetes est un système capable de faire tourner des **applications
|
||||
conteneurisées**, d'**automatiser le déploiement** et de gérer la mise à
|
||||
l'échelle (**auto-scaling**).
|
||||
|
||||
@ -147,10 +150,10 @@ EKS](./media/schema_contenu_eks.png){width=100%}
|
||||
* le **backend** de l'application (FastAPI),
|
||||
* et le **frontend** de l'application (en fichiers statiques).
|
||||
|
||||
Afin de permettre une livraison régulière de l'application, il va falloir
|
||||
automatiser au maximum les étapes entre la publication d'une nouvelle version
|
||||
de l'application et sa livraison. Puis son déploiement en production via une
|
||||
intervention humaine.
|
||||
Afin de permettre une **livraison régulière** de l'application, il va falloir
|
||||
**automatiser au maximum** les étapes entre la publication d'une nouvelle
|
||||
version de l'application et son déploiement en production en passant par la
|
||||
livraison en environnement de pré-production par une intervention humaine.
|
||||
|
||||
### Environnements
|
||||
|
||||
@ -165,9 +168,10 @@ sur **chaque machine des développeurs** à l'aide des outils fournis
|
||||
(Dockerfile, docker-compose du projet applicatif),
|
||||
* l'environnement de **test** : il est composé de l'**ensemble des Runner
|
||||
Gitlab** utilisés à l'intérieur de la chaîne d'intégration continue,
|
||||
* l'environnement de **pré-production** (appelé « **staging** ») : c'est
|
||||
l'infrastructure présentée ci-avant, appliquée dans AWS avec une configuration
|
||||
dite *plus légère* (moins de machines virtuelles EC2 par exemple),
|
||||
* l'environnement de **pré-production** (appelé « **staging** »
|
||||
) : c'est l'infrastructure présentée ci-avant, appliquée dans AWS avec
|
||||
une configuration dite *plus légère* (moins de machines virtuelles EC2 par
|
||||
exemple),
|
||||
* et l'environnement de **production** : c'est l'**infrastructure
|
||||
finale** ; celle qui est disponible aux utilisateurs finaux (les usagers).
|
||||
|
||||
@ -232,21 +236,23 @@ non-exhaustive :
|
||||
* les données brutes de l'application, stockées dans la **base de données
|
||||
postgreSQL**,
|
||||
* les **données sensibles** (mots de passe, clés d'accès),
|
||||
* les **copies de sauvegardes** des données elle-même,
|
||||
* les **copies de sauvegardes** des données elles-mêmes,
|
||||
* et les **fichiers de journalisation** des services en production.
|
||||
|
||||
Regardons pour chacun des points de cette liste où se situe le stockage.
|
||||
|
||||
#### Stockage
|
||||
|
||||
En reprenant les éléments précédent, nous avons :
|
||||
Les éléments précédents donnent lieu au tableau suivant :
|
||||
|
||||
* des **dépôts Gitlab** pour notre code applicatif ET les dépôts de
|
||||
l'infrastructure, gérés par Gitlab,
|
||||
* un **stockage AWS EBS** (Elastic Block Store) pour la base de données
|
||||
postgreSQL,
|
||||
* et un **stockage AWS S3** (Simple Storage Service) pour les copies de
|
||||
sauvegardes.
|
||||
: Données présentes et leur lieu de stockage
|
||||
|
||||
Données | Stockage
|
||||
-----|-----
|
||||
Code applicatif | **dépôt Gitlab**
|
||||
Code de l'infrastructure | **dépôt Gitlab**
|
||||
Base de données postgreSQL | **stockage AWS EBS** (Elastic Block Store)
|
||||
Sauvegardes | **stockage AWS S3** (Simple Storage Service)
|
||||
|
||||
Cela devrait être suffisant pour stocker les diverses données disponibles.
|
||||
|
||||
@ -267,17 +273,17 @@ postgreSQL-HA](./media/postgresql-ha.png){height=50%}
|
||||
Les dépôts de version utilisés étant sur Gitlab, [service qui se targue d'être
|
||||
entre 99% et 100% disponible](
|
||||
https://handbook.gitlab.com/handbook/engineering/monitoring/#historical-service-availability)
|
||||
, une **sauvegarde dite « préventive » mensuelle** suffit.
|
||||
, une **sauvegarde dite « préventive » mensuelle** suffit.
|
||||
|
||||
En revanche **la production**, même en **étant un service en haute
|
||||
disponibilité**, doit fournir au moins **une sauvegarde 1 fois par jour**.
|
||||
L'outil de sauvegarde choisi est **Velero**. Compatible avec l'environnement
|
||||
Kubernetes et permettant aussi de sauver l'état du cluster à un moment donné.
|
||||
Son outil en ligne de commande permet de gérer les sauvegardes mais aussi les
|
||||
restaurations de ces dernières.
|
||||
Kubernetes et permettant aussi de **sauver l'état du cluster** à un instant
|
||||
*T*. Son outil en ligne de commande permet de gérer les sauvegardes mais aussi
|
||||
les restaurations de ces dernières.
|
||||
|
||||
Comme énoncé précédemment, les sauvegardes du cluster seront mises **sur un
|
||||
stockage AWS S3** (dit « bucket S3 »).
|
||||
stockage AWS S3** (dit « bucket S3 »).
|
||||
|
||||
\newpage
|
||||
|
||||
@ -291,8 +297,9 @@ Le fonctionnement de Velero dans ce projet est visible sur le schéma suivant.
|
||||
|
||||
### Supervision
|
||||
|
||||
Le choix se porte sur **Datadog** pour sa **souplesse** et sa capacité à
|
||||
proposer des **services supplémentaires de manière progressive**.
|
||||
Le choix de l'outil de supervision se porte sur **Datadog** pour sa
|
||||
**souplesse** et sa capacité à proposer des **services supplémentaires de
|
||||
manière progressive**.
|
||||
|
||||
Le fonctionnement semble simple : installation d'agents Datadog dans le
|
||||
système Kubernetes pour receuillir de nombreuses informations. Comme peut le
|
||||
@ -303,18 +310,29 @@ montrer le schéma suivant.
|
||||
{height=70%}
|
||||
|
||||
Une fois installé, l'agent Datadog recueille et envoie les informations sur
|
||||
les serveurs officiels de l'entreprise Datadog qui en gère le stockage et
|
||||
l'accès.
|
||||
|
||||
#### Surveillance (monitoring)
|
||||
|
||||
Pour le monitoring, on veillera à suivre des **indicateurs simples** comme
|
||||
l'**utilisation CPU** et la **mémoire vive** des instances AWS EC2 (Elastic
|
||||
Compute Cloud) utilisées.
|
||||
L'utilisation de Datadog donne accès à de nombreux moniteurs pré-configurés.
|
||||
|
||||
On veillera à utiliser des **indicateurs simples** comme l'**utilisation CPU**
|
||||
et la **mémoire vive** des instances AWS EC2 (Elastic Compute Cloud) utilisées.
|
||||
|
||||
Il y a également :
|
||||
|
||||
* le **nombre de pods utilisés** par l'instance EC2,
|
||||
* et la **disponibilité du service** de l'application API-Utilisateurs.
|
||||
* et la **disponibilité du service** de l'application *API Utilisateurs*.
|
||||
|
||||
Cependant ces moniteurs doivent s'agrémenter d'**alertes**.
|
||||
Cependant ces moniteurs sont insuffisants. On pourrait ajouter :
|
||||
|
||||
* le temps de réponse de l'API,
|
||||
* le nombre de requêtes par seconde sur l'API,
|
||||
* même chose pour le nombre de requêtes sur la base de données,
|
||||
* le nombre d'erreurs 500 retournées par le frontend et le backend,
|
||||
* etc.
|
||||
|
||||
#### Alertes
|
||||
|
||||
@ -328,21 +346,36 @@ utilisons donc le [**Gitlab ChatOps**](https://docs.gitlab.com/ci/chatops/).
|
||||
|
||||
En suivant toutes ces indications, nous devrions avoir une base stable et
|
||||
saine pour constuire une supervision correcte de l'application
|
||||
API-Utilisateurs.
|
||||
*API Utilisateurs*.
|
||||
|
||||
### Sécurité
|
||||
|
||||
Au niveau de la sécurité, **vaste sujet**, nous partirons de peu
|
||||
d'éléments :
|
||||
Au niveau de la sécurité, **vaste sujet**, nous partirons de ces
|
||||
éléments :
|
||||
|
||||
* lancement de **tests** sur le **code applicatif**,
|
||||
* lancement de **tests SAST** (Static application security testing), sur Terraform notamment,
|
||||
* et utilisation d'un **coffre fort numérique** pour les mots de passes et clés d'accès en tous genres.
|
||||
* lancement de **tests SAST** (Static application security testing), sur
|
||||
Terraform notamment,
|
||||
* et utilisation d'un **coffre fort numérique** pour les mots de passes et
|
||||
clés d'accès en tous genres.
|
||||
|
||||
Le coffre-fort choisi est **Vaultwarden**.
|
||||
|
||||
Il y a beaucoup à faire pour **améliorer la sécurité**. Ceci est un **processus continu** à faire tout au long du **suivi et la maintenance du projet**.
|
||||
Il y a beaucoup à faire pour **améliorer la sécurité**. Ceci est un
|
||||
**processus continu** à faire tout au long du **suivi et la maintenance du
|
||||
projet**.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Les spécifications techniques étant établies, nous allons pouvoir nous concentrer sur la démarche suivie pour mettre en place le projet. C'est à dire comment nous allons atteindre les objectifs du cahier des charges à l'aide des solutions choisies ici-même.
|
||||
Les spécifications techniques décrivent bien l'application, composée de 3
|
||||
éléments (backend, frontend et base de données) qui s'intégreront bien dans
|
||||
l'environnement Kubernetes installé sur l'infrastructure posée dans le cloud
|
||||
AWS.
|
||||
|
||||
On retient ainsi un déploiement automatique dans le Cloud d'une infrastructure
|
||||
prête à accueillir à la fois l'application et d'autres services tierces comme
|
||||
la supervision avec Datadog et les sauvegardes à l'aide de Velero.
|
||||
|
||||
La sécurité aura cette spécificité de devoir être régulièrement vérifiée,
|
||||
maintenue et améliorée au fil du temps. C'est donc un processus continu dont
|
||||
la réussite dépend beaucoup de la discipline et la régularité.
|
||||
@ -7,7 +7,7 @@ application dans le Cloud. C'est une **nouvelle équipe**, dans un **nouvel
|
||||
environnement** avec une application inconnue et **des savoirs à acquérir**.
|
||||
|
||||
En pareille situation, c'est tout un **écosystème DevOps** qu'il faut mettre
|
||||
en place. Nous allons donc avant tout parler de **méthodologie utilisées**
|
||||
en place. Nous allons donc avant tout parler des **méthodologies utilisées**
|
||||
pour ce faire, puis des **outils utilisés** et enfin aborder le sujet de
|
||||
**collaborations** avec d'autres équipes.
|
||||
|
||||
@ -15,13 +15,13 @@ pour ce faire, puis des **outils utilisés** et enfin aborder le sujet de
|
||||
|
||||
### Agile
|
||||
|
||||
Le choix d'une **méthodologie agile** « basique » s'est offerte à nous,
|
||||
Le choix d'une **méthodologie agile** « basique » s'est offerte à nous,
|
||||
notamment par :
|
||||
|
||||
* des **comptes-rendus journaliers rapides de 10mn** en respectant les points
|
||||
suivants :
|
||||
* ce que j'ai fais hier,
|
||||
* ai-je rencontré un/des problème(s) qui vaille(nt) d'être cité(s),
|
||||
* ce que j'ai fait hier,
|
||||
* ai-je rencontré un/des problème(s) qui vaut(valent) d'être cité(s),
|
||||
* ce que je compte faire aujourd'hui,
|
||||
* la **création de jalons** avec un ensemble de tâches sur une période d'une
|
||||
semaine,
|
||||
@ -30,9 +30,6 @@ semaine,
|
||||
* et l'utilisation d'un **tableau façon Kanban** (méthode de gestion de
|
||||
production en flux tendus).
|
||||
|
||||
C'est ainsi que les **jalons** ont parsemés la durée du projet en **objectifs à
|
||||
atteindre**.
|
||||
|
||||
### Jalons
|
||||
|
||||
Les **jalons** (milestones en anglais) permettent de savoir si le projet
|
||||
@ -46,13 +43,12 @@ wiki, etc.), **cahier des charges**,
|
||||
* Étape 5 (avec 4) : **Supervision** (observabilité, alertes),
|
||||
* Étape 6 : **extras** (s'il reste du temps).
|
||||
|
||||
Les jalons n'étaient pas suffisants, d'autres éléments ont dû être pris en
|
||||
compte.
|
||||
|
||||
### Choix de standards et normes
|
||||
|
||||
Plusieurs standards/normes ont été choisies pour **rassembler plutôt que
|
||||
diviser le groupe** : SemVer, Git OneFlow et Conventional commit.
|
||||
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
|
||||
|
||||
@ -142,7 +138,7 @@ l'exemple montre une référence vers le ticket #18 du dépôt nommé *projet*.
|
||||
|
||||
## Outils
|
||||
|
||||
Au delà d'une à plusieurs méthodologies/normes/standards, nous avons utilisés
|
||||
Au delà d'une à plusieurs méthodologies/normes/standards, nous avons utilisé
|
||||
des outils afférents.
|
||||
|
||||
### Nom de domaine
|
||||
@ -153,8 +149,8 @@ location d'un nom de domaine : **devu42.fr**.
|
||||
|
||||
Ce domaine fait référence à notre cursus de DevOps dans un centre de formation
|
||||
nommé **DevU**niversity. Le **nombre 42** est un chiffre connu lié aux
|
||||
ouvrages de Douglas Adams dans sa trilogie en 5 volumes de « H2G2, Guide du
|
||||
Voyageur Galactique ».
|
||||
ouvrages de Douglas Adams dans sa trilogie en 5 volumes de « H2G2, Guide
|
||||
du Voyageur Galactique ».
|
||||
|
||||
Nous avons ainsi pu avoir des **noms de domaines spécifiques** pour :
|
||||
|
||||
@ -233,8 +229,8 @@ d'appliquer à nouveau le même workflow.
|
||||
## Cas d'une collaboration inter-équipe {#collab}
|
||||
|
||||
Dans le cadre de nos diverses **réflexions** nous avons eu un contact **avec
|
||||
l'équipe** qui se nomme **« Team Matrix »** dont le sujet était le déploiement
|
||||
de serveurs Matrix en haute disponibilité.
|
||||
l'équipe** qui se nomme **« Team Matrix »** dont le sujet était le
|
||||
déploiement de serveurs Matrix en haute disponibilité.
|
||||
|
||||
Nous avons échangé sur le **sujet de la promotion des versions entre
|
||||
environnements**. Maxime, de la Team Matrix, et moi avons principalement
|
||||
@ -248,8 +244,9 @@ https://codefresh.io/blog/how-to-model-your-gitops-environments-and-promote-rele
|
||||
L'idée de l'article, en quelques mots, est de **favoriser l'utilisation d'un
|
||||
dossier par environnement** plutôt qu'utiliser une branche Git pour chaque
|
||||
environnement. Il conseille également de faire la promotion des versions entre
|
||||
ces différents environnements/dossiers. Avec un protocole à suivre par les «
|
||||
humains » pour limiter de trop nombreuses promotions logicielles en même temps.
|
||||
ces différents environnements/dossiers. Avec un protocole à suivre par les
|
||||
« humains » pour limiter de trop nombreuses promotions logicielles
|
||||
en même temps.
|
||||
|
||||
Pour reprendre le schéma de l'article :
|
||||
|
||||
@ -257,7 +254,7 @@ Pour reprendre le schéma de l'article :
|
||||
versions](./media/article_schema_promotion.png){width=100%}
|
||||
|
||||
Après moultes discussions, **nous sommes tombés d'accord** sur quelques
|
||||
points, parmi :
|
||||
points, notamment :
|
||||
|
||||
* **ne pas utiliser une branche par environnement**,
|
||||
* essayer au maximum d'**avoir des dépôts indépendants** (favoriser la
|
||||
@ -279,9 +276,9 @@ de sécurité**, des **tests du code**, vérification de la **couverture de
|
||||
code** et **tests sur la compilation** - éventuelle - de l'outil et/ou des
|
||||
**images Docker** puis **publication sur un registre**,
|
||||
* avoir une gestion de chacun de ces dépôts d'**un système de versionnement**
|
||||
(les fameuses « releases »),
|
||||
(les fameuses « releases »),
|
||||
* avoir la **même chose pour chaque module Terraform** que nous avons fabriqué
|
||||
(par exemple notre module « networking »),
|
||||
(par exemple notre module « networking »),
|
||||
* puis utiliser, dans un dépôt **infra** par exemple, seulement les versions
|
||||
de nos modules (situés indépendamment sur des registres),
|
||||
* de là on peut imaginer :
|
||||
@ -293,12 +290,11 @@ de nos modules (situés indépendamment sur des registres),
|
||||
* ajouter des **tests de sécurité des images** (comme la somme de contrôle) avant
|
||||
utilisation dans d'autres dépôts.
|
||||
|
||||
À noter que Maxime et moi étions également arrivés sur le fait qu'il y a déjà
|
||||
2 types de promotions dans tout cela :
|
||||
Maxime et moi avons également relevé que lorsqu'on parle de promotions dans
|
||||
l'infrastructure on peut imaginer 2 types de promotions :
|
||||
|
||||
* la promotion des versions des logiciels/modules/charts utilisés,
|
||||
* et la promotion des configurations de ces derniers au sein de nos
|
||||
infrastructures.
|
||||
* la promotion de versions concernant les logiciels/modules/charts utilisés,
|
||||
* et la promotion de configurations pour différentes infrastructures.
|
||||
|
||||
C'est un autre sujet très intéressant que nous ne détaillerons pas ici.
|
||||
|
||||
@ -79,12 +79,11 @@ pourquoi ne pas **utiliser Git lui-même à l'aide d'un commit sur le dépôt
|
||||
suivant** ? Ainsi, sans outils supplémentaires, nous pouvons lier les
|
||||
dépôts entre eux.
|
||||
|
||||
En suivant cette logique, nous obtenons le schéma représentant la pipeline de
|
||||
chaque dépôt :
|
||||
|
||||
```{=latex}
|
||||
\begin{sidewaysfigure}
|
||||
|
||||
En suivant cette logique, nous obtenons le schéma représentant la pipeline de
|
||||
chaque dépôt~:
|
||||
|
||||
\includegraphics{./media/schema_3_pipelines.png}
|
||||
\caption{Schéma des 3 pipelines}
|
||||
\end{sidewaysfigure}
|
||||
@ -137,7 +136,7 @@ inform-charts:
|
||||
**Le code a dû être modifié (raccourcissement des lignes) pour les fins de
|
||||
rédaction du présent document**.
|
||||
|
||||
La **ligne 27 à 29** posent un tag sur le dépôt **charts** en mettant
|
||||
Les **ligne 27 à 29** posent un tag sur le dépôt **charts** en mettant
|
||||
simplement à jour les versions utilisées du backend et du frontend dans les
|
||||
charts Helm sur le registre Gitlab.
|
||||
|
||||
@ -376,6 +375,13 @@ Deux expériences variées et différentes qui s'imbriquent pourtant dans le
|
||||
processus de production logicielle et de livraison continue. Il y a beaucoup
|
||||
de choses à dire sur chacun des sujets, tellement ils sont passionnants. Ils
|
||||
amènent également à prendre des initiatives et tester localement des outils.
|
||||
Nous parlerons d'ailleurs dans le prochain chapitre d'une situation de travail
|
||||
ayant amené à faire une recherche. Nous pourrons ainsi voir plus en détail le
|
||||
processus de travail suivi afin d'aboutir à ce résultat.
|
||||
|
||||
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,23 +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, a permis d'**acquérir tout au long de ces derniers
|
||||
mois**.
|
||||
|
||||
Ainsi **je ressors riche de nouvelles expériences**, de **nouveaux outils**,
|
||||
de **nouvelles méthodes** et de **nouveaux collaborateurs** dans un monde sans
|
||||
cesse grandissant qu'est **le monde du DevOps**.
|
||||
|
||||
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 !
|
||||
@ -3,14 +3,14 @@
|
||||
# Situation de travail
|
||||
|
||||
L'exercice demandé dans ce chapitre est particulier pour moi. Il est demandé,
|
||||
je cite, « **une description d'une situation de travail ayant nécessité une
|
||||
recherche effectuée par le candidat durant le projet** ».
|
||||
je cite, « **une description d'une situation de travail ayant nécessité
|
||||
une recherche effectuée par le candidat durant le projet** ».
|
||||
|
||||
Pour bien saisir **ma façon de travailler**, je pense qu'il est nécessaire de
|
||||
Pour saisir **la méthodologie choisie**, je pense qu'il est nécessaire de
|
||||
décrire une situation complète. Nous allons poser le contexte, faire l'état
|
||||
des lieux puis suivre le cheminement parcouru pour atteindre l'objectif.
|
||||
des lieux puis suivre la démarche pour atteindre l'objectif.
|
||||
|
||||
## Contexte
|
||||
## Contexte et état des lieux
|
||||
|
||||
Du projet émane un besoin d'**avoir du temps de calcul pour les pipelines**.
|
||||
|
||||
@ -22,8 +22,6 @@ utilisons Gitlab**, ce sont donc des Gitlab Runner que nous visons.
|
||||
Où les installer ? Comment ? **De quelles ressources
|
||||
disposons-nous ?**
|
||||
|
||||
## État des lieux
|
||||
|
||||
**Nous utilisons Gitlab** qui propose, dans sa version gratuite, une **limite
|
||||
de temps de calcul**. Une fois le seuil atteint : il faut trouver une
|
||||
solution alternative aux **machines de Gitlab, payantes**.
|
||||
@ -41,7 +39,7 @@ et un **environnement Kubernetes** pour **déployer des Gitlab Runner**.
|
||||
|
||||
Après en avoir discuté en groupe, je me suis attelé à la tâche. Régulièrement.
|
||||
|
||||
## Cheminement
|
||||
## Démarche
|
||||
|
||||
### Retranscription préalable
|
||||
|
||||
@ -77,14 +75,14 @@ Et c'est ce que j'ai fait :
|
||||
|
||||
* **demande à un ami DevSecOps** si je pouvais l'interpeller de temps en temps
|
||||
sur l'un ou l'autre sujet,
|
||||
* achat du **livre « Kubernetes - Guide pratique »** aux éditions
|
||||
* achat du **livre « Kubernetes - Guide pratique »** aux éditions
|
||||
\textsc{O'Reilly},
|
||||
* recherche, infructueuse, **à la médiathèque** : le rayon informatique
|
||||
est maigre,
|
||||
* recherche sur le domaine du DevOps **sur Internet** avec une **grande
|
||||
lecture initiale** de [**Stéphane Robert** (Devenez expert DevOps et maîtrisez
|
||||
ses outils)](https://blog.stephane-robert.info/){#stephane-robert} (j'ai
|
||||
repris le titre du site tel quel).
|
||||
lecture initiale** de [**Stéphane \textsc{Robert}** (Devenez expert DevOps et
|
||||
maîtrisez ses outils)](https://blog.stephane-robert.info/){#stephane-robert}
|
||||
(j'ai repris le titre du site tel quel).
|
||||
|
||||
{height=35%}
|
||||
@ -94,9 +92,10 @@ pratique](./media/livre-oreilly.jpg){height=35%}
|
||||
### Point de départ
|
||||
|
||||
Grâce à la lecture de quantité d'articles sur le blog de [Stéphane
|
||||
Robert](#stephane-robert), notamment la [série d'article sur « Mon nouveau
|
||||
Homelab DevOps](https://blog.stephane-robert.info/docs/homelab/introduction/)
|
||||
(Cf. https://blog.stephane-robert.info/docs/homelab/introduction/) et la
|
||||
\textsc{Robert}](#stephane-robert), notamment la [série d'article sur
|
||||
« Mon nouveau Homelab DevOps »](
|
||||
https://blog.stephane-robert.info/docs/homelab/introduction/) (Cf.
|
||||
https://blog.stephane-robert.info/docs/homelab/introduction/) et la
|
||||
**Roadmap de son parcours de formation DevSecOps** (Cf.
|
||||
https://blog.stephane-robert.info/docs/#la-roadmap), j'ai pu établir des
|
||||
**objectifs à court terme** et des étapes de sujets à aborder comme :
|
||||
@ -105,7 +104,7 @@ https://blog.stephane-robert.info/docs/#la-roadmap), j'ai pu établir des
|
||||
* **le GitOps avec** un outil tel que **FluxCD**.
|
||||
|
||||
{width=100%}
|
||||
\textsc{Robert}](./media/screenshot_stephane-robert.png){width=100%}
|
||||
|
||||
### Recherches
|
||||
|
||||
@ -115,9 +114,11 @@ Je pars souvent de **sites de référence ou de sites que j'ai déjà utilisé**
|
||||
plusieurs fois dans le passé. Le sujet de la virtualisation a donc donné lieu
|
||||
à **quelques recherches sur des sites déjà connus** :
|
||||
|
||||
* Le **wiki d'ArchLinux** et sa catégorie « **Virtualization** » :
|
||||
* Le **wiki d'ArchLinux** et sa catégorie
|
||||
« **Virtualization** » : \
|
||||
https://wiki.archlinux.org/title/Category:Virtualization,
|
||||
* Le blog précédemment cité de [**Stéphane Robert**](#stephane-robert).
|
||||
* Le blog précédemment cité de [**Stéphane
|
||||
\textsc{Robert}**](#stephane-robert).
|
||||
|
||||
Je me suis concentré sur l'outil conseillé par **mon contact DevSecOps** qui
|
||||
utilise QEMU/KVM/Libvirt pour l'émulation d'une machine complète. J'ai lu et
|
||||
@ -143,8 +144,8 @@ https://odtre.gitlab.io/doc/virtualisation/.
|
||||
plusieurs systèmes d'exploitation** avant de les adopter et les déployer sur
|
||||
notre infrastructure.
|
||||
|
||||
{width=100%}
|
||||
{width=100%}
|
||||
|
||||
\newpage
|
||||
|
||||
@ -158,8 +159,9 @@ nécessaires** pour déployer et utiliser **FluxCD** :
|
||||
|
||||
* la **page d'installation officielle**, Cf.
|
||||
https://fluxcd.io/flux/installation/,
|
||||
* les différents « **bootstrap** » possibles en fonction d'un **fournisseur de
|
||||
dépôt Git** choisi, Cf. https://fluxcd.io/flux/installation/bootstrap/,
|
||||
* 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 ».
|
||||
@ -178,3 +180,15 @@ Bien que pour la plupart des outils, une fois choisis, la documentation
|
||||
officielle de ces outils semble suffire pour leur installation et leur
|
||||
utilisation. Les **bonnes pratiques** restent **dans les articles des
|
||||
blogueurs** et autres joyeux rédacteurs en tous genres.
|
||||
|
||||
Le blog de [Stéphane \textsc{Robert}](#stephane-robert) est un bon point de
|
||||
départ qui ne dispense absolument pas de recherches supplémentaires. Des
|
||||
outils tels que QEMU/KVM/libvirt pour la virtualisation sont de bonnes idées
|
||||
pour tester les outils de DevOps dans un environnement isolé. Tout comme
|
||||
FluxCD qui permet d'automatiser, à l'intérieur d'un environnement Kubernetes,
|
||||
la recherche de nouvelles versions de ses applications.
|
||||
|
||||
La méthodologie ayant été fructueuse, elle sera dans mes priorités pour les
|
||||
années à venir. Il faudra cependant être attentif au temps passé à la
|
||||
publication de ses recherches qui, bien qu'il soit un investissement sur long
|
||||
terme, consomme un temps certain à la rédaction et la mise en page.
|
||||
35
content/90_conclusion.md
Normal file
35
content/90_conclusion.md
Normal file
@ -0,0 +1,35 @@
|
||||
\newpage
|
||||
|
||||
# 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.
|
||||
Reference in New Issue
Block a user