soutenance/content/60_situation_de_travail.md

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

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.

## 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 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 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%}

\newpage

### 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 : 

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

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

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.

![Section « Documentation » du site statique odtre.gitlab.io généré sur 
Gitlab](./media/screenshot_odtre_doc.png){width=100%}

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

![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** restent **dans les articles des 
blogueurs** et autres joyeux rédacteurs en tous genres.