De GCP/Vercel à Scaleway, sans perdre une donnée
Dans [l'article précédent](/blog/pourquoi-scaleway-souverainete), j'expliquais pourquoi j'ai rapatrié tout mon perso chez un hébergeur français. Ici, place au comment — le récit technique d'une migration de sept applications, plus un backoffice, réalisée par-dessus le weekend.
Le point de départ
Sur GCP et Vercel, j'avais accumulé :
- 7 applis : ce portfolio (Nuxt), un tracker de pompes, un traducteur khmer, une appli de fiançailles, l'espace de souvenirs de couple « Lys », une API Rust, et des jeux.
- Neon pour les bases PostgreSQL.
- Google Cloud Storage pour les fichiers (photos, coffre du couple : ~5 Go).
- Une facture compute qui tournait autour de 30 €/mois — pas énorme, mais du gaspillage pour des services qui dorment 95 % du temps.
La règle numéro un : zéro perte de données
Avant de toucher à quoi que ce soit, un principe non négociable : on ne supprime rien tant que tout n'est pas vérifié. Les buckets GCS ont été copiés (jamais déplacés) vers le stockage objet Scaleway avec rclone, puis validés par checksum, octet par octet. GCS est resté intact comme sauvegarde jusqu'à la toute fin. Les souvenirs d'un couple ne se « migrent » pas à la légère.
Le cœur technique : un adaptateur GCS → S3
Le plus élégant du chantier : Scaleway Object Storage parle le protocole S3, standard de fait. Plutôt que de réécrire chaque appli, j'ai écrit un petit adaptateur qui imite l'API de Google Cloud Storage (file().save(), .download(), getFiles()…) mais tape sur S3 en dessous, via le SDK AWS. Résultat : le code métier des applis n'a quasiment pas bougé, seule la couche stockage a été échangée.
const s3 = new S3Client({
region: 'fr-par',
endpoint: 'https://s3.fr-par.scw.cloud',
forcePathStyle: true,
credentials: { accessKeyId, secretAccessKey },
})
Serverless Containers + scale-to-zero
Chaque appli a été containerisée (Docker), poussée sur le registry Scaleway, et déployée en Serverless Container configuré en min-scale = 0 : quand personne ne s'en sert, zéro conteneur tourne, zéro euro dépensé. Au premier accès, ça démarre à froid en une poignée de secondes. Pour un usage perso, le compromis est idéal.
Tout est regroupé sous des sous-domaines de chetana.fr, avec certificats TLS Let's Encrypt provisionnés automatiquement — un simple enregistrement DNS + une commande, et le HTTPS est là.
Les pièges rencontrés (pour ceux qui suivront)
- Repointer les URLs internes. En supprimant mon ancienne API, j'ai cassé sans le voir le backend du portfolio (blog, expériences, compétences disparus). Leçon : tracer toutes les dépendances entre services avant de couper quoi que ce soit.
- La variable
PORTest réservée sur les conteneurs Scaleway (elle est injectée automatiquement) — impossible de la définir soi-même. container updateremplace toute la map d'environnement : changer une variable oblige à toutes les repasser, sous peine de perdre les secrets.- CORS et redirections : les anciennes URLs
*.chetana.devrenvoient désormais un 301/308 verschetana.fr, pour ne casser aucun lien partagé.
Le résultat
Sept applis + ce backoffice (celui-là même avec lequel j'écris cet article ✍️), toutes en France, sous un seul domaine, avec une facture compte qui tend vers zéro au repos. La base de données (Neon) suivra bientôt vers Scaleway Serverless SQL pour co-localiser data et calcul.
Migration bouclée. Et accessoirement, ce texte est le tout premier article publié depuis le nouveau backoffice, sur la nouvelle infra. Méta, non ? 🇫🇷
Commentaires
Aucun commentaire pour le moment.