\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 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 des lieux puis suivre le cheminement parcouru pour atteindre l'objectif.

## Contexte

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&nbsp;? Comment&nbsp;? De quelles ressources disposons-nous&nbsp;?

## État des lieux

Nous utilisons Gitlab qui propose, dans sa version gratuite, un limite de temps de calcul. Une fois le seuil atteint&nbsp;: il faut trouver une solution alternative aux machines de Gitlab. Payantes.

Autre environnement disponible&nbsp;: 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&nbsp;: il faut envisager autre chose. Avec les ressources à disposition du groupe, autrement dit&nbsp;: avec le matériel de chacun.

L'idée&nbsp;? 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.

## Cheminement

### 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](https://odtre.gitlab.io/) afin qu'il puisse être consulté par mes collaborateurs.

Ce site va contenir principalement 2 choses&nbsp;: 

* posts&nbsp;: les réflexions sur différents sujets/thèmes de l'environnement de test,
* doc&nbsp;: 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&nbsp;!

### Méthode de renseignement

Je procède souvent de la même manière&nbsp;: 

* 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&nbsp;: 

* 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&nbsp;: le rayon informatique est maigre,
* recherche sur le domaine du DevOps 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).

![Première de couverture du livre O'Reilly, Kubernetes - Guide 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 **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&nbsp;: 

* le sujet de la virtualisation,
* le GitOps avec un outil tel que FluxCD.

![Apparence de la page d'accueil du blog de Stéphane Robert](./media/screenshot_stephane-robert.png){width=100%}\

### 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&nbsp;: 

* Le wiki d'ArchLinux et sa catégorie « Virtualization »&nbsp;: https://wiki.archlinux.org/title/Category:Virtualization,
* Le blog précédemment cité de [Stéphane 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 appliqué&nbsp;: 

* 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)&nbsp;: 

* 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.

![odtre.gitlab.io](./media/screenshot_odtre_doc.png){width=100%}\

#### 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&nbsp;: 

* 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/.

![Documentation de FluxCD sur le site officiel](./media/screenshot_fluxcd_doc.png){width=100%}\

## 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 restant dans les articles des blogueurs et autres joyeux rédacteurs en tous genres.
