Initial commit
This commit is contained in:
@@ -0,0 +1,277 @@
|
||||
---
|
||||
date: '2021-09-12'
|
||||
title: Déployer Hugo via Gitea et Drone-CI
|
||||
---
|
||||
|
||||
## Pourquoi faire simple quand on peut faire compliqué ?
|
||||
|
||||
De prime-abord, on pourrait se dire : "si je veux un blog, je lance un WordPress
|
||||
comme la moitié du web et je commence à publier en deux minutes". Mais quand on
|
||||
est un vieux routard du web, on a des aspirations et des principes un peu plus
|
||||
élitistes :
|
||||
|
||||
- WordPress ne génère pas de sites statiques (nativement)
|
||||
- Le fait qu'il soit utilisé [par la moitié d'Internet](https://w3techs.com/technologies/overview/content_management) me révèle que c'est une cible facile pour des personnes ou des robots mal-intentionnés
|
||||
- PHP est indispensable pour faire fonctionner WordPress, même si WordPress est configuré pour générer des pages pseudo-statiques
|
||||
- WordPress est une usine à gaz, qui sort du HTML, du CSS et du Javascript pas optimisés
|
||||
- Le code de WordPress est abominablement dégueulasse, impossible de faire quoique ce soit de propre, ni même de léger
|
||||
- WordPress est impersonnel, ce que je trouve embêtant pour un blog (et encore plus pour un site corporate d'ailleurs) : il doit être le reflet de son auteur ; s'il ressemble à tous les autres, quel intérêt ? (et je vous le dis : ce n'est pas simplement parce que vous customisez un thème qu'on ne voit pas que vous utilisez WordPress...)
|
||||
- WordPress a besoin d'une base de données
|
||||
- L'écrasante majorité des extensions tierces un tant soit peu intéressantes sont payantes ou sur l'immonde modèle du premium
|
||||
|
||||
Un générateur de sites statiques comme Hugo me permet de :
|
||||
|
||||
- Séparer l'apparence, le contenu, et l'outil qui construit le site final (je peux utiliser autre chose qu'Hugo si j'en ai envie, moyennant quelques ajustement mineurs). Impossible de faire ça avec WordPress
|
||||
- Publier un site 100% sécurisé : sans PHP, sans formulaires, sans Javascript, le maillon faible de la sécurité de mon site n'est pas mon site
|
||||
- Avoir un suivi de mes modifications (grâce à Git)
|
||||
- Simplifier les processus de sauvegarde et de restauration (en gros, avoir un plan de relance en béton armé en cas de défaillance technique - je peux même faire héberger temporairement mon site ailleurs sans avoir besoin d'aucune autre dépendance qu'un serveur web, impossible de faire ça avec WordPress en un minimum de temps)
|
||||
- Être réellement libre du point de vue logiciel
|
||||
|
||||
L'utilisation de git dans ce processus est totalement facultative : il est tout
|
||||
à fait possible de construire son site avec Hugo sans tout ce que je vais
|
||||
présenter dans cet article. Néanmoins, cette procédure qui semble fastidieuse
|
||||
de prime-abord est en réalité très puissante et très confortable au quotidien :
|
||||
|
||||
- Je créé ou modifie mes articles sous la forme de fichiers [Markdown](https://gohugo.io/content-management/formats/) - pratiquement du texte brut
|
||||
- Je les publie sur [ma forge Gitea](https://git.dern.ovh/)
|
||||
- Drone-CI fait le reste : construire le site en lançant l'exécutable Hugo et envoyer les fichiers HTML et CSS au serveur de production
|
||||
|
||||
Pour peu qu'on choisisse un thème existant plutôt qu'en créer un, on peut
|
||||
**réellement** ne se préoccuper que du contenu de son site.
|
||||
|
||||
## Composant logiciels
|
||||
|
||||
Tout passe par des containers (docker, évidemment, mais l'utilisation de podman
|
||||
est possible). Je présume donc que docker est installé et fonctionnel.
|
||||
|
||||
### Gitea
|
||||
|
||||
[Gitea](https://gitea.io/en-us/) est une _forge logicielle_ qui s'appuie sur le
|
||||
système de gestion de code [Git](https://git-scm.com). J'ai choisi Gitea pour sa
|
||||
sobriété, sa légèreté et sa simplicité, mais il existe d'autres forges
|
||||
logicielles : [GitHub](https://github.com) qui appartient à Microsoft et qu'il
|
||||
n'est pas possible d'auto-héberger, ou [Gitlab](https://about.gitlab.com) pour
|
||||
ne citer que ces deux-là.
|
||||
|
||||
_docker-compose.yml_ :
|
||||
|
||||
```yaml {class=not-prose}
|
||||
version: "3"
|
||||
services:
|
||||
gitea:
|
||||
image: gitea/gitea:latest
|
||||
restart: always
|
||||
ports:
|
||||
- "${HTTP_PORT}:3000"
|
||||
- "${SSH_PORT}:22"
|
||||
volumes:
|
||||
- ${DATA_DIR}:/data
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
```
|
||||
|
||||
Remplacez les variables en fonction de vos besoins :
|
||||
|
||||
- `HTTP_PORT` : le port sur lequel les requêtes HTTP arrivent sur votre serveur (pas le port HTTP du container)
|
||||
- `SSH_PORT` : le port du serveur SSH du serveur (pas le port SSH du container)
|
||||
- `DATA_DIR` : le chemin complet du dossier dans lequel stocker les données de Gitea, ou le volume si vous préférez utiliser un volume
|
||||
|
||||
### Hugo
|
||||
|
||||
[Hugo](https://gohugo.io) est un générateur de sites statiques. C'est ce que
|
||||
j'utilise pour créer et maintenir mon blog. Il en existe d'autres, tels que
|
||||
[Jekyll](https://jekyllrb.com). J'ai choisi Hugo pour sa légèreté.
|
||||
|
||||
L'essentiel du travail avec Hugo se fait sur votre machine locale. Il n'y a rien
|
||||
à installer côté serveur. La construction du site se fera via Drone-CI, dans
|
||||
lequel on va configurer un
|
||||
[_pipeline_](https://docs.drone.io/pipeline/overview/) pour compiler les
|
||||
ressources CSS (et éventuellement Javascript), et créer l'ensemble du site
|
||||
statique dans un container docker. Tous ces fichiers seront ensuite envoyé au
|
||||
serveur web via rsync, scp, ou ce que vous voulez.
|
||||
|
||||
Pour faire tout cela, il "suffit" d'ajouter un fichier _.drone.yml_ à la racine
|
||||
de votre projet Hugo avec le contenu suivant :
|
||||
|
||||
```yaml {class=not-prose}
|
||||
kind: pipeline
|
||||
type: docker
|
||||
name: default
|
||||
|
||||
steps:
|
||||
|
||||
- name: submodules
|
||||
image: alpine/git
|
||||
commands:
|
||||
- git submodule update --init --recursive
|
||||
|
||||
- name: build
|
||||
image: klakegg/hugo:ext-ci
|
||||
commands:
|
||||
- cd themes/blog_theme && npm i && cd -
|
||||
- hugo --gc --minify --environment production
|
||||
|
||||
- name: deploy
|
||||
image: appleboy/drone-scp
|
||||
settings:
|
||||
host: "10.0.2.1"
|
||||
target: /mnt/volume1/shares/www/richard-dern.fr/www/
|
||||
source: public/*
|
||||
username:
|
||||
from_secret: ssh_user
|
||||
password:
|
||||
from_secret: ssh_password
|
||||
|
||||
trigger:
|
||||
branch:
|
||||
- master
|
||||
```
|
||||
|
||||
L'étape _submodules_ (entre les lignes 7 et 10) n'est nécessaire que si le thème
|
||||
que vous utilisez est dans un _submodule_ git dans le répertoire _theme_ de
|
||||
votre projet Hugo. Si le thème est directement dans l'arborescence de votre
|
||||
projet, vous pouvez supprimer les lignes concernées.
|
||||
|
||||
Le thème que j'ai créé utilise
|
||||
le framework [Tailwind CSS](https://tailwindcss.com), j'ai donc besoin de
|
||||
compiler les ressources via `npm`, ce que je fais à la ligne 15, juste avant de
|
||||
construire toutes les pages du site. Jusqu'à présent, c'est plutôt simple, non ?
|
||||
|
||||
Ensuite, l'étape la plus compliquée (_deploy_). Il faut créer des _secrets_ dans
|
||||
Drone-CI (ici, `ssh_user` et `ssh_password`), mais nous verrons cela un peu plus
|
||||
bas. Pensez simplement à modifier les valeurs de _host_ et _target_ : l'adresse
|
||||
IP du serveur qui va héberge Hugo et le chemin où les fichiers générés par Hugo
|
||||
seront envoyés.
|
||||
|
||||
Ceci dit, ici j'utilise `scp`, mais d'autres services sont disponibles.
|
||||
Consultez la [liste des plugins Drone-CI](http://plugins.drone.io) pour utiliser
|
||||
celui qui convient à votre hébergement.
|
||||
|
||||
Enfin, on a ajouté la directive
|
||||
[_trigger_](https://docs.drone.io/pipeline/triggers/) pour que tout ce processus
|
||||
de publication ne soit déclenché **que** lorsque la branche git _master_ est
|
||||
modifiée, l'idée étant de protéger la branche _master_ en écriture, modifier le
|
||||
contenu dans une nouvelle branche, fusionner avec _master_ une fois terminé,
|
||||
mais là on part dans des considérations philosophiques devops :smile:
|
||||
|
||||
### Drone-CI
|
||||
|
||||
[Drone-CI](https://www.drone.io) est une application d'intégration continue :
|
||||
c'est le genre d'applications qui s'intercalent entre la forge logicielle et les
|
||||
serveurs de mise en production, une position privilégiée qui confère à ces
|
||||
outils beaucoup de puissance et un intérêt considérable. Tests unitaires,
|
||||
construction de ressources, publication automatique, les cas d'usage sont
|
||||
nombreux.
|
||||
|
||||
La documentation de Drone-CI préconise de l'installer sur une machine physique
|
||||
différente du serveur Gitea afin d'éviter les problèmes et de simplifier la
|
||||
configuration. C'est l'option que j'ai choisi, mais en pratique, si vous savez
|
||||
ce que vous faites, vous ne devriez pas avoir de soucis.
|
||||
|
||||
Il faut toutefois prendre en considération les ressources du (des) serveurs. Si
|
||||
vous utilisez des Raspberry Pi par exemple, il vaut peut-être mieux lancer
|
||||
Drone-CI sur un Pi dédié à cet usage.
|
||||
|
||||
Pour que Drone-CI puisse communiquer avec Gitea, il faut aller dans Gitea,
|
||||
votre profil, puis dans l'onglet _Applications_. Là, créez une application
|
||||
_OAuth_. Mettez ce que vous voulez comme nom ("drone", par exemple), et l'URL
|
||||
de redirection, qui correspond à l'URL complète à laquelle vous accèderez à
|
||||
Drone-CI, suffixée par _/login_. Dans mon cas, l'URL de redirection est :
|
||||
|
||||
> https://ci.athaliasoft.com/login
|
||||
|
||||
Validez, et Gitea vous communiquera un certain nombre d'informations à
|
||||
renseigner dans le fichier _docker-compose.yml_ pour Drone-CI, notamment un
|
||||
_Client ID_ et un _Client Secret_, à remplacer ci-dessous.
|
||||
|
||||
_docker-compose.yml_ :
|
||||
|
||||
```yaml {class=not-prose}
|
||||
version: "3"
|
||||
services:
|
||||
drone:
|
||||
image: drone/drone
|
||||
restart: always
|
||||
ports:
|
||||
- "${PORT}:80"
|
||||
environment:
|
||||
- DRONE_GITEA_SERVER=${DRONE_GITEA_SERVER}
|
||||
- DRONE_GITEA_CLIENT_ID=${DRONE_GITEA_CLIENT_ID}
|
||||
- DRONE_GITEA_CLIENT_SECRET=${DRONE_GITEA_CLIENT_SECRET}
|
||||
- DRONE_RPC_SECRET=${DRONE_RPC_SECRET}
|
||||
- DRONE_SERVER_HOST=${DRONE_SERVER_HOST}
|
||||
- DRONE_SERVER_PROTO=https
|
||||
volumes:
|
||||
- ${VOLUME_ROOT}:/data
|
||||
```
|
||||
|
||||
- `DRONE_GITEA_SERVER` correspond à l'URL de votre serveur Gitea
|
||||
- `DRONE_RPC_SECRET` est une clé à générer via la commande `openssl rand -hex 16` (par exemple)
|
||||
- `DRONE_SERVER_HOST` est le nom d'hôte correspondant à l'URL de redirection (donc, dans mon cas spécifique, _drone.git.dern.ovh_)
|
||||
- `VOLUME_ROOT`, un volume docker ou un répertoire dans lequel seront stockées les données de Drone-CI
|
||||
|
||||
### Runners
|
||||
|
||||
En plus de Drone-CI, il faut configurer des
|
||||
[_runners_](https://docs.drone.io/runner/overview/), c'est-à-dire un ou
|
||||
plusieurs services qui vont exécuter les pipelines configurés. Comme je dispose
|
||||
de plusieurs serveurs, j'ai installé un runner par serveur, ce qui permet
|
||||
d'améliorer les performances générales de Drone-CI, mais il est tout à fait
|
||||
possible (et viable) d'avoir un seul runner installé sur la même machine que
|
||||
Drone-CI.
|
||||
|
||||
_docker-compose.yml_ :
|
||||
|
||||
```yaml {class=not-prose}
|
||||
version: "3"
|
||||
services:
|
||||
runner:
|
||||
image: drone/drone-runner-docker
|
||||
restart: always
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock
|
||||
ports:
|
||||
- "3000:3000"
|
||||
environment:
|
||||
- DRONE_RPC_PROTO=http
|
||||
- DRONE_RPC_HOST=drone
|
||||
- DRONE_RPC_SECRET=${DRONE_RPC_SECRET}
|
||||
- DRONE_RUNNER_CAPACITY=${DRONE_RUNNER_CAPACITY}
|
||||
- DRONE_RUNNER_NAME=${DRONE_RUNNER_NAME}
|
||||
```
|
||||
|
||||
Pensez à modifier les variables suivantes pour convenir à votre environnement :
|
||||
|
||||
- `DRONE_RPC_SECRET`, la même clé que celle définie plus haut pour Drone-CI
|
||||
- `DRONE_RUNNER_CAPACITY`, le nombre de pipelines que le runner peut exécuter en même temps (1 est suffisant pour des environnements modestes, 2 ou plus pour des environnements plus musclés)
|
||||
- `DRONE_RUNNER_NAME`, un nom à attribuer au runner pour savoir quel runner a exécuté quoi et quand
|
||||
|
||||
## Performances
|
||||
|
||||
En voyant tout ça, on pourrait se dire que c'est consommateur de ressources. En
|
||||
réalité, tout cela est très, très léger, et très performant. Il faut moins de 30
|
||||
secondes pour déployer en production un nouvel article ; une durée qui serait
|
||||
beaucoup - beaucoup - plus courte s'il n'y avait pas l'étape de compilation CSS
|
||||
avec `npm`.
|
||||
|
||||
La possibilité de tirer partie d'un nombre indéterminé de runners est un gage de
|
||||
scalabilité, même si les performances sont déjà élevées avec un seul serveur,
|
||||
grâce à la sobriété des applications mises en oeuvre.
|
||||
|
||||
J'aime ce qui est rapide et performant, même si cela nécessite un peu de temps
|
||||
pour être mis en oeuvre. Le processus expliqué ici respecte mon cahier des
|
||||
charges.
|
||||
|
||||
## Conclusion
|
||||
|
||||
J'ai présenté ici le déploiement automatisé d'un site statique créé avec Hugo,
|
||||
puisant dans un serveur Gitea, en construisant le site via Drone-CI avant de
|
||||
copier les fichiers sur le serveur de production. C'est **un** cas d'usage parmi
|
||||
d'autres : je me sers également de cette configuration pour créer
|
||||
automatiquement des releases pour certaines de mes librairies, par exemple.
|
||||
|
||||
Le simple fait de parcourir [la liste des plugins](http://plugins.drone.io/) de
|
||||
Drone-CI donne un aperçu de ce qu'il est possible de faire _out-of-the-box_,
|
||||
mais en réalité, il n'y a pas vraiment de limite dans la mesure où on peut
|
||||
facilement créer ses propres plugins, puisque ce ne sont que des containers
|
||||
docker !
|
||||
@@ -0,0 +1,205 @@
|
||||
---
|
||||
date: '2021-09-25'
|
||||
title: L'éco-responsabilité en informatique
|
||||
---
|
||||
|
||||
Derrière le terme très politique de "éco-responsabilité" se cachent de
|
||||
nombreuses ramifications, et je vais m'intéresser aujourd'hui à celles qui
|
||||
concernent spécifiquement l'informatique, et en particulier du point de vue
|
||||
applicatif.
|
||||
|
||||
## Le coût énergétique du code
|
||||
|
||||
Le code informatique a un coût énergétique. On a tendance à l'oublier. Le
|
||||
matériel le plus récent tend vers une efficacité énergétique accrue : un
|
||||
processeur moderne, comparé à un processeur plus ancien doté du même nombre de
|
||||
coeurs et d'une même fréquence, exécutera les instructions qu'on lui donne plus
|
||||
rapidement, mais aussi de façon plus efficiente, en consommant moins d'énergie.
|
||||
Quand on achète du matériel moderne, on fait un geste éco-responsable[^1], mais
|
||||
on peut mieux faire. C'est facile de faire des économies d'énergie en achetant
|
||||
du matériel récent, mais il est possible d'aller beaucoup plus loin avec des
|
||||
_logiciels_ et des _comportements_ éco-responsables. Cela prend tout son sens
|
||||
lorsque l'on est soi-même développeur.
|
||||
|
||||
[^1]: À charge logicielle équivalente. En réalité, il faut tenir compte d'autres facteurs pour que ce geste soit réellement éco-responsable, comme l'âge du matériel remplacé, les matériaux employés (recyclables ou non), etc.
|
||||
|
||||
Il est possible de chiffrer ce coût énergétique. Ce n'est peut-être pas à la
|
||||
portée de tout le monde, mais avec
|
||||
[le matériel adéquat](https://duckduckgo.com/?q=prise+wattmetre&t=osx&iar=shopping&iax=shopping&ia=shopping),
|
||||
on peut facilement l'évaluer. Il suffit de mesurer la consommation de la machine
|
||||
sur laquelle on fait le test, avec et sans l'application qu'on veut tester, et
|
||||
faire la différence. C'est ainsi que j'ai appris que MariaDB consomme plus
|
||||
d'énergie que PostgreSQL, que nginx consomme plus que Caddy, etc.
|
||||
|
||||
Du coup, puisqu'il existe une différence substantielle et mesurable, entre
|
||||
différentes applications qui effectuent le même type de tâches, on peut pousser
|
||||
l'idée un peu plus loin en tant que développeur, et se demander : "Combien
|
||||
d'énergie consomme le code que je produis ?"
|
||||
|
||||
On peut avoir des surprises, et pas que des bonnes... surtout que cette
|
||||
consommation dépend de facteurs divers.
|
||||
|
||||
## Le coût énergétique du réseau
|
||||
|
||||
Car, pour peu que l'application considérée effectue des opérations sur le
|
||||
réseau, la consommation indirecte de cette application peut rapidement grimper
|
||||
en flèche. Une consommation qui ne se verra pas en consultant la consommation
|
||||
immédiate de la machine sur laquelle tourne l'application, puisqu'il faut aussi
|
||||
prendre en considération l'activité du point d'accès sans-fil, du switch, du
|
||||
routeur, du modem, bref, de _toute_ l'infrastructure réseau, non seulement du
|
||||
point de vue du client (qui initie la connexion) mais aussi du point de vue du
|
||||
serveur (qui reçoit la requête).
|
||||
|
||||
C'est un exemple très personnel et peut-être pas représentatif de la majorité
|
||||
des cas d'usage, mais lors d'accès réseaux intensifs, la consommation électrique
|
||||
de mon réseau informatique dans sa globalité peut facilement passer du simple au
|
||||
double. C'est notamment le cas pendant les mises à jour des images docker
|
||||
employées sur mes serveurs : je passe d'une consommation globale de 36W en
|
||||
moyenne à parfois près de 80W[^2].
|
||||
|
||||
[^2]: Dans ces 36 à 80W, je compte la consommation de mes trois serveurs, d'un point d'accès sans-fil, et d'un switch 16 ports en rack. La Freebox Revolution n'est pas comptée dans cette mesure, mais je sais qu'elle consomme à elle-seule près de 40W, notamment à cause de son disque dur mécanique.
|
||||
|
||||
## Développer éco-responsable
|
||||
|
||||
Si vous êtes développeur et que :
|
||||
|
||||
- vous vous souciez de l'optimisation extrême de votre code,
|
||||
- vous n'implémentez que les fonctionnalités nécessaires et évitez de réinventer la roue,
|
||||
- vous vous assurez de suivre les bonnes pratiques de réutilisation du code, sa simplification, sa compartimentation,
|
||||
- vous surveillez régulièrement les ressources systèmes consommées par votre application,
|
||||
|
||||
vous êtes déjà éco-responsable ! Dans le cas contraire, il va falloir reprendre
|
||||
les bases. Dans tous les cas, il y a quelques pistes à explorer, quelques
|
||||
situations à prévoir.
|
||||
|
||||
Par exemple, il est possible qu'à l'avenir, les applications se voient
|
||||
catégorisées par une
|
||||
[étiquette-énergie](https://fr.wikipedia.org/wiki/Étiquette-énergie), exactement
|
||||
comme tout matériel électrique actuellement vendu en Europe. Être capable de
|
||||
développer des applications efficientes devrait déjà être un critère de choix
|
||||
pour les entreprises, si elles veulent être prêtes le jour où cela arrivera :
|
||||
dans une société dont la demande énergétique est en constante hausse et où la
|
||||
production peine à suivre à cause de la raréfaction du nucléaire, se présenter
|
||||
comme une entreprise dont les logiciels sont efficients sera aussi important
|
||||
pour les clients et prospects que d'annoncer vendre des produits issus de
|
||||
matériaux recyclables.
|
||||
|
||||
<details class="update"><summary>Mise à jour du 24 décembre 2021</summary>
|
||||
|
||||
Un pas vers une telle catégorisation a été fait hier :
|
||||
|
||||
* [Mesurer le CO2 selon les gigaoctets consommés : l’idée qui consterne le secteur du numérique](https://www.numerama.com/tech/803201-mesurer-le-co2-selon-les-gigaoctets-consommes-lidee-qui-consterne-le-secteur-du-numerique.html)
|
||||
|
||||
Je ne m'exprimerai par sur la forme, apparemment les geeks ont l'air de dire que
|
||||
c'est mal branlé, personnellement j'estime que c'est un pas en avant, une étape
|
||||
avant l'imposition de cette information par application, plus compliquée à
|
||||
mettre en place sur le plan juridique.
|
||||
|
||||
</details>
|
||||
|
||||
Dans l'absolu, on a amélioré les technologies pour pouvoir faire plus de choses.
|
||||
Le débit des connexions Internet a explosé grâce à la fibre optique et la 4/5G,
|
||||
les processeurs sont de plus en plus puissants tout en étant plus économes en
|
||||
énergie, le cloud permet de déplacer l'exécution de code à l'extérieur du
|
||||
réseau, etc. En somme, on a amélioré la qualité de vie des faignants et des
|
||||
producteurs de spam. Tant de technologies déployés pour afficher des publicités
|
||||
plus vite qu'avant ? Pour être pistés plus rapidement qu'avant ?
|
||||
L'éco-responsabilité passera forcément par l'abandon de ces pratiques, dont le
|
||||
coût énergétique n'est jamais pris en charge par leur producteur et toujours par
|
||||
le client. Une pratique commerciale abominable du début à la fin, à laquelle de
|
||||
nombreux développeurs ont participé. Une pratique qui doit cesser. Si on dispose
|
||||
de meilleures technologies, il faut aussi en faire un meilleur usage.
|
||||
|
||||
## Des usages éco-irresponsables
|
||||
|
||||
Malheureusement, les applications les plus populaires sont loin d'être des
|
||||
références en matière de consommation énergétique. Pas forcément parce qu'elles
|
||||
sont mal conçues, ou parce qu'elles intègrent des algorithmes complexes pour
|
||||
déterminer quelles publicités vous afficher à vous spécifiquement (...), mais
|
||||
aussi parce qu'elles n'optimisent pas ce qu'elles font. Je pense en particulier
|
||||
aux applications de vidéo-conférence, propulsées sur le devant de la scène par
|
||||
la série de confinements connue entre 2019 et 2021. Le coût énergétique de la
|
||||
vidéo-conférence est [prohibitif](https://www.forbes.com/sites/petersuciu/2021/04/16/do-we-need-to-worry-that-zoom-calls-use-too-much-energy/),
|
||||
et totalement inconnu ou ignoré des participants qui n'ont qu'un seul objectif :
|
||||
communiquer. Il y a pourtant de nombreux paramètres à prendre en compte :
|
||||
|
||||
- l'équipement informatique requis pour faire de la vidéo-conférence : ordinateurs, écrans, webcams, micros, et bien sûr, l'infrastructure réseau entre les différentes machines
|
||||
- les logiciels employés et leur paramétrage, y compris le système d'exploitation (un mode sombre consomme moins d'énergie qu'un mode clair), les réglages du matériel (baisser la luminosité des écrans permet de gagner quelques watts)
|
||||
- la distance entre les différents ordinateurs
|
||||
- etc.
|
||||
|
||||
Le matériel est de plus en plus efficient en énergie. Mais ce n'est pas encore
|
||||
le cas des applications où il reste beaucoup de travail à faire. Et ce n'est pas
|
||||
encore suffisant : comme certains gestes ont dû être appris au cours de ces
|
||||
dernières décennies, comme le tri sélectif, éteindre le robinet pendant qu'on se
|
||||
brosse les dents, etc., il faudra apprendre à mieux utiliser son informatique.
|
||||
Est-ce qu'une vidéo-conférence est réellement nécessaire ? Cette réunion ne
|
||||
peut-elle pas être réalisée uniquement en audio ? Et du point de vue du
|
||||
développeur : est-ce que j'ai réellement besoin d'un accès réseau pour effectuer
|
||||
telle ou telle opération ?
|
||||
|
||||
## Les travers du cloud
|
||||
|
||||
Le cloud, comme dirait la [FSF](https://www.fsf.org/), c'est stocker ses données sur un ordinateur qui
|
||||
ne nous appartient pas. Quand vous installez une application sur votre téléphone
|
||||
portable, posez-vous la question : est-ce que cette application m'apporte une
|
||||
plus-value par rapport à visiter directement le site depuis mon navigateur ? En
|
||||
général, la réponse est soit "non", soit une mauvais réponse, telle que : "oui
|
||||
parce que c'est mieux intégré à mon téléphone". En réalité, cela dépend de ce
|
||||
que fait l'application par rapport au site, et surtout _comment_ elle le fait.
|
||||
Si l'essentiel du travail est effectué sur votre téléphone, tant mieux, mais si
|
||||
de multiples échanges avec le serveur sont nécessaires, c'est là que la
|
||||
consommation explose.
|
||||
|
||||
Comment le vérifier ? Par aucun moyen simple à l'heure actuelle. Soit
|
||||
l'application est sous licence libre, auquel cas vous pouvez consulter le code
|
||||
source pour voir si l'application est bien écrite, soit elle est sous licence
|
||||
propriétaire et il faut utiliser des outils appropriés pour évaluer la quantité
|
||||
et la qualité de ses accès réseau. Une tâche impossible pour le commun des
|
||||
mortels, et fastidieuse à réaliser quand on maitrise le sujet, considérant la
|
||||
quantité d'applications à tester. J'aimerais bien voir, sur mon téléphone, en
|
||||
plus de la consommation en "_data_" d'une application donnée, sa consommation
|
||||
électrique estimée. On aurait sans doute des informations intéressantes, et cela
|
||||
inciterait sûrement à la production d'applications de meilleure qualité...
|
||||
|
||||
En outre, stocker ses documents dans le cloud est très consommateur d'énergie,
|
||||
puisqu'on parle souvent de fichiers de plusieurs méga-octets. Une photo de bonne
|
||||
résolution, prise avec votre téléphone portable, pèse en moyenne 5Mo à 10Mo. Mes
|
||||
photos prises avec mon APN en RAW peuvent peser 50Mo. Les fonds d'écrans,
|
||||
sonneries, pièces jointes d'email, musiques, vidéos, etc. vont transiter sur le
|
||||
réseau, et utiliser de l'énergie. L'énergie de votre téléphone, de l'antenne du
|
||||
réseau mobile, du datacenter où seront stockées ces données, etc.
|
||||
|
||||
Auto-héberger tout cela **est éco-responsable**, en limitant cette consommation
|
||||
d'énergie à votre propre infrastructure. Si vous êtes une entreprise, et du seul
|
||||
point de vue de l'énergie, cela vous reviendra moins cher que payer un
|
||||
intermédiaire qui répercutera ces coûts sur votre facture, avec une marge.
|
||||
|
||||
Avec le cloud, on multiplie le coût énergétique de chaque opération réseau.
|
||||
Donc, en tant que développeur, demandez-vous, à chaque ligne de code créée qui
|
||||
envoie une requête à un serveur distant, si cette ligne est parfaitement
|
||||
optimisée et ne surchargera pas le serveur en question. Exemple tout bête :
|
||||
arrêtez de faire des pages HTML où vous déclarez 50 fichiers javascript et 50
|
||||
feuilles de styles : concaténez. Ce n'est pas parce que HTTP/2 permet de faire
|
||||
des requêtes en parallèle qu'il faut en abuser...
|
||||
|
||||
## Les bénéfices de l'éco-responsabilité
|
||||
|
||||
Évidemment, il y a le gain environnemental. Moins de consommation d'énergie
|
||||
signifie moins d'émissions de CO2. Il y a également le coût financier :
|
||||
l'énergie est chère, et le sera de plus en plus si on continue à scier la
|
||||
branche sur laquelle on est assis en "sortant du nucléaire".
|
||||
|
||||
Mais de façon plus pragmatique, être éco-responsable en informatique signifie
|
||||
aussi augmenter le délais entre deux charges de batterie de téléphone ou
|
||||
d'ordinateur portable, réduire la charge système et donc disposer d'un
|
||||
périphérique plus agréable à utiliser, peut-être au point de devoir le remplacer
|
||||
moins souvent, d'où encore plus d'économies et... une meilleure
|
||||
éco-responsabilité.
|
||||
|
||||
Les gains côté développeur ne sont pas moins intéressants : être éco-responsable
|
||||
signifie moins de code à maintenir, un code plus efficace, plus facile à
|
||||
analyser, à relire, donc plus de temps pour créer de nouvelles fonctionnalités
|
||||
et moins de temps à débugguer, donc moins de bugs et plus vite corrigés, donc
|
||||
clients satisfaits, employeur satisfait, meilleure qualité de vie au travail,
|
||||
licornes et arcs-en-ciel.
|
||||
Reference in New Issue
Block a user