On ne va pas se mentir ; on est une famille geek et on adore configurer des machines et des réseaux (surtout tbowan si vous voulez tout savoir). Au fil du temps, et sous prétexte de se former et de rester à jours sur ce genre de technologie, nous avons construit notre petite infra dont on tire une petite fierté…

Deux boxes d’accès à internet et deux pare-feu en haute disponibilité pour ne jamais être déconnecté du grand Internet. Un réseau de téléphonie sur IP parce que c’est marrant tout ce qu’on peut faire avec un IPBX. Deux DMZ pour héberger nos extranets et intranet. Un lab pour faire du devops sur nos sites publics et aussi tester plein de trucs (qui ne sont pas sur le schéma). Un contrôleur de domaine et ses partages de fichiers. Deux serveurs physiques pour virtualiser tous ces services. Et bien sûr, des ordinateurs, téléphones et imprimantes pour travailler jouer.

Même si nous avons acheté tout ça reconditionné (sauf les smartphones, on avoue), cette débauche de moyens nécessite pas mal d’énergie pour fonctionner…

• Les deux serveurs physiques cumulaient 1kW, soit 8760 kWh à l’année ; suivant les tarifs, ça fait autour de 1800€ et 880kg de CO₂.
• En réduisant la virtualisation sur le plus petit des deux on est depuis descendus à 250W ; soit 450€ et 220kg de CO₂ a l’année.

Et forcément, on s’est demandé si on ne pouvais pas aller plus loin et simplifier tout ça. Puis on s’est dit que ça pourrait vous intéresser.

Le site web

Commençons par regarder comment nous mettions notre site en ligne… Que ce soit l’ancienne version dynamique avec grav, ou la nouvelle version statique, nous utilisions encore récemment toute une infrastructure dédiée : un serveur gitlab pour héberger le code du site et orchestrer la CI/CD avec un runner pour compiler et déployer sur des environnements de préproduction, et un autre pour récupérer le résultat du premier et le déployer en production. Et pour mesurer notre audience, nous envoyions les logs vers matomo sur sa propre machine virtuelle.

Soyons honnêtes. C’est effectivement plus « beau » et « satisfaisant » d’utiliser tous ces trucs de devops-lean-agiles (il ne nous manque que docker, Kubernetes et Ansible pour être à la mode) mais sérieusement… pour des site statique !?

Les pré-productions : Sachant qu’on compile systématiquement le site manuellement pour tester avant de publier quoi que ce soit, ces plateformes et environnement provisionnés automatiquement n’avaient aucune utilité (nous ne les avions d’ailleurs jamais utilisées).

Le runner pour la production : En vrai, la compilation étant faite sur les préproductions, il ne faisait qu’un rsync vers le serveur. On peut donc très bien le faire nous même quand on veut publier ce qu’on vient de compiler.

Les statistiques : Entre leur fiabilité variable, les questions éthiques qu’elles soulevaient (est-ce qu’on apprécierait ce genre de suivi dans le monde réel ?) et l’impact négatif qu’elles avaient sur notre créativité, on a décidé de s’en passer complètement. Plus de matomo, ni de goaccess ni rien sur nos sites et on s’en porte pas plus mal.

On ne garde donc que gitlab pour centraliser le code source et on lance les commandes à la main lorsqu’on a besoin de publier. La mise en prod tiens en une ligne de commande :

make deploy

La téléphonie

Passons maintenant à notre deuxième jouet, la téléphonie sur IP et tous ses composants indispensables…

Puisque nous avions deux boxes d’accès, nous avions utilisé les deux lignes correspondantes, Ces lignes sont analogique nous avions donc besoin d’une passerelle analogique, et comme elle avait deux ports FXS, nous y avions branché deux téléphone analogiques (dont un vieux socotel à cadran 😊). Cette passerelle ne fournissant pas un serveur IPBX, nous avions du ajouter un serveur vitalpbx, et tant qu’on y était nous avions flashé et ajouté 4 IP-8815. À ce stade, nous avions aussi ajouté des applications pour transformer nos smartphones en SIP-phones.

Une fois que tout ce petit monde a réussi à se parler, on a pu passer à l’étape suivante et configurer l’IPBX : la présentation du numéro pour savoir qui nous appelle, les groupes de sonnerie pour faire sonner plusieurs téléphone lors d’un appel entrant, la messagerie vocale pour recevoir les messages par courriel lorsqu’on décroche pas, la liste noire pour bloquer un numéro pénible et un test de turing pour éviter le spam.

Soyons honnêtes, c’est vrai que c’est plutôt sympa à utiliser mais objectivement, mis à part les robots d’appels, une seule personne nous appelait sur ces lignes. Et nous ne les utilisions d’ailleurs quasiment jamais non plus.

Nous avons donc demandé à notre opérateur de basculer tout appel entrant directement sur messagerie (et de nous envoyer les messages par courriel). On rappellera ceux qui ont laissé un message, les autres ne sont pas important. Puis on a tout supprimé (sauf les smartphones on avoue).

Le Réseau

Maintenant qu’on a supprimé la production des sites web et la téléphonie sur IP, on y voit déjà un peu plus clair.

Nous avions donc un accès ADSL pour pallier aux pannes côté fibre puis deux routeurs en haute disponibilité (au cas où l’un des deux ait un problème). À côté du LAN habituel, nous avions une DMZ publique avec un apache pour partager des fichiers avec des amis, une DMZ privée pour notre intranet pour nous organiser. Ainsi qu’un lab qui nous servait de réseau de test, réparti sur les deux hyperviseurs avec un câble dédié. Et bien sûr des VLANs pour mutualiser certains câbles.

Soyons honnêtes, c’est sûr que la sécurité est au cœur du projet. Mais avons-nous vraiment besoin de tout ça ?

L’ADSL : statistiquement les pannes réseaux ont été assez rare pour ne pas justifier l’investissement. Pire, depuis qu’elle ne gère plus l’IPv6 on devrait tout rétrograder en IPv4 pour qu’elle serve en cas de panne (car sinon les machines restent en IPv6 et ne peuvent utiliser cette connexion). Et surtout, on s’est rendu compte que les déconnexions font du bien et qu’on a toujours plein de choses à s’occuper pendant que l’opérateur remet en marche.

Les pfSense : statistiquement, la haute disponibilité n’a jamais été utile en cinq ans. Et puisque pour économiser l’électricité ces deux machines sont virtualisées sur le même hyperviseur, on peut se demander quel genre de panne elle couvre…

Les DMZ : le site en DMZ publique n’a été utilisé que deux fois en 5 ans et on peut donc le supprimer sans regrets. Côté DMZ privée notre kanboard sert quotidiennement mais il n’est pas nécessaire de le cloisonner à ce point vu notre base d’utilisateurs.

Le Lab : maintenant que les runners et les environnement de préproductions ont disparu, aucune machine n’y est allumée en permanence. Pour les autres, soit il s’agit d’expertises et elles sont sur leur propre réseau complètement isolé (donc hors du schéma), soit elles peuvent bien se brancher sur le LAN le temps du test.

Les VLANs : si on enlève tout ce qui précède nous n’en avons plus besoin du tout (nous avons enfin assez de cartes et de câbles), du coup le switch n’a plus besoin d’aucune configuration spécifique.

Et maintenant ?

Côté énergie, on a réduit de 5W par téléphone (sauf le socotel qui ne consomme rien s’il n’est pas utilisé), 10W pour la passerelle et 20W pour la box ADSL. La suppression des machines virtuelle n’a pas changé grand chose sur l’hyperviseur (le plus gros de la conso est dans les disques durs) et je ne peux pas évaluer de combien on économise en supprimant l’orchestration de la CI/CD chez gitlab.

En arrondissant un peu, mettons qu’on arrive à 500 kWh par an. Nous avons donc réduit notre facture de 100€ et 50 kg de CO₂. Ce n’est pas négligeable mais on sent bien que si l’objectif est d’économiser l’énergie consommée et le carbone émis, il y a plein d’autres gestes plus performants à faire.

En fait cette histoire d’écologie est surtout un prétexte pour enclencher une démarche de simplification et une prise de conscience plus globale. Même si tous ces trucs sont très satisfaisantes à acquérir, installer, configurer, maintenir et utiliser, soyons honnêtes : nous en avons rarement vraiment besoin.

Face à tous ces trucs à la mode, n’ayons pas peur de questionner leur utilité réelle. Mesurons ce qu’ils nous procurent vraiment (et pas ce qu’on pense qu’ils nous procureront) et mettons-le en regard ce qu’ils nous coûtent vraiment (en Watt, en euros, en carbone, en temps ou n’importe quelle autre unité). Puis ayons le courage de supprimer tout le superflu.

Un petit truc à la fois on dégage de la place, on libère un peu plus nos esprits et on respire enfin.

Licences

Les schémas ont été réalisés avec yEd. Un freeware développé (en java 😭) par yworks.

Les icones des schémas ont été conçues par VRT System (sous licence CC By SA). Elles sont initialement pour libre office mais pafnow propose un dépôt git où il les a converties pour yEd (son travail est sous licence GPL v3).

Je me la jouerais bien à la cisco et cie et vous dire que pour avoir le code source, il faut que vous nous envoyiez un courriel mais en vrai, remplacez simplement l’extension png par graphml dans les adresses des images et vous l’aurez directement😉 (mais vous pouvez quand même nous écrire, ça nous fait toujours plaisir).