8.3 KiB
\newpage
Situation de travail
L'exercice demandé dans ce chapitre est particulier pour moi. Il est demandé, je cite, « une description d'une situation de travail ayant nécessité une recherche effectuée par le candidat durant le projet ».
Pour saisir la méthodologie choisie, je pense qu'il est nécessaire de décrire une situation complète. Nous allons poser le contexte, faire l'état des lieux puis suivre la démarche pour atteindre l'objectif.
Contexte et état des lieux
Du projet émane un besoin d'avoir du temps de calcul pour les pipelines.
Il est nécessaire de réfléchir et trouver une solution viable pour l'environnement de test. L'objectif est donc de préparer un environnement de test pour l'ensemble des éléments du projet. Nous utilisons Gitlab, ce sont donc des Gitlab Runner que nous visons.
Où les installer ? Comment ? De quelles ressources disposons-nous ?
Nous utilisons Gitlab qui propose, dans sa version gratuite, une limite de temps de calcul. Une fois le seuil atteint : il faut trouver une solution alternative aux machines de Gitlab, payantes.
Autre environnement disponible : AWS. Mais avec un budget limité qui mangerait dans le budget alloué à nos 2 environnements : la production et la pré-production.
Il n'y a pas le choix : il faut envisager autre chose. Avec les ressources à disposition du groupe, autrement dit : avec le matériel de chacun.
L'idée ? Utiliser une machine disponible, y installer un serveur et un environnement Kubernetes pour déployer des Gitlab Runner.
Après en avoir discuté en groupe, je me suis attelé à la tâche. Régulièrement.
Démarche
Retranscription préalable
Étant donné que j'allais passer du temps à faire des recherches, il fallait un lieu où synthétiser les résultats. J'ai opté pour l'utilisation d'un site .gitlab.io généré automatiquement par les pipelines de Gitlab en utilisant comme moteur statique un outil nommé Hugo. Le résultat est disponible sur odtre.gitlab.io afin qu'il puisse être consulté par mes collaborateurs.
Ce site va contenir principalement 2 sections :
- posts : les réflexions sur différents sujets/thèmes de l'environnement de test,
- doc : de la documentation sur l'installation effectuée des outils en place.
Maintenant qu'un système de retranscription est en place, la recherche commence !
Méthode de renseignement
Je procède souvent de la même manière :
- contact avec des personnes de mon entourage déjà dans le métier et pouvant m'indiquer des pistes à suivre,
- recherche de livres existants sur le sujet,
- passage à la médiathèque,
- recherches sur Internet d'articles sur le sujet (support textuel uniquement).
Et c'est ce que j'ai fait :
- demande à un ami DevSecOps si je pouvais l'interpeller de temps en temps sur l'un ou l'autre sujet,
- achat du livre « Kubernetes - Guide pratique » aux éditions \textsc{O'Reilly},
- recherche, infructueuse, à la médiathèque : le rayon informatique est maigre,
- recherche sur le domaine du DevOps sur Internet avec une grande lecture initiale de Stéphane \textsc{Robert} (Devenez expert DevOps et maîtrisez ses outils){#stephane-robert} (j'ai repris le titre du site tel quel).
\newpage
Point de départ
Grâce à la lecture de quantité d'articles sur le blog de Stéphane \textsc{Robert}, notamment la série d'article sur « Mon nouveau Homelab DevOps » (Cf. https://blog.stephane-robert.info/docs/homelab/introduction/) et la Roadmap de son parcours de formation DevSecOps (Cf. https://blog.stephane-robert.info/docs/#la-roadmap), j'ai pu établir des objectifs à court terme et des étapes de sujets à aborder comme :
- le sujet de la virtualisation,
- le GitOps avec un outil tel que FluxCD.
Recherches
Sujet de la virtualisation
Je pars souvent de sites de référence ou de sites que j'ai déjà utilisé plusieurs fois dans le passé. Le sujet de la virtualisation a donc donné lieu à quelques recherches sur des sites déjà connus :
- Le wiki d'ArchLinux et sa catégorie
« Virtualization » :
https://wiki.archlinux.org/title/Category:Virtualization, - Le blog précédemment cité de Stéphane \textsc{Robert}.
Je me suis concentré sur l'outil conseillé par mon contact DevSecOps qui utilise QEMU/KVM/Libvirt pour l'émulation d'une machine complète. J'ai lu et appliqué :
- La page Wiki d'ArchLinux sur QEMU, Cf. https://wiki.archlinux.org/title/QEMU,
- La page Wiki d'ArchLinux sur libvirt, Cf. https://wiki.archlinux.org/title/Libvirt,
- et un message de forum (forums.debian.net) concernant les bonnes pratiques sur l'usage de virt-manager, Cf. https://forums.debian.net/viewtopic.php?t=158967.
J'ai ainsi rédigé 2 articles sur le sujet de la virtualisation, disponibles sur odtre.gitlab.io (outil de retranscription) :
- réflexion sur le sujet de la virtualisation, Cf. https://odtre.gitlab.io/post/002-virtualisation/,
- et exemple de virtualisation avec QEMU/KVM/Libvirt sous Linux, Cf. https://odtre.gitlab.io/doc/virtualisation/.
La virtualisation permet, dans notre situation, de tester un ou plusieurs systèmes d'exploitation avant de les adopter et les déployer sur notre infrastructure.
\newpage
Sujet sur FluxCD
Concernant des outils spécifiques tels que FluxCD, je favorise avant tout la documentation du site officiel. Cf. https://fluxcd.io/flux/.
C'est ainsi que plusieurs éléments de documentation m'ont été nécessaires pour déployer et utiliser FluxCD :
- la page d'installation officielle, Cf. https://fluxcd.io/flux/installation/,
- les différents « bootstrap » possibles en fonction d'un fournisseur de dépôt Git choisi, Cf. https://fluxcd.io/flux/installation/bootstrap/,
- et des explications sur le contrôleur de sources,
Cf. https://fluxcd.io/flux/installation/bootstrap/ pour se mettre à jour « tout seul ».
Comme auparavant, ceci a donné lieu à la rédaction d'un article sur notre outil de retranscription, Cf. https://odtre.gitlab.io/doc/fluxcd/.
Conclusion
Que les recherches soient fructueuses ou non, le projet a avancé. Les recherches ne donnent pas tous les savoirs, parfois il faut tester aussi. Bien que pour la plupart des outils, une fois choisis, la documentation officielle de ces outils semble suffire pour leur installation et leur utilisation. Les bonnes pratiques restent dans les articles des blogueurs et autres joyeux rédacteurs en tous genres.
Le blog de Stéphane \textsc{Robert} 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.