diff --git a/content/30_liste_competences.md b/content/30_liste_competences.md index f0cc8cb..ab1710e 100644 --- a/content/30_liste_competences.md +++ b/content/30_liste_competences.md @@ -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. diff --git a/content/40_cahier_des_charges.md b/content/40_cahier_des_charges.md index b9d91b4..0a90c09 100644 --- a/content/40_cahier_des_charges.md +++ b/content/40_cahier_des_charges.md @@ -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. diff --git a/content/50_specifications_techniques.md b/content/50_specifications_techniques.md index dfac720..75f4501 100644 --- a/content/50_specifications_techniques.md +++ b/content/50_specifications_techniques.md @@ -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 à : ![Schéma de la couche basse de l'infrastructure](./media/schema_couche_basse.png){width=100%} -C'est sur cette base qu'il est possible d'intégrer un environnement capable de -déployer, automatiser et gérer des applications conteneurisées. - ### 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. ![Schéma des agents Datadog dans notre système Kubernetes](./media/schema_datadog.png){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é. diff --git a/content/60_demarche.md b/content/60_demarche.md index 77c9fe0..a1886c4 100644 --- a/content/60_demarche.md +++ b/content/60_demarche.md @@ -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 diff --git a/content/70_realisations.md b/content/70_realisations.md index fc1b24e..6b556df 100644 --- a/content/70_realisations.md +++ b/content/70_realisations.md @@ -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. diff --git a/content/80_situation_de_travail.md b/content/80_situation_de_travail.md index b2649f6..6be30a8 100644 --- a/content/80_situation_de_travail.md +++ b/content/80_situation_de_travail.md @@ -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. -![Section « Documentation » du site statique odtre.gitlab.io généré sur -Gitlab](./media/screenshot_odtre_doc.png){width=100%} +![Section « Documentation » du site statique odtre.gitlab.io +généré sur Gitlab](./media/screenshot_odtre_doc.png){width=100%} \newpage @@ -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. diff --git a/content/90_conclusion.md b/content/90_conclusion.md index e78aaae..dfedcda 100644 --- a/content/90_conclusion.md +++ b/content/90_conclusion.md @@ -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.