Héberger le serveur Crunu sur Google Cloud Run

Ce que fait Crunu sur Cloud Run

Crunu tourne dans le cloud sur app.crunu.com : vous n’avez donc pas besoin de votre propre serveur pour commencer. Si votre infrastructure vit dans Google Cloud, le serveur Crunu se déploie sur Cloud Run en un seul script, garde ses secrets dans Secret Manager et utilise Postgres sur Cloud SQL ou Neon.

Sur Cloud Run comme partout ailleurs, le serveur est aveugle : la base de données contient des données chiffrées, des clés publiques, des documents signés et des métadonnées, jamais une clé capable de déchiffrer une valeur.

Déployer

Il vous faut Node.js 24, gcloud connecté, un projet avec facturation, une base de données Postgres et un fichier .env créé par server-init. Les commandes se lancent depuis le répertoire du serveur Crunu, où se trouvent les scripts de déploiement.

node scripts/server-init.mjs --origin https://vault.company.example --database-url env:DATABASE_URL
sh deploy/gcp/deploy.sh --project my-project --region europe-west1 --service vault

Le script vérifie le .env, active les API Cloud Run, Artifact Registry et Secret Manager, construit une image linux/amd64 dans Artifact Registry, stocke les secrets du serveur dans Secret Manager et crée un compte de service qui ne peut lire que ces secrets. Il déploie ensuite le service.

• Secrets figés par révision. Une nouvelle version de secret n’apparaît que lorsqu’une valeur change, et le service référence les secrets par numéro de version, pas par latest. Chaque révision garde les valeurs avec lesquelles elle a été déployée : rediriger le trafic vers une révision plus ancienne ramène donc aussi ses secrets.
• Cloud SQL par son socket. Utilisez une adresse comme postgres://user:password@/database?host=/cloudsql/project:region:instance. Le script rattache l’instance au service et accorde à son compte de service le rôle Cloud SQL Client.
• Réglages fusionnés. Les variables d’environnement sont fusionnées : les valeurs définies à la main sur le service restent en place. Les variables qui ne figurent plus dans .env sont listées, et supprimées seulement avec --prune.
• Adresses des clients. Par défaut, les clients atteignent directement le service. Derrière l’équilibreur de charge externe de Google, déployez avec --trust-proxy xff:2 : le service n’accepte alors que le trafic de l’équilibreur, et PUBLIC_ORIGIN doit être l’adresse de l’équilibreur.

Le nettoyage ne tourne que s’il y a du trafic

Les machines qui font tourner l’agent crunu interrogent le serveur chaque minute par défaut : avec des machines en ligne, le nettoyage tourne donc au passage environ toutes les 5 minutes.

Anciennes révisions

Le script de déploiement n’attribue pas de tags aux révisions : les plus anciennes n’ont donc pas d’adresse propre. Si vous avez tagué des révisions à la main, retirez ces tags, car une ancienne révision taguée fonctionne avec la même base de données et les mêmes secrets :

gcloud run services update-traffic <service> --region <region> --remove-tags <tag>

Voir aussi

• Auto-hébergement
• Google Cloud Run dans la documentation
• Changer de plateforme
• Docker