53 lines
5.3 KiB
Plaintext
53 lines
5.3 KiB
Plaintext
|
---
|
||
|
|
title: faire compliquer quand on peut faire simple
|
||
|
|
date: 2022-10-02
|
||
|
|
---
|
||
|
|
|
||
|
|
Je ne sais pas si c'est le fait de m'intéresser au "small web", mais je me rends compte que la mise en place de mon informatique personnelle est bien trop complexe par rapport à mon réel besoin. La raison est relativement simple, j'ai profité d'auto-hébergé différents services pour me former ou creuser différents sujets dont j'ai besoin professionnellement. Je ne regrette pas de l'avoir fait ainsi car cela m'a ouvert des portes à plusieurs reprises et permis d'acquérir des compétences que j'aurais du apprendre à la hâte dans un contexte professionnel. Ceci dit, on se retrouve avec une informatique personnelle équipée d'un "bazooka pour tuer une mouche".
|
||
|
|
|
||
|
|
Il y a quelques années en arrière, je débutais dans l'industrialisation dans l'infrastructure et le déploiement d'applications sur serveurs. Avant, je faisais quelque chose de très similaire mais sur des terminaux android et encore plus avant sur des terminaux windows mobile / CE. Et pendant cette expérience plus orientée serveur, j'ai commencé à faire du Ansible. J'ai donc naturellement commencé à faire du ansible pour mon informatique personnelle qui à l'époque tournait sur un VPS chez Scaleway. Et en plus de quelques playbooks d'administration pour mon serveur, j'ai commencé à écrire la configuration de mes différents containers docker et ma petite infrastructure avec ansible. Ensuite professionnellement, j'ai commencé à m'interesser à kubernetes et tout bêtement, j'ai continué à en faire de même. J'ai installé du Rancher k3s sur différentes machines pour avoir un cluster, en essyant de me mettre certaines contraintes inutiles comme des volumes partagés en lecture / écriture sur plusieurs noeuds. C'est cette dernière contrainte qui m'a posé énormément de souci avec Friendica qui a participé a finalement me faire jeter l'éponge il y a quelques mois.
|
||
|
|
|
||
|
|
Mais franchement, avais-je vraiment besoin de mettre en place un cluster kubernetes en place pour mes besoins? La réponse pragmatique est "NON!". La containerisation peut sembler plus discutable mais je pense qu'en cherchant bien, la réponse serait non également.
|
||
|
|
|
||
|
|
De même avais-je besoin d'avoir un serveur dédié au base de données? D'un point de vue architecture ça a du sens, mais pour mon besoin? Je n'en suis plus si sur.
|
||
|
|
|
||
|
|
Comme je le disais en préambule, cela m'a permis de découvrir, mettre en pratique beaucoup de choses que je n'aurais pas eu le temmps de faire pendant mon temps professionnel. Cependant le résultat est que pour ma petite infra personnelle, je me retrouve avec plusieurs serveurs chez Hetzner et maintenant que j'ai arrêté mon instance Friendica, je n'aurais besoin qu'un petit serveur ou un raspberry pi.
|
||
|
|
|
||
|
|
Pour donner une petite idée, je dispose de 3 serveurs: carrot, truffel et mango. C'est important de nommer ces petites bêtes :-D (pour la référence, cf Pepper&Carrot).
|
||
|
|
|
||
|
|
* mango (2vcpu / 4GB): serveur de base de données et serveur NFS (pour les volumes lecture/écriture)
|
||
|
|
* carrot (2vcpu/ 2GB): serveur control de mon cluster k3s et execute quelques charges de travail
|
||
|
|
* truffel (4vcpu / 8GB): noeud simple d'execution de charge de travail avec des ressources plus importantes.
|
||
|
|
|
||
|
|
Soit un total de de 8vcpu pour 14GB de RAM.
|
||
|
|
|
||
|
|
Et tout ça permet de faire tourner "seulement", classé par usage réel:
|
||
|
|
|
||
|
|
* Tiny Tiny RSS
|
||
|
|
* WikiJS
|
||
|
|
* Cette capsule
|
||
|
|
* Wallabag
|
||
|
|
* RSS Bridge
|
||
|
|
* Owncast
|
||
|
|
* Fishnet (calcul de position d'échecs lichess) : j'ai des ressources dispo
|
||
|
|
* Outillage: traefik, sealed-secret, grafana, prometheus
|
||
|
|
|
||
|
|
Il y a peu, j'avais aussi friendica qui en plus d'une base assez gourmande nécessitait de beaucoup de ressources.
|
||
|
|
|
||
|
|
Les consommateurs de ressources sont:
|
||
|
|
|
||
|
|
* Fishnet qui se dépriorise en cas de besoin
|
||
|
|
* Owncast que je n'utilise presque pas ... en ai-je vraiment besoin?
|
||
|
|
|
||
|
|
Tout ça est "as Code" avec des manifest kustomize et des secrets chiffrés avec SealedSecret et tourne sur du Rancher k3s.
|
||
|
|
|
||
|
|
Si j'allais à l'étape que j'imaginais initialement, je pensais installer ArgoCD pour gérer les déploiements automatiquement. Mais bon, reflexion faite, c'était bien trop complexe pour le besoin réel. J'imagine que l'étape d'après aurait été de centraliser les logs et voir pour intégrer un APM?
|
||
|
|
|
||
|
|
Le réel problème de cette "sur-ingénierie" c'est qu'il faut la maintenir et que cela prend du temps. Et que bien souvent je ne dispose pas de ce temps, ou tout simplement, je ne souhaite pas passer mon temps libre sur d'autres sujets. Par exemple, il est nécessaire que je mette à jour k3s sur carrot et truffel mais que plusieurs heures seront nécessaires. Car le côté magique a toujours le chic de ne pas faire partie de mon expérience dans ces cas.
|
||
|
|
|
||
|
|
Je dispose d'un quatrième serveur qui était suffisant auparavant pour mes besoins : 1vcpu / 2GB. Aujourd'hui il me sert principalement à faire tourner un bridge tor.
|
||
|
|
|
||
|
|
Je pense que revenir sur une installation mono serveur avec des composants installés directement quand c'est possible et en container quand c'est nécessaire me semble plus judicieux. Faut-il pour autant que j'abandonne le "as Code"? Je ne suis pas certains mais je pense que ça va me simplifier la vie.
|
||
|
|
|
||
|
|
Ca sera intéressant de faire un avant / après et voir si ça vallait le coup de faire une énième migration :-D
|