Aller au contenu
quest'n'click

Clever CloudExplicationPour adminsS'applique de 4.2.3

Redéploiements

This page in EnglishCette page sur le wiki GitHub

Sur Clever Cloud, un déploiement (ou un push, ou clever restart) démarre la nouvelle instance pendant que l’ancienne sert encore. Le Studio Server est fait pour ce chevauchement : aucune écriture n’est perdue, mais les écritures sont lentes ou refusées pendant environ une minute. Cette page dit pourquoi, ce qui a été mesuré, et comment déployer sans surprendre les membres.

Pourquoi

Le spike S l’a mesuré le 17 octobre 2026 : pendant clever restart --without-cache, la nouvelle instance a démarré alors que l’ancienne répondait encore, et l’ancienne n’a jamais consigné de SIGTERM. Deux instances qui écrivent le même jeu en même temps corrompraient son histoire, et attendre un signal qui ne vient pas bloquerait la bascule. Donc :

  • Les instances partagent un bail de service dans PostgreSQL : celle qui le tient sert les écritures. Il dure 30 s et se renouvelle toutes les 10 s à l’horloge de la base ; une instance qui ne peut pas le renouveler cesse d’écrire à sa propre horloge avant que les 30 s puissent passer.
  • La nouvelle instance démarre, répond à /startz (la vérification de santé de Clever, CC_HEALTH_CHECK_PATH=/startz), puis attend : /readyz est en 503 ("writes":"waiting") et ses écritures en 503 avec Retry-After: 2 (« this instance does not serve writes yet; try again »).
  • La passation (depuis la 4.2.3). Dès qu’elle écoute, la nouvelle instance demande le bail ; le détenteur le rend à son renouvellement suivant (10 s au plus) et consigne {"event":"lease-lost",…} ; la nouvelle consigne {"event":"lease-taken",…}. Une instance plus ancienne ne reprend jamais le bail à une plus récente.
  • Un client retente une écriture refusée avec le même identifiant d’opération (X-Studio-Op), et elle est appliquée une fois. Le bail propre du journal, avec sa clôture, empêche toujours deux instances d’écrire sur la même tête.

Ce qui a été mesuré

Clever Cloud garde l’ancienne instance STOPPING environ deux minutes, qui reçoit encore des requêtes jusqu’à la fin du déploiement, et elle ne consigne aucune ligne stopping.

En tout, environ une minute d’écritures lentes ou refusées par déploiement, aucune perdue.

Pendant que les deux instances tournent, elles tiennent deux fois plus de connexions : sur le plan PostgreSQL DEV (5), le travail de fond échoue sur « too many connections » à chaque déploiement, et une écriture d’une version plus ancienne pouvait en échouer (un 500). Prenez un plan plus grand pour un déploiement dont on se sert (Applications et add-ons).

Déployer sans surprendre l’équipe

Vérifié sur : 19 octobre 2026 (les mesures ci-dessus ; commits du moteur avant le tag 4.2.3, package.json 4.2.2). Le texte de cette page lui-même n’est pas vérifié sur une installation réelle.

  1. Prévenez les membres, ou choisissez un moment calme : environ une minute d’écritures lentes ; environ deux minutes et demie d’écritures refusées pour le premier déploiement vers la 4.2.3 ou plus depuis une version plus ancienne.

  1. Déployez depuis votre machine, dans le dépôt du moteur, le worker d’abord quand les deux changent :

    # sur votre machine, dans le dépôt du moteur
clever deploy --alias my-game-worker
clever deploy --alias my-game-studio

  1. Regardez /readyz revenir à 200 et la ligne lease-taken (son instance est la nouvelle) :

    # sur votre machine
until curl -sf https://studio.example.fr/readyz; do sleep 2; done
  1. Faites une écriture (une note) et voyez-la enregistrée, à la révision suivante.

Les autres possibilités écartées

  • Compter sur SIGTERM pour passer le bail : Clever ne l’a jamais délivré de façon observable (spike S, déploiement de référence).
  • Arrêter l’ancienne instance d’abord (clever stop, puis déployer) : une minute ou plus sans Studio du tout. Gardé pour un seul cas, une migration qui change ce que lit l’ancienne version (Mettre à jour le serveur).
  • Plusieurs instances qui servent à la fois : le journal demande un seul écrivain par jeu.

Les compromis

La passation réduit la fenêtre de refus de plusieurs minutes à quelques secondes, mais le routage de Clever vers l’ancienne instance jusqu’à la fin du déploiement garde 10 à 16 s de 503. Une alerte sur /readyz doit le tolérer (Supervision).

Décisions et ADR