fix(content): syntax, language, etc. after comments
This commit is contained in:
parent
d9ee716c85
commit
31631d6e87
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
|
||||
|
||||
@ -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 !"
|
||||
```
|
||||
|
||||
|
||||
@ -2,14 +2,7 @@
|
||||
|
||||
# Remerciements
|
||||
|
||||
Avant toute chose il y a une personne sans qui cette aventure n'aurait pas été
|
||||
possible : **Agnès \textsc{Schweitzer}**. Elle a été l'**immense
|
||||
soutien** derrière les petites mains qui écrivent ces lignes. Présente quand
|
||||
les choses n'allaient pas, quand la voie semblait sans issue et que l'iceberg
|
||||
s'approchait du bateau ! En sa présence l'**humilité** n'a qu'à bien se
|
||||
tenir !
|
||||
|
||||
À **Madame \textsc{Schweitzer}** pour ses **conseils**, son aide
|
||||
À **Madame Agnès \textsc{Schweitzer}** pour ses **conseils**, son aide
|
||||
**précieuse**, sa **présence d'esprit** et son **exceptionnelle
|
||||
intelligence** : MERCI !
|
||||
|
||||
@ -20,23 +13,12 @@ autre ligne. C'est ce que permet l'organisme de formation **DataScientest**
|
||||
au travers de ses nombreux parcours proposés aux personnes qui, comme moi,
|
||||
souhaitent **changer de métier**.
|
||||
|
||||
Je remercie Sarah \textsc{Bouras} d'avoir été mon premier contact avec cet
|
||||
organisme. Elle a été **à l'écoute**, soucieuse de répondre **avec précision
|
||||
et parcimonie** à toutes mes questions et de me rassurer sur les sujets qui
|
||||
m'inquiétaient.
|
||||
Je remercie particulièrement les personnes suivantes pour leur **écoute**,
|
||||
leur **professionnalisme** et leur souci de réponses claires :
|
||||
|
||||
C'est ensuite Benjamin \textsc{Fiche}, **chef de cohorte**, qui a pris le pas
|
||||
en répondant **consciencieusement** à toutes mes questions ; même les plus
|
||||
triviales/simplettes/absurdes. Il a toujours fait preuve d'**un
|
||||
professionnalisme hors pair** et je me devais de le souligner.
|
||||
|
||||
Nous avons également Jérémie \textsc{Tarot}, notre **passionnant - et
|
||||
passionné** - Mentor qui détient une **connaissance infinie** des outils
|
||||
et des pratiques du monde du DevOps. Son savoir nous a donné de **multiples
|
||||
pistes** quand nous étions bloqués. Ses conseils ont été spécifiquement utiles
|
||||
lorsque les ressources venaient à manquer dans le projet, que ce soit en terme
|
||||
de ressources humaines ou de ressources temporelles. Il a **cru en nous** ; et
|
||||
ceci représente une aide précieuse.
|
||||
* Sarah \textsc{Bouras},
|
||||
* Benjamin \textsc{Fiche},
|
||||
* et Jérémie \textsc{Tarot}.
|
||||
|
||||
Je remercie également **l'ensemble de l'équipe DataScientest** pour leur
|
||||
patience et leur savoir-vivre au regard de mes nombreux retours sur les cours,
|
||||
@ -46,52 +28,31 @@ les examens et les machines virtuelles fournies.
|
||||
|
||||
Chaque membre de l'équipe a ses **difficultés**, une **vie sociale et
|
||||
familiale** prenante, des **obligations** et des **responsabilités** à côté de
|
||||
la formation.
|
||||
la formation. Et pourtant ils ont donné ce qu'ils pouvaient.
|
||||
|
||||
Pris à part, nous avons **chacun nos particularités**. Ensemble ces problèmes
|
||||
étaient amoindris. Nous aurions pu faire mieux et plus loin. Mais nous avons
|
||||
fait. Et rien que pour cela je remercie l'équipe d'y être parvenu.
|
||||
Merci à :
|
||||
|
||||
À Eliel \textsc{Moncada} pour ses **trouvailles** Web et sa **patience** sur
|
||||
les schémas visuels qui prennent un temps considérable !
|
||||
|
||||
À Hrubech \textsc{Hombessa} pour sa **qualité d'échange** sur des **sujets
|
||||
pointus** et la **pertinence** de ses questions.
|
||||
|
||||
À Julien \textsc{Sabiols} pour sa **détermination**, son **travail acharné**,
|
||||
son **intelligence** et son énorme **humilité**. Il a su être un partenaire
|
||||
de pair-programming **brillant** avec un **esprit affûté**. C'est rare. Et
|
||||
très appréciable !
|
||||
* Hrubech \textsc{Hombessa},
|
||||
* Eliel \textsc{Moncada},
|
||||
* et Julien \textsc{Sabiols}.
|
||||
|
||||
J'imagine que derrière chaque personne il y a également **un ou une partenaire
|
||||
de vie** qui a facilité l'organisation et la disponibilité autour de la
|
||||
formation. Pour ces personnes **cachées dans l'ombre** : MERCI !
|
||||
Vous méritez de figurer dans ces lignes.
|
||||
de vie**. Vous méritez de figurer dans ces lignes et d'avoir un grand
|
||||
MERCI !
|
||||
|
||||
## Aux membres de la « cohorte »
|
||||
## Aux membres de la « cohorte »
|
||||
|
||||
Je tiens à remercier également **l'ensemble des membres de la cohorte**. À
|
||||
ceux qui ont participé aux discussions, à ceux qui ont bien voulu échanger,
|
||||
à ceux qui ont accepté de répondre à des questions, à ceux qui ont partagé
|
||||
des difficultés ou encore des solutions, à ceux qui étaient eux-même.
|
||||
des difficultés ou encore des solutions, à ceux qui étaient eux-mêmes.
|
||||
|
||||
Une mention particulière aux personnes suivantes (ordre alphabétique -
|
||||
prénom) :
|
||||
Une mention particulière aux personnes suivantes :
|
||||
|
||||
* à Dorian \textsc{Roly} pour nos **échanges intéressants** sur de multiples
|
||||
technologies et sur les archétypes des personnes dans l'informatique,
|
||||
* à Maxime \textsc{Boulanghien} pour sa **sérénité**, son **implication** et
|
||||
son efficacité sur des sujets dûments travaillés ; notamment la promotion
|
||||
logicielle au sein d'une automatisation complète de déploiement d'une
|
||||
infrastructure,
|
||||
* à Michael \textsc{Lachand} pour nos discussions sur **l'importance de
|
||||
l'individu** au sein du domaine professionnel plutôt que des chiffres et des
|
||||
compétences seules ; mais aussi des difficultés apportés par notre Société
|
||||
moderne à ce sujet,
|
||||
* et enfin à Philippe \textsc{Risser-Maroix} avec qui j'ai pu discuter de
|
||||
**notions informatiques poussées** et de Logiciel Libre sans me sentir seul à
|
||||
ce sujet ; sa sensibilité au sujet de la **sécurité informatique** est un
|
||||
point fort !
|
||||
* à Maxime \textsc{Boulanghien},
|
||||
* à Michael \textsc{Lachand},
|
||||
* à Philippe \textsc{Risser-Maroix},
|
||||
* et à Dorian \textsc{Roly}.
|
||||
|
||||
## Et les autres
|
||||
|
||||
@ -100,6 +61,5 @@ participé à leur façon. Je tiens à remercier notamment Grégoire
|
||||
\textsc{Stein}, en sa qualité de **DevSecOps**, pour ses **précieux
|
||||
conseils** tout au long de cette aventure !
|
||||
|
||||
Si d'aventures j'avais oublié des personnes, je m'en excuse. Il y a pourtant
|
||||
ici toute la place nécessaire, voilà pourquoi j'ai reservé ce paragraphe à
|
||||
toutes celles et ceux dont j'aurais omis le nom/prénom.
|
||||
À Richard \textsc{Dern} et son œil d'aigle pour les nombreuses relectures et
|
||||
fautes d'orthographes découvertes dans ce document.
|
||||
|
||||
@ -1,22 +1,20 @@
|
||||
\newpage
|
||||
|
||||
# Liste de compétences couvertes par le projet
|
||||
|
||||
Le référentiel de compétences du *Titre Professionnel Administrateur Système
|
||||
DevOps* liste 11 compétences réparties en 3 catégories :
|
||||
|
||||
* Automatiser le déploiement d’une infrastructure dans le cloud
|
||||
* Compétence **n°1 : Automatiser la création de serveurs à l’aide de
|
||||
* Automatiser le déploiement d'une infrastructure dans le cloud
|
||||
* Compétence **n°1 : Automatiser la création de serveurs à l'aide de
|
||||
scripts**
|
||||
* Compétence **n°2 : Automatiser le déploiement d'une infrastructure**
|
||||
* Compétence **n°3 : Sécuriser l’infrastructure**
|
||||
* Compétence **n°4 : Mettre l’infrastructure en production dans le
|
||||
* Compétence **n°3 : Sécuriser l'infrastructure**
|
||||
* Compétence **n°4 : Mettre l'infrastructure en production dans le
|
||||
cloud**
|
||||
* Déployer en continu une application
|
||||
* Compétence **n°5 : Préparer un environnement de test**
|
||||
* Compétence **n°6 : Gérer le stockage des données**
|
||||
* Compétence **n°7 : Gérer des containers**
|
||||
* Compétence **n°8 : Automatiser la mise en production d’une
|
||||
* Compétence **n°8 : Automatiser la mise en production d'une
|
||||
application avec une plateforme**
|
||||
* Superviser les services déployés
|
||||
* Compétence **n°9 : Définir et mettre en place des statistiques de
|
||||
@ -26,7 +24,8 @@ DevOps* liste 11 compétences réparties en 3 catégories :
|
||||
éventuellement en anglais**
|
||||
|
||||
En utilisant les critères de performance fournis par chaque fiche de
|
||||
compétence, j'ai pu établir le tableau suivant :
|
||||
compétence, j'ai pu établir le tableau suivant permettant de voir les points à
|
||||
améliorer :
|
||||
|
||||
: Couverture de compétences du projet
|
||||
|
||||
@ -35,7 +34,7 @@ Compétence | Nbre critères perf. | Couverte ? | Note
|
||||
Compétence n°1 | 3/3 | Oui | EC2 / Terraform
|
||||
Compétence n°2 | 3/3 | Oui | Terraform
|
||||
Compétence n°3 | 2/2 | Oui | Staging, Vaultwarden, Let's Encrypt
|
||||
Compétence n°4 | **2**/3 | Oui | Terraform → « prod »
|
||||
Compétence n°4 | **2**/3 | Oui | Terraform → « prod »
|
||||
Compétence n°5 | 4/4 | Oui | Gitlab CI
|
||||
Compétence n°6 | **1**/3 | Partiellement | postgresql-ha, Velero
|
||||
Compétence n°7 | 4/4 | Oui | Docker
|
||||
@ -49,10 +48,9 @@ tests concernant le système de sauvegarde qui a été développé mais pas
|
||||
déployé, **faute de tests et de temps**.
|
||||
|
||||
La **compétence n°9** (Définir et mettre en place des statistiques de
|
||||
services) ne semble pas pertinente dans un projet où nous n'avons eu **aucun
|
||||
autre interlocuteur que le « mentor »**.
|
||||
services) n'a pu être clairement établie **faute d'interlocuteur autre que le
|
||||
« mentor »**.
|
||||
|
||||
La **compétence n°10** (Exploiter une solution de supervision) est **en lien
|
||||
avec la compétence précédente**, ce qui influe sur la pertinence des moniteurs
|
||||
mis en place dans la solution. Ce qui, à mon sens, ne résoud pas totalement
|
||||
cette compétence.
|
||||
mis en place dans la solution.
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
\newpage
|
||||
|
||||
# Cahier des charges
|
||||
|
||||
Dans le cadre d'une **formation, dans l'école DataScientest**, il a été
|
||||
@ -16,57 +14,58 @@ contraintes attenantes.
|
||||
|
||||
### Dans le cadre d'une formation
|
||||
|
||||
**[Datascientest]{#datascientest}** est une **école de formation** créée en
|
||||
**[DataScientest]{#datascientest}** est une **école de formation** créée en
|
||||
2017, située sur Paris et proposant **plus de 18 formations différentes**,
|
||||
dont *Administrateur Système DevOps*.
|
||||
|
||||
Plusieurs formats de formation existent parmi **Bootcamp**, continu et en
|
||||
alternance. **Ce projet est un exercice de fin de formation** proposé à tous
|
||||
les élèves de la « cohorte » (équivalent d'une classe).
|
||||
les élèves de la « cohorte » (équivalent d'une classe).
|
||||
|
||||
Plusieurs élèves se regroupent autour d'un projet auquel ils ont un **intérêt
|
||||
commun**.
|
||||
Plusieurs élèves se regroupent autour d'un projet pour lequel ils ont un
|
||||
**intérêt commun**.
|
||||
|
||||
### L'équipe DevU42 {#devu42}
|
||||
|
||||
Le **groupe DevU42** s'est formé le **17 octobre 2024**. Il est composé de
|
||||
**quatre étudiants** participant à la formation **Administrateur Système
|
||||
DevOps** de l’organisme de formation [DataScientest](#datascientest).
|
||||
DevOps** de l'organisme de formation [DataScientest](#datascientest).
|
||||
|
||||
Ses membres sont, par ordre alphabétique (prénom) :
|
||||
Ses membres sont, par ordre alphabétique :
|
||||
|
||||
* **Eliel MONCADA**
|
||||
* **Hrubech HOMBESSA**
|
||||
* **Julien SABIOLS**
|
||||
* Olivier DOSSMANN
|
||||
* **Hrubech \textsc{Hombessa}**,
|
||||
* **Eliel \textsc{Moncada}**,
|
||||
* **Julien \textsc{Sabiols}**,
|
||||
* et Olivier \textsc{Dossmann}.
|
||||
|
||||
Ils interviennent sur le projet en qualité d’**Administrateur Système DevOps**.
|
||||
Ils interviennent sur le projet en qualité d'**Administrateur Système DevOps**.
|
||||
|
||||
L'équipe a été supervisée et suivie par [**Jérémie Tarot** sous la
|
||||
dénomination de **« Mentor »**]{#mentor}. Et ainsi en sera-t-il dans le
|
||||
présent document.
|
||||
L'équipe a été supervisée et suivie par [**Jérémie \textsc{Tarot}** sous la
|
||||
dénomination de **« Mentor »**]{#mentor}. Et ainsi en sera-t-il
|
||||
dans le présent document.
|
||||
|
||||
### Organisation d'équipe
|
||||
|
||||
Pour s'organiser, l'équipe s'est doté de plusieurs outils et suivi quelques méthodologies.
|
||||
Pour s'organiser, l'équipe s'est dotée de plusieurs outils et suivi certaines
|
||||
méthodologies particulières.
|
||||
|
||||
#### Rapports hiérarchiques
|
||||
|
||||
L’équipe s'articule autour de membres ayant le **même degré de
|
||||
L'équipe s'articule autour de membres ayant le **même degré de
|
||||
responsabilités** et d'objectifs. Leur périmètre et leur champ d'action est
|
||||
similaire qu'il s'agisse de déterminer les tickets à prendre en charge, les
|
||||
axes de travail à rajouter au projet ou bien de nouveaux objectifs.
|
||||
|
||||
En cas de désaccord sur un sujet, une décision est prise à la majorité
|
||||
votante, avec pour ultime recours l’avis du [Mentor](#mentor).
|
||||
votante, avec pour ultime recours l'avis du [Mentor](#mentor).
|
||||
|
||||
#### Moyens de communication
|
||||
|
||||
La géolocalisation des membres de l'**équipe étant éparse**, plusieurs moyens
|
||||
de communication **en ligne** ont été nécessaires, parmi :
|
||||
de communication **en ligne** ont été nécessaires, parmi lesquels :
|
||||
|
||||
* Canaux de **discussions sur [Slack](https://slack.com/intl/fr-fr/)** fournis
|
||||
initialement par [Datascientest](#datascientest) :
|
||||
initialement par [DataScientest](#datascientest) :
|
||||
* canal du projet - **sep24_bootcamp_devops** : favorise l'échange
|
||||
entre [DevU42](#devu42) et le [Mentor](#mentor),
|
||||
* canal d'équipe - **devu42** : pour les **discussions techniques**,
|
||||
@ -96,7 +95,7 @@ la formation :
|
||||
Le budget alloué au projet est de **150€ mensuel** pour couvrir l'intégralité
|
||||
des frais issus de l'utilisation de **services Amazon** (AWS).
|
||||
|
||||
C'est une limite configurée par [Datascientest](#datascientest) sur l'espace
|
||||
C'est une limite configurée par [DataScientest](#datascientest) sur l'espace
|
||||
Amazon qu'ils nous partagent.
|
||||
|
||||
#### Temps
|
||||
@ -108,7 +107,7 @@ Au terme des 7 semaines, un support visuel de présentation du projet pour son
|
||||
lancement est attendu (Cf. [Section du présent chapitre sur les
|
||||
Livrables](#livrables)).
|
||||
|
||||
Après livraison, l’amélioration du projet est possible, bien qu'un dossier
|
||||
Après livraison, l'amélioration du projet est possible, bien qu'un dossier
|
||||
professionnel, un dossier de projet (ci-présent) et un support de présentation
|
||||
est demandé à chacun des [membres de l'équipe DevU42](#devu42).
|
||||
|
||||
@ -126,14 +125,14 @@ puisse **apprendre par la pratique**.
|
||||
|
||||
On imagine facilement le cadre :
|
||||
|
||||
> Une entreprise ayant une application de gestion d’utilisateur souhaite
|
||||
> Une entreprise ayant une application de gestion d'utilisateur souhaite
|
||||
> déployer et faire évoluer son service en favorisant les bonnes pratiques
|
||||
> suivies dans la culture DevOps.
|
||||
|
||||
De la même manière, l'entreprise pourrait rencontrer de nombreux
|
||||
**problèmes** :
|
||||
|
||||
* **Reprise d’activité** lente, coûteuse et avec pertes d’informations,
|
||||
* **Reprise d'activité** lente, coûteuse et avec pertes d'informations,
|
||||
* Service instable, **disponibilité** non garantie, **vulnérabilité** du
|
||||
service,
|
||||
* Capacité limitée pour encaisser des **augmentations** ponctuelles de la
|
||||
@ -143,7 +142,7 @@ service,
|
||||
développement pouvant être améliorées par l'**automatisation**,
|
||||
* Perte de temps et erreurs humaines liées aux actions manuelles,
|
||||
* Manque de **portabilité de l'application** d'un système à l'autre,
|
||||
* Lenteurs d’implémentation de **nouvelles fonctionnalités** avec
|
||||
* Lenteurs d'implémentation de **nouvelles fonctionnalités** avec
|
||||
interruptions de service.
|
||||
|
||||
Pour bien saisir l'état des lieux de ladite application, regardons de plus
|
||||
@ -156,7 +155,7 @@ suivants :
|
||||
|
||||
* Backend utilisant le framework **FastAPI** (en Python),
|
||||
* Frontend statique (en **React**, **Vite.js** et **Chakra UI**) :
|
||||
Interface de gestion et d'enregistrement d’utilisateurs utilisant l'API du
|
||||
Interface de gestion et d'enregistrement d'utilisateurs utilisant l'API du
|
||||
backend,
|
||||
* Base de données **postgreSQL**,
|
||||
* et **Traefik** (Proxy inverse).
|
||||
@ -176,20 +175,20 @@ Mais **le projet voit plus loin**.
|
||||
|
||||
En dehors des objectifs à atteindre, le projet vise à :
|
||||
|
||||
* répondre aux problématiques de l’entreprise sur l'application existante par
|
||||
* répondre aux problématiques de l'entreprise sur l'application existante par
|
||||
**la méthode DevOps**,
|
||||
* répondre aux attentes de l’examen en matière de compétences attendues
|
||||
* répondre aux attentes de l'examen en matière de compétences attendues
|
||||
(méthode d'**apprentissage par la pratique**),
|
||||
* démontrer un **savoir-faire technique** sur les sujets principaux du DevOps,
|
||||
notamment vis à vis du Cloud **en utilisant AWS** (Amazon Web Services),
|
||||
* appliquer une méthode de travail qui optimise l’efficacité de la production
|
||||
* appliquer une méthode de travail qui optimise l'efficacité de la production
|
||||
des livrables.
|
||||
|
||||
C'est de ces **ambitions** que naîssent plusieurs objectifs spécifiques.
|
||||
|
||||
### Objectifs
|
||||
|
||||
D'après moi, ce projet à plusieurs objectifs :
|
||||
Ce projet à plusieurs objectifs :
|
||||
|
||||
* balayer l'ensemble des **sujets liés à la culture DevOps et ses méthodes**,
|
||||
* porter, puis **déployer** une application **sur le cloud**,
|
||||
@ -198,7 +197,7 @@ applications,
|
||||
* respecter un **budget** et des **limites de temps**,
|
||||
* **déployer en continu** un projet en passant par une phase de test, de
|
||||
pré-production puis de production,
|
||||
* penser à la **gestion de la donnée**,
|
||||
* penser à la **gestion des données**,
|
||||
* **superviser** un système déployé en production avec des tableaux de bord
|
||||
efficaces,
|
||||
* rendre un système **résilient** en prenant en compte les augmentations ET
|
||||
@ -208,7 +207,7 @@ humaines**,
|
||||
* procéder, de manière automatique, à des vérifications sur **la sécurité**
|
||||
des éléments produits et déployés,
|
||||
* favoriser une **collaboration** plus fluide entre les équipes de
|
||||
développements et les équipes d'opérations,
|
||||
développement et les équipes d'opération,
|
||||
* et obtenir des **alertes** en cas de défaillance d'un ou plusieurs éléments
|
||||
du système.
|
||||
|
||||
@ -218,17 +217,18 @@ primordiaux.
|
||||
|
||||
## Planification
|
||||
|
||||
C'est par le [mentor](#mentor) que nous avons reçu le plan d'action pour les 7
|
||||
semaines de travail à venir et une liste de livrables attendus. Nous avons
|
||||
adapté ce plan d'action pour nous correspondre.
|
||||
Après quelques échanges avec le [mentor](#mentor) nous avons établi le plan
|
||||
d'action pour les 7 semaines de travail à venir ainsi qu'une liste de
|
||||
livrables attendus.
|
||||
|
||||
### Étapes de travail
|
||||
|
||||
Commençons par le détail de chaque étape. Pour les 7 semaines à venir.
|
||||
Le plan s'articule en étapes bien définies.
|
||||
|
||||
#### Semaine 1 : Cadrage
|
||||
|
||||
Sous le signe de l'**encadrement**, cette première semaine est dite « douce » :
|
||||
Sous le signe de l'**encadrement**, cette première semaine est dite
|
||||
« douce » :
|
||||
|
||||
* **réunion** de prise de contact, présentation et cadrage,
|
||||
* introduction de chaque membre du projet,
|
||||
@ -257,7 +257,7 @@ Nous prévoyons aussi :
|
||||
* une **configuration de Gitlab**, des principaux dépôts, des branches, etc.,
|
||||
* de s'organiser en équipe : définir des **méthodologies** à suivre.
|
||||
|
||||
#### Semaine 3 : Automatisation de la chaine d’intégration et de livraison
|
||||
#### Semaine 3 : Automatisation de la chaine d'intégration et de livraison
|
||||
|
||||
Une fois les outils principaux mis en place, il s'agit d'**automatiser**
|
||||
plusieurs parties :
|
||||
@ -276,7 +276,7 @@ pas encore clairement définie).
|
||||
|
||||
L'**adoption d'un workflow Git** pour la gestion des branches est la bienvenue.
|
||||
|
||||
#### Semaine 4 : Conception de l’infrastructure
|
||||
#### Semaine 4 : Conception de l'infrastructure
|
||||
|
||||
Vient ensuite la création de la **couche basse de l'infrastructure** :
|
||||
|
||||
@ -303,8 +303,8 @@ alertes](#semaine6), la gestion des données est importante et passe par :
|
||||
* et installer/configurer une solution de **sauvegarde** et de **restauration
|
||||
de données**.
|
||||
|
||||
C'est un sujet bien à part. D'où la possibilité de la **faire en parallèle**
|
||||
d'un autre.
|
||||
C'est un sujet bien à part. D'où la possibilité de **faire cette étape en
|
||||
parallèle** d'une autre.
|
||||
|
||||
#### Semaine 6 : Observabilité et alertes {#semaine6}
|
||||
|
||||
@ -316,7 +316,7 @@ gérer :
|
||||
l'application,
|
||||
* **choix des métriques** à utiliser pour la création de tableaux de bords,
|
||||
* création des **tableaux de bords**,
|
||||
* **définition des niveaux d'alertes** pour les métriques choisis,
|
||||
* **définition des niveaux d'alertes** pour les métriques choisies,
|
||||
* mise en place des **alertes**,
|
||||
* et envoi des alertes sur **les canaux choisis**.
|
||||
|
||||
@ -335,7 +335,7 @@ de l'application**. Il faudra donc :
|
||||
* et résoudre les derniers problèmes majeurs connus - s'ils existent.
|
||||
|
||||
C'est un **plan ambitieux** quand on considère que **les membres de l'équipe
|
||||
proviennent d'horizons et de formations variées**.
|
||||
proviennent d'horizons et de formations variés**.
|
||||
|
||||
### Livrables {#livrables}
|
||||
|
||||
@ -360,7 +360,7 @@ Le projet **couvre beaucoup de situations** et **domaines** autour de
|
||||
application avec une **supervision** et une **mise à l'échelle** de cette
|
||||
dernière.
|
||||
|
||||
En groupe, c'est un projet idéal pour suivre l'« **apprentissage par la
|
||||
pratique** » proposé par [DataScientest](#datascientest) et couvrir un maximum
|
||||
de compétences demandées pour le *Titre Professionnel d'Administrateur
|
||||
En groupe, c'est un projet idéal pour suivre l'« **apprentissage par la
|
||||
pratique** » proposé par [DataScientest](#datascientest) et couvrir un
|
||||
maximum de compétences demandées pour le *Titre Professionnel d'Administrateur
|
||||
Système* DevOps.
|
||||
|
||||
@ -11,8 +11,8 @@ outils utilisés.
|
||||
## Étude de l'application
|
||||
|
||||
Le dépôt Git contenant l'application **existait déjà**. Une étude des
|
||||
composants fournis par le projet a donc été nécessaire. Ce qui a été fournis
|
||||
aux développeurs également. Ce qui a permis d'en mesurer les implications.
|
||||
composants fournis a donc été nécessaire, ce qui a permis d'en mesurer les
|
||||
implications.
|
||||
|
||||
### Composants de l'application
|
||||
|
||||
@ -54,11 +54,12 @@ prendra connaissance des particularités de cette application.
|
||||
|
||||
### Points d'attentions
|
||||
|
||||
La **partie Frontend** permet de générer des fichiers dits « statiques », du
|
||||
**serverless** est envisageable. L'application, bien que faisant des appels à
|
||||
une API, fonctionne de manière **autonome**. Ce qui, a priori, facilite la
|
||||
préparation pour un déploiement. Cependant **un nom de domaine est inscrit en
|
||||
dur dans le fichier Dockerfile**, ce qui peut compliquer un déploiement sur
|
||||
La **partie Frontend** permet de générer des fichiers dits
|
||||
« statiques », du **serverless** est envisageable. L'application,
|
||||
bien que faisant des appels à une API, fonctionne de manière **autonome**. Ce
|
||||
qui, a priori, facilite la préparation pour un déploiement. Cependant les
|
||||
développeurs de l'application utilisent **un nom de domaine inscrit en dur
|
||||
dans le fichier Dockerfile**, ce qui peut compliquer un déploiement sur
|
||||
plusieurs domaines et environnements.
|
||||
|
||||
La **partie backend** s'appuie sur une base de données de type PostgreSQL. Elle
|
||||
@ -165,9 +166,10 @@ sur **chaque machine des développeurs** à l'aide des outils fournis
|
||||
(Dockerfile, docker-compose du projet applicatif),
|
||||
* l'environnement de **test** : il est composé de l'**ensemble des Runner
|
||||
Gitlab** utilisés à l'intérieur de la chaîne d'intégration continue,
|
||||
* l'environnement de **pré-production** (appelé « **staging** ») : c'est
|
||||
l'infrastructure présentée ci-avant, appliquée dans AWS avec une configuration
|
||||
dite *plus légère* (moins de machines virtuelles EC2 par exemple),
|
||||
* l'environnement de **pré-production** (appelé « **staging** »
|
||||
) : c'est l'infrastructure présentée ci-avant, appliquée dans AWS avec
|
||||
une configuration dite *plus légère* (moins de machines virtuelles EC2 par
|
||||
exemple),
|
||||
* et l'environnement de **production** : c'est l'**infrastructure
|
||||
finale** ; celle qui est disponible aux utilisateurs finaux (les usagers).
|
||||
|
||||
@ -232,21 +234,23 @@ non-exhaustive :
|
||||
* les données brutes de l'application, stockées dans la **base de données
|
||||
postgreSQL**,
|
||||
* les **données sensibles** (mots de passe, clés d'accès),
|
||||
* les **copies de sauvegardes** des données elle-même,
|
||||
* les **copies de sauvegardes** des données elles-mêmes,
|
||||
* et les **fichiers de journalisation** des services en production.
|
||||
|
||||
Regardons pour chacun des points de cette liste où se situe le stockage.
|
||||
|
||||
#### Stockage
|
||||
|
||||
En reprenant les éléments précédent, nous avons :
|
||||
Les éléments précédents donnent lieu au tableau suivant :
|
||||
|
||||
* des **dépôts Gitlab** pour notre code applicatif ET les dépôts de
|
||||
l'infrastructure, gérés par Gitlab,
|
||||
* un **stockage AWS EBS** (Elastic Block Store) pour la base de données
|
||||
postgreSQL,
|
||||
* et un **stockage AWS S3** (Simple Storage Service) pour les copies de
|
||||
sauvegardes.
|
||||
: Données présentes et leur lieu de stockage
|
||||
|
||||
Données | Stockage
|
||||
-----|-----
|
||||
Code applicatif | **dépôt Gitlab**
|
||||
Code de l'infrastructure | **dépôt Gitlab**
|
||||
Base de données postgreSQL | **stockage AWS EBS** (Elastic Block Store)
|
||||
Sauvegardes | **stockage AWS S3** (Simple Storage Service)
|
||||
|
||||
Cela devrait être suffisant pour stocker les diverses données disponibles.
|
||||
|
||||
@ -267,7 +271,7 @@ postgreSQL-HA](./media/postgresql-ha.png){height=50%}
|
||||
Les dépôts de version utilisés étant sur Gitlab, [service qui se targue d'être
|
||||
entre 99% et 100% disponible](
|
||||
https://handbook.gitlab.com/handbook/engineering/monitoring/#historical-service-availability)
|
||||
, une **sauvegarde dite « préventive » mensuelle** suffit.
|
||||
, une **sauvegarde dite « préventive » mensuelle** suffit.
|
||||
|
||||
En revanche **la production**, même en **étant un service en haute
|
||||
disponibilité**, doit fournir au moins **une sauvegarde 1 fois par jour**.
|
||||
@ -277,7 +281,7 @@ Son outil en ligne de commande permet de gérer les sauvegardes mais aussi les
|
||||
restaurations de ces dernières.
|
||||
|
||||
Comme énoncé précédemment, les sauvegardes du cluster seront mises **sur un
|
||||
stockage AWS S3** (dit « bucket S3 »).
|
||||
stockage AWS S3** (dit « bucket S3 »).
|
||||
|
||||
\newpage
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ application dans le Cloud. C'est une **nouvelle équipe**, dans un **nouvel
|
||||
environnement** avec une application inconnue et **des savoirs à acquérir**.
|
||||
|
||||
En pareille situation, c'est tout un **écosystème DevOps** qu'il faut mettre
|
||||
en place. Nous allons donc avant tout parler de **méthodologie utilisées**
|
||||
en place. Nous allons donc avant tout parler des **méthodologies utilisées**
|
||||
pour ce faire, puis des **outils utilisés** et enfin aborder le sujet de
|
||||
**collaborations** avec d'autres équipes.
|
||||
|
||||
@ -15,13 +15,13 @@ pour ce faire, puis des **outils utilisés** et enfin aborder le sujet de
|
||||
|
||||
### Agile
|
||||
|
||||
Le choix d'une **méthodologie agile** « basique » s'est offerte à nous,
|
||||
Le choix d'une **méthodologie agile** « basique » s'est offerte à nous,
|
||||
notamment par :
|
||||
|
||||
* des **comptes-rendus journaliers rapides de 10mn** en respectant les points
|
||||
suivants :
|
||||
* ce que j'ai fais hier,
|
||||
* ai-je rencontré un/des problème(s) qui vaille(nt) d'être cité(s),
|
||||
* ce que j'ai fait hier,
|
||||
* ai-je rencontré un/des problème(s) qui vaut(valent) d'être cité(s),
|
||||
* ce que je compte faire aujourd'hui,
|
||||
* la **création de jalons** avec un ensemble de tâches sur une période d'une
|
||||
semaine,
|
||||
@ -142,7 +142,7 @@ l'exemple montre une référence vers le ticket #18 du dépôt nommé *projet*.
|
||||
|
||||
## Outils
|
||||
|
||||
Au delà d'une à plusieurs méthodologies/normes/standards, nous avons utilisés
|
||||
Au delà d'une à plusieurs méthodologies/normes/standards, nous avons utilisé
|
||||
des outils afférents.
|
||||
|
||||
### Nom de domaine
|
||||
@ -153,8 +153,8 @@ location d'un nom de domaine : **devu42.fr**.
|
||||
|
||||
Ce domaine fait référence à notre cursus de DevOps dans un centre de formation
|
||||
nommé **DevU**niversity. Le **nombre 42** est un chiffre connu lié aux
|
||||
ouvrages de Douglas Adams dans sa trilogie en 5 volumes de « H2G2, Guide du
|
||||
Voyageur Galactique ».
|
||||
ouvrages de Douglas Adams dans sa trilogie en 5 volumes de « H2G2, Guide
|
||||
du Voyageur Galactique ».
|
||||
|
||||
Nous avons ainsi pu avoir des **noms de domaines spécifiques** pour :
|
||||
|
||||
@ -233,8 +233,8 @@ d'appliquer à nouveau le même workflow.
|
||||
## Cas d'une collaboration inter-équipe {#collab}
|
||||
|
||||
Dans le cadre de nos diverses **réflexions** nous avons eu un contact **avec
|
||||
l'équipe** qui se nomme **« Team Matrix »** dont le sujet était le déploiement
|
||||
de serveurs Matrix en haute disponibilité.
|
||||
l'équipe** qui se nomme **« Team Matrix »** dont le sujet était le
|
||||
déploiement de serveurs Matrix en haute disponibilité.
|
||||
|
||||
Nous avons échangé sur le **sujet de la promotion des versions entre
|
||||
environnements**. Maxime, de la Team Matrix, et moi avons principalement
|
||||
@ -248,8 +248,9 @@ https://codefresh.io/blog/how-to-model-your-gitops-environments-and-promote-rele
|
||||
L'idée de l'article, en quelques mots, est de **favoriser l'utilisation d'un
|
||||
dossier par environnement** plutôt qu'utiliser une branche Git pour chaque
|
||||
environnement. Il conseille également de faire la promotion des versions entre
|
||||
ces différents environnements/dossiers. Avec un protocole à suivre par les «
|
||||
humains » pour limiter de trop nombreuses promotions logicielles en même temps.
|
||||
ces différents environnements/dossiers. Avec un protocole à suivre par les
|
||||
« humains » pour limiter de trop nombreuses promotions logicielles
|
||||
en même temps.
|
||||
|
||||
Pour reprendre le schéma de l'article :
|
||||
|
||||
@ -257,7 +258,7 @@ Pour reprendre le schéma de l'article :
|
||||
versions](./media/article_schema_promotion.png){width=100%}
|
||||
|
||||
Après moultes discussions, **nous sommes tombés d'accord** sur quelques
|
||||
points, parmi :
|
||||
points, notamment :
|
||||
|
||||
* **ne pas utiliser une branche par environnement**,
|
||||
* essayer au maximum d'**avoir des dépôts indépendants** (favoriser la
|
||||
@ -279,9 +280,9 @@ de sécurité**, des **tests du code**, vérification de la **couverture de
|
||||
code** et **tests sur la compilation** - éventuelle - de l'outil et/ou des
|
||||
**images Docker** puis **publication sur un registre**,
|
||||
* avoir une gestion de chacun de ces dépôts d'**un système de versionnement**
|
||||
(les fameuses « releases »),
|
||||
(les fameuses « releases »),
|
||||
* avoir la **même chose pour chaque module Terraform** que nous avons fabriqué
|
||||
(par exemple notre module « networking »),
|
||||
(par exemple notre module « networking »),
|
||||
* puis utiliser, dans un dépôt **infra** par exemple, seulement les versions
|
||||
de nos modules (situés indépendamment sur des registres),
|
||||
* de là on peut imaginer :
|
||||
@ -293,12 +294,11 @@ de nos modules (situés indépendamment sur des registres),
|
||||
* ajouter des **tests de sécurité des images** (comme la somme de contrôle) avant
|
||||
utilisation dans d'autres dépôts.
|
||||
|
||||
À noter que Maxime et moi étions également arrivés sur le fait qu'il y a déjà
|
||||
2 types de promotions dans tout cela :
|
||||
Maxime et moi avons également relevé que lorsqu'on parle de promotions dans
|
||||
l'infrastructure on peut imaginer 2 types de promotions :
|
||||
|
||||
* la promotion des versions des logiciels/modules/charts utilisés,
|
||||
* et la promotion des configurations de ces derniers au sein de nos
|
||||
infrastructures.
|
||||
* la promotion de versions concernant les logiciels/modules/charts utilisés,
|
||||
* et la promotion de configurations pour différentes infrastructures.
|
||||
|
||||
C'est un autre sujet très intéressant que nous ne détaillerons pas ici.
|
||||
|
||||
|
||||
@ -79,12 +79,11 @@ pourquoi ne pas **utiliser Git lui-même à l'aide d'un commit sur le dépôt
|
||||
suivant** ? Ainsi, sans outils supplémentaires, nous pouvons lier les
|
||||
dépôts entre eux.
|
||||
|
||||
En suivant cette logique, nous obtenons le schéma représentant la pipeline de
|
||||
chaque dépôt :
|
||||
|
||||
```{=latex}
|
||||
\begin{sidewaysfigure}
|
||||
|
||||
En suivant cette logique, nous obtenons le schéma représentant la pipeline de
|
||||
chaque dépôt~:
|
||||
|
||||
\includegraphics{./media/schema_3_pipelines.png}
|
||||
\caption{Schéma des 3 pipelines}
|
||||
\end{sidewaysfigure}
|
||||
@ -137,7 +136,7 @@ inform-charts:
|
||||
**Le code a dû être modifié (raccourcissement des lignes) pour les fins de
|
||||
rédaction du présent document**.
|
||||
|
||||
La **ligne 27 à 29** posent un tag sur le dépôt **charts** en mettant
|
||||
Les **ligne 27 à 29** posent un tag sur le dépôt **charts** en mettant
|
||||
simplement à jour les versions utilisées du backend et du frontend dans les
|
||||
charts Helm sur le registre Gitlab.
|
||||
|
||||
@ -377,5 +376,5 @@ processus de production logicielle et de livraison continue. Il y a beaucoup
|
||||
de choses à dire sur chacun des sujets, tellement ils sont passionnants. Ils
|
||||
amènent également à prendre des initiatives et tester localement des outils.
|
||||
Nous parlerons d'ailleurs dans le prochain chapitre d'une situation de travail
|
||||
ayant amené à faire une recherche. Nous pourrons ainsi voir plus en détail le
|
||||
ayant amené à faire une recherche. Nous pourrons ainsi voir plus en détails le
|
||||
processus de travail suivi afin d'aboutir à ce résultat.
|
||||
|
||||
@ -3,8 +3,8 @@
|
||||
# Situation de travail
|
||||
|
||||
L'exercice demandé dans ce chapitre est particulier pour moi. Il est demandé,
|
||||
je cite, « **une description d'une situation de travail ayant nécessité une
|
||||
recherche effectuée par le candidat durant le projet** ».
|
||||
je cite, « **une description d'une situation de travail ayant nécessité une
|
||||
recherche effectuée par le candidat durant le projet** ».
|
||||
|
||||
Pour bien saisir **ma façon de travailler**, je pense qu'il est nécessaire de
|
||||
décrire une situation complète. Nous allons poser le contexte, faire l'état
|
||||
@ -77,14 +77,14 @@ Et c'est ce que j'ai fait :
|
||||
|
||||
* **demande à un ami DevSecOps** si je pouvais l'interpeller de temps en temps
|
||||
sur l'un ou l'autre sujet,
|
||||
* achat du **livre « Kubernetes - Guide pratique »** aux éditions
|
||||
* achat du **livre « Kubernetes - Guide pratique »** aux éditions
|
||||
\textsc{O'Reilly},
|
||||
* recherche, infructueuse, **à la médiathèque** : le rayon informatique
|
||||
est maigre,
|
||||
* recherche sur le domaine du DevOps **sur Internet** avec une **grande
|
||||
lecture initiale** de [**Stéphane Robert** (Devenez expert DevOps et maîtrisez
|
||||
ses outils)](https://blog.stephane-robert.info/){#stephane-robert} (j'ai
|
||||
repris le titre du site tel quel).
|
||||
lecture initiale** de [**Stéphane \textsc{Robert}** (Devenez expert DevOps et
|
||||
maîtrisez ses outils)](https://blog.stephane-robert.info/){#stephane-robert}
|
||||
(j'ai repris le titre du site tel quel).
|
||||
|
||||
{height=35%}
|
||||
@ -94,9 +94,10 @@ pratique](./media/livre-oreilly.jpg){height=35%}
|
||||
### Point de départ
|
||||
|
||||
Grâce à la lecture de quantité d'articles sur le blog de [Stéphane
|
||||
Robert](#stephane-robert), notamment la [série d'article sur « Mon nouveau
|
||||
Homelab DevOps](https://blog.stephane-robert.info/docs/homelab/introduction/)
|
||||
(Cf. https://blog.stephane-robert.info/docs/homelab/introduction/) et la
|
||||
\textsc{Robert}](#stephane-robert), notamment la [série d'article sur
|
||||
« Mon nouveau Homelab DevOps »](
|
||||
https://blog.stephane-robert.info/docs/homelab/introduction/) (Cf.
|
||||
https://blog.stephane-robert.info/docs/homelab/introduction/) et la
|
||||
**Roadmap de son parcours de formation DevSecOps** (Cf.
|
||||
https://blog.stephane-robert.info/docs/#la-roadmap), j'ai pu établir des
|
||||
**objectifs à court terme** et des étapes de sujets à aborder comme :
|
||||
@ -105,7 +106,7 @@ https://blog.stephane-robert.info/docs/#la-roadmap), j'ai pu établir des
|
||||
* **le GitOps avec** un outil tel que **FluxCD**.
|
||||
|
||||
{width=100%}
|
||||
\textsc{Robert}](./media/screenshot_stephane-robert.png){width=100%}
|
||||
|
||||
### Recherches
|
||||
|
||||
@ -115,9 +116,11 @@ Je pars souvent de **sites de référence ou de sites que j'ai déjà utilisé**
|
||||
plusieurs fois dans le passé. Le sujet de la virtualisation a donc donné lieu
|
||||
à **quelques recherches sur des sites déjà connus** :
|
||||
|
||||
* Le **wiki d'ArchLinux** et sa catégorie « **Virtualization** » :
|
||||
* Le **wiki d'ArchLinux** et sa catégorie
|
||||
« **Virtualization** » : \
|
||||
https://wiki.archlinux.org/title/Category:Virtualization,
|
||||
* Le blog précédemment cité de [**Stéphane Robert**](#stephane-robert).
|
||||
* Le blog précédemment cité de [**Stéphane \textsc{Robert}**](#stephane-robert)
|
||||
.
|
||||
|
||||
Je me suis concentré sur l'outil conseillé par **mon contact DevSecOps** qui
|
||||
utilise QEMU/KVM/Libvirt pour l'émulation d'une machine complète. J'ai lu et
|
||||
@ -143,7 +146,7 @@ https://odtre.gitlab.io/doc/virtualisation/.
|
||||
plusieurs systèmes d'exploitation** avant de les adopter et les déployer sur
|
||||
notre infrastructure.
|
||||
|
||||
{width=100%}
|
||||
|
||||
\newpage
|
||||
@ -158,7 +161,7 @@ nécessaires** pour déployer et utiliser **FluxCD** :
|
||||
|
||||
* la **page d'installation officielle**, Cf.
|
||||
https://fluxcd.io/flux/installation/,
|
||||
* les différents « **bootstrap** » possibles en fonction d'un **fournisseur de
|
||||
* les différents « **bootstrap** » possibles en fonction d'un **fournisseur de
|
||||
dépôt Git** choisi, Cf. https://fluxcd.io/flux/installation/bootstrap/,
|
||||
* et des **explications sur le contrôleur de sources**, \
|
||||
Cf. https://fluxcd.io/flux/installation/bootstrap/ pour se mettre à jour
|
||||
|
||||
@ -6,7 +6,7 @@ Ma **passion anticipée pour l'automatisation** et l'**amélioration des
|
||||
processus** de **création logiciel** m'ont amené à ce moment, aujourd'hui, où
|
||||
j'écris ces lignes pour **embrasser le métier d'Administrateur Système
|
||||
DevOps**. La formation, puis **le projet de fin de formation** ont été
|
||||
**bénéfique à la prise d'expérience**, mais pas que.
|
||||
**bénéfiques à la prise d'expérience**, mais pas que.
|
||||
|
||||
En effet, **il est question de nouvelles compétences**, que le projet, à
|
||||
travers la rédaction d'un cahier des charges, de spécifications
|
||||
|
||||
Loading…
Reference in New Issue
Block a user