chore(content): work on intro/conclusion
This commit is contained in:
parent
77dd0c0795
commit
61cb52dc50
@ -1,5 +1,7 @@
|
||||
# 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 :
|
||||
|
||||
@ -23,6 +25,8 @@ 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 permettant de voir les points à
|
||||
améliorer :
|
||||
@ -54,3 +58,10 @@ services) n'a pu être clairement établie **faute d'interlocuteur autre que le
|
||||
La **compétence n°10** (Exploiter une solution de supervision) est **en lien
|
||||
avec la compétence précédente**, ce qui influe sur la pertinence des moniteurs
|
||||
mis en place dans la solution.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Le projet décrit dans le présent document couvre de manière complète une
|
||||
énorme partie des compétences attendues. Au final 2 type de compétences
|
||||
sont partiellement couvertes : celle concernant la supervision et celle
|
||||
concernant le stockage de données.
|
||||
|
||||
@ -145,13 +145,13 @@ développement pouvant être améliorées par l'**automatisation**,
|
||||
* 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**) :
|
||||
@ -169,11 +169,10 @@ 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
|
||||
**la méthode DevOps**,
|
||||
@ -184,11 +183,9 @@ notamment vis à vis du Cloud **en utilisant AWS** (Amazon Web Services),
|
||||
* appliquer une méthode de travail qui optimise l'efficacité de la production
|
||||
des livrables.
|
||||
|
||||
C'est de ces **ambitions** que naîssent plusieurs objectifs spécifiques.
|
||||
|
||||
### Objectifs
|
||||
|
||||
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**,
|
||||
@ -215,7 +212,7 @@ 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}
|
||||
|
||||
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
|
||||
@ -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
|
||||
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.
|
||||
|
||||
@ -69,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
|
||||
|
||||
@ -105,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**).
|
||||
|
||||
@ -148,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
|
||||
|
||||
@ -276,9 +278,9 @@ https://handbook.gitlab.com/handbook/engineering/monitoring/#historical-service-
|
||||
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 »).
|
||||
@ -295,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
|
||||
@ -307,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
|
||||
|
||||
@ -332,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é.
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -375,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étails 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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -119,8 +117,8 @@ plusieurs fois dans le passé. Le sujet de la virtualisation a donc donné lieu
|
||||
* Le **wiki d'ArchLinux** et sa catégorie
|
||||
« **Virtualization** » : \
|
||||
https://wiki.archlinux.org/title/Category:Virtualization,
|
||||
* Le blog précédemment cité de [**Stéphane \textsc{Robert}**](#stephane-robert)
|
||||
.
|
||||
* 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
|
||||
@ -146,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
|
||||
|
||||
@ -161,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 ».
|
||||
@ -181,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.
|
||||
|
||||
@ -3,9 +3,9 @@
|
||||
# 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é
|
||||
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, à
|
||||
@ -14,10 +14,22 @@ 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**.
|
||||
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.
|
||||
|
||||
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 !
|
||||
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.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user