Comment j’ai mis en ligne mon site fait avec Webstudio pour limiter au maximum son impact environnemental

La recommendation la plus évidente pour limiter l’impact environnemental de son site est de l’héberger sur un serveur respectueux de l’environnement.

Aujourd’hui, je vous fais part de mon expérience au moment où j’essaie moi-même de passer mon site sur un server “vert”.

Qu’est-ce qu’un serveur respectueux de l’environnement ?

Il n’existe pas de définition précise. Votre serveur doit mettre en place des actions pour limiter son impact sur l’environnement. On peut lister quelques unes des plus communes :

• Être alimenté par des énergies renouvelables
• Compenser ses émissions - par exemple via une taxe ou des actions de reforestation
• Utiliser des machines conçues pour durer dans le temps
• Avoir un système de recyclage des machines

Il existe cependant des initiatives pour standardiser et valider les initiatives éco-responsables des data centers.

L’une des références dans le domaine à l’échelle mondiale est la Green Web Foundation. Cette association a créé une base de données regroupant les fournisseurs d'hébergement que l’on peut qualifier comme éco-responsable. C’est ce répertoire que je vais utiliser pour trouver le mien.

Choisir son fournisseur de services en ligne éco-responsable

Avant de commencer, je vous donne le contexte. J’ai un site, celui-là même où vous lisez cet article, et je cherche à l’héberger de manière éco-responsable en France.

J'ai fait le choix de faire mon site sur Webstudio, une alternative à Webflow. Utiliser un générateur de site no-code me permet de gérer mon projet un peu plus facilement et de faire des modifications en quelques clics. Mais niveau impact environnemental ce n'est pas idéal. En effet, je dois héberger un site ET un "builder". Le builder c'est l'interface sur laquelle je modifie mon site. Donc mon objectif c'est de trouver comment héberger les deux, site et builder, de manière responsable.

Concernant le builder, je n’ai pas besoin qu’il soit en ligne 24h/24h donc je vais simplement le “self-host”. En d’autres termes, je vais le faire tourner sur mon ordinateur quand j’en ai besoin et c’est tout.

Concernant le site web, je me rends sur https://app.greenweb.org/directory et je vais chercher un fournisseur vert en France avec une gamme de prix intéressante pour ce que je veux héberger. Je veux trouver une offre qui répond à mes trois principaux critères :

• Une solution clairement positionnée pour le respect de l’environnement
• Un produit très flexible pour que je puisse installer mon site (et potentiellement d’autres projets) comme je le souhaite
• Un tarif inférieur à 10e par mois

Je choisis finalement l’offre VPS (Serveur Privé Virtuel) de Ex2. Ex2 est une entreprise canadienne qui offre des solutions d’hébergement avec des data centers en France. Ils sont spécialisés dans l’hébergement respectueux de l’environnement, et leur offre la plus basique commence à 8€50.

Attention, à partir de maintenant l'article devient un peu technique 🧑‍🏫

Le self-hosting comme hébergement durable

Objectif numéro 1 : héberger sur ma machine mon builder Webstudio.

Je suis les instructions que me donne Webstudio : https://docs.webstudio.is/contributing/contributing-for-developers. Je vous laisse consulter la page pour voir le détail, mais globalement il s’agit de copier le code source de Webstudio sur son ordinateur et de le lancer localement.

Une fois l’application installée, il suffit de se connecter en utilisant le “login with secret”. Le "secret" est simplement une variable d’environnement à ajouter dans un fichier .env.development.

Maintenant je peux créer et éditer mes projets directement sur mon ordinateur ! Plus besoin d’utiliser la version en ligne de Webstudio, je peux même supprimer mon compte 👍

Récupérer mon projet Webstudio pour pouvoir le publier

Une fois le builder lancé sur mon ordinateur, je vois que je ne peux pas importer mon projet Webstudio que j’avais commencé en ligne. Je recommence donc un projet de 0. Je peux tout de même copier/coller les éléments principaux. Une grosse trentaine de minutes plus tard, mon projet est prêt à être publié.

Avec la version self-host du builder, ce n’est pas possible d’utiliser le bouton export ou publish pour mettre ses projets en ligne, il faut utiliser la CLI.

La CLI de Webstudio c’est ce qui va me permettre d’interagir avec Webstudio en utilisant des lignes de commandes dans le terminal. Je suis les instructions détaillées que vous pouvez retrouver ici : https://docs.webstudio.is/university/self-hosting.

Il faut d’abord installer Webstudio en utilisant NPM :

npm install -g webstudio

Il suffit ensuite de lancer la commande webstudio et de suivre les consignes :

• Se connecter à son interface Webstudio
• Copier un lien via le bouton “Share” puis le coller dans le terminal (ici je récupère bien l’URL sur mon instance du builder lancée localement sur mon ordinateur)
• Choisir comment déployer son projet : docker ou SSG

Et c’est là que ça se complique. Idéalement je voudrais faire un export SSG (Static Site Generation) avec uniquement des fichiers HTML/CSS/JS. Cette option permettrait d’enlever beaucoup de complexité au moment de passer le site en ligne, et permettrait d’avoir une version de mon site que je peux publier en ligne la plus minimaliste et la plus performante possible. Malheureusement, avec Webstudio, cette option ne permet pas d’exporter les pages générées dynamiquement. Les pages de mes articles de blog sont en effet construites en faisant des requêtes au CMS Hygraph.

Je vais donc choisir Docker pour le moment. Je vais pas m'épancher sur Docker, si vous êtes arrivé·e là j'imagine que vous avez une vague idée de ce que c'est. Pour faire simple, Docker permet d'exécuter des applications dans des environnements isolés, en empaquetant le code et ses dépendances pour garantir une exécution cohérente sur n'importe quel système.

Publier mon site sur un serveur éco-responsable

Les choses sérieuses commencent ici. Mon VPS est disponible, mon site est prêt à être publié, maintenant il faut combiner les deux. Je vais détailler les étapes pour le système d'exploitation installé sur mon serveur : Ubuntu 20.04 LTS x64.

1️⃣ Me connecter à mon serveur.

Je récupère l'adresse IP de mon serveur sur l'interface d'Ex2 puis ⁠j'ouvre un terminal sur mon mac. Je me connecte via ssh :

⁠⁠ssh root@<adresse_ip_de_mon_serveur>

⁠On me demande un mot de passe, celui ci est aussi disponible l'interface d'Ex2.

Ensuite, j'ajoute un utilisateur :

⁠adduser gauvain

Je lui donne le droit d'utiliser sudo :

⁠usermod -aG sudo gauvain⁠

Je ferme le terminal :

exit

Étape 1 terminée ✅

2️⃣ Installer Docker sur mon serveur.

Je me reconnecte à mon serveur avec l'utilisateur que je viens de créer (et son mot de passe correspondant) :

⁠⁠⁠ssh gauvain@<adresse_ip_de_mon_serveur>

Puis je suis les instructions pour installer Docker que vous pouvez retrouver ici : https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository et https://docs.docker.com/engine/install/linux-postinstall/ (dans cet ordre).

⁠Étape 2 terminée ✅

3️⃣ Mettre le code source de mon site sur Github.

⁠Sur mon ordinateur, je retourne sur le code source de mon site que j'ai récupéré avec la CLI de Webstudio et je le lie à un repository sur Github (par ici si vous ne savez pas comment faire).

⁠Étape 3 terminée ✅

4️⃣ Enregistrer mon image Docker sur le Github Container Registry.

⁠Placer mon image Docker dans le Github container registry va me permettre d'y accéder depuis mon serveur. Je dois d'abord créer un Personnal Access Token : https://github.com/settings/tokens/new?scopes=write:packages,read:packages,delete:packages.

Ensuite, je pousse mon image sur le Github container registry. Dans un terminal je rentre les commandes suivantes :

⁠export CR_PAT=<mon_personnal_access_token>

echo $CR_PAT | docker login ghcr.io -u <mon_username_github> --password-stdin

docker build . -t ghcr.io/<mon_username_github>/<nom_de_mon_image>:latest && docker push ghcr.io/<mon_username_github>/<nom_de_mon_image>:latest

Je viens de déclarer une variable, que j'utilise ensuite pour me connecter et récupérer mon image, puis je build mon image et je la pousse sur le Github container registry.

⁠Étape 4 terminée ✅

5️⃣ Utiliser docker compose pour lancer le projet sur mon serveur.

⁠Je me re-connecte à mon serveur :

⁠⁠⁠⁠ssh gauvain@<adresse_ip_de_mon_serveur>

Je créé un dossier pour mon projet :

⁠mkdir gauvain-dev

Je rentre dans ce dossier et je créé un nouveau fichier :

⁠cd gauvain-dev && vi docker-compose.yml

⁠Dans ce fichier je rentre les lignes suivantes :

services:
  frontend:
    container_name: frontend
    image: ghcr.io/<mon_username_github>/gauvain-dev:latest
    environment:
       - DOMAINS=<adresse_ip_de_mon_serveur>
    ports:
       - 80:3000

Je peux ensuite lancer mon site :

docker compose up -d

Maintenant, quand je vais sur l'adresse IP de mon serveur, mon site est en ligne !

⁠Étape 5 terminée ✅

6️⃣ (bonus) Automatiser le tout avec des Github actions

Faire toutes ces actions manuelles à chaque fois que je fais des manipulations sur mon site va vite devenir ennuyant. Je décide donc d'utiliser des Github actions pour automatiser tout ce processus dès que le repository Github est modifié.

Je me re-connecte à mon serveur puis je créé une clé SSH :

ssh-keygen -t rsa -b 4096

Je l'ajoute au fichier des clés autorisées :

cat <path/to/public/key> >> ~/.ssh/authorized_keys

Je copie le contenu de ma clé :

more ~/.ssh/id_rsa

Je reviens sur mon repository Github et je rajoute les secrets suivants :

• SSH_PRIVATE_KEY avec le contenu de la clé
• SSH_USER avec nom utilisé pour le SSH
• SSH_HOST avec l'adresse IP de mon serveur
• WORK_DIR avec le chemin du dossier qui contient le fichier docker-compose.yml

Sans trop rentrer dans les détails, parce que ce n'est pas le propos, voici le contenu du fichier .github/workflows/docker-publish.yml pour définir mes actions Github :

name: publish

on:
  push:
    branches: [ "main" ]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: <mon_username_github>/gauvain-dev:latest

jobs:
  publish:
    name: publish image
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Login
      run: |
        echo ${{ secrets.PAT }} | docker login ghcr.io -u ${{ github.actor }} --password-stdin
    - name: Build and Publish Frontend
      run: |
        docker build . --tag ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
        docker push ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}

  deploy:
    needs: publish
    name: deploy image
    runs-on: ubuntu-latest
    
    steps:
    - name: install ssh keys
      run: |
        install -m 600 -D /dev/null ~/.ssh/id_rsa
        echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
        ssh-keyscan -H ${{ secrets.SSH_HOST }} > ~/.ssh/known_hosts
    - name: connect and pull
      run: ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "cd ${{ secrets.WORK_DIR }} && docker compose pull && docker compose up -d && exit"
    - name: cleanup
      run: rm -rf ~/.ssh

⁠Étape 6 terminée ✅

7️⃣ Paramétrer un domaine pour mon site

Une fois mon site en ligne sur l'adresse IP de mon serveur, je retourne sur mon fournisseur de nom de domaine et je rajoute un enregistrement DNS "A" dans lequel j'indique l'adresse IP de mon serveur.

⁠Étape 7 terminée ✅

Conclusion

À la relecture de cet article, je me rends compte que la complexité de passer mon site sur un serveur vert va en décourager plus d'un. On perd beaucoup de facilité d'utilisation, mais on apprend beaucoup de choses et on reprend le contrôle sur ses outils.

J'espère au moins que le partage de mon expérience pourra faciliter la vie de ce qui se lance dans la même aventure. Ce que je retiens : avec des solutions open-source et un peu de temps il y a beaucoup de solutions pour construire un web moins nuisible ! 🌱