Hébergement on Zwindler's Reflection

Je réessaye les sites statiques (Bloggrify) chez Clever Cloud

Mon, 07 Jul 2025 09:00:00 +0200

Introduction

Pour celles et ceux qui suivent mes péripéties d’hébergement de blog, vous savez que j’ai une relation compliquée (le fameux “it’s complicated” sur Facebook) avec Clever Cloud. J’ai déjà écrit à ce sujet dans deux articles précédents :

Pour finalement abandonner Clever Cloud et revenir sur une VM IONOS que je gère moi-même (voir Ça bouge encore sur le blog).

Mais depuis, Clever Cloud a ajouté les apps statiques à son catalogue. Plus besoin de passer par un runtime Apache + PHP, ce qui était effectivement un peu overkill pour un site Hugo statique (et pas compatible avec l’offre Pico, donc fallait prendre au minimum Nano à ~7€ par mois).

Du coup, je me suis dit : pourquoi ne pas retenter l’expérience ?

Comme Julien Wittouck m’a devancé de 3 semaines et a fait un article sur l’hébergement de sites statiques avec Hugo via ce nouveau type d’app chez Clever Cloud, vous pouvez aller lire son post ici, je n’ai pas envie de faire la même chose.

Pour ce test, j’ai choisi d’utiliser un autre site que celui-ci : 50ndk.zwindler.fr, qui me sert pour faire la promotion de mon livre.

Il est actuellement hébergé sur GitHub Pages et utilise le moteur Bloggrify (un des projets d’Hugo Lassiège, quelqu’un que j’apprécie énormément dans l’écosystème tech français).

Le principe est globalement le même qu’avec Hugo, à quelques petites différences près. C’est un site statique généré tout pareil, mais c’est Nuxt sous le capot et ça va nous être utile. Il y a quelques petites différences aussi depuis mon dernier test de 2023 que je ne manquerai pas de souligner.

Les sources du site sont disponibles ici si vous êtes curieux / curieuse :

https://github.com/zwindler/50ndk

Prérequis

On pourrait aller créer l’application dans l’UI. Normalement, les “tuiles” Static, Linux et VLang sont disponibles à tout le monde depuis le 4 juillet. J’ai un petit accès anticipé (merci David) mais je n’en ai pas beaucoup profité 🙃 (occupé avec le livre). Grosso modo c’est comme les autres types d’Apps chez Clever, vous ne serez pas perdus.

Bon, en WebUI c’est bien mais c’est plus rigolo de le faire en CLI.

clever login
Opening https://console.clever-cloud.com/cli-oauth?cli_version=3.0.2&cli_token=xxxxxxxxxxxxx in your browser to log you in…
Login successful as Denis GERMAIN <denis@domain.org>

Euh, je vois 3.0.2 dans l’URL ??? Je ne suis pas à jour. Visiblement j’avais installé la CLI clever avec npm (je ne m’en souviens pas). Plus simple, il y a aussi des dépôts .deb (ou brew, autre selon votre distribution).

clever version
3.0.2
╭─────────────────────────────────────────╮
│ │
│ Update available 3.0.2 → 3.13.1 │
│ Run npm i -g clever-tools to update │
│ │
╰─────────────────────────────────────────╯

Un petit npm i -g clever-tools et ça va mieux :)

$ clever version
3.13.1

Configuration de l’app

Un petit clever create avec le type de l’app et c’est parti !

denis@coucou % clever create --type static
✓ Application 50ndk successfully created!
Type ⬢ Static
ID app_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Org ID user_yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
Name 50ndk
Zone par
Next steps:
! Commit your changes first:
$ git add .
$ git commit -m "My changes"
→ Run clever deploy to deploy your application
→ Manage your application at: https://console.clever-cloud.com/goto/app_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Note : si votre app est hébergée sur GitHub, vous pouvez rajouter aussi --github OWNER/REPO à la ligne de commande précédente. J’en parle plus tard, mais lisez tout avant de le faire.

Comme fin 2023, je vais avoir besoin de 2 machines différentes. Une qui va construire mon site statique, une qui va le servir. Et du coup, là comme je n’ai pas Apache, je peux avoir accès à une pico et économiser quelques euros à la fin de l’année :

$ clever scale --build-flavor M
App rescaled successfully
$ clever scale --flavor pico
App rescaled successfully

Dans mon test précédent avec Hugo+Clever, j’avais besoin de spécifier dans quel dossier le contenu statique doit être servi (et aussi quel dossier la machine qui construit doit partager avec la machine qui sert).

Dans le cas de Bloggrify, tout est dans .output/public. MAIS comme c’est du Nuxt, David m’a dit que je n’en avais pas besoin parce que Clever détecte automatiquement que c’est du Nuxt grâce au fichier nuxt.config.ts à la racine du projet.

Inutile donc de spécifier les variables CC_WEBROOT, CC_OVERRIDE_BUILDCACHE (pour pointer sur .output/public) CC_PRE_BUILD_HOOK et CC_BUILD_COMMAND (les commandes npm).

Plutôt une bonne surprise :).

Déploiement de l’application

À partir de là, on peut essayer de faire un premier déploiement à la main. Pour rappel, soit on envoie un commit sur le remote spécial créé par Clever (cf le message lors de la commande clever create), mais je vais préférer utiliser la commande clever deploy, déjà disponible en 2023 lors de mon premier test, car je l’utiliserai pour automatiser le workflow plus tard.

dgermain@dgermain-mac 50ndk % clever deploy
🚀 Deploying 50ndk
 Application ID app_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 Org ID user_yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy

🔀 Git information
 ! App is brand new, no commits on remote yet
 Local commit aaaaaa [will be deployed]

La première partie du processus va donc lancer une machine de taille M dans le but d’accélérer un peu le temps de construction :

🔄 Deployment progress
 → Pushing source code to Clever Cloud…
 ✓ Code pushed to Clever Cloud
 → Waiting for deployment to start…
 ✓ Deployment started (deployment_zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz)
 → Waiting for application logs…
 ...

Clever va détecter tout seul que j’ai du Nuxt, lancer un npm install pour installer les prérequis pour Bloggrify, puis le npm run generate pour générer le code HTML statique.

[...]
2025-07-07T10:23:47.847Z Deploying commit ID defc0be02d44ace246127e11a17d4f359262ccfb
2025-07-07T10:23:47.847Z Nuxt.js configuration file detected
2025-07-07T10:23:47.847Z Running build command: npm i && npm run generate && mv .output/public cc_static_autobuilt
[...]
2025-07-07T10:24:48.809Z [nitro] ℹ Initializing prerenderer
2025-07-07T10:24:52.533Z [nitro] ℹ Prerendering 8 initial routes with crawler
2025-07-07T10:24:52.598Z [nitro] ├─ /robots.txt (17ms)
2025-07-07T10:24:52.841Z [nitro] ├─ /200.html (296ms)
2025-07-07T10:24:52.842Z [nitro] ├─ /404.html (297ms)
2025-07-07T10:24:52.964Z [nitro] ├─ /api/search (415ms)
2025-07-07T10:24:52.965Z [nitro] ├─ /sitemap.xml (417ms)
2025-07-07T10:24:52.965Z [nitro] ├─ /rss.xml (416ms)
2025-07-07T10:24:53.105Z [nitro] ├─ / (564ms)
[...]

Une fois le generate terminé, la machine de construction génère un artefact contenant notre site, et passe la main à la machine qui va servir le trafic :

2025-07-07T10:24:55.843Z ✔ You can now deploy .output/public to any static hosting!
2025-07-07T10:24:56.137Z Creating build cache archive…
2025-07-07T10:24:56.197Z build cache archive successfully created
2025-07-07T10:24:56.197Z No cron to setup
2025-07-07T10:24:56.213Z Uploading application build cache archive… file is 21M before compression.
2025-07-07T10:24:56.899Z 2025-07-07T10:24:56.899385Z INFO multipart_upload_lib::uploader: Uploaded part=1
2025-07-07T10:24:57.041Z 2025-07-07T10:24:57.041879Z INFO multipart_upload_lib::uploader: Completed the multipart upload
2025-07-07T10:24:57.350Z Done uploading build cache archive
2025-07-07T10:24:57.350Z Build succeeded in 1 minute and 14 seconds

11 secondes plus tard, le site de promotion de mon livre est déployé sur Clever Cloud

2025-07-07T10:25:28.425Z Serving static website from /cc_static_autobuilt
2025-07-07T10:25:28.425Z Launching 'static-web-server' on port 8080
2025-07-07T10:25:28.425Z No cron to setup
2025-07-07T10:25:28.425Z Successfully deployed in 0 minutes and 10 seconds

✓ Access your application: https://app-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.cleverapps.io
→ Manage your application: https://console.clever-cloud.com/goto/app_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Ajouter un domaine

Comme chez tous les PaaS, il est évidemment possible d’ajouter un domaine de manière à ce que les requêtes entrantes n’aient pas besoin de se faire sur l’URL en cleverapps.io

% clever domain add 50ndk.zwindler.fr
Your domain has been successfully saved

Une fois le FQDN associé, il est possible d’ajouter un CNAME chez votre gestionnaire de nom de domaine :

Automatiser le `clever deploy`

Imaginons que je sois un fainéant ou que je n’aie pas envie d’installer clever CLI sur tous les postes où je travaille. Admettons que j’aie envie qu’une nouvelle version de mon site soit automatiquement déployée dès que je pousse un commit sur GitHub.

deploy-to-clever-cloud

Dans l’article Planifier les posts de mon blog Hugo sur Clever Cloud, j’avais exploré la piste d’un Cron pour redéployer régulièrement mon site, notamment pour que les posts publiés dans le futur soient postés “au bon moment”.

J’avais aussi trouvé une GitHub Action tierce de quelqu’un (47ng) qui a l’air très bien mais que je ne connais pas :

https://github.com/marketplace/actions/deploy-to-clever-cloud

J’ai testé, elle fonctionne, mais j’étais moyen chaud à l’époque de déléguer mes creds à Github (les fameuses variables CLEVER_TOKEN et CLEVER_SECRET affichées lors du clever login), qui en retour les aurait injecté à cette “action”.

Et ben ça tombe bien parce qu’il y a deux nouvelles pour répondre à ces problématiques.

preview par PR

La première, c’est qu’il existe plusieurs façons d’automatiser les déploiements avec Clever Cloud. Je ne sais pas si elle existait à l’époque, mais en tout cas je l’ai trouvée aujourd’hui ;-P.

On peut faire des environnements de preview par PR (depuis 2024) :

Je ne vais pas dans cet article aborder cette action qui permet de déployer des apps en préview par PR car je n’en ai pas du tout le besoin pour ce site secondaire. Cela dit, si jamais j’ai une grosse mise à jour avec breaking changes, ça pourra valoir le coup de jeter un œil.

Créer des tokens de CI

La seconde, c’est qu’il est possible de créer des tokens (là encore, je ne sais plus si c’était possible en 2023), qu’il sera possible de révoquer en cas de leak.

https://www.clever-cloud.com/developers/api/howto/#request-the-api

Et avec ces tokens, on peut se faire sa propre CI :

https://www.clever-cloud.com/developers/doc/ci-cd/custom-scripts/

Note : j’ai cependant l’impression qu’il n’y a pas encore de scope sur le token. Donc en termes de sécu, c’est mieux car je peux les révoquer, mais s’il y a un leak, on a accès à tout mon compte, pour l’instant (sauf si j’ai mal compris).

Déploiements depuis GitHub (ou GitLab)

Mais le plus simple ici, c’est d’utiliser une fonctionnalité de Clever qui existe depuis “toujours” mais dont j’ignorais l’existance : les déploiements via Github.

Si vous voulez utiliser cette fonctionnalité, il faudra par contre autoriser Clever Cloud à lister vos dépôts préalablement (ce qui peut être un problème pour vous), et vous ne pourrez plus pousser des commits avec clever deploy ou git push sur le git remote de clever (vous prendrez une erreur 401).

Clever Cloud provides a GitHub integration to deploy any repository hosted on GitHub to Clever Cloud

On configure ça grâce au --github de tout à l’heure !

A partir du moment où c’est fait, il n’y a rien à faire… le rebuild sera déclenché dès que je pousserai un nouveau commit sur ma branche Github :)

commit 788465fb980c09e597872a3b510ac44fdaa27d48 (HEAD -> main, origin/main, origin/HEAD)
Author: Denis GERMAIN <denis@example.com>
Date: Fri Jul 4 16:31:11 2025 +0200
test commit

Note : on peut spécifier quelle branche on veut envoyer en prod dans les paramètres de l’application :

Conclusion

Clever Cloud a énormément bougé ces derniers mois, avec beaucoup de nouvelles apps, de nouvelles fonctionnalités (la plus grosse étant Materia, ainsi que tout le travail autour de l’IA).

Les static apps (et Linux, et V) pourraient presque paraître anecdotiques, mais couplées aux autres améliorations (tokens, Grafana managé avec les stats), ce n’est pas le même produit qu’en 2023.

C’est cool à voir :)

Un an dans le nua.ge

Thu, 06 Oct 2022 22:00:00 +0200

C’est l’histoire d’un cloud

Vous vous en souvenez peut-être ?

L’an dernier, en novembre, un certain nombre de comptes techs twitter recevaient une box contenant des codes pour tester un tout nouveau fournisseur cloud, fièrement Français, du nom de nua.ge.

J’avais été un peu surpris de recevoir, quelques mois plus tôt, un message de la part d’Iris, pour me demander si je voulais bien tester avec quelques autres “happy few” ce tout nouveau service cloud.

Pour la petite histoire, c’était la toute première fois qu’on me proposait ce genre de choses. C’était aussi la toute première fois où je me suis fait qualifier “d’influenceuse tech”. Amusant.

J’ai attendu un peu (1 an) avant de faire un retour.

Buzz, ou bad buzz ?

Pourquoi attendre pour ce retour ?

D’abord, parce que beaucoup d’autres ont dégainé plus tôt. Je vous ai mis les liens, en fin d’article, de tous les articles de mes pairs que j’ai retrouvés sur le sujet.

Ensuite parce que je voulais voir dans quelle direction le service allait aller.

Beaucoup ont reproché à nua.ge (à l’époque) d’être un peu “pauvre” en fonctionnalités, surtout par rapport à son positionnement tarifaire. A priori ce n’est pas forcément vrai, nuage se situe plutôt dans la moyenne (cf l’étude de coud Mercato).

La société qui opère nua.ge Oxeva avait répondu à cette critique en disant qu’une roadmap était en cours d’élaboration et que les points les plus bloquants seraient rapidement adressés.

Premiers pas avec l’interface

La première chose que j’ai remarqué est que l’interface était effectivement assez simple. Le site web vante d’ailleurs un service “simple mais pas simpliste”.

L’onboarding était hyper efficace (un des meilleurs que j’ai vu). La page de création d’une nouvelle VM aussi.

On a globalement cinq menus:

un menu “espace de travail” dans lequel on a les machines du projet courant
un pour gérer ces fameux projets (en créer un nouveau, le supprimer)
un pour créer des utilisateurs (nouveau)
un pour le suivi de la consommation
un pour la facturation

Les deux derniers auraient pu être fusionnés je pense, je me trompe toujours et je les inverse…

A quelques détails près, c’est tout.

Alors qu’en est il, 11 mois après ?

Je vais être franc, j’ai eu à ma disposition 10000€ de crédit.

De quoi tester allègrement toutes les fonctionnalités et même héberger pas mal de trucs pendant un bon moment.

Au niveau de la stabilité du service, je n’ai rien à redire.

Au cours des 12 derniers mois, le service a subi de brèves coupures réseau (et encore, c’est surtout les autres utilisateurs qui l’ont remonté). Mon monitoring externe n’a pas repéré grand-chose.

Au niveau infrastructure, ça semble donc être du solide.

Cependant, au niveau fonctionnalités, je vais être obligé d’être d’accord avec mes pairs. Même 11 mois après, on a vite fait le tour… On a des VMs, des projets… et c’est tout.

Des défauts corrigés

La roadmap publique a été mise en ligne et il est possible de voter pour des fonctionnalités.

Ca avait été promis quasiment depuis le lancement : l’API publique et documentée a rapidement été mise en ligne et est disponible ici.

Au fil des mois, l’interface a elle aussi été améliorée. Possibilité de transférer des IPs publiques d’une machine à l’autre, ajout de disques plus gros pour les machines (500 Go si nécessaire au lieu de 100 par défaut).

Il est également possible d’avoir une gestion des utilisateurs avec une gestion des droits basique par projet que j’utilise beaucoup.

La gestion des groupes de sécurité (firewalling / flux réseau) ont été grandement améliorés. Au début on avait le choix qu’avec traffic web et traffic SSH, il y a maintenant plus d’options.

Mais d’autres toujours bien présents

Certains des points remontés dès le début sont malheureusement toujours absents. Stéphane Bortzmeyer avait reproché à nua.ge son absence d’IPv6, c’est toujours le cas. Je l’avais également remonté via le “chat”.

Le provider terraform (ou tout autre outil d’infrastructure as code) se fait toujours attendre. On a l’API mais c’est très “manuel”.

[Edit]Il existe un provider non officiel github.com/MKCG/terraform-provider-nuage. Son créateur m’a contacté pour me l’indiquer, ainsi que le fait qu’il n’avait pas l’intention de le maintenir. Cependant, comme il est open source, n’importe qui pourrait potentiellement le faire.

Plus grave, l’interface a plein de petites limitations très agaçantes (rarement, on peut les contourner par l’API).

Les projets

Il ne semble pas possible de modifier un projet existant. On doit le supprimer (et tout ce qu’il y a dedans) et en refaire un nouveau.

Toujours en parlant des projets, ils ont des quotas, fixés par défaut à 40 coeurs, 256 Go de RAM, 2 To de stockage et 20 IP publiques.

Je trouve cette fonctionnalité très utile ! Cependant, quel intérêt de les afficher dans l’UI au moment de la création du projet, s’il n’est possible de les modifier ? Les quotas sont donc immuables, à la hausse (admettons) comme à la baisse !

Les VMs

Encore plus grave, il n’est pas possible de modifier une machine virtuelle.

Dans l’interface, les seules actions possibles sont : allumer, éteindre, redémarrer. Impossible de changer sa taille en cours de route, même éteinte. Il faut la détruire et en refaire une autre. Vous avez intérêt à bien prévoir votre capacity planning…

J’ai dû réinstaller entièrement des serveurs elasticsearch trop gros à cause de ça et j’ai bien ragé. Je suis toujours en colère, je crois.

On aurait pu contourner le problème en ré-attachant les disques, sauf qu’ils ne sont pas détachables. Un disque appartient à une VM, point. Il est créé avec, détruit avec.

Cerise sur le gâteau, ça veut dire que ça compliquera aussi la réversibilité (pourtant un point capital dans le cloud…).

Enfin, c’est plus une problématique de poweruser / bidouilleur, mais il n’est pas possible de donner un nom “long” à une machine (mavm.example.org). C’est gênant, parce que la VM est ensuite déployée à l’aide de templates cloud-init et il est non trivial de changer le hostname en FQDN de manière pérenne.

En partie à cause de ça, j’ai été incapable d’installer Proxmox VE au dessus d’une installation Debian 11 fraîche (alors que j’avais réussi sur le IaaS de Scaleway).

Il manque pas mal de modules dans les Ubuntu 22.04 donc dès que j’en bootstrap une, je lance

sudo apt update && sudo apt upgrade -y && sudo apt install curl linux-image-generic-hwe-22.04 -y && sudo reboot

Conclusion

Ca fonctionne et j’en ai abondamment profité.

J’utilise nua.ge depuis quasiment 1 an pour héberger des serveurs pour plusieurs associations auxquelles je participe, et je ne peux pas dire que je suis insatisfait du service rendu pour ces besoins basiques.

Oui, une bonne partie des promesses initiales sont là : l’interface est hyper simple, le billing est limpide, l’infra semble solide.

Cependant, si je n’avais pas mes crédits gratuits, est ce que j’aurais choisi nua.ge pour héberger ces associations ?

Car une fois l’enthousiasme des milliers d’euros de coupons et du parrainage retombés, il ne restera plus que les clients payant leurs factures.

Cette punchline de David Legrand résonne toujours…

Hébergement on Zwindler's Reflection

Je réessaye les sites statiques (Bloggrify) chez Clever Cloud

Introduction

Prérequis

Configuration de l’app

Déploiement de l’application

Ajouter un domaine

Automatiser le clever deploy

deploy-to-clever-cloud

preview par PR

Créer des tokens de CI

Déploiements depuis GitHub (ou GitLab)

Conclusion

Un an dans le nua.ge

C’est l’histoire d’un cloud

Buzz, ou bad buzz ?

Premiers pas avec l’interface

Alors qu’en est il, 11 mois après ?

Des défauts corrigés

Mais d’autres toujours bien présents

Les projets

Les VMs

Conclusion

Sources additionnelles

Automatiser le `clever deploy`