\newpage

# Situation de travail

L'exercice demandé dans ce chapitre est particulier pour moi. Il est demandé, 
je cite, «&#8239;**une description d'une situation de travail ayant nécessité une 
recherche effectuée par le candidat durant le projet**&#8239;».

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, une **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&nbsp;: 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 sections**&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 «&#8239;Kubernetes - Guide pratique&#8239;»** aux éditions 
\textsc{O'Reilly},
* recherche, infructueuse, **à la médiathèque**&nbsp;: 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)](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 
\textsc{Robert}](#stephane-robert), notamment la [série d'article sur 
«&#8239;Mon nouveau Homelab DevOps&#8239;»](
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 
\textsc{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 
«&#8239;**Virtualization**&#8239;»&nbsp;: \
https://wiki.archlinux.org/title/Category:Virtualization,
* 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 
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.

![Section «&#8239;Documentation&#8239;» 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**&nbsp;: 

* la **page d'installation officielle**, Cf. 
https://fluxcd.io/flux/installation/,
* les différents «&#8239;**bootstrap**&#8239;» 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 
«&#8239; tout seul&#8239;».

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.
